3 Software Defined Networking (SDN)
3.5 SDN Protocols

The separation of the control and data forwarding plane – one of the central pillars of SDN together with centralization of control plane means that there is a need for communication protocol. In this section we introduce some of them, starting with the most popular – OpenFlow.

OpenFlow

OpenFlow is an open standard originally developed at universities and currently maintained by Open Network Foundation (ONF) [9] – a non-profit consortium with mission to commercialize and promote OpenFlow based SDN. ONF succeeded spectacularly, with OpenFlow being the most popular protocol used for communication between control plane and data forwarding plane – becoming the de facto standard. However, this ONF campaign led to many misunderstanding that OpenFlow equals SDN.

Despite existing software based switching solutions allowing research into new methods and networking protocols, most do not provide the sufficient computational performance and/or port densities for large scale experiments.

The simplest of examples are many open software based implementations of routing or switching protocols running on general purpose computers with several network interfaces. These techniques can be categorized into the first group that is lacking performance wise, when compared to dedicated networking equipment. On the other end of the spectrum there are hardware based networking research solutions like the NetFPGA utilizing specialized FPGA card for line-rate processing of the traffic.

NetFPGA is used mainly in the academia and rapid prototyping because it is limited to only 4 ports per card.

As mentioned in [10] these are limiting factors for academic networking researchers, with OpenFlow being a compromise between low-performance generality and freedom of research solutions and closed and not very modifiable high-performance of network equipment from commercial vendors.

The OpenFlow protocol defines communication interface between control plane and forwarding plane devices and so it must be implemented by both sides. Since OpenFlow provides extremely granular control on per-flow basis, it enables the network to react to topology, application or user changes in real-time.

ONF white paper [9] notes that the classical network routing solutions today do not support the control on this level of the granularity.

image
Fig. 5 - Flowchart detailing packet handling in OpenFlow logical switch [11]

When a packet is received by OpenFlow enabled switch, it is handled in OpenFlow pipeline composed of one or more Flow Tables, each containing entries with rules and actions to be performed on the packet belonging to flow. If the match for the packet is not found in any Flow Table and the rule to send unknown packets to Controller is set-up, it is sent to the controller. Controller processes the packet and either drops the packet or establishes a new flow, by creating a new entry in Flow Table. The handling mechanism of a received packet inside the OpenFlow switch is charted in Fig. 5.

ForCES

Forwarding and Control Element Separation (ForCES) protocol [12] defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element.

ForCES addresses mainly the open API/protocol that provides a clear separation between control and forwarding plane.

The major strength of ForCES lies in its Forwarding Element Model that enables description of new forwarding plane functionality without changing the protocol between control and forwarding planes.

ForCES development aimed to split network device into distinct control and forwarding planes. The motivation behind this arose from the desire to build forwarding plane of network elements from flexible hardware components independently from control plane. This results in ForCES creating a new architecture for network devices, while OpenFlow aims to create new network architecture.

NETCONF

NETCONF is a network management protocol that provides mechanisms to remotely install, manipulate, and delete the configuration of network devices.

NETCONF protocol itself is divided into four layers with a set of base protocol operations using RPC (Remote Procedure Call) methods with XML-encoded message parameters.

One of the goals of NETCONF is to provide a programmatic interface to the device that closely follows the functionality of the device's native interface.

Although it was initially developed as a successor to SNMP and some of the CLI protocols for configuration of network elements, NETCONF capabilities can be used to create a form of a hybrid SDN. Moreover, NETCONF support is a requirement for network devices to be compatible with OF-CONFIG part of OpenFlow specification.

PCE-P

Path Computational Element (PCE) is an entity that computes paths on behalf of the nodes in the network that can find optimal paths for MPLS and GMPLS P2P and P2MP traffic engineered label switched paths (LSPs).

PCE then communicates this path to network nodes using PCE Communication Protocol. Thus, PCE can also be perceived as extending MPLS and GMPLS TE capabilities narrowing the gap between SDN and standard MPLS/GMPLS.

Although PCE in itself was not primarily developed as an SDN enabling technology, it can provide logically centralized management model for existing technologies with a few additional enhancement.

Interface to the Routing System

Interface to the Routing System (I2RS) is one of the more ambitious approaches to SDN that is still in early stages, being developed by IETF. The I2RS is a bidirectional programmatic interface for communication between routing system and applications - allowing network monitoring, reservation of resources and modification of the routing configuration. While I2RS is concerned with communication to and from the routing system, it is not intended to provide direct interfaces to forwarding plane, making use of existing mechanisms to distribute selected routes into forwarding plane.

Cisco ONE

Even though Cisco is a part of the Open Networking Foundation and is actively participating in the OpenFlow development, it is not the only SDN project it is working on. One of their proprietary alternatives is Open Network Environment (Cisco ONE), which is providing programmatic interface to directly control Cisco equipment. The key component of Cisco ONE is ONE Platform Kit (onePK) – developer kit including several platform APIs, enabling easy development of network applications using direct access to networking equipment through network abstraction layer.

Nuage

In April of 2013 Alcatel-Lucent launched spin-out company Nuage Networks tasked with creating a SDN solution built on its earlier Application Fluent Network but with freedom to utilize alternative fresh technologies. The product of this endeavor is Nuage Virtualized Service Platform, a software solution that focuses on the problem of the network virtualization in data centers and Cloud Service Providers (CSPs). Because Nuage VSP is implemented in software and uses VXLAN as the encapsulation across hypervisors, it is not dependent on a specific type or brand of TOR switches to function.