與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未必是好的應用場景。但這個還要實踐後，再給出文章分析。