與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未必是好的應用場景，但這個還要實踐后，再給出文章分析，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/188744.html
標籤：python