The OpenFlow SDN Architecture

The OpenFlow protocol provided a specification for communication between an SDN switch and Controller. Due to its proximity specifications (or lack thereof) between the forwarding device (switch) and the control element (controller), the OpenFlow architecture additionally specifies a secure channel between the controller and the switch. Thus, the OpenFlow SDN architecture actually has three key elements, as illustrated in Figure 2.1:

• Controller

• Switch

Figure 2.1: SDN Architecture

We provide a general discussion of each of these here and explore security issues with each later on in this chapter.

2.4.1.1 Controller

One of the key characteristics of SDN is the logically centralized controller. The modern controller not only provides a central control point for the flows in the net- work but also provides a platform for launching other network services. Essentially the controller functions as a network operating system [35] upon which various appli- cations can be run which provide the network services. Some of the more currently widely used controllers include RYU [36], OpenDaylight [37] and Floodlight [38].

The applications typically interact with the controller via a Northbound, REST API (Representational State Transfer Application Program Interface). The con- troller provides hooks which allow applications to perform queries and issue com- mands to the switch. These applications provide services such as traffic routing (e.g a mac learning switch application) and QoS guarantees. Many provide security ser- vices such as DDoS or scanning detection and protection by monitoring and filtering

the traffic coming into and moving around the network. We explore several such applications later in this chapter.

The controller interacts with the switch via the southbound interface [39]. In OpenFlow networks, it interacts with the OpenFlow Agent residing on the switch. As mentioned before in the discussion on programmable networks, the switch itself contains a very limited control plane which exists for the purpose of interacting with the controller. This is the OpenFlow Agent. Over time, the evolution of the OpenFlow protocol has created more functionality between the controller and the switch, however the basic interactions have remained the same. The controller can issue commands to install flows, remove flows and query the status of the flow table which gives it the flows existing in the switch along with various statistics associ- ated with them (such as the number of packets that have passed through them). Using these commands, the controller exercises complete control over the network and through it, the applications perform their functions.

2.4.1.2 Controller-Switch Communication Channel

The communication channel is described as a secure channel which connects the OpenFlow switch to the controller [40]. It provides a medium over which the con- troller configures the switch and the switch provides information to the controller. The protocol leaves the implementation to the discretion of the network administra- tors. Conventionally, wired Ethernet is used, however wireless [41] and even cellular links [42] have been proposed.

2.4.1.3 Switch

The Switch is responsible for forwarding packets around the network. In a pure SDN architecture, the switch does not make its own decisions about how to route packets but receives such decisions from the controller. In this regard, the switch has often been referred to as a “dumb” device. The SDN switch has several funda- mental attributes:

OpenFlow Agent:

the controller using the OpenFlow protocol [43]. The OFA provides the interface between the switch and the control plane. It is responsible for crafting packet-in messages to request flow rules from the controller and inserting the flow rule issued by the controller into the flow table. On a more general note, it is responsible for responding to controller instructions on the switch. It provides the minimal control plane functions on the switch as specified above.

Flow Table:

The switch Flow Table stores rules providing information on how to route packets which arrive at the switch [40]. Since the switch in itself makes no decisions, the controller is responsible for populating the switch Flow Table by installing or re- moving rules from it. Each rule contained in the switch flow table consists of several attributes (Figure 2.2 shows a sample). These include the packet header field values with which the rule is concerned, the number of packets and bytes which have used the rule, the length of time it has been in the switch and the actions the switch must take for any packet that matches said rule.

TCAM (Ternary Content Addressable Memory):

TCAM is used to support the flow tables in the switch for fast lookup of flow rules when forwarding packets [44]. TCAM is unfortunately very expensive and this limits the amount of memory the switches hold. TCAM flow tables are often restricted to holding a few thousand flows which is less than ideal in large networks. We explore further why this is a problem later in this chapter.

Data Plane:

The Data Plane is located within the switch and handles the forwarding of packets to the next hop in their path. When a packet arrives at a switch, the switch’s data plane consults the flow table for instructions on how to handle the packet. If the packet’s header fields match a flow rule in the flow table, the switch performs the action associated with that flow (e.g flood, drop or forward out of a specific port). In the event that the packet’s header field values do not match any flow rules in the Flow Table, the packet is passed to the OpenFlow Agent in the switch which prepares a query for the controller on how to handle this packet. Application- Specific Integrated Circuits (ASICs) within the switch provide high performance packet switching within SDN switches. Some well known ASIC providers include Cisco, Huawei, Juniper [39].