Market disruption and the explosion of bandwidth consumption are challenging SPs to scale up and increase agility whilst reducing costs. Challenged by major business disruption from web players and over-the-top providers, traditional SPs are looking at the strategies deployed by these competitors. One particular strategy that is of interest, is the migration to white box routers and network disaggregation to create what appears to be massively scalable, hyper agile, inexpensive networks. But is this the full picture? Let’s take a closer look.
Over the last few months we have seen a flurry of announcements around router hardware and software disaggregation such as AT&T announcing that they plan to install more than 60,000 white box routers running their disaggregated Network Operating System (dNOS).
Cisco is at the forefront of this movement and top-level executives across the board have announced that some of our leading products will be available as disaggregated options.
Cisco Embraces Disaggregation
Yvette Kanouff, SVP/GM Service Provider Business Unit, announced the disaggregation of Cisco IOS XR and the support for new and innovative consumption models.
Roland Acra, SVP Data Center Business Unit, announced support for the Switch Abstraction Interface (SAI) on our Nexus platforms allowing customers to run the Network Operating System (NOS) of their choice on our SAI-ready Nexus platforms.
Cisco made it possible for our customers to run NX-OS on third party hardware platforms.
IOS XR programmability was enhanced through two new APIs:
- The Service Adaptation Layer (SAL) provide programmability access to the routing control plane
- The Open Forwarding Abstraction (OFA) Layer which provides access to the forwarding and telemetry capabilities of the underlying hardware (see “Enabling IOS-XR on Third-Party Network Hardware”).
- You can now exercise the APIs to develop new features, integrate with external protocol modules and solve your specific business problem at your own software development speed.
Both IOS XR and IOS XE support Application Hosting, enabling various Cisco and third party applications to be hosted in Linux containers (LXC).
Different Levels of Disaggregation Bring Different Benefits… and Challenges
The basic premise of router disaggregation is the decoupling of the NOS from the underlying hardware (see Figure 1). This gives a customer the flexibility to source the NOS of their choice and match it with a white label hardware platform that fits their requirements. The ideal scenario is that the NOS operates as an application which can be installed on a wide range of supported Linux distributions. The white label hardware platform is expected to be Open Compute Project (OCP) compliant, supporting the Open Network Install Environment (ONIE). The OCP provides standardized interfaces and procedures to boot and run a 3rd party NOS on a white box. With this model, the NOS is decoupled from the hardware, but customers are still bound to the NOS vendor to provide features, updates and innovation based on their roadmap.
The next level of disaggregation is the de-layering of the NOS and exposing APIs at various levels, moving to an open and modular model. We’ve seen a lot of use cases typically associated with network disaggregation being solved in this manner. Let’s take a look at the various layer groupings.
- Routing Protocols and Applications Layer – This layer contains protocols (BGP, ISIS, OSPF etc.) and features such as L2VPN, L3VPN. It also exposes command line interface (CLI) for features and protocols in the network application layer along with model-driven APIs for use with automation tools.
- Network Infrastructure Abstractions Layer – Typically consists of components such as the RIB, Label Switch database, BFD, network interface handler and APIs on for higher layers/agents. The SAL API allows access to these components which in turn enable the development of applications.
- Forwarding Abstractions Layer – This layer interacts with the ASIC SDK (provided by the ASIC vendor) and handles programming of the data plane based on RIB state, or label switch database (LSD) state etc.
- White box hardware – Consists of the ASIC , micro server (see Figure 2) that handles forwarding decisions and provides hooks (through the ASIC SDK) to help program route lookup tables in the hardware. Other system components such as the board management controller, fans, sensors and optics make up the rest of this layer.
The disaggregated and modular models will create a lot of opportunities by driving openness, creating a larger ecosystem of vendors and open source projects that will accelerate innovation.
The flip side is that someone has to pull together and validate the router stack, integrate the software and hardware combinations that each SP will decide to deploy. In essence every combination of software with white label hardware becomes a new platform deployment. In some cases, it is expected that the NOS vendor will be responsible for certifying a set of OCP compliant white label boxes, while in other cases the task may need to be driven by the SP. The question of technical support and the triaging between the various vendors is also one of high interest. We will see how Cisco is stepping up in to solve these challenges later in the blog.
Disaggregation Promises Many Benefits
Let’s take a look at the key benefits:
- Software Feature Development Speed – By opening up the monolithic router, an open ecosystem of collaborative software vendors can be created. The expectation is that the speed of software features as well as new technology introductions will be increased.
- Hardware Platform Independence – By severing the bond between hardware and software, plug-and-play scenarios can be realized, allowing faster hardware innovation adoption, independent from software integration with OSS systems. Essentially the HW and SW innovation are independent of each other.
- Cost efficiency – By driving standardization in the hardware and opening up the software market, a unit cost reduction is expected.
- New Operating Paradigms – Disaggregated systems follow traditional “server” designs such as board management controllers (BMC), NOS installed as native Linux application utilizing Linux facilities for image management, SSH access, DNS, etc. Given the model the model based API programmability of modern NOSs, they can now be managed with toolchains that have been developed in the web and IT networks, increasing automation and improving various KPIs such us software release time, reduction of outages due to change, uptime, etc.
Is Disaggregating SP Networks Mission Impossible?
That’s all great for Web players and their “no-legacy” infrastructures. But can Service Providers benefit from the promises of disaggregation? Looking at the typical SP network, the difficulty of the disaggregation challenge is quickly apparent. SP networks are complex environments with different domains and requirements (see Figure 3).
A lot of interest is seen in the access domain, especially in cell site routers, given the expected rollout of 5G services. At the time of writing, every major white box vendor (Accton, Agema, Dell, Edgecore, Quanta etc..) are focusing on building “pizza-style” single NPU, single rack unit boxes which seem to be a good fit at the cell-site. The scale of deployment is expected to be in the 10s of thousands of devices, promising cost-effective rollouts, but also creating interesting staging and deployment challenges.
In the aggregation domain, feature rich, high capacity and high availability solutions are needed to support the SP offerings of commercial as well as residential services. A few SPs are looking at disaggregated solutions in this space (see DT Access 4.0), requiring spine-leaf designs which are more akin to the data center architectures.
Moving on towards the core domain, we do not see yet any initiatives for disaggregation. The high capacity, density and cost efficiency profile of this domain makes the modular, multi-chassis integrated systems the clear choice for these locations.
Finally, the DC domain is the sweet spot of disaggregated routers, in TOR, spine and leaf roles. This is especially true in the web scale DCs, who have adopted the disaggregated model at scale.
The end to end deployment of solutions with disaggregated routers raises the question of who will be responsible for testing and validating the design, ensuring that the design will meet requirements and then committing to the timely rollout of the solution. Even more importantly, once in production, who will be responsible for optimizing it on an ongoing basis?
Cisco is Stepping Up to Solve SPs’ Challenges
How can Cisco Services help you to achieve these benefits? We are working with all SPs considering disaggregation and already having conversations on how address some of their concerns and support their plans, especially as SPs are thinking to operationalize the disaggregated routers. Throughout these engagements, a few common concerns are surfacing, such as:
- Is disaggregation the right model for me?
- Who will certify my choice of software and white label hardware?
- Can I get a tested and validated design that supports my requirements, end to end?
- Staging and deployment? In some use cases the quantities are massive.
- What is the support model? Do I have to triage the various software and hardware vendors or can Cisco do it for me?
- Can Cisco provide technical support for 3rd party software on 3rd party hardware?
- I would like a single support number to call for vendor agnostic support.
Today Cisco Services is ready to support engagements with disaggregated routers. Our goal is to provide the same high value Cisco customer experience to disaggregated router engagements as we do to our typical integrated router engagements. Our customers should not experience a difference. The complete services portfolio, from advisory, implementation, optimization, cloud managed services and technical support services has been reassessed in support of this goal.
- Our Advisory Services capabilities can open a disaggregation conversation with the customer and ensure they get the best outcome
- We have considered the market need from a single router perspective and how we solve the multi-party technical support challenge. To that effect, our technical assistance services are ready to support Cisco IOS XR and NX-OS software on Cisco certified 3rd party white label hardware
- We have also looked at the end to end customer solution validation with our Solution Validation Services (SVS) and have trained and skilled our teams on key 3rd party white label hardware solutions
- Our Services engineers have been studying and learning, hands on, the behavior, boundary parameters, limitations of key 3rd party white label hardware and are ready to lead the design, planning and implementation of end to end customer networks.
Separating the software from the hardware and opening up the ecosystem promises significant benefits, both from an increased innovation and device cost optimization perspectives. But to achieve this, Service Providers want help putting the solution back together, managing the total cost of ownership, mitigating the risk associated with new platform introductions as well the ongoing technical support and optimization. This naturally extends to disaggregated systems, which will be widespread in our largest SP customers. Service Providers require a partner that has the experience, expertise, scale and financial stability to see this transition through.
With the largest and most complete network design and support capability in the world, Cisco is the only partner that is ready to operationalize your choice of white label box.
Learn more about Cisco Services.
Blog contributors: Carlos Pignataro, Jeff Apcar, Steve Iatrou
Let's not just open up the monolith, let's eliminate it.
Providing contracts between the layers will streamline integration points and ease the implementation of service-oriented layers.
Comments are closed.