A survey of open networking standards, part 4: OpenFlow
August 20, 2015
The first three parts of our series on open source networking standards have covered OpenDaylight, Open vSwitch and OpenStack, all of which are broad...
The first three parts of our series on open source networking standards have covered OpenDaylight, Open vSwitch and OpenStack, all of which are broad software projects intended to change how vendors and telecom and enterprise customers approach the network. These three initiatives address software-defined networking (SDN) controllers (OpenDaylight), virtual switching (Open vSwitch), and cloud orchestration (OpenStack).
In this post, we’ll look at some open source networking protocols that have become instrumental in the push for greater network agility. Arguably the most prominent is OpenFlow, which was really the catalyst for the SDN movement since it made the industry pay attention to the idea that switches could be programmable. OpenFlow has its roots in Ethane, a 2006 project by then Stanford Ph.D. student Martin Casado (since CTO and co-founder of Nicira and currently an executive at Nicira acquirer VMware), and it is now managed by the Open Networking Foundation.
OpenFlow: A protocol for managing traffic and enabling SDN orchestration
Despite its prominence, OpenFlow isn’t the only protocol for SDN, nor is it sufficient on its own to qualify as SDN. Instead, it is, as Steve Evans pointed out for ComputerWeekly a while back, a building block for an SDN architecture that enables the key abstractions and programmability essential to SDN.
At the most fundamental level, OpenFlow centralizes packet switching control, replacing the proprietary software that controls where each switch sends packets on most networks. It is based on a flexible flow field, rather than simple destination-matching based, and it is designed to be a standard communications interface between the forwarding and control planes within SDN. With OpenFlow it is possible to not only decouple forwarding and control, but also software and hardware as well as physical and logical configurations.
Whereas a traditional L2 switch uses MAC learning and unicast flooding to progressively populate its forwarding table and destination MAC addresses for forwarding, a network built around OpenFlow receives its forwarding table instructions from an OpenFlow controller (such as OpenDaylight) running on a server or VM. The OpenFlow Controller interacts with switches and routers via the OpenFlow protocol and business applications via northbound APIs.
The centralized position of the controller allows it to optimize network-wide control of flows to maximize bandwidth utilization, deliver better end-to-end QoS, and efficiently respond to dynamic requirements coming from applications and services based on business policies. OpenFlow is an ideal companion to cloud orchestration, since its more flexible, programmable nature allows it to be the basis for connectivity that supports policy-driven infrastructure environments.
There are three key components of an OpenFlow system:
· The flow tables in OpenFlow-compatible switches
· The OpenFlow Controller, as described above
· The OpenFlow protocol through which the controller and switches communicate
A flow table entry on an OpenFlow switch contains packet fields that can be matched, including source (or destination) Ethernet or IP address, TCP/IP ports, etc. Actions such as forwarding the packet to the right port, altering header values, or dropping are driven by flow policies based on these fields.
Flow parameters are defined by the controller, which will also typically receive any packets that don’t match an existing flow table entry. When the controller processes one of these packets it will create a new entry with instructions for dealing with similar flows in the future.
Messaging by OpenFlow Controllers and OpenFlow Switches may be symmetric, asynchronous, or controller-to-switch:
· Symmetric messages are “hello” messages between switch and controller, as well as echo messages for monitoring switch-to-controller communications latency.
· Asynchronous messages come from the switch and involve the aforementioned case of a packet that doesn’t match an extant flow table entry. The switch may also inform the controller of a change of port, error, or removal of a flow due to inactivity.
· Controller-to-switch is what it sounds like in that the controller may ask the switch for information, modify its flow tables, or resend a packet after a new entry has been created.
OpenFlow and the SDN community
OpenFlow is an important cog in the machinery of both the SDN movement and the broader open source community. OpenFlow has key interactions with OpenDaylight and Open vSwitch (e.g., it allows for programmatic extensions for Open vSwitch, facilitating network automation). For SDN, it is the most influential open source protocol for forwarding/control abstraction. The Open Networking Foundation now includes many major vendors such as HP, Huawei, and IBM, and it continues to refine OpenFlow.
However, it’s not the only game in town. Cisco has pushed OpFlex as part of its Application Centric Infrastructure (ACI), which can be looked at as a very different take on SDN that doesn’t require the particular feature set of OpenFlow. In addition, network overlay approaches such as VMware’s NSX offer a completely different paradigm for approaching network programmability.
The SDN space opened up by OpenFlow years ago is still highly competitive, as more organizations make the shift to the software-defined datacenter and additional virtualization. With Gartner declaring that SDN has reached the nadir point on its hype-cycle journey, true adopters are doing the serious work to turn protocols like OpenFlow and its competitors into real-world solutions to actual business problems. Only time will tell which paradigms will win out.
QualiSystems Ltd.
