与4G核心网相比，5G核心网有下面几个特性：服务化，C/U分离（控制面与用户面解耦），NFV，切片等。本篇在NFV和C/U分离的背景下，先描述了UPF网元选用P4作为技术方案的优缺点和参考实现方案，最后结合相关开源代码给出一个基于P4的UPF概念演示demo。
背景
以个人观点看，NFV和C/U分离都是软件定义一切的思想向CT领域渗透的结果。NFV(Network Functions Virtualization,网络功能虚拟化)，将以前在专用硬件才有的网络功能，以软件的形式提供，并可部署在通用服务器下的虚拟化平台中。用软件实现网络功能，可加快新功能和新业务的上线。虚拟化，又可节约硬件投入成本和加大硬件利用效率。再看C/U分离，C/U分离差不多是另一种语境下，或可称之为移动通信领域下SDN。C/U分离，将核心网分为控制面和用户面两部分。将移动性管理、会话管理、用户数据等信令控制功能且包含一定用户身份敏感信息的部分放在控制面，其通常部署在管理完善的中心DC。同时，为满足低时延和高带宽的需求，用户面可灵活部署在靠近用户侧的边缘DC。用户面通过控制面下发的转发策略进行用户数据的转发，5G用户面网元UPF相较于4G网关SGW/PGW的功能，其功能相对简化、单一。另外，再结合C/U接口协议（PFCP）定义的标准化过程，使得5G UPF有可能作为一种白盒网络交换设备产品出现。
简单的讲，UPF（User Plane Function，用户面功能）为移动基础设施（Mobile Infrastructure，例如：RAN）和 DN（Data Network）之间的网关设备，完成 终端用户数据业务的 GTP-U隧道转发功能。借用下面这张图可以看出UPF在移动通信网络中的逻辑关系。UPF受控制面网元SMF控制，SMF通过参考点N4接口向UPF按照PFCP（Packet Forwarding Control Protocol）定义的交互消息向UPF下发转发规则。UPF从基站侧N3口接收UE终端用户上行访问DN的数据业务，完成GTPU隧道的解封装和路由工作。UPF从DN（数据网络）侧接收下行数据，进行目的UE的GTPU隧道封装工作，交由基站，最终由基站通过无线信道将数据转发给UE。
从下图协议栈的角度看，可能也很容易看出UPF数据面所做的GTPU隧道转发处理的工作。当然上述描述的只是UPF最基础的功能，UPF还需要有计费、策略、Qos和DPI等功能。
与其他NFV中以数据转发为主要功能的产品技术实现方案一样。NFV下的UPF也多采用DPDK+SR-IOV/passthrough方案。此方案SR-IOV/passthrough直接越过虚拟化层，将网卡资源直接供guest OS使用，避免了虚拟化网络对性能的影响。Guest OS中，UPF使用DPDK越过了OS的网络协议栈，在用户态下实现网络报文快速转发处理。当前大多数NFV环境下的网卡和CPU架构都可满足DPDK+SR-IOV/passthrough运行条件，故此方案的适配性已不是最大问题。转而面临的最大挑战在于，这种基于通用CPU的数据面处理方案，在受多线程同步、cache miss等影响下，时延抖动和最大速率很难得到保证。换一个方式说，就是当前DPDK+SR-IOV/passthrough已经到了性能的瓶颈期，如果需要可保证的时延和带宽的需求，需要考虑新的技术实现方案。
从性能角度看，硬件实现方案应该是最优的。数据面硬件方案有FPGA、专用ASIC和NP（网络处理器）。而P4作为一种可编程数据面语言，对于熟悉Linux 网络开发人员来说，学习门槛更低，结合例如Barefoot Tofino的P4芯片，可以快速开发创新多样的数据面应用。下一节将给出P4下UPF的几种方案考虑。
UPF的P4方案
1、upf as sdn app
UPF作为在SDN OS之上的APP，UPF APP完成控制相关的功能，例如PFCP会话的建立，PFCP消息的编解码，并通过SDN OS接口完成转发规则的下发。此方案也称为vnf offload方案，即vnf UPF功能用sdn实现。此时UPF业务作为整体SDN网络功能的一部分，路由功能可有SDN OS提供链路拓扑让上层APP实现。
2、upf +switchOS
Upf-C控制面功能单独作为一个程序，直接用switchOS通信，不需要SDN OS。
| 对比项 | upf as sdn app | upf +switchOS |
|---|---|---|
| 规模 | 多个switchOS，在已有sdn fabric网络中新增UPF功能。 | 单switchOS。新增独立UPF节点。强调轻量级和小型化 |
| 开发难易程度 | 难。需要对SDN OS和switch OS，P4 pipeline都有一定的知识储备。 | 简单。主要具备switchOS北向接口和p4 pipeline知识即可。因为是单节点，路由协议功能可以放在UPF-C静态配置或做简单的动态路由。 |
| 维护 | 难。定位问题，需要从上到下。 | 简单。结构的简单，带来定位问题的简单。 |
在UPF使用P4的起步阶段，个人觉得upf +switchOS更简单也更易推广，在已有白盒P4交互机上进行UPF-C的开发，就可实现边缘UPF功能，转发性能和功耗方面比通用服务器UPF的方案具有竞争优势。在通用服务器使用P4加速网卡的情况下，也可将此方案直接用在VNF中。
由于P4报文处理基本依赖table match—action操作，对于DPI这种深层（七层）协议解析且需要大量正则表达式匹配的处理，存在dataplane无法处理的问题。两种方案中，都可将此类报文送到控制面处理。但笔者更倾向于将类数据面业务转发到另一个“协处理单元”进行处理，这引出了方案3.
3、upf+switchOS+vpp
此方案中switchOS中的dataplane充当整个UPF的fastpath，对于无法识别或处理的报文，转发到VPP所在的网络接口，VPP处理完后，然经由SwitchOS dataplane转发（对外体现网络接口IP的一致性）。VPP实现dpi功能，可借鉴融合vpp ndpi项目。
upf_p4_poc
为对P4在UPF应用，有一个更直观的评价和认知。笔者基于方案2 upf +switchOS思路，制作了一个upf_p4_proc工程，详见upf_p4_poc。整体组件框图如下：
此工程基于stratum+bmv2，实现了简单的pfcp session建立下pdr和far创建，以及对应的上下行gtpu数据在p4 pipeline的处理。对P4和UPF开发感兴趣的可以同学看一下，其中UPF信令面和用户面的基于scapy的python脚本，对UPF开发同学也许有点参考作用。以前做UPF开发的时候，最痛苦的就是UPF不好自测，现在依靠scapy，难度降低不少。
后期，还会考虑一下基于xdp的upf demo。虽然个人认为xdp可能更适合当前已有的使用iptable在内核态实现一些防火墙的功能，UPF未必是好的应用场景。但这个还要实践后，再给出文章分析。