== Generalized Storage-Aware Routing ==
GEC-12, Kansas City, MI, Nov 2, 2012

'''Abstract:'''

== Receiver-Controlled Multi-Homing ==
!HotMobile'12, San Diego, CA, Feb 28, 2012

'''Abstract:'''

== Robust Content Delivery to Multi-homed Mobile ==
GEC-13, Los Angeles, CA, Mar 13, 2012

'''Abstract:'''

== Openflow-controlled Routing !ByPass ==
Industrial Advisory Board Meeting (IAB), WINLAB, May 14, 2012

'''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.

{{{
            Regular Topology                           By-Pass Topology
            ================                           ================
                                 OF introduces
                 R2              bypass R1<-->R3                R2 
                / \             --------------->               / \
               /   \                                          /   \
              /     \                                        /     \      
        s -- R1      R3 -- r                           s -- R1 ---- R3 -- r


s-sender host, (R1,R2,R3) - !MobilityFirst routers, r - receiver host
}}}


'''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:
{{{
#on sb9 console, use ORBIT web service to configure switch
> wget "http://nox.orbit-lab.org:5052/network/addOpenFlow?switch=10.19.0.253&ofip=10.19.1.11&ofp=6633&dpid=0x001010162001" 
}}}
When 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:

{{{
#on OF controller node1-11

#drop pkts from 1->3
>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",
"dst-mac":"00:15:17:d6:cb:7e","active":"true"}' http://localhost:8080/wm/staticflowentrypusher/json

#drop pkts from 3->1
>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",
"dst-mac":"00:15:17:d6:da:4a","active":"true"}' http://localhost:8080/wm/staticflowentrypusher/json

}}}
 
After 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.

Now, introduce the bypass link between R1<->R3 routers by removing the link disabling flow rules introduced earlier:

{{{
#on OF controller node1-11
> curl -X DELETE -d '{"name":"bypass-block-1"}' http://localhost:8080/wm/staticflowentrypusher/json
> curl -X DELETE -d '{"name":"bypass-block-2"}' http://localhost:8080/wm/staticflowentrypusher/json
}}}

Restart 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.