As the trends of software-defined networking (SDN) and network functions virtualization (NFV) continue to evolve and converge to form a complete framework, the picture of what’s ahead becomes clearer. Despite the fact that SDN and NFV were kick-started using simplistic ideas — like having one controller replace distributed IP routing, or “just porting” high network functions from proprietary SMPs to PCs — the momentum behind these former buzzwords is steadily increasing.
This is despite the fact that SDN/NFV notions are now understood to be much more involved. By looking at some of the deeper underlying principles at play here, we can gain a better understanding of the momentum behind these new technologies. Additionally, by taking a look at how tech giants Google and Apple were able to add hundreds of thousands of features to millions of phones in the past five years, we can gain some insight in to how similar principles are at work to fuel the programmability and extensibility of SDN and NFV.
At a high-level, the way both iOS and Android managed to pull off the aforementioned monumental feature-phone task has a lot to do with the way they redefined mobile context management. Unlike the programs in computers, apps on a smart-phone operating system (OS) that are currently in the context-switched front cannot be disrupted by back-end processes (daemons) that belong to some other app. This separation allows for a vast amount of developers or independent software vendors (ISV) to introduce apps without the need for joint lock-step regression testing, and without stepping on each other’s unique user experiences — the kind of protection infrastructure developers look for when unbundling functions from routing boxes to virtual machines.
In mobile apps, that old heavy background process load that used to cause interference and an annoying lack of responsiveness has now been relocated to the cloud, where, based on the context of the user’s app/phone connection, backend processes are managing anything from Angry Birds’ high scores to synchronizing calendars and storing music. The ability to manage all of that in a shared and unfragmented, yet completely separated, manner is another highly valued quality for unbundling network high-function processing out of routing boxes and into computer clusters.
The Concentric Rings of Context
Taking a closer look at cloud providers and carrier networking infrastructure, we notice a range of methods when it comes to managing state and context. Just like in the case of the mobile consumer, these approaches are evolving and are redefined within the scope of SDN/NFV to allow for better agility/performance and concurrent development with independent software vendors.
For example, in data centers of Internet giants like Facebook, we can see miles of computer racks devoted to managing user-application context: who searches what index, or who posted what to which friends’ walls. Whereas in a typical core router, we see a minimalistic “context-free” design. The goal of this design can be summarized by the phrase “get rid of and forget all about the packet”. We have now reached a point where these traditional extremes are being challenged and redefined by SDN/NFV, and context management segmentation is much like the case of the introduction of smartphones.
The architecture that emerges for handling these evolved context (re) segmentations resembles that of concentric rings, where each one is defined mainly by what portion of the overall end-to-end application state is held in it. For example, at the innermost context circle, we still find the high-density IP core switch or core router. This base underlay has a minimal, localized “need-to-know” state that allows it to compress terabytes of forwarding into small, dense boxes. On the other hand, at the outermost rings, we find the cloud application with a large number of data-center racks dedicated to map-reducing user context per operation-application. In between, we define the SDN/NFV overlays and examine what they’re about from a context management viewpoint.
The NFV overlay is all about the way carriers and other cloud service providers insert middle functions between fixed/mobile customers and the Internet applications. These user connections drive public network roads, so there is quite a bit of functionality regulating and policing their usage. Clearly not all virtualized network functions are made equal! Some virtual network functions (VNFs), like IP telephony, form a full-fledged peer-to-peer talk application and are more than just a middle box. Additionally, if you can’t reach someone on the phone and are directed to their voicemail, this would be a complete storage, indexing, and transcoding primary application. Other functions offer middle-box capabilities from implementing critical subscriber mobility, through light-touch header adjustments, to a very compute-like, intensive, full-cached web proxy.
In any case, these functions maintain enough context to perform a range of actions between the core carrier network and the Internet providers. These functions can now be delivered using highly protected virtual machines, so they can run on shared standard hardware with minimal interference. This ensures concurrent development when transforming the network infrastructure world into an “app-for-that” mode and dynamics.
The amount of context kept by a function processing unit, (NF-VM), determines the amount of traffic the unit will receive and, in turn, retransmit. This also ultimately defines the NFV requirements from the underlying software network or SDN.
Context Defines the SDN/NFV Link
To further clarify this point, let’s consider an evolved packet core (EPC) as an example. The EPC is a set of (virtualized) functions between mobile broadband and the Internet dedicated to enabling users to move while the Internet “thinks” they don’t. This is done by maintaining in-network user context (as a hub for packets) per roaming user, to and from the Internet. Related mobility management functions maintain user-administrative context but do not channel the actual data-path packets. Obviously the amount of user context kept per each gigabit-per-second of traffic varies considerably between the two subfunctions. They also vary between types of users, for example a meter or a smartphone. The context-affinity per VM defines the method and requirements by which the underlying software-defined network needs to link NFV solutions.
The underlying software network obviously needs to know just enough about the type of NFV and user context per VM in order to send it the right traffic in the right sequence. The core switches are obviously not going to do that based on their normal bridging and routing stacks, as they are not wired for that, yet these stacks are still very much needed for implementing basic connectivity. What is therefore needed from the network on top of these stacks is a dedicated overlay for context-aware application networking. This is actually how we define Carrier SDN and the flow forwarding from access to Internet through functions over basic IP packet connectivity.
Lastly, in order to take a comprehensive look, we must address the scaling of context. The innermost core networking underlay has to, in a way, scale itself and will end up minimizing the amount of state and context it manages. This is because this can be an especially difficult task if it’s bootstrapped from zero. The SDN overlay doesn’t have that option. It has, by definition, a considerable amount of context to carry. However, it can use the underlying IP layer for assistance by building a lightweight context-mapping system scaled by the underlying network. This is the core architecture of the Location/ID Separation Protocol (LISP) overlay standards that OpenDaylight uses to scale-federate carrier SDN. Although the NFV outerlay has considerably more long-lived states and application context to carry than SDN, it’s actually scaled by the SDN layer, much like the data-center application context is scaled by underlying map-reduce infrastructure.
With the proliferation of connected devices not showing any signs of slowing, it’s now time for SDN and NFV technology to follow suit and advance the service-provider infrastructure to the next level.