From Nsnam
Revision as of 16:52, 10 February 2013 by Vedranm (Talk | contribs) (Remove manual links and replace them with wiki links)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

My approach and deliverables are described in the project's wiki page.

The code I've produced so far is available in the ns-3 mercurial repository [1].


This project will enable ns-3 simulations to use OpenFlow switches (McKeown et al.), widely used in research. OpenFlow switches are configurable via the OpenFlow API, and also have an MPLS extension for quality-of-service and service-level-agreement support. By extending these capabilities to ns-3 for a simulated OpenFlow switch that is both configurable and can use the MPLS extension, ns-3 simulations can accurately simulate many different switches.

The Switch module presents a SwitchNetDevice and a SwitchHelper for installing it on nodes. Like the Bridge module, it takes a collection of NetDevices to set up as ports, and it acts as the intermediary between them, receiving a packet on one port and forwarding it on another, or all but the received port when flooding. Like an OpenFlow switch, it maintains a configurable flow table that can match packets by their headers and do different actions with the packet based on how it matches. The module's understanding of OpenFlow configuration messages are kept the same format as a real OpenFlow-compatible switch, so users testing Controllers via ns-3 won't have to rewrite their Controller to work on real OpenFlow-compatible switches.


The Switch module's basic design is finished, although there's a possibility SwitchChannel will be removed before the project concludes (it's currently superfluous). SwitchNetDevice has a working flow table and utilizes openflow-interface.h{.cc} to integrate the OFSID code. It can receive Packets from ns3 over its NetDevice ports, translate them into an OpenFlow buffer to run through the flow table, then translate them back into Packets and output via one or more (if flooding) ports.

There's a test/demo (located in scratch/ when downloading the code) that sets up a simple SwitchNetDevice with 4 ports that each connect to one node. Packets are then sent from node 0 to node 3 and from node 3 to node 0 over 10 seconds. It is set to log all information messages from SwitchNetDevice, which detail receiving a packet on a port and constructing a flow for it. It currently has three modes (change the DeviceAttribute "DemoType" to NONE, DROP, or LEARNING). The DROP and LEARNING modes make the SwitchNetDevice configure its flow table to demonstrate the flow table's usability. The DROP mode builds a flow for a received packet that just drops the packet, so logging messages will show that two flows are created, one for packets received from node 0, and one for packets received from node 3. The first packet from these nodes create the flow that matches it, and the packets that follow will match to the flow and be dropped accordingly. The LEARNING mode builds a flow for a received packet that floods it amongst the ports until its destination is matched to a port when another packet sourced to the destination is received by the SwitchNetDevice.

For details on how I've gotten here, check the Wiki's Progress section which chronicles my week-to-week.

Future Goals

  • Once the csma-switch demo for showing OpenFlow functionality is done, create a second test for showing OpenFlow MPLS functionality.
  • Incorporate ns-3 simulation clock.
  • Incorporate ns-3-configurable parameters into the switch code.
  • Explore ways of allowing controllers to access the ns-3 OpenFlow switches. If an rconn is created on a port, ethernet device, or tap, then you can run a separate controller program (a sample is in the OFSI code) to push IP packets with an OpenFlow message over the rconn. I haven't yet explored the best way to create and manage this rconn.
  • Explore the OFSI STP (spanning tree protocol) implementation for possible use.

Current Issues

Currently the test/demo LEARNING mode doesn't work. I'm still learning how to tweak the OFSI flow table implementation; there's some work to be done on creating flows with an output action. The learning algorithm itself also needs to be designed (matching a received packet to see if it's source is the destination of a flow and thus should constrain to one port).

Manipulating the flow table is difficult for end users under the current limitations. AddFlow and ModFlow are available, but creating and filling the ofp_flow_mod struct that is needed is more complicated than it needs to be. Currently, AddFlow and ModFlow only expect to be called when a specific packet is received from the Controller, so to use them, ofp_flow_mod has to be filled with some fake packet information (as if it were sent from the Controller). In the future, an interface will be added to make manipulation easier. Furthermore, when Controllers can connect to the SwitchNetDevice and vice versa, the normal way of manipulating the flow table will be available as well.