|Figure 1: Software Defined Networking architecture|
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:
- 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.
- 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.
- 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.
|Figure 2: NetFlow/IPFIX and sFlow|
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Scalable The sFlow architecture scales better than flow-based architectures, see Superlinear.
- Multi-Vendor The sFlow standard is supported by most switch vendors, including virtually all OpenFlow capable switches.
- Merchant Silicon Hardware support for sFlow is widely implemented in merchant silicon.