Comments
Virtualization

Crack the NFV Code for Free with our New NFV 101 Training Course

Paul Fonte
Project Manager

Oct 9, 2018

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.

NFV Basics

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)
  • Security
  • 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.

NFV Use Cases

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.

NFV Architecture

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.

Relevant Open Source Projects

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.

CableLabs and NFV

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.

Three Waves of NFV

If you have any questions about the content, contact me at p.fonte@cablelabs.com. If you would like to request a live training session of the course, contact Amar Kapadia at akapadia@aarnanetworks.com. To review the video series of the training, click below.


Take the NFV 101 Course

Comments
Virtualization

CableLabs Announces SNAPS-Kubernetes

Randy Levensalor
Principal Architect, Future Infrastructure Group, Office of the CTO

Jul 23, 2018

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.

Member Impact

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:

  1. Lift & Shift
  2. Cloud Native
  3. Autonomous Networks

SNAPS Kubernetes three waves of nfv

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.

Cloud Native

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

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.

Features

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:

  • Weave
  • Flannel
  • Calico
  • Macvlan
  • 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.

Next Steps

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

Subscribe to our blog to learn more about SNAPS in the future.


SUBSCRIBE TO OUR BLOG

Comments
Virtualization

Container Workloads: Evolution of SNAPS for Cloud-Native Development

Feb 8, 2018

Application developers drive cloud-platform innovation by continuously pushing the envelope when it comes to defining requirements for the underlying platform. In the emerging application programming interface (API) and algorithm economy, developers are leveraging a variety of tools and already-built services to rapidly create new applications. Edge computing and Internet-of-Things (IoT) use cases require platforms that can be used to offload computing from low-power devices to powerful servers. Application developers deliver their software in iterations where user feedback is critical for product evolution. This requires building platforms that allow developers to develop new features rapidly and deploy them in production. In other words, to adopt DevOps.

In the telecommunications world, network function virtualization (NFV) is driving the evolution of telco clouds. However, the focus is shifting towards containers as a lightweight virtualization option that caters to the application developer’s requirements of agility and flexibility. Containerization and cluster-management technologies such as Docker and Kubernetes are becoming popular alternatives for tenant, network and application isolation at higher performance and lower overhead levels.

Container is an operating system level virtualization that allows execution of lightweight independent instances of isolated resources on a single Linux instance. Container implementation like Docker avoids the overhead and maintenance of virtual machines and helps in enabling portability and flexibility of applications across public and private cloud infrastructure.

Microservice architectures are enabling developers to easily adopt the API and algorithm economy. It has become imperative that we start to look at containers as an enabler for carrier-grade platforms to power new cloud-native applications.

Edge computing and IoT require containers

Edge Computing and IoT are introducing new use cases that demand low-latency networks. Robotics, autonomous cars, drones, connected living, industrial automation and eHealth are just some of the areas where either low latency is required, or a large amount of data needs to be ingested and processed. Due to the physical distance between the device and public clouds, the viability of these applications depends on the availability of a cloud platform at the edge of the network. This can help operators and MSOs leverage their low-latency access networks—their beachfront property—to enable such applications and create new revenue streams. The edge platforms require cloud-native software stacks to help “cloud-first” developers travel deep inside the operators’ networks and make the transition frictionless.

On the other hand, the devices also require client software, which can communicate with the “edge.” The diversity of such devices such as drones, sensors or cars makes it difficult to install and configure software. Containers can make life easier since they require a version of Linux operating system and container runtime to launch, manage, configure and upgrade software to any device.

The role of intelligence and serverless architectures in the carrier-grade platform

Let’s consider the example of a potential new service for real-time object recognition. By integrating artificial intelligence (AI) and machine learning (ML) algorithms, operators can enhance the edge platform so developers can create applications for pedestrian or obstacle detection in autonomous driving, intrusion detection in video surveillance and image and video search. The operator’s platform that hosts such applications needs to be “intelligent” to provide autonomous services. It requires the ability to host ML tools and support event-driven architectures where computing can be offloaded to the edge on-demand. Modern serverless architectures could be a potential solution for such requirements, but containers and cloud-native architectures are a near-perfect fit.

Are containers ready for carrier-grade workloads?

Containers as a technology have existed for over a decade. Linux containers and FreeBSD Jails are two early examples. However, it was not easy to network or manage the lifecycle of containers. Docker made this possible by simplifying container management and operations, which led to the ability to scale and port applications through containers. Today, the Open Container Initiative of the Linux Foundation is defining the standards for container runtime and image formats. APIs provided by container runtimes and additional tools help abstract low-level resource management of the environment for application developers. Container runtimes can download, verify and run containerized application images.

The production applications are typically composed of several containers that can independently scale. To manage such deployments, new software ecosystems have emerged that primarily orchestrate, manage and monitor applications across multiple hosts. Kubernetes and Docker Swarm are examples of such solutions, commonly called container orchestration engines (COE).

Some of the key challenges for carrier-grade deployments of container-based platforms are:

  • Complex networking with several alternatives for overlay and underlay networks within a cluster of containers
  • Lack of well-defined resource-management procedures like isolating containers with huge pages, CPU pinning, GPU sharing, inter-POD, node-affinity, etc.
  • Complex deployment techniques are required to deploy multi-homed PODs
  • Large ecosystems for securing container platforms as it is not easy to deploy and manage large container security solutions

SNAPS and Containers

SNAPS, which is short for SDN/NFV Application Development Platform and Stack, is an open-source platform developed by CableLabs. The platform enables rapid deployment of virtualized platforms for developers. SNAPS accelerates adoption of virtual network functions by bootstrapping and configuring a cloud platform for developers so they can focus on their applications. Aricent is involved in the SNAPS-OpenStack and SNAPS-Boot projects and contributed to the platform development with CableLabs.

An obvious next phase is to enable containerized platforms. A key first step was already achieved in the SNAPS-OpenStack project where Docker containers are used for executing many OpenStack components. The next obvious step is to create a roadmap for enabling containers for application developers. A cursory look at the cloud-native landscape reveals that this ecosystem is huge. There are several options available for DevOps, tooling, analytics, management, orchestration, security, serverless, etc. This can create confusion for developers regarding what to use and how to configure these components. They will have to “learn” the ecosystem, which will delay their own application development. The future roadmap for SNAPS is to enable developers by bootstrapping a secure and self-service container platform with the following features:

  • Container orchestration and resource management
  • In-built tooling for monitoring and diagnostics
  • A reference microservices architecture for application development
  • Easy management and deployment of container networking
  • Pre-configured and provisioned security components
  • DevOps-enabled for rapid development and continuous deployment

These are exciting times for developers. The availability of platforms and technologies will drive innovation throughout the developer community. The SNAPS community is focused on ensuring that the best-in-class developer platforms are created in the spirit of open innovation. The SNAPS platform roadmap adopting cloud-native ecosystem is going to provide developers an easy-to-use platform. We are looking forward to a larger participation for the developer and operator community. As a community, we must solve the key challenges and create a resilient platform for containerized application platform for network applications.

Have Questions? We’d love to hear from you: 

--

The author, Shamik Mishra, is the Assistant VP of Technology at Aricent. SNAPS, CableLabs’ SDN/NFV Application Development Platform and Stack Project, was developed leveraging the broader industry’s open source projects with the help of the Software Engineering team at Aricent. CableLabs selected Aricent for this specific project because of their world-class expertise in software-defined networks and network virtualization. In a little less than a year, CableLabs and Aricent worked closely to extend CableLabs’ initial code base to the full SNAPS platform. The SNAPS platform has now been released to open source to enable the wider industry to collaboratively build on our work and to use it to test new network approaches based on SDN and NFV.

Comments
Virtualization

NFV License Management: The Missing Piece of the Puzzle

Don Clarke
Principal Architect, Network Technologies

Jan 4, 2018

Ever experienced the annoyance of trying to install or reinstall licensed software on your PC only to find that you lost the license key? Imagine the challenge of managing software licenses in a large complex organization such as a telecommunications operator with hundreds, if not thousands or even tens of thousands, of licenses spread across many critical systems. How many licenses are in use at any given moment? How many are expired or technically in breach of commercial agreements with vendors?

I could go on, but you get the gist. Software license management in the telecommunications environment is about to become an order of magnitude more complex as NFV emerges from the shadows to become the technology of choice for future telecommunications network infrastructures!

Physical network appliances, purchased with a packet of software licenses, wrapped up in a commercial agreement with a single vendor and fixed for several years are about to be displaced by racks of servers running thousands of ephemeral instances of Virtual Network Functions (VNFs) and other types of critical software originating from a myriad of diverse sources - and changing minute by minute according to changing demands on the network.

Welcome to the brave new world of NFV.

How Software Licensing Underpins the Economic Viability of NFV

As one of the leaders of the group of network operators who introduced the NFV concept in 2012, I have been aware since the very beginning of the critical role that software licenses will play in the economics of NFV. Once a rack of servers is installed, software licensing becomes a significant recurring cost, as anyone who purchases software will know all too well. It might seem obvious, but there shouldn’t be any technical barriers to the implementation (and enforcement) of any type of commercial licensing agreement between network operators and software providers.

The ability to negotiate and concurrently implement different software licensing regimes with different software providers is a very important competition dynamic for NFV. Interoperability for automated license management transactions between software providers and network operators will be crucial and we want to level the playing field for innovative small software vendors to engage with the cable industry by specifying standardized approaches.

Leveling the Playing Field for Small Software Vendors

I hadn’t thought much more about NFV License Management until the summer of 2015 when I was approached at a Silicon Valley conference by the marketing director of a small independent software vendor. He said his company was very concerned that they might be excluded from NFV procurement contracts because network operators would not be motivated to implement proprietary license management arrangements with more than a few predominantly large players. I was very concerned about this because the whole point of NFV was to open the telecommunications ecosystem to small innovative software players. A vibrant and open telecommunications ecosystem is something I feel passionately about, and I resolved to do something about it.

Why do we need standards for NFV License Management?

Today there is huge diversity of license management mechanisms across the software industry which is reflected in the product offerings from Virtual Network Function (VNF) providers. Each network operator and VNF provider has a different licensing and enforcement process and the rate of change for software is increasing. Clearly, this will make service provisioning and license renewal operations more complex, error-prone and time-consuming. How will VNF providers know that their software is being used according to the license terms? And network operators need to ensure that any failure in license acquisition or enforcement does not lead to service outage.

These issues can be resolved by establishing a standard NFV license management architecture which, in addition to facilitating software vendors creating their own, independent, commercial licensing terms, would have many benefits, including:

  • Avoiding the need to customize the license management procedure for each VNF type and VNF provider.
  • Simplifying acquisition of VNF license usage information, this is particularly important when dynamically scaling VNF instances to support service demand.
  • Reducing licensing errors which might otherwise lead to service outages.
  • Massively simplified license management operations which are independent of the underlying VNF solution. This, in turn, may result in savings from the ability to optimize actual usage, reducing the waste of digital assets like software licenses.
  • Enabling a competitive ecosystem for NFV software providers.

A guiding principle is to minimize the impact on the existing NFV specifications by identifying the minimum features needed to implement any commercial license management framework typically residing in a separate or higher layer system (e.g. OSS/BSS). I think of this as identifying and specifying the minimum set of operations necessary to be executed by the NFV Management & Orchestration (MANO) system to acquire VNF software licenses and monitor their usage.

Addressing the NFV License Management Challenge

I encouraged discussion on this topic in the ETSI NFV Network Operator Council and there were notable contributions from BT, Korea Telecom and others which raised global awareness.

Peter Willis at BT summed up the network operator requirements for NFV license management very nicely in an influential contribution:

  • All VNFs should use the same methods, mechanisms and protocols.
  • Processes should be fully automated requiring no manual intervention and scalable to 10’s of Millions of VNF instances.
  • There should be no common mode failure mechanisms.
  • Networks should be able to bootstrap in all possible scenarios.
  • Customers should not lose service due to administrative errors (i.e. VNFs should default to running).
  • All commercial VNF licensing models should be supported without requiring VNFs to be re-written or upgraded.
    • Peter provided some interesting examples: Perpetual, pre-pay, post-pay, pay-per-use, pay-per-GByte, pay-per-Gbit, pay-by-maximum-instances, pay-per-day, pay-per-month, pay-per-minute, etc.
  • VNF “usage” accounting should be independent of “billing” (i.e. it should be possible to turn “usage” data into a “bill” using a third-party application).
  • “Usage” data should be authenticated & auditable (a key concern for VNF providers).

With the network operators fully on board, an ETSI NFV Work Item was initiated to study the topic and to publish a set of recommendations that the industry could sign off on. Abinash Vishwakarma at NetCracker volunteered to lead the work which started in the autumn of 2016.

Recommendations Published

I am really pleased that just as everyone was heading home for the holidays, ETSI NFV delivered the Report on License Management for NFV. This work took months of collaborative effort and is a very important step for the industry. It documents the features required to be implemented within the NFV Architectural Framework to support NFV License Management. These features will enable any combination of commercial license management regimes without implementing proprietary license management mechanisms.

The ETSI NFV work is complemented by work in TM Forum on NFV License Management addressing the higher layer requirements.

Next Steps

The next step will be to specify the necessary features within the ETSI NFV Architectural Framework and associated APIs that may be required to support License Management. This work is targeted to be completed in time for Release 3 of the ETSI NFV specifications in the summer of 2018.

Meanwhile, I am in dialogue with software providers to encourage them to get involved in this critical next stage of ETSI NFV work and to begin developing product road-maps to support NFV license management with the features and scalability required for telecommunications-grade operations.

What is CableLabs doing in this space?

CableLabs has been working on SDN and NFV for over four years. We have studied the impact of NFV in the cable environment, including the home environment and the access network. We are also making a significant contribution to the collaborative industry effort on NFV. We hold leadership positions in ETSI NFV and our NFV & SDN software stack – SNAPS is part of OPNFV. We actively encourage interoperability for NFV and SDN solutions and CableLabs’ subsidiary Kyrio operates SDN-NFV interoperability labs at our Sunnyvale-CA and Louisville-CO locations, which enable vendors and operators to work together to validate interoperability for their solutions.

ETSI NFV has created the foundation standards to deliver carrier-grade virtualization capabilities for the global telecommunications industry. You can find more information at ETSI NFV Industry Specification Group. To stay current with what CableLabs is doing in this space, make sure to subscribe to our blog.

--

Don Clarke is a Principal Architect at CableLabs working in the Core Innovation Group. He chairs the ETSI NFV Network Operator Council and is a member of the ETSI NFV leadership team.

Comments
Virtualization

  NFV for Cable Matures with SNAPS

Randy Levensalor
Principal Architect, Future Infrastructure Group, Office of the CTO

Oct 10, 2017

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.

Background

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

  1. 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.
  2. Provides transparent API’s for various kinds of infrastructure
  3. Reduces the complexity of integration testing
  4. 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.”

NFV for Cable Matures with SNAPS

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:

  1. Shorter development times
  2. Operator resources savings
  3. 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):

  1. 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.
  2. 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.

NFV for Cable Matures with SNAPS Aricent

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 r.levensalor@cablelabs.com 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.

Comments
Virtualization

SNAPS-OO is an Open Sourced Collaborative Development Resource

Randy Levensalor
Principal Architect, Future Infrastructure Group, Office of the CTO

Mar 21, 2017

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.

Next Steps

  • 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.

Comments
Networks

Network Operator Perspectives on NFV priorities for 5G

Tetsuya Nakamura
Principal Systems Architect, Network Technologies

Feb 21, 2017

Today, twenty-three network operators published a white paper to guide the industry on priorities for NFV to deliver the industry vision for 5G systems: "Network Operator Perspectives on NFV priorities for 5G". The network operator co-authors include Bell Canada, BT, CableLabs, CenturyLink, China Mobile, China Unicom, Colt, Deutsche Telekom, KDDI, KT, NTT, NTT DOCOMO, Orange, Portugal Telecom, Rogers, SK Telecom, Sprint, STC, Swisscom, Telecom Italia, Telefonica, Telenor, and Vodafone. As managing editor for this white paper, I worked closely with colleagues from these leading organizations to document some key consensus requirements that we want the 5G standards community to take into account in their upcoming specification work.

We believe the evolved 5G network will be characterized by agile resilient converged fixed/mobile networks based on NFV and SDN technologies and capable of supporting network functions and applications encompassing many different networks and services domains. The breadth of foreseen 5G use cases and environments implies high scalability, ultra-low latency and ability to support a massive number of concurrent sessions, as well as ultra-high reliability and security. To achieve these ambitious goals, Network Slicing, Cloud-native design principles, End-to-end Service Management, Edge Computing, RAN Cloudification, Multi-site/domain Services, NFV License Management, Security, Reliability, and Scalability are important enablers as outlined in some detail in this paper.

In an era of increasingly stretched resources, it is vitally important for standards development organizations and open source communities to avoid re-invention and wasteful duplication of effort. Hence, an important message is to encourage reference to the extensive body of foundational NFV specification work already published by the ETSI NFV Industry Specification Group over the past four years as the basis for 5G.

As managing editor, I believe this white paper should be used as guidance for the wider industry on how NFV should be used to realize 5G use cases.

What is CableLabs Doing in this Space?

The cable network will provide an ideal foundation for 5G because it is ubiquitous and already supports millions of Wi-Fi nodes in places where the majority of wireless data is consumed. It has high capacity for both Access and Backhaul. It is highly reliable and has low intrinsic latency because it is based on optical fiber which penetrates deep into the access network feeding wideband coaxial cables reaching all the way to the end-user premises. Moreover, it is a multi-node remotely powered access topology ideally suited to support the connection of the large number of small cells close to homes and businesses that will be needed for 5G.

A multi-faceted CableLabs R&D program is addressing the key technologies required for 5G around NFV and SDN that we are executing on behalf of our cable operator stakeholders. For example, CableLabs is progressing an intensive study of virtualized provisioning of the cable access network to enable programmability, our NFV/SDN reference platform is based on OPNFV and we are looking ahead to support 5G using an end-to-end virtualized architecture that includes low latency edge compute nodes located at the cable head-end. In addition, we are seeking to accelerate NFV/SDN interoperability through CableLabs’ Kyrio subsidiary which has built an interoperability lab where vendors can work together with operators to toward their NFV and SDN solutions.

By Tetsuya Nakamura, Principal Architect, Strategy & Innovation, CableLabs

Comments
Virtualization

Network and Service Management – The Missing Piece for NFV

Don Clarke
Principal Architect, Network Technologies

Jan 12, 2017

Network Functions Virtualization (NFV) enables telecommunications networks to be implemented in software running on high volume industry standard servers as outlined by network operators in a seminal white paper published in 2012. NFV standards have been under development in the ETSI NFV Industry Specification Group since the early part of 2013. The ETSI NFV work provides the foundation for NFV and is being referenced by standards organizations globally, and new open source software communities have sprung up to accelerate NFV implementation. I’ve written about industry progress on NFV in previous blogs but we still have some way to go before NFV is commonplace in telecommunications networks.

The key pieces of NFV, notably Virtual Network Functions (VNFs) run on industry standard compute platforms – basically datacenters; and must be dynamically configured and connected at scale to deliver tangible value; automation is absolutely vital for success. Cloud players such as Amazon and Facebook have mastered automation within the confines of their proprietary datacenters, and as a result their operations require orders of magnitude fewer people. New products and services appear at the speed of code, and customer self-service is taken for granted. Concepts that exploit automation such as Machine Learning are being applied which is supercharging the ability of cloud operators to optimize their systems and create cool new stuff. We in the telecoms industry need to also become masters of automation or we will be left behind in the inexorable march to a software defined future.

While the ETSI NFV Industry Specification Group has worked very hard on the “nuts and bolts” of NFV with a keen eye on automation (in my book the most important benefit of NFV), the industry hasn’t made much headway on the key pre-requisite: automation of the Operations environment. Collaboration to address this essential capability is vitally important for the industry to remain competitive and deliver what our customers need in the future.

Information Modeling and Network Automation

Two very important industry initiatives are underway that will accelerate progress. The first initiative is to harmonize information modeling approaches across the telecoms industry (standards and open source). Unless Standards Development Organizations (SDOs) in the different network domains align their information modeling approaches, network operators will have to deal with an ever increasing degree of complexity as they seek to create new networks and services based on NFV. The second is a new industry-wide effort to foster collaboration on Networks and Service Management.

Towards achieving these goals, in January 2016, CableLabs hosted the first multi-SDO and Open Source workshop on Information Modeling which was widely regarded as the moment when the industry realized the value of harmonization. Aligning Information Modeling approaches is a critical first step to achieving network automation (see the blog by my colleague Tetsuya Nakamura). Information models are the “templates” needed to orchestrate compute resources into a meaningful configuration. In the cloud environment, these templates are used routinely, and we need to use them as well, but unlike cloud operators who work in a proprietary, mostly homogeneous environment, telecoms network operators work in a heterogeneous environment spanning many different network domains and referencing standards coming from many different SDOs. Applying cloud technologies in such an environment is extremely complex. Fortunately, SDOs and Open Source communities have recognized this challenge and an unprecedented era of cross-industry collaboration is getting underway.

Multi-SDO Collaboration is not simple, or it would be routine. The first barrier is the focus of individual SDOs on a narrow domain. Other barriers are culture and modus-operandi, and leadership teams motivated by agenda and timelines specific to their domain. Not to mention the dreaded IPR which can stymie even the most worthy of collaborations.

Second Multi-SDO Information Modeling Workshop

To build and maintain momentum, Deutsche Telekom hosted the second Multi-SDO Information Modelling workshop in Bonn-Germany last month. I co-chaired the event with Klaus Martiny at Deutsche Telekom and Michael Brenner at GigaSpaces, and my CableLabs colleague Tetsuya Nakamura played a key role in organization. The workshop dovetailed with another milestone event, the first cross-industry workshop on Networks and Service Management organized by Deutsche Telekom which addressed the broader challenges for automating telecoms networks.

Participants from the following organizations presented their views on harmonizing information modeling:  3GPP (SA5), ARIA, Broadband Forum, ETSI NFV, IETF, IISOMI, ITU-T, MEF, NGMN, OASIS/TOSCA, ONF, OSM, OPEN-O, ON.Lab/CORD, and TM-Forum.

The discussions were intense and extremely positive. Clearly the spirit of collaboration and a sense of common purpose are as strong now as they were after the CableLabs hosted first workshop which bodes well for maintaining momentum on alignment. Follow-up collaborative activities are structured around a set of key topics which we identified as high priority to be addressed with named owners from different organizations who will be accountable for progress. A public WiKi has been created for anyone to follow progress. Activities include:

  • Looking at Federated Information Models as a way to get to a Common Information Model.
  • Aligning nomenclature amongst the different organizations in relation to Information Modeling and Data Modeling.
  • Collecting Use Cases and Business Requirements as a way to bind the effort towards a practical goal.
  • Creating and maintaining central repositories for the numerous information models and data models in use across the industry together with descriptive meta-data and open source tooling.

Achieving harmonization is vitally important for the industry to enable automation of the NFV operations environment so we are setting an aggressive timescale to build momentum through 2017.

What CableLabs is doing in this space

We have a number of activities around NFV and SDN that we are executing on behalf of MSOs. For example, CableLabs is progressing an intensive study of virtualized provisioning of the cable access network to enable programmability, our NFV/SDN reference platform is based on OPNFV and we are looking ahead to support 5G using an end-to-end virtualized architecture that includes low latency edge compute nodes located at the cable head-end. In addition, we are seeking to accelerate NFV/SDN interoperability through our subsidiary Kyrio which has built an interop lab where vendors can work together with operators to validate interoperability for their SDN and NFV solutions.

The NFV journey is only just beginning and 5G will be the first new wave of technology to be designed from the ground up using NFV and SDN technologies. The cable industry, with our low latency access network, is in a leadership position to advance these technologies for the benefit of MSOs and their customers globally.

Comments
Security

  Improving Infrastructure Security Through NFV and SDN

Steve Goeringer
Distinguished Technologist, Security

Nov 4, 2016

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.

Comments
Virtualization

Snapping Together a Carrier Grade Cloud

Randy Levensalor
Principal Architect, Future Infrastructure Group, Office of the CTO

Sep 27, 2016

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.

Current Environment

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

Performance

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, 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.

location-location

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.

Interoperability

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.

Looking Ahead

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.

project-snaps

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.

 

Comments