In the first two blogs in this series we discovered what a programmable fabric is and what it looks like. Now we are ready to dive deeper into programmable fabrics and discover network function offload.
Telecom communication service providers need to provision “Network Functions” in their infrastructure in order to run the network. Network functions like a BNG (Broadband Network Gateway) for terminating fixed access subscribers or UPF (User Plane Function) for terminating 5G wireless subscribers. These network functions have been evolving from physical boxes to virtual network functions and the disaggregation of these network functions is key to being able to truly scale and grow the network.
However, the evolution of these network functions to date has been fraught with performance and scaling problems as legacy BNG and UPF vendors looked to quickly virtualise their network functions without taking advantage of newer technologies and architectures. Programmable fabrics is one such technology that could potentially help scale network functions by allowing their user plane portions (the most I/O intensive portion) to be “offloaded” into the network.
Figure 1 – Network Function Offload
CUPS (Control User Plane Separation) is the terminology used to describe the separation of the control plane part of a network function (NF-c) and the user plane portion of the network function (NF-u). This separation of control and user planes allows them to be scaled independently and for the user plane to be pushed down into the programmable forwarding engine of the SmartNIC or Switch (see diagram below). This frees up the server CPU cores from doing mundane packet processing and all the performance and tuning problems that this normally brings in a DPDK environment (i.e. Hugepages, NUMA balancing, CPU pinning, etc).
The NF-c can be implemented in two different ways:
- Stand alone mode:where the NF-c will use the standardised DP interfaces (i.e. P4 Runtime, gNMI and gNOI) to communicate directly to the Data Plane nodes. This is useful in the early stages of a programmable fabric implementation where the coming together of the PFE pipelines into a single data plane node is premature and not practical (i.e. the early implementations are more likely to implement separate BNG, UPF and Fabric Management pipelines on separate SmartNICs and switches).
Figure 2- NF-c in Stand Alone mode
- Fabric Controller mode:where the NF-c will use the standardised Fabric Controller interfaces to configure and manage the NF user plane (NF-u) function in the PFE pipeline in the data plane node. While this is probably the optimal future state it will take clearly defined Fabric Controller interfaces and appropriate policy and collaboration from all network function applications.
Figure 3 – NF-c in Fabric Controller mode
NF-u Pipeline
The user plane portion of the network function (i.e. NF-u) is pushed down into the programmable forwarding engine (i.e. SmartNIC or Switch) into what we call the “pipeline”. The pipeline is basically the set of functions that get applied to each and every packet as it comes into the SmartNIC or Switch. We use a network domain specific programming language called P4 to describe this pipeline (see https://p4.org for more information).
When network functions need to be added to a single P4 pipeline this can then complicate the pipeline and requires some co-ordination of access to the individual P4 tables within the pipeline as can be seen in the addition of the BNG functional block to the general fabric pipeline depicted below.
Figure 4 – P4 pipeline
In this pipeline the BNG-c network function would have control of all the BNG block P4 tables (i.e. updating the tables to reflect new subscribers as they’re authenticated onto the network), but it may also need to co-ordinate with the other fabric management tables for things like core routing for the BNG subscribers. This could be done by partitioning parts of the tables with things like a VRF id (Virtual Router Function ID) or potentially having the fabric management application expose the routing tables and data models north bound to the BNG-c.
Open Programmable Service Edge
Dell EMC has been working with its partners Intel, Netcope and Benu Networks to prove out an open architecture to allow network functions to offload their user plane components onto P4 programmable SmartNICs so that operators can take advantage of the benefits this technology brings.
The ONF Stratum project is used to provide the Data Plane Agent (DP-Agent) and provides standardised north bound interfaces (P4 Runtime, gNMI & gNOI) for the Network Function control plane (i.e. BNG-c) and integrates south bound to the Intel PAC N3000 FPGA SmartNIC.
ONF’s Stratum is also integrated into other switches, with both programmable and fixed pipelines and more will be integrated over time. This then allows the hardware integration to Stratum to be done once and then leveraged by many different Network Function vendors rather than each vendor needing to do a customer integration to a SmartNIC or Switch. More information on the ONF Stratum project can be found here https://www.opennetworking.org/stratum/ .
Network Function offload is a very interesting use case for Telecommunication providers as it will allow them to truly scale their network functions, while freeing up server CPU cores to do other edge use case processing (i.e. IoT aggregation, Augmented Reality, Content Delivery, etc). Dell Technologies is committed to helping our customers build out the next generation Telco Edge using open standards where possible like our Open Programmable Service Edge architecture.
The post To the edge and beyond: Network function offload appeared first on RCR Wireless News.