Northbound APIs for traffic engineering

Figure 1: Performance aware software defined networking

Previous articles on this blog have looked at use cases for performance aware software defined networking, including DDoS mitigation, load balancing large flows, traffic marking and packet brokers. Figure 1 shows the components of a traffic engineering SDN application. The sFlow-RT analytics engine receives a continuous stream of sFlow datagrams from network devices and converts them into actionable metrics, accessible through a REST API. SDN applications respond to changing network traffic by instructing a controller to adapt the network. In the diagram, an OpenFlow controller uses the OpenFlow protocol to communicate with network devices and modify their forwarding behavior.

Based on experiences with a variety of OpenFlow controllers, this article identifies areas where OpenFlow controllers could be improved in order to better support traffic engineering applications.

Firstly, it is worth understanding why external measurements need to be incorporated to build traffic engineering SDN applications. The following entry from the Floodlight FAQ page describes the limitations of OpenFlow for delivering measurements:

How can I measure link bandwidth and latency in Floodlight?
You can find the theoretical max link bandwidth of a port by making a features query through the REST API. Unfortunately finding the real link latency and bandwith is not as simple. OpenFlow, being a control-plane protocol has great difficult accurately determining data-plane measurements. The way to do this with OpenFlow entails making periodic flow stats requests to the switches on the network. The problem is that stats are never truly accurate. By the time they have been processed on the switch, sent over the network, and then processed by the controller they will be out of date. Data-plane measurements are best handled by third party applications.

Instrumentation to support the sFlow standard is embedded in the data plane of most switches, providing the real time visibility into link utilizations and large flows needed to support traffic engineering applications.

The first set of requirements arises from need to translate between the agent addresses and interface index numbers used to identify switches and ports in sFlow and the identifiers used in OpenFlow.

• Agent IP address ⟷ OpenFlow switch ID
• SNMP ifIndex ⟷ OpenFlow port ID

Note: The requirement for these mappings isn't unique to sFlow, incorporating measurements from other measurement protocols requires similar mappings (e.g. NetFlow, IPFIX, jFlow, NetStream, SNMP etc.)

In order to support the incorporation of external data, the OpenFlow controller Northbound APIs should allow control actions to be expressed using external identifiers, automatically translating them into OpenFlow identifiers.

Any device supporting OpenFlow and sFlow (or any of the other measurement protocols) will be able to map between the different port and device identifiers. Exposing these mappings to OpenFlow controllers can be easily accomplished through the device configuration protocol. For example, the Open vSwitch project recently added SNMP ifIndex numbers to the Interface table exposed by its configuration protocol (ovs-vsctl):

% ovs-vsctl --format json --columns name,ofport,ifindex list Interface
{"data":[["br2",65534,10],["eth0",1,2],["br1",65534,9],["vm",2,11],["gre0",1,0]],"headings":["name","ofport","ifindex"]}

Similar capabilities could be added to the Open Networking Foundation configuration protocol (OF-Config).

The second set of requirements is more challenging. Current generation OpenFlow controllers are limited in their ability to integrate requests from multiple applications into a unified set of OpenFlow commands. For example, traffic engineering applications would be much easer to develop if the OpenFlow controller exposed the following Northbound actions:

• mark flow at network edge (DSCP, priority etc.)
• drop flow at network edge
• rate limit flow at network edge
• steer flow at network core

The controller should support wild card matches on flow keys for these commands. In addition, the controller needs to accept commands from other APIs (authentication, access control etc.) and compose the potentially competing settings into OpenFlow rules that are realizable by the switch hardware and ensure that packets reach their destination.

It is often argued that OpenFlow controllers are becoming a commodity and that the value of SDN derives from applications running on top of the controller (e.g. Much Ado About SDN Controller Platforms).  However, a rich ecosystem of applications is only possible if the controller delivers the platform services needed to safely deploy multiple third party applications on production networks. An effective controller simplifies the task of application developers by factoring APIs and allowing each application to address a specific task and rely on the platform to combine applications to deliver a complete service. Customers benefit by being able to draw from a rich selection of pre-built applications in order to meet their specific requirements.

Today, controllers are alike because they are little more than OpenFlow device drivers supporting a single embedded SDN application (e.g. packet capture) that exports a RESTful Northbound API for configuration. The field is still wide open in the OpenFlow controller space, the first controller platform capable of supporting a rich ecosystem of commercial and open source SDN applications has the potential to quickly displace existing controllers, establish dominance in the market and move SDN into the mainstream.