Multiple Controllers (And making them cooperate). ¶

This page documents the process of designing a multi-controller OpenFlow architecture where the controllers actively collaborate to emulate a network stack for experiments.

Quick Links. ¶

Overview
Logistics
Subpages - extra notes related to this page
Logs - records of work

Overview. ¶

The basic architecture for an OpenFlow network is a client - server (switch - controller) model involving a single controller and one or more switches. Networks can host multiple controllers. FlowVisor virtualizes a single network into slices so that it can be shared amongst various controllers, and the newest OpenFlow standard (v1.3.0) defines equal, master and slave controllers to coexist as part of a redundancy scheme in what would be a single slice. A multi-controller scheme that isn't really explored yet is one where each controller has a different function, and cooperate.

Cooperation is a fairly complex task, for several reasons:

• There must be a communication scheme so that the controllers can cooperate
• A single protocol suite can be divided amongst controllers in various ways
• The information being communicated between controllers changes with protocol suite and division of tasks

Developing a general solution to this problem is difficult, so focus will be narrowed down to a more specific task of producing a cooperative multi-controller framework for running a topology configuration service split into a global and local component, and an experimental routing protocol with ID resolution.

Logistics ¶

Work Setup ¶

The ​Mininet SDN prototyping tool will be used for testing and debugging implementations. The implementation will be based on modified versions of OpenFlow Hub's ​Floodlight controller.

Proof-of-concept experiments for evaluating the architecture will be run on ORBIT sandboxes.

Timeline ¶

An approximate 3.5 months (14 weeks) is allotted for design, implementation, and evaluation. the ideal split of time is the following:

• 3-5 weeks: architecture layout, topology control, context framework
• 3-4 weeks (end of: week 6-9): integrating routing/resolution
• 3-4 weeks (end of: week 9-13): evaluation
• remainder (end of: week 14): documentation

This schedule is a general outline and is used as a guideline; the actual work-flow will inevitably change.

Subpages ¶

Logging. ¶

(9/5) ¶

---

Home.