GSoC 2013: A Master/Slave configuration of OpenFlow controllers

[Bertrand Bonnefoy-Claudet]

Hi all,

I'd be interested in applying for the project on a master/slave configuration. Being quite new to RouteFlow, it's hard to come up with my own ideas (I find the concept of Mirage pretty exciting but really don't know whether it could leverage RouteFlow) but I think that resiliency is crucial for networks and working on that looks cool.

I'm comfortable with Python and IP protocols in general but just familiar with C, C++, OPSF, distributed and HA protocols (I can think of VRRP) and JSON/REST. I hope it seems okay for this project, I believe I can quickly catch up on that and MongoDB.

As suggested, I've setup the development environment from a newly installed Ubuntu VM and run the two tests successfully (though sequence of commands and timing seem important to make rftest2 work) and played a bit with rfweb.

I've also read most of what is on the wiki and here are a few questions for later:
* I've seen mentions of a support for multiple controllers. Does it include redundant controllers or only distributed control? If not, has work already been committed for enabling such a master/slave config?
* It's written on the main page of the wiki that new pages like RFProxy porting guides should be published soon. Will they be available before GSoC starts?

The internals of RouteFlow are still not clear to me (especially the OpenFlow translation rules) so I will continue to look at the specifications, the code and the produced flows during the tests.

Thanks,
--
Bertrand

[Christian Esteve Rothenberg]

Hi Bertrand,

I can only agree that networks without resilience are basically useless :)

That is why we suggest the resiliency / multi-controller work on RouteFlow.

Going into your questions:

>>> * I've seen mentions of a support for multiple controllers. Does it include redundant controllers or only distributed control? If not, has work already been committed for enabling such a master/slave config?

We have only worked on multiple controllers for distributed control,
i.e. a subset of OpenFlow devices controller by a controller with
RFProxy, Nothing done for the master/slave config. Exactly this is one
of the suggested topics for the GSOC projects.

Basically it requires two things:
1.- A keep alive mechanism among OF controllers running RFProxy.
2.- A (consensus?) algorithm to decide on who becomes master and then
use the OF 1.2/1.3 role change commands to inform the OF switches
about their new mater controller connection.

>>> * It's written on the main page of the wiki that new pages like RFProxy porting guides should be published soon. Will they be available before GSoC starts?

Hmmm. Not sure about this. I will check with the team how the plans
look like to document "RFProxy porting". What I can guarantee you is
that the people (cc: here) that have done for POX, Floodlight, and Ryu
will be available to help other RouteFlow contributors on their GSOC
activities. That said, I would not count on _documentation_ for this
work. (Actually, there are some documents in portuguese if you want).
Here is a recent presentation including details on the RFProxy port to Ryu:
https://dl.dropboxusercontent.com/u/15183439/PPTs/ONS13-Dev-Track-Ryu-RouteFlow-Rothenberg-20130416.pdf

Cheers,
Christian

> --
> You received this message because you are subscribed to the Google Groups
> "RouteFlow" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to routeflow-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Christian Esteve Rothenberg, Ph.D.
Converged Networks Business Unit
CPqD - Center for Research and Development in Telecommunications
Tel. (+55 19) 3705 4479 / Cel. (+55 19) 8193-7087

[Bertrand Bonnefoy-Claudet]

Thank you for your answers and the document you mentioned. I have a
few more questions.

First I'd like to know what you will expect from a student working on
this project wrt programming. It seems to me that some work needs to
be done before coding anything and I'm wondering whether such
reflections can be part of the official assignment or should have
already been done before the start of the GSoC program. That would
help me come up with a coherent schedule for my application (I don't
really now how accurate it is supposed to be for such a project).

2013/4/22 Christian Esteve Rothenberg <est...@cpqd.com.br>:

>> * I've seen mentions of a support for multiple controllers. Does it include redundant controllers or only distributed control? If not, has work already been committed for enabling such a master/slave config?
>
> We have only worked on multiple controllers for distributed control,
> i.e. a subset of OpenFlow devices controller by a controller with
> RFProxy, Nothing done for the master/slave config. Exactly this is one
> of the suggested topics for the GSOC projects.
>
> Basically it requires two things:
> 1.- A keep alive mechanism among OF controllers running RFProxy.
> 2.- A (consensus?) algorithm to decide on who becomes master and then
> use the OF 1.2/1.3 role change commands to inform the OF switches
> about their new mater controller connection.

I've read the related sections in the OpenFlow specification and I'm
wondering if the following scheme should be supported by RouteFlow,
that is, whether distribution and redundancy could be mixed together.
For example, let's say we have three subnetworks and each controller
is responsible for a subset of this composite network (these subsets
overlap):

Subnet1: C1, C2
Subnet2: C2, C3
Subnet3: C3, C1

Maybe that's a minor concern but I'm still figuring things out about RouteFlow.

[Christian Esteve Rothenberg]

Hi Bertrand,

IJt is expect that you account in you proposal for one or two weeks to
plan for the detailed implementation plan and some catch up on the
code documentation and related work material.

As you said, the most important factor is that your proposal contains
a coherent, realistic schedule. Something between 1 and 3 weeks of
preparation and planning would make sense. Of course, the more
accurate you are on your proposal the better I expect it to be
evaluated, although this in turn depends on the content itself of the
proposal, e.g., you could be very accurated on implementing a trivial
set of features and that would be not as valuable as being less
accurate over a more comprehensive implementation target.

As for your question, I understand that your notion of subnet is about
a collection of switches, or do you mean IP subnets?
I would not be that concerned about this specfic setup. For the
Master/Slave subproject for instance, I would consider a simpler setup
with 4 switches as in rftest2 where all of them are connected to a
single Controller instance in Master Mode running RFProxy, and also to
a second controller in Slave Mode also running RFProxy. In case that
the Master controller fails the Slave should be able to informing the
switches about its new role as a Master and the remaining pieces of
the RouteFlow control plane should be keep running as if nothing had
happened.

Cheers,
Christian

[Bertrand Bonnefoy-Claudet]

Okay for the time schedule, I will do my best. :)

2013/4/29 Christian Esteve Rothenberg <est...@cpqd.com.br>:

> As for your question, I understand that your notion of subnet is about
> a collection of switches, or do you mean IP subnets?

You're right, I meant a subset of the switches. I shouldn't have used
the word "subnet" as it usually refers to IP networks. I will consider
your more simple example since it will probably make it easier for me
to go ahead and understand how the whole system could work.

I'm also taking a closer look at RFProxy and POX but I've also read
about a Ryu implementation and as I'd prefer to work with Ryu, could
you point me at where to go to make Ryu work with RouteFlow?

[Christian Esteve Rothenberg]

Hi Bertrand,

we suggest/support using Ryu for the OpenFlow 1.3 develpments.

Here is the 1.2 code for rfproxy. The 1.3 version is foundamentally the same and will be available at the beginning of the GSOC activities or earlier.

https://github.com/raphaelvrosa/RF-OFv1.2

-Ch

--
You received this message because you are subscribed to the Google Groups "RouteFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to routeflow-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Srijan Mishra]

Hello Christian,

You mentioned that rfproxy is already implemented using 1.2 in the above repo and is fundamentally same as 1.3. Doesn't  the first project "Applying OF 1.3 to IP routing" require same thing? Is it only related to applying new features like IPv6, etc and merging the repo having MPLS implementation?

Also you mentioned that multiple controller have been used for distributed control. Is it a part of the github repo? Can you please provide a brief description about its architecture and working? I basically have doubt how multiple controller instances communicate with the openflow switches (which controller is responsible for it from the many controllers, it seems to be a point to be covered in the master/slave architecture or some other mechanism is being used currently)?

Regards

[Christian Esteve Rothenberg]

Hi Srijan,

> You mentioned that rfproxy is already implemented using 1.2 in the above
> repo and is fundamentally same as 1.3. Doesn't the first project "Applying
> OF 1.3 to IP routing" require same thing? Is it only related to applying new
> features like IPv6, etc and merging the repo having MPLS implementation?

That is right. The basic 1.3 support should be there in the Ryu-based
1.3 RFProxy implementation. However there are a number of features on
the RouteFlow side that need to be worked out to make use of the OF
1.3 features. For instance:

- Implementing matching on L2, L3, and ACL/firewall rules as separate
tables in the OpenFlow pipeline. (see related issues at github
including the vanderwercken efforts:
https://github.com/CPqD/RouteFlow/pull/40)
- Implementing the current next hop forwarding as group table entries.
- Adding support to read and install IPv6 and MPLS entries.

> Also you mentioned that multiple controller have been used for distributed
> control. Is it a part of the github repo? Can you please provide a brief
> description about its architecture and working? I basically have doubt how
> multiple controller instances communicate with the openflow switches (which
> controller is responsible for it from the many controllers, it seems to be a
> point to be covered in the master/slave architecture or some other mechanism
> is being used currently)?

Allan may be able to give you the latest pointers. Currently the
multiple controller support is not per switch, that is, one switch is
always connected on OF controller running RFProxy. HOwever, we added
support to have multiple RFProxy controllers each controlling a
separate set of OF switches. I think the code is up in the latest
version but not fully documented and enabled by default.

The high availability GSOC idea should work on master/slave support,
that is having two OF controllers + RFProxy associated to each OF
switch. The project should implement the mechanisms to manage the role
(Master/Slave/Equal) of each controller, including detecting failures.
Since Master/Slave was introduced in OF 1.2, the project should run on
this protocolo version or above, preferably using OF 1.3. Therefore,
one could envision some of these activities being covered in the 1.3
Support project, but we did not want to overload the project scope for
the given time frame. Getting high availability right may be a
consuming task depending on the number and type of failures to be
support and at what performance level.

Thanks for your interest,
Christian

[Christian Esteve Rothenberg]

The currently supported segmented (distributed) control using multiple
controllers is described here:
https://sites.google.com/site/routeflow/documents/sbrc13-routeflow-allan.pdf?attredirects=0

[Bertrand Bonnefoy-Claudet]

I've tried to run rftest1_ryu but haven't succeeded yet so I'll try
again later. Maybe I will be able to use code that has recently been
merged (or will soon be) to run it.

Regarding controller redundancy, I'd like to make sure I get it right.
I've attached a diagram which is similar to the one on the wiki page
for rftest2 but with a little bit more details (it's a lot easier to
work on an exampe). Does it seem correct?

So, as far as I can tell, RVFS and A-D switches will have to deal with
two controllers, which shouldn't be too hard to do given the OpenFlow
specification, but the RFServer will also need to be aware of the fact
that two controllers will handle the network, which might require
changes in its code and maybe in the IPC protocol. Am I heading in the
right direction?

I'm working on a first version of my proposal that I should submit
soon. I must say there are more details to be taken into account than
I expected so I'm probably going to make a lot of guesses that will be
refined later. I hope that's fine.

I have a rough idea about how to split the work. During the first
phases, the controllers wouldn't need to elect a slave or a master
because we could make tests with fixed scenarios. Therefore,
consensus-based or whatever election scheme can be implemented
afterwards.

The first coding phase could consist in developing and testing each
part (controllers + OF network, then controllers + RFVS, then
controllers + RFServer) independently but I'm really not sure it will
be possible that way because some of these components seem to rely on
each other.

I'll try to figure that out but any hints would be welcome. :)

Thanks,
--
Bertrand

2013/4/30 Christian Esteve Rothenberg <est...@cpqd.com.br>: