請問高端網(wǎng)絡(luò)芯片如何處理數(shù)據(jù)包呢？

*本文系SDNLAB編譯自瞻博網(wǎng)絡(luò)技術(shù)專家兼高級工程總監(jiān)Sharada Yeluri的博客

隨著網(wǎng)絡(luò)芯片帶寬的持續(xù)提升，其內(nèi)部數(shù)據(jù)包處理單元的工作負載也隨之增加。然而，如果處理單元無法與網(wǎng)絡(luò)接口的傳入速率相匹配，將無法及時處理數(shù)據(jù)包，這不僅會導(dǎo)致數(shù)據(jù)包隨機丟失，更會降低網(wǎng)絡(luò)的吞吐量。

本文將深入探討與數(shù)據(jù)包處理相關(guān)的各項工作和挑戰(zhàn)，分析處理單元吞吐量的需求演變，以及在網(wǎng)絡(luò)芯片中執(zhí)行這些功能的多種方法和技術(shù)。

數(shù)據(jù)包處理

網(wǎng)絡(luò)芯片中的數(shù)據(jù)包處理是指，當(dāng)網(wǎng)絡(luò)數(shù)據(jù)包通過路由器、交換機或防火墻中的芯片時，芯片對網(wǎng)絡(luò)數(shù)據(jù)包執(zhí)行的一系列操作。網(wǎng)絡(luò)芯片主要檢查數(shù)據(jù)包的L2/L3報頭信息。從宏觀層面來看，數(shù)據(jù)包處理的主要功能可以概述如下：

解析

第一步是對數(shù)據(jù)包報頭進行分析，以了解其結(jié)構(gòu)和所采用的協(xié)議（如以太網(wǎng)、VLAN、IP、TCP/UDP 以及現(xiàn)有的封裝）。解析過程中會識別出后續(xù)處理步驟中需要使用的關(guān)鍵字段，例如源地址和目標(biāo)地址、端口號和協(xié)議類型。

封裝是網(wǎng)絡(luò)通信中的一種常見做法，即在數(shù)據(jù)包外部添加額外的一層報頭信息，通常是為了提供額外的功能，例如安全性（在 VPN 的情況下）和隧道（如 GRE 或 VXLAN）。這樣就形成了具有外部報頭和一個/多個內(nèi)部報頭的數(shù)據(jù)包。在這種情況下，解析邏輯需要同時檢查外部報頭和內(nèi)部報頭。此功能對于嚴重依賴封裝技術(shù)對網(wǎng)絡(luò)流量進行分段、保護和管理的現(xiàn)代網(wǎng)絡(luò)基礎(chǔ)設(shè)施至關(guān)重要。

分類

首先要確定數(shù)據(jù)包的來源。

數(shù)據(jù)包的來源包括其主機身份、接收接口（邏輯和物理）及其轉(zhuǎn)發(fā)域。通常，會執(zhí)行第 2 層地址和數(shù)據(jù)包進入的物理接口之間的綁定檢查。然后根據(jù)數(shù)據(jù)包的報頭字段（例如源/目標(biāo) IP 地址、端口號和協(xié)議類型）對數(shù)據(jù)包進行分類。分類決定了如何處理數(shù)據(jù)包，例如應(yīng)用哪些服務(wù)質(zhì)量 (QoS) 策略。

隧道終止

通過比較隧道報頭字段與隧道端點信息，邏輯確定是否需要終止隧道。

對于需要終止的隧道，其封裝的數(shù)據(jù)包將被解封裝，恢復(fù)到原始格式后再被發(fā)送至最終目的地。外部/內(nèi)部報頭有許多變體，網(wǎng)絡(luò)芯片可以根據(jù)其部署用例支持不同的隧道終止子集。一些常見的受支持的隧道技術(shù)包括 MPLS、VXLAN、GRE、MPLSoverUDP、IPinIP 等。

過濾

許多設(shè)備通過訪問控制列表 (ACL) 實現(xiàn)數(shù)據(jù)包過濾。ACL通常由一組規(guī)則（即ACL條目）組成，每個ACL條目定義了一種訪問控制策略，包括允許或拒絕特定類型的流量或訪問請求。ACL通?；谠吹刂?、目標(biāo)地址、協(xié)議類型、端口號、時間等條件來控制網(wǎng)絡(luò)訪問。

路由查找

根據(jù)數(shù)據(jù)包的目標(biāo)地址和路由表，處理器決定數(shù)據(jù)包的下一跳，并據(jù)此進行轉(zhuǎn)發(fā)。這一過程涉及對 IPv4/IPv6 數(shù)據(jù)包執(zhí)行最長前綴匹配查找，以及在轉(zhuǎn)發(fā) MPLS 數(shù)據(jù)包時執(zhí)行索引查找，或者在基于目標(biāo) MAC 地址進行 L2 轉(zhuǎn)發(fā)時進行精確匹配。查找結(jié)果可以直接指示數(shù)據(jù)包應(yīng)離開的發(fā)送接口，或者指向一系列下一跳指令，這些指令被執(zhí)行后將找到正確的發(fā)送接口。

下一跳處理

下一跳處理（執(zhí)行存儲在大內(nèi)存中的一系列下一跳指令）決定了如何將數(shù)據(jù)包轉(zhuǎn)發(fā)到其目的地。該處理過程會得出數(shù)據(jù)包必須離開的目標(biāo)端口、實現(xiàn)ECMP 或 LAG 的負載平衡，以及確定推送或交換的 MPLS 標(biāo)簽等。此外，數(shù)據(jù)包可選擇性地執(zhí)行策略控制和計數(shù)。

重寫

最后一步，數(shù)據(jù)包報頭將被修改以剝離封裝報頭（在隧道終止的情況下）、更新TTL 遞減、V4 校驗和更新、時間戳更新等。

入站數(shù)據(jù)包處理

在入站數(shù)據(jù)包處理完成后，如果目標(biāo)隊列擁塞，或者該數(shù)據(jù)包被選擇為 WRED 丟棄對象，則數(shù)據(jù)包可能會被丟棄。當(dāng)數(shù)據(jù)包被允許轉(zhuǎn)發(fā)時，它會在片上緩沖區(qū)或外部內(nèi)存緩沖區(qū)內(nèi)排隊等待。無論是入站處的數(shù)據(jù)包排隊/出站的可選排隊，還是出站調(diào)度，這些過程都極大地依賴于網(wǎng)絡(luò)芯片的架構(gòu)特性。

出站數(shù)據(jù)包處理

當(dāng)數(shù)據(jù)包從緩沖區(qū)中讀出，并準(zhǔn)備離開出站接口時，它會在出站階段進行進一步的處理，以便在傳輸前對數(shù)據(jù)包進行必要的修改。這些修改包括添加新的 L2 報頭和/或 VLAN 標(biāo)簽、封裝（當(dāng)網(wǎng)絡(luò)設(shè)備位于隧道入口點時）、添加 MPLS 標(biāo)簽等。此外，數(shù)據(jù)包還可以選擇性地通過出站過濾/策略執(zhí)行。這些實現(xiàn)方式因設(shè)備而異。

具有入站/出站數(shù)據(jù)路徑和數(shù)據(jù)包處理子系統(tǒng)的獨立網(wǎng)絡(luò)交換機

大型路由器可以使用多個模塊化路由芯片通過switch fabric相互連接，這些模塊化路由芯片可使用術(shù)語“數(shù)據(jù)包轉(zhuǎn)發(fā)實體（PFE）”來指代。在這些系統(tǒng)中，入站數(shù)據(jù)包處理發(fā)生在網(wǎng)絡(luò)流量進入的 PFE 中，出站數(shù)據(jù)包處理發(fā)生在流量離開的 PFE 中。

數(shù)據(jù)包處理實現(xiàn)

數(shù)據(jù)包處理的實現(xiàn)方式取決于所需的靈活性、設(shè)備的總吞吐量、以及該功能的功耗/性能/面積預(yù)算。

專用處理引擎

大約二十年前，隨著網(wǎng)絡(luò)協(xié)議快速演化，新的可選/擴展報頭和隧道標(biāo)準(zhǔn)也隨之涌現(xiàn)。數(shù)據(jù)包的處理是通過大量高度靈活且可編程的專用處理引擎實現(xiàn)的。這些專用處理引擎通常包含存儲在片上和/或片外指令存儲器中的微碼指令。與 RISC 和 X86 指令集不同，微碼是一種低級指令集，通常以非常長的指令字 (VLIW)的形式打包。處理引擎通過這些微碼指令序列解析存儲在本地存儲器中的數(shù)據(jù)包頭的不同字段，以確定數(shù)據(jù)包的結(jié)構(gòu)，并執(zhí)行上述所有入站和出站處理功能。處理引擎的硬件并不了解任何網(wǎng)絡(luò)協(xié)議，它只是盲目地執(zhí)行指令以形成新的數(shù)據(jù)包頭并計算輸出接口。



用于數(shù)據(jù)包處理的PPE

雖然基于微碼的處理提供了無限的靈活性，但在芯片面積或每 Gbps 功耗方面效率較低。在混合方法中，一些功能（如過濾/最長前綴匹配查找、策略執(zhí)行等）可以在硬件本地（硬件加速器）中實現(xiàn)，同時使用微代碼指令進行數(shù)據(jù)包解析和其余的數(shù)據(jù)包轉(zhuǎn)發(fā)功能。

數(shù)據(jù)包處理Pipeline

隨著高端芯片開始封裝更多的 WAN 帶寬，混合方法無法滿足每 Gbps 的功率/面積目標(biāo)。十多年前，一些網(wǎng)絡(luò)供應(yīng)商開始使用硬件pipeline（同時以本地/功能特定的指令/排序操作的形式提供有限的靈活性）本地實現(xiàn)所有數(shù)據(jù)包處理功能。

下圖是基于Juniper的Express Architecture pipeline實現(xiàn)的入站數(shù)據(jù)包處理pipeline的概念圖。



入站和出站數(shù)據(jù)包處理pipeline及其數(shù)據(jù)結(jié)構(gòu)

該pipeline包含一系列后續(xù)塊或模塊，其中每個模塊負責(zé)上文描述的特定功能。通常，整個數(shù)據(jù)包存儲在數(shù)據(jù)路徑存儲器中，而報頭（通常是數(shù)據(jù)包的前128字節(jié)）則通過數(shù)據(jù)包處理pipeline。由于數(shù)據(jù)包處理只關(guān)注 L4 的報頭信息，因此不需要通過pipeline發(fā)送整個數(shù)據(jù)包。

根據(jù)吞吐量需求的不同，數(shù)據(jù)包報頭以每周期一個數(shù)據(jù)包的速率或更低的速率通過pipeline發(fā)送。每個模塊都有許多存儲在 SRAM 中的本地數(shù)據(jù)結(jié)構(gòu)/配置。

Pipeline的靈活性

網(wǎng)絡(luò)是一個不斷發(fā)展的領(lǐng)域，為了適應(yīng)新技術(shù)和新需求，經(jīng)常會開發(fā)/標(biāo)準(zhǔn)化新協(xié)議和現(xiàn)有協(xié)議的擴展。從新的 RFC 標(biāo)準(zhǔn)發(fā)布到其實際在網(wǎng)絡(luò)芯片中得到應(yīng)用，通常會有3-4 年的延遲時間。這就是為什么在這些pipeline中具有一定的靈活性非常重要。

例如，除了對已知的L2-L4報頭的標(biāo)準(zhǔn)解析之外，硬件還可以支持靈活的解析功能，以解析未來的協(xié)議報頭或現(xiàn)有協(xié)議的擴展。這可以通過一系列CAM（內(nèi)容可尋址存儲器）和規(guī)則集來實現(xiàn)，它們指定了要查找新協(xié)議的Type/Length/Value字段的字節(jié)偏移量。

并非所有的網(wǎng)絡(luò)應(yīng)用程序都經(jīng)過相同的數(shù)據(jù)包處理。例如，某些數(shù)據(jù)包可能需要多次查找。第一次查找可能是 LPM（最長前綴匹配）查找，以確定數(shù)據(jù)包的下一個目的地。第二次查找可能涉及更具體的路由策略，比如基于策略的路由，其中決策基于數(shù)據(jù)包中的其他字段或應(yīng)用類型。

類似地，在 MPLS 網(wǎng)絡(luò)中，第一次查找可能涉及讀取 MPLS 標(biāo)簽以在 MPLS 網(wǎng)絡(luò)內(nèi)做出轉(zhuǎn)發(fā)決策。當(dāng)數(shù)據(jù)包到達 MPLS 網(wǎng)絡(luò)的邊緣，并且標(biāo)簽被彈出時，需要進行第二次查找，以便根據(jù)數(shù)據(jù)包的原始 IP 報頭確定數(shù)據(jù)包的下一跳。

Express 數(shù)據(jù)包處理pipeline中的查找功能提供了這樣的選項，其中第一次查找的操作可以指示后續(xù)的查找，并且報頭循環(huán)回查找函數(shù)的開頭以進行下一次查找。



數(shù)據(jù)包如何在每個查找模塊內(nèi)循環(huán)

需要注意的是，在數(shù)據(jù)包處理pipeline中，因為每個數(shù)據(jù)包都經(jīng)過不同的pipeline并具有不同數(shù)量的查找、過濾器和下一跳操作，因此無法不會保持數(shù)據(jù)包的原有順序。網(wǎng)絡(luò)設(shè)備必須確保同一數(shù)據(jù)流中的數(shù)據(jù)包不會被打亂順序。粗略地判斷數(shù)據(jù)流的方式是以數(shù)據(jù)包進入的輸入端口/接口為準(zhǔn)。而更為精細的判斷方法則是查看數(shù)據(jù)包的五元組，并通過計算哈希函數(shù)來確定數(shù)據(jù)流。pipeline末端的重排序引擎可以將數(shù)據(jù)包重新按照每個端口或每個數(shù)據(jù)流的順序排列好。



帶有重排序引擎的數(shù)據(jù)包處理pipeline

再循環(huán)

在某些封裝中，報頭字節(jié)可能會超過 128B。對于那些在初次傳遞中無法檢測到內(nèi)部報頭的情況，數(shù)據(jù)包需經(jīng)歷如下步驟：首先在剝離已解析的報頭字節(jié)，接著從入口內(nèi)存中讀取額外的報頭字節(jié)，并將新報頭再次發(fā)回處理pipeline進行處理。在接下來的循環(huán)中，將重復(fù)處理步驟以處理內(nèi)部報頭。

再循環(huán)應(yīng)用的示例包括MPLS over UDP，其中需要處理兩個以上的堆棧，以及基于防火墻的隧道解封裝。



再循環(huán)的概念圖

吞吐量

網(wǎng)絡(luò)芯片所需的每秒數(shù)據(jù)包處理速率與能夠進入設(shè)備的最小數(shù)據(jù)包大?。ㄍǔＪ?64B 以太網(wǎng)幀）、數(shù)據(jù)包間隙 (IPG) 以及設(shè)備的總 WAN 吞吐量成正比。

Packets per second = (bits/second) / (bits /packet + IPG/packet)

假設(shè)一個3.2Tbps 的設(shè)備需要處理連續(xù)到來的 64B 數(shù)據(jù)包，若要跟上這種處理節(jié)奏，在1GHz的時鐘頻率下，每周期幾乎需要處理近5個數(shù)據(jù)包。由于每個pipeline最多只能每周期處理一個數(shù)據(jù)包，這意味著在這種情況下需要約5個數(shù)據(jù)包處理pipeline。就面積和功率而言，是相當(dāng)昂貴的。



3.2Tbps 設(shè)備要滿足 64B 數(shù)據(jù)包的線路速率需要 5 個pipeline

在實際網(wǎng)絡(luò)流量中，平均數(shù)據(jù)包大小通常大于 64B。大多數(shù)流量通常使用最大傳輸單元 (MTU) 大小的數(shù)據(jù)包來最大化吞吐量。設(shè)計針對平均常用數(shù)據(jù)包大小優(yōu)化的數(shù)據(jù)包處理引擎有助于實現(xiàn)更優(yōu)的設(shè)計，有效利用芯片面積。那么，我們?nèi)绾未_定平均數(shù)據(jù)包大小呢？

一種方法是檢查網(wǎng)絡(luò)性能測試中使用的各種 IMIX 模式。

IMIX（ Internet MIX）是網(wǎng)絡(luò)性能測試中使用的概念，用于更準(zhǔn)確地模擬現(xiàn)實世界中的互聯(lián)網(wǎng)流量模式。IMIX不使用統(tǒng)一的數(shù)據(jù)包大小，而是采用多種數(shù)據(jù)包大小的組合來代表互聯(lián)網(wǎng)流量的多樣性。例如，IMIX 可能包含小型數(shù)據(jù)包（64 字節(jié)，常見于 ACK 或控制消息）、中型數(shù)據(jù)包（大約 576 字節(jié)，通常用于特定應(yīng)用數(shù)據(jù)）和大型數(shù)據(jù)包（大約 1500 字節(jié)，），并且它們之間有一定的分布比例。

對于 IMIX 數(shù)據(jù)包大小分布并沒有一個普遍接受的標(biāo)準(zhǔn)。不同的組織可能會根據(jù)其特定需求和對網(wǎng)絡(luò)流量的觀察，定義自己的 IMIX 配置文件。谷歌和 Meta 在評估網(wǎng)絡(luò)設(shè)備時都有自己的 IMIX 模式。

假設(shè)數(shù)據(jù)包處理需要以線速處理平均約 345 B大小的數(shù)據(jù)包，并在1.1GHz的時鐘頻率下運行，那么只需一條pipeline即可滿足需求！



該表顯示了增加平均數(shù)據(jù)包大小以滿足線路速率時，如何減少pipeline數(shù)量

為了應(yīng)對互聯(lián)網(wǎng)流量可能存在突發(fā)性的特點，以及可能出現(xiàn)瞬態(tài)場景，即平均數(shù)據(jù)包大小小于350B，且有許多連續(xù)的小數(shù)據(jù)包涌入，這就需要在數(shù)據(jù)包處理輸入端增設(shè)一個突發(fā)吸收緩沖區(qū)（即圖中所示的入口緩沖區(qū)）。一旦這個緩沖區(qū)開始填滿，硬件就可以執(zhí)行優(yōu)先級感知丟棄策略，即給予控制/?；顢?shù)據(jù)包更高的優(yōu)先級。丟棄策略的具體規(guī)定因供應(yīng)商而異。

在上一代 Express Silicon (Express4) 中，為了實現(xiàn)3.2Tbps處理能力，并使得平均數(shù)據(jù)包大小達到約180B，決定增加兩條pipeline。如下圖所示，在實現(xiàn)這兩條pipeline時，它們可以共享本地數(shù)據(jù)結(jié)構(gòu)、路由表和下一跳內(nèi)存資源。

? ?

總結(jié)

本文闡述了高端路由器中數(shù)據(jù)包處理引擎所使用的技術(shù)，以實現(xiàn)每秒數(shù)十億數(shù)據(jù)包的高性能處理，同時提供足夠的處理靈活性。從宏觀層面概述了數(shù)據(jù)包處理的基本原理，討論了其如何隨著時間演變，以及網(wǎng)絡(luò)芯片供應(yīng)商在不斷增加廣域網(wǎng)帶寬時面臨的吞吐量擴展挑戰(zhàn)。

審核編輯：劉清