通信网络
近日,谷歌正式向 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数据包的格式如上所示,并由下表定义。
审核编辑:黄飞
全部0条评论
快来发表一下你的评论吧 !