Context Navigation

tut2

Timestamp:: Oct 20, 2014, 4:06:40 PM (10 years ago)
Author:: wontoniii
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

Tutorials/oMF/tut2

-              v18
+              v19
 In this exercise, we will try to drive synthetic traffic through the router and measure key performance characteristics such as throughput and forwarding latency. Since MobilityFirst presents a hop-by-hop block data transport, we can vary the unit size of the data block and observe it's impact on the performance. We will also try to visualize the performance results using OMF's result service by installing an OML-enabled monitor on the routers.
+=== Pre-requisites ===
+ * Experimenters are expected to have basic networking knowledge and familiarity with Linux OS and some of its tools (command line tools, ssh, etc.).
+ * An ORBIT user account.
+ * Some familiarity with the !MobilityFirst terminology.
 === Deploy the Network ===
 …
 [[Image(Tutorials/oMF:MFTurorialNetwork.png)]]
+[[CollapsibleStart(If not coming from the previous exercise follow these instructions to setup your network)]]
+Once logged into the grid console:
+If not coming from [wiki:Tutorials/oMF/tut1 exercise 1] follow these instructions on how to setup the topology. Running exercise 1 before moving to exercise 2 is advised to understand the steps and software components involved.
+[[CollapsibleStart(4 nodes topology setup)]]
+First of all, log in into the grid console using SSH:
 {{{
 …
 }}}
+From the console we will start by loading the Mobilityfirst image into the four nodes that have been assigned to you:
+For simplicity, open 3 different consoles on your laptop and access the grid's console with all of them; you will need them in the continuation of the exercise.
+From the console we will start loading the !Mobilityfirst image into the four nodes that have been assigned to you:
 {{{
 …
 }}}
 '''system:topo:mf-groupX''' represents the group of 4 nodes and '''mf-groupX''' has to be replaced by the group id assigned to you.
 For example, '''mf-group1''' will load the image on nodes 'node1-1,node1-2,node2-1,node2-2'
 If the output of your console looks similar to:
+''system:topo:mf-groupX'' represents the topology of 4 nodes that has been assigned to you're group and ''mf-groupX'' has to be replaced by the group id assigned to you.
+For example, ''mf-group1'' will load the image on nodes 'node20-20,node20-19,node19-19,node19-20'
+If at the end of the execution, the final output of your console looks similar to:
 {{{
 …
 === Deploy Network ===
 Software and experiment control in the ORBIT testbed can be automated greatly using the OMF framework. An OMF control script is written in Ruby and allows the experimenter to specify the set of nodes, their network configuration, to specify software components and arguments, and to control their execution on one or more nodes. We will use an OMF script to bring up 4 ORBIT nodes to host our topology, with corresponding software components.
 We will first introduce the main details of the scripts that will be run and then will step to the execution itself.
+Software and experiment control in the ORBIT testbed can be automated greatly using the OMF framework. An OMF control script is written in Ruby and allows the experimenter to specify the set of nodes, their network configuration, to specify software components and arguments, and to control their execution on one or more nodes. We will use an OMF script to bring up 4 ORBIT nodes to host our topology, with the corresponding software components.
+We will first introduce the main details of the scripts that will be run and then we will step to the execution process itself.
 ==== Software Component Specification ====
 The following snippet shows the specification of the MobilityFirst router along with the required arguments:
+The following snippet shows the specification of the !MobilityFirst components along with the required arguments. A typical application will have at least a brief description, a path for the associated binary to execute and a list of properties that correspond to the parameters  that will be passed once starting the executable.
 {{{
 #!ruby
+#Application definition of a MobilityFirst access router
 defApplication('MF-Router', 'router') {|app|
         app.shortDescription = "Click-based MobilityFirst Access Router"
 …
+}
+#Application definition of a GNRS server
 defApplication('MF-GNRS', 'gnrs') {|app|
         app.shortDescription = "GNRS Server"
 …
+}
+#Enable OML reporting by default
+#Application definition of the client network protocol stack
 defApplication('MF-HostStack', 'hoststack') {|app|
         app.shortDescription = "MF host network stack"
 …
 }}}
+As seen above, the router is configured with both 'core' and 'edge' interfaces. The core interfaces connect routers towards the core of the network, while the edge interface enables hosts to connect and access the MobilityFirst network.
+Also seen above is the GNRS service related arguments that specify which server (IP and port) the router should use for in-network name resolution purpose, both for sending requests and to receive responses. By default it will listen on all interfaces and port 10001.
+A few considerations on the defined applications:
+ * As seen above, the router is configured with both 'core' (''core_dev'') and 'edge' (''edge_dev'') interfaces. Different router configurations are available depending on the required functionality. In this case we use what we call a !MobilityFirst Access Router, which has the particularity of having the core interfaces connected towards the core of the network, while the edge interface enables hosts to connect and access the !MobilityFirst network.
+ * For this basic setup, the GNRS has been configured to be running as a single server instance, but in a larger experiment, it is designed to be a distributed system deployed at different locations.
+ * Most of the client settings are located in a configuration file pre-loaded on the ORBIT image in the folder ''/usr/local/src/mobilityfirst/eval/orbit/conf/''.
 ==== Setting up the Software Node Groups ====
 The following shows how the node groups for the routers are setup in the OMF control scripts. Node groups allows experimenters to use single statements to set configuration and execute commands across all nodes in the group.
+The following snippet shows how the node groups for the routers are setup in the OMF control scripts. Node groups allow experimenters to use single statements to set configuration (e.g. network interfaces) and execute commands across all nodes belonging to the group.
 {{{
 #!ruby
+#Create router groups
 for i in 1..num_routers
+        #Create a topology with a single router in it
         defTopology("topo:router_#{i}") { |t|
                 aNode = routersTopo.getNodeByIndex(i-1)
 …
+        }
+        #Through the group definition we set up the applications to run
         defGroup("router_#{i}", "topo:router_#{i}") {|node|
                 node.addApplication('MF-Router') {|app|
 …
+                }
           #If is the first router add the GNRS
+          #If it is the first router add the GNRS
           if i == 1
       aNode = routersTopo.getNodeByIndex(i-1)
       info aNode, " will also host the GNRS server"
                   node.addApplication('MF-GNRS') {|app|
                     app.setProperty('log4j_config_file', GNRS_log_file)
                     app.setProperty('jar_file', GNRS_jar_file)
                     app.setProperty('config_file', GNRS_conf_file)
+                  }
+                aNode = routersTopo.getNodeByIndex(i-1)
+                info aNode, " will also host the GNRS server"
+                node.addApplication('MF-GNRS') {|app|
+                      app.setProperty('log4j_config_file', GNRS_log_file)
+                      app.setProperty('jar_file', GNRS_jar_file)
+                      app.setProperty('config_file', GNRS_conf_file)
+                }
           end
+          #Setup the node interfaces
+          #The first ethernet interface is used as the core interface
           node.net.e0.ip = "192.168.100.#{i}"
           node.net.e0.netmask = '255.255.255.0'
+    node.net.w0.mode = "adhoc"
+    node.net.w0.type = 'g'
+    node.net.w0.channel = "11"
+    node.net.w0.essid = "SSID_group_#{i}"
+    node.net.w0.ip = "192.168.#{i}.1"
+          #The first wireless interface is used to give access to clients
+          node.net.w0.mode = "adhoc"
+          node.net.w0.type = 'g'
+          node.net.w0.channel = "11"
+          node.net.w0.essid = "SSID_group_#{i}"
+          node.net.w0.ip = "192.168.#{i}.1"
+        }
 end
 …
 #Create host groups
 for i in 1..num_hosts
+        #Create a topology with a single router in it
         defTopology("topo:host_#{i}") { |t|
                 aNode = hostsTopo.getNodeByIndex(i-1)
 …
+        }
+        #Through the group definition we set up the applications to run
         defGroup("host_#{i}", "topo:host_#{i}") {|node|
                 node.addApplication('MF-HostStack') {|app|
 …
                         app.setProperty('log_level', log_level)
+                }
-    #node.net.e0.ip = "192.168.#{i}.#{i+100}"
-          #node.net.e0.netmask = '255.255.255.0'
+    node.net.w0.mode = "adhoc"
+    node.net.w0.type = 'g'
+    node.net.w0.channel = "11"
+    node.net.w0.essid = "SSID_group_#{i}"
+    node.net.w0.ip = "192.168.#{i}.2"
+        }
+          #The first wifi interface is used to connect to the Access Router
+          node.net.w0.mode = "adhoc"
+          node.net.w0.type = 'g'
+          node.net.w0.channel = "11"
+          node.net.w0.essid = "SSID_group_#{i}"
+          node.net.w0.ip = "192.168.#{i}.2"
+      }
 end
 }}}
+As can be seen above, properties which were defined in the MF-Router, MF-GNRS and MF-HostStack applications have been set here. Moreover, node interfaces have been set up, and IP addresses have been assigned to them. As we discussed earlier the router is configured with both edge and core interfaces. The ethernet interface is used to connect to the core of the network, and the wireless interface is for connection to the clients. On the other side, the client is equipped with wifi interface to connect to the access router.
+As it can be seen above, once defining applications that each group will execute, the application properties are set accordingly. While we do not want to enter the details of each parameter, it is important to notice how by simple use of counters, the different nodes can be assigned different values.
+Moreover, resources such node interfaces and their corresponding IP addresses have to be set up in this phase of the experiment. As we discussed earlier the router is configured with both edge and core interfaces. An ethernet interface is used to connect to 2 core routers, while a wireless interface is used to provide access for the clients.
 [[CollapsibleEnd]]
+We will assume the network described and initialized in Exercise 1 is up and functional. Here also we will use mfping to send packets between the hosts. In addition to the deployment specified in exercise 1, we install OML-enabled statistics monitor for MobilityFirst routers.
+==== Setting up the 'OML enabled Monitor on Routers Application' ====
+At this point, the network topology described and initialized in Exercise 1 is up and functional. In order to produce synthetic traffic, we will use mfping to send packets between the hosts. In order to perform more advanced network measurements, other applications are also available, such as a modified version of the commonly used application ''iperf''. In addition to the deployment specified in exercise 1, we install OML-enabled statistics monitor for MobilityFirst routers.
 The entire script is available as part of the tutorial package as orbit/tutorial/scripts/exercise2.rb
 The key extensions over previous script are briefly discussed below.
-==== Setting up the 'OML enabled Monitor on Routers Application' ====
 The following snippet from the script shows the code added to set up the OML enabled Monitor on Routers Application and its arguments: