Context Navigation

OFIntro

Timestamp:: Aug 1, 2013, 8:54:49 PM (11 years ago)
Author:: akoshibe
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

Internal/OpenFlow/OFIntro

-              v10
+              v11
 Mininet's datapaths are backed by OVS. Therefore, if you have a Mininet install, you get OVS for "free". You can use OVS directly for your data plane.
+----
 = II More complex examples = #II
 It is possible to run multiple instances of controllers (for whatever reason), or different logical components together in the same network.
 …
 === Sections ===
  [#multi 2.1 Multiple Controllers ][[BR]]
  [#fv 2.2 With !FlowVisor (Network virtualization/slicing) ][[BR]]
+ [#fv 2.2 Network virtualization/slicing ][[BR]]
 == 2.1 Multiple Controllers == #multi
 You may have multiple controllers in the same logical space of the control plane for various reasons - special applications, failover, etc.
+You may have multiple controllers in the same logical space of the control plane for various reasons - special applications, fail-over, distributed control planes, etc.
  * 2.1.1 On multiple hosts
 …
 If each controller is running on its own host (machine, VM, etc.), there is little to change; if you have hosts A,B, and C, and Floodlight instances running on each, switches can be pointed to targets A:6633, B:6633, C:6633, or any combination thereof (switches can be pointed to multiple controllers).
+=== 2.1.2 On the same host ===
+=== 2.1.2 On the same host === #2_1_2
+==== The Floodlight configuration file ====
 Multiple instances of Floodlight may be run on the same host, as long as each controller listens on a separate set of sockets. In this case, all controllers would be on the same IP address(es), so you must change the ports they are listening on. These ports include the !OpenFlow control port (TCP 6633), REST API (TCP 8080), and debug (TCP 6655).
 …
 Several entries can be added to this list to tweak TCP port values. Unfortunately, these entries may change fairly frequently due to active development.
  * !net.floodlightcontroller.restserver.RestApiServer.port = 8080
  * !net.floodlightcontroller.core.internal.FloodlightProvider.openflowport = 6633
  * !net.floodlightcontroller.jython.JythonDebugInterface.port = 6655
+ * net.floodlightcontroller.restserver.!RestApiServer.port = 8080
+ * net.floodlightcontroller.core.internal.!FloodlightProvider.openflowport = 6633
+ * net.floodlightcontroller.jython.!JythonDebugInterface.port = 6655
 Each entry should be on its own line, with no spaces or newlines in between lines. For example, to change the port that Floodlight listens for switches on from the default of 6633 to 6634, append:
 …
 }}}
+Each instance of the controller run on the same host can then be pointed to its own .properties file with the `-cf` flag, with different port value parameters. Going with a similar example from earlier, you may have one host A and three Floodlight instances 1,2, and 3, configured as below:
+==== Launching multiple controllers ====
+Each instance of the controller run on the same host can be pointed to its own .properties file with the `-cf` flag, with different port value parameters. Begin by making as many copies of the default .properties file as you will have controllers. Going with a similar example as earlier, you can have one host A and three Floodlight instances 1,2, and 3, configured as below:
  || || 1 || 2 || 3 ||
 …
  || !JythonDebugInterface.port || 6655 || 6656 || 6657 ||
 No ports should be shared by the three instances, or else they will likely throw errors at startup, exiting shortly after.
 With a .properties file for each instance under resources/ (named 1,2, and 3.properties for this example), you may launch the controllers in a loop:
+No ports should be shared by the three instances, or else they will probably throw errors at startup and exit shortly after.
+With a .properties file for each instance under resources/ (named 1,2, and 3.properties for this example), you can launch the controllers in a loop for example:
 {{{
 for i in `seq 1 3`; do
 …
 == 2.2 With !FlowVisor (Network virtualization/slicing) == #fv
+A more typical case you might encounter is a network that is sliced, or virtualized.
+ * 2.2.1 A brief intro to network virtualization
+ * 2.2.2 Virtualization with multiple hosts
+ * 2.2.3 On the same host
+=== 2.2.1 A brief intro to network virtualization ===
 A virtualized network is organized as below:
 {{{
 …
                   [network]
 }}}
+The network hypervisor provides each controller with an illusion that it is the only controller in the network. The analogy used in the !FlowVisor whitepaper is that of multiple VMs sharing the same physical machine.
+A network hyperviser like [http://onlab.us/flowvisor.html FlowVisor] sits between the control and data plane, intercepting and re-writing the contents of the !OpenFlow control channel to one or more controllers running independently of one another. Ultimately, the network hypervisor provides each controller with an illusion that it is the only controller in the network. It accomplishes this by
+. Rewriting the topology information conveyed by !OpenFlow (in the form of PORT_STATs and !PacketIns triggered by LLDP messages) before it reaches each controller, allowing it to only work on a subset, or slice, of the network, and
+. Mapping the !PacketIns/!PacketOuts to and from each controller to the proper sets of switches and switch ports.
+How the re-writing occurs depends on a set of admin-defined policies.
+=== 2.2.2 Virtualization with multiple hosts ===
+We begin by introducing a simple example of a virtualized topology:
+{{{
+[Floodlight 1] [Floodlight 2]
+           \    /
+         [FlowVisor]
+              |
+          [Mininet]
+}}}
+Each component above will be run on a separate node. Since we need more than two nodes, you may want to reserve either Sandboxes 4 or 9. The components can also be run on the same node, with the caveats discussed in the next section, 2.2.3.
+Here, Mininet will be used to emulate a three-switch, three-host data plane:
+{{{
+h1   h2   h3
+ |    |    |
+s1---s2---s3
+}}}
+This data plane will be sliced so that one Floodlight instance will control switches s1 and s2, and the other, s3.
+=== 2.2.3 On the same host ===
+As with the case of multiple controllers on the same VM/host, you must be careful that neither !FlowVisor nor the controllers listen on the same sets of ports. For the multiple controllers, this can be avoided as described in [#2_1_2 Section 2.1.2]. !FlowVisor and Floodlight conflict on ports 6633 and 8080.
 ----