close Warning: Can't synchronize with repository "(default)" ("(default)" is not readable or not a Git repository.). Look in the Trac log for more information.

Changes between Initial Version and Version 1 of Internal/SystemPrototyping/Software/Demonstrations


Ignore:
Timestamp:
May 17, 2012, 11:09:44 PM (12 years ago)
Author:
nkiran
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Internal/SystemPrototyping/Software/Demonstrations

    v1 v1  
     1
     2== Generalized Storage-Aware Routing ==
     3GEC-12, Kansas City, MI, Nov 2, 2012
     4
     5'''Abstract:'''
     6
     7== Receiver-Controlled Multi-Homing ==
     8!HotMobile'12, San Diego, CA, Feb 28, 2012
     9
     10'''Abstract:'''
     11
     12== Robust Content Delivery to Multi-homed Mobile ==
     13GEC-13, Los Angeles, CA, Mar 13, 2012
     14
     15'''Abstract:'''
     16
     17== Openflow-controlled Routing !ByPass ==
     18Industrial Advisory Board Meeting (IAB), WINLAB, May 14, 2012
     19
     20'''Abstract:''' Data transfer in !MobilityFirst uses a reliable hop-by-hop transport, that progresses data packets towards the destination. When appropriate, however, the packets may simply be switched by 'bypassing' intermediate routing elements. By combining a configurable switching fabric that can be triggered by a variety of events (routing overload, path congestion, real-time requirement, etc.), a fast path can be set up for !MobilityFirst packets. In this demonstration we show how a Openflow controlled switching fabric is used to set up a fast path between sender and receiver nodes, bypassing the intermediate router shown in topology below. While the bypass can be executed transparent to the MF routers, here we allow sender MF router to reconfigure it's forwarding rule to use the bypass path.
     21
     22{{{
     23            Regular Topology                           By-Pass Topology
     24            ================                           ================
     25                                 OF introduces
     26                 R2              bypass R1<-->R3                R2
     27                / \             --------------->               / \
     28               /   \                                          /   \
     29              /     \                                        /     \     
     30        s -- R1      R3 -- r                           s -- R1 ---- R3 -- r
     31
     32
     33s-sender host, (R1,R2,R3) - !MobilityFirst routers, r - receiver host
     34}}}
     35
     36
     37'''Demo Instructions:''' This experiment can be run on SB9 sandbox ORBIT testbed. 3 nodes run !MobilityFirst routers, with one also being a file sender, and another being a file receiver. Another node is required to run the Openflow controller. Refer to the [http://www.orbit-lab.org/wiki/Documentation/OpenFlow SB9 Openflow setup page]. Nodes node1-1, node1-3, node1-4 were used as MF routers(note that we combine sender s into R1, and receiver r into R3 for simplicity) and node1-11 as the OF controller. The following images were used for MF router and OF controller nodes, respectively: 'MF-router-IAB-May2012.ndz', 'OF-controller-IAB-May2012.ndz'. The router image contains the MF 1.0 rc-1, and the OF controller contains [http://Floodlight.openflowhub.org FloodLight] controller (installed at /usr/share/floodlight) by default configured to run as a learning switch. Once imaged, configure the sb9 data switch to OF mode and point it to running controller on node1-11:
     38{{{
     39#on sb9 console, use ORBIT web service to configure switch
     40> wget "http://nox.orbit-lab.org:5052/network/addOpenFlow?switch=10.19.0.253&ofip=10.19.1.11&ofp=6633&dpid=0x001010162001"
     41}}}
     42When the OF controller is up, use the REST API to introduce a static flow rule to disable link R1<->R3 in above shown topology (Note: since all nodes in sb9 are connected to   switch, by default they can reach each other. We disable link to introduced original topology). The flow rule simply drops all packets on that link:
     43
     44{{{
     45#on OF controller node1-11
     46
     47#drop pkts from 1->3
     48>curl -d '{"switch": "00:00:00:23:20:5e:da:65", "name":"bypass-block-1", "cookie":"0", "priority":"32768", "src-mac":"00:15:17:d6:da:4a",
     49"dst-mac":"00:15:17:d6:cb:7e","active":"true"}' http://localhost:8080/wm/staticflowentrypusher/json
     50
     51#drop pkts from 3->1
     52>curl -d '{"switch": "00:00:00:23:20:5e:da:65", "name":"bypass-block-2", "cookie":"0", "priority":"32768", "src-mac":"00:15:17:d6:cb:7e",
     53"dst-mac":"00:15:17:d6:da:4a","active":"true"}' http://localhost:8080/wm/staticflowentrypusher/json
     54
     55}}}
     56 
     57After starting the sender, router, and receiver (using topology file: [https://mobilityfirst.orbit-lab.org/browser/trunk/code/prototype/eval/topology/OFdemo-IAB-may2012.tp OFdemo-IAB-may2012.tp]), you will notice that file transfer proceeds along R1->R2, R2->R3. This can be observed using tcpdump, MF router logs, etc. The OF controller image also has a OMLized monitor that periodically retrieves flow statistics from the !FloodLight controller and pushes to configured OML server - another way to observe the experiment.
     58
     59Now, introduce the bypass link between R1<->R3 routers by removing the link disabling flow rules introduced earlier:
     60
     61{{{
     62#on OF controller node1-11
     63> curl -X DELETE -d '{"name":"bypass-block-1"}' http://localhost:8080/wm/staticflowentrypusher/json
     64> curl -X DELETE -d '{"name":"bypass-block-2"}' http://localhost:8080/wm/staticflowentrypusher/json
     65}}}
     66
     67Restart the sender. You should see that MF GSTAR routing will discover the enabled link and determine it to be the shorter path to the destination node, and will proceed to transfer the data along bypass link 1->3.