Modern SDN Stack
The SDN paradigm began with the development of the NOX controller and the OpenFlow forwarding specification. NOX's programming model was based on OpenFlow messages; each incoming OpenFlow message was a NOX event. Thus, "applications" (that is, control programs written on top of NOX) must deal with each of these OpenFlow messages. There has been some research on how to refine this programming model (e.g., Frenetic, Nettle), but the research community is still largely confined to this basic approach.
However, it is clear (as exemplified by the ONIX controller) that there must be a better approach. The goal of this project is to develop a new model that is appropriate for modern SDN control stacks. This research effort involves three separate thrusts: abstractions, distribution, and debugging.
Abstractions
The first step in this process involves building the controller around a set of principled abstractions. We believe there are three key abstractions that should be core to a modern SDN stack.
- Global network view. As discussed above, NOX (and many other subsequent controllers) are built about OpenFlow messages as their basic events. A far more principled approach would be to provide control programs with a global network view, and have these control programs compute their desired configuration as a function of this view. This greatly simplifies the task of control programs: they need not understand OpenFlow, or any other low-level protocol, and can focus solely on changes in the network view. Moreover, this approach ensures that control programs are well tuned to the "eventual consistency" model that most controllers adopt (the resulting configuration is a function only of the eventual view, and does not depend on the sequence of events that led to that view). This is similar to the approach taken in the ONIX controller.
- Forwarding. OpenFlow has gained substantial traction as the interface to each switch's forwarding path. However, the SDN stack should not use OpenFlow as the only interface to the forwarding infrastructure. In order to ease the burden on applications (so they don't have to configure each individual switch), we believe that modern SDN stacks should include a "fabric" forwarding interface, which provides an end-to-end forwarding model. OpenFlow-like forwarding control is supported only at the edge of the fabric, but applications are shielded from the details of the fabric internals. This allows fabric vendors to incorporate a variety of innovations (such as rapid failure recovery) that are not easily supported in the canonical OpenFlow model.
- Specification. To further ease the burden on application writers, the SDN stack should allow applications to provide only the minimal amount of information required to specify their desires. To this end, the SDN stack should expose an "abstract" view of the network to applications, rather than a topologically faithful view of the network. For instance, in a multitenant network, the specification abstraction should provide each tenant's application with a view of their abstract network.
Distribution
In order to achieve the necessary scale and resilience, the SDN stack must be distributed. The key here is to understand more fully the consistency requirements at each level of the SDN stack and employ the appropriate coordination techniques to provide that level of consistency. The goal is to enable applications to remain ignorant of this distribution, but to provide simple "design patterns" that enable them to tolerate transient inconsistencies that arise.
Debugging
The third step in developing a modern controller is providing a tool to validate the SDN stack. We are developing a debugger for this stack that detects when physical switch configurations produce behaviors that are inconsistent with the high-level configurations specified by the control program. This requires two basic pieces:
- Correspondence Checker. The debugger verifies that the configurations at different levels in the SDN stack are all consistent with the behavior specified by the control program.
- Test Harness. this allows users to investigate how the system responds to different network event streams. Moreover, this enables the debugger to detect whether the inconsistencies that are found by the Correspondence Checker are transient or long-lived, and whether they result in harmful loops or deadends.
This modern SDN stack will be built on the POX controller (now under active development), and (once it is further along) will become part of the ONRC prototyping efforts.