Crack the NFV Code for Free with our New NFV 101 Training Course
Network Functions Virtualization (NFV), Software-Defined Networking (SDN) and virtualization are transitioning from “buzz words” to reality. As this transition takes place, our members and other players in the ecosystem are asking:
- What is NFV at its core?
- How will it impact my operations?
- What does it mean for my long-term strategy?
In an attempt to answer those questions, CableLabs has developed an NFV 101 training course. This seven-part training series:
- Introduces NFV basics,
- Key NFV requirements,
- Use cases,
- Current industry landscape,
- The role of open source and standards,
- And the future trends we’re expecting from this technology.
NFV will play a key role in shaping how we operate as an industry. With that in mind, this course was designed for anybody who wants to learn more about the technology. Let’s explore in more detail what to expect from each part of the series:
Part 1: NFV Basics
This section will lay the foundational building blocks by exploring what NFV is at its core. You will also find examples of how the technology will impact the network and where SDN plays a role with NFV.
Part 2: Key NFV Requirements
For NFV implementations to be successful, key requirements must be met. This section explores what those requirements are and how to manage those requirements as you encounter them. These key requirements are:
- Cloud-based network topology implementation
- Environmental considerations (e.g., space, power)
- Performance (e.g., latency, throughput)
- License management
- Availability (e.g., reliability, resilience, fault management)
Part 3: NFV Use Cases
NFV presents some compelling use cases, and in this section, we’ll explore some of the most prominent that we’re seeing in the industry, including vFirewall, vCCAP Core with Remote PHY Device (RPD), and SD-WAN. This section also discusses how each use case will impact your operations and customer base.
Part 4: Industry Landscape
In this section of the training, we will dive more deeply into the NFV architecture and what role each of the major components plays. This section will also highlight what roles network services and Virtual Network Functions (VNFs) play within NFV, along with how ETSI has impacted the development and maturity of this technology.
Part 5: Relevant Open-Source Projects
As NFV technology has matured, so have open-source initiatives to improve the technology and interoperability. This section will review the major open-source initiatives and the role they play within the architecture.
Part 6: CableLabs and NFV
As open source and standards mature and shape the future of NFV, CableLabs is playing a key role in helping shape those groups for the entire cable ecosystem. CableLabs has developed a program called SDN & NFV Application Platform and Stack (SNAPS™). SNAPS is the overarching program that provides the foundation for virtualization projects and deployment leveraging SDN and NFV. CableLabs spearheaded the SNAPS project to fill in gaps in the open-source community and to ease the adoption of SDN/NFV for our cable members.
Part 7: Future Trends
Leveraging NFV, cable is poised for the future with the best access network. In this section, we will review where NFV and SDN can take cable networks, along with what to expect from NFV as the technology matures and grows with production implementations.
If you have any questions about the content, contact me at firstname.lastname@example.org. If you would like to request a live training session of the course, contact Amar Kapadia at email@example.com. To review the video series of the training, click below.
CableLabs Announces SNAPS-Kubernetes
Today, I’m pleased to announce the availability of SNAPS-Kubernetes. The latest in CableLabs’ portfolio of open source projects to accelerate the adoption of Network Functions Virtualization (NFV), SNAPS-Kubernetes provides easy-to-install infrastructure software for lab and development projects. SNAPS-Kubernetes was developed with Aricent and you can read more about this release on their blog here.
In my blog 6 months ago, I announced the release of SNAPS-OpenStack and SNAPS-Boot, and I highlighted Kubernetes as a future development area. As with the SNAPS-OpenStack release, we’re making this installer available while it's still early in the development cycle. We welcome contributions and feedback from anyone to help make this an easy-to-use installer for a pure open source and freely available environment. We’re also releasing the support for the Queens release of OpenStack—the latest OpenStack release.
The use of cloud-native technologies, including Kubernetes, should provide for even lower overhead and an even better-performing network virtualization layer than existing virtual machine (VM)-based solutions. It should also improve total cost of ownership (TCO) and quality of experience for end users. A few operators have started to evaluate Kubernetes, and we hope with SNAPS-Kubernetes that even more members will be able to begin this journey.
Our initial total cost of ownership (TCO) analysis with a virtual Converged Cable Access Platform (CCAP) core distributed access architecture (DAA) and Remote PHY technology has shown the following improvements:
- Approximately 89% savings in OpEx costs (power and cooling)
- 16% decrease in rack space footprint
- 1015% increase in throughput
We anticipate that Kubernetes will only increase these numbers.
Three Waves of NFV
SNAPS-Kubernetes will help deliver Virtual Network Functions (VNFs) that use fewer resources, are more fault-tolerant and quickly scale to meet demand. This is a part of a movement coined “cloud native.” This the second of the waves of NFV maturity that we are observing.
With the adoption of NFV, we have identified three overarching trends:
- Lift & Shift
- Cloud Native
- Autonomous Networks
Lift & Shift
Service providers and vendors typically support the Lift & Shift model today. These are large VMs running on an OpenStack-type Virtualized Infrastructure Manager (VIM). This is a mature technology, and many of the gaps in this area have closed.
VNF vendors often brag that their VNF solution runs the same version of software that runs on their appliances in this space. Although achieving feature parity with their existing product line is admirable, these solutions don’t take advantage of the flexibility and versatility that can be achieved by fully leveraging virtualization.
There can be a high degree of separation between the underlying hardware and operating system from the VM. This separation is great for portability, but it comes at a cost. Without some level of hardware awareness, it isn’t possible to take full advantage of acceleration capabilities. An extra layer of indirection is included, which can add latency.
Containers and Kubernetes excel in this quickly evolving section of the market. These solutions aren’t yet as mature as OpenStack and other virtualization solutions, but they are lighter weight and integrate software and infrastructure management. This means that Kubernetes will scale and fail over applications, and the software updates are also managed.
Cloud native is well suited for edge and customer-premises solutions where compute resources are limited by space and power.
Autonomous networks are the desired future in which every element of the network is automated. High-resolution data is being evaluated to continually optimize the network for current and projected conditions. The 3–6-year projection for this technology is probably a bit optimistic, but we need to start implementing monitoring and automation tools in preparation for this shift.
This release is based on Kubernetes 1.10. We will update Kubernetes as new releases stabilize and we have time to validate these releases. As with SNAPS-OpenStack, we believe it’s important to adopt the latest stable releases for lab and evaluation work. Doing so will prepare you for future features that help you get the most out of your infrastructure.
This initial release supports Docker containers. Docker is one of the most popular types of containers, and we want to take advantage of the rich ecosystem of build and management tools. If we later find other container technologies that are better suited to specific cable use cases, this support may change in future releases.
Because Kubernetes and containers are so lightweight, you can run SNAPS-Kubernetes on an existing virtual platform. Our Continuous Integration (CI) scripts use SNAPS-OO to completely automate the installation on almost any OpenStack platform. This should work with most OpenStack versions from Liberty to Queens.
SNAPS-Kubernetes supports the following six solutions for cluster-wide networking:
- Single Root I/O Virtualization (SRIOV)
- Dynamic Host Configuration Protocol (DHCP)
Weave, Calico and Flannel provide cluster-wide networking and can be used as the default networking solution for the cluster. Macvlan and SRIOV, however, are specific to individual nodes and are installed only on specified nodes.
SNAPS-Kubernetes uses Container Network Interface (CNI) plug-ins to orchestrate these networking solutions.
As we highlighted before, serverless infrastructure and orchestration continue to be future areas of interest and research. In addition to extending the scope of our infrastructure, we are focusing on using and refining the tools.
Multiple CMTS vendors have announced and demonstrated virtual CCAP cores, so this will be an important workload for our members.
Try It Today
Like other SNAPS releases, SNAPS-Kubernetes is available on GitHub under the Apache Version 2 license. SNAPS-Kubernetes follows the same installation process as SNAPS-OpenStack. The servers are prepared with SNAPS-Boot, and then SNAPS-Kubernetes is installed.
Have Questions? We’d Love to Hear from You
- Reach out on IRC: Server: Freenode Channel #cablelabs-snaps
- Contribute to the documentation, backlog and code on GitHub
- Send an email message directly to firstname.lastname@example.org
- Tweet to @RandyLevensalor
Subscribe to our blog to learn more about SNAPS in the future.
Kyrio NFV Interop Lab: Powered by SNAPS
On Dec. 14, 2017, CableLabs released two new open source projects, SNAPS-Boot and SNAPS-OpenStack. SNAPS, which is short for SDN/NFV Application Development Platform and Stack, is an open source platform with the following objectives:
- Speed development of cloud applications
- Facilitate collaboration between solution providers and operators
- Ensure interoperability
- Accelerate adoption of virtual network functions and platform components.
In this post, we explore some of the synergies between the SNAPS projects and the Kyrio NFV Interop Lab.
Background: Delivering on the NFV Promise
The Kyrio NFV Interop Lab is designed as an open, collaborative system integration environment where multiple solution providers can work together in a neutral setting to develop concept systems and then showcase them to the operator community.
At last year’s Summer Conference, we displayed proof-of-concept systems demonstrating orchestrated deployment of SD-WAN with firewalling and LTE to WiFi call hand-off over a D3.1 R-PHY access network connected to a virtual CCAP Core and a virtual mobile core.
These technologies are fundamental enablers for converged networks composed of virtualized network functions running on virtual network cores. The SD-WAN, firewall and mobile calling use cases represent a significant opportunity for operators to offer efficient, flexible and agile services to their customers.
The systems were envisioned and designed by Kyrio NFV Lab sponsoring partners, integrated at CableLabs, and demonstrated at the CableLabs Summer Conference. They remain on display in the Kyrio NFV Lab in order to provide operators with ongoing access to the systems and to enable solution providers to continue development of new functions and features. Further system details are available in this webinar.
Running on Open Source: The Way of the Future
Kyrio NFV Lab systems are designed by lab sponsors using a variety of hardware and software components. However, open source software and generic commercial-off-the-shelf (COTS) hardware are the preferred environment for operators. To that end, SNAPS has been developed to provide a cloud environment that is freely available to operators and developers, based on and synchronized to OPNFV OpenStack, one of the world’s largest open source projects delivering cloud software.
Project code is publicly available and located here:
SNAPS-Boot: Automates the imaging and configuration of servers that constitute a cloud.
SNAPS-OpenStack: Automates the deployment of the OpenStack VIM on those servers.
Together they provide a powerful method for creating a standard development and testing environment.
For details on project objectives, timelines and participation contact Randy Levensalor, the SNAPS project lead.
The Mobile Call Hand-off system mentioned above was built on a beta version of SNAPS, based on Newtown OpenStack. New systems in the Kyrio NFV Lab are running on the public release of SNAPS, based on Pike OpenStack. OpenStack synchronization is a key benefit for operators, solution developers and interop testing.
Kyrio NFV Lab: Taking the Next Steps
New system development planned for the next two quarters include orchestration of multi-vendor software firewalls and orchestration of a virtual CCAP Core.
Latest generation Intel COTS servers have arrived featuring dual Xeon 6152 CPUs (44 cores/host), 364 GB RAM, four 1 TB SSDs, plus two 250 GB SSDs and multiple 40/10 Gbs NICS.
Evaluation is underway to determine data throughput under various BIOS settings, using select versions of Linux. Work is also underway to measure power consumption baselines under various load conditions.
A stable, well-characterized hardware/software platform is the foundation of the Kyrio NFV Lab’s work toward evaluation of SDN/NFV component interoperability, and Virtual Network Function on-boarding. The main questions operators will ask when considering trial or deployment of a virtual application will be:
- “Does it work as designed?”
- “Does it interoperate with other elements in my environment?”
- “How easy is it to deploy?”
These are the questions that the Kyrio NFV Lab, working over the SNAPS platform, will consider on behalf of the operator community. The faster we can answer “Yes”, “Yes” and “Very”, the faster the ecosystem will advance, the faster operators will adopt, and the faster customers will have access to newer and more reliable services. Stay tuned for progress updates from the Kyrio NFV Interop Lab - powered by SNAPS.
For further information or Kyrio NFV Lab programs and participation opportunities:
Email: Robin Ku, Director Kyrio NFV Lab
For further information on SNAPS and open source software development:
See Broadband Technology Report’s article and Randy Levensalor's blog post "CableLabs Announces SNAPS-Boot and SNAPS-OpenStack Installers"
Email: Randy Levensalor, Lead Architect Application Technologies
For CableLabs members:
Attend the Inspir[ED] NFV workshop February 13-15, in Louisville CO, for business and technical track sessions and access to all demo systems.
CableLabs Announces SNAPS-Boot and SNAPS-OpenStack Installers
After living and breathing open source since experimenting in high school, there is nothing as sweet as sharing your latest project with the world! Today, CableLabs is thrilled to announce the extension of our SNAPS-OO initiative with two new projects: SNAPS-Boot and SNAPS-OpenStack installers. SNAPS-Boot and SNAPS-OpenStack are based on requirements generated by CableLabs to meet our member needs and drive interoperability. The software was developed by CableLabs and Aricent.
SNAPS-Boot will prepare your servers for OpenStack. With a single command, you can install Linux on your servers and prepare them for your OpenStack installation using IPMI, PXE and other standard technologies to automate the installation.
The SNAPS-OpenStack installer will bring up OpenStack on your running servers. We are using a containerized version of the OpenStack software. SNAPS-OpenStack is based on the OpenStack Pike release, as this is the most recent stable release of OpenStack. You can find an updated version of the platform that we used for the virtual CCAP core and mobile convergence demo here.
How you can participate:
We encourage you to go to GitHub and try for yourself:
SNAPS (SDN & NFV Application Platform and Stack) is the overarching program to provide the foundation for virtualization projects and deployment leveraging SDN and NFV. CableLabs spearheaded the SNAPS project to fill in gaps in the open source community to ease the adoption of SDN/NFV with our cable members by:
Encouraging interoperability for both traditional and prevailing software-based network services: As cable networks evolve and add more capabilities, SNAPS seeks to organize and unify the industry around distributed architectures and virtualization on a stable open source platform to develop baseline OpenStack and NFV installations and configurations.
Network virtualization requires an open platform. Rather than basing our platform on a vendor-specific version, or being over 6 months behind the latest OpenStack release, we added a lightweight wrapper on top of upstream OpenStack to instantiate virtual network functions (VNFs) in a real-time dynamic way.
Seeding a group of knowledgeable developers that will help build a rich and strong open source community, driving developers to cable: SNAPS is aimed at developers who want to experiment with building apps that require low latency (gaming, virtual reality and augmented reality) at the edge. Developers are able to share information in the open source community on how they optimize their application. This not only helps other app developers, but helps the cable industry understand how to implement SDN/NFV in their networks and gain easy access to these new apps.
At CableLabs, we pursue a “release early” principle to enable contributions to improve and guide the development of new features and encourage others to participate in our projects. This enables us to continuously optimize the software, extend features and improve the ease of use. Our subsidiary, Kyrio, is also handling the integration and testing on the platform at their NFV Interoperability lab.
You can find more information about SNAPS in my previous blog posts “SNAPS-OO is an Open Sourced Collaborative Development” and “NFV for Cable Matures with SNAPS”
Who benefits from SNAPS?
- App Developers will have access to a virtual sandbox that allows them to test how their app will run in a cable scenario, saving them time and money.
- Service providers, vendors and enterprises will be able to build more exciting applications, on a pure open source NFV platform focused on stability and performance, on top of the cable architecture.
How we developed SNAPS:
We leverage containers which have been built and tested by the OpenStack Kolla project. If you are not familiar with Kolla, it is an OpenStack project that maintains a set of Docker containers for many of the OpenStack components. We use these scripts to deploy the containers because the Kolla-Ansible scripts are the most mature and include a broad set of features which can be used in a low latency edge data center. By using containers, we are improving the installation process and updating.
To maximize the usefulness of the SNAPS platform, we included many of the most popular OpenStack projects:
Additional services we included:
Where the future of SNAPS is headed:
- We plan to continue to make the platform more robust and stable.
- Because of the capabilities we have developed in SNAPS, we have started discussions with the OPNFV Cross Community Continuous Integration (XCI) project to use SNAPS OpenStack as a stable platform for testing test tools and VNFs with a goal to pilot the project in early 2018.
- Aricent is a strong participant in the open source community and has co-created the SNAPS-Boot and SNAPS-OpenStack installer project. Aricent will be one of the first companies to join our open source community contributing code and thought leadership, as well as helping others to create powerful applications that will be valuable to cable.
- As an open source project, we encourage other cable vendors and our members to join the project, contribute code and utilize the open source work products.
There are three general areas where we want to enhance the SNAPS project:
- Integration with NFV orchestrators: We are including the OpenStack NFV orchestrator (Tacker) with this release and we want to extend this to work with other orchestrators in the future.
- Containers and Kubernetes support: We already have some support for Kubernetes running in VMs. We would like to evaluate the benefit of running Kubernetes with or without the benefit/overhead of VMs.
- Serverless computing: We believe that Serverless computing will be a powerful new paradigm that will be important to the cable industry and will be exploring how best to use SNAPS as a Serverless computing platform.
Interactive SNAPS portfolio overview:
Have Questions? We’d love to hear from you
- Reach out on IRC: Server: Freenode Channel #cablelabs-snaps
- Contribute to the documentation, backlog and code on GitHub
- Send an e-mail directly to email@example.com
- Tweet to @RandyLevensalor
Don’t forget to subscribe to our blog to read more about NFV and SNAPS in our upcoming in-depth SNAPS series. Members can join our NFV Workshop February 13-15, 2018. You can find more information about the workshop and the schedule here.
NFV for Cable Matures with SNAPS
SNAPS is improving the quality of open source projects associated with the Network Functions Virtualization (NFV) infrastructure and Virtualization Infrastructure Managers (VIM) that many of our members use today. In my posts, SNAPS is an Open Source Collaborative Development Resource and Snapping Together a Carrier Grade Cloud, I talk about building tools to test the NFV infrastructure. Today, I’m thrilled to announce that we are deploying end-to-end applications on our SNAPS platform.
To demonstrate this technology, we recently held a webinar “Virtualizing the Headend: A SNAPS Proof of Concept” introducing the benefits and challenges of the SNAPS platform. Below, I’ll describe the background and technical details of the webinar. You can skip this information and go straight to the webinar by clicking here.
CableLabs’ SDN/ NFV Application Development Platform and OpenStack project (SNAPS for short) is an initiative that attempts to accelerate the adoption of network virtualization.
Network virtualization gives us the ability to simulate a hardware platform in software. All the functionality is separated from the hardware and runs as a “virtual instance.” For example, in software development, a developer can write an application and test it on a virtual network to make sure the application works as expected.
Why is network virtualization so important? It gives us the ability to create, modify, move and terminate functions across the network.
Why SNAPS is unique
- Creates a stable, replicable and cost-effective platform: SNAPS allows operators and vendors to efficiently develop new automation capabilities to meet the growing consumer demand for self-service provisioning. Much like signing up for Netflix, self-service provisioning allows customers to add and change services on their own, as opposed to setting-up a cable box at home.
- Provides transparent API’s for various kinds of infrastructure
- Reduces the complexity of integration testing
- Only uses upstream OpenStack components to ensure the broadest support: SNAPS is open source software which is available directly from the public OpenStack project. This means we do not deviate from the common source.
With SNAPS, we are pushing the limits of open source and commodity hardware because members can run their entire Virtualized Infrastructure Manager (VIM) on the platform. This is important because the VIM is responsible for managing the virtualized infrastructure of a NFV solution.
Webinar: Proof of Concepts
We collaborated with Aricent, Intel and Casa Systems to deploy two proof of concepts that are reviewed in the webinar. We chose these partners because they are leading the charge to create dynamic cable and mobile networks to keep up with world’s increasing hunger for faster, more intelligent networks tailored to meet customers' needs.
Casa and Intel: Virtual CCAP and Mobile Cores
CableLabs successfully deployed a virtual CCAP (converged cable access platform) core on OpenStack. Eliminating the physical CCAP provides numerous benefits to service providers, including power and cost savings.
Casa and Intel provided hardware and Casa Systems provided the Virtualized Network Function (VNFs) which ran on the SNAPS platform. The virtual CCAP core controls the cable plant and moves every packet to and from the customer sites. You can find more information about CCAP core in Jon Schnoor’s blog post “Remote PHY is Real.”
Advantages of Kyrio’s NFV Interop Lab
For the virtual CCAP demo, the Kyrio NFV Interop Lab provided a collaborative environment for Intel and Casa to leverage the Kyrio lab and staff to build and demonstrate the key building blocks for virtualizing the cable access network.
The Kyrio NFV Interop Lab is unique. It provides an opportunity for developers to test interoperability in a network environment against certified cable access network technology. You can think of the Kyrio lab as a sandbox for engineers to work and build in, enabling:
- Shorter development times
- Operator resources savings
- Faster tests, field trials and live deployments
Aricent: Low Latency and Backhaul Optimization
With Aricent we had two different proof of concepts. Both demos highlighted the benefits of having a cloud (or servers) at the service provider edge (less than 100 miles from a customer’s home):
- Low latency: We simulated two smart cars connected to a cellular network. The cars used an application running on a cloud to calculate their speed. If the cloud was too far away, a faster car would rear end a slower car before it was told to slow down. If the cloud was close, the faster car would slow down in time to prevent rear-ending the slower car.
- Bandwidth savings: Saving data that will be used by several people in a closer location can reduce the amount of traffic on the core network. For example, when someone in the same neighborhood watches the same video, they will see a local copy of the video, rather than downloading the original from the other side of the country.
The SNAPS platform continues CableLabs’ tradition of bringing leading technology to the cable industry. The collaborations with Intel, Aricent and Casa Systems were very successful because:
- We demonstrated end-to-end use cases from different vendors on the same version of OpenStack.
- We identified additional core capabilities that should be a part of every VIM. We have already incorporated new features in the SNAPS platform to better support layer 2 networking, including increasing the maximum frame size (or MTU) to comply with the DOCSIS® 3.1 specification.
In addition to evolving these applications, we are interested in collaborating with other developers to demonstrate the SNAPS platform. Please contact Randy Levensalor at firstname.lastname@example.org for more information.
Don’t forget to subscribe to our blog to read more about how we utilize open source to develop quickly, securely, and cost-effectively.
SNAPS-OO is an Open Sourced Collaborative Development Resource
In a previous blog, I have provided an overview of the SNAPS platform which is CableLabs’ SDN/NFV Application development Platform and Stack project. The key objectives for SNAPS are to make it much easier for NFV vendors to onboard their applications, provide transparent APIs for various kinds of infrastructure and reduce the complexity of integration testing.
I am thrilled to share our latest SNAPS success. We have written an OpenStack API abstraction library that also contains many automated tests and we have contributed it to the Open Platform for NFV (OPNFV) project at the Linux Foundation. OPNFV is a project where service providers and network vendors collaborate to improve the capabilities and adoption of open source Network Functions Virtualization (NFV). Our results have also been shared at NFV World Congress, SDN World Congress, OPNFV Summit [video], Open Networking Summit (ONS) [video] [pdf] and the Big Communications Event (BCE).
The Rationale for our Approach
CableLabs has deep expertise developing specifications by following a collaborative, iterative approach. In many ways, the open source software development process mirrors many of these specification development processes. In the open source communities, CableLabs provides source code and feedback coming from our integration and debugging activity. In fact, CableLabs contributions are included in key open source projects such as OpenStack and OpenDaylight. In this way, we are making it easier for vendors to use open source projects to build solutions for the benefit of the entire ecosystem.
We have generated practical knowledge and insights through our hands-on experience of building and operating an active SDN/NFV application development lab. And we took vendor neutrality to the next level by basing our software stack on purely open source solutions and based on the OPNFV reference configuration. We did not use versions of OpenStack, OpenDaylight, etc. that have been tested and customized by a vendor. This allowed us to interact with a much larger community for new features and fixes.
The CableLabs team supported by vendors and services providers has moved our project into OPNFV as “SNAPS-OO”, based on the idea that it is an Object Oriented way to work with our SDN/NFV Application development Platform and Stack. The project was quickly accepted and is now being used by the release testing team to verify each OPNFV build. With the integration of SNAPS-OO into the OPNFV FuncTest project, our contributions are now part of the release criteria and suite of tests that will be used at the upcoming OPNFV PlugFest next month.
Some of the benefits that SNAPS-OO delivers are:
- Ease of use for new developers
- A rich library of example applications and test suites
- Support for accessing multiple secured clouds
- Automated cleanup of the NFVI when updates are applied
- Quick identification of component failure(s)
As a result of this open source approach, and in just a few weeks since SNAPS-OO was released, we have seen a significant increase in the level of contributions and adoption.
- Continue to expand the capabilities supported by SNAPS-OO.
- Encourage additional OPNFV projects to use SNAPS-OO.
- Use SNAPS-OO and other tools to run much more sophisticated SDN/NFV workloads.
- Share SNAPS-OO with more open source communities.
How SNAPS-OO Benefits Our Membership
SNAPS-OO is helping to improve the quality of the open source projects associated with the NFV infrastructure and Virtualization Infrastructure Managers that many members are using today and plan to use in the future. SNAPS-OO can be used to validate that the infrastructure is installed properly and it will be playing a key role in the Kyrio NFV Interoperability lab. Future NFV development provided by vendors will benefit from the use of SNAPS-OO. With the variety of workloads that we will be running on our SNAPS platform, we will be able to specify a single configuration that can run future NFV workloads alongside other cloud hosted applications.
Improving Infrastructure Security Through NFV and SDN
October was Cybersecurity Awareness Month in the US. We certainly were aware. In September, IoT cameras were hacked and used to create the largest denial of service attacks to date, well over 600Gbps. On October 21, the same devices were used in a modified attack against Dyn authoritative DNS services resulting in disruption of around 1200 websites. Consumer impacts were widely felt, as popular services such as Twitter and Reddit became unstable.
Open distributed architectures can be used to improve the security of network operators’ rapidly evolving networks, reducing the impacts of attacks and providing excellent customer experiences. Two key technologies enabling open distributed architectures are Network Function Virtualization (NFV) and Software Defined Networking (SDN). Don Clarke detailed NFV further in his blog post on ETSI NFV activities. Randy Levensalor also reviewed one of CableLabs’ NFV initiatives, SNAPS earlier this year.
Future networks based on NFV and SDN will enable simpler security processes and controls than we experience today. Networks using these technologies will be easier to upgrade and patch as security threats evolve. Encryption will be supported more easily and other security mechanisms more consistently than legacy technologies. And network monitoring to manage threats will be easier and more cost-effective.
Open distributed architectures provide the opportunity for more consistent implementation of fundamental features, process and protocols, including easier implementation of new, more secure protocols. This in turn may enable simpler implementation and deployment of security processes and controls. Legacy network infrastructure features and processes are largely characterized by proprietary systems. Even implementing basic access control lists from IP based interfaces varies widely, not only in the interfaces used to implement the control lists, but in the granularity and specificity of the controls. Some areas have improved but NFV and SDN can improve further. For example, BGP Flowspec has helped standardize blocking, rate limiting, and traffic redirection on routers. However, it has strict limits today on the number of rules practically supported on routers. NFV and SDN can provide improved scalability and greater functionality. NFV provides an opportunity to readdress this complexity by providing common methods to implement security controls. SDN offers a similar opportunity, providing standardized interfaces to implement flow tables to devices and configuration deployment through model-based configuration (e.g. using YANG and NETCONF).
Standardized features, processes, and protocols naturally lead to simpler and more rapid deployment of security tools and easier patching of applications. NFV enables the application of Develop Operations (DevOps) best practices to develop, deploy, and test software patches and updates. Physical and virtual routers and network appliances can be similarly programmatically updated using SDN. Such agile and automated reconfiguration of the network will likely make it easier to address security threats. Moreover, security monitors and sensors, firewalls, virtual private network instances, and more can be readily deployed or updated as security threats evolve.
Customer confidentiality can be further enhanced. In the past, encryption was not widely deployed for a wide range of very good economic and technical reasons. The industry has learned a great deal in deploying secure and encrypted infrastructure for DOCSIS® networks and also radio access networks (RANs). New hardware and software capabilities already used widely in data center and cloud solutions can be applied to NFV to enable pervasive encryption within core networks. Consequently, deployment of network infrastructure encryption may now be much more practical. This may dramatically increase the difficulty of conducting unauthorized monitoring, man-in-the-middle attacks and route hijacks.
A key challenge for network operators continues to be detection of malicious attacks against subscribers. Service providers use a variety of non-intrusive monitoring techniques to identify systems that have been infected by malware and are active participants in botnets. They also need to quickly identify large-scale denial of service attacks and try to limit the impacts those attacks have on customers. Unfortunately, such detection has been expensive. NFV promises to distribute monitoring functions more economically and more widely, enabling much more agile responses to threats to customers. In addition, NFV can harness specific virtualization techniques recommended by NIST (such as hypervisor introspection) to ensure active monitoring of applications. Moreover, SDN provides the potential to quickly limit or block malicious traffic flows much closer to the source of attacks.
Finally, NFV promises to allow us the opportunity to leap ahead on security practices in networks. Most of the core network technologies in place today (routing, switching, DNS, etc.) were developed over 20 years ago. The industry providing broadband services knows so much more today than when the initial broadband and enterprise networks were first deployed. NFV and SDN technologies provide an opportunity to largely clean the slate and remove intrinsic vulnerabilities. The Internet was originally conceived as an open environment – access to the Internet was minimally controlled and authentication never integrated at the protocol level. This has proven to be naïve, and open distributed architecture solutions enabled by NFV and SDN can help to provide a better, more securable infrastructure. Of course, there will continue to be vulnerabilities – and new ones will be discovered that are unique to NFV and SDN solutions.
As Cybersecurity Awareness Month closes and we start a new year focused on improving consumer experiences, CableLabs is pursuing several projects to leverage these technologies to improve the security of broadband services. We are working to define and enable key imperatives required to secure virtualized environments. We are using our expertise to influence key standards initiatives. For example, we participate in the ETSI NFV Industry Specification Group (ETSI NFV) which is the most influential NFV standards organization. In fact, CableLabs chairs the ETSI NFV Security Working Group which has advanced the security of distributed architectures substantially the past 4-years. Finally, we continue to innovate new open and distributed network solutions to create home networks that can adaptively support secure services, new methods of authentication and attestation in virtual infrastructures, and universal provisioning interfaces.
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.
ETSI NFV Continues to Build Momentum
Last year I blogged about ETSI NFV Industry Specification Group (ETSI NFV) progress. The ETSI NFV body of work has become firmly established as the key reference for both global standards bodies and open source communities. Last week I was in Dublin for the thirteenth ETSI NFV plenary meeting (NFV#13) hosted by Cobham Wireless and OPENET.
Why Was This Meeting Important?
NFV#13 was an important milestone for the ETSI NFV community, not only did it mark the start of the fourth year of work, but the final documents comprising ‘Release 2’ were scheduled for approval, plus a large body of new work was under consideration to be included in the work plan. The new work will comprise ‘Release 3’. It was sure to be a very intense week.
In my mind, NFV#13 was also an important test of the continuing relevance of the ETSI NFV community in the face of accelerating progress on NFV-related standards and open source, and NFV deployments are gathering pace globally. As it turned out, 210 delegates travelled to Dublin from all over the world, a similar number or slightly more than previous meetings in Europe. Membership continues to grow and now stands at over 290 companies including government bodies and academic institutions as well as vendors and network operators. The intensity of ETSI NFV work continues unabated which confirms the relevance of this forum to the industry.
As ETSI NFV Network Operator Council (NOC) chair, I was concerned to ensure that the operator group which now consists of 39 operators (CableLabs represents MSOs) would have adequate time to review the large body of new work to ensure it would be relevant to network operator needs. Under the leadership of co-chair Klaus Martiny at Deutsche Telekom, the NOC had carried out an analysis of the proposed new work program and this was referenced by the ETSI NFV Technical Steering Committee and working groups in Dublin to help guide their planning discussions.
The five working groups broke into parallel sessions after the opening plenary on Tuesday and managed to complete work on 12 documents, 3 of which were approved for immediate publication and 9 sent for remote consensus in the next four-weeks. In addition, 17 new work items were approved but there was insufficient time to consider all of the proposals put forward for approval in Dublin and the remainder will be discussed on an ETSI NFV plenary call in April. I am confident these will be approved in time for work to begin at or soon after NFV#14 which will be hosted by AT&T in Atlanta, May 3-6, 2016.
As a founder of the ETSI NFV forum, I am particularly interested that the work is timely and that it continues to be of high value to the industry. The current mandate from ETSI expires at the end of this year and there needs to be clarity on what will be the role of the forum in continuing to build the NFV ecosystem. With this in mind, I initiated discussions in the NOC on what should be the focus for ETSI NFV in 2017 and beyond. The outcomes of these discussions will be presented at NFV#14 and I will blog about them as soon as the direction becomes clearer.
It was an exhausting week for everyone considering the unprecedented intensity of the work program. The ETSI NFV community is working well together and there is a high degree of mutual trust amongst the participants which serves the industry well. The community has proved that it can both deliver and adapt to the changing needs of the industry as the NFV transformation takes hold.
What is CableLabs Doing in this Space?
CableLabs has been working in the SDN and NFV space for over three years with work spanning the breadth of the cable network. We will continue to be actively involved in ETSI NFV and related open source activities contributing insights from our R&D and Innovation activities. And we have established Kyrio, a wholly owned subsidiary of CableLabs to provide a collaborative environment for SDN and NFV integration and testing including an OPNFV lab. which is open to participation by external organizations.
If your organization is interested in participating in the OPNFV lab. please contact Wylie Nelson
Don Clarke is a Principal Architect at CableLabs working in the Core Innovation group.
Making Network Virtualization and Carrier Ethernet Easier
A CableLabs Demonstration of SDN with OpenSource Software
Seeing is believing, especially with all of the hype and limitless possibilities that new technologies promise. It is refreshing to quickly build a prototype for a real customer use case without all of the smoke and mirrors. Through an open and collaborative effort, CableLabs and BSS/OSS solutions provider Intraway developed a proof-of-concept and demonstration using open source software. This demonstration manages virtualized customer premise equipment (vCPE) and is compliant with Metro Ethernet Forum (MEF) defined Carrier Ethernet services. Details on the demonstration and how you run and build upon this work will be shared later in this post.
Software-Defined Networks and Network Function Virtualization, commonly known as SDN and NFV, are terms that are present in every telecommunications engineer’s mind today. It is hard to look at a technical newsletter or site without seeing at least one article with those acronyms.
Most Communications Service Provider (CSP) executives know what these letters mean in essence, and that they represent a shift in the networking paradigm. The real question is not how trendy this technological approach is, but rather if it is still just hype or if there are genuine business opportunities for service providers. In this article, we intend to answer that question. And, here’s a spoiler: this technology is closer than you think.
But, why would any CSP want to adopt this technology so early?
CableLabs sees three key benefits for leveraging SDN and NFV technologies:
- Reduce time to market
SDN and NFV allow for more flexible and agile deployment of networks and network services
- Reduce operational expense
SDN and NFV enable greater automation of network configuration by exposing network functions through application programming interfaces (APIs)
- Facilitate rapid innovation
Networking functions implemented in software can be developed, verified, and deployed - or rejected - far faster than hardware development cycles allow.
For instance, what happens in a non-virtualized environment when a customer requests a bandwidth upgrade for all its branches? Normally, it would take weeks to manually gather the network configuration. Then there are the planning, designing and delivery stages, which can take months. And what if that upgrade request was made to handle a high-demand period? Too often, by the time the service operator is ready to deliver, the high demand is over. But SDN/NFV, along with an orchestration layer, delivers new services and change requests in a matter of days or even hours. With SDN and NFV adoption, rapid innovation is the new network paradigm. It opens so many doors to new sources of revenue that we are just starting to imagine the possibilities. This technology represents such a shift that while not yet fully realized, its promise is already changing the business playbook for MSOs.
The Enabling Technology
SDN is commonly characterized as the separation of the networking equipment’s control capability from the data manipulation and forwarding processes. By separating the control of networked equipment from the hardware, SDN provides an opportunity to programmatically configure the network. By exposing control of networked elements through a software programming interface, configuration and control of the network can be automated through software scripts or applications.
Software controlling operation of networking equipment can be modified and tested easily, and deployed much faster than the design-build-test cycle of the hardware. Thus, SDN provides the opportunity to greatly streamline not only the initial deployment of services on the network, but also later modification and maintenance.
NFV is the modularization of functionality in networking equipment so that it can be separated from the network hardware and potentially executed outside the equipment in a sequence determined by the network engineer. NFV creates the opportunity to both simplify network hardware and introduce flexibility in the network architecture. Examples include network functions such as routing, load balancing, packet inspection, and firewall. When implemented in software as independent virtual network functions (VNF), data handling processes such as these can be invoked and chained together as needed.
CableLabs established early leadership in virtualization technology for deploying business services by exploring the use of open source SDN controller platforms to configure networking equipment for delivering business/commercial services. Open source refers to the software development by a community of talented developers that are not necessarily all working for the same company. Open source development allows for progress to be made at a pace that is not necessarily tied to a particular organization’s product schedule or hardware specifics.
But if SDN and NFV are to be more than a collection of proprietary, semi-closed ecologies, there needs to be a working reference model that the greater communications community can look to for ideas, guidance, and benchmarks.
CableLabs initiated a proof-of-concept project called the Virtualized Business CPE demonstration. The goal of the project is to demonstrate a properly implemented, open-source based SDN solution to support existing services. Intraway volunteered to join CableLabs (with consultant Inocybe Technologies) in this open-source effort.
Service activation and live modification of business services typically have the longest lead time and often require the most manual intervention. These use cases were selected for the initial demonstration. A point-to-point Ethernet circuit between two User Network Interfaces (UNIs) was chosen as the service. To demonstrate that SDN functions need not be proprietary, we used OpenDaylight as the control plane, OVSDB for the communications interface, and Open vSwitch to do the actual switching in the CPE devices.
For the hardware, we chose to use two Raspberry Pi devices to host the UNIs, an eight port Ethernet switch (to act as the network) and a laptop running Ubuntu Linux acting as the controller. Connected to each of the Raspberry Pi UNIs were laptops acting as the clients or end-devices. (The operating system of the two ‘client’ laptops is not important.)
This demonstration shows the creation of an Ethernet Private Line (EPL) between the two Raspberry Pi devices at a set bandwidth rate. After connectivity and traffic are established, we instruct the network to modify the existing rate through the controller software, which then issues instructions to the Raspberry Pi devices. The bandwidth of the EPL is immediately changed without having to tear down and rebuild the circuit!
Conclusion / Next Steps
With the success of the proof-of-concept, the source code is now publicly available in the open source project’s code repositories. CableLabs members and the vendor community can operationalize these concepts for many business services.
git clone https://git.opendaylight.org/gerrit/unimgr
git clone https://gerrit.opnfv.org/gerrit/lsoapi
This open collaboration with participation and feedback from CableLabs members, along with the active participation of vendors such as Intraway and Inocbye in open source projects, is one way that CableLabs helps ease the path forward with the adoption of new technology.
The Virtualized Business CPE demo, developed by CableLabs with participation from Inocybe Technologies and Intraway, will be featured at CableLabs 2016 Winter Conference in Orlando, Florida. If you are attending the conference, stop by to catch a glimpse of the future!
Randy Levensalor is a Lead Architect in the Wired Networks group at CableLabs.