Software defined networking

Figure 1: Software Defined Networking architecture

The elements of the Software Defined Networking (SDN) architecture are shown in Figure 1. The Data Plane comprises switches connected together to form a network. However, instead of relying on proprietary software running on each switch to control its forwarding behavior, switches in a SDN architecture are controlled by a Network OS (NOS) that interacts with the switches to provide an abstract model of the network topology to Applications running on the NOS. Applications can adapt the network behavior to suite specialized requirements, for example, providing network virtualization services that allow multiple logical networks to share a single physical network - similar to the way in which a hypervisor allows multiple virtual machines to share a single physical machine.

Note: While to diagram shows the NOS as a single logical entity, it is likely to be implemented as a distributed cluster of controllers in order to provide scalability and fault tolerance.

Open APIs for programatic access to the switches is an essential pre-requisite to building a software defined network:

1. Forwarding The OpenFlow protocol was originally developed so that academic researchers could experiment with external control of switch packet forwarding. OpenFlow quickly gained support, leading to the formation of the Open Networking Foundation (ONF) to develop and promote the OpenFlow standard.
2. Configuration  It was quickly realized that OpenFlow alone isn't sufficient - a configuration protocol is needed to assign switches to controllers, configure port settings and provision queues. Recently, the Open Networking Foundation released the initial OF-Config version 1.0 specification for configuring OpenFlow switches. OF-Config is defined as an extension of the NETCONF protocol, which provides an programmatic XML/RPC API that is well suited to SDN.
3. Visibility Current efforts in the SDN community are focused on provisioning of network services.  Going beyond merely providing connectivity to creating a NOS that is aware of network performance requires an API providing visibility into switch traffic. A performance aware NOS allows applications to manage resource allocation, balance loads and ensure quality of service.

The rest of this article examines different approaches to monitoring switch performance and their strengths and weaknesses within the context of software defined networking.

Figure 2: NetFlow/IPFIX and sFlow

The most common APIs for monitoring switch performance, NetFlow/IPFIX and sFlow, are shown in Figure 2:

1. NetFlow/IPFIX Cisco NetFlow and IPFIX (the IETF standard based on NetFlow) define a protocol for exporting flow records. A flow record summarizes a set of packets that share common atributes - for example, a typical flow record includes ingress interface, source IP address, destination IP address, IP protocol, source TCP/UDP port, destination TCP/UDP port, IP ToS, start time, end time, packet count and byte count. Figure 2 shows the steps performed by the switch in order to construct flow records. First the stream of packets is likely to be sampled (particularly in high-speed switches). Next, the sampled packet header is decoded to extract key fields. A hash function is computed over the keys in order to look up the flow record in the flow cache. If an existing record is found, its values are updated, otherwise a record is created for the new flow. Records are flushed from the cache based on protocol information (e.g. if a FIN flag is seen in a TCP packet), a timeout, inactivity, or when the cache is full. The flushed records are finally sent to the traffic analysis application.
2. sFlow With sFlow monitoring, the decode, hash, flow cache and flush functionality are no longer implemented on the switch. Instead, sampled packet headers are sent to the traffic analysis application which decodes the packets and aggregates the data. In addition, sFlow provides a polling function, periodically sending standard interface counters to the traffic analysis applications, eliminating the need for SNMP polling, see Link utilization.

Given the differences between the two technologies, the following attributes highlight features of sFlow that make it an attractive option for providing visibility in SDN environments:

1. Software Defined With sFlow, decoding and analysis of network traffic is performed by external software, allowing the NOS to tailor measurements for consistency with its internal network model. In contrast, the decode, hash, flush, pipeline needed to generate flow records is typically implemented in hardware. Hardware-based measurements are inflexible, requiring switch vendor hardware/firmare upgrades to implement new measurements.  Hardware differences mean that measurements are inconsistent between vendors, or even between different products from the same vendor.
2. Lightweight The sFlow architecture minimized resources consumed on the switch. In contrast, flow-based measurements consumes scarce TCAM resources that would be better used to increase the number of packet forwarding entries.
3. Stateless The sFlow architecture is stateless, measurements are not stored on the switch, but immediately exported to the traffic analyzer (NOS) where they can be acted on. Flow-based measurements rely on a stateful flow cache that delays export, making the data less suitable for implementing dynamic control functionality in the NOS, see Delay and stability. 
4. Easy to configure Very few parameters required to configure sFlow monitoring: the address of the traffic analyzer, a counter polling interval and a packet sampling rate. Flow-based technologies require additional configuration parameters: identifying packet attributes to decode, specifying how packet attributes and values should be used to update the flow cache, flow cache size, flow cache timeouts, etc. Operational complexity acts as a significant barrier to large scale deployment, see  Complexity kills.
5. Scalable The sFlow architecture scales better than flow-based architectures, see Superlinear. 
6. Multi-Vendor The sFlow standard is supported by most switch vendors, including virtually all OpenFlow capable switches. 
7. Merchant Silicon Hardware support for sFlow is widely implemented in merchant silicon.

In the data center, SDN is being used as a component of cloud orchestration systems like OpenStack and CloudStack that manage network, server and application resources in order to deliver Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).  The sFlow standard supports cloud orchestration by providing unified, cloud-scale, visibility that links network, system and application performance in a single integrated system.