So far in this series on Software Defined Networks (SDNs), I’ve discussed a basic taxonomy that can be used to classify SDNs, some of the challenges with actually building a control plane, and examined several SDN and SDN-like solutions through the lens of the southbound interface. In order to help you understand the problem space better, this post will consider the CAP theorem in relation to the concept of an SDN.
The original Path Computation Element Protocol (PCEP) work dates from the early 2000’s, with the first IETF RFC (4655) being made informational in 2006—which means PCEP predates the time when SDNs were “cool.” PCEP was originally, because of the increasingly complex nature of computing Traffic Engineering (TE) paths through (primarily), Service Provider (SP) networks. Three specific developments drove the design, standardization, and deployment of PCEP—
Topics: Enhancing Network Efficiency
The last post on the topic of interface to the routing system (I2RS) discussed use cases; this one will provide an overview of the I2RS architecture, and then consider some challenges in the neighborhood of I2RS. The architecture of I2RS is considered in the illustration below.
Through this (probably far too long) series on SDNs, we have looked at BGP, Fibbing, and Openflow. BGP and Fibbing would be described as augmented control planes; the distributed control plane is not replaced, but rather augmented with a controller that modifies the best path decisions of the control plane by interacting with the control itself in a somewhat “native” way.
Openflow is the “father of software defined networks” in the minds of many engineers. To understand Openflow, however, you cannot just look at the protocol itself; rather you must go back to the beginning, in the mists of old networking.
The last post on the topic of SDNs discussed BGP as a southbound interface to control policy. This form of SDN was once common in hyperscale data centers (though not as common as it once was). In our pursuit of out of the way (and hence interestingly different) forms of SDNs (hopefully this series will help you understand the scope and meaning of the concept of SDNs by examining both common and uncommon cases), it’s time to look at another unusual form of policy injection—Fibbing. In fibbing, a centralized controller engineers traffic flow in a link state network by interacting with the control plane directly, rather than interacting with the forwarding plane or the RIB.
BGP as an SDN? Clearly this must be some sort of mistake! Or maybe not. Consider, for a moment, the following network:
Topics: Enhancing Network Efficiency
In the last post on SDNs, I spent a little time discussing just a bare minimum of some internal router architecture—specifically the difference between the RIB and the FIB, and thinking a little about management. In this post, I want to add one more dividing point to the mix, and then start thinking about how we can classify various “software defined” solutions in a way that makes more sense out of the field of options.
In my last blog post, I considered two questions: what does a control plane really do, and what does a forwarding device really look like? Before continuing to our final destination—a better understanding of what an SDN is, and what the fuss is all about—we need to back up to the first post in this series, and reexamine the question of centralization and decentralization.
To really understand Software Defined Networks (SDNs), we need to start from a place far different than the top of the current hype cycle. Instead, where we need to start is thinking about what a control plane actually does in a packet switched network. There seem to be just a few specific things involved in what a control plane does: