Difference between revisions of "GSOC2010OpenFlow"

From Nsnam
Jump to: navigation, search
(Copying from the Proposal)
 
m (Remove manual links and replace them with wiki links)
 
(86 intermediate revisions by one other user not shown)
Line 1: Line 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.
+
This project will enable ns-3 simulations to use OpenFlow switches (McKeown et al. [http://doi.acm.org/10.1145/1355734.1355746]), 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.
  
== Approach == 
+
'''The Code Review is available here [http://codereview.appspot.com/1872049/show]'''
  
Develop an OpenFlowSwitchHelper class that takes an ns3::Node and aggregates it with the yet-to-be-developed OpenFlowSwitch interface, modeling an ns-3 router Helper. Develop an OpenFlowSwitch class that extends ns3::Object, modeling an ns-3 router Object.
+
'''The OpenFlow software implementation distribution is hereby referred to as the OFSID.''' This is a demonstration of running OpenFlow in software that the OpenFlow research group has made available. There is also an OFSID that Ericsson researchers created to add MPLS capabilities; this is the OFSID currently included with the patch. The design of the patch will allow the users to, with minimal effort, switch in a different OFSID that may include more efficient code than a previous OFSID.
Draw inspiration from the OpenFlowMPLS model. There exists a software switch reference implementation for running MPLS-enabled OpenFlow, created by the OpenFlowMPLS Project (http://www.openflowswitch.org/wk/index.php/OpenFlowMPLS). This implementation, written in C code, melds an MPLS-functional OpenFlow build (openflow-mpls.tgz) with switch-running code (openflow-mpls.tgz/switch/) that runs in the user-space.
+
Copy the MPLS-functional OpenFlow build. It will be a hard copy, not a linked dependency. Due to the MPLS functionality, the switch-running code depends on internal functionality that isn't yet present on the most recent non-MPLS OpenFlow build. It is configured to be built by make presently, so it will also be reconfigured to be built by waf.
+
Translate the switch-running code into the ns-3 architecture. The software switch reference implementation has several fundamental issues that must be addressed.
+
It runs on the command line. The code that sets up the switch using the OpenFlow API is in the 'main' function of openflow-mpls.tgz/switch/switch.c. This will be copied to the StartSwitch() function in the OpenFlowSwitch class, and the parameters for the command line will become ns3::Attributes of the OpenFlowSwitch.
+
It runs on physical ethernet devices. This will be abstracted to ns3::NetDevices. By aggregating the OpenFlowSwitch with a Node, different NetDevices can be installed to simulate a PointToPoint, Wifi, et cetera receiving/sending adapters for the OpenFlowSwitch.
+
It runs without maintaining a simulation clock. The ns3 simulation clock API will be used to synchronize the OpenFlowSwitch.
+
It runs without ns-3 configurable parameters. These will be parameterized, variables will be added to the OpenFlowMPLS classes and structs, each linked to a specific ns3::Attribute.
+
It runs, as expected, with different packet structs that aren't immediately compatible with ns3::Packets. Algorithms for converting between these classes will be developed for the OpenFlowSwitch class.
+
To demonstrate this project's results are in working condition, I will endeavor to create an ns-3 simulation that demonstrates MPLS being used in a small topology. It should use code similar to:
+
Ptr<Node> switch = CreateObject<Node>();
+
...
+
OpenFlowSwitchHelper of;
+
of.SetAttribute("EnableMPLS",BooleanValue(true));
+
// set other attributes
+
of.Install(switch);
+
  
== Deliverables ==
+
'''The OFSID requires OpenSSL (for an SSL virtual connection), libxml2 (for MPLS FIB xml file parsing), libdl (for address fault checking), and boost (for assert) libraries to be installed.''' The Switch module does not use the code in the OFSID that uses OpenSSL, libxml2 and libdl. The code that uses OpenSSL is guaranteed to not be used in the Switch module, so you can delete the vconn-ssl.h{.c} from the OFSID to remove the dependency. When the project is finalized, libxml2 and libdl may no longer be required as well.
  
I have set up a Google Project (at http://code.google.com/p/ns-3-openflow/). This stub will be updated with the latest patch files, described below.
+
== Current Issues/Questions ==
  
File/Directory Details
+
These are issues/questions that have come up in my implementation. It is probable that most of these are just my programming errors. If you have an answer for any of the unresolved issues, please send me an email [mailto:naimorai@gmail.com].
src/routing/openflowswitch/openflow-switch.cc
+
class OpenFlowSwitch extends ns3::Object; It accesses and provides an ns-3 layer to the OpenFlowMPLS code to convert ns-3 packets through the receiving and forwarding process.  
+
src/helper/openflow-switch-helper.cc
+
class OpenFlowSwitchHelper; Aggregates the OpenFlowSwitch Object with a provided ns3::Node to associate it as an OpenFlow switch.
+
src/routing/openflowswitch/openflow/ Directory containing all the OpenFlowMPLS code. The files not in the /switch directory do not need to be edited for this project, so I will not include them in this list of patch files, though they will be provided in every download, because the specific switch code depends on it.
+
switch/ It holds all the specific code for the MPLS-enabled OpenFlow switch. This code needs to be reviewed line-by-line in the parameterization process.
+
chain.c, chain.h Chains tables (defined in table.h and implemented in table-hash.c and table-linear.c) together to make a trie, thereby simulating a hardware TCAM, which is the basis of OpenFlow development.
+
crc32.c, crc32.h
+
datapath.c, datapath.h
+
dp_act.c, dp_act.h
+
er_act.c, er_act.h
+
nx_act.c, nx_act.h
+
pt_act.c, pt_act.h
+
switch.c
+
switch-flow.c, switch-flow.h
+
switch-port.c, switch-port.h
+
table.h
+
table-hash.c
+
table-linear.c
+
Plan.
+
  
I will upload the latest build of the patch to the Google Project on a consistent basis. With regard to the expected time of development, I shall start by uploading it monthly. Later on in the project timeframe, probably August, I will upload more frequently to apply smaller changes.  
+
Issue 1: In the csma-switch demo, packet UID is expected to increase by 1 for every packet received, but instead it leaps up in chunks.<br>
 +
Status: Resolved. The packets weren't forwarding correctly--the packet trace showed that the packets weren't getting to their destinations, and highlighted an interesting problem where Packets had multiple EthernetHeaders. It turns out the SwitchNetDevice needed to copy the Packet before sending it out on a port, and then the Packet headers would line up. Note: The SwitchNetDevice will not run through the UIDs in exact sequential order like the BridgeNetDevice. Each flow created for a matched packet is a separate queue, and with two queues running in the csma-switch demo, UID order will be mixed as the queues run.
  
The last three days of each time estimate will be spent testing and verifying the code.
 
Time estimates based on the Approach chart:
 
  
One week to complete the OpenFlowSwitchHelper class. OpenFlowSwitchHelper's functionality is relatively simple, and will probably be similar to other routers' Helper classes.
+
Issue 2: When the csma-switch Demo is run, occasionally it fails from an assert error located in the Ipv4Header code: assert failed. file=../src/node/ipv4-header.cc, line=284, cond="(verIhl >> 4) == 4".<br>
 +
Status: Resolved. The SwitchNetDevice was sending the wrong protocol number when sending the packet over ports.
  
One to two weeks to complete the shell of the OpenFlowSwitch class. At this point, testing and verifying will be implemented. It may include adding a small store-and-forward process to the OpenFlowSwitch and making a small demo to make sure it can be used when ns-3 is built.
 
  
Two to four weeks to complete the OpenFlow integration.
+
'''Issue 3: It may be possible for the project to not be dependent on the Boost library.''' Static asserts are the only feature depended upon, so re-implementing it might be worth not having the dependency. On the other hand, the Boost library has a lot of useful features that ns-3 may use in the future, so perhaps the dependency should remain. Need the ns-3 community and ns-3 team to discuss this one.<br>
One to two weeks to integrate the OpenFlowMPLS code into the switch without yet parameterizing it. At this point testing and verifying will be on a fully capable OpenFlow switch, so a network topology demonstration will be created with analysis on the results. There probably won't be too much output in the results because of the lack of parameters.
+
Status: Unresolved.
  
One to two weeks to parameterize the OpenFlowMPLS code. The same demonstration developed for stage 2 should return more detailed results in the testing and verifying process, and should predictably change as different parameters are modified.
+
== Progress/Plan ==
  
One week to finalize the demonstration (it will already be partially constructed as of stage 2).
+
'''5/31 -- Week 1'''
 +
*Created the Switch module, initially as a copy of the Bridge module in ns-3.
 +
*Unpacked the OFSI code from the OpenFlowMPLS project [http://www.openflowswitch.org/wk/index.php/OpenFlowMPLS].
 +
*Studied OFSI code and drafted a plan to use it as a static C library, with wrapper code for each OFSI struct, combining the struct and its related functions into an OOP class.
 +
*Created waf script to build the OFSI code as a static C library.
  
Remaining time spent on testing, verifying, and polishing the code and adding documentation.
+
'''6/7 -- Week 2'''
 +
*Created the ns-3-openflow repository for checking in updates.
 +
*Discovered the wrapper plan would fail--it wouldn't be able to fix the fact that the OFSI code expected certain structs at certain levels of the code and those structs needed to be rewritten to properly integrate ns-3.
 +
*Drafted a new plan: start with the datapath.h{.c} code, translate it to C++, and integrate it into the Switch module.
 +
*Started the new plan.
  
== References ==
+
'''6/14 -- Week 3'''
 +
*Finished translating the datapath.h{.c} code and datapath-struct-dependent code into C++ in an of-datapath.h{.cc} file.
 +
*Started integrating ns-3 in the form of replacing dependencies on OFSI code where there exists an ns-3 equivalent.
  
Kohler, E., Morris, R., Chen, B., Jannotti, J., and Kaashoek, M. F. 2000. The click modular router. ACM Trans. Comput. Syst. 18, 3 (Aug. 2000), 263-297. DOI= http://doi.acm.org/10.1145/354871.354874
+
'''6/21 -- Week 4'''
 +
*Finished integrating ns-3 in the form of replacing dependencies on OFSI code.
 +
*Starting work on demo code for testing of-datapath.h{.cc} to make sure core functionality, such as flow-table manipulation and packet processing, works.
 +
*Starting work on making the Datapath class more and more like the SwitchNetDevice class in the Switch module [the code will eventually be merged because the Datapath class in of-datapath is an OpenFlow-compatible Switch itself, just with ties to hardware ethernet devices instead of ns-3 ones].
 +
*Starting to work on functions for converting OpenFlow messages (of structs such as ofpbuf) into ns-3 messages (of classes such as Packet) and vice versa.
  
Kurkowski, S., Camp, T., and Colagrosso, M. 2005. MANET simulation studies: the incredibles. SIGMOBILE Mob. Comput. Commun. Rev. 9, 4 (Oct. 2005), 50-61. DOI= http://doi.acm.org/10.1145/1096166.1096174
+
'''6/28 -- Week 5'''
 +
*Finished making the Datapath class mergeable.
 +
*Started merging the Datapath class with SwitchNetDevice.
 +
 
 +
'''7/5 -- Week 6'''
 +
*Finished merging the Datapath class with SwitchNetDevice. The of-datapath.h{.cc}, now renamed openflow-interface.h{.cc}, contains the miscellaneous OpenFlow classes the SwitchNetDevice uses.
 +
*Started working on the csma-switch demo for SwitchNetDevice, testing the conversion functions for converting ns3 Packets into OpenFlow buffers (ofpbuf) and testing the flow table.
 +
*Finished the DROP mode for the csma-switch demo.
 +
*Started work on the LEARNING mode for the csma-switch demo.
 +
*Started work on a more user-friendly interface for manipulating the SwitchNetDevice's flow table.
 +
 
 +
'''[[GSOC2010OpenFlow/MidTermReport|Midterm Report]]'''
 +
 
 +
'''7/12 -- Week 7 Milestones'''
 +
*Finished the LEARNING mode for the csma-switch demo.
 +
*Started work on the controller interface [controller is an external program that thinks for the switch; when the switch doesn't know what to do with the packet it forwards it to the controller]
 +
*Started work towards releasing a patch for review, such as making sure the code is properly styled and documented.
 +
 
 +
'''7/19 -- Week 8 Milestones'''
 +
*Finished a start for the controller interface; tap bridges wouldn't work without more analysis, so I opted to create an interface for writing controllers in ns3, subclassing from Controller. To demonstrate how to do this, I re-implemented the switch demo system through DropController and LearningController. The majority of the controller code will be similar to a real life example in that processing messages from the switch will be the same, but the sending and receiving parts will have to be replaced with real connection management, and the code itself will have to be ported to an external program (right now it is either built into the switch module or the user's demo code). The connection between the controller and switch is currently not simulated in-depth--the controller simply calls a public function in the switch it's talking to, and vice versa. In the future the controller will most likely be installed on another node to simulate the processing and communication overhead.
 +
*Finished incorporating a configurable flow table lookup overhead in the scheduler. Right now it's not immediately obvious what other overheads should be added; if anyone has any ideas let me know.
 +
*Wrote some test cases, polished, and further documented code where needed.
 +
 
 +
'''7/26 -- Week 9 Milestones'''
 +
*Started work on releasing patch for review.
 +
*Further polished code.
 +
 
 +
'''8/2 -- Week 10 Milestones'''
 +
*Released patch for review.
 +
*Developed a system for downloading and building the OFSID library separate from ns-3 and linking to it. Download the provided OFSID .tgz and extract it to wherever, naming the directory "openflow". Drop in the openflow/waf and openflow/wscript files from the patch into the "openflow" directory, run "./waf configure", then "./waf build" in the "openflow" folder. That will build the openflow library, and linking it is done with "./waf configure --with-openflow=path/to/openflow" then "./waf build" in the ns-3-dev (whatever you have named the root of the ns-3 distribution) directory.  
 +
*Conclude the project.
 +
 
 +
'''Incomplete Milestones'''<br>
 +
These are goals that may not make the final project, either due to current lack of feedback necessary to finish them, or not enough time in the scope of the project:
 +
*Adding OFSI's STP (spanning tree protocol) implementation.
 +
*Finishing MPLS integration and creating a demo/test for it showcasing the OpenFlow MPLS functionality. Note: No matter what, the OFSI's MPLS functionality limits the flow table matching to up to two MPLS labels. Labels deeper in the stack won't be matched.
 +
*Reestablishing the controller as a remote connection [installing it on another node so that different ns3 Channels/NetDevice connections can simulate the connection between the controller and the switch(es)]
 +
*Adding simulated processing overheads other than the flow table lookup overhead.
 +
 
 +
== Approach == 
 +
 
 +
#Develop a SwitchHelper class that can take an ns3::Node and install an OpenFlow-compatible SwitchNetDevice.
 +
#Develop a SwitchChannel.
 +
#Develop a SwitchNetDevice.
 +
##Draw inspiration from the OpenFlowMPLS model. There exists a software switch reference implementation for running MPLS-enabled OpenFlow, created by the OpenFlowMPLS Project [http://www.openflowswitch.org/wk/index.php/OpenFlowMPLS]. This implementation, written in C code, melds an MPLS-functional OpenFlow build (openflow-mpls.tgz) with switch-running code (openflow-mpls.tgz/switch/) that runs in the user-space.
 +
##Copy the MPLS-functional OpenFlow build. It will be a hard copy, not a linked dependency. Due to the MPLS functionality, the switch-running code depends on internal functionality that isn't yet present on the most recent non-MPLS OpenFlow build. It is configured to be built into executables by make presently, so it will be reconfigured to be built into a static library by waf.
 +
##Translate the switch-running code into the ns-3 architecture. The software switch reference implementation has several fundamental issues that must be addressed.
 +
###It's written in C that isn't compatible with C++ unless its compiled and built as a C static library. The majority of the code that doesn't need to be edited will be built as a C static library, the edited code will be translated into C++ with all of the following issues addressed.
 +
###It runs on the command line. The code that sets up switches using the OpenFlow API compiles for an executable and thus presents all of its variables at the command line. Configuration of the SwitchNetDevice will be done through ns3::Attributes.
 +
###It runs on physical ethernet devices. These will be abstracted to ns3::NetDevices, so that different NetDevices can be installed to simulate a PointToPoint, Wifi, et cetera receiving/sending adapters for the SwitchNetDevice.
 +
###It runs without maintaining a simulation clock. The ns3 simulation clock API will be used to synchronize the OpenFlowSwitch.
 +
###It runs without ns-3 configurable parameters. These will be parameterized, variables will be added to the OpenFlowMPLS classes and structs, each linked to a specific ns3::Attribute.
 +
###It runs, as expected, with different packet structs that aren't immediately compatible with ns3::Packets. Translation methods for converting between these classes will be developed for the SwitchNetDevice.
 +
# To demonstrate this project's results are in working condition, I will endeavor to create an ns-3 simulation that demonstrates MPLS being used in a small topology. It should use code similar to:
 +
::Ptr<Node> switchNode = CreateObject<Node>(); // node that will have the SwitchNetDevice installed on it.
 +
::NetDeviceContainer switchDevices; // Collection of NetDevices that will serve as the ports of the SwitchNetDevice
 +
::...
 +
::SwitchHelper of;
 +
::Ptr<MPLSController> controller = Create<MPLSController> ();
 +
::// set other attributes
 +
::of.Install(switchNode, switchDevices, controller);
 +
 
 +
== Deliverables ==
  
McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (Mar. 2008), 69-74. DOI= http://doi.acm.org/10.1145/1355734.1355746
+
I have set up a repository on the ns-3 code server [http://code.nsnam.org/bhurd/ns-3-openflow/]. This repository will receive at least one update per week.  
  
Neufeld, M., Jain, A., and Grunwald, D. 2002. Nsclick:: bridging network simulation and deployment. In Proceedings of the 5th ACM international Workshop on Modeling Analysis and Simulation of Wireless and Mobile Systems (Atlanta, Georgia, USA, September 28 - 28, 2002). MSWiM '02. ACM, New York, NY, 74-81. DOI= http://doi.acm.org/10.1145/570758.570772
+
{| border="1" cellpadding="5"
 +
|-
 +
! align="left" width="270" | File/Directory
 +
! align="left" | Details
 +
|-
 +
| wscript || Two modifications made to the main ns-3 building script, marked by #BHURD above and below: 1) In order to link the OFSID C static library, "lib.uselib_local.append('openflow');" must be called in the build method. 2) To link the OFSID library, the include path needs to be updated. This is done in the configure method.
 +
|-
 +
| src/wscript || Modification made to add the Switch module to the build process.
 +
|-
 +
| src/internet-stack/wscript || Modification made to add the ArpHeader to the build process. NOTE: This seems to have been a bug in ns-3 and the fix is now part of the ns-3-dev repository.
 +
|-
 +
| examples/switch/csma-switch.cc || Example code for a simple csma network of four nodes/computers that communicate using a switch, a node with a SwitchNetDevice installed.
 +
|-
 +
| examples/switch/wscript || Used to build the examples/switch/csma-switch example.
 +
|-
 +
| src/devices/switch/ || The Switch Module Directory, contains all the code.
 +
|-
 +
| src/devices/switch/openflow-interface.cc{.h} || Includes OFSI files from the static library and presents an OOP C++ interface. SwitchNetDevice includes this to interface OpenFlow capabilities. Controller coding examples are located here, as well.
 +
|-
 +
| src/devices/switch/switch-channel.cc{.h} || class SwitchChannel; Currently a superfluous copy of BridgeChannel, not used in the rest of the code (BridgeChannel is used currently). If it still isn't needed when the project concludes, it will be removed before the official release.
 +
|-
 +
| src/devices/switch/switch-helper.cc{.h} || class SwitchHelper; Installs the SwitchNetDevice on a provided ns3::Node to give it OpenFlow switch capability. Like the BridgeNetDevice, it takes a NetDeviceContainer that contains NetDevices to install as the switch's ports. It can optionally take a Controller to register with the switch.
 +
|-
 +
| src/devices/switch/switch-net-device.cc{.h} || The OpenFlow-compatible SwitchNetDevice. The flow table is fully implemented. When a packet is received over a port, it matches against the flow table, and, if it cannot match the packet, forwards it to the switch's registered Controller, if it has one.
 +
|-
 +
| src/devices/switch/switch-test-suite.cc || The Switch module test suite; runs unit test cases to verify the OpenFlow-compatibility of the Switch.
 +
|-
 +
| src/devices/switch/waf || Save some keystrokes to initiate a waf build from within the switch directory.
 +
|-
 +
| src/devices/switch/wscript || Waf building script for the OpenFlowSwitch module. It has two parts to it: build the OpenFlow C static library from the OFSID, and build the OpenFlowSwitch module itself. The first part adds all files from specific directories within the OFSID and compiles them into the library. The second part is similar to the building process of other modules/devices in ns-3, with create_ns3_module and ns3header for the .cc and .h files within the Switch module.
 +
|-
 +
| src/devices/switch/README || Documentation on how to set up the OFSID library, link it, and build ns-3 to activate the Switch module.
 +
|-
 +
| src/devices/switch/openflow/waf || Once a copy of the OFSID is established somewhere in an "openflow" directory, copy this file to it to establish it as a waf project.  
 +
|-
 +
| src/devices/switch/openflow/wscript || Like above, once the "openflow" directory is established, copy this file to it to describe the waf project. Run "./waf configure" then "./waf build". Afterwards, you can configure ns3 with "./waf configure --with-openflow=path/to/openflow" and "./waf build" to link the OFSID library with ns-3 and activate the Switch module.
 +
|}
  
 
== About Me ==
 
== About Me ==

Latest revision as of 16:53, 10 February 2013

This project will enable ns-3 simulations to use OpenFlow switches (McKeown et al. [1]), 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 Code Review is available here [2]

The OpenFlow software implementation distribution is hereby referred to as the OFSID. This is a demonstration of running OpenFlow in software that the OpenFlow research group has made available. There is also an OFSID that Ericsson researchers created to add MPLS capabilities; this is the OFSID currently included with the patch. The design of the patch will allow the users to, with minimal effort, switch in a different OFSID that may include more efficient code than a previous OFSID.

The OFSID requires OpenSSL (for an SSL virtual connection), libxml2 (for MPLS FIB xml file parsing), libdl (for address fault checking), and boost (for assert) libraries to be installed. The Switch module does not use the code in the OFSID that uses OpenSSL, libxml2 and libdl. The code that uses OpenSSL is guaranteed to not be used in the Switch module, so you can delete the vconn-ssl.h{.c} from the OFSID to remove the dependency. When the project is finalized, libxml2 and libdl may no longer be required as well.

Current Issues/Questions

These are issues/questions that have come up in my implementation. It is probable that most of these are just my programming errors. If you have an answer for any of the unresolved issues, please send me an email [3].

Issue 1: In the csma-switch demo, packet UID is expected to increase by 1 for every packet received, but instead it leaps up in chunks.
Status: Resolved. The packets weren't forwarding correctly--the packet trace showed that the packets weren't getting to their destinations, and highlighted an interesting problem where Packets had multiple EthernetHeaders. It turns out the SwitchNetDevice needed to copy the Packet before sending it out on a port, and then the Packet headers would line up. Note: The SwitchNetDevice will not run through the UIDs in exact sequential order like the BridgeNetDevice. Each flow created for a matched packet is a separate queue, and with two queues running in the csma-switch demo, UID order will be mixed as the queues run.


Issue 2: When the csma-switch Demo is run, occasionally it fails from an assert error located in the Ipv4Header code: assert failed. file=../src/node/ipv4-header.cc, line=284, cond="(verIhl >> 4) == 4".
Status: Resolved. The SwitchNetDevice was sending the wrong protocol number when sending the packet over ports.


Issue 3: It may be possible for the project to not be dependent on the Boost library. Static asserts are the only feature depended upon, so re-implementing it might be worth not having the dependency. On the other hand, the Boost library has a lot of useful features that ns-3 may use in the future, so perhaps the dependency should remain. Need the ns-3 community and ns-3 team to discuss this one.
Status: Unresolved.

Progress/Plan

5/31 -- Week 1

  • Created the Switch module, initially as a copy of the Bridge module in ns-3.
  • Unpacked the OFSI code from the OpenFlowMPLS project [4].
  • Studied OFSI code and drafted a plan to use it as a static C library, with wrapper code for each OFSI struct, combining the struct and its related functions into an OOP class.
  • Created waf script to build the OFSI code as a static C library.

6/7 -- Week 2

  • Created the ns-3-openflow repository for checking in updates.
  • Discovered the wrapper plan would fail--it wouldn't be able to fix the fact that the OFSI code expected certain structs at certain levels of the code and those structs needed to be rewritten to properly integrate ns-3.
  • Drafted a new plan: start with the datapath.h{.c} code, translate it to C++, and integrate it into the Switch module.
  • Started the new plan.

6/14 -- Week 3

  • Finished translating the datapath.h{.c} code and datapath-struct-dependent code into C++ in an of-datapath.h{.cc} file.
  • Started integrating ns-3 in the form of replacing dependencies on OFSI code where there exists an ns-3 equivalent.

6/21 -- Week 4

  • Finished integrating ns-3 in the form of replacing dependencies on OFSI code.
  • Starting work on demo code for testing of-datapath.h{.cc} to make sure core functionality, such as flow-table manipulation and packet processing, works.
  • Starting work on making the Datapath class more and more like the SwitchNetDevice class in the Switch module [the code will eventually be merged because the Datapath class in of-datapath is an OpenFlow-compatible Switch itself, just with ties to hardware ethernet devices instead of ns-3 ones].
  • Starting to work on functions for converting OpenFlow messages (of structs such as ofpbuf) into ns-3 messages (of classes such as Packet) and vice versa.

6/28 -- Week 5

  • Finished making the Datapath class mergeable.
  • Started merging the Datapath class with SwitchNetDevice.

7/5 -- Week 6

  • Finished merging the Datapath class with SwitchNetDevice. The of-datapath.h{.cc}, now renamed openflow-interface.h{.cc}, contains the miscellaneous OpenFlow classes the SwitchNetDevice uses.
  • Started working on the csma-switch demo for SwitchNetDevice, testing the conversion functions for converting ns3 Packets into OpenFlow buffers (ofpbuf) and testing the flow table.
  • Finished the DROP mode for the csma-switch demo.
  • Started work on the LEARNING mode for the csma-switch demo.
  • Started work on a more user-friendly interface for manipulating the SwitchNetDevice's flow table.

Midterm Report

7/12 -- Week 7 Milestones

  • Finished the LEARNING mode for the csma-switch demo.
  • Started work on the controller interface [controller is an external program that thinks for the switch; when the switch doesn't know what to do with the packet it forwards it to the controller]
  • Started work towards releasing a patch for review, such as making sure the code is properly styled and documented.

7/19 -- Week 8 Milestones

  • Finished a start for the controller interface; tap bridges wouldn't work without more analysis, so I opted to create an interface for writing controllers in ns3, subclassing from Controller. To demonstrate how to do this, I re-implemented the switch demo system through DropController and LearningController. The majority of the controller code will be similar to a real life example in that processing messages from the switch will be the same, but the sending and receiving parts will have to be replaced with real connection management, and the code itself will have to be ported to an external program (right now it is either built into the switch module or the user's demo code). The connection between the controller and switch is currently not simulated in-depth--the controller simply calls a public function in the switch it's talking to, and vice versa. In the future the controller will most likely be installed on another node to simulate the processing and communication overhead.
  • Finished incorporating a configurable flow table lookup overhead in the scheduler. Right now it's not immediately obvious what other overheads should be added; if anyone has any ideas let me know.
  • Wrote some test cases, polished, and further documented code where needed.

7/26 -- Week 9 Milestones

  • Started work on releasing patch for review.
  • Further polished code.

8/2 -- Week 10 Milestones

  • Released patch for review.
  • Developed a system for downloading and building the OFSID library separate from ns-3 and linking to it. Download the provided OFSID .tgz and extract it to wherever, naming the directory "openflow". Drop in the openflow/waf and openflow/wscript files from the patch into the "openflow" directory, run "./waf configure", then "./waf build" in the "openflow" folder. That will build the openflow library, and linking it is done with "./waf configure --with-openflow=path/to/openflow" then "./waf build" in the ns-3-dev (whatever you have named the root of the ns-3 distribution) directory.
  • Conclude the project.

Incomplete Milestones
These are goals that may not make the final project, either due to current lack of feedback necessary to finish them, or not enough time in the scope of the project:

  • Adding OFSI's STP (spanning tree protocol) implementation.
  • Finishing MPLS integration and creating a demo/test for it showcasing the OpenFlow MPLS functionality. Note: No matter what, the OFSI's MPLS functionality limits the flow table matching to up to two MPLS labels. Labels deeper in the stack won't be matched.
  • Reestablishing the controller as a remote connection [installing it on another node so that different ns3 Channels/NetDevice connections can simulate the connection between the controller and the switch(es)]
  • Adding simulated processing overheads other than the flow table lookup overhead.

Approach

  1. Develop a SwitchHelper class that can take an ns3::Node and install an OpenFlow-compatible SwitchNetDevice.
  2. Develop a SwitchChannel.
  3. Develop a SwitchNetDevice.
    1. Draw inspiration from the OpenFlowMPLS model. There exists a software switch reference implementation for running MPLS-enabled OpenFlow, created by the OpenFlowMPLS Project [5]. This implementation, written in C code, melds an MPLS-functional OpenFlow build (openflow-mpls.tgz) with switch-running code (openflow-mpls.tgz/switch/) that runs in the user-space.
    2. Copy the MPLS-functional OpenFlow build. It will be a hard copy, not a linked dependency. Due to the MPLS functionality, the switch-running code depends on internal functionality that isn't yet present on the most recent non-MPLS OpenFlow build. It is configured to be built into executables by make presently, so it will be reconfigured to be built into a static library by waf.
    3. Translate the switch-running code into the ns-3 architecture. The software switch reference implementation has several fundamental issues that must be addressed.
      1. It's written in C that isn't compatible with C++ unless its compiled and built as a C static library. The majority of the code that doesn't need to be edited will be built as a C static library, the edited code will be translated into C++ with all of the following issues addressed.
      2. It runs on the command line. The code that sets up switches using the OpenFlow API compiles for an executable and thus presents all of its variables at the command line. Configuration of the SwitchNetDevice will be done through ns3::Attributes.
      3. It runs on physical ethernet devices. These will be abstracted to ns3::NetDevices, so that different NetDevices can be installed to simulate a PointToPoint, Wifi, et cetera receiving/sending adapters for the SwitchNetDevice.
      4. It runs without maintaining a simulation clock. The ns3 simulation clock API will be used to synchronize the OpenFlowSwitch.
      5. It runs without ns-3 configurable parameters. These will be parameterized, variables will be added to the OpenFlowMPLS classes and structs, each linked to a specific ns3::Attribute.
      6. It runs, as expected, with different packet structs that aren't immediately compatible with ns3::Packets. Translation methods for converting between these classes will be developed for the SwitchNetDevice.
  4. To demonstrate this project's results are in working condition, I will endeavor to create an ns-3 simulation that demonstrates MPLS being used in a small topology. It should use code similar to:
Ptr<Node> switchNode = CreateObject<Node>(); // node that will have the SwitchNetDevice installed on it.
NetDeviceContainer switchDevices; // Collection of NetDevices that will serve as the ports of the SwitchNetDevice
...
SwitchHelper of;
Ptr<MPLSController> controller = Create<MPLSController> ();
// set other attributes
of.Install(switchNode, switchDevices, controller);

Deliverables

I have set up a repository on the ns-3 code server [6]. This repository will receive at least one update per week.

File/Directory Details
wscript Two modifications made to the main ns-3 building script, marked by #BHURD above and below: 1) In order to link the OFSID C static library, "lib.uselib_local.append('openflow');" must be called in the build method. 2) To link the OFSID library, the include path needs to be updated. This is done in the configure method.
src/wscript Modification made to add the Switch module to the build process.
src/internet-stack/wscript Modification made to add the ArpHeader to the build process. NOTE: This seems to have been a bug in ns-3 and the fix is now part of the ns-3-dev repository.
examples/switch/csma-switch.cc Example code for a simple csma network of four nodes/computers that communicate using a switch, a node with a SwitchNetDevice installed.
examples/switch/wscript Used to build the examples/switch/csma-switch example.
src/devices/switch/ The Switch Module Directory, contains all the code.
src/devices/switch/openflow-interface.cc{.h} Includes OFSI files from the static library and presents an OOP C++ interface. SwitchNetDevice includes this to interface OpenFlow capabilities. Controller coding examples are located here, as well.
src/devices/switch/switch-channel.cc{.h} class SwitchChannel; Currently a superfluous copy of BridgeChannel, not used in the rest of the code (BridgeChannel is used currently). If it still isn't needed when the project concludes, it will be removed before the official release.
src/devices/switch/switch-helper.cc{.h} class SwitchHelper; Installs the SwitchNetDevice on a provided ns3::Node to give it OpenFlow switch capability. Like the BridgeNetDevice, it takes a NetDeviceContainer that contains NetDevices to install as the switch's ports. It can optionally take a Controller to register with the switch.
src/devices/switch/switch-net-device.cc{.h} The OpenFlow-compatible SwitchNetDevice. The flow table is fully implemented. When a packet is received over a port, it matches against the flow table, and, if it cannot match the packet, forwards it to the switch's registered Controller, if it has one.
src/devices/switch/switch-test-suite.cc The Switch module test suite; runs unit test cases to verify the OpenFlow-compatibility of the Switch.
src/devices/switch/waf Save some keystrokes to initiate a waf build from within the switch directory.
src/devices/switch/wscript Waf building script for the OpenFlowSwitch module. It has two parts to it: build the OpenFlow C static library from the OFSID, and build the OpenFlowSwitch module itself. The first part adds all files from specific directories within the OFSID and compiles them into the library. The second part is similar to the building process of other modules/devices in ns-3, with create_ns3_module and ns3header for the .cc and .h files within the Switch module.
src/devices/switch/README Documentation on how to set up the OFSID library, link it, and build ns-3 to activate the Switch module.
src/devices/switch/openflow/waf Once a copy of the OFSID is established somewhere in an "openflow" directory, copy this file to it to establish it as a waf project.
src/devices/switch/openflow/wscript Like above, once the "openflow" directory is established, copy this file to it to describe the waf project. Run "./waf configure" then "./waf build". Afterwards, you can configure ns3 with "./waf configure --with-openflow=path/to/openflow" and "./waf build" to link the OFSID library with ns-3 and activate the Switch module.

About Me

I've been a programmer for the past six years, and I received my B.S. in Computer Science from West Chester University in Spring 2009. I've always been interested in research, and now as a newly accepted Temple University PhD student (starting Fall 2010), I want to pursue the Networking field within research. An ns-3 project in GSoC 2010 presents this perfect opportunity: I can enter my PhD career as someone who is already furthering academia.

I have been programming in C++ and Python for the past six years. As for ns-3 experience, I've been working with ns-3 for the past two months, since I first saw the opportunity for Networking research through GSoC by working with ns-3.

This is my first attempt at adding to an open source project.

Research

I did a Natural Language Processing (NLP) research project in my senior year at West Chester University. I programmed in Python, and experimented with using the Natural Language Toolkit (NLTK) to parse text into flash cards, an automatic SparkNotes for studying purposes.

Personal Interests

I have a variety of interests within Computer Science research. I'm interested in AI, specifically as it applies to Natural Language Processing (NLP), and how NLP could be used to automatically generate supplementary studying and testing material for students. I'm also interested in cloud computing as a method for dividing-and-conquering all sorts of research problems. But most importantly, I am interested in Networking research, which I will able to fully pursue at Temple University. Because I am focusing my research on Networking, I want to pursue a GSoC 2010 project that will teach me more about Networking and make me better known to the Networking academic community.