Openflow: Enabling Innovation in Campus Networks Filip Stankovski Jacobs University Bremen f.stankovski@jacobs-university.de April 30, 2014 Filip Stankovski (JUB) OpenFlow April 30, 2014 1 / 16
Table of Contents Filip Stankovski (JUB) OpenFlow April 30, 2014 2 / 16
Why do we need programmable networks? The Internet is huge = reluctance to experiment = very high barrier for new ideas No practical way to test out new ideas to gain confidence Hence, it is commonly believed that the networks infrastructure is fixed We need something to help out with experimenting on the networks Filip Stankovski (JUB) OpenFlow April 30, 2014 3 / 16
How? GENI(Global Environment for Network Innovations) - proposed nationwide research facility Use programmable switches and routers Allocate a slice or resources to researchers, can be programmed to behave as they wish Virtualized programmable networks can help lower the entry barrier for innovations However, nationwide deployment is costly Let s focus on something smaller, yet still significant: campus networks Filip Stankovski (JUB) OpenFlow April 30, 2014 4 / 16
Campus wide programmable networks Problem: People might not be comfortable inserting experimental equipment into networks Problem: How will researchers control only a portion of the network without disrupting everyday traffic? Solution 1: Persuade commercial vendors to provide open platform on switches and routers - difficult to standardize Solution 2: Use an open software platform(pc with several interfaces and an OS) - performance issues Solution 3: Use OpenFlow(enabled) switches Filip Stankovski (JUB) OpenFlow April 30, 2014 5 / 16
OpenFlow Switches Designed to be: Amenable to high-performance low-cost implementations Supports a broad range of research Separate experimental and everyday traffic Vendors platforms stay closed Have one network administrator that partitions traffic Researchers control their own flows Arbitrary handling of packets suffers Filip Stankovski (JUB) OpenFlow April 30, 2014 6 / 16
OpenFlow Switch Components Flow Table with an action associated to each entry A secure channel for communicating to the controller OpenFlow protocol - open and standard way to communicate with a switch This way researchers don t have to program the switch itself. Filip Stankovski (JUB) OpenFlow April 30, 2014 7 / 16
Types of OpenFlow Switches All switches must support these actions: Forward a specific flow s packets to a specific port Encapsulate a flow s packets and forward to the controller Drop a flow s packets Forward flow s packets through the normal processing pipeline(openflow-enabled switches only) Dedicated OpenFlow switches Flow Table has the following format: Packet header that defines the flow, Action, Statistics OpenFlow-enabled switches Normal routers/switches enhanced by adding the protocol, flow table and secure channel Uses preexisting hardware for the flow table, the secure channel and protocol will run on the OS Instead of the 4th action, they can implement VLANs to separate traffic Filip Stankovski (JUB) OpenFlow April 30, 2014 8 / 16
OpenFlow Switch Components Filip Stankovski (JUB) OpenFlow April 30, 2014 9 / 16
OpenFlow Type 0 Header Filip Stankovski (JUB) OpenFlow April 30, 2014 10 / 16
OpenFlow Controller Adds/removes flow entries to/from the Flow Table on behalf of experiments Has the potential to be enhanced to the point where it can dynamically add/remove flows as an experiment progresses Filip Stankovski (JUB) OpenFlow April 30, 2014 11 / 16
OpenFlow enabled switches Filip Stankovski (JUB) OpenFlow April 30, 2014 12 / 16
OpenFlow Usage Examples Amy-OSPF She experiments, so she decides not to disrupt the normal flows Wants a flow to go through specific switches Flow Table action for her packets: Encapsulate and forward all packets to a controller The protocol chooses a route and adds flow entry to every switch when packets reach controller Problem: Amy s protocol can add entries for other flows. We need to take care of that Solution: Depends on the controller. Permissions are one way of dealing with this Network Management VLANs Wireless VOIP clients Non-IP networks Processing packets individually Filip Stankovski (JUB) OpenFlow April 30, 2014 13 / 16
OpenFlow Consortium and Deploying Switches The OpenFlow Consortium aims to popularize OpenFlow and maintains the specifications Membership is open to anyone in a school, university or government agency and is free The OpenFlow Switch specifications are free for all commercial and non-commercial use Vendors are open to the idea of adding OpenFlow since it does not require any hardware changes Already deployed at Stanford University There are reference designs for Linux, OpenWRT and NetFPGA. Designs get posted as they become available Filip Stankovski (JUB) OpenFlow April 30, 2014 14 / 16
Questions? Questions? Filip Stankovski (JUB) OpenFlow April 30, 2014 15 / 16
References OpenFlow: Enabling Innovation in Campus Networks(Apr 2008) N. McKeown, T.Anderson, H.Balakrishan, G.Parulkar, L.Peterson, J.Rexford, S.Shenker, J.Turner Filip Stankovski (JUB) OpenFlow April 30, 2014 16 / 16