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 firstname.lastname@example.org
- 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 email@example.com
- Tweet to @RandyLevensalor
Don’t forget to subscribe to our blog to read more about NFV and SNAPS in our upcoming in-depth SNAPS series. Members can join our NFV Workshop February 13-15, 2018. You can find more information about the workshop and the schedule here.
NFV for Cable Matures with SNAPS
SNAPS is improving the quality of open source projects associated with the Network Functions Virtualization (NFV) infrastructure and Virtualization Infrastructure Managers (VIM) that many of our members use today. In my posts, SNAPS is an Open Source Collaborative Development Resource and Snapping Together a Carrier Grade Cloud, I talk about building tools to test the NFV infrastructure. Today, I’m thrilled to announce that we are deploying end-to-end applications on our SNAPS platform.
To demonstrate this technology, we recently held a webinar “Virtualizing the Headend: A SNAPS Proof of Concept” introducing the benefits and challenges of the SNAPS platform. Below, I’ll describe the background and technical details of the webinar. You can skip this information and go straight to the webinar by clicking here.
CableLabs’ SDN/ NFV Application Development Platform and OpenStack project (SNAPS for short) is an initiative that attempts to accelerate the adoption of network virtualization.
Network virtualization gives us the ability to simulate a hardware platform in software. All the functionality is separated from the hardware and runs as a “virtual instance.” For example, in software development, a developer can write an application and test it on a virtual network to make sure the application works as expected.
Why is network virtualization so important? It gives us the ability to create, modify, move and terminate functions across the network.
Why SNAPS is unique
- Creates a stable, replicable and cost-effective platform: SNAPS allows operators and vendors to efficiently develop new automation capabilities to meet the growing consumer demand for self-service provisioning. Much like signing up for Netflix, self-service provisioning allows customers to add and change services on their own, as opposed to setting-up a cable box at home.
- Provides transparent API’s for various kinds of infrastructure
- Reduces the complexity of integration testing
- Only uses upstream OpenStack components to ensure the broadest support: SNAPS is open source software which is available directly from the public OpenStack project. This means we do not deviate from the common source.
With SNAPS, we are pushing the limits of open source and commodity hardware because members can run their entire Virtualized Infrastructure Manager (VIM) on the platform. This is important because the VIM is responsible for managing the virtualized infrastructure of a NFV solution.
Webinar: Proof of Concepts
We collaborated with Aricent, Intel and Casa Systems to deploy two proof of concepts that are reviewed in the webinar. We chose these partners because they are leading the charge to create dynamic cable and mobile networks to keep up with world’s increasing hunger for faster, more intelligent networks tailored to meet customers' needs.
Casa and Intel: Virtual CCAP and Mobile Cores
CableLabs successfully deployed a virtual CCAP (converged cable access platform) core on OpenStack. Eliminating the physical CCAP provides numerous benefits to service providers, including power and cost savings.
Casa and Intel provided hardware and Casa Systems provided the Virtualized Network Function (VNFs) which ran on the SNAPS platform. The virtual CCAP core controls the cable plant and moves every packet to and from the customer sites. You can find more information about CCAP core in Jon Schnoor’s blog post “Remote PHY is Real.”
Advantages of Kyrio’s NFV Interop Lab
For the virtual CCAP demo, the Kyrio NFV Interop Lab provided a collaborative environment for Intel and Casa to leverage the Kyrio lab and staff to build and demonstrate the key building blocks for virtualizing the cable access network.
The Kyrio NFV Interop Lab is unique. It provides an opportunity for developers to test interoperability in a network environment against certified cable access network technology. You can think of the Kyrio lab as a sandbox for engineers to work and build in, enabling:
- Shorter development times
- Operator resources savings
- Faster tests, field trials and live deployments
Aricent: Low Latency and Backhaul Optimization
With Aricent we had two different proof of concepts. Both demos highlighted the benefits of having a cloud (or servers) at the service provider edge (less than 100 miles from a customer’s home):
- Low latency: We simulated two smart cars connected to a cellular network. The cars used an application running on a cloud to calculate their speed. If the cloud was too far away, a faster car would rear end a slower car before it was told to slow down. If the cloud was close, the faster car would slow down in time to prevent rear-ending the slower car.
- Bandwidth savings: Saving data that will be used by several people in a closer location can reduce the amount of traffic on the core network. For example, when someone in the same neighborhood watches the same video, they will see a local copy of the video, rather than downloading the original from the other side of the country.
The SNAPS platform continues CableLabs’ tradition of bringing leading technology to the cable industry. The collaborations with Intel, Aricent and Casa Systems were very successful because:
- We demonstrated end-to-end use cases from different vendors on the same version of OpenStack.
- We identified additional core capabilities that should be a part of every VIM. We have already incorporated new features in the SNAPS platform to better support layer 2 networking, including increasing the maximum frame size (or MTU) to comply with the DOCSIS® 3.1 specification.
In addition to evolving these applications, we are interested in collaborating with other developers to demonstrate the SNAPS platform. Please contact Randy Levensalor at firstname.lastname@example.org for more information.
Don’t forget to subscribe to our blog to read more about how we utilize open source to develop quickly, securely, and cost-effectively.
SNAPS-OO is an Open Sourced Collaborative Development Resource
In a previous blog, I have provided an overview of the SNAPS platform which is CableLabs’ SDN/NFV Application development Platform and Stack project. The key objectives for SNAPS are to make it much easier for NFV vendors to onboard their applications, provide transparent APIs for various kinds of infrastructure and reduce the complexity of integration testing.
I am thrilled to share our latest SNAPS success. We have written an OpenStack API abstraction library that also contains many automated tests and we have contributed it to the Open Platform for NFV (OPNFV) project at the Linux Foundation. OPNFV is a project where service providers and network vendors collaborate to improve the capabilities and adoption of open source Network Functions Virtualization (NFV). Our results have also been shared at NFV World Congress, SDN World Congress, OPNFV Summit [video], Open Networking Summit (ONS) [video] [pdf] and the Big Communications Event (BCE).
The Rationale for our Approach
CableLabs has deep expertise developing specifications by following a collaborative, iterative approach. In many ways, the open source software development process mirrors many of these specification development processes. In the open source communities, CableLabs provides source code and feedback coming from our integration and debugging activity. In fact, CableLabs contributions are included in key open source projects such as OpenStack and OpenDaylight. In this way, we are making it easier for vendors to use open source projects to build solutions for the benefit of the entire ecosystem.
We have generated practical knowledge and insights through our hands-on experience of building and operating an active SDN/NFV application development lab. And we took vendor neutrality to the next level by basing our software stack on purely open source solutions and based on the OPNFV reference configuration. We did not use versions of OpenStack, OpenDaylight, etc. that have been tested and customized by a vendor. This allowed us to interact with a much larger community for new features and fixes.
The CableLabs team supported by vendors and services providers has moved our project into OPNFV as “SNAPS-OO”, based on the idea that it is an Object Oriented way to work with our SDN/NFV Application development Platform and Stack. The project was quickly accepted and is now being used by the release testing team to verify each OPNFV build. With the integration of SNAPS-OO into the OPNFV FuncTest project, our contributions are now part of the release criteria and suite of tests that will be used at the upcoming OPNFV PlugFest next month.
Some of the benefits that SNAPS-OO delivers are:
- Ease of use for new developers
- A rich library of example applications and test suites
- Support for accessing multiple secured clouds
- Automated cleanup of the NFVI when updates are applied
- Quick identification of component failure(s)
As a result of this open source approach, and in just a few weeks since SNAPS-OO was released, we have seen a significant increase in the level of contributions and adoption.
- Continue to expand the capabilities supported by SNAPS-OO.
- Encourage additional OPNFV projects to use SNAPS-OO.
- Use SNAPS-OO and other tools to run much more sophisticated SDN/NFV workloads.
- Share SNAPS-OO with more open source communities.
How SNAPS-OO Benefits Our Membership
SNAPS-OO is helping to improve the quality of the open source projects associated with the NFV infrastructure and Virtualization Infrastructure Managers that many members are using today and plan to use in the future. SNAPS-OO can be used to validate that the infrastructure is installed properly and it will be playing a key role in the Kyrio NFV Interoperability lab. Future NFV development provided by vendors will benefit from the use of SNAPS-OO. With the variety of workloads that we will be running on our SNAPS platform, we will be able to specify a single configuration that can run future NFV workloads alongside other cloud hosted applications.