Changes between Version 4 and Version 5 of AAG/aag_2nd_year_report
- Timestamp:
- 08/06/15 15:19:10 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AAG/aag_2nd_year_report
v4 v5 19 19 * Develop an approach for plugging a user-specified controller module into the AAG controller for controlling traffic flowing within an SDN-controlled slice. 20 20 21 * Demonstrate the implemented functions at GEC21, GEC22 and GEC23. Prepare and present the A odopt-A-GENI tutorial at the summer camp 2015 held at University of Connecticut.21 * Demonstrate the implemented functions at GEC21, GEC22 and GEC23. Prepare and present the Adopt-A-GENI tutorial at the summer camp 2015 held at University of Connecticut. 22 22 23 23 === B. Deliverables made === … … 33 33 == II. Description of work performed during the reporting period == 34 34 35 The following provides a description of the progress made during the lastreporting period.35 The following provides a description of the progress made during the reporting period. 36 36 37 37 === A. Activities and findings === … … 39 39 Our activities and findings can be described in the following five aspects. 40 40 41 ==== 1. developing a module for integrating the AAG path selection function into the GENI Desktop. ====41 ==== 1. Developing a module for integrating the AAG path selection function into the GENI Desktop. ==== 42 42 43 43 The GENI Desktop was designed to be extensible in the sense that new 44 44 modules can be written to include new functionalities. We took advantage 45 of this property of the GENI Desktop and wr ite a module for the AAG function.45 of this property of the GENI Desktop and wrote modules for the AAG functions. 46 46 While creating a module is straightforward, the major task is to modify 47 47 the exiting AAG code to handle the interactions between the GENI Desktop … … 60 60 a graphical user interface (GUI) showing the topology of the slice. 61 61 Instead of providing a list of desired nodes, the user can pick the nodes 62 via the GUI of the GENI Desktop. There is amechanism in the GENI Desktop63 to pass this information from GUI to an associated module. The AAG module64 processes th isinformation and installs the flows to the switches.62 via the GUI of the GENI Desktop. We used the mechanism in the GENI Desktop 63 to pass this information from GUI to the AAG module, which 64 processes the information and installs the flows to the switches. 65 65 66 [[Image(gec21_aag_demo.png, 600)]] 66 [[Image(pathselected.png, 600)]] 67 68 The above figure shows the AAG module developed. It provides three functions: 69 70 * 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. 71 72 * 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. 73 74 * 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. 67 75 68 76 ==== 2. Integrating Jacks with the GENI Desktop for allocating SDN resource. ==== … … 72 80 Jacks with the GENI Desktop. We customized Jacks to create special icons, 73 81 including the AAG controller node and the AAG OVS node. Users can drag 74 the AAG controller into the experiment. The AAG OVS node includes the AAG 82 the AAG controller into the experiment. It is a custom image we created that 83 includes OpenDaylight code and runs OpenDaylight controller once the node is up. 84 The AAG OVS node contains a custom OVS image we created that includes the AAG 75 85 initialization script and related code. It can initialize and configure 76 the OVS node and point the OVS node to the AAG controller. 86 the OVS node and point the OVS node to the AAG controller so that the controller 87 can issue OpenFlow commands to OVS nodes and control the behavior of the switches. 77 88 78 89 Currently we are developing code to automate the initialization step. … … 86 97 a flow is correctly installed and monitor 87 98 the traffic that is part of the flow. 99 The user can pick a flow to monitor and determine at which node to collect the 100 traffic information about the flow. 101 88 102 We can get the statistics about the number of packets (bytes) 89 103 matching a flow entry from the controller. However, they … … 104 118 behavior of the flow. 105 119 106 The following figure shows an example output where 120 [[Image(15mins.png, 600)]] 121 122 The figure shows an example output where 107 123 peaks can be easily identified by the experimenter. 108 109 [[Image(15mins.png, 600)]] 124 The module allows the experimenter to decide the time interval covering the displayed data. 125 The user can either zoom in or 126 zoom out the chart for a more detailed or more general visualization of the flow performance. 110 127 111 128 ==== 4. Developing an approach for plugging a user-specified controller module. ==== … … 116 133 controller to install the user-specified module as a bundle. 117 134 118 As the first step, the user needs to use tools like maven for compilation 119 and dependencies, java as programming language and (optionally) eclipse to 120 ease syntax completion. Once the module is written and successfully compiled, 135 As the first step, the user needs to write the module in Java and 136 use tools like maven for compilation and dependencies. 137 Several environments, such as eclipse, can be used for easy syntax completion. 138 Once the module is written and successfully compiled, 121 139 a .jar file representing the bundle will be created. 122 140 The final step is to use Web GUI or OSGi console to install the bundle and start … … 125 143 We developed a sample module for port forwarding and demonstrated the approach. 126 144 The module checks if the destination port is within the (user-defined) range 5000-6000. 127 If so, flow entries are installed that forward such traffic to port 5050 and handle packets sent back to the client. Otherwise, a "DROP" rule is installed preventing further connections to the target destination port. 145 If so, flow entries are installed that forward such traffic to port 5050. 146 Otherwise, a "DROP" rule is installed preventing further connections to the target destination port. 147 The module also needs to handle packets sent back to the client. 148 We plugged this module into the AAG controller and demonstrated the function 149 at GEC 23. 128 150 129 151 ==== 5. Demos and Tutorial ==== 130 152 131 We demonstrated the AAG path selection func iton at GEC 21, the monitoring153 We demonstrated the AAG path selection function at GEC 21, the monitoring 132 154 of flow traffic at GEC 22, and user-specified sub-controller at GEC 23. 133 155 We also give a tutorial of the Adopt-A-GENI project at the 2015 summer 134 camp held inthe University of Connecticut.156 camp held at the University of Connecticut. 135 157 136 158 === B. Project participants ===