Snapping Together a Carrier Grade Cloud
Today's enterprise and hyper-scale cloud solutions will not deliver everything needed to virtualize the service providers’ networks. However, cloud solutions do provide many of the building blocks as a great starting point.
Service providers are evolving their networks and services to better meet customer needs and expectations. Hosted applications are continuously updated with new features and consumers are starting to demand a similar frequency of change with services innovation. This rate of change and innovation in service provider networks will not be achieved by rolling more and more specialized hardware boxes to tens of millions of customers. Delivering software-based network solutions that reduce dependency on specialized hardware boxes is the only way to meet these customer expectations.
End users' expectation for service quality continues to increase, and they are typically not willing to accept a tradeoff between performance and capabilities. They want both increased performance and increased capabilities. Service Level Agreements (SLAs) are typically required for enterprise customers, but simply over-provisioning dedicated resources to meet these needs is neither economic, nor sustainable. High performance and network proximity are key to delivering interactive voice and video solutions with high bandwidth and low latency. No one wants to be misunderstood when delivering nuanced details during a videoconference with their stakeholders!
Currently, network services are delivered on several specialty devices located at customer sites or hosted by operators. Today, these specialty devices only provide a subset of needed capabilities and physical upgrades are both expensive and time consuming.
Critical Success Factors
In addition to being consistent and predictable, the network must be fast. There are no milliseconds to spare while moving across the network. For time sensitive applications such as cellular networks, there is no tolerance for physically routing packets inappropriately. They need to traverse the quickest route to their ultimate destination. To use a reference from "Smokey and the Bandit," one of my favorite movies, Bandit (Burt Reynolds' character) didn't drive through New York City to win the race from Texas to Georgia. He took the shortest and fastest route possible. Network traffic needs to do the same thing. Stick to the fastest and most direct route and only deviate when absolutely necessary,
This is not the natural mode for software running in an interrupt-driven multi-tasking environment. Much like humans trying to multi-task, tasks tend to take much longer if we are very busy. Software needs to be configured to prevent or bound interference when multiple workloads are running on the same computer.
"Location, location, location" is as important to network virtualization as it is to real-estate. Virtual Network Functions (VNFs) are the software components that replace the current Physical Network Functions (PNFs). VNFs need to be strategically placed, including positioning at the customer site or even other service provider nodes. Managing Wi-Fi networks requires access to devices at customer sites. Even when offloading the majority of the work to a hosted cloud, there are still physical accesses, routing and local security workloads that are best hosted on the customer site.
Low latency services, such as Content Delivery Networks need caching instances to be located relatively close to the customer site to reduce latency and core network bandwidth. Storage of data should not be on the other side of a busy or slow network connection. The path the data takes over the network needs to provide a consistent user experience. The network also needs to be flexible, as it must adapt to varying network loads and outages. Typically, enterprise cloud applications are designed for high availability and low cost. Speedier customer use is not always a consideration. The ability to easily manage service delivery locations by automatically placing and moving workloads within a data center, or geographically is a must for virtualizing network services.
VNFs must work with the deployed Network Function Virtualization (NFV) infrastructure and hardware. Should each VNF require a different infrastructure, it would be nearly impossible to manage and would cost much more to deploy. Interoperability can enable more competition and a broader set of vendors to deliver network services. Competition drives innovation. Standards and interoperability drive economies of scale.
ETSI-NFV is leading the way in developing the foundational standards for NFV based on a set of use cases and requirements coming from industry. Other standards bodies are referencing the ETSI-NFV work to address application-specific needs. These standards are becoming the basis for defining interoperability. But as with any standards effort, there will be many interpretations and implementations that follow these guidelines.
All of the independent components will need to be validated at key touch points to ensure interoperability and there is still no single test suite available today that will guarantee interoperability between VNFs or between VNFs and the infrastructure that hosts them. To help address this issue, ETSI-NFV is developing test specifications that are being referenced by OPNFV which itself was initiated by the ETSI NFV co-founders to accelerate implementation and feedback on the NFV specifications.
Over the next two to three years, we should see NFV being incorporated in mainstream cloud platforms. The expected performance and interoperability enhancements will increase the efficiency of compute and networking resources while requiring less power and space to run the same work. The improved, distributed nature of a trusted cloud will simplify managing applications running on or near the customers’ locations.
What CableLabs is Doing
CableLabs’ SDN/NFV Application development Platform and Stack project (SNAPS for short) is just one of the initiatives at CableLabs that attempts to accelerate and ease the adoption of network virtualization.
We are identifying the performance needs for network virtualization by evaluating the best open source software components and commercially available servers in order to build a stable and replicable platform for developing and demonstrating virtualized network capabilities and to validate interoperability and repeatability. Currently, the SNAPS project leverages a specific configuration of OPNFV which is being tested and hardened. Many of our enhancements have been included in the OPNFV "Colorado" release of the Apex installer.
Sharing our Expertise
While trying out different OpenStack installers, we soon ran into the dilemma of how to quickly use and validate our cloud in a repeatable manner. In response, we created a Python library whose responsibility is to deploy and provision OpenStack tenants from which we built a set of test suites to perform this validation. While the test suite tools are still under development, we have already made them available under the Apache v2 open source license in CableLabs' C3 collaborative software environment.
Additional contributors are always welcome. The source repository is located here: https://gerrit.cablelabs.com/#/admin/projects/snaps-provisioning
Accelerating NFV Adoption
The SNAPS project team, consisting of CableLabs member companies and vendors, is currently generating requirements and defining use cases to be shared publicly. These requirements include both performance and interoperability guidelines.
CableLabs wholly owned subsidiary Kyrio is using the lessons learned through this R&D process to drive evolution of the Kyrio SDN/NFV Interoperability lab.
We are actively involved in OPNFV and OpenDaylight, and we actively contribute to ETSI NFV.
NFV and SDN: Paving the Way to a Software-Based Networking Future
When ONF Executive Director Dan Pitt invited me to contribute a blog post, it brought to mind our interaction in the summer of 2012 on how to treat SDN in the seminal NFV White Paper I was then editing. The operator co-authors were keen to ensure that SDN and NFV were positioned in the paper as being complementary. This was important because we wanted to create momentum for NFV by highlighting use cases that did not require the then perceived complexity of SDN. As soon as the ETSI NFV Industry Specification Group (NFV ISG) was launched, we engaged with ONF, recognizing its key role in championing an open SDN ecosystem. And in 2014 the NFV ISG entered into an MoU with ONF to facilitate joint-work.
The vision for NFV was compelling because the benefits could be readily attained. By replacing network appliances based on proprietary hardware with virtualized network functions (VNFs) running on industry standard servers, operators could greatly accelerate time to market for new services, and operations streamlined through automation. Moreover, important NFV use cases (e.g. virtualized CPE) would not require massive systems upgrades — a huge barrier for innovation in telecoms. We are seeing this first-hand at CableLabs, where we have been able to prototype virtualized CPE for business services and home networks on a two-month development cycle.
In contrast, the simplified definition of SDN- the separation of control plane from data plane -in my mind does not adequately convey the compelling benefits of SDN. The term ‘Software Defined Networking’ should mean just that, every element of the network, including the VNFs and network control should be implemented within a fully programmable software environment, exposing open interfaces and leveraging the open source community. This is the only way to create an open ecosystem and to unleash a new and unprecedented wave of innovation in every aspect of networking.
NFV releases network functions “trapped inside hardware” (a description I stole from an HP colleague) achieving tremendous benefits. But VNFs must be dynamically configured and connected at scale to deliver tangible value. While today’s telecommunications operations support systems (OSS) are adequate for static NFV use cases, the real potential for NFV to transform networking can only be realized through SDN control. Consequently, SDN represents much more than the mere separation of control plane and data plane.
Given telecommunications networks are deployed at massive geographic scale, it is a hard sell to convince thousands, or even millions of customers that their services will be migrating to a new network platform where their services will not be quite the same but prices won’t go down. Couple that with the significant time and cost to upgrade the OSS, wide ranging operational processes changes, and the need to validate that the new platforms are sufficiently stable and reliable, not to mention the obligations of regulation, it is not surprising that there is hesitancy to contemplate significant telecommunications network transformations.
Consequently, the telecoms industry has resorted to decades of incremental network upgrades which have piled legacy functionality on top of legacy functionality to avoid the costs and risks of wholesale network and services migration. In the face of these realities, SDN was perceived to offer insufficient benefit to justify significant investment except in niche areas where it could be overlaid on top of existing systems. Furthermore, the idea of logically centralized SDN control is very scary to network designers who don’t readily understand abstract software concepts and who lose sleep striving to deliver reliable connectivity at massive scale, with relentless downward pressure on costs.
Just over two years into the NFV revolution, it is clear that the emergence of NFV has galvanized the industry to embrace software-based networking; short-circuiting a transition that might otherwise have taken years. The revelation that NFV can be deployed in digestible chunks, without massive system upgrades has forced network designers to take notice. After all, it is difficult to ignore a pervasive industry trend when vendors’ product plans have morphed into software roadmaps!
Given that NFV is now accepted by all major network operators and some have already made significant announcements, there is no turning back. Leading vendors have committed to NFV roadmaps and analysts talk about ‘when’ and not ‘if’ NFV will be deployed. More importantly, SDN and NFV are now frequently discussed in the same breath. In my mind, the distinction between NFV and SDN is becoming an artifact of history, and the terms will ultimately be subsumed by a software-based networking paradigm, which itself will emerge as an integral aspect of Cloud technology.
The emergence of NFV with SDN is accelerating the evolution of cloud technologies to satisfy the stringent requirements of software-based telecommunications networks. Whereas a web service could momentarily stall with minimal customer impact while a virtual machine reboots, some business-critical network services cannot tolerate loss of connectivity even for a few milliseconds. Therein lies both challenge and opportunity. Challenge because meeting stringent telecommunications availability and performance requirements is not easy as evidenced by the ETSI NFV ISG’s deliberations. Opportunity, because I foresee an unprecedented wave of telecommunications innovation on a par with the birth of the Internet.
Carrier-grade network resilience (e.g. 5-nines and beyond) will be achieved by pooling virtualized resources, fault management will be supplanted by autonomic self-healing networks that can not only withstand equipment failures but can even rapidly recover from large scale natural disasters by instantly migrating network capacity to remote location as demonstrated by NTT DOCOMO et al in the aftermath of the Fukushima disaster. And exciting new routing paradigms such as intent-based networking and content-based networking will become feasible in a much earlier timeframe with innovation galvanized by the potential for imminent experimentation on deployed infrastructures. I could go on…
The genie of software-based networking — where synergies between NFV and SDN result in significantly greater capability than either could deliver alone — is now truly out of the bottle. The ultimate challenge is to encourage growth of an open telecommunications ecosystem, where operators and vendors can work together to create and deliver value to their customers. Energized by the NFV ISG and ONF, among other industry groups, and open source projects that are becoming increasingly important, the reality is just around the corner.
Don Clarke is Principal Architect for Virtualization Technologies at CableLabs and Chairman of the ETSI NFV ISG Network Operator Council.