2.2 Software Defined Networks

2.2.4 OpenFlow

A number of protocol standards exist on the use of SDN in real applications, with the most popular protocol standard called OpenFlow.

It was proposed in the paper ”OpenFlow: enabling innovation in campus networks” [23], aiming to provide a high performance traffic control across multiple vendors’ network devices. OpenFlow is one of the first protocol designed specifically for SDN, and is already standard- ised by the ONF [24].

OpenFlow is a open protocol used to establish communication between the control appli- cation layer (e.g., software applications) and forwarding plane (e.g., routers, switches) within the SDN infrastructure, thus enabling the handling of the network as a whole rather than individual devices, granting a more efficient use of network resources.

2.2.4.1 OpenFlow Architecture

An OpenFlow based architecture essentially consists of three main components: an OpenFlow- compliant switch, an OpenFlow controller, and a secure communication channel which provides a link for the transmission of commands and packets between the controller and the switch, as shown in figure 2.3 [25].

Figure 2.3: OpenFlow based Architecture from OFv1.0 specifications

Source: [25]

2.2.4.2 OpenFlow Switch

An OpenFlow Logical Switch consists of one or more flow tables, a group table which performs packet lookups and forwarding, and one or more OpenFlow channels to an external controller (Figure 2.4). The switch communicates with the controller and the controller manages the switch via the OpenFlow switch protocol through a secure channel [20] [26]. The OpenFlow switches establish a communication channel with the controller via an IP address using a specified port, then initiates a standard Transport Layer Security (TLS) or Transmission Control Protocol (TCP) connection to the controller. The traffic between the controller and switch does not go through the OpenFlow pipeline, so it must identify when incoming traffic is from the controller before matching it with the flow tables. Each OpenFlow switch may establish communication with a single or multiple controllers [20].

OvS [20] is one of the most popular software-driven OpenFlow switches.

Figure 2.4: OpenFlow based Switch

2.2.4.3 OpenFlow Flow Tables, Match Fields and Actions

Switches use flow tables (i.e. a list of flow entries) to forward packets. Each entry consists of: match fields, counters and instructions. Match fields are compared against the fields of the packet being processed; Counters are used to keep statistics about packets; and instructions to apply to the processed packet, such as modifying the packet’s fields, drop the packet, forward the packet or encapsulate the packet and send it to the controller.

Incoming packets are compared with the match fields of each entry and if there is a match, the packet is processed according to the action contained by that entry.

The OpenFlow specification defines three types of tables in the logical switch architecture. A flow table matches incoming packets to a particular flow and specifies the actions that are to be performed on the packets. There may be multiple flow tables that operate in a pipeline fashion, as show in figure 2.5 A flow table may direct a flow to a group table, which may trigger a variety of actions that affect one or more flows. A meter table can trigger a variety of performance-related actions on a flow.

The typical packet processing flow in a OpenFlow switch is the following: When a packet arrives at the switch, the packet is matched against the flow entries of the flow table, if a match is found, the instruction set included in that flow entry is executed. These instructions may explicitly direct the packet to another flow table (using the GotoTable Instruction), where the same process is repeated again.

A flow entry can only direct a packet to a flow table number which is greater than its own flow table number, in other words, pipeline processing can only go forward and not backward. If the matching flow entry does not direct packets to another flow table, the current stage of pipeline processing stops at this table and the packet is processed with its associated action set. If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss depends on the table configuration. The instructions included in the

Figure 2.5: Packet flow through the processing pipeline

table-miss flow entry in the flow table can flexibly specify how to process unmatched packets, such as dropping them, passing them to another table or sending them to the controllers over the control channel via packet-in messages. There are few cases where a packet is not fully processed by a flow entry and pipeline processing stops without processing the packet’s action set or directing it to another table. If no table-miss flow entry is present, the packet is dropped [20].

2.2.4.4 OpenFlow Controller

The OpenFlow controller is the entity responsible for manipulating the switch’s flow tables, managing how to handle traffic without valid flow entries, as well as distributing appropriate instructions to the network devices, using the OpenFlow protocol via a secure channel. The controller has a global, logical view of the network.

Several controllers have been proposed since OpenFlow was brought to the community in 2008 [27]. The first open source controller was NOX [28], followed by others, such as, Maestro [29], Beacon [30] or Trema [31]. Examples of controllers that address scalability [32] are DevoFlow [33], ONIX [34] or FlowN [35]. Examples of open source OpenFlow controllers, still maintained, being among the most widely used [36]: OpenDaylight [37], POX [38], Floodlight [39], ONOS [40] and Ryu [41].

In document Implementação de serviços em ambientes multi-access edge computing (Page 32-35)