| | 1 | = Multiple Controllers (And making them cooperate). = |
| | 2 | This page documents the process of designing a multi-controller !OpenFlow architecture where the controllers actively collaborate to emulate a network stack for experiments. |
| | 3 | |
| | 4 | == Quick Links. == |
| | 5 | [#i Overview.] [[BR]] |
| | 6 | |
| | 7 | == Overview. == #i |
| | 8 | 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. |
| | 9 | |
| | 10 | Cooperation is a fairly complex task, for several reasons: |
| | 11 | |
| | 12 | * There must be a communication scheme so that the controllers can cooperate |
| | 13 | * A single protocol suite can be divided amongst controllers in various ways |
| | 14 | * The information being communicated between controllers changes with protocol suite and division of tasks |
| | 15 | |
| | 16 | 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. |
| | 17 | |
