What is an OpenFlow switch?

Don Kline

CS 641: Computer Architecture

1. What is OpenFlow?

2. Why use OpenFlow?

3. Current Hardware

4. Applications

1. What is OpenFlow?

Definition of a flow:

· Rule: The rule is the exact, or wildcard definition used to match a packet based on its ip-address, VLAN, or other network metric.

· Action: What to do with the packet e.g., send the packet to port 3 if it matches the rule.

· Statistics: Count packets & bytes, Expiration time/count.

Definition of the flow table:

The flow table is simply the list of all known flows typically stored on the switches hardware for fast packet processing. Packets that a switch receives that match one of its rules, get the specified action performed on them, and there statistics refreshed. Packets that don’t match any flow get dropped.

Definition of OpenFlow:

“The basic idea is simple: we exploit the fact that most modern Ethernet switches and routers contain ﬂow-tables (typically built from TCAMs) that run at line-rate to implement ﬁrewalls, NAT, QoS, and to collect statistics. While each vendor’s ﬂow-table is different, we’ve identiﬁed an interesting common set of functions that run in many switches and routers. OpenFlow exploits this common set of functions.

OpenFlow provides an open protocol to program the ﬂowtable in different switches and routers. A network administrator can partition traffic into production and research ﬂows. Researchers can control their own ﬂows - by choosing the routes their packets follow and the processing they receive. In this way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP. On the same network, the production traffic is isolated and processed in the same way as today.”[1]

In other words, current switching/routing technology uses hardware to determine and remember where network packets are directed if they have the same header information. OpenFlow uses this same technology, however instead of leaving everything up to the hardware configuration; there is programmable software that is used to determine how to direct unrecognized packets. Typically, and hopefully, only a small percentage of packets received will have to be sent to software, which is also referred to as the slowpath.

Fig 1: High-level view of how an OpenFlow switch works[1].

Going out to software enables more complex, and more customized routing applications to be done. Specifically, routing protocols can be different for each VLAN as one example which is one of the primary reasons OpenFlow was originally developed, which is explained more in the next section.

2. Why use OpenFlow?

“Networks have become part of the critical infrastructure of our businesses, homes and schools. This success has been both a blessing and a curse for networking researchers; their work is more relevant, but their chance of making an impact is more remote. The reduction in real-world impact of any given network innovation is because the enormous installed base of equipment and protocols, and the reluctance to experiment with production traffic, which have created an exceedingly high barrier to entry for new ideas. Today, there is almost no practical way to experiment with new network protocols (e.g., new routing protocols, or alternatives to IP) in suciently realistic settings (e.g., at scale carrying real traffic) to gain the conﬁdence needed for their widespread deployment. The result is that most new ideas from the networking research community go untried and untested; hence the commonly held belief that the network infrastructure has ‘ossiﬁed’”[1].

In an effort to bring innovation back to the networking research community, OpenFlow allows for the flow tables of the switch to be virtualized in hardware. As Figure 2 demonstrates traffic from different VLANs can use a completely different OpenFlow program in order to generate flows. This enables production traffic to run normally, while also allowing researchers to use their own custom routing protocols that may not even be IP based.

Fig 2: Virtualizing the flow table of an OpenFlow switch[2].

3: Current Hardware

Figure 3 shows a high-level design of a typical OpenFlow switch. It shows that data comes into the switch ports, and potentially gets redirected straight to a port for output based on the HW Packet Processing Tables. Alternatively, the packet will be directed to the port manager, and the OpenFlow Datapath is there is no entry in the HW tables. Depending on the switch, and the OpenFlow configurations, the OpenFlow datapath will either use the SW Flow Table to place a new entry in the HW Tables, or it will send the packet information to the OpenFlow Controller which will determine what to do with the packet. In either case, The HW Table Manager is used to record statistics, and any new flows that are generated by the OpenFlow Datapath/Controller.

Fig 3: ‘High Level OpenFlow Switch Software Architecture’[3]

The exact hardware in commercial OpenFlow switches is not heavely published, howerever some of the OpenFlow switches available, as of Oct, 2008 are:

· Cisco Catalyst 6509

· Juniper MX-480

· NEC IP8800

· HP ProCurve 5400-series

A cheaper, less feature rich alternative to buying OpenFlow capable switches is to buy a NetFPGA card, which is also capable of running the OpenFlow API with hardware acceleration, however with fewer network ports. These cards cost from $500 to $1200 for the 4x gigabit port model. Specifications of this NetFPGA card can be found at:

http://www.netfpga.org/php/specs.php

Fig 4: NetFPGA card, along with high level architecture, which is similar to Figure 3[4].

4: Applications

a. OpenFlow applications:

a. Changing networks, without packet loss.

b. Changing networks while uploading, file/video.

c. Giving applications primitive network information e.g., an application can query the network to determine the congestion of part of the network, or request its own quality of service.[5]

b. NetFPGA applications:

a. Run the OpenFlow api

b. http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/ProjectTable

Multipath routing
Reducing packet loss
Maintaining packet separation

References:

1: http://www.openflowswitch.org//documents/openflow-wp-latest.pdf

2: http://groups.geni.net/geni/attachment/wiki/presentations/GEC3%20Demo%20Oct2008%20v1-4.pdf?format=raw

3: www.openflowswitch.org/wk/images/c/c2/Of-hw-api-draft-0.4.pdf

4: http://www.digilentinc.com/Products/Detail.cfm?Prod=NETFPGA&Nav1= Products&Nav2=Programmable

5: http://www.openflowswitch.org/wk/index.php/SFNet