網絡虛擬化基于網絡包處理流水線實現，常見的網絡包處理流水線有三種：定制的流水線、可軟件編程的流水線以及通過FPGA實現的硬件可編程流水線。

1 包處理用于網絡虛擬化

網絡包處理機制可以用來處理各種不同的網絡協議，特別是一些可軟件編程的處理引擎的出現，使得增加新的網絡協議處理更加的靈活簡單。通用的網絡包處理機制，也適用于網絡虛擬化VLAN/VxLAN的處理。

1.1 虛擬網絡，狹義的網絡虛擬化

網絡虛擬化通常指通過VLAN、VxLAN、NVGRE等虛擬網絡相關的協議，在一個大的物理網絡的基礎上，靈活構建不同的虛擬網絡域，也可以通過一定的機制，實現在不同虛擬網絡域間的跨域訪問。虛擬網絡不是在初始構建的那一刻配置完成就結束，而是在網絡運行過程中，每條流、每個包都需要經過虛擬網絡協議的處理。隨著網絡帶寬的持續增加，為了優化虛擬網絡的性能以及CPU資源消耗，勢必需要通過硬件加速的方式來實現更高性能的虛擬網絡處理。

虛擬網絡基于物理網絡實現，如圖1，以VxLAN為例，最核心的處理是通過VNID和內部目標地址作為關鍵字，在查找表中查詢到對應的外部目標地址。而內部目標地址和外部目標地址的映射關系處理則交給軟件去完成，可以實現跟現有的軟件虛擬網絡系統兼容，支持更加動態且靈活的虛擬網絡設計，實現硬件的高效和軟件的靈活兼顧。

圖1 VxLAN Tx項虛擬化映射

1.2 廣義的網絡虛擬化

除了虛擬網絡場景，還有一些網絡場景具有虛擬化的特征：比如負載均衡，通過把數量眾多的后端服務器虛擬成一臺強大的服務器來提供服務；再比如NAT，內網服務器可以通過一個公網IP訪問互聯網，站在內網服務器的角度，可以看作是把一個公網訪問IP虛擬化成多個公網訪問IP。

更廣泛的，網絡是分層的體系，每一層從下一層的接口獲取服務、然后實現本層的功能，再把本層的功能封裝成新的接口，通過接口提供服務給上一層。站在整個網絡系統的角度，網絡的每一層都可以看作是一層虛擬化封裝，為上一層提供新的服務接口。

硬件實現的網絡包處理架構，可以支持很多不同類型的網絡協議。特別是數據面可編程的網絡包處理架構，不需要預先把可能要支持的協議都實現，只需要根據自己的場景需要，編程實現特定的若干個協議就好。數據面可編程的網絡包處理可以非常方便的支持特定場景應用，實現高效的網絡虛擬化硬件加速處理。

2 定制的網絡包處理

傳統的ASIC實現的定制網絡協議處理流水線，在設計的開始，需要確定場景以及支持的協議，理論上可以實現最高的網絡包處理性能。

如圖2，是一個定制的網絡包處理流水線，每個階段都是固定的功能，支持的是特定協議的處理，想更新新的協議需要重新設計新的芯片，因此對新協議的支持非常困難。

圖2 定制協議網絡包處理流水線示例

如圖3，IETF（Internet Engineering Task Force，互聯網工程任務組）的RFC（Request for Comments，請求意見稿，即網絡協議）數量一直在爆炸式的增長，應用于各種新型網絡場景的新協議層出不窮。但是，傳統的網絡處理芯片都是封閉的、特定的設計，用于特定協議處理。想要增加新的協議非常困難，并且對新協議的支持受到不同供應商的約束。定制的網絡處理芯片，對新協議的支持不足以及缺乏有效的靈活性，這使得要想在網絡系統增加新的功能非常困難，限制了客戶的網絡創新能力。

圖3 IETF RFC的數量增長

3 ASIC軟件可編程包處理

本節通過數據面編程的背景知識、RMT模型以及流水線映射三個方面介紹可軟件編程的ASIC包處理流水線。

3.1 數據面編程的網絡包處理流水線

Nick McKeown 在 ONF Connect 2019演講中定義了SDN發展的三個階段：

• 第一階段（2010–2020年）：通過Openflow將控制面和數據面分離，用戶可以通過集中的控制端去控制每個交換機的行為；

• 第二階段（2015–2025年）：通過P4編程語言以及可編程FPGA或ASIC實現數據面可編程，這樣，在包處理流水線加入一個新協議的支持，開發周期從數年降低到數周；

• 第三階段（2020–2030年）：展望未來，網卡、交換機以及協議棧均可編程，整個網絡成為一個可編程平臺。

這預示著，未來不管是交換機側還是網卡側，均需要實現類似CPU于通用程序設計的完全可編程的網絡處理引擎，并且要基于此平臺實現一整套的軟件堆棧。把一個完全可編程的網絡交給用戶，支撐用戶更快速的網絡創新。

圖4中介紹的PISA（Protocol Independent Switch Architecture，協議無關的交換架構），是一種支持P4數據面可編程包處理的流水線引擎架構，通過可編程的解析器、多階段的可編程的匹配動作以及可編程的逆解析器組成的流水線，來實現數據面的編程。這樣可以通過編寫P4程序，下載到處理器流水線，可以非常方便的支持新協議的處理。

圖4 PISA的數據面可編程網絡包處理流水線

3.2 可重配置的匹配表模型

RMT（Re-Configurable Match-Action Tables，可重配置匹配表）模型，是一種基于RISC的用于網絡包處理的流水線架構。RMT允許自定義數量的包頭和包頭序列，通過自定義大小的匹配表對字段進行任意匹配，對數據包包頭字段進行自定義的寫入，以及數據包的狀態更新。RMT允許在不更改硬件的情況下在現場更改網絡數據面, PISA架構從RMT模型中獲得了很多的設計靈感。

如圖5所示，是包處理流水線核心處理“匹配動作”階段的內部架構。每個匹配階段都允許配置匹配表的大小，例如，對于IP轉發，可能需要一個256K 32位前綴的匹配表；輸入選擇器選擇要匹配的字段；數據包修改使用VLIW（Very Long Instruction Word，超長指令字，一種比較特殊的CPU架構實現）架構的ALU動作單元，該指令字可以同時對包頭向量中的所有字段進行操作。

圖5 匹配動作的架構

如圖6，RMT定義了一個可編程的解析器。解析器輸入的是數據包數據，輸出4K位的數據包頭向量。輸入的包頭數據和解析狀態信息不斷的送到TCAM去查詢，TCAM查詢會觸發動作，這個動作會更新狀態機，并把結果送到字段提取處理，提取出的字段組成數據包字段向量輸出。

圖6 可編程的解析器模型

3.3 映射處理程序到包處理流水線

當實現了完全可編程的流水線之后，在P4工具鏈的支持下，就可以通過P4編程的方式來實現自定義的流水線，來達到對自定義協議的支持。

如圖7所示，P4定義的Parser程序會被映射到可編程的解析器，數據、包頭定義、表以及控制流會被映射到多個匹配動作階段。圖7中把L2處理、IPv4處理、IPv6處理以及訪問控制處理分別映射到不同的匹配動作處理單元進行串行或并行的處理，來實現完整的支持各種協議的網絡包處理。

圖7 基于PISA流水線的數據包處理示例

4 FPGA硬件可編程包處理

Xilinx在2014年推出SDNet（Software Defined Specification Environment for Networking，軟件定義網絡規范環境）解決方案，將可編程能力和智能化功能從控制面擴展至數據面。SDNet支持可編程數據層功能設計，其功能規范可自動編譯到賽靈思的FPGA和SoC中。

如圖8， Xilinx的SDNet可以通過編程實現數據面代碼的自動生成，可以支持從簡單的數據包分類到復雜的數據包編輯的各種數據包處理功能。SDNet支持P4編程，可以通過編寫標準的P4程序來實現SDNet的包處理。

圖8 Xilinx SDNet解決方案及開發環境

SDNet是充分利用FPGA器件的硬件可編程性來實現包處理的靈活性的，通過P4實現功能靈活且特定的包處理規則，通過SDNet的編譯器，把P4程序生成特定的RTL代碼，再經過自動化的FPGA流程處理，把生成的鏡像更新到FPGA中。而從設計架構的角度，SDNet的實現機制仍屬于定制的網絡包處理流水線，其解析器、編輯器以及查找動作等處理都是針對特定的包的處理，支持的是特定的（標準的或用戶自定義的）網絡協議。

SDNet基于模塊化設計，包括各種不同類型引擎以及引擎之間的連接接口。這些引擎通過與數據包和元組通信，以實現更大的系統行為。執行模型是被動的，基于同步數據流模型，當所有輸入到達時觸發引擎工作。輸入可以是數據包以及相應的作為元組通信的元數據。

SDNet數據流模型的端口有：

• 數據包。數據包端口是SDNet主要的接口，負責在引擎之間以及外部環境傳遞數據包。

• 元組。元組端口是輔助的SDNet接口，負責引擎之間以及與外部環境傳遞與數據包相關的元數據。

• 訪問。SDNet中的訪問端口由編譯器在后臺連接，并在在數據流模型中進行了說明。SDNet規范并未明確實例化或連接這些端口，它們由編譯器自動連接。

• 自定義格式。SDNet中的自定義格式端口用于，上述三種類型無法涵蓋的，與用戶引擎之間的通信接口。

SDNet通過分層的系統構建，包含各種不同類型引擎：

• 解析引擎。用于讀取和解碼數據包頭，并提取所需的信息用于分類或之后的數據包修改。解析引擎只能讀取數據包，而不能修改它們?？梢詫臄祿崛〉臄祿绦杏嬎?，并將數據作為輸出元組傳輸。

• 編輯引擎。用于處理數據包。編輯引擎無法直接從總線讀取數據包，但可以寫入數據包路徑，用于插入、替換或移除數據包。以從分組中插入，替換或刪除數據。

• 元組引擎。主要用于處理元組并基于元組數據計算新的元組信息，這些元組數據可能由外部或其他引擎輸出的數據包或數據確定。

• 查找引擎。實現對各種不同類型表的搜索。SDNet包含一個具有不同查找引擎類型的小型庫，包含四種類型：EM（Exact Match，完全匹配）、LPM（Longest Prefix Match最長前綴匹配）、TCAM（Ternary Content Addressable Memory，三態按內容尋址內存）或直接地址查找（RAM）。

• 用戶引擎。允許用戶將自定義IP內核導入SDNet規范，以利用SDNet框架進行數據平面構建和系統仿真。在SDNet中，用戶引擎只定義引擎的接口，但不定義引擎的行為。用戶引擎必須符合SDNet數據流模型的同步數據流行為。

• 系統。在SDNet模型中，系統被視為一種引擎。根據引擎的匹配端口類型，系統將引擎連接在一起。系統只能包含一個數據包輸入端口和一個數據包輸出端口。系統只允許元組輸出，不允許元組輸入。系統還可以具有用于連接子系統或用戶引擎的自定義端口。子系統是在父SDNet系統中例化的另一個SDNet系統。

5 案例：Mellanox FlexFlow

高性能的以太網交換機是現代數據中心的網絡核心，不斷變化的虛擬化和能自我修復的網絡架構，都要求交換機具有動態的編程功能。Mellanox FlexFlow使得交換機支持用戶自定義功能，FlexFlow具有非常好的可編程能力以及靈活性，支持大規模并行數據包處理以及完全共享的有狀態的轉發數據庫。

如圖9，Mellanox FlexFlow的包處理流水線跟傳統交換機的包處理流水線相比：

• 傳統的包處理流水線具有嚴格的流水線功能約束；而FlexFlow具有可編程的解析器、編輯器以及可編程的流水線。

• 傳統包處理流水線所有的流量是串行的處理；而FlexFlow支持大量的并行以確保最大吞吐。

• 因為串行，傳統的包處理流水線具有很高的延遲；而FlexFlow針對每個流進行優化，確保更低的延遲。

• 傳統的包處理流水線采用分散的查找表資源，更低的擴展性但更高的功耗；而FlexFlow共享查找表資源，因此具有更高的擴展性以及更低的功耗。

(a) 傳統交換機流水線

(b) Mellanox FlexFlow流水線

圖9 傳統的交換機流水線和FlexFlow比較

FlexFlow具有如下典型特征：

• 深度的包解析。解析器是數據包處理流水線的第一個階段。該階段負責將輸入的數據翻譯成有意義的數據包頭字段，這些字段會被用于轉發、策略實施和QoS。FlexFlow支持可編程的數據包處理，可以解析多達512B的數據包。更大的解析深度和自定義支持的數據包格式，數據包處理流水線可以支持更豐富的隧道傳輸、更先進的遙測，同時還可以支持新的網絡協議。

• 靈活的特定于流的查找表。FlexFlow可編程流水線可以定義查找表數量，可以以流為單位配置查找關鍵字。查找動作包括標準的轉發、策略行為以及指向下一個查找表的指針?？梢栽诿恳粭l流的粒度，定制表的數量、查找的序列、匹配關鍵字和動作?；诹髁６鹊牟檎倚蛄?，數據包處理可以多次訪問同一張表?；诹髁６鹊牟檎倚蛄?，FlexFlow可以在固定的物理網絡拓撲中實現靈活多變的網絡抽象。

• 功能強大的隧道。靈活的數據包編輯引擎通過編程添加、修改和刪除多層數據包頭。FlexFlow支持可編程的封裝和解封裝、IPv4選項、IPv6擴展以及多種Overlay協議。FlexFlow為未來的隧道和Overlay技術提供了很好的支持，這些技術是未來幾年網絡虛擬化的根本。

• 完全共享的查找表。傳統的交換機使用碎片化的轉發表，這些轉發表硬連線到特定的流水線階段。用于流水線階段的表的資源和查找表大小都是預先定義好的。在某個特定的流水線階段中的表資源可能存在浪費。FlexFlow可以實現高效的表共享，可以提供幾乎無限的查找表大小的設定，這使得基于FlexFlow的交換機可以支持當前的以及未來的網絡協議所需的所有數據包轉換。

• 綜合遙測。FlexFlow流水線使用靈活的有狀態的流水線階段，以編程的方式提取元數據并提供實時遙測。隨著數據中心網絡復雜性日益提升，FlexFlow提供了完全集成的遙測功能，減少了故障時間，增加正常運行時間，更好的優化了網絡架構的利用率。

6 網絡包處理總結

網絡包處理是一個特定的領域，具有非常明顯的特征，通過ASIC實現效率最高。有利必有弊，ASIC實現極大的約束了網絡的靈活性。上層的網絡用戶只是一個使用者，只能使用ASIC提供的功能；而不是作為一個開發者，開發創新自己想要的功能。隨著這些年來互聯網的迅猛發展，新協議層出不窮，甚至有些網絡服務商會采用一些私有協議。用戶需要極大的網絡創新來支撐自己的業務發展，對網絡的可管理性、可編程性要求變得越來越高。硬件實現的網絡處理加速，勢必需要從專用向通用方向適當的回調。

跟通常的硬件加速從通用到專用的趨勢不同，網絡包處理流水線的實現是反其道而行，走的是從定制到部分可編程的道路。PISA等具有數據面可編程能力的網絡包處理流水線很好的實現了通用和專用之間的平衡：

• 部分可編程性（而不是完全可編程），可以保證單個包處理引擎的性能和效率（跟完全定制的ASIC比較）不受太多影響。

• 通用的處理引擎降低了硬件的耦合性和復雜度，可以實現更大規模的并行度，反而可以更好的提升性能。

• ASIC因為設計門檻的原因，希望盡可能覆蓋較多的應用場景，在具體的某個場景中，必然存在無關協議所占用硬件資源所導致的資源浪費的情況；而數據面可編程的設計具有的靈活性，可以更大限度的保證物盡其用，把所有硬件資源都用于場景相關的協議處理，在硬件資源利用率方面，反而高于ASIC。打個比方，某ASIC網絡芯片支持100種不同的網絡協議處理，但實際應用場景只需要其中的10種協議；在同等晶體管資源占用下，假設數據面可編程的架構只能支持50種網絡協議的處理，這樣當我們處理10種協議的時候，可以編程實現并行的5路處理，性能反而高于純ASIC定制的流水線。

• 提供的軟件可編程性，用戶可以靈活快速的實現特定場景協議，而不需要關心場景無關的協議，反而降低了軟件編程的復雜度。

從整個流水線實現架構來看，基于部分可編程能力的PISA等架構實現的網絡包處理芯片是一種DSA架構處理器。