Changes between Initial Version and Version 1 of AAG/aag_final_report

Timestamp:

01/18/17 16:22:24 (7 years ago)

Author:

fei@netlab.uky.edu

Comment:

--

AAG/aag_final_report

@@ +1 @@
+[[PageOutline]]
+
+= Adopt-a-GENI Project Final Report = 
+
+
+== I. Major accomplishments ==
+
+The following highlights our accomplishments for the project. 
+
+=== A. Milestones achieved ===
+
+We achieved all the milestones defined for the project. 
+
+ * Develop the Adopt-A-GENI AAG Controller to manage and install user-defined SDN-controlled paths. 
+
+ * Integrate the AAG path selection function with the GENI Desktop.
+
+ * Incorporate SDN resource allocation functions with Jacks, including whatever compute resources are available through Jacks.
+
+ * Develop monitoring capability to verify correct connectivity and functioning of user-defined SDN-controlled path.
+
+ * Develop an approach for plugging a user-specified controller module into the AAG controller for controlling traffic flowing within an SDN-controlled slice. 
+
+ * Demonstrate the implemented functions at GEC19, GEC20, GEC21, GEC22 and GEC23. Prepare and present the Adopt-A-GENI tutorial at the summer camp 2015 held at the University of Connecticut. 
+
+=== B. Deliverables made ===
+
+ * We developed the AAG Controller to install user-defined SDN-controlled paths. 
+
+ * We developed a module in the GENI Desktop for integrating the AAG path selection function into the GENI Desktop.
+
+ * We integrated Jacks with the GENI Desktop so that users can allocate OVS nodes, together with other compute resources through the GENI Desktop. 
+
+ * We developed a flow monitoring module in the GENI Desktop that can monitor the user-defined path to verify its correctness. 
+
+ * We developed a sample module for port forwarding and demonstrated the approach of plugging the module into the AAG controller.
+
+== II. Description of work performed during the reporting period ==
+
+The following provides a description of the progress made during the reporting period.
+
+=== A. Activities and findings ===
+
+Our activities and findings can be described in the following aspects.
+
+==== 1. Developing the Adopt-A-GENI AAG Controller to manage and install user-defined SDN-controlled paths. ====
+
+We developed the AAG Controller based on the  OpenDaylight controller. The main function of the AAG controller is to manage user-selected paths. As the first step, we implemented the fucntion of setting the default paths in the OVS nodes in the GENI experiments. First, we developed Java code that will initialize the OVS nodes for users. It will configure all interfaces and specify the AAG controller on their behalf. After that the OVS nodes will be able to communicate with the AAG controller in regards to processing of incoming packets. Then, the AAG controller will set up the default paths in all OVS nodes in the slice. The default paths are set based on the shortest path between any pair of source and destination nodes. 
+
+After that, we developed the code for the AAG Controller to install user-defined paths in SDN networks. The user in SDN networks may prefer a different path for various reasons, such as traffic engineering, special treatment of certain flows, or bypassing a firewall. The user can simply specify the names of the nodes in the path from the source node to the destination node. All the details are then figured out by the AAG controller to install the appropriate rules on the OVS nodes along the path. The AAG controller first checks the legitimacy of the path itself. It needs to make sure that the path contains no loop and is from one end host (non-OVS node) to another end host (non-OVS node). It also checks that any two consecutive nodes specified in the parameter actually comprise an edge in the topology of the experiment.
+
+To create the flow rules that need to be installed, the AAG controller uses the Manifest RSpec to get the specific MAC addresses and corresponding output ports at each OVS node needed to form the user-defined path. Once the flows are formed, they are installed at the OVS nodes using the REST interface of the OpenDaylight controller. 
+
+==== 2. Developing a module for integrating the AAG path selection function into the GENI Desktop. ==== 
+
+The GENI Desktop was designed to be extensible in the sense that new 
+modules can be written to include new functionalities. We took advantage 
+of this property of the GENI Desktop and wrote modules for the AAG functions. 
+While creating a module is straightforward, the major task is to modify 
+the exiting AAG code to handle the interactions between the GENI Desktop 
+and the AAG module. There are two aspects.
+
+One aspect is how to get the information about a slice. In order to 
+verify and set up the user-selected path, the AAG module needs information 
+about the slice, such as the topology, IP addresses, MAC addresses, etc. 
+The original AAG code obtained this information from the manifest, which 
+was provided as a textual file in XML format. As a part of the GENI Desktop, 
+the AAG module gets the slice information from the parser of the GENI Desktop. 
+The parser obtains the slice information from aggregates and provides the 
+manifest as a JSON object. The AAG code was modified to accommodate this change. 
+
+The other aspect is how the user selects the path. The GENI Desktop provides 
+a graphical user interface (GUI) showing the topology of the slice. 
+Instead of providing a list of desired nodes, the user can pick the nodes 
+via the GUI of the GENI Desktop. We used the mechanism in the GENI Desktop 
+to pass this information from GUI to the AAG module, which 
+processes the information and installs the flows to the switches. 
+
+[[Image(pathselected.png, 400)]]
+
+The above figure shows the AAG module developed. It provides three functions:
+
+ * Install a flow: A user can request a flow to be installed along its associated path so that all the packets belonging to the flow will be forwarded along that path. The user can specify the source and destination addresses, port numbers and the protocol for the flow. The flow can be installed in one direction or both directions of the path. The OpenFlow rules will be installed on all OpenFlow-enabled switches in the path(s) by the AAG module.
+
+ * List flows: A user can request all the flows to be listed. A flow can be installed in different ways, either through the the AAG module or directly installed via the OpenFlow controller.
+
+ * Delete a flow: A user can request that a flow be deleted. This requires that all the rules on the switches on the associated path of the flow be removed.
+
+==== 3. Integrating Jacks with the GENI Desktop for allocating SDN resource. ====
+
+Jacks provided the function to allocate both OVS nodes and other compute
+resources. As a joint effort with the GENI Desktop project, we integrated
+Jacks with the GENI Desktop. We customized Jacks to create special icons, 
+including the AAG controller node and the AAG OVS node. Users can drag 
+the AAG controller into the experiment. It is a custom image we created that 
+includes OpenDaylight code and runs the OpenDaylight controller once the node is up.  
+The AAG OVS node contains a custom OVS image we created that includes the AAG
+initialization script and related code. It can initialize and configure
+the OVS node and point the OVS node to the AAG controller so that the controller
+can issue OpenFlow commands to OVS nodes and control the behavior of the switches. 
+
+Currently we are developing code to automate the initialization step. 
+The AAG controller can be added automatically to the user experiment and
+the script on the OVS nodes will be run by the GENI desktop to specify 
+the information about the AAG controller. 
+
+==== 4. Developing monitoring capability for SDN-controlled paths. ====
+
+We designed a Flow Monitoring Module (FMM) in the GENI Desktop to verify that
+a flow is correctly installed and to monitor
+the traffic that is part of the flow. 
+The user can pick a flow to monitor and determine at which node to collect the 
+traffic information about the flow. 
+
+We can get the statistics about the number of packets (bytes)
+matching a flow entry from the controller. However, they
+are the cumulative counts since the flow entry was installed.
+Therefore, it does not show the changes or trends of the flow of interest.
+It is hard and time-consuming for an
+experimenter to figure out the changes manually. 
+
+The FMM
+provides a live monitoring functionality by periodically querying
+the controller to get these statistics over a period of time.
+Luckily, the controller does not restrict the frequency with
+which we can query statistics from it. The FMM transforms the
+collected data into a dynamic time series plot that depicts the
+flow’s performance over time since the data collection began.
+The plot is updated in real time as more data are collected from
+the controller. Therefore, it provides live monitoring of the
+behavior of the flow. 
+
+[[Image(15mins.png, 600)]]
+
+The figure shows an example output where
+peaks can be easily identified by the experimenter.
+The module allows the experimenter to decide the time interval covering the displayed data.
+The user can either zoom in or
+zoom out the chart for a more detailed or more general visualization of the flow performance.
+
+==== 5. Developing an approach for plugging a user-specified controller module. ====
+
+The AAG controller is based on the OpenDaylight controller. To plug the user-specified
+controller module to the AAG controller for controlling traffic flowing with a 
+AAG-controlled user slice, we can use the Web GUI or the OSGi console of the OpenDaylight 
+controller to install the user-specified module as a bundle. 
+
+As the first step, the user needs to write the module in Java and 
+use tools like maven for compilation and dependencies.
+Several environments, such as eclipse, can be used for easy syntax completion. 
+Once the module is written and successfully compiled, 
+a .jar file representing the bundle is created. 
+The final step is to use the Web GUI or the OSGi console to install the bundle and start
+it. 
+
+We develop a sample module for port forwarding to demonstrate the approach. 
+The module checks if the destination port is within the (user-defined) range 5000-6000. 
+If so, flow entries are installed that forward such traffic to port 5050.
+Otherwise, a "DROP" rule is installed preventing further connections to the target destination port.
+The module also needs to handle packets sent back to the client. 
+We plugged this module into the AAG controller and demonstrated the function
+at GEC 23. 
+
+
+==== 6. Extending the AAG controller to handle a variety of SDN controllers, including Floodlight, RYU, and HP-VAN. ====
+
+The original AAG controller was designed for the OpenDaylight (ODL)
+controller, which meant that experimenters who wanted to use the AAG system
+were required to use the ODL controller.  To address this limitation, we
+developed a REST API translator (RAPTOR) that allows users to develop their
+network control software independent of any particular SDN controller. RAPTOR
+exposes a REST-based API to a controller-agnostic (i.e., generic) set of SDN
+controller functions and data models.  RAPTOR translates the generic SDN
+controller API calls into controller-specific (e.g., ODL, Floodlight, RYU, or
+HP-VAN) API calls to the real controller's northbound interface.
+
+
+==== 7. Developing a flow-entry installation module based on RAPTOR. It allows a user to install the same OpenFlow rule on multiple switches. ====
+
+In addition to the original set of AAG modules to install a path, list paths,
+or delete a path, we developed a new module that leveraged Raptor to install
+specific flow-entries.  When traffic needs to be handled in the same way at
+every switch -- for instance, sending all ARP traffic to the controller or
+dropping  all HTTP connections -- experimenters can now use our new
+flow-entry installation module to install the rule on multiple switches. The
+module was tested using RAPTOR-supported SDN controllers, including
+Floodlight, RYU and HP-VAN.  
+
+
+
+=== B. Project participants ===
+
+The following individuals are involved with the project in one way or another:
+ * Zongming Fei - Project PI (Kentucky)
+ * Jim Griffioen - Project Co-PI (Kentucky)
+ * Kobus van der Merwe - Project Co-PI (Utah)
+ * Rob Ricci - Project Co-PI (Utah)
+ * Hussamuddin Nasir - Technician/Programmer (Kentucky)
+ * Charles Carpenter - Technician/Programmer (Kentucky)
+ * Jonathon Duerig - Research Associate (Utah)
+ * Sergio Rivera Polanco - Ph.D. Student (Kentucky)
+ * Navjeet Sandhu - M.S. Student (Kentucky)
+ * Amrita Jyotiprada - M.S. Student (Kentucky) 
+
+=== C. Publications (individual and organizational) ===
+
+ * Sergio Rivera P., Zongming Fei, and James Griffioen, "Providing a High Level Abstraction for SDN Networks in GENI," in Proc. of the 2nd International Workshop on Computer and Networking Experimental Research Using Testbeds (CNERT 2015), Columbus, OH, June 29, 2015. 
+
+ * Sergio Rivera P., Zongming Fei, James Griffioen, "RAPTOR: A REST API TranslaTOR for OpenFlow Controllers," Proceedings of the International Workshop on Computer and Network Experimental Research Using Testbeds (CNERT 2016), in Conjunction with IEEE INFOCOM, San Francisco, CA, April 10-15, 2016.
+
+=== D. Outreach activities ===
+
+ * We gave demos at GEC 19, GEC 20, GEC 21, GEC 22, and GEC 23. We also gave a tutorial at the GENI summer camp. 
+
+=== E. Collaborations ===
+
+ * Most of our collaborations have been between the Kentucky team and the Utah team. We continued our discussion on what functions need to be provided in Jacks for the AAG project and how to better integrate Jacks with the GENI Desktop. 
+
+=== F. Other Contributions ===