Changes between Version 4 and Version 5 of 2012/Projects/OpenFlowMF


Ignore:
Timestamp:
Aug 14, 2012, 9:10:00 PM (5 years ago)
Author:
aravind
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 2012/Projects/OpenFlowMF

    v4 v5  
    1616'''Flow Setup:''' 
    1717 
     18At the controller, there are no limitations on the number of header fields that can be accessed for computing the route. Hence, the trivial case is to send each packet to the controller and let the controller decide how the packet should be forwarded. However, this will not scale well, since the controller might get overwhelmed with traffic when the number of OpenFlow switches under its control increases. Moreover, when a MobilityFirst chunk is being transmitted as multiple packets, only the first packet has the routing header. Hence, there is no incentive to send all packets to the controller. Additionally, all packets corresponding a chunk have the same Hop ID. Hence, the first packet of each chunk can be sent to the controller, and once the controller computes the out bound port for that packet, a flow rule can be set up on the switch which says, 
    1819 
     20            Hop ID = x and Source MAC Address = y => Out bound Port = z 
     21 
     22However, since the switch will not understand what Hop ID is, we need to set up flows using only layer 2 header fields (the ether type of MobilityFirst packets being 0x27C0 prevents us from using any of the higher layer fields at the switch). Hence, we insert the Hop ID of each packet into the Vlan tag field of the layer 2 header. This way, the switch can look at the source MAC address, and the Vlan tag and decide which port the packet has to be forwarded through. The rule now looks like, 
     23 
     24           VLAN ID = x and Source MAC Address = y => Out bound Port = z 
     25 
     26                  [[Image(mfheader.png)]] 
    1927 
    2028== Results & Performance Evaluation: ==