Version 3 (modified by 12 years ago) ( diff ) | ,
---|
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)
Attachments (2)
- module_arch.png (85.4 KB ) - added by 12 years ago.
- controller_arch_rev-3.png (62.4 KB ) - added by 12 years ago.
Download all attachments as: .zip