本文档是超以太网联盟发布的最新规范（2025.6.11）的中文翻译。英文规范路径：https://ultraethernet.org/wp-content/uploads/sites/20/2025/06/UE-Specification-6.11.25.pdf

此外，原始文档中表格，没有翻译，以及有的表格使用的截图，要搜索请到原始文档中搜索。

1 引言

1.1. 背景

超以太网联盟（UEC）是一项行业协作成果，有众多贡献者参与，包括超大规模数据中心运营商、系统供应商、芯片提供商等，其使命是增强以太网，使其适用于人工智能（AI）和高性能计算（HPC）领域。

贡献者们致力于涵盖一项成功规范的所有方面，包括软件 API、网络协议、硬件适配性与可扩展性、网络运营、合规性以及可扩展性。为实现 UEC 的使命，本文档规定了用于以太网网络的新协议，以及对现有以太网协议的可选增强功能，这些增强功能可提升 AI 和 HPC 应用的性能、功能和互操作性。

超以太网（UE）规范涵盖了与 AI 和 HPC 工作负载相关的广泛软硬件范围：从符合 UE 标准的设备所支持的 API，到传输层、链路层和物理层提供的服务，以及管理、互操作性、基准测试和合规性要求。

UE 不要求或强制更改网络层或以太网物理层（PHY）及链路层。例如，符合 UE 标准的实现可能会使用本规范发布时市场上常见的以太网交换机。不过，UE 提供了可选的网络层、以太网物理层和链路层功能，可为高要求的应用提供更优性能。随着实践经验的积累，这些可选功能中的一部分可能会逐渐普及，甚至成为必需功能。符合 UE 标准的实现需支持本规范中的强制性要求。

1.1.1. UEC 组织架构

UE 架构包含经典 ISO/OSI 网络模型的四个低层，以及软件服务和向上层暴露这些服务的 API。UEC 的每个工作组（如图 1-1 中的行所示）负责处理四个层级中的一个，定义所需的架构，并在可扩展性、能力、性能和互操作性方面提出严格要求和特征。UEC 管理工作组负责以太网 fabric 和终端的管理。UE 管理架构包括管理协议、传输方式和数据模型。UEC 合规性工作组与技术咨询委员会（TAC）合作，定义合规性和互操作性要求。UEC 管理工作组和调试与性能工作组与上述所有工作组均有交互。

此外，UEC 正在网络服务之外增加存储服务，以支持相关的应用和工作负载。图 1-1 中所示的作为列的工作组是在初始的作为行的工作组之后成立的。它们对 UE 规范和其他独立文档的贡献计划在未来版本中发布。

Figure 1-1 - Working Group Organization

UEC 是在 Linux 基金会联合开发基金会（JDF）旗下成立的国际标准开发组织（SDO）。UE 规范公开可供下载。未来版本一旦制定并批准，也将公开提供下载。UEC 成员的意图是将其工作成果提交给适当的标准组织和/或相关开源社区，以鼓励广泛采用，并为以太网、互联网协议（IP）、软件和 API 开发等主流行业标准化工作做出适当贡献。潜在的相关标准组织包括但不限于 IEEE、IETF、OCP、OFA、SONiC/SAI，以及各种存储和管理标准组织。

1.1.2. UE传输方案

UET 规定了三种方案：AI 基础方案（AI Base）、AI 完整方案（AI Full）和 HPC方案。AI 基础方案旨在以最低成本提供当前和未来 AI 应用所需的高性能功能。AI 完整方案增加了额外功能（如可延迟发送、精确匹配以及对原子操作原语的支持）。HPC 方案满足高性能计算应用的需求，在很大程度上是 AI 完整方案的超集。

每种方案都列出了合规产品在传输层提供的服务和所需的不同功能。方案在第 3.3 节中定义。终端的硬件接口细节不在 UE 规范的范围内。向上层提供的软件 API 是为了与高层软件实现互操作性而规定的。其目标是，支持特定方案的不同供应商的设备应能按照本规范中描述的那样实现互操作性和功能。

方案可能包含可选实现的功能。如果实现了可选功能，则必须遵循已定义的规范以声称合规。

1.2. UE规范约定

UE 规范在规范性语言、说明性注释、术语、单位、数字和图表格式方面采用以下约定。

1.2.1. 规范性、说明性和实现说明

规范性语言采用 IETF BCP14 中定义的术语。关键词 “必须（MUST）”、“不得（MUST NOT）”、“要求（REQUIRED）”、“应（SHALL）”、“不应（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）” 在本文档中仅当以全部大写形式出现时，其解释应遵循 IETF BCP 14 [4]、IETF RFC 2119 [1] 和 IETF RFC 8174 [2] 中的规定。

未明确标识为说明性注释的所有文本均为规范性内容。章节标题中的 [说明性（informative）] 标记适用于包括所有子章节在内的整个章节。图表在标题中未标记为 [说明性] 的情况下均视为规范性内容。

文本部分采用以下约定标记为说明性内容：

说明性文本：
本区域包含说明性文本。

偶尔，会包含给本规范实现者的注释，用于提供信息。这些注释旨在阐明规范的意图，并为实现者提供指导。它们采用以下格式表示：
实现说明：
本区域包含实现说明。

1.2.2. 术语（略）

1.2.2.1. 缩写词

1.2.2.2. 术语

1.2.3. 格式

图表用于定义协议头和协议序列交换。这些图表的约定如下所示。如果图表与文字描述无意中出现矛盾，以文字描述为准。

1.2.3.1. 头格式图示

图 1-2 是本规范中所示的完整头栈示例。这些完整头栈并未展示每个层级头的所有细节，而是标识了解析头和查找栈中下一层级所需的重要字段。头栈的层级显示在左侧，并以不同颜色区分。

Figure 1-2 - Example Full Header Format

图1-3是本规范其他章节使用的独立头部详图示例。字节编号标注于图示顶部和左侧。字节最低有效位（LSB）位于左侧首位，字节最高有效位（MSB）位于右侧。头部字段名称标注于顶部字节标签下方及左侧字节偏移量标签右侧。头部字段宽度严格按实际比特位宽绘制。保留字段在接收时应忽略，发送时须置零填充。每个独立图示均以字节偏移量0为头部起始位置，实际数据包中的头部偏移量由未在独立图示中展示的前导头部格式决定。

Figure 1-3 - Example Individual Header Format

头部详图后附表格提供字段说明。

1.2.3.2. 序列图

图 1-4 展示了本规范中使用的序列图示例。序列图用于说明两个实体之间以及实体内部各功能层之间特定信息交换的时间线。事件时间线从上到下流动。序列图并未规范性地描述实体之间交换的完整信息集，而是用于描述特定通信场景的实例。示例中显示了外部实体（如 libfabric provider）向 UET 语义层提供的消息，以及该消息如何被拆分为数据包并传递到 PDS 层，以通过线路传输到远程目标。一些重要的 UET 头字段显示在指示线路上传输的数据包的箭头上方。信息交换过程中发生的动作和事件使用虚线箭头和辅助文本突出显示。

Figure 1-4 - Example Sequence Diagram Figure

1.2.4. 引用

UE 规范包含规范性引用和说明性引用。规范性引用是确保 UE 组件之间互操作性所必需的。说明性引用旨在提供额外背景，帮助进一步理解 UE 的运行环境。UE 规范的每一章都可能提供规范性和说明性引用的列表。

本引言材料中使用的规范性引用如下：

[1] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels," 1997. [Online].

Available: https://www.rfc-editor.org/rfc/rfc2119.

[2] IETF RFC 8174, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words," 2017. [Online].

Available: https://www.rfc-editor.org/rfc/rfc8174.

[3] IETF RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6

Headers," 1998. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc2474.

[4] IETF BCP14, "IETF Best Pratice 14," 2023. [Online]. Available:

https://datatracker.ietf.org/doc/bcp14/.

1.3. 系统视图与术语

人工智能（AI）和高性能计算（HPC）领域正以极快的速度发展。AI 模型的变化速度更是有过之而无不及。这就需要针对各种 AI 和 HPC 工作负载进行精细调整的系统，既要支持横向扩展，也要支持纵向扩展。横向扩展指增加更多终端和 / 或 fabric 交换机；纵向扩展指通过增加更多的处理能力、内存和 / 或存储来扩展终端。

算法和模型的演进速度超过了硬件（主要体现在内存、存储和网络方面）。一个优化的系统需要在计算、网络（即 fabric）和相关数据（即模型参数和训练数据）这三者之间取得平衡。UE 规范明确针对网络技术，同时也间接涉及其他元素。

UE 规范适用于分布式工作负载（无论是 AI 还是 HPC 工作负载），并自然地沿用了并行计算中的一些术语。图 1-5 展示了UE 规范所涉及的并行计算组件、术语和概念的系统概述。下文将对 UE 环境及相关术语进行高层次的概述和介绍。本标准中规定的组件的程序、协议和操作的技术细节将在后续的规范性章节中给出。

UE 被规定在集群内运行，集群包括通过 fabric 互连的多个节点。端口实现了 IEEE Std 802.3 所定义的单个媒体访问控制（MAC），根据其遵循的 UET 方案的要求，还可选择性地包含任何 UE 特定的扩展。链路连接两个端口。fabric 接口（FI）是一个物理实体，它提供一个或多个端口，并向一个或多个操作系统实例（OSI）暴露一个或多个 fabric 端点（FEP）。fabric 地址（FA）是 IPv4 或 IPv6 地址，FEP 是被分配了单个 FA 的逻辑可寻址实体。UE 传输协议在 FEP 处终止，还可选择性地包含一个安全上下文。具体而言，一个 FEP 只能被单个 OSI 使用，一个节点可能拥有一个或多个 FEP。每个OSI可以使用一个或多个FI搭配一个或多个FEP接入到fabric。

交换机拥有两个或更多端口，是 fabric 的一部分，用于转发数据包。数据包根据转发信息沿路径转发，转发信息包括数据包的FA、其他头部字段（例如用作熵值的 UDP 源端口）和交换机状态。具有相同路径转发信息的任意两个数据包应通过 fabric 采用相同的路径。fabric 平面是一组 FEP 的集合，这些 FEP 通过链路连接，还可选择性地通过交换机连接，使得该集合中的任何 FEP 都能与其他 FEP 通信。不同 fabric 平面的 FEP 之间的通信超出了本规范的范围。路径存在于 fabric 平面内，而不存在于 fabric 平面之间。fabric 由一个或多个 fabric 平面组成。

Figure 1-5 - System Overview

节点是具有一个或多个 FEP 的计算设备。集群是通过 fabric 连接的一组此类节点（注意：图 1-5 中的简化图表仅用于说明，仅显示了集群中的一个节点。典型的 UE 部署可包含数十万个节点）。加速器是为高效执行特定功能而设计的计算模块或设备。CPU 是用于任意计算的通用处理器。CPU 和加速器都连接有内存，FEP 可通过虚拟寻址访问这些内存。节点可包含本地存储，还可包含一个或多个 CPU 和 / 或一个或多个加速器。

用户是有权访问集群节点的实体。用户可以执行进程。进程是在特定用户拥有的 OSI 上运行的程序实例，具有私有的内存虚拟地址空间（VAS）。进程由其运行所在的 OSI 上唯一的进程 ID（PID）标识。进程地址空间 ID（PASID）是每个 OSI 内VAS 的唯一标识符。

集群有两种基本不同的使用方式，且这两种方式可能共存：

1. 以并行作业模式执行（例如，MPI/*CCL 或 SHMEM）。
2. 以客户端 / 服务器模式执行，其中客户端可以连接到服务器（例如，存储或功能即服务（FaaS））。

每个数据包都携带一个标识符，指示它所参与的模式。并行作业执行的特点是 “运行至完成” 模式，而客户端 / 服务器执行通常是服务器无限期运行，为无限数量的客户端提供服务（通常具有复杂的可靠性和可用性保证）。

两个 FEP 要进行通信，需要具备 IP 级别的连接性。UE 网络支持多端口 FEP，前提是存在一个 FA（即 IP 地址）与任何 FEP 相关联。与 FEP 相关联的 FA 被用作从该 FEP 发送的所有数据包的源地址，或发送到该 FEP 的所有数据包的目的地址。

FEP 可以有多个端口（如图 1-6 中的场景 A）。UE 不强制规定这些端口的使用方式。可能的多端口配置有多种，包括：与同一交换机上的成员端口形成链路聚合（LAG）（如图 1-6 中的场景 D）、与不同交换机上的成员端口形成多交换机 LAG（如图 1-6 中的场景 E）、通过多个端口实现到 FEP 独立地址的 IP 级多路径连接，或采用主备配置。在公共 fabric 接口上支持多个端口的其他场景也是可能的，具体取决于实现（如图 1-6 中的场景 B、C 和 F）。图 1-6 中的场景 F 显示了 fabric 接口卡上的嵌入式交换机。

Figure 1-6 - Multi-plane Networks and Multi-port FEPs

在多端口 FEP 架构中，UET 拥塞管理子层为每个数据包选择熵值。UET 不强制规定多端口主机的特定端口选择方法，不同实现可采用不同的方法。

说明性文本：
在多端口配置中，网络应提供一种机制，使 FEP 能够检测到某个目的 IP 地址（例如，对等 FEP 的 FA）在任何给定平面上是否不可达，若不可达，则避免使用该平面与该目的地址通信。实现此目的的可能方法包括使用 IP 路由协议或 ICMP 不可达消息向 FEP 传达不可达性。然而，UET 不强制规定任何特定技术。未来，UET 中可能会定义用于确定可达性的机制。

两种不同的计算模型在寻址方面有所区别：并行作业模型和客户端 / 服务器模型。单个 FEP 可设计为支持两种流量类型，也可仅支持其中一种。两种模式可在单个 FEP 上同时运行。图 1-7 和图 1-8 概述了集群内的这两种不同计算模型。

Figure 1-7 - Parallel Job Model

并行作业（job）是在集群上运行并通信的一组进程，这些进程属于同一用户。作业通常是集体启动的，在集群内由唯一的JobID 标识。JobID 用于寻址和授权。作业由一个或多个 rank 组成，这些 rank 是协同计算特定工作负载的进程。一个作业可在每个 OSI 上生成多个 rank，一个 OSI 也可承载多个作业的 rank。如果一个作业全局包含 R 个进程 /rank，则它们的 RankID 从 0 到 R-1 编号。在并行作业模型中，FEP 上的 PIDonFEP 寻址范围是 0 到 P-1，其中 P 是与某个给定作业相关联的 FEP 上的进程数量。如果每个 FEP 上关联的进程数量相同，则每个端点可以轻松计算出特定 RankID 对应的 PIDonFEP。例如，假设一个作业在 N 个节点的R个rank上运行，每个节点有 F 个 FEP。RankID的范围是0到R-1，每个节点的 rank 数量为 R/N，每个FEP 的 rank 数量为 R/N/F。此时，P 为 R/N/F，PIDonFEP 的范围是 0 到 P-1，即 0 到 R/N/F-1。

服务器是节点上为一个或多个客户端提供服务的软件实体。客户端和服务器通过 FEP 进行通信。服务器 PIDonFEP 标识特定FEP 上可用的服务，资源索引标识该服务内的资源。同一 FEP 可被多个服务器使用（在单个 OSI 上），单个服务器也可通过FEP 上的多个 PIDonFEP 提供服务。客户端 / 服务器 JobID 在概念上类似于 “多对一” 连接，用于客户端对服务器的授权，但它可能是短暂的，仅在流量活跃时存在。服务器 PIDonFEP 和资源索引的组合在概念上类似于 TCP/UDP 端口。

Figure 1-8 - Client/Server Job Model

UET 服务器可以使用知名的服务器 PIDonFEP 值和一组特定服务的资源索引，UET 客户端可以使用预先配置的静态服务器FA，或者通过各种发现机制（如 DNS 或 “hosts” 文件）将服务器的主机名或别名解析为 FA，从而与服务器建立通信。此外，UET 客户端和服务器还可以选择利用非 UET 发现方法，例如先建立 TCP/IP 连接，再交换 UET 功能、地址和标识符。

UET 有相对和绝对两种端点寻址模式（见图 1-9）。相对寻址模式在并行作业模型中提供连续寻址，以确保能够扩展到最大进程数。绝对寻址则用于客户端 / 服务器模型。

在相对寻址模式中，UET 定义了目标地址的四个互补部分：

1. 标识 FEP 的 FA。
2. 在集群中唯一标识作业的 JobID。
3. 范围为 0 到 P-1 的 PIDonFEP。
4. 标识目标进程内服务、库或其他实体的资源索引（RI）（例如，MPI与*CCL）。

当数据包到达目标 FEP 时，可以根据 JobID 和 PIDonFEP 的组合确定目标 PASID。

Figure 1-9 - Addressing Modes

说明性文本：
假设一个作业包含 K 个终端和每个终端 P 个进程。这种寻址方案允许在源端使用一个大小为 K-1 的表来转换到目标 FA，然后在该目标端使用一个大小为 P 的表来转换到目标进程。在每个终端支持多个作业的系统中，JobID 用于在目标端区分不同的作业，以找到正确的大小为 P 的 PIDonFEP 表。这避免了如果使用一个扁平地址空间所需要的 O (K*P) 表项，而是用 O (K+P) 表项取而代之。K 预计为数万个，P 预计为数百个。

在绝对寻址模式中，UE 定义了地址的三个互补部分：

1. 标识 FEP 的 FA。
2. 标识与目标 FEP 相关联的 OSI PID 之一的 PIDonFEP。
3. 标识目标进程内服务或其他实体的资源索引（RI）。

RI 用于寻址服务器中的特定子程序或功能（例如，运行 FaaS 或 rPC 服务）。当数据包到达目标 FEP 时，目标 PASID 是基于PIDonFEP 确定的。JobID 不作为寻址的一部分，但用于客户端对服务器的授权。

消息代表 UE 网络中的单个通信事务。图 1-10 展示了消息通信交付背后的主要概念。事务由进程调用 UET libfabric 提供程序（provider）创建，该提供程序进而调用语义层。语义子层创建各种消息以完成事务。消息及其相关缓冲区在源 FEP 处按内存寻址顺序拆分为一组有序的数据包。这些数据包通过网络沿路径发送和路由，可能不按顺序进行。消息最初可能涉及UET语义规范中定义的会合协议步骤。

此类消息的源称为发起方，目的地称为目标方。每个数据包都有一个源 FEP 和一个目标 FEP。路径是两个 FEP 之间通过节点和 / 或交换机的有序链路集合。在不考虑 fabric 中数据包丢失的情况下，同一流量类别（TC）的数据包沿相同路径发送时，总是按发送顺序在目标 FEP 处接收。当数据包在两个 FEP 之间通过多条路径路由时，不同路径的数据包到达顺序不做保证。UET 期望在路由不变的情况下，交换机将来自同一 PDC、具有相同熵值和流量类别的两个数据包沿相同路径传输。UE 传输协议（UET）定义了 FEP 通信所使用的协议、数据包格式和 FEP 策略。FEP 可设计为支持并行、客户端 / 服务器或两者的流量类型。

Figure 1-10 - Transport Data Delivery and Packet Delivery Contexts

数据包交付上下文（PDC）是两个 FEP 之间的单向逻辑实体（通常是临时的），由传输层定义，存在于发起方 FEP 和目标方FEP，用于控制数据包的成功传输。数据包交付子层（PDS）创建和使用 PDC 来提供请求的排序和可靠性交付模式。可靠性通过确认数据包（即 ACK 和 NACK）来实现，目的地将这些数据包传输到源以指示端到端接收成功。拥塞管理子层（CMS）控制源在任何给定时间可以传输到目的地的字节数。数据包窗口是 CCC 上允许的最大未确认字节数。同一作业的多个进程可以共享单个 PDC，单个进程也可以使用多个 PDC 与另一个进程通信。两个 FEP 之间可以有一个或多个 PDC，每个数据包都标识一个相关联的 PDC。

1.3.1. 工作负载 [说明性]

本小节中的信息是背景材料，代表 UE 规范 v1.0 发布时工作负载的最新状态。UE 针对以下四种工作负载：

1. 人工智能训练（AIT）
2. 人工智能推理（AII）
3. 高性能计算（HPC）
4. 客户端 / 服务器（例如，存储流量）

1.3.1.1. 人工智能训练工作负载

人工智能训练工作负载最初以 “3D 并行性” 为特征，其通信模式在有利情况下可以表示为 3D 环面。第一个维度是数据并行性（DP），其中单个小批量中的样本通过多个模型副本进行处理，梯度或权重通过 allreduce 操作进行同步。

第二个维度是管道并行性（PP），其中每个管道阶段是模型的一组层，激活在正向传播方向通信，误差在反向传播方向通信，在不同加速器上的相邻层之间形成管道，采用点对点通信。

第三个维度是算子并行性（OP），这取决于层的类型。对于大型语言模型（LLMs），主要的层操作是矩阵乘法。因此，层会实现并行矩阵乘法，这也可以通过 allreduce 操作来表示。“混合专家”（MoE）模型通常使用专家并行性（EP），这在 3D 并行性视图中类似于算子并行性。EP 将 k 个（通常 k=16 到 256）模型捆绑在一起，并在它们之间执行 alltoall (v) 操作。alltoall (v) 操作并不总是平衡的。人工智能推理并行性与此非常相似。不同之处在于它不考虑数据并行性，通常使用非常小的批量。因此，作业大小和传输的消息通常都较小。

后来，添加了更多的并行性维度，如序列和上下文并行性，可能会导致更高维度的通信结构。

作为工作负载示例（大约 2023 年），著名的 GPT-3 模型在 96 个 Transformer 层中有 1750 亿个参数。以 FP16 格式存储这些参数需要 350 GiB，这需要 2023 年可用的多个最先进的加速器（不考虑训练过程中存储的激活或其他临时值或副本）。在这种情况下，如果沿管道有 6 个加速器，在算子并行性维度有 4 个加速器，那么每4个加速器有 16 个 GPT 解码器层。在 2023 年可用的加速器上，这将花费大约 160 毫秒的计算时间。通信量则是每个维度（管道和算子）每层 50 MiB。

假设目标服务级别目标为 200 毫秒，则 40 毫秒用于管道通信和环形 allreduce（其中数据发送两次）。每个加速器现在为allreduce 发送 50 MiB 16*2 次，沿管道维度发送一次。因此，它需要在 40 毫秒内传输 1.7 GiB，需要 41 GiB/s 的带宽。为了实现更低的延迟，可以扩展算子维度并减少通信时间。对于 10 毫秒的服务级别目标，大约需要 150-200 GiB/s 的吞吐量。

人工智能训练工作负载遵循 3D 并行性方案，但除了权重外，每个加速器通常还存储权重的 “黄金副本” 以及其层的所有激活输出，直到在反向传播中应用梯度。一般来说，人工智能训练工作负载需要极高的（低成本）带宽，对延迟的敏感度从中到低。典型的消息大小在兆字节或更大的范围内。

1.3.1.2. 人工智能推理工作负载

人工智能推理工作负载遵循 3D 并行性方案，但不提供数据并行性，因为每个输入样本都是用户请求。它们可能会被批处理，但通常这只是为了提高加速器效率。人工智能推理工作负载有时具有严格的服务级别目标，以满足交互式使用模式。在这种情况下，批处理量更小，导致激活（管道消息）和操作（allreduce）的大小也更小。这些通常保持在千字节范围内。

以 GPT-3 上的生成式人工智能推理为例。在这种情况下，输入只有一个标记（token），而不是上述 GPT-3 示例中的完整序列。因此，所有内容都大约小一个序列长度（GPT-3 为 2048）。实际上，生成式推理系统通常使用束搜索来提高质量。束宽为 4 时，总缩减因子为 512。不幸的是，权重内存保持不变，导致相同的分布（OP=4，PP=6）。计算现在可以小至 1 毫秒，并将每个加速器发送 3.3 MB 的数据。在 1.2 毫秒的服务级别目标下，缩减操作将在 0.2 毫秒内完成，导致带宽要求为 16 GB/s—— 但现在 allreduce 的大小约为 100 KB。如果这些被拆分到多个平面上，消息大小将在个位数千字节范围内。带宽需求随着分布式KV缓存而增长！推理通常比训练需要更低的延迟。

1.3.1.3. 高性能计算工作负载

高性能计算工作负载分为两类：（1）低深度（LD），具有高度并行性；（2）高深度（HD），具有长依赖链。HD 工作负载通常具有长而窄的有向无环图（DAGs），导致对延迟敏感的执行。许多强扩展问题具有这种形状。

以天气预报为例。在这种情况下，计算必须在特定时间内完成。算法在模拟过程中运行多次迭代，时间步长与分辨率成反比。更高精度的高分辨率模型导致更小的时间步长。在实践中，此类模型的通信开销很高（25-50%），主要是重复模式中的小（单包）消息（2.5 kiB）。

许多其他工作负载是 LD，因此对延迟不太敏感。大多数弱扩展工作负载，其中可以调整本地域大小以在给定系统上良好运行，都属于这一类。其中一些工作负载可能需要高带宽（如人工智能训练）或高消息速率（如图算法）。

1.3.1.4. 客户端 / 服务器（例如，存储流量）

存储流量负责将数据从存储服务器传输到终端，是客户端 / 服务器通信的一个示例。通信协议栈通常会将较大的请求拆分为多个较小的消息（例如，一些 MiB 甚至一些 KiB）。这些消息的大小在某种程度上可以根据传输协议进行调整。

数据访问模式和大小取决于用户，很少由系统管理员控制。因此，随机的扇入事件（例如，许多客户访问同一台存储服务器）会定期发生。

1.4. 软件

1.4.1. 人工智能和高性能计算API接口

UE 旨在支持 libfabric v2.0 APIs，并与 libfabric 社区合作，使终端能够与人工智能框架和高性能计算工作负载进行交互。一些UE 的可选功能需要网络设备（如交换机）支持高级功能，例如数据包修整。为此，网络操作系统（NOS）需要进行扩展以支持 UE 功能

UE 目前不涉及跨管理域的交互。

1.4.2. fabric 终端软件栈

图 1-11 展示了运行在 FEP 上的软件栈。

Figure 1-11 - UE Software Endpoint Stack

UE 旨在支持现有的 AI 训练（AIT）和 AI 推理（AII）框架。这些框架，如 TensorFlow、PyTorch、JAX 等，有望在 UE 软件栈之上无缝运行。换句话说，UE 的一个目标是使依赖这些框架的应用程序能够迁移到支持 UE 的节点上，而无需进行修改。这些框架通常会利用依赖于硬件的特定供应商的*CCL 库。然而，符合 UE 标准的*CCL 库，虽然没有直接规定，但不需要对应用程序进行修改。

1.4.3. 交换机软件栈

图 1-12 展示了一个支持 UE 功能的交换机软件栈示例。UE 可以在现有的以太网交换机上运行，但通过在交换机中支持可选的UE 功能，可以获得额外的能力。UE 环境中的交换机预计将运行各种网络操作系统（例如，SONiC、FBOSS、Junos OS、IOS 等）。交换机芯片中可选的 UE 功能可以通过交换机芯片抽象接口（例如 SAI）来访问，该接口已经为 UE 进行了适当的增强。交换机及其相关的网络操作系统（NOS）的转发模式无需更改。基于 IP 的转发可以保持不变；但是，为 UE 定义了一些可选功能（例如，数据包修整）。

Figure 1-12 - Switch Module Layering

1.4.4. 网络操作系统（NOS）接口

NOS 在交换机上提供配置和控制方面的基本服务。一些 NOS 组件可能需要更新以支持 UE 功能。以下是一些示例：

• 用于 LLDP 的 UE 组织特定的 TLV。
• 数据包修整。

图 1-12 展示了各种交换机模块的分层。交换机抽象接口（SAI）之上的层称为 NOS 控制平面，其之下的功能称为 NOS 数据平面。

控制平面软件通过抽象 API 与数据平面功能进行交互。一个示例接口是开放计算项目（OCP）中开发的交换机抽象接口（SAI）。SAI 在供应商提供的软件开发工具包（SDK）之上提供了一个抽象层。这种抽象有助于 NOS 通过一组一致的 API 与硬件编程进行交互。请参见以下参考资料：

• <https://www.opencompute.org/wiki/Networking>

• <https://www.opencompute.org/wiki/Networking/SAI>

软件定义网络（SDN）控制器可能是 UE 实现的一部分，但不在 UE 规范的范围内。

1.5. 网络

1.5.1. 人工智能和高性能计算网络分类

如图 1-13 所示，UE 将网络分为三种类型：

1. 前端网络
2. 后端横向扩展网络
3. 纵向扩展网络

1.5.1.1. 前端网络

前端网络是数据中心中的运营网络，用于将所有计算节点连接到外部世界（例如，其他数据中心或互联网上的终端客户）。这使得前端网络成为数据中心中最重要的组件之一。前端传输的任何可用性损失都会直接影响客户并带来相关成本。由于前端网络连接客户和远程数据中心，它可能支持多种传输协议（例如，TCP/IP、UDP/IP 和 QUIC），这些协议可以在具有毫秒级延迟的长距离链路上运行。此外，计算节点的多租户模式经常被使用，这可能需要网络重叠（overlay）技术来支持虚拟机迁移和网络虚拟化。

从根本上讲，前端网络承载两种类型的流量：“南北向”（NS）流量，即往返于外部世界（即其他数据中心和客户）的流量；以及 “东西向”（EW）流量，即来自同一数据中心内网络终端的流量。每种流量类型具有根本不同的特征。例如，东西向流量通常比南北向流量带宽更高，并且数据包的 “价值” 较低（即，与南北向流量相比，它们可以被丢弃和重传的成本更低）。此外，东西向流量通常对延迟（即微秒级）和带宽（例如，数十吉比特每秒（Gb/s））有更严格的要求，因为它经常连接各种服务，如微服务的深度调用链、无服务器功能（function）或存储访问。南北向流量通常面向客户，瓶颈经常出现在数据中心外部。这些特征可能将延迟限制在个位数毫秒，带宽限制在数十兆比特每秒（Mb/s）。

Figure 1-13 - Network Types

除了提供高可用性外，处理这两种类型的流量使得前端网络相当复杂。交换机和网络接口卡（NIC）需要支持复杂的功能，如过滤、 policing、封装和安全。

1.5.1.2. 后端横向扩展网络

后端网络通常是一个专门的高性能网络，与前端网络相比范围有限 —— 通常部署在一个 “集群” 中（例如，一组机架）。它有时也被称为 “横向扩展” 网络。后端横向扩展网络通常形成自己的三层子网，通常不直接连接到前端网络。前端和后端网络之间的通信通常通过具有两个网络接口的计算节点进行。

后端横向扩展网络有非常特殊的用途。例如，高性能计算后端横向扩展网络通过消息传递接口（MPI）实现通信，而深度学习后端横向扩展网络传输训练流量。面向人工智能的后端横向扩展网络可能包括特殊的优化，如交换机支持对大量数据的集合操作，而面向高性能计算的后端横向扩展网络可能仅对小型集合支持延迟优化。

拥有两个网络可能会增加整个系统的成本（即，两个网络而不是一个 —— 独立的前端和后端网络）。然而，两个网络实现了流量的清晰分离（即，没有干扰）和设计的分离（即，允许不同的架构和技术部署）。在一些经典的高性能计算系统中，后端横向扩展网络为计算节点提供所有的连接和网络服务。然而，这是通过在高性能计算传输（例如， portals、IPoIB）之上改造传统的传输协议（例如，TCP/IP）来实现的，并且需要接受由此带来的权衡。

1.5.1.3. 纵向扩展网络

纵向扩展网络通常是非常专业的短距离互连，通常只配备单层交换机，甚至可能根本没有交换机。

历史上的纵向扩展网络支持输入 / 输出（I/O）一致性，而这种一致性并非在所有类型的互连中都存在。现代用于连接加速器（例如，被称为 GPU、FPGA 或专用片上系统的 XPU）的示例包括 AMD 的 XGMI、NVIDIA 的 NVLINK、英特尔的 Xe Link、交换式 PCIExpress 以及 CXL 系统。这些网络的功能通常包括内存语义（类似于用于批量传输的 RDMA），且能实现极低的延迟（针对小规模或程序化内存访问，目标是亚微秒级）。UE 主要关注后端和横向扩展网络，但 UE 技术的理念和部分内容可能适用于纵向扩展网络。

在 2024 年典型的数据中心环境中，这三种类型的网络具有不同的特征，汇总于表 1-1 中。

Table 1-1 - Distinctive characteristics by network type (circa 2024)

Characteristic (2024)	Frontend (Intra Data Center)	Backend Scale-out	Scale-up
Latency requirements1 (One-way delay)	100 µs+	< 10 µs	< 1 µs
Single-link bandwidth requirements	up to 100 Gbit/s	up to 800 Gbit/s	up to 800 Gbit/s
Number of links	1 per node	1 to 2 (per accelerator)	Many (per accelerator)
Multi-tenancy requirements	Hundreds of tenants per endpoint	Up to tens of tenants per endpoint	Usually, single tenant
Security requirements	Important today (SSL/TLS encrypt everything)	Important in the future for some (depends on offering, encrypt everything should be optional)	Optional
Protocol requirements	Wide variety of transport protocols (all IP compatible, some workload- specialized proprietary, need to co-exist)	Proprietary protocols ok (desired for workload specialization, probably L3 headers for compatibility, no need to co-exist)	Proprietary protocols necessary (probably no IP for performance reason, L1/L2 headers only, some provide coherency)
Maximum link length requirement	1500 m	150 m	5-10 m
Deployment scale (network endpoints)	256k+	256k	100-1000
Topology	3 level Clos	2-3 level Clos or Dragonfly	full mesh or single stage switch
Single-job scale (network endpoints)	100	256k	100-1000
Note: 1. The latency requirement is a bound on the range of the congestion window for full bandwidth.

说明性文本：
本规范侧重于后端横向扩展网络。UEC 将考虑适时支持前端网络和纵向扩展网络。其目的是，在进行权衡时，支持前端网络或纵向扩展网络的目标不会影响后端横向扩展部署的性能，也不会影响本规范的交付进度。

1.5.2. UE 传输（UET）目标

UET 致力于为高性能计算和人工智能（AI 训练和 AI 推理）的工作负载及用例提供支持。UET 主要以 RDMA 服务为目标，力求为在人工智能和高性能计算工作负载中传输 RDMA 提供最佳、现代化且高度优化的传输服务。其一般特征汇总于表 1-2 中。这三种用例（即专用 AI 训练集群、云 AI / 高性能计算以及大规模高性能计算）涉及到两类组织：一类是充分利用单个应用程序的全系统规模的组织，另一类是在机器中大量运行单节点应用程序的组织，以及介于这两者之间的所有情况。UET 的目标是通过单一传输协议满足这些广泛的用例需求。

Table 1-2 - Characteristics of UET Deployment Model

Characteristic (2026+)	Dedicated AI Training Cluster	Cloud AI/HPC	At Scale HPC
Network scale (Ethernet ports)	100k – 256k	256k	80k – 256k
Target unloaded one-way latency	2 – 10 µs	2 – 10 µs	2 – 10 µs
Ethernet port speed	800 G+	400 G+	800 G+
Average network utilization	Up to 85%	20-40% overall BW 60-80% for AI cloud	Varies, 60-80% for BW-intensive apps
Packet rate	Low	Mixed	High
Message size	Relatively large	Mixed	Tiny to Mixed
Encryption	Optional	Required	Optional
Multi-tenancy	Node-level job isolation	Node-level job isolation + network virtualization	Node-level job isolation

UET 的另一个目标是提供易于加速器使用的接口。这包括制定一项规范，以最大限度地降低集成终端所需的硬件复杂性。另一个方面是制定软件解决方案，使加速器和其他处理器能够更多地借助硬件来实现功能。例如，UET 可能允许加速器掌控 “快速路径”，而将其他功能（如管理和复杂错误处理）转移到单独的处理器（如主机 CPU）上。终端内部与加速器之间的硬件实现和接口细节不在本规范的范围内。

虽然 UET 在尽力而为网络上借助多路径和由网络遥测辅助的改进型拥塞控制能提供出色的性能，但它在架构上也适用于无损网络。对于尽力而为网络，UET 借鉴了从以太网、TCP/IP 以及为包括云在内的各种应用部署的大规模网络的成功经验中得出的两个基本教训：传输协议应提供丢失恢复功能；许多大规模无损 fabric 在运行时不引发线头阻塞和拥塞扩散，会面临诸多挑战。遵循这些原则，UE 传输建立在经过验证的分布式路由算法以及基于终端的可靠性和拥塞控制基础之上。

1.5.3. 网络 fabric

网络 fabric 由以太网交换机和下文所述的相关元素组成。

1.5.3.1. 元素

UE 交换 fabric 包含三个常见的功能平面：控制平面、数据平面和管理平面。这些平面如图 1-14 所示，描述如下。

1.5.3.1.1. 控制平面

控制平面负责运行关键功能，如路由协议，以维持 fabric 交换机之间的通信。该层由 SONiC、FBOSS 等网络操作系统（NOS）进行管理。控制平面通过 SAI 等标准 API 或特定供应商的 API 与交换机数据平面进行交互。

Figure 1-14 - Layered View of Networking Functionality

1.5.3.1.2. 数据平面

数据平面也称为转发平面，负责在网络中转发数据包。该层涵盖 UE 终端（即 FEP）和网络交换机。需要明确的是，数据平面不控制或管理 UET FEP。该层包含交换机硬件的低层抽象，并负责根据控制平面提供的转发信息转发数据包。

1.5.3.1.3. 管理平面

管理平面负责确保交换 fabric 的正常运行、可靠性和安全性。管理系统和相关协议执行软件升级、监控和其他管理活动。管理平面通过 Netconf、gNMI、SNMP 等标准接口与控制平面进行交互。管理平面所操作的被管理对象由 YANG 等标准化数据模型定义，并得到 OpenConfig 等厂商中立软件的支持（参见：https://openconfig.net）。

说明性文本：
传统上，终端的管理与 fabric 的管理是分开的。UE 遵循行业和各组织所习惯的这种传统分离方式。UEC 管理工作组负责确保符合 UE 标准的设备具备完整的功能、性能和互操作性。

1.5.3.2. 物理网络中的 UE 交换机运行

符合 UE 标准的交换机在两种类型的物理网络中运行：

1. UE 数据平面网络：通过 UE 交换机将 FEP 相互连接的网络。该网络承载各种工作负载的应用程序流量，并针对 UE 规范进行了优化。
2. 交换机管理网络：每个交换机至少提供一个专用以太网端口，用于连接非 fabric 终端，如 SDN 控制器、fabric 管理器、遥测收集器、SNMP 服务器以及其他负责管理基础设施的设备。该网络对延迟不敏感，通常带宽要求较低。

1.5.3.3. 拓扑结构

拓扑结构是人工智能和高性能计算 fabric 的关键部分，因为它通过定义网络直径和对分带宽来确立性能边界。部署时需要考虑系统在能耗以及电缆成本等物理方面的最优成本。

本规范中的拥塞管理以 Clos 网络为目标，但不排除其他拓扑结构。然而，除了折叠 Clos 网络（即胖树）之外，没有为其他拓扑结构设定优化或性能目标。本规范中的拥塞管理已在胖树网络拓扑上进行了模拟。

1.5.3.4. 网络约束

UE fabric 受限于使用基于 IPv4/IPv6 的三层转发。目前尚未规定使用隧道（如 VXLAN）的 UE fabric，这部分内容由实现者自行决定。多租户问题可以在 FEP 层面通过加密租户应用程序数据、特定分配 JobID 来解决，也可以利用现有的隧道机制。

UE 不需要对网络层进行更改，可以使用现有的路由协议。UE 交换机使用等价多路径（ECMP）路由进行负载均衡，其中熵值由 UET 拥塞管理子层（CMS）管理。拥塞管理算法的设计基于这样的预期：fabric 交换机不会修改熵值，并且任何具有相同熵值的两个数据包在 UE fabric 中会走相同的路径。CMS 期望 UE 交换机支持 IETF RFC 3168 中规定的显式拥塞通知（ECN），但有一个附加约束：在出队传输时标记拥塞数据包，而不是在入队时。第 4.1 节中规定的数据包修整是另一种拥塞通知机制，它利用多个区分服务代码点（DSCP）来识别可被修整和已被修整的数据包，并确保这些数据包被映射到适当的流量类别以进行加速转发。

流量类别体现在终端和交换机中用于差异化传输数据包的机制和资源（如队列、缓冲区、调度器）中。流量类别彼此不同，并且可以相互确定优先级。数据包通过所接收数据包的属性和头部字段映射到相应的流量类别。UE 主要依靠 IP 头部中的DSCP 字段来识别所接收数据包的流量类别。

说明性文本：
流量类别在多个层面进行规定。UE 将 libfabric 层规定的流量类别映射到整个 fabric 的流量类别。例如，UET 建议为请求和确认/否定确认分别设置不同的流量类别。UET 对流量类别采用宽泛的定义，以认可那些整合了排队资源和转发机制的实现，这些机制能够实现通过区分服务代码点（DSCP）识别的数据包的差异化转发。DSCP 可以识别 64 种不同的区分服务，其中 16 种可用于本地定义和使用。各种实现提供了多种方式来配置在终端链路和交换机层面将通过 DSCP 识别的数据包映射到流量类别的过程。UE 目前没有确定或定义执行这种映射的标准。在某些情况下，多个 DSCP 值可能映射到同一个流量类别（参见CMS 第 3.6.4.7 节中的 UET DSCP 映射表）。UE 功能依赖于终端和整个 fabric 中流量类别的一致配置和使用。UE 建议采用一致的映射，网络运营商负责确保这种一致性。

图 1-15 展示了应用程序请求的流量类别到终端和交换机链路层可用流量类别的映射。虚线框内所示的项目是 UE 操作员在 UE 解决方案栈不同层级可使用的配置值。应用程序可以使用 fi_domain () 库 API 指定所需的 libfabric 流量类别。如果未指定，UE libfabric 映射的第 2.2 节会提供用于请求的默认 DSCP 值。CMS 规范在第 3.6.4.7 节中提供了一份 DSCP 到流量类别的映射表。该表描述了不同类别的 DSCP 值如何映射到链路层的流量类别。

从 libfabric 层为消息请求提供的 DSCP 值会被传递，并被归类为 DSCP_TRIMMABLE（可修整）或 DSCP_NO_TRIM（不可修整）。UET 协议包含为生成的确认（ACK）、否定确认（NACK）和控制数据包分配的 DSCP 值，这些被归类为DSCP_CONTROL（控制）。UET 协议还可以将重传的数据包归类为 DSCP_TRIMMABLE_RETX（可修整重传）。所有这些DSCP 类别都被映射到链路级别的 TC_high（高流量类别）和 TC_low（低流量类别），其中 TC_high 的优先级高于 TC_low。

进行数据包修整的交换机（图 1-15 中以剪刀图标表示）会将 DSCP 值更改为 DSCP_TRIMMED（已修整）或DSCP_TRIMMED_LASTHOP（已修整最后一跳），具体取决于它们在 fabric 拓扑中的位置。已修整数据包的 DSCP 值可以映射到第三个流量类别（TC_med，中等流量类别）（如果可用），否则使用 TC_high。在交换机内将 DSCP 值映射到流量类别的管理操作要么是特定于供应商的，要么目前尚未明确规定。

UET 的拥塞管理子层在设计时要求至少为 PDC（数据包交付上下文）使用两个流量类别，以实现高性能。网络运营商负责分配和配置 UET 所使用的流量类别。UET 数据包类型到流量类别的映射取决于网络是尽力而为型还是无损型。更多详情参见CMS 的第 3.6.4.7 节。

Figure 1-15 - Traffic Class Mapping

1.6. UE 规范概述：各层级

UE 规范涵盖从软件层一直到物理层的多个层级。图 1-16 按层级展示了 UE 规范的必需组件和可选组件。以下各节将对每个层级进行概述：

Figure 1-16 - UE Specifications by Layers

1.6.1. 软件层

UE 软件规范在第 2 节中给出，其中包括与 libfabric API 的映射。

libfabric 映射：符合 UE 标准的实现支持开放 fabrics 接口 ——libfabric API（Libfabric）。libfabric v2.0 是符合 UE 标准的终端的基准 API。libfabric 是北向 API，UE API 在其中定义，合规性也在此进行检查。UE 规范有望与libfabric 社区保持一致。选择 libfabric 是因为它支持基于 RDMA 的 fabrics 上的多种工作负载，并且有许多厂商在开发符合该规范的硬件和软件时采用了它。多家厂商已成功开发出能够支持基于 MPI 的高性能计算应用程序，同时也支持 PGAS、SHMEM 和其他编程模型的产品。与此同时，厂商们还开发了支持热门人工智能框架（如 PyTorch、TensorFlow 或 ONNX）的库。事实证明，所有这些厂商提供的产品都能轻松且高效地通过 libfabric 进行映射。UEC 与 libfabric 社区合作，在适当且有必要时扩展 libfabric API，以支持新的 UE 功能。

1.6.2. 传输层

UE 传输层规范在第 3 节中给出。UE 传输协议旨在满足高性能计算和人工智能工作负载的网络需求。定义了不同的方案，以便对产品进行优化，从而满足这些工作负载的独特需求。预计人工智能和高性能计算工作负载的网络需求将日益重叠。UE 传输协议支持多种实现方式。UE 传输协议的组件包括消息语义、数据包交付可靠性模式、拥塞管理和安全性。

语义子层（SES）：SES 子层旨在通过 libfabric 映射整合到广泛部署的人工智能框架和高性能计算库中。使用 libfabric 的应用程序通过 fabric 交换消息，并采用流行的零拷贝技术将这些消息直接放入彼此的缓冲区内存中。SES 子层规定了一种协议，该协议定义了应用程序消息的识别方式、相关缓冲区的寻址方式以及消息的首选操作的使用方式。SES 子层是 UE 传输与libfabric 提供程序之间的主要接口。

数据包交付子层（PDS）：应用程序的需求决定了相应的 UET 数据包交付服务的选择。不同的应用程序针对消息交付的各种可靠性和数据包排序约束进行了优化。通过 UET 分层模型和相关库，应用程序可以选择最适合其需求的传输协议功能。PDS 子层定义了一种具有多种操作模式的协议，可提供可靠与不可靠、有序与无序数据包交付服务的所有组合。

拥塞管理子层（CMS）：端到端的拥塞管理对于实现高网络效率、减少数据包丢失、最小化延迟同时在竞争流之间保持公平性至关重要。网络中使用流量类别来分离具有不同特征和网络需求的流量流。为了保持公平性并确保低延迟控制环路，UE 拥塞管理设计为用于同一流量类别中的所有流量。流量类别的配置由网络运营商负责。通过允许 UET 拥塞管理在 fabric 中启用多路径数据包分发，并在收到拥塞信号时避免热点，可实现高网络效率并减少延迟。在 UET 下，具有无序流的 PDC 可以同时使用所有到目的地的路径，从而更均衡地利用所有网络路径。通过在终端和交换机之间根据实时拥塞管理协调选择路径，避免了链路负载不平衡。这种细粒度的负载均衡提高了网络利用率并减少了尾部延迟。

传输安全子层（TSS）：人工智能训练和推理通常在需要作业（job）隔离的托管网络中进行。此外，人工智能模型越来越敏感，已成为有价值的商业资产。鉴于此，UE 传输在设计中融入了网络安全性，能够对人工智能训练或推理作业中计算终端之间发送的所有网络流量进行加密和认证。随着作业规模的扩大，需要在不增加主机和网络接口中会话状态的情况下支持加密。为此，UET 采用了新的密钥管理机制，允许参与作业的大量计算节点之间高效地共享密钥。其设计旨在高效地实现在人工智能训练和推理所需的高速率和大规模场景下的应用。在大型以太网网络上运行的高性能计算作业也具有类似的特征，需要相应的安全机制。请注意，TSS 是一项可选功能。

1.6.3. 网络层

可选的 UE 网络层功能规范在第 4 节中给出。UE 不需要对网络层做任何更改，但 UET 拥塞管理要求支持 IETF RFC 3168 中规定的显式拥塞通知（ECN），不过有一个附加约束：在出队传输时标记拥塞数据包，而不是在入队时。

数据包修整：fabric 内部的拥塞是不可避免的。随着 fabric 速度的提高以及对有限交换机芯片缓冲的压力增大，拥塞信号会变得更加普遍，这些信号中包含的信息在确定纠正措施时也变得更加重要。UE 定义了一种数据包修整功能，允许交换机截断有争议的数据包，修改截断数据包的 DSCP 字段，并将截断的数据包作为拥塞信号转发到目的地。与仅使用 ECN 位相比，数据包修整提供的拥塞信息要多得多。数据包修整对于交换机而言是可选实现的功能，但对于 FEP 而言，接收已修整的数据包是必需的。

1.6.4. 链路层

可选的 UE 链路层规范在第 5 节中给出。UE 规范为链路层增加了几项可选功能，因为认识到推出支持这些功能的产品可能需要更长时间。一些工作负载可能会从这些功能中受益，而大规模的实验可能是证明这一点的最佳方式。此外，其他标准开发组织（SDO），如 IEEE 802，可能有兴趣对其中一些功能进行修改。

图 1-17 展示了相对于 IEEE 802 链路层架构，UE 链路层规范的重点关注领域。UE 对链路层的可选建议涉及阴影部分。所有功能对于 UE 合规性而言都是可选的。

Figure 1-17 - UE Link Layer Specification Focus Areas

链路层重试（LLR）：随着速度和规模的提高，以及加速器网络中常见的极高带宽密度，仅依靠端到端重试来解决数据包丢失的传统方法对延迟敏感型工作负载来说越来越繁重。在横向扩展的高性能计算网络（如百亿亿级系统中使用的网络）中，链路层的本地错误处理已被证明是很有价值的。UE 规范为以太网提供了这种能力。

基于信用的流控制（CBFC）：传统上，以太网网络不使用基于信用的链路，而这在 fabric 技术中很常见。然而，一些最近推出的产品支持这种链路，并为某些工作负载提供了可选的改进。CBFC 是 UE 链路层的一项可选功能。

UE 链路协商：UE 规范支持 “现有的以太网交换机”，但引入了多项可选的新功能，这些功能得益于发现和功能协商能力。虽然 UE 的一个目标是在专用的后端网络上运行，以实现加速器之间的通信，但这一目标并不能减少对网络上所有实体（终端和交换机）之间支持发现和功能协商的需求。UE 提出了 “方案（profile）” 的概念，用于描述必需功能和可选功能。要与方案支持的功能实现互操作，必须在所有网络实体之间进行检测、发现并达成共识。UE 假定行业中普遍存在像 LLDP 这样的标准协商机制，并且这些机制可扩展以满足上述目的。

1.6.5. 物理层

UE 物理层规范在第 6 节中给出。UE 针对物理层的规定采用了 IEEE Std 802.3 中定义的每通道（lane） 100G 信号传输。

图 1-18 展示了相对于 IEEE 802.3 物理层架构，UE 物理层规范的重点关注领域。UEC 对物理层的可选建议涉及阴影部分。

Figure 1-18 - UE Physical Layer Specification Focus Areas

IEEE 802.3 每通道 100G 信号传输：UE 物理层部分列出了属于 UE 范围内的 IEEE 802.3 规范。

通道质量假设：加速器节点比标准终端或顶层接入交换机（TOR）更为复杂。在本规范发布时，假设 IEEE 标准已足够适用，同时鼓励 UE 产品构建更稳健的通道。

用于链路质量预测的前向纠错（FEC）统计：假设 UE 网络由多个受前向纠错（FEC）保护的高性能链路组成，在这些链路上，由物理层错误导致的数据丢失极为罕见。然而，在大规模网络中，可能会有少数异常链路，其错误发生频率高于网络中的其他链路。对于大规模并行应用而言，此类链路可能需要频繁重传，从而成为整个网络的性能瓶颈。UE 物理层规范包含一种通过 FEC 解码器的统计数据来估算每条链路上物理层错误平均间隔时间（MTBPE）的方法。这种估算能够识别出性能不佳的链路，从而为提升网络性能提供机会（例如，将性能最差的链路从网络中移除，或对其终端进行维护）。