OpenFlow is an architecture and protocol recently developed in academia. In this new architecture, the control plane is de-coupled from the forwarding plane in a given router and generally in a network. The functionality of a conventional router is reorganized as a distributed system. An OpenFlow network contains a network-wide control platform, running on one or more servers in the network. The control platform oversees and manages a set of simple switches.
Conventional router architecture follows an integrated design where the control plane and data forwarding engine are tightly coupled in the same box, which results in an overly complicated control plane and complex network management. Due to the high complexity, equipment vendors and network operators are reluctant to deploy changes to these routers and the network itself is fragile and hard to manage. This is generally seen as creating a large burden on network administrators and a high barrier of entry for new protocol and technology developments related to networking.
OpenFlow defines a network element model where the two central components are the controller and the OpenFlow switch as depicted in FIG. 1. A controller is able to communicate with an OpenFlow Switch via the OpenFlow protocol in order to control the switch. The OpenFlow control protocol provides a vendor agnostic interface for controlling network forwarding elements. OpenFlow enables the separation of the control plane and data plane in routing and switching gear. The OpenFlow interface allows flexible deployment of the network control plane software and simplifies the control plane on network forwarding hardware. The control plane can be deployed on a centralized controller that controls multiple forwarding elements, rather than having a distributed control plane with components that run on each switch. This split architecture of OpenFlow enables increased innovation in control plane software and simplified operations and management.
The architecture of an OpenFlow switch is shown also in FIG. 1. The OpenFlow switch consists of three major components, the flow table, a secure channel to the control process, and the OpenFlow protocols. Switches are modeled as a flow table in which there are three columns: rules, actions, and counters. The rules column defines the flow. Rules are matched against the headers of incoming packets. If a rule matches, the actions from the action column are applied to the packet and the counters in the counter column are updated. The OpenFlow protocol is carried over the secure channel and specifically transport layer security (TLS) is used for the implementation of that secure channel. The OpenFlow protocol provides an open and standard method for an OpenFlow switch to communicate to a controller.
The split architecture of an OpenFlow network can includes multiple OpenFlow switches interconnecting with each other and a small number of controllers that instruct the switches' forwarding behavior. The main task of an OpenFlow switch is to forward packets from ingress port to an egress port, according to the rules in the flow table programmed by the remote controller. Each flow entry contains a set of actions such as forwarding packets to a given port, modifying certain bits in the packet header, or encapsulating packets to the controller, or simply dropping the packets. For the first packet in a new flow, the switch normally forwards the packet to the controller to trigger the new flow entry being programmed. It can also be used to forward all slow-path packets to a controller for processing such as Internet control message protocol (ICMP) packets. The concept of a flow can be defined broadly, e.g., a TCP connection, or all traffic from a particular MAC address or IP address.
The controller adds and removes flow-entries from the Flow Table. It defines the interconnection and routing among the set of data plane switches. It also handles network state distribution, such as collecting information from the switches and distributing routing instructions to them. It can also be programmed to support any new addressing, routing, and complex packet processing applications. The controller is the “brain” of the network. An OpenFlow switch needs to connect to at least one controller to function correctly. A simple network topology that consists of two controllers and a set of OpenFlow switches is illustrated in FIG. 2.
FIG. 2 illustrates a network that consists of seven OpenFlow switches and two controllers. There can be a fixed binding between controller and switches, which is the shortest path between the switch and its closest controller. A static binding between controller and the switch is also possible, e.g., C1 is the assigned controller for S3. S3 can only be controlled by C1 even if it is also reachable by C2. In this example, there is a separate link between two controllers C1 and C2 to exchange the network states between them. Each controller uses the same network constructed using the OpenFlow switches to communicate with those OpenFlow switches that the respective controller has been assigned to control. For instance, S7 goes through S3 and S1 to reach the controller C1, marked as a dotted line. It is also assumed that fixed routing has been set up. The subscripts denote the flow entries in each switch. An entry on S4 is programmed by C1 to match any HTTP flow from IP1 and forward to port 1 connected to S7.
USPTO Backgrounds
USPTO Backgrounds