Survey just about any large-scale network these days and you’ll find that they’re increasingly dominated by the two “Big Ds”: distribution and disaggregation. From mobile operators’ radio access networks (RAN) to service providers’ sprawling hyperscale edge networks, forward-looking organizations keep pushing advanced services closer to users. As they do, they’re deploying their networks in more flexible and cost-effective ways, running some functions from thousands of smaller sites closer to the customers, while maintaining centralized cloud control.
These distributed cloud architectures offer major advantages to service providers and other large network operators for certain use cases. But they also introduce a new problem: often, the locations housing distributed networking functions are small, remote and severely space- and power-constrained. Previously, there was only one solution to this problem: deploy new physical routing appliances at each of those thousands of sites, at exorbitant cost. But today, service providers and network operators have another option. They can deploy routers as cloud-native software and run them on the same existing physical server as other distributed applications, such as an O-RAN Distributed Unit (DU).
It’s a powerful alternative. And Juniper Networks can help service providers take advantage of it with the Juniper Cloud-Native Router (J-CNR). This software-only solution provides everything that people love about Juniper and Junos software. But it delivers it in a fully cloud-native package that fits perfectly into evolving large-scale distributed networks.
Going Cloud-Native
Juniper’s Cloud Native Router delivers many of the advanced software capabilities as our hardware-based platforms, with the same Junos experience, in a containerized, cloud-native solution. It combines a cloud-native version of Junos routing, and management components called containerized Routing Protocol Daemon (cRPD), with our Contrail Data Plane Development Kit (DPDK) virtual router forwarding plane for x86 and ARM processors. Deployed within cloud-native environments, the J-CNR seamlessly leverages the Kubernetes operator and controller framework by design, exposing full networking capabilities via a Kubernetes Container Network Interface (CNI).
With the J-CNR, service providers and network operators can:
- Reduce Capital and Operating Expenses (CapEx and OpEx): J-CNRs require far less capital investment than traditional hardware appliances, especially for distributed RAN and edge networks with tens of thousands of sites. They are frugal with resources and their performance scales with the resources made available to them.
- Maintain a unified end-to-end routing experience: J-CNRs support the same operational model as Juniper’s physical routers. That means your Ops team can manage an entire Juniper deployment, including other CNRs and physical routers at larger sites, with the same familiar software experience. Meanwhile, you can position your organization for the future with a thoroughly, unapologetically cloud-native solution.
- Tap into cloud-native management and orchestration: As a fully Kubernetes CNI-compliant solution, J-CNRs can be managed via Kubernetes orchestration. This is like the operations models pioneered by the cloud hyperscalers and represents a much simpler deployment and operations model than traditional virtualized solutions.
- Bring advanced routing to constrained locations: In many cases, using traditional routers would not be optimal for the performance needs of smaller distributed sites—and they can add significant new operational requirements. Deploying advanced Juniper routing capabilities as cloud-native software offers a compelling alternative.
Building a Distributed RAN
Let’s consider just how much transformation service providers must undertake as they embark on their 5G RAN journey.
5G requires much higher RAN density than previous networks, so upgrading the same cell sites used for 4G simply won’t be enough. Service providers and network operators will need many more—likely tens of thousands more sites. To connect these sites as efficiently as possible, they’ll want to employ Distributed RAN (D-RAN) architectures for many of them. The challenge is that these sites can be severely power- and space-constrained, often with just a small equipment cabinet under the cell tower. Yet, given the complex nature of distributed 5G cloud RANs, advanced routing features are still needed. And, since service providers are managing thousands of sites, they will need a programmatically driven routing function. Enter the J-CNR.
The J-CNR fits perfectly within a D-RAN/5G cloud RAN strategy, deployed on the same physical server running the DU and other RAN components such as Intel FlexRAN (Figure 1). It substantially lowers CapEx compared to physical appliances while saving on real estate, power and more by consolidating two boxes into one.
In future blogs, we’ll dive into the D-RAN use case and architecture in more detail, and address other use cases, such as hyperscaler-telco Virtual Private Cloud (VPC) interconnects.
Reimagining Operations
Cloud-native or not, the J-CNR is still a Juniper router. So, it’s not enough for it to be “good enough,” it must work brilliantly. That means it needs to fit seamlessly within our customers’ operational frameworks for deployment, configuration and lifecycle management—both today and in the future.
That’s not a trivial task. The emerging cloud-native world brings exponential growth in the number of discrete software components to control—orders of magnitude more than traditional networks. And there are so many aspects of these environments that can be tweaked and customized, that trying to automate them using traditional methods quickly becomes overwhelming. The only way to prevent cloud-native complexity from spiraling out of control is via scalable, productized automation. Which, for today’s cloud-native software, means Kubernetes orchestration.
Juniper has devoted significant attention to ensuring the J-CNR is fully controllable via Kubernetes, including the implementation of CNI abstraction for the entire software package and the development of a full Kubernetes Operator extension to facilitate management. To Kubernetes, the J-CNR looks like any other Kubernetes CNI—albeit a very powerful one. At the same time, full operator support brings rich routing-specific context to what would otherwise be an opaque Kubernetes workload. The result: customers can fully configure, control and lifecycle-manage the J-CNR via Kubernetes. And they can begin moving away from traditional element management systems and start transitioning toward an automated, cloud-native operational model.
Envisioning the Cloud-Native Future
Cloud-native routers won’t replace the need for traditional, high-performing routing appliances in many parts of the network, at least not any time soon. But they offer a flexible new way to augment traditional infrastructure—and a powerful strategy to reap the benefits of distributed, disaggregated networks.
Want to know more? Listen to this episode of the Get Connected podcast with Chris Lewis, where Juniper’s Philip Goddard, Director of Product Management – Software Transformation, shares what goes into building a cloud-native Juniper router.
