= Multiple Controllers (And making them cooperate). = #home 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. == [#i Overview] [[BR]] [#ii Logistics] [[BR]] [#iii Subpages] - extra notes related to this page [[BR]] [#iv Logs] - records of work == Overview. == #i 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 == #ii ==== Work Setup ==== The [http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet Mininet SDN prototyping tool] will be used for testing and debugging implementations. The implementation will be based on modified versions of !OpenFlow Hub's [http://floodlight.openflowhub.org 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 == #iii == Logging. == #iv === (9/5) === ---- [#home Home.]