Navigating Device Management and Control Interfaces in the Age of SDN

The proliferation of different types of device interfaces places a significant burden on application developers and equipment providers alike. One of the reasons for the rise of Software Defined Networking (SDN) is its promise to simplify management by providing a single point through which the entire network can be managed and administered. This raises the question whether this promise extends towards dramatic simplification of the device interface landscape as well, specifically, whether SDN can put an end to device interface proliferation and in the future a single management and control interface may be all that is required. Unfortunately, it turns out that this particular hope is unsubstantiated. Here is why.

The Promised SDN Land of Interface Simplification

Much has been made of the need to align the various interfaces through which networking devices can be managed and controlled. It has been difficult enough to just keep SNMP implementations consistent. Throw CLI, syslog, and Web Services into the mix, and the task becomes daunting indeed. One reason why different interfaces have to be supported has to do with customer preferences, of course. Chef is the new paradigm to support? Sure, we’ll add that. ReST is becoming en-vogue? We’ll support that too.

In the middle of all this, along comes SDN. “Don’t bother with individual devices and their legacy interfaces” is the siren call. “Use a controller to orchestrate the network instead” – a single point of control through which the network can be operated and maintained, an enticing value proposition indeed. Early SDN technology such as OpenFlow made a big splash and gained a lot of mind share this way. Rather than messing with the hodgepodge of existing interfaces, a single interface was introduced to control OpenFlow switches. Just support this one interface, or so the message went, and your equipment can join the New World of Software-Defined Networking, leaving the Old World of fragmented interfaces behind, much like early European settlers coming to America hoped for freedom and a better life, leaving behind constantly quarreling fiefdoms and many centuries of historical baggage.

Of course, not everything in life is quite as simple, and a more sophisticated picture is beginning to emerge.  While OpenFlow is useful, SDN encompasses a lot more and benefits from combining centralized algorithms with intelligence that is distributed across the network.  By combining both concepts correctly, SDN can indeed help unleash tremendous value that was previously very hard to achieve, from easier customization of network behavior to simplified integration of networks into IT environments, from greatly simplified and more robust management and enforcement of access policies to service level optimization through smarter feedback loops.  However, all of this means that at the same time, on the inside SDN solutions cannot be quite as simple any more.  Providing a system that is “simple” and “easy to use” does not necessarily mean that everything about this system is simple; to the contrary, a great deal of internal complexity may be required to make the system appear simple to the outside.

The End of Device Interface Proliferation?

Nevertheless, in conjunction with the emergence of SDN and network controllers, the question comes up whether having to support only a single interface between device and controller would in principle be sufficient (Note, we are not considering the interface northbound of the controller). Unfortunately, the answer is that this is unlikely, just as it is unlikely that there will be single controller as articulated here.

As it turns out, there are inherent technical, not just historical or political reasons for this. Those reasons have to do with the fact that different control applications have different needs which impose different requirements on interfaces. In some cases, these requirements conflict with one another. For example:

• Some applications that are geared towards fulfillment and need to orchestrate a series of configuration operations across multiple devices in order to configure a service. As a result, interactions between controllers and devices are typically of a transaction-oriented nature, largely request – response based.  Reliability may be more important than performance – applications need to know if a configuration request “took” and be able to easily undo operations in case errors are encountered, even if the operation takes tenths of seconds instead of microseconds.

• Other applications need to monitor device state and are oriented towards assuring proper service operation. Interactions are typically of an interrupt-driven nature, largely based on events. Here, performance and the minimization of delay is of utmost importance. The controller needs to be able to react immediately, while it is sufficient for the amount of data that needs to be transferred to remain small.
• Finally, some applications may require crunching large volumes of telemetry data to detect suspected intrusion detections and mine traffic data for shifting traffic patterns. To convey this data, scale and minimized overhead are the most important requirements here, while reliability is less of a  priority – it may be acceptable if occasionally a data item gets lost.

As a result, different interfaces need to make different tradeoffs with regards to which purpose they serve and what aspects they optimize (delay? robustness? throughput). They need to support different interaction patterns. Furthermore, optimizations may incur an additional footprint on the device, which may or may not be acceptable depending on the deployment scenario. To the earlier examples:

• An interface used for transaction-based applications needs to support request/response interaction patterns. It may provide additional services to lock data from other changes, to roll back effects of earlier requests when needed, and to help address the problem of configuration drift, in which applications need to be able to deal with configuration changes that are introduced from other sources. This may involve additional steps to validate requests or to persist state before changes are made, at the expense of performance.
• Interfaces used to let devices emit unsolicited events may differ on properties such as reliability. Some applications may require special provisions for reliability, involving features such as the ability to support on-demand event replay, at the expense of keeping state at the device and higher overhead. As events can be of very different nature, data transferred may include additional meta-data that can be used to properly interpret the event contents.
• Interfaces used for to stream bulk data with minimal overhead, on the other hand, will tend to rely on extremely efficient encoding schemes. In order to eliminate the need to persist or transcode data, features such as retransmission of earlier data or self-describing data may not be supported.

In addition, interfaces may differ on the interaction paradigm they need to support.  For example, who initiates an interaction – the controller or the device? One category of applications may rely on the controller to observe the network, then act, while another category may rely on the device to observe which then requests the controller to act. Interfaces in such cases need to support interactions in which the device triggers the controller, not the other way round. Examples of the latter include applications in which the occurrence of a certain flow observed at the device triggers a policy decision to be made by the controller. The services that need to be supported by the interface differ in each case: rather than a controller “pushing” a request to the device, it is the device “pulling” a decision from the controller.

Further variations in what may be required from interfaces are possible. The discussion so far assumed that interactions between devices and controllers occur point-to-point. This need not always be true – they might, for example, be point to multipoint, as in the in case of a controller that wants to install the same policy on a group of multiple devices and would like to direct the same request at any device meeting a certain criteria. This may involve support for publish-subscribe or multicast capabilities.  Additional interface capabilities may be required if a single request can result in multiple responses.

Model-driven Interfaces are the Key

For scenarios that involve SDN applications with a very specific, focused, narrow purpose, having a single and effective interface is certainly feasible. However, chances are that in such scenarios, other applications (and controllers, and interfaces) will be needed before long. For all these reasons stated above, assuming that a single, simple interface between SDN controller and devices will be sufficient for generalized SDN controller applications is nothing but a pipe dream. Heck, it turns out that even OpenFlow  has to rely on multiple interfaces! One interface is needed to deal with flow table manipulation and another to configure the OpenFlow switches themselves.

The good news is that the need to support different interfaces does not mean that different interfaces can’t still be aligned. The key here is to utilize common data models that are shared between interfaces. In whichever other ways they differ, each interface provides a way to interact with the same underlying device, resources, and state that applications need to access. In other words, each interface provides merely a view of the same underlying data. Whether an application needs to change the configuration of a port on a line card, whether it wants to retrieve a piece of statistics about this port, or whether it wants to be notified of a change in the port’s health status, it is always the same port.

Accordingly, the key to alignment lies in basing different interfaces on the same underlying data model and making the interface model-driven. By basing the view that each interface provides on the same underlying data model, interfaces become aligned. Data that is exchanged across the interface becomes easy to correlate for applications and additional interfaces are easy to learn for users and application developers (as focus is on the services and methods of access, not the data itself).

Through the use of model-driven tool chains, interface implementations can in large part simply be generated from the same data model, making it easy to introduce additional interfaces when needed. Model-driven interfaces allow interfaces to proliferate further, but suddenly, this proliferation is not a scary prospect any more. To the contrary, it sets Software Defined Networks free: free to optimize interaction patterns between controllers and network devices, free from worry about leaving crucial functionality from legacy interfaces behind, and free to customize interfaces to the needs of applications and customers in ways that were not possible before.

Which technology should be used to define data models?  YANG is an excellent choice here, but this is a topic for another blog post.