近日，谷歌正式向 OCP 提交了 Falcon 協議草案。此前在《再談谷歌Falcon以太網硬件傳輸協議》一文中，我們已經對谷歌Falcon協議有了一些認識。 ? Falcon涉及的技術： ?

Carousel：一種流量限制機制（流量整形），允許在各個主機的上下文中調節數據包流的性能和強度。

Snaps：基于微內核的網絡子系統，可以通過模塊進行擴展，通過模塊可以添加高級功能，例如網絡虛擬化、流量限制和消息傳遞功能。

Swift：數據中心級網絡的擁塞控制機制，短 RPC 消息可實現低于 50 微秒的延遲，同時在接近 100% 負載的情況下保持每臺服務器 100 Gbps 的吞吐量。

RACK-TLP：一種確定 TCP 數據包丟失的算法。

PLB：一種使用擁塞信號的負載平衡機制。

CSIG：一種遙測交換協議，用于發送擁塞和流量控制信號。

? 此次谷歌提交的 Falcon 草案包括： ? OCP Specification_ Falcon Transport Protocol_Rev0.9 ? 該規范描述了為 RDMA 操作和 NVMe 命令提供可靠傳輸的 Falcon 協議。Falcon 是一種面向連接的請求響應傳輸協議，可為 RDMA 和 NVMe 等上層協議 (ULP) 提供端到端可靠傳輸和基于連接的安全性。Falcon 連接可以是有序的，也可以是無序的。Falcon 包括一個可編程擁塞控制引擎，可用于實現最先進的擁塞控制算法。Falcon 使用 Paddywhack 安全協議 (PSP) 或 IPSEC ESP 協議對每個連接的所有 ULP 數據進行身份驗證和加密。 ? OCP Specification_ RDMA over Falcon Transport_Rev0.9： ? 該規范描述了 RDMA ULP 到 Falcon 傳輸協議的映射，包括數據包格式、支持的操作和錯誤處理模式。RDMA ULP 由 Infiniband Verbs 規范定義，并且 Falcon 傳輸上的 RDMA 映射支持 Verbs 規范的可靠連接 (RC) 和不可靠數據報文 (UD) 模式。 ?

? 下面小編將帶大家簡單看一下草案的內容，文末提供完整 PDF 下載。 ? ? 協議體系結構

? 上圖是Falcon的協議層。Falcon本身由兩個子層組成：事務層和數據包傳輸層。事務層主要處理ULP事務，并負責資源管理和事務排序。數據包傳輸層主要負責網絡數據包，并負責可靠傳遞和擁塞控制。Falcon不公開自己的硬件/軟件接口。ULP負責實施硬件/軟件接口、操作處理、完工通知和端到端流量控制。 ? ULP操作（Op）可以映射到一個或多個Falcon事務。Falcon事務由請求和響應定義。Falcon通過在網絡上發送和接收一個或多個數據包來可靠地完成事務。在完成事務時，Falcon通過響應或完成來通知ULP。Falcon的push和pull請求提供了基本的primitives，可以將不同的ULP操作靈活地映射到Falcon事務。下圖顯示了ULP操作、Falcon事務和數據包之間的關系。 ?

? 事務子層 ? 事務子層為ULP提供事務接口。Falcon事務由ULP向Falcon發出的請求和Falcon返回ULP的響應組成，表示事務結束。ULP可以生成兩種類型的事務：pull 和 push。所有ULP操作都必須映射到pull 和 push事務。例如，RDMA讀取和原子操作碼映射到pull事務，RDMA發送和寫入操作碼映射為push事務。Falcon的每個事務都有一個請求序列號（RSN），用于跟蹤事務狀態和排序。 ?

?

? 數據包傳輸子層

?

? 數據包傳輸子層的兩個主要功能是可靠的數據包傳輸和從Falcon發送器到Falcon接收器的擁塞控制。數據包傳輸子層使用兩個滑動窗口來分離請求和數據。請求滑動窗口負責pull 請求的可靠傳遞，數據滑動窗口負責pull 和push 數據的可靠傳遞。需要兩個滑動窗口來避免協議死鎖。 ? ? 擁塞控制 ? Falcon使用每連接的擁塞控制。Falcon數據路徑硬件負責測量擁塞信號，并基于每個連接強制執行計算的擁塞窗口和速率。擁塞控制算法本身在與主Falcon數據路徑分離的速率更新引擎（RUE）中實現。 ? Falcon在ACK/NACK接收、數據包重傳等特定事件上觸發RUE操作。RUE響應這些事件計算擁塞控制輸出，并將其返回給Falcon。 ? Swift是一種基于延遲的擁塞控制，適用于數據中心，可在高帶寬下提供低尾部延遲和近乎零丟包： ?

利用每個數據包NIC硬件的時間戳，并有效地將其用于擁塞窗口和速率計算。

快速反應算法處理網絡中的大規模入侵和流量沖突。

通過對fabric和終端主機組件的cwnd（或速率）計算進行解耦，消除歧義，并對fabric和終端主機/NIC擁塞做出適當響應。

負載平衡對于最大限度減少fabric中的擁塞熱點也至關重要。保護性負載平衡是一種利用Swift擁塞信號的有效負載平衡算法。 ? ? 錯誤處理 ? Falcon支持ULP的錯誤處理語義。特別是Falcon支持“接收器未就緒（RNR）”指示的ULP概念。RNR指示允許目標ULP指定必須重試事務的時間。Falcon實現了對ULP透明的RNR重試。從發起端重試push事務。從目標端重試pull事務。 ? 此外，Falcon還支持快速恢復。CIE語義可以更好地處理各種錯誤（例如RDMA ULP中的內存保護錯誤），而不要求在ULP中將此類錯誤視為致命錯誤。目標ULP可以使用CIE指示來回復pull或push事務。對于pull事務，ULP必須返回具有CIE錯誤代碼的零長度拉取響應。對于push事務，ULP必須返回帶錯誤代碼的顯式CIE指示。Falcon 會將帶有 ULP 錯誤代碼的 CIE NACK 數據包從目標發送到發起端。發起端將錯誤地完成交易，并將CIE錯誤代碼返回給發起端ULP。 ? 盡管RNR NACK和CIE NACK是不可靠的數據包，但Falcon具有從丟失的 NACK 中恢復的機制。 ? 在Falcon塊本身中，錯誤處理完全在硬件中實現。錯誤處理的目標是僅將影響范圍限制在發生錯誤的連接上，并且不影響其他連接的性能。使用數據包超時和重傳來處理包丟失等協議錯誤。超過可配置閾值的重復重傳失敗會向軟件發出信號，以便可以采取糾正措施，例如重新建立連接。 ? 分配給 Falcon 內事務的所有資源都可以在可配置的超時后回收。Falcon 中的所有資源都可以被視為“軟狀態”，因為資源清理是在發起方和目標方超時后發生的。 ? ? 數據包格式 ? Falcon數據包

? Falcon數據包的有線格式如上圖所示。Falcon數據包被封裝為加密協議（如PSP或IPSEC ESP）的有效負載，該協議提供Falcon數據包的身份驗證和加密。Falcon報頭位于PSP/ESP報頭之后（由PSP報頭中的Next header值252指示）。Falcon數據包的有效負載包含上層協議（ULP）數據包有效負載，Falcon報頭中的協議類型字段指示ULP協議。緊跟在Falcon報頭之后的是ULP協議特定報頭。在PSP的情況下，PSP加密偏移字段配置為指向Falcon報頭的前4個字節之外（將連接ID字段留空）。 ? Transport Mode（傳輸模式）

? Falcon在傳輸模式下最常見的數據包格式如上圖所示。傳輸模式格式具有單個IP報頭，其中源IP地址和目標IP地址表示網絡中計算機的物理IP地址。傳輸模式格式用于RDMA RC和RD模式的非虛擬化部署。 ? Tunnel Mode（隧道模式）

? Falcon也可以在隧道模式下使用，這在虛擬化環境中很有用。在隧道模式下，PSP/ESP有效負載攜帶內部IPv4/IPv6數據包。 ? Falcon Base Header?

? 除ACK和NACK數據包外，所有Falcon數據包都攜帶Falcon Base報頭。Falcon報頭的格式如上圖所示，下表提供了報頭各個字段的規格。 ?

? Pull請求數據包

? 作為對ULP發起的pull事務的響應，發起者向目標發送pull請求包。在目標端，pull請求包被傳送到目標ULP, ULP必須通過發送pull響應來完成pull事務。Pull請求包的格式如上圖所示，由下表定義。 ?

? Pull數據包

? 作為對目標接收到的pull請求的響應，目標端的ULP向發起者發送pull數據包。Pull數據包的格式如上圖所示，定義如下表所示。 ?

? Push數據包

? 作為對ULP發起的推送事務的響應，一個推送數據包由發起者發送到目標端。推送數據包的格式如上圖所示，定義如下表所示。 ?

? 重新同步數據包

? 重新同步數據包從Falcon發送器發送到Falcon接收器，以同步滑動窗口狀態（即PSN）。重新同步數據包的格式如上圖所示，并由下表定義。 ?

? 確認（ACK）數據包 ? 有兩種類型的ACK數據包：基本ACK（BACK）和擴展ACK（EACK）。 ? 基本ACK（BACK）數據包 ?

? BACK數據包由Falcon接收器發送給Falcon發送器，以確認收到數據包。接收方可以合并確認。因此，一個BACK包可以確認以前收到的多個包。BACK數據包的格式如上所示，并由下表定義。 ?

? 擴展ACK（EACK）數據包 ?

? EACK數據包用3個位圖擴展BACK：接收器數據序列號ACK位圖（Data - ACK - Bitmap）、接收器數據序列編號Rx位圖（Data - Rx - Bitmap）、接收器請求序列號位圖（req-bitma）。 ?

? 否定確認（NACK）數據包

? NACK 數據包由 Falcon 接收器發送到 Falcon 發送器，以響應 ULP 發出的錯誤信號或超出接收器滑動窗口的無序接收的數據包。NACK數據包的格式如上所示，并由下表定義。 ?

? 審核編輯：黃飛

?