wiki:2012/Projects/OpenFlowMF

Version 4 (modified by aravind, 5 years ago) (diff)

--

Project Participant: Aravind Krishnamoorthy

Project Objective:

To implement MobilityFirst's storage aware routing protocol "GSTAR" using OpenFlow?.

Motivation:

Traditionally, routing protocols are implemented as distributed algorithms running on several network devices that communicate with each other to keep the routing information converged. This has certain drawbacks such as the time it takes to recompute routes in case of link failures and the performance limitation of software implementations (such as ones using Click). However, if we can program the switching fabric to route packets based on rules that conform to the desired routing protocol, then a much higher throughput can be achieved. This is the idea behind OpenFlow?. A central controller which can see a map of the entire network, runs the routing algorithms, and installs appropriate flow rules on the switches to make them act like routers. Hence the architecture is one where a central intelligent controller defines how packets are handled by several dumb network elements, instead of the traditional method of using several intelligent network devices working in conjunction with each other. In this way, we can not only implement routing protocols on a switch, but also program the controller such that back up flows are installed immediately if links or devices in the network go down.

OpenFlow Architecture

Limitations of OpenFlow? v1.0 Standards:

The OpenFlow? version 1.0, that most hardware switches and controllers currently support, has severe limitations on the number of header fields that the switch can match on each incoming packet. Specifically, the layer 3 fields that can be matched are source and destination IP address, ToS bits and the protocol field, amounting to a total of less than 10 bytes. However, the MobilityFirst layer 3 header has fields that add up to a minimum of 48 bytes in the first packet of a chunk, and 12 bytes for the subsequent packets in a chunk. Moreover, for the layer 3 fields to be used in a flow rule at the switch, the ether type of the packet has to match the corresponding upper layer protocol; for example, for IPv4 fields such as source and destination network address to be used in a flow rule, the ether type of the packet has to be 0x0800. In order to overcome these limitations we set up flows on the switch as described below.

Flow Setup:

Results & Performance Evaluation:

Results:

Attachments (5)

Download all attachments as: .zip