What Is OpenFlow?
OpenFlow is a network communication protocol used between controllers and forwarders in an SDN architecture. The core idea of SDN is to separate the forwarding plane from the control plane. To achieve this, a communication standard must be built between controllers and forwarders to allow the controllers to directly access and control the forwarding plane of forwarders. OpenFlow introduces the concept of flow table, based on which forwarders forwards data packets. Controllers deploy flow tables on forwarders through OpenFlow interfaces, achieving control on the forwarding plane.
Origin and Development of OpenFlow
OpenFlow originated from the Clean Slate Program of Stanford University. This program considered how the Internet could be redesigned with a "clean slate", and aimed to change the network infrastructure that was slightly out of date and difficult to evolve. In 2006, Martin Casado, a student from Stanford University, led a project on network security and management. The project attempted to use a centralized controller to allow network administrators to easily define security control policies based on network flows and to apply these security policies to various network devices, thereby implementing security control over the entire network communication.
Inspired by this project, professor Nick McKeown — the director of the Clean Slate Program — and his team found that if the data forwarding and routing control modules of traditional network devices were separated, a centralized controller could be used to manage and configure various network devices through standard interfaces. This would result in more possibilities for the design, management, and use of network resources, thereby facilitating network innovation and development. Therefore, they put forward the concept of OpenFlow and published a paper entitled "OpenFlow: Enabling Innovation in Campus Networks" in 2008, introducing the principles and application scenarios of OpenFlow in detail for the initial time.
On the basis of OpenFlow, this team further proposed a concept of SDN in 2009, which attracted wide attention of the industry. In 2011, Google, Facebook, Microsoft, and other companies jointly set up the Open Networking Foundation (ONF) — an organization dedicated to promotion and adoption of SDN. The ONF defines OpenFlow as the first standard southbound communication interface between the control and forwarding layers in the SDN architecture, and standardizes OpenFlow.
OpenFlow in the SDN architecture
Since its first official version 1.0 released at the end of 2009, OpenFlow has evolved from versions 1.1, 1.2, 1.3, to the latest version 1.5. Currently, versions 1.0 and 1.3 of OpenFlow are most widely supported and applied.
Evolution and major changes of OpenFlow versions
How OpenFlow Works
The OpenFlow architecture consists of a controller, OpenFlow switch, and secure channel. The controller controls the network in a centralized manner to implement the functions of the control layer. The OpenFlow switch is responsible for forwarding at the data layer; it exchanges messages with the controller through a secure channel to receive forwarding entries and report its status.
OpenFlow architecture
OpenFlow Controller
An OpenFlow controller is the brain of the SDN architecture and is located at the control layer to instruct data forwarding through the OpenFlow protocol. Currently, mainstream OpenFlow controllers are classified into two types: open-source controllers and vendor-developed commercial controllers. The widely used open-source controllers include NOX, POX, and OpenDaylight. Huawei's iMaster NCE controllers are commercial ones.
OpenFlow Secure Channel
A secure channel is established between a controller and an OpenFlow switch. Through this channel, the controller controls and manages the switch, and receives feedback from the switch.
The messages exchanged over the OpenFlow secure channel must comply with the format specified by the OpenFlow protocol. The OpenFlow secure channel is usually encrypted using Transport Layer Security (TLS), but may be run directly over TCP in plain text in OpenFlow 1.1 and later versions. The following OpenFlow messages are transmitted over the channel:
- Controller-to-Switch message: is sent by the controller to the OpenFlow switch to manage or obtain the OpenFlow switch status.
- Asynchronous message: is sent by the OpenFlow switch to the controller to update network events or status changes to the controller.
- Symmetric message: is sent without solicitation by either the OpenFlow switch or the controller. It is mainly used to set up a connection and detect whether the peer is online.
OpenFlow Switch
As a core component of the OpenFlow network, an OpenFlow switch is mainly responsible for forwarding at the data layer. It can be a physical or virtualized switch/router. OpenFlow switches are classified into the following types based on their support for OpenFlow:
- Dedicated OpenFlow switch: is a standard OpenFlow device that supports only OpenFlow forwarding. The switch processes all traffic that passes through it in OpenFlow mode, and cannot perform Layer 2 or Layer 3 forwarding on the traffic.
- OpenFlow-compatible switch: supports both OpenFlow forwarding and Layer 2/3 forwarding. It is a commercial switch that supports OpenFlow features such as flow tables and secure channels.
An OpenFlow switch forwards packets entering the switch based on the flow table, which contains a set of policy entries instructing the switch on how to process traffic. Flow entries are generated, maintained, and delivered by a controller.
Flow entry
Traditional network devices such as switches and routers forward data based on the locally saved Layer 2 MAC address forwarding table, Layer 3 IP address routing table, and transport-layer port numbers. OpenFlow switches forward data based on flow tables that contain network configuration information of all layers on the network, instead of 5-tuple information. The entries in a flow table are flexible combinations of certain keywords and actions.
Each flow entry in an OpenFlow flow table consists of match fields and a set of instructions applying to matching packets. When receiving a data packet, an OpenFlow switch parses and matches the packet header against match fields in the flow entries, and executes the corresponding instruction if a match is found.
The flow entry structure varies according to the OpenFlow versions, as shown in Figure 1-5.
Multi-level flow table and pipeline processing
OpenFlow v1.0 uses a single flow table to match packets. This implementation is simple, but the flow table becomes quite large as various policies are configured to implement increasingly complex network requirements. This makes management of the control plane more difficult, and poses higher requirements on hardware.
OpenFlow v1.1 and later versions support multi-level flow tables and pipeline processing. When a packet arrives at a switch, matching starts from the flow table with the smallest sequence number, and may continue to additional flow tables in the pipeline. Multi-level flow tables can not only implement complex processing on data packets, but also reduce the length of a single flow table and therefore improve the entry lookup efficiency.
Multi-level flow table processing
Flow table delivery
OpenFlow flow tables can be delivered in proactive or reactive mode.
- In proactive mode, the controller delivers the flow table information to OpenFlow switches.
- In reactive mode, when an OpenFlow switch does not find any flow entry matching a received packet, it sends a message to the controller. The controller then determines how to forward the packet, and calculates and delivers the corresponding flow entry to the switch. In this mode, the switch does not need to maintain all flow entries. Instead, it obtains flow entries from the controller and saves them only for actually generated traffic, and deletes flow entries when they are aged out. Therefore, this mode greatly reduces the occupied chip space on the switch.
Application Scenarios of OpenFlow
With the development and popularization of OpenFlow, its research and application fields are also continuously expanded, covering network virtualization, security and access control, and load balancing. The following describes the typical application scenarios of OpenFlow:
- Application of OpenFlow on a college campus network
The network of scientific research institutions is where OpenFlow comes into being and also the network environment where OpenFlow is widely used. Students or researchers may need to verify newly designed network control protocols and data forwarding technologies when conducting innovative research on networks. In such cases, they want a platform separating the control plane from the forwarding plane, so that they can flexibly verify their research work. An OpenFlow-based network is such a platform meeting these requirements by providing almost the same complex environment as an actual network, while ensuring a good experiment effect and reducing experiment costs.
- Application of OpenFlow on a data center network
OpenFlow starts its large-scale application on cloud data center networks. Deployment of cloud data centers poses many virtualization requirements, such as dynamic creation of multi-tenant resources, traffic isolation, and dynamic migration of virtual machines (VMs). OpenFlow switches can work with the cloud management platform to implement dynamic allocation of network resources and on-demand transmission of network traffic, meeting network virtualization requirements of cloud services and improving network performance. As data centers have heavy traffic, data congestion may occur if transmission paths are not properly allocated, thereby hindering the operational efficiency of data centers. To avoid this situation, OpenFlow can be deployed in data centers to dynamically obtain traffic transmission information of each link and deliver OpenFlow flow entries to load balance traffic among links.
- Application of OpenFlow on an enterprise campus network
OpenFlow can be used on a campus network to effectively manage and control access devices, which are large in number, have a relatively high failure rate, but provide simple functions and traffic policies. With OpenFlow, a controller can be deployed to centrally deliver flow entries to access devices, and monitor and manage these devices. In scenarios where user identity authentication is required, the authentication traffic can be diverted to the controller. After user identities are successfully authenticated, the controller delivers admission rules to the switch interfaces connected to users. If the controller detects that a network interface or traffic of a user is abnormal, it delivers rules to disable the interface or control the traffic to quickly rectify network faults, thereby improving network reliability and security.
- Author： Gao Yangyang
- Updated on： 2021-09-30
- Views： 18593
- Average rating：
