Daily Archives: June 29, 2012

SDN Focus Turns to Infrastructure

At this year’s SIGCOMM conference in Helsinki, Finland, a workshop called Hot Topics in Software-Defined Networking (HotSDN) will be held on August 13.  A number of papers will be presented as part of HotSDN’s technical program, but one has been written as a “call to arms for the SDN community.”

The paper is called: “Fabric: A Retrospective on Evolving SDN.” Its authors are Martin Casado, CTO of Nicira Networks; Teemu Koponen of the International Computer Science Institute (ICSI); Scott Shenker, a co-founder of Nicira Networks (along with Casado) and also a professor of computer science at University of California, Berkeley; and Amin Tootoonchian, a PhD candidate at the University of Toronto and a visiting researcher at ICSI.

SDN Fabrics

We’ll get to their definition of fabric soon enough, but let’s set the stage properly by explaining at the outset that the paper discusses SDN’s shortcomings and proposes “how they can be overcome by adopting the insight underlying MPLS,” which is seen as helping to facilitate an era of simple network hardware and flexible network control.

In the paper’s introductory section, the authors contend that “current networks are too expensive, too complicated to manage, too prone to vendor lock-in, and too hard to change. “ They write that the SDN community has done considerable research on network architecture, but not as much on network infrastructure, an omission that they then attempt to rectify.

Network infrastructure, the paper’s authors contend, has two components: the underlying hardware, and the software that controls the overall behavior of the network. Ideally, they write, hardware should be simple, vendor-neutral, and future-proof, while the control plane should be flexible.

Infrastructure Inadequacies

As far as the authors are concerned, today’s network infrastructure doesn’t satisfy any of those criteria, with “the inadequacies in these infrastructural aspects . . .  probably more problematic than the Internet’s architectural deficiencies.” The deficiencies cannot be overcome through today’s SDN alone, but a better SDN can be built by, as mentioned above, “leveraging the insights underlying MPLS.”

And that’s where network fabrics enter the picture. The authors define a network fabric as “a contiguous and coherently controlled portion of the network infrastructure, and do not limit its meaning to current commercial fabric offerings.” Later, they refer to a network fabric as “a collection of forwarding elements whose primary purpose is packet transport. Under this definition, a network fabric does not provide more complex network services such as filtering or isolation.”

Filtering, isolation, policy, and other network services will be handled in software at the network edge, while the fabric will serve primarily as a “fast and cheap” interconnect. The authors contend that we can’t reach that objective with today’s SDN and OpenFlow.

OpenFlow’s Failings

They write that OpenFlow’s inability to “distinguish between the Host-Network interface (how hosts inform the network of requirements) and the Packet-Switch interface (how a packet identifies itself to a switch) has resulted in three problems, the first of which is that OpenFlow, in its current form, does not “fulfill the promise of simplified hardware” because the protocol requires switch hardware to support lookups of hundreds of bits.

The second problem relates to flexibility. As host requirements evolve, the paper’s authors anticipate “increased generality in the Host-Network interface,” which will mean increasing the generality in . . . “matching allowed and the actions supported” on any every switch supported by OpenFlow. The authors are concerned that “needing functionality to be present on every switch will bias the decision towards a more limited feature set, reducing OpenFlow’s generality.”

The third problem, similar to the second, is that the current implementation of OpenFlow “couples host requirements to the network core behavior.” Consequently, if there is a change in external network protocols (such as a transition from IPv4 to IPv6), the change in packet matching would necessarily extend into the network core.

Toward a New Infrastructure

Accordingly, the authors propose a network fabric that borrows heavily from MPLS, with its labels and encapsulation, and that also benefits from proposed modifications to the SDN model and to OpenFlow itself. What we get is a model that includes a network fabric as “architectural building block” within SDN. A diagram illustrating this SDN model shows a source host connecting to an ingress edge switch, which then applies MPLS-like label-based forwarding within the “fabric elements.” On the other side of the fabric, an egress edge switch ensures that packets are delivered to the destination host. The ingress and egress edge switches answer to an “edge controller,” while a “fabric controller” controls the fabric elements.

The key properties associated with the SDN fabric are separation of forwarding and separation of control. Separation of forwarding is intended to simplify the fabric forwarding elements, but also to “allow for independent evolution of fabric and edge.” As for separation of control, I quote from the paper:

While there are multiple reasons to keep the fabric and the edge’s control planes separate, the one we would like to focus on is that they are solving two different problems. The fabric is responsible for packet transport across the network, while the edge is responsible for providing more semantically rich services such as network security, isolation, and mobility. Separating the control planes allows them each to evolve separately, focusing on the specifics of the problem. Indeed, a good fabric should be able to support any number of intelligent edges (even concurrently) and vice versa.

Two OpenFlows?

As the authors then write, “if the fabric interfaces are clearly defined and standardized, then fabrics offer vendor independence and . . . limiting the function of the fabric to forwarding enables simpler switch implementations.”

The paper goes on to address the fabric-service model, fabric path setup, addressing and forwarding in the fabric, and how the edge context is mapped to the fabric (the options are address translation and encapsulation, which is the authors’ favored mechanism.)

To conclude, the authors look at fabric implications, one of which involves proposed changes to OpenFlow. The authors prescribe an “edge” version of OpenFlow, more general than the current manifestation of the protocol, and a “core” version of OpenFlow that is similar to MPLS forwarding. The authors say the current OpenFlow is an “unhappy medium,” insufficiently general for the edge and not simple enough for the core. The authors say the generic “edge version of OpenFlow should aggressively adopt the assumption that it will be processed in software, and be designed with that freedom in mind.”

Refinements to the Model

In the final analysis, the authors believe their proposal to address infrastructure as well as architecture will result in an SDN model “where the edge processing is done in software and the core in simple (network) hardware,” the latter of which would deliver the joint benefits of reduced costs and “vendor neutrality. “

The paper essentially proposes a refinement to both OpenFlow and to the SDN architectural model. We might call it SDN 2.0, though that might seem a little glib and presumptuous (at least on my part). Regardless of what we call it, it is evident that certain elements in the vanguard of the SDN community continue to work hard to deliver a new type of cloud-era networking that delivers software-based services running over a brawny but relatively simple network infrastructure.

How will the broader SDN community and established vendors in network infrastructure respond? We won’t have to wait long to find out.