Resources

What is Multiservice Network Architecture?

As service providers (SPs) seek to integrate multiple services onto a single platform, they are driven by factors such as growth in bandwidth demand, cloud computing, 5G network rollout, IoT adoption, and network complexity. This service convergence is essential for preventing service providers’ revenue leaks, as they lose the monetization battle to over-the-top (OTT) companies and hyperscalers, leaving them with infrastructure investment debt. There is still more that can be done to address this service convergence issue and stop SPs’ ongoing revenue leaks.

An overview of multiservice network architecture

The classic chassis, which was, and still is, the basis for most networking functions is built in a manner that drives inherently inefficient resource utilization, and therefore a sub-optimal CapEx and OpEx structure.

Such chassis are based with a fixed set of resources, of different types:

  • Compute resources – x86 CPU executed instructions
  • Storage resources – RAM, storage etc.
  • Bandwidth resources – traffic forwarding in and out of and within the chassis (AKA data plane)
  • TCAM (Ternary Content-addressable memory) resources – include high-speed memory resources, used to store Forwarding Information Bases (FIB), Access Control Lists (ACL), counters etc.
  • Quality of Service (QoS) resources – include buffers, queues, policers etc. used for SLA (Service Level Agreement) mechanisms implementation.

When using the platform in a specific network scenario, the inherent inefficiency of the monolithic architecture makes it under-utilized, for at least one of the resources mentioned above.

As the network becomes larger, it grows in the consumption of these favored resources, and further intensifies the abuse of unused resources. with more addressed networking scenarios, this inefficiency eventually expands to all hardware resource types and accumulates, turning into a significant operator investment that does not yield any benefit. Wasted money, in other words.

While different hardware resources are abstracted and different cloud service instances (SIs from DriveNets or 3rd party) run over it, the DriveNets system represents each network function as a standalone node, keeping the network manageable. This means that a single cluster can accommodate multiple networking functions that are physically collocated, yet logically separated. This is enabled by the microservice-based architecture of the DriveNets Network Operating System (DNOS), serving as a multiservice network architecture.

What is DriveNets multiservice network architecture? 

DriveNets Network Cloud is ahead of the curve, already enabling service providers to construct scalable and cost-effective networks that enhance their ability to launch new services.  DriveNets Network Cloud offers a shared network infrastructure with tools for deploying, operating and managing any network function, including core, peering, aggregation and other functions. However, can a shared network infrastructure truly be called “shared” if only one service can use it? In the case of cloud computing, the shift from on-premises to the cloud was attractive and successful due to the ability to run multiple applications on the same existing hardware. The same applies to DriveNets multiservice. 

What is DriveNets multiservice network architecture used for? 

The DriveNets multiservice platform provides access to and control of existing networking and compute resources to any network function through its DriveNets Network Cloud API. This enables the hosting of multiple network functions, including third-party applications and network functions. 

For instance, a service provider can build a multiservice cluster that hosts a core and peering router, along with a third-party firewall and DDoS protection solution. All of these can operate independently and utilize the same underlying hardware, sharing existing networking and compute resources. 

What are the main capabilities of DriveNets multiservice network architecture? 

To understand better the DriveNets multiservice platform, let’s review the following three key capabilities: 

  1. Any service can be served at any port 
  2. Optimal infrastructure utilization 
  3. Faster innovation of new services

#1 Any network service can be served at any port 

In traditional edge networks of SPs, various services such as mobile, business services (e.g., Layer 2 or Layer 3 VPN), and internet edge are aggregated by single-service peering edge (PE) routers. Each router specializes in performing a specific task and may have different operational environments and teams. At the other end, the local core acts as an intermediary for communication between domains and connecting PEs within the same network. 

Multiservice Network Architecture
Figure 1: Traditional Edge Networks

This setup is inefficient as resources from one PE cannot be shared with others; for example, business service links cannot use resources from the mobile PE or internet PE even if they are available.  

Multiservice architecture solves this issue by completely virtualizing the cluster resources, enabling any port to access any service and utilize any necessary hardware resources. This means flexibility, as any cluster port can be used for any service, and scaling is performed at a cluster level without the need to predict which service or use case will require more resources. Additionally, all intra-cluster connections are done logically on the fabric level, eliminating the need for physical links and their associated costs. 

Multiservice Network Architecture
Figure 2: Multiservice – Any Service Can Use Any Port

 #2 Optimal network infrastructure utilization 

Traditional networks can utilize up to 20 different boxes, such as core, aggregation and peering boxes. Maintaining a network with so many different components can be a significant operational burden. When evaluating these components, we find a balance between different resources. For instance, core services prioritize bandwidth (number of ports used), while they consume minimal routing resources (TCAM) and have lean QoS policies. On the other hand, VPN services require a lot of routing resources but have lower bandwidth requirements. 

DriveNets multiservice architecture offers optimal resource allocation based on real-time needs. Instead of adding more physical routers to the network, additional containerized service instances (SIs) can be installed on the existing network hardware, with the cluster hypervisor allocating the necessary resources for each service. This simplifies scaling, reduces total cost of ownership (TCO), and decreases operational overhead. 

 

Multiservice network architecture
Figure 3: Resource Diagram

#3 Faster innovation of new network services 

Multiservice within DriveNets Network Cloud goes beyond grouping existing network functions under one roof. With decoupled data and control planes, new network functions can be added to existing networks by containerizing them and interfacing with Network Cloud’s open API for optimal performance by utilizing both X86 compute and network-oriented compute (NPU). This allows for easy and fast introduction of new services with a simple click of a button, reducing time to market (TTM) of new revenue-generating services.  

An example of such new services could range from VPNs and IoT control functions to unique services aimed at increasing ARPU and preventing user churn. 

Multiservice network architecture

Addressing network inefficiencies with one shared network architecture

DriveNets Network Cloud’s multiservice platform enables service providers to take advantage of grouping existing and new network functions under one shared network architecture.  

 Addressing the inefficiencies of traditional solutions with separate hardware resources, this solution results in cost savings, optimal hardware utilization, simplified operations, a smaller footprint, reduced power consumption, and minimized physical interfaces. 

Additional Multiservice Network Architecture Resources

Blog

Educational Center