Difference between revisions of "GSOC2010OpenFlow"

From Nsnam
Jump to: navigation, search
Line 24: Line 24:
 
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.  
 
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.  
  
File/Directory Details
+
'''The OpenFlow software implementation distribution is hereby referred to as the OFSID.''' This is a demonstration of running OpenFlow in software that OpenFlow makes available. There is 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.
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.
+
! File/Directory
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.
+
! Details
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.
+
| wscript || Modification made to the main ns-3 building script. In order to link the OFSID C static library, "lib.uselib_local.append('openflow');" must be called in the build method. This is marked by #BHURD above and below the one line change.
crc32.c, crc32.h
+
|-
datapath.c, datapath.h
+
| src/helper/openflow-switch-helper.cc || class OpenFlowSwitchHelper; Aggregates the OpenFlowSwitch Object with a provided ns3::Node to associate it as an OpenFlow switch.
dp_act.c, dp_act.h
+
|-
er_act.c, er_act.h
+
| src/devices/switch/ || Directory containing the rest of the code: OpenFlowSwitch NetDevice and Channel code, a distribution of the OpenFlow software implementation, and wrappers for accessing common attributes in the software implementation
nx_act.c, nx_act.h
+
|-
pt_act.c, pt_act.h
+
| src/devices/switch/openflow-wrappers.cc{.h} || The wrappers for the OFSID. The OFSID code, so far, is in C and styled in a way that cannot be quickly compiled into C++. As such, the code is compiled into a C static library and linked to the ns-3 project. The wrappers bridge this gap by including the files from the static library and interfacing them in OOP-style C++ that mirrors the ns-3 programming style.
switch.c
+
|-
switch-flow.c, switch-flow.h
+
| src/devices/switch/switch-channel.cc{.h} || The OpenFlowSwitch Channel. Currently it's just a copy of a BridgeChannel; it might stay superfluous as the project progresses in which case it will be removed before the project is officially finished.
switch-port.c, switch-port.h
+
|-
table.h
+
| src/devices/switch/switch-net-device.cc{.h} || The OpenFlowSwitch NetDevice. It utilizes the OpenFlow wrappers to maintain an OpenFlow-compatible switch. It uses the BridgeNetDevice system of maintaining a list of pointers to basic NetDevices as its ports.
table-hash.c
+
|-
table-linear.c
+
| 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 makes assumptions on specifically named files within the OFSID that are compiled 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 three .cc and .h files within the OpenFlowSwitch module.
 +
|-
 +
| src/devices/switch/openflow || A copy of an OFSID. This one has the MPLS extension built in, a distribution that Ericsson researchers developed to propose an OpenFlow standard that includes MPLS capability. There are many files within, and documenting them would take a long time. The grand majority aren't even used, the current abstraction uses wscript to build the necessary files into a C static library, and the openflow-wrappers file contains wrappers for the library. Consider this a black box of OpenFlow functionality.
 +
|}
  
 
== Plan ==
 
== Plan ==

Revision as of 18:42, 14 May 2010

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.

Approach

  1. Develop an OpenFlowSwitchHelper class that can take an ns3::Node and install an OpenFlowSwitch NetDevice. Develop an OpenFlowSwitch NetDevice and Channel.
    1. 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.
    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 by make presently, so it will also be reconfigured to be built 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 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.
      2. 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.
      3. It runs without maintaining a simulation clock. The ns3 simulation clock API will be used to synchronize the OpenFlowSwitch.
      4. 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.
      5. It runs, as expected, with different packet structs that aren't immediately compatible with ns3::Packets. Wrappers for converting between these classes will be developed for the OpenFlowSwitch class.
  2. 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

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.

The OpenFlow software implementation distribution is hereby referred to as the OFSID. This is a demonstration of running OpenFlow in software that OpenFlow makes available. There is 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.

File/Directory Details
wscript Modification made to the main ns-3 building script. In order to link the OFSID C static library, "lib.uselib_local.append('openflow');" must be called in the build method. This is marked by #BHURD above and below the one line change.
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/devices/switch/ Directory containing the rest of the code: OpenFlowSwitch NetDevice and Channel code, a distribution of the OpenFlow software implementation, and wrappers for accessing common attributes in the software implementation
src/devices/switch/openflow-wrappers.cc{.h} The wrappers for the OFSID. The OFSID code, so far, is in C and styled in a way that cannot be quickly compiled into C++. As such, the code is compiled into a C static library and linked to the ns-3 project. The wrappers bridge this gap by including the files from the static library and interfacing them in OOP-style C++ that mirrors the ns-3 programming style.
src/devices/switch/switch-channel.cc{.h} The OpenFlowSwitch Channel. Currently it's just a copy of a BridgeChannel; it might stay superfluous as the project progresses in which case it will be removed before the project is officially finished.
src/devices/switch/switch-net-device.cc{.h} The OpenFlowSwitch NetDevice. It utilizes the OpenFlow wrappers to maintain an OpenFlow-compatible switch. It uses the BridgeNetDevice system of maintaining a list of pointers to basic NetDevices as its ports.
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 makes assumptions on specifically named files within the OFSID that are compiled 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 three .cc and .h files within the OpenFlowSwitch module.
src/devices/switch/openflow A copy of an OFSID. This one has the MPLS extension built in, a distribution that Ericsson researchers developed to propose an OpenFlow standard that includes MPLS capability. There are many files within, and documenting them would take a long time. The grand majority aren't even used, the current abstraction uses wscript to build the necessary files into a C static library, and the openflow-wrappers file contains wrappers for the library. Consider this a black box of OpenFlow functionality.

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.

The last three days of each time estimate will be spent testing and verifying the code. Time estimates based on the Approach chart:

  1. One week to complete the OpenFlowSwitchHelper class. OpenFlowSwitchHelper's functionality is relatively simple, and will probably be similar to other routers' Helper classes.
  2. 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.
  3. Two to four weeks to complete the OpenFlow integration.
    1. 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.
    2. 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.
  4. One week to finalize the demonstration (it will already be partially constructed as of stage 2).
  5. Remaining time spent on testing, verifying, and polishing the code and adding documentation.

References

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

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

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

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

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.