电子发烧友App
近日，谷歌正式向 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数据包的格式如上所示，并由下表定义。
审核编辑：黄飞
工商网监
评论