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 (NFs) in their infrastructure in order to run the network. NFs like a BNG (Broadband Network Gateway) for terminating fixed access subscribers or UPF (User Plane Function) for terminating 5G wireless subscribers. These NFs have been evolving from physical boxes to virtual network functions and their disaggregation is key to being able to truly scale and grow the network.
However, the evolution of NFs to date has been fraught with performance and scaling problems as legacy BNG and UPF vendors looked to quickly virtualize their NFs without taking advantage of newer technologies and architectures. Programmable fabrics is one such technology that could potentially help scale NFs 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).
Stand alone mode: where the NF-c will use the standardized 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 1 – Network Function Offload
Fabric Controller mode:where the NF-c will use the standardized 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 NF 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.
When NFs need to be added to a single P4 pipeline this can then complicate the pipeline and requires some coordination of access to the individual P4 tables as can be seen in the addition of the BNG functional block to the general fabric pipeline depicted below.
Figure 4 – P4 pipeline
The ONF Stratum project is used to provide the Data Plane Agent (DP-Agent) and provides standardized northbound interfaces (P4 Runtime, gNMI & gNOI) for the NF 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 NF 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.
Network Function offload is a very interesting use case for Telecommunication providers as it will allow them to truly scale their NFs, while freeing up server CPU cores to do other edge use case processing (IoT aggregation, Augmented Reality, Content Delivery, and so forth). 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.
