OpenFlow support in CloudLab
Part 1: Software OpenFlow:
GENI: Intro to OpenFlow
The Rspecs referenced in the above OVS tutorial document should work on the APT cluster available through the CloudLab portal.
Part 2a: General Hardware OpenFlow Information:
If you don't have a concrete reason for using hardware OpenFlow, then we suggest that you stick with a software implementation. There are several things you must take into careful consideration if you believe hardware OF is necessary in your experiments:
* Not all OF matching / actions are handled on the switch fast path.
If you are unsure what is meant by "switch fast path", please take some time to study switch hardware architecture before going any further. Typically switches can use the fast path to match (via a TCAM or other hardware look-up mechanisms) on OF OXMs that correspond to typical Layer 2 packet switching functions. E.g., on Ethernet addresses and VLAN tags.
In the case of the HP FlexFabric switches in the CloudLab Utah cluster, the hardware fast path capabilities are enumerated in the JSON info dump linked in below, found under the section for the table with ID 100. This table corresponds to the "MAC-IP" table in HP's documentation. The FlexFabric switches also support what the documentation calls an "extensibility" table, which has ID 200 in the JSON dump below. This table is more flexible, but is at least partially handled by the switch's general CPU (slow path). Since the slow path can introduce jitter and latency, depending on current load, using the extensibility table is discouraged. In fact, it may be possible to bog down the switch's CPU and impact other slow path functionality.
* Not everything in the OF spec is supported by any particular switch platform.
Virtually all standards have optional elements. OpenFlow is no exception. Switches can support a particular version of OpenFlow, but almost certainly will not support all aspects of it. For this reason, we highly recommend reviewing the supported match and action rules for each table type that a switch platform supports. For the HP FlexFabric switches deployed in the Utah CloudLab cluster, please refer to the JSON dump linked in below.
* OF controllers have bugs and shortcomings.
When domains on a switch (e.g. vlans) are setup to be managed by an OF instance, it is up to the controller to properly direct traffic. When problems arise, resist the temptation to conclude that the switch must be at fault. For example, the "simple switch" application that comes with the Ryu controller is extremely limited. It does not properly check for the existence of tables at a particular ID (assumes ID 0). It does not check to see if tables have support for the OXMs and actions in flow rules it tries to push. It does not properly handle multi-switch topologies that have a fan out greater than two. Finally, it does not properly handle or even report many errors that attached switches send along.
We do not endorse any particular OpenFlow controller implementation. It is up to you to find a suitable controller and ensure that its implementation conforms to the OpenFlow version that the switches support. You must also configure or modify it to operate with the parameters setup by CloudLab. See the next section for details on the Utah CloudLab cluster's switches and how they are configured for OpenFlow.
Part 2b) Using hardware OpenFlow at the Utah CloudLab cluster:
Note: Please read the previous section before proceeding.
The "CloudLab Utah" cluster offers OpenFlow access to the physical switches (OF instances per vlan). To request this, you can add the following directive to the "link" specification in your Rspec to create an OF instance, which will be pointed at the controller you specify:
<emulab:openflow_controller url="tcp:CONTROLLER_IP:6633"/>
In-line example:
<link xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1" client_id="lan-1">
<interface_ref xmlns="http://www.geni.net/resources/rspec/3" client_id="interface-0"/>
<interface_ref xmlns="http://www.geni.net/resources/rspec/3" client_id="interface-1"/>
...
<emulab:openflow_controller url="tcp:CONTROLLER_IP:6633"/>
</link>
Substitute "CONTROLLER_IP" with the IP address of your OF controller host. Adjust the port (6633 above) as necessary.
* Notes on HP FlexFabric (Comware 7) switches and how CloudLab configures OpenFlow:
They are OF 1.3.1 compliant. Note that this does NOT mean they implement everything in the OF 1.3.1 spec! See the JSON dump below for specific details on what OXMs can be matched, and what actions are available in which tables.
When you ask for OpenFlow as above, CloudLab will set up a "MAC-IP" hardware table at ID 100, and an "extensibility" table at ID 200 for your OF instance. This is important to keep in mind because some controller software assumes that a table exists at ID 0.
You must use a publicly accessible (routed) IP address for your controller. CloudLab cannot currently setup a channel in the private experimental plane for your controller-to-switch communication. You can make use of a CloudLab node to run your controller on by first instantiating a single node profile, setting up your controller on it, and then instantiating another profile that requests OpenFlow. You would use the public IP address of the instantiated controller node from the first profile in the "openflow_controller" url field in the RSPEC of the second profile.
The following document has detailed information, dumped from Floodlight, showing the OF capabilities of CloudLab Utah's Comware 7 (HP FlexFabric) switches:
No comments:
Post a Comment