SDN architecture

In the current architecture, network devices are monolithic and operates the control and the data planes. Figure 2.1 shows the common network architecture where the device performs both tasks, and dotted lines represent the communication channels between control decisions and hardware instructions. The control plane manages addresses, routing and logic resources between network and link layers. The forwarding plane manipulates the packet and administrates device’s ports and interfaces. Each device deals only with partial information and constitutes a portion of the distributed system to perform fundamental tasks such as addressing or routing.

SDN separates the control plane from the data plane, also called forwarding plane.

SDN comprises three layers, upper layer corresponds to protocol logic and applications for

Device

Figure 2.3: Network architecture comparison: Current network vs. SDN.

network administration, the second layer is the network operating system (NOS) as support of the control plane, and lower layer is the data plane and forwarding. Figure 2.2 shows the SDN architecture and its layer division by purpose. The logical channel between controller and forwarding, dotted lines in the figure, operates the OpenFlow protocol [McK+08a]. The controller is responsible for running network functionality. In addition, it can execute other high–level applications to control the traffic. Figure 2.3 shows architectural differences between the current network and the SDN paradigm. In SDN, each layer is executed on different hardware, they are physically decoupled. The controller runs on a server, and the forwarding is performed on simple datapaths (switches).

OpenFlow

OpenFlow protocol (OF) is an open implementation of a protocol that communicates the controller and the datapath. It allows to program the datapath and modify the forwarding table, commonly called flowtable. [McK+08a]. A secure channel is established to connect the controller and the datapath through the OF protocol, so the controller can install/delete/modify rules into datapath’s flowtable. Datapaths store the flowtable with forwarding actions for each match entry with current-protocols and regular Ethernet fields.

OF defines three atomic actions: SEND, DROP, and SEND_TO_CONTROLLER to perform over a packet when it reaches the datapath. Figure 2.4 shows the header fields used by OF to manage traffic. The forwarding table stores is a list of packet–header matchers and the correspondent action to be executed to a packet.

The controller can modify entries from the flowtable, independently of the user and

In Port VLAN ID Ethernet IP TCP Src Dst Type Src Dst Proto ToS Src Dst

Figure 2.4: Packet fields for header matching in OpenFlow version 1.0.

operation. Then, OF allows the creation of new flow rules that does not interrupt other users network utilization. Using the OF syntax shown in figure 2.5, the network administrator can program the datapath behavior, and decide how the packets are processed by the device.

SDN can also offers isolation which allows independent network domain for each user, and facilitates to create virtual networks. Other extensions for OF have been developed and depend on the protocol version, [Ope11; Ope12; Ope13].

R u l e s r ::= hpat, pri, t, [a1, . . . , a_n]i P a t t e r n s pat ::= {h1: n1, . . . , h_k : n_k} P r i o r i t y pri ::= n

Timeout t ::= n | None

A c t i o n s a ::= output ( op ) | modify ( h, n )

Header h ::= i n _ p o r t | vlan | d l _ s r c | d l _ d s t | d l _ t y p e | n w _ s r c | nw_dst | nw_proto | t p _ s r c | t p _ d s t P o r t s op ::= n | flood | c o n t r o l l e r

Figure 2.5: OpenFlow syntax.

Initially, OF was created for research purposes, using Ethernet switches and a standard interfaces. Then, multiple vendors offered APIs and protocols based on OF to manipulate the flowtable on their devices and called it OF enabled.

Using this architecture, network administrators are able to share resources in a dynamic way because it allows creating virtual networks, independent network domains for multiple groups of users, and have a fine–grain control of the traffic.

Forwarding devices

A datapath is an OF enabled device, switch, router or any forwarding device, responsible for storing the flow–table, also called forwarding table, with a set of actions for each entry.

This table stores a list of match-action pairs hmatch,actioni. If a received packet matches any header–rule of the table, the device executes the associated action. On the other hand, if the packet header does not match any entry, the device sends a request to the controller. A request contains the header, destination and received ports, and in some cases it includes the singular packet. After receiving the request, the controller can create or modify a rule, and update the forwarding table on the device. An OF device checks matching using current protocols and Ethernet fields. Figure 2.4 shows possible

header-fields used by OF. Controller and network applications can process packets using these fields with OpenFlow. The registered actions that a device can perform are: send to a specific device-port, drop the packet, or send to controller request.

The network controller

The controller acts as an intermediate layer (2.5 layer) that manages data–plane devices and holds the network state. Normally, the controller is a centralized entity, has a database with topological information, and it supports the intelligence behind the network. Under this perspective, network layer devices no longer have to calculate and handle routing tables, as the traditional L3 devices did. Logical sets of rules, such as routing protocols, are applications that run on the controller and set forwarding instructions on each device under the controller’s domain. All routing information, such as addressing, spanning trees or path calculation, comes from the controller. Moreover, the controller is the only authorized entity to add, modify and delete flow rules on datapaths. For instance, the controller can also execute the path computation element protocol (PCEP)^a that computes paths over a topology. The controller, and its Network Operating System (NOS), has two interfaces:

north and south. The north–bound is an Application Program Interface (API) with network applications that provides controlling services. And the south–bound communicates the controller with datapaths.

In summary, OpenFlow facilitates the separation of control and forwarding functions.

Network equipment is reduced to devices that receive and forward packets according to its flowtable. Regularly, network devices report unknown or new traffic to the controller, and it updates its network information. Diverse implementations were developed to optimize flowtables on datapaths. For example, DevoFlow [Cur+11] uses the ASIC hardware to separate long flows from small ones, and central control has only to focus on significant flows and reduces the amount of flowtable entries. In this way, it minimizes requests to optimize the interaction with the control plane . Later, Nguyen et al. [NSBT14] proposed an optimization problem of rule selection and placement on switches and solved it with Integer Linear Programming which includes in and out points, and consider that routing policy can be ignored if those points are respected. Therefore, its allocation procedure maximizes the rule-allocation that satisfies the out points.