Going beyond the monolithic model
We’ve known for nearly a decade that hosted “network functions” were going to play a growing role in new telecom and Internet services. Why then is the concept still struggling? The answer is that the models for function hosting have been tied too closely to the monolithic-boxes model of networking’s past. They need to be tied to the cloud; the thing that’s networking’s future. DriveNets, whose disaggregated Network Cloud model of routing and switching, already breaks the monolithic-box barrier, is offering a true cloud-compatible pathway to network functions, the “Network Cloud Network Function” or NCNF.
Virtual functions came out of the efforts of an ETSI Industry Specification Group for Network Function Virtualization (the NFV ISG) almost a decade ago. But NFV aimed at per-customer higher-layer features, “virtual CPE” rather than virtual routing. More recently, the O-RAN Alliance defined function hosting for 5G in a more general way, through a pair of RAN Intelligent Controller (RIC) elements, and these provide the orchestration and management of 5G RAN features in the “O-Cloud”, but O-RAN is focused on higher-layer mobile-network elements and not on IP.
The value behind the RIC concept is its ability to coordinate RAN resources with a very fast response time, and to couple highly agile RAN service elements to traditional management and higher-layer cloud service elements. That demonstrates that future services need their hosted elements to be optimized as service elements and not as traditional applications, and that’s something DriveNets has known from the first.
Hosting new service features while delivering greater capacity
The Network Cloud contains CPU and GPU resources, but also custom Network Processing Units (NPU), and the rules for deploying and configuring this broader resource set aren’t enforced by traditional network cloud orchestrators. Failover and scaling also have to be faster in the Network Cloud, to meet networks’ stringent availability requirements. DriveNets’ Network Operating System (DNOS) and Network Orchestrator (DNOR) were designed to meet these requirements, and the architecture those tools create can also be used to support third-party service elements today.
All this means that DriveNets’ Network Cloud combines capacity greater than monolithic routers with a more generalized ability to host new service features, above IP as 5G or CDNs define, or associated with IP such as DDoS protection or advanced analytics. Their decision to give a name, Network Cloud Network Function or NCNF, to their architecture model came about because they now intend to exploit this new-feature capability through custom development and partnerships.
Some might be surprised by comparisons between NCNF and Network Function Virtualization’s VNF (Virtual Network Function VNF) and CNF (Cloud-Native Network Function), but it’s not only appropriate but important. VNFs were designed to deploy the virtual equivalent of devices (Physical Network Functions or PNFs), and so deployed monoliths that required considerable configuration optimization. CNFs expanded NFV to support containers, which are prepackaged with configuration information and are easier to deploy, but still depended on the management and orchestration tools defined for VNFs. 5G was defined to use VNFs, and as I’ve already noted, adopted the RIC model to handle management and orchestration. This evolution is the result of the early experience with service use of hosted components, and DriveNets based their Network Cloud architecture on the same experience.
Exploring DriveNets Network Cloud Network Function (NCNF)
The NCNF architecture is similar to the O-RAN RIC concept, though it predates O-RAN and it’s more generalized. DNOS and DNOR, and the NCNF microservices that provide switching/routing support, expose a set of APIs that link the components and support message and data flows for service/feature composition. What the NCNF evolution is doing is packaging a subset of those APIs for consumption by higher-layer and third-party services. This will expand the current capability for the Network Cloud to host connected but not tightly coupled third-party containerized microservices, by allowing new service elements to couple directly to the NPU, while still protecting functional integrity and security of the Network Cloud cluster.
5G and Mobile or Multi-Access Edge Computing (MEC) has already been cited by operators and vendors as applications that benefit from or even mandate tight coupling between hosted service elements or applications and the network, and obviously NCNF will support these kinds of applications. But even today’s applications would benefit from NCNF implementation. Content delivery networks support streaming video, the largest and fastest-growing traffic on the Internet, and CDNs couple content caching and network address redirection/virtualization, things that could be accelerated through tight coupling and NCNF.
The benefits of a disaggregated model
If the future of cloud computing is MEC, as many believe it is, then the future of cloud computing is tight coupling with the network. DriveNets’ disaggregated model is truly a “network cloud”, and their understanding of the intricate and complex process of creating unity of function from a distributed implementation is critical. Extending the Network Cloud to support other applications directly, and exposing security/stability-managed APIs to accelerate those applications to the network cloud, brings the model of function hosting evolving in O-RAN and CNF to any network service, and to the broader edge computing market.
There are clear capital and operations benefits to disaggregated routing. What NCNF does is bring feature/function benefits into play. Network operators need to manage costs to sustain acceptable return on infrastructure, but they also need to raise top-line revenues from new services. NCNF is offering a feature/function payoff to what’s already a superior capex/opex control strategy. That’s why watching the concept evolve is so exciting…and important.
White Paper
NCNF: From "Network on a Cloud" to "Network Cloud"