Standardization of SDN solutions ... Are we there yet?
on 08-03-201208:10 AM - last edited on 10-28-201311:16 PM by bcm1
I thought I’d take an opportunity to write about and hopefully update folks on some recent happenings in the Software Defined Networking (SDN) space as it relates to standards bodies, such as the Internet Engineering Task Force (IETF) and the Open Networking Foundation (ONF).
Refresher on SDN
Software Defined Networking is all the buzz these days, especially here in Silicon Valley. I have personally been following it for about 2 years now and the buzz and hype has grown exponentially over the last year and even more so over the last 3-6 months or so. For new readers of these blogs that desire a quick refresher on SDN, please go here.
The modern history of SDN can be traced back to the introduction of the OpenFlow protocol. For those familiar with MPLS technologies, the history of MPLS can be traced back to the 1990’s with the invention of a concept called “cut-through routing” or “IP switching”. This concept and technology then became more commonly known as “tag switching”, and then ultimately, MPLS as we know it. Who remembers Ipsilon Networks? Anyway, look at where we are now with massively deployed global MPLS networks and all the network service offerings based on MPLS technologies; from what started as a technology to improve the performance of IP routers! It makes one wonder where SDN will be in 2 years … or 5 years.
So, what began with the introduction of the simple OpenFlow protocol has now turned into an industry in and of itself. But to be clear, SDN does not require OpenFlow. As previously stated in these blogs, OpenFlow is a key enabler of SDN but is not an explicit pre-requisite. More on this later.
While there are many potential use cases for SDN, from a high-level, there are two broad use cases worth discussing for SDN: Data Center (DC) Network Virtualization and Wide Area Network (WAN) Optimization. While one could argue that there are many other relevant use cases for SDN, I would like to keep this discussion simple and lump them into those two broad categories.
DC Network Virtualization Use Case: In a grossly simplified explanation, within the DC networking environment there is a need to connect physical and virtual servers at Layer-2. These resources can reside within the same DC or they can be geo-graphically dispersed and reside in different DCs (eg. “any rack, any where”). The emerging SDN solution for this connectivity involves virtualizing the network infrastructure by creating L2-over-L3 overlay networks to connect these resources; basically, abstract logical topologies that resides on the physical networking topology, but are simple to provision, manage and scale.
The industry’s move toward cloud networking is directly related to the DC virtualization use case. Cloud networking brings new challenges to DC networks in terms of dynamic and mobile workloads, network elasticity, east/west traffic patterns and rapid network and service provisioning. However, I’d like to keep this blog simple and more narrowly focused on the DC overlay problem space.
WAN Optimization SDN Use Case: In the WAN, there is a desire to have more control over how packet forwarding is traffic-engineered. In other words, a provider could optimize how traffic is forwarded over their network infrastructure with the goal of reducing cost. This manipulation of packet forwarding would be done in a centrally managed, programmatic fashion. New network services could even be created and offered based on these new capabilities. This type of capability could be equally desirable in Campus networks. So, the WAN optimization use case involves directing or programming L2, L3, or even MPLS flows in a more efficient and centrally managed manner.
Both of these broad use cases require a SDN controller where some sort of “southbound API” implements these functions into the networking infrastructure. This southbound API is often assumed to be the OpenFlow protocol or some variant. There is also a “northbound API” from the controller which talks to the SDN layer, where the real intelligence resides within the orchestration layer.
The ONF is responsible for the standards development of the OpenFlow protocol. The latest specification that is released is OF v1.3. The ONF is actively engaged in extending the functionality of the OF protocol, so stay tuned in to their website for new specifications of OF. The evolution of OF is directly correlated to the evolution of the SDN problem space. However, the SDN problem space is now evolving very rapidly on its own and is no longer directly tied to the development timelines of the OF protocol. The ONF continues to drive awareness and architecture development around the SDN problem space, including organizing and hosting industry events such as the Open Networking Summit and the industry’s first OF interoperability Plug Fest. The ONF produced a very technical OF interoperability white paper based on the Plug Fest event that is worth a read.
Along with the standards development of the OF protocol, the ONF is also driving the standards of related protocols, such as the OpenFlow Management and Configuration Protocol (OF-Config). OF-config is a companion protocol to OF and its purpose is to allow additional configuration of OF devices; in addition to pushing forwarding state into these devices which is what OF does. For example, enabling or disabling a port on an OF switch.
There are even organized working groups within the ONF that are focused on solving specific problems related to the OF protocol or the SDN problem space in general. These working groups are each focused on a specific area of OF and/or SDN. For example, while the Extensibility WG produces standards for the OF protocol, the Hybrid WG is working on exploring and documenting the requirements for a hybrid programmable forwarding plane (HPFP). Very interesting stuff. However, while the ONF is where the OF protocol and the SDN solution space were spawned, it is no longer the only standards body driving SDN solutions.
As stated on the Internet Engineering Task Force website; “The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.” The end goal of a specific IETF activity is to produce a Request for Comments (RFC) standard, which defines a specific standard or protocol that is intended to be used in IP networking . An RFC facilitates an industry standard, multi-vendor and interoperable implementation of an Internet related protocol and solution. The mantra of the IETF used to be “rough consensus and running code”, but as this standards body has evolved, oftentimes there are RFCs approved that do not have a broad basis of industry support. But I digress …
The IETF has several working group efforts that relate to both of the SDN use cases I previously mentioned. It is interesting to note that some of these efforts have been underway for many years in the WAN optimization area but only fairly recently has the IETF been involved in addressing some of the challenges in the DC overlay use case. More specifically, the activity within the IETF in this particular use case has dramatically accelerated in terms of Internet Drafts (IDs) and mailing list discussion over the last 6 months or so. This is no coincidence. In terms of new industry-wide networking challenges, much effort is being put into the Data Center area of networking, versus the Campus or WAN area of networking. Most of today’s innovation in networking is happening in the DC space. What I find particularly interesting is that while new technologies and protocols (such as VXLAN or NVGRE) are being developed to solve some of the emerging DC challenges in terms of DC growth, scale and Virtual Machine (VM) mobility, there is also quite a bit of recent movement in the IETF towards adapting some existing technologies and protocols to solve some of these same problems. It will be very interesting to see how this flushes out over the next 1-2 years.
In terms of general SDN applicability to the IETF, there are some problem statements being developed that are worth perusing. A few are here , here, and here.
A few interesting IETF activities in the WAN optimization space are Application Layer Traffic Optimization (ALTO) and Path Computation Element (PCE). While these are not SDN solutions per say, they are intending to solve some of the same SDN WAN optimization use cases. Both are worth following in terms of the SDN problem space; however, the PCE solution appears to be more applicable to the current use case for WAN optimization. PCE is geared towards intra-domain traffic-engineering while ALTO is geared more towards inter-domain traffic-engineering.
A very interesting, and somewhat new, area of IETF activity in the DC overlay space is the Network Virtualization Overlays (NVO3) WG. This WG was started within the last 6 months or so and has many Internet Drafts, ideas and discussions around the DC overlay/SDN solution space. The mailing list is also quite active, since this is a major area of innovation in networking. There are also many discussions on how existing protocols and solutions can be re-used, such as BGP and MPLS, to solve some of the DC overlay problems. As a sample of some of the ideas in this area, take a look at this, this and this.
There are even some non-working group mailing lists being created to discuss problem statements and possible solutions in the SDN space. Examples are the Software Driven Network Protocol (SDNP) and the Interface to the Internet Routing System (IRS) lists; and of note, the IRS was just created in the last few weeks. Here is the problem statement. The IRS activity is interesting in that it appears to be as focused on extracting information and state from the network as it is in implementing state into the network. The subject of extracting information from networks, or unlocking the intelligence that is inherent in networks, is one area of SDN that I believe needs to be addressed more broadly. Most of the activity in the SDN problem space seems to be focused on pushing state into networks. However, to fully utilize the network assets there needs to be a better real-time understanding of what is happening in the network. This type of two-way information exchange makes sense to me anyway. But that’s a subject for another blog.
Lastly as far as IETF activity that relates to SDN, I’d like to point out some work that has been ongoing for many years that bears quite a bit of resemblance to the goals of OpenFlow. There is a Forwarding and Control Element Separation (FORCES) WG that has been working on standardizing interfaces, mechanisms and protocols with the goal of separating the control plane from the forwarding plane of IP routers. As you may know, purists in the OpenFlow space have a desire to move the control plane of routers to a centrally managed element or server. While FORCES isn’t envisioning the exact same result, it does bear similarities to the goals of OpenFlow purists.
It is important for me to point out that the IETF IDs that I reference here are merely a sample of what is going on within the IETF that relates to SDN; so, I am not pretending that this blog covers this activity within IETF in a comprehensive manner. But I think I have mentioned most of the relevant ones.
The Internet Research Task Force "promotes research of importance to the evolution of the Internet by creating focused, long-term Research Groups working on topics related to Internet protocols, applications, architecture and technology." This effort is related to the IETF but is research oriented rather than standards oriented. But there is an important research group in the IRTF that is worth mentioning; this is the recently proposed Software Defined Networking Research Group (SDNRG). This research group is worth following to see what types of problems they will address and what the proposed solutions to those problems will be. Here is one relevant presentation being discussed on the "southbound API".
So, as you can see the IETF is becoming quite active in the SDN problem space. SDN related standards development is no longer being driven solely by the ONF. As the IETF mailing list and working group activity is increasing exponentially in this problem space, it is evident that the IETF “brain-trust” is clearly shifting towards solving problems in this space. Some of these ideas will die and some will evolve into complete and relevant RFCs.
So, as you can clearly see, the scope of SDN is expanding broadly across the industry and in a rapid fashion. Both the ONF and the IETF are actively involved in creating requirements and solutions for the SDN problem space. Since IETF 84 is being held in Vancouver as I write this, my fellow Brocade colleagues who are attending may have some relevant updates to bring back. So, stay tuned here for updates or comments to this blog!