Give your Edge an Adrenaline Boost: Using Kubernetes to Orchestrate FPGAs and GPU
Over the past year, we’ve been experimenting with field-programmable gate arrays (FPGAs) and graphics processing units (GPUs) to improve edge compute performance and reduce the overall cost of edge deployments.
Unless you’ve been under a rock for the past 2 years, you’ve heard all the excitement about edge computing. For the uninitiated, edge computing allows for applications that previously required special hardware to be on customer premises to run on systems located near customers. These workloads require either very low latency or very high bandwidth, which means they don’t do well in the cloud. With many of these low-latency applications, microseconds matter. At CableLabs, we’ve been defining a reference architecture and adapting Kubernetes to better meet the low-latency needs of edge computing workloads.
CableLabs engineer Omkar Dharmadhikari wrote a blog post in May 2019 called Moving Beyond Cloud Computing to Edge Computing, outlining many of the opportunities for edge computing. If you aren’t familiar with the benefits of edge computing, I’d suggest reading that post before you read further.
As part of our efforts around Project Adrenaline, we’ve shared tools to ease the management of hardware accelerators in Kubernetes. These tools are available in the SNAPS-Kubernetes GitHub repository.
- Field-programmable gate array (FPGA) accelerator integration
- Graphics processing unit (GPU) accelerator integration
FPGAs and GPUs can be used as hardware accelerators. There are three advantages that we consider when moving a workload to an accelerator:
- Time requirements
- Power requirements
- Space requirements
Time, space and power are all critical for edge deployments. You have limited space and power for each location. The time needed to complete the operation must fall within the desired limits, and certain operations can be much faster running on an accelerator than on a CPU.
Writing applications for accelerators can be more difficult because there are fewer language options than general-purpose CPUs have. Frameworks such as OpenCL attempt to bridge this gap and allow a single program to work on CPUs, GPUs and FPGAs. Unfortunately, this interoperability comes with a performance cost that makes these frameworks a poor choice for certain edge workloads. The good news is that several major accelerator hardware manufacturers are targeting the edge, releasing frameworks and pre-built libraries that will bridge this performance gap over time.
Although we don’t have any hard-and-fast rules today for what workloads should be accelerated and on which platform, we have some general guidelines. Integer (whole number) operations are typically faster on a general-purpose CPU. Floating point (decimal number) are typically faster on GPUs. Bitwise operations, manipulating ones and zeros, are typically faster on FPGAs.
Another thing to keep in mind when deciding where to deploy a workload is the cost of transitioning that workload from one compute platform to another. There’s a penalty for every memory copy, even within the same server. This means that running consecutive tasks within a pipeline on one platform can be faster than running each task on the platform that is best for that task.
Accelerator Installation Challenges
When you use accelerators such as FPGAs and GPUs, managing the low-level software (drivers) to run them can be a challenge. Additional hooks to install these drivers during the OS deployment have been added to SNAPS-Boot, including examples for installing drivers for some accelerators. We encourage you to share your experiences and help us add support for a broader set of accelerators.
These features were developed in a co-innovation partnership with Altran. We jointly developed the software and collaborated on the proof of concepts. You can discover more about our co-innovation program on our website, which includes information about how to contact CableLabs with a co-innovation opportunity.
Extending Project Adrenaline
Project Adrenaline only scratches the surface of what’s possible with accelerated edge computing. The uses for edge compute are vast and rapidly evolving. As you plan your edge strategy, be sure to include the capability to manage programmable accelerators and reduce your dependence on single-purpose ASICs. Deploying redundant and flexible platforms is a great way to reduce the time and expense of managing components at thousands or even millions of edge locations.
As part of Project Adrenaline, SNAPS-Kubernetes ties together all these components to make it easy to try in your lab. With the continuing certification of SNAPS-Kubernetes, we’re staying current with releases of Kubernetes as they stabilize. SNAPS-Boot has additional features to easily prepare your servers for Kubernetes. As always, you can find the latest information about SNAPS on the CableLabs SNAPS page.
Contact Randy to get your adrenaline fix at Mobile World Congress in Barcelona, February 24-27 2020.
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.
Deployment of OpenStack using CableLabs’ SNAPS on Aparna µCloud 4015
OpenStack software controls large pools of compute, storage and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure and it is a popular platform for service providers to run their NFV software. Given the large number of services provided by OpenStack, the deployment methods can be complex—even with excellent documentation provided by the OpenStack consortium.
SNAPS from CableLabs
To reduce the complexity of deployment of OpenStack, CableLabs introduced a set of scripts and a process called SNAPS and has placed these resources in an open source domain. SNAPS allows any organization to deploy a release of OpenStack on a set of compute, storage and network devices with two scripts/processes—as long as these devices meet OpenStack’s minimal requirements.
SNAPS OpenStack deployment scripts involve downloading the latest source/scripts from CableLabs’ GitHub repository and making modifications to a well-documented YAML file that provides details about the controller and compute nodes along with networking information:
- The SNAPS Boot—This document specifies the steps and configuration required for OS provisioning of bare metal machines via SNAPS boot.
- The OpenStack Distribution Deployment—This document specifies the steps and configuration required for OpenStack installation on servers configured by SNAPS Boot.
Aparna Systems’ µCloud 4015
Ideal for SNAPS OpenStack deployment, Aparna Systems’ µCloud 4015 (Micro Cloud) is an ultra-converged, open, compact and high-density hardware platform consisting of compute, storage and network devices ideally suited for deployment at the edge of the network. A µCloud 4015 system:
- Can host up to 15 Intel Xeon (8, 12 or 16 core) µServers with attached storage for two SATA/NVME SSD drives
- Includes the provision of two fabric modules to provide connectivity between µServers as well as to the outside world
To demonstrate the advantages that an integrated and converged system such as the µCloud 4015 can provide, Figure 1 shows Aparna Systems deployment configurations in contrast withed with discrete servers.
In a system with discrete servers, switches and storage modules, setting up interconnections and managing a fresh installation (as well as any additions to the system) can take significant time. By contrast, the number of connections that the µCloud 4015 requires are merely those needed for the network: two for OpenStack data and management networks and two for the fabric management port and preboot execution environment (PXE) network.
Hardware Requirements of OpenStack Installation Using SNAPS
Any OpenStack installation requires servers running as controller, compute and storage nodes (called host nodes), switches to connect these nodes as per the network requirements and a configuration/deployment node to manage the installation. All of these have certain minimum requirements (shown below).
SNAPS OpenStack requires a minimum of three nodes for a basic configuration:
- One controller node and two compute nodes, each with at least 16 GB of memory
- 80 GB hard disk (or SSD)
- Two mandatory and one optional network interfaces
These nodes must be network boot enabled and Intelligent Platform Management Interface (IPMI) capable. Our test configuration includes three PXE boot enabled µServers, each with an Intel Xeon D1541 processor, 64 GB of memory and standard IPMI interfaces.
SNAPS OpenStack deployment requires three network interfaces: management, tenant and data. The tenant interface is an internal interface between the deployed nodes in the system and doesn’t require an external connection from the fabric module to the external world. However, the other two interfaces—management and data—must be connected to the external world.
Two 40G/10G ports of the fabric module are connected (either in the breakout mode or straight connection) to an external switch, which in turn lets the data and management interfaces be connected to the external world, as Figure 1 shows. The single-root I/O virtualization (SR-IOV) feature of the Intel Xeon D processors is used to create virtual interfaces from the single 10G interface to the fabric module of each of the µServers. PXE networking is enabled by using the fabric management (1G) network.
According to the SNAPS guide, a server machine with 64bit Intel/AMD architecture with 16GB RAM and one network interface is required. This machine must be able to reach the host nodes via IPMI. An external machine matching or exceeding these criteria is used.
A µCloud 4015 can be used as a fully configured and prebuilt OpenStack system by using one of the µServers as a build/configuration node. This mode is also verified in the SNAPS OpenStack installation scripts.
SNAPS OpenStack Deployment—Adaptation Summary
To install OpenStack using SNAPS scripts, changes to the deployment process were necessary. However, one of the main criteria in using SNAPS scripts to deploy OpenStack is to avoid any system changes to the configuration/deployment node, as the same server could be used for different purposes in a lab environment. This has been achieved in Aparna Systems’ deployment by implementing all the changes and adding services on the fabric module of the µCloud 4015 system. These particular changes—including enabling BMC network access from an external configuration server and PXE boot changes—can be accessed on the CableLabs GitHub.
In addition, SR-IOV configuration changes are applied on each of the µServers to enable multiple virtual interfaces with a single physical 10G interface from the µServer to the fabric module. These are used in data, management and tenant networks of the OpenStack deployment.
Once SNAPS boot is completed, OpenStack deployment is achieved by modifying the “deployment.yaml” file with the IP addresses of the controller and compute nodes (and additional information), and running the script with appropriate parameters. This process is well documented at the SNAPS GitHub repository.
CableLabs Support Success
The support provided by the CableLabs team during this process has been immensely helpful in resolving issues that are specific to the µCloud 4015 deployment. The SNAPS team also gathered some valuable feedback from this adaptation exercise that could be useful for the enhancement of the scripts for future versions. Interested in learning more about the SNAPS platform in the future? Don't forget to subscribe to our blog or contact CableLabs Lead Architect Randy Levensalor.
 CableLabs does not endorse or certify the Aparna platform and similar platforms are available from other vendors.
The author, Ramana Vakkalagadda, is Director of Software Engineering at Aparna Systems.
Container Workloads: Evolution of SNAPS for Cloud-Native Development
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:
- Send an email directly to email@example.com
- Contribute to the documentation, backlog and code on GitHub
- Reach out on IRC: Server: Freenode Channel #cablelabs-snaps
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.
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 firstname.lastname@example.org
- 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 email@example.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.
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.