NS3 - OpenFlow switch support

https://www.nsnam.org/docs/models/html/openflow-switch.html

OpenFlow switch support

ns-3 simulations can use OpenFlow switches (McKeown et al. [1]),widely used in research. OpenFlow switches are configurable via theOpenFlow API, and also have an MPLS extension for quality-of-service andservice-level-agreement support. By extending these capabilities to ns-3for a simulated OpenFlow switch that is both configurable and can usethe MPLS extension, ns-3 simulations can accurately simulate many differentswitches.

The OpenFlow software implementation distribution is hereby referred to asthe OFSID. This is a demonstration of running OpenFlow in software thatthe OpenFlow research group has made available. There is also an OFSIDthat Ericsson researchers created to add MPLS capabilities; this is theOFSID currently used with ns-3. The design will allow the users to,with minimal effort, switch in a different OFSID that may include moreefficient code than a previous OFSID.

Model Description

The model relies on building an external OpenFlow switch library (OFSID),and then building some ns-3 wrappers that call out to the library.The source code for the ns-3 wrappers lives in the directorysrc/openflow/model.

Design

The OpenFlow module presents a OpenFlowSwitchNetDevice and a OpenFlowSwitchHelper forinstalling it on nodes. Like the Bridge module, it takes a collection ofNetDevices to set up as ports, and it acts as the intermediary betweenthem, receiving a packet on one port and forwarding it on another, or allbut the received port when flooding. Like an OpenFlow switch, it maintainsa configurable flow table that can match packets by their headers and dodifferent actions with the packet based on how it matches. The module’sunderstanding of OpenFlow configuration messages are kept the same formatas a real OpenFlow-compatible switch, so users testing Controllers vians-3 won’t have to rewrite their Controller to work on realOpenFlow-compatible switches.

The ns-3 OpenFlow switch device models an OpenFlow-enabled switch. It is designed toexpress basic use of the OpenFlow protocol, with the maintaining of a virtualFlow Table and TCAM to provide OpenFlow-like results.

The functionality comes down to the Controllers, which send messages to theswitch that configure its flows, producing different effects. Controllers canbe added by the user, under the ofi namespace extending ofi::Controller. Todemonstrate this, a DropController, which creates flows for ignoring every singlepacket, and LearningController, which effectively makes the switch a more complicatedBridgeNetDevice. A user versed in a standard OFSID, and/or OF protocol, can writevirtual controllers to create switches of all kinds of types.

OpenFlow switch Model

The OpenFlow switch device behaves somewhat according to the diagram setup as a classical OFSIDswitch, with a few modifications made for a proper simulation environment.

Normal OF-enabled Switch:

| Secure Channel                  | <--OF Protocol--> | Controller is external |
| Hardware or Software Flow Table |

ns-3 OF-enabled Switch (module):

| m_controller->ReceiveFromSwitch() | <--OF Protocol--> | Controller is internal |
| Software Flow Table, virtual TCAM |

In essence, there are two differences:

1) No SSL, Embedded Controller: Instead of a secure channel and connecting to anoutside location for the Controller program/machine, we currently only allow aController extended from ofi::Controller, an extension of an ns3::Object. Thismeans ns-3 programmers cannot model the SSL part of the interface or possibilityof network failure. The connection to the OpenFlowSwitch is local and there aren’t anyreasons for the channel/connection to break down. <<This difference may be anoption in the future. Using EmuNetDevices, it should be possible to engage anexternal Controller program/machine, and thus work with controllers designedoutside of the ns-3 environment, that simply use the proper OF protocol whencommunicating messages to the switch through a tap device.>>

2) Virtual Flow Table, TCAM: Typical OF-enabled switches are implemented on a hardwareTCAM. The OFSID we turn into a library includes a modelled software TCAM, that producesthe same results as a hardware TCAM. We include an attribute FlowTableLookupDelay, whichallows a simple delay of using the TCAM to be modelled. We don’t endeavor to make thisdelay more complicated, based on the tasks we are running on the TCAM, that is a possiblefuture improvement.

The OpenFlowSwitch network device is aimed to model an OpenFlow switch, with a TCAM and a connectionto a controller program. With some tweaking, it can model every switch type, per OpenFlow’sextensibility. It outsources the complexity of the switch ports to NetDevices of the user’s choosing.It should be noted that these NetDevices must behave like practical switch ports, i.e. a Mac Addressis assigned, and nothing more. It also must support a SendFrom function so thatthe OpenFlowSwitch can forward across that port.

Scope and Limitations

All MPLS capabilities are implemented on the OFSID side in the OpenFlowSwitchNetDevice,but ns-3-mpls hasn’t been integrated, so ns-3 has no way to pass inproper MPLS packets to the OpenFlowSwitch. If it did, one would only need to makeBufferFromPacket pick up the MplsLabelStack or whatever the MPLS headeris called on the Packet, and build the MPLS header into the ofpbuf.

Future Work

References

[1]	McKeown, N.; Anderson, T.; Balakrishan, H.; Parulkar, G.; Peterson, L.; Rexford, J.; Shenker, S.; Turner, J.; OpenFlow: enabling innovation in campus networks, ACM SIGCOMM Computer Communication Review, Vol. 38, Issue 2, April 2008.

Usage

The OFSID requires libxml2 (for MPLS FIB xml file parsing), libdl (for address fault checking),and boost (for assert) libraries to be installed.

Building OFSID

In order to use the OpenFlowSwitch module, you must create and link theOFSID (OpenFlow Software Implementation Distribution) to ns-3.To do this:

1. Obtain the OFSID code.An ns-3 specific OFSID branch is provided to ensureoperation with ns-3. Use mercurial to download this branch and waf to buildthe library:

   $ hg clone http://code.nsnam.org/openflow
   $ cd openflow
   

   From the “openflow” directory, run:

   $ ./waf configure
   $ ./waf build
   

2. Your OFSID is now built into a libopenflow.a library!To link to an ns-3 build with this OpenFlow switch module, run from the ns-3-dev(or whatever you have named your distribution):

   $ ./waf configure --enable-examples --enable-tests --with-openflow=path/to/openflow
   

3. Under ---- Summary of optional NS-3 features: you should see:

   "NS-3 OpenFlow Integration     : enabled"
   

   indicating the library has been linked to ns-3. Run:

   $ ./waf build
   

to build ns-3 and activate the OpenFlowSwitch module in ns-3.

Examples

For an example demonstrating its use in a simple learning controller/switch,run:

$ ./waf --run openflow-switch

To see it in detailed logging, run:

$ ./waf --run "openflow-switch -v"

Helpers

Attributes

The SwitchNetDevice provides following Attributes:

• FlowTableLookUpDelay: This time gets run off the clock when making a lookup in our Flow Table.

• Flags: OpenFlow specific configuration flags. They are defined in the ofp_config_flags enum. Choices include:

  OFPC_SEND_FLOW_EXP (Switch notifies controller when a flow has expired),OFPC_FRAG_NORMAL (Match fragment against Flow table),OFPC_FRAG_DROP (Drop fragments),OFPC_FRAG_REASM (Reassemble only if OFPC_IP_REASM set, which is currently impossible,because switch implementation does not support IP reassembly)OFPC_FRAG_MASK (Mask Fragments)

• FlowTableMissSendLength: When the packet doesn’t match in our Flow Table, and we forward to the controller,

  this sets # of bytes forwarded (packet is not forwarded in its entirety, unless specified).

Note

TODO

Tracing

Note

TODO

Logging

Note

TODO

Caveats

Note

TODO

Validation

This model has one test suite which can be run as follows:

$ ./test.py --suite=openflow