[Reading Summary] OpenFlow: Enabling Innovation in Campus Networks

The backgroud is that I am working as an engineer in cisco developing products with inhouse ASIC/sillicon one. But I have no permission to read related documents, even the datasheet. Yeah, it sounds like crazy. So I have to search public documents for understanding the inside mechanism of our own company's product, as I am a person love to do reasonable things...and I am also considering if there is a chance to pursure a Phd journey, hoping the way to figure out how the chip on my hand works also give me some hints about my life path selection.

The first paper come to my eye is dRMT: Disaggregated Programmable Switching, but it's not enough to catch the big picture, and after several searchs from names and references I found I need to start from Nick's OpenFlow: Enabling Innovation in Campus Networks.

After several passes reading, I am trying to summary the very first paper. Of cause when I read I randomly reference to IP protocol and MPLS protocol and my plan to next summary is IPv4. It's surprising that openflow was proposed in 2008, it's just 16 years ago. I thought it's an ancient story like thermodynamics.

The main idea about the paper is to enable innovation in LAN, though the title said it only targets campus network. The solution the paper gave is openflow. Openflow is now almost dead and there are also other ways of enabling innovation in computer network. But this paper still valuable for understanding why there is smart NIC, smart-TOR and why cisco s1 can achieve route/switch in one arch.

First the author proposed that we need a programmable network, because the network at that time is a closed network which is in form of a dirtributed black boxes for customers. The customers includez the network operators and network researchers only have ability to use the the boxes with fixed network protocols and can't differentiate between experiment traffics and production traffics which makes new protocol development has no chance to do experiments on real-world network and also makes real-world network hard to apply new network protocols.

Second the author proposed that how to implement a programmable network: openflow. With no surprise, it still needs box makers's help. The foundation of openflow is the authors's insight that most modern Ethernet switches and routers contain flow-tables (typically built from TCAMs) that run at line-rate to implement firewalls, NAT, QoS, and to collect statistics.

And then openflow needs box makers to export a flow table interface to the users. Each flow table entry has three fields: (1) A packet header that defines the flow, (2) The action, which defines how the packets should be processed, and (3) Statistics, which keep track of the number of packets and bytes for each flow, and the time since the last packet matched the flow (to help with the removal of inactive flows).

For actions, it requires below functions:

1. Forward this flow's packets to a given port (or ports). Run at line-rate.

2. Encapsulate and forward this flow's packtes to a controller. Only 1 packet or all the packets to help make policy.

3. Drop this flow's packtes.

4. Forward this flow's packets through the switch's normal processing pipeline.

Third the author gives some usecases of openflow. Openflow makes all networking resources (mainly flow tables) in LAN together as a pool and use it in the way people want to use. It makes me think of that we use memory pools instead of malloc time and time again. Seems resource pooling can be very useful when you have a big picture to do something, the cost is you need to carefully define the interface and schedule the resource with a good controller (or the system will be broken).

First example in the paper is Amy-OSPF, which needs the controller's help to check the packet and apply flow-entrys to all openflow switches in the path. The effort here you need to build a controller with performance, realiability and scalability. Nick has built Ethane controller as an example and shows that a low-cost desktop PC could process over 10000 new flows per second, enough for a  large college campus. And NOX is a follow up work.

Nick also illustrated several usecase types like (1). Network management and access control. (2). VLANs. (3). Mobile wireless VOIP clients. (4). A non-IP network realized by offset-value-mask combination. (5). Processing packets rather than flows, such as congestion control or packet content change. Also we can use FPGA to improve performance.

Openflow marked as the start of SDN and also inspired a log of network. It's a good hint for understanding today's computer networks.