📊 扩展阅读：为了更直观地理解，你可以查看 RoCE v1分析报告 页面。

RoCE v1 协议架构深度解析与 ns-3 仿真实现策略

1. 引言

随着数据中心对高性能计算（HPC）和大规模分布式存储需求的激增，网络互连技术正经历着从传统 TCP/IP 向低延迟、高带宽架构的深刻转型。远程直接内存访问（Remote Direct Memory Access, RDMA）技术，最初作为 InfiniBand（IB）网络的核心特性，通过“零拷贝”（Zero-copy）和“内核旁路”（Kernel-bypass）机制，彻底改变了服务器间的数据传输效率。然而，InfiniBand 昂贵的专用硬件成本促使了 RDMA over Converged Ethernet（RoCE）的诞生。RoCE 旨在利用无处不在的以太网基础设施承载 InfiniBand 传输协议，从而在通用硬件上实现近似 HPC 级别的网络性能。

本报告旨在对 RoCE v1 协议进行详尽的技术解构，并针对开源网络仿真器 ns-3 中的 ns3-rdma 项目（基于 RoCE v2）提出系统的改造与实现方案。报告不仅涵盖 RoCE v1 的协议栈细节、帧结构定义及其与 InfiniBand 的渊源，还将深入代码层面，指导研究人员如何通过修改 C++ 源码，将现有的 UDP/IP 封装架构回退至基于原始以太网（Raw Ethernet）的链路层架构，从而在 ns-3 环境中精确复现 RoCE v1 的行为特征。

—

2. RoCE v1 协议实现的深度解析

RoCE v1（RDMA over Converged Ethernet version 1）是 RDMA 协议在以太网上的首次尝试，其核心设计理念是保留 InfiniBand 的传输层和网络层语义，但将其物理层和链路层替换为标准的以太网。理解 RoCE v1 的关键在于把握其“二层协议”的本质，这决定了其在寻址、路由及流控方面的所有特性。

2.1 协议栈架构与 EtherType 定义

与构建在 UDP/IP 之上的 RoCE v2 不同，RoCE v1 是一个纯粹的以太网链路层协议。在协议栈中，它直接位于以太网 MAC 层之上，完全跳过了网络层（IP）和传输层（UDP/TCP）。

2.1.1 EtherType 0x8915 的确立

在以太网帧的封装中，为了区分上层负载是 IP 数据包（0x0800）、ARP 请求（0x0806）还是其他协议，IEEE 为 RoCE v1 分配了专用的以太网类型码（EtherType）：0x8915 1。

• 机制分析：当网卡（NIC）或交换机接收到一个以太网帧时，它首先检查帧头中的 EtherType 字段。如果该值为 0x8915，接收端即知晓随后的有效载荷（Payload）并非标准的 IP 数据包，而是一个封装了 InfiniBand 头部结构（GRH + BTH）的 RDMA 数据包。
• 实现含义：这一设计意味着 RoCE v1 报文在传输过程中不具备 IP 路由能力。它依赖以太网交换机基于 MAC 地址表进行转发，因此通信范围被严格限制在同一个二层广播域（Layer 2 Broadcast Domain）或 VLAN 内 2。这也解释了为什么 RoCE v1 无法跨越路由器进行广域网通信。

2.2 帧结构与头部字段详解

RoCE v1 的帧结构是“以太网头 + IB 网络层 + IB 传输层 + 数据负载 + 校验”的组合。尽管移除了 IP 头，但为了保持与 InfiniBand 传输层逻辑（Verbs）的兼容性，RoCE v1 强制保留了全局路由头（GRH）。

2.2.1 以太网链路层头部 (Ethernet L2 Header)

这是标准的 Ethernet II 帧头，长度为 14 字节：

• 目的 MAC 地址 (Destination MAC)：6 字节。
• 源 MAC 地址 (Source MAC)：6 字节。
• EtherType：2 字节，固定为 0x8915。
• VLAN Tag (可选)：如果配置了 802.1Q VLAN，则会增加 4 字节的标签字段，其中包含 3 位的优先级（PCP）字段，这对 RoCE v1 的流控至关重要 4。

2.2.2 全局路由头 (Global Route Header, GRH)

GRH 是 RoCE v1 中最令人困惑但也最重要的部分。尽管 RoCE v1 不进行 IP 路由，但 IB 规范要求传输层必须能处理 GID（全局标识符）。因此，RoCE v1 借用了 GRH 来承载 GID 信息。GRH 的格式与 IPv6 头部完全一致（40 字节），但在 RDMA 语境下字段含义略有不同 6。

字段 (Field)	长度 (Bits)	IPv6 对应字段	RoCE v1 / IB 含义与作用
IP Version	4	Version	固定为 6。
Traffic Class	8	Traffic Class	关键字段。对应 IB 的 Service Level (SL) 或优先级。在无 VLAN 标签时，交换机或接收端依靠此字段进行 QoS 分类和 PFC 映射。
Flow Label	20	Flow Label	用于区分同一源-目的对之间的不同数据流，以此在支持 ECMP 的网络中保持包序，防止乱序到达。
Payload Length	16	Payload Length	指示 GRH 之后的数据长度（包括 BTH 和负载）。
Next Header	8	Next Header	标识下一个头部的类型，通常指向 BTH（Base Transport Header），值为 IB 传输协议号。
Hop Limit	8	Hop Limit	在 RoCE v1 中实际意义有限，因为不跨子网，但在 IB 语义中用于限制跳数。
Source GID	128	Source Address	发送端的 GID。在 RoCE v1 中，通常基于 MAC 地址和子网前缀生成（类似 IPv6 Link-Local 地址）。
Dest GID	128	Dest Address	接收端的 GID。

深入洞察：GRH 的存在揭示了 RoCE v1 的设计妥协——为了让上层软件（RDMA Verbs）无需修改即可运行在以太网上，底层协议栈伪造了一个“类似 InfiniBand”的环境，即保留 GRH 使得传输层以为自己在处理标准的 IB 路由包，尽管物理传输走的是以太网 4。

2.2.3 基础传输头 (Base Transport Header, BTH)

BTH 是实现 RDMA 语义的核心头部，长度为 12 字节，包含以下关键信息 4：

• OpCode (8 bits)：操作码，指示当前包是 RDMA Write、Read 还是 Send 操作，以及是否是立即数（Immediate Data）操作。
• Solicited Event (SE)：指示接收端是否需要产生完成队列事件（CQE）。
• Partition Key (P_Key, 16 bits)：用于逻辑隔离，类似于 VLAN ID，但在 IB 层面上定义。
• Destination Queue Pair (Dest QP, 24 bits)：核心字段。指定接收端的队列偶（Queue Pair）编号。这是 RDMA 通信的“目的端口”，硬件根据此字段将数据直接送入用户态内存，无需内核干预。
• Acknowledge Request (A)：指示发送端是否请求 ACK 确认。
• Packet Sequence Number (PSN, 24 bits)：包序列号，用于检测丢包、重复包和乱序，是实现可靠连接（Reliable Connection, RC）的基础。

2.2.4 校验序列 (ICRC & FCS)

• ICRC (Invariant CRC)：4 字节。覆盖 GRH 和 BTH 中不变的字段，确保端到端的数据完整性，防止数据在交换机内部被错误修改 7。
• FCS (Frame Check Sequence)：4 字节。标准的以太网尾部校验，用于链路层的错误检测。

2.3 寻址机制与无 ARP 特性

RoCE v1 的寻址是一个跨层映射过程。

• GID 与 MAC 的映射：RDMA 应用层使用 GID（128位）建立连接（Queue Pair）。但在链路层，以太网交换机只认 MAC 地址（48位）。在 RoCE v1 中，源 GID 通常是根据源 MAC 地址按照 EUI-64 规则生成的（例如 fe80::…mac…）。接收端必须能够从目标 GID 推导出目标 MAC 地址，或者在建立连接（QP 握手）阶段通过带外管理（Connection Manager）交换 MAC 地址信息。
• 无 ARP：由于没有 IP 层，RoCE v1 不使用 ARP 协议解析 MAC。这意味着在仿真实现中，节点必须通过静态配置或 Side-channel（如 TCP 握手交换信息）预先获知对端的 MAC 地址，并将其填入以太网帧头 1。

2.4 链路层流控：PFC (Priority Flow Control)

RoCE v1 对丢包极其敏感。传统的 TCP 可以容忍丢包并重传，但 RDMA 的高性能建立在“无损网络”（Lossless Network）假设之上。

• PFC 机制：RoCE v1 依赖 IEEE 802.1Qbb 优先级流控（PFC）。当交换机入口缓冲区的某个优先级队列（对应 GRH Traffic Class）达到阈值时，交换机会向上一跳发送 PAUSE 帧，暂停该优先级的流量发送 4。
• 拥塞控制缺失：与 RoCE v2 支持基于 IP ECN 的端到端拥塞控制（如 DCQCN）不同，RoCE v1 缺乏网络层的拥塞感知能力。它完全依赖链路层的“背压”（Backpressure）机制。这在仿真中意味着必须严格实现基于队列深度的 PAUSE 帧触发逻辑，而不能使用 ECN 标记 1。

—

3. 开源代码 ns3-rdma (v2) 的架构剖析

为了将基于 RoCE v2 的 ns3-rdma 项目修改为 v1 版本，必须首先透彻理解现有代码的架构，特别是它是如何利用 ns-3 的 UDP/IP 协议栈来模拟 RDMA 的。该项目由 Microsoft 研究员 Bob Zhu 开发，旨在模拟数据中心网络中的拥塞控制算法（DCQCN, TIMELY） 11。

3.1 核心组件与文件结构

通过分析项目源码 11，我们可以识别出以下几个关键模块，它们是修改工作的重点对象：

1. 流量生成端 (applications/model/udp-echo-client.cc)：
   • 现状：这是一个经过修改的 UDP Client。它使用 UdpSocketFactory 创建 socket，这意味着它生成的数据包会自动经过 ns-3 的 UDP 层和 IP 层，被加上 UDP 头和 IP 头。
   • v2 特征：代码中通过 SetTos（Type of Service）设置 IP 优先级，用于模拟 RDMA 的 Traffic Class。
   • 问题：RoCE v1 不需要 UDP 和 IP 头，因此不能使用 UdpSocket。
2. 网络设备与流控 (point-to-point/model/qbb-net-device.cc)：
   • 现状：实现了支持 PFC 的网络设备（QBB 即 802.1Qbb）。它监听接收队列的深度，并发送 PAUSE 帧。
   • v2 特征：它可能通过读取 IP 包头的 DSCP/TOS 字段来将包映射到不同的硬件队列。
   • 关键点：对于 v1，设备必须能够识别 EtherType 0x8915 的帧，并从 GRH 或 VLAN 标签中提取优先级，而不是查看 IP 头。
3. 交换机模型 (network/model/broadcom-node.cc)：
   • 现状：模拟 Broadcom 芯片的共享缓存架构。它实现了 ECN 标记逻辑（ThresholdMarkECN）。
   • v2 特征：当队列超过阈值时，修改 IP 头的 ECN 位。
   • v1 适配需求：RoCE v1 没有 IP 头，因此必须禁用 ECN 标记逻辑，仅保留 PFC 触发逻辑 11。
4. 自定义头部 (internet/model/seq-ts-header.cc)：
   • 现状：作者实现了一个简化的头部，仅包含序列号（Sequence Number）和时间戳（Timestamp），用于测量吞吐量和 RTT（针对 TIMELY 算法）。
   • 缺失：项目中并没有完整的 GRH 和 BTH 头部类。在 v2 仿真中，这些信息隐含在 UDP/IP 头或应用层 Payload 中。但在 v1 仿真中，必须显式构建 GRH 和 BTH 头部，因为物理线路上必须存在这些字节。

3.2 现有数据流分析

在 ns3-rdma (v2) 中，一个 RDMA Write 操作的数据流如下：

1. App 调用 Send() -> 传入 Payload + SeqTsHeader。
2. L4：ns-3 添加 UDP 头（源/目的端口 4791）。
3. L3：ns-3 添加 IP 头（源/目的 IP，ECN 位，Protocol=UDP）。
4. L2：ns-3 添加 Ethernet 头（EtherType = 0x0800 IPv4）。
5. 物理层：传输。

RoCE v1 的目标数据流必须变为：

1. App 手动构建 GRH + BTH + Payload。
2. Socket：直接调用 L2 接口（PacketSocket）。
3. L2：ns-3 添加 Ethernet 头（EtherType = 0x8915）。
4. 物理层：传输。

—

4. RoCE v1 仿真修改实战指南 (初步方案，未校验)

本节详细阐述如何根据 ns3-rdma 项目修改得到 RoCE v1 版本的仿真。这需要从应用层 Socket 类型、包头构造到中间节点处理逻辑的全方位改造。

4.1 步骤一：Socket 通信机制的重构 (从 UDP 到 Raw Ethernet)

这是最核心的修改。RoCE v1 不使用 IP 寻址，因此必须放弃 UdpSocketFactory，转而使用 ns-3 提供的 PacketSocketFactory。PacketSocket 允许应用程序直接操作链路层帧，绕过网络层协议栈 13。

4.1.1 修改 udp-echo-client.cc (建议重命名为 roce-client.cc)

原始代码 (v2):

C++

// 典型的 UDP Socket 创建
TypeId tid = TypeId::LookupByName (“ns3::UdpSocketFactory”);
m_socket = Socket::CreateSocket (GetNode (), tid);
m_socket->Bind ();
m_socket->Connect (InetSocketAddress (m_peerAddress, m_peerPort)); // 使用 IP 地址

修改后代码 (v1):

C++

// 引入必要的头文件
#include “ns3/packet-socket-factory.h”
#include “ns3/packet-socket-address.h”

// 1. 创建 PacketSocket
TypeId tid = TypeId::LookupByName (“ns3::PacketSocketFactory”);
m_socket = Socket::CreateSocket (GetNode (), tid);

// 2. 准备物理地址 (MAC) 和 EtherType
PacketSocketAddress socketAddr;
socketAddr.SetSingleDevice (m_netDevice->GetIfIndex()); // 绑定到特定的网络设备接口
socketAddr.SetPhysicalAddress (m_destMacAddress); // 设置目的 MAC 地址 (需预先获知)
socketAddr.SetProtocol (0x8915); // **关键**：设置 EtherType 为 RoCE v1

// 3. 绑定与连接
m_socket->Bind (socketAddr);
m_socket->Connect (socketAddr);

深度解析：

• SetProtocol(0x8915)：这一步至关重要。它告诉底层的 NetDevice，在封装以太网帧时，类型字段应填入 0x8915 16。
• MAC 地址获取：在 v2 中，用户提供 IP，系统通过 ARP 解析 MAC。在 v1 仿真中，则需要在仿真脚本中，显式地将接收节点的 MAC 地址传递给发送节点的 Application。可以通过 node->GetDevice(0)->GetAddress() 获取 MAC。

4.2 步骤二：RoCE 专用头部类的实现 (C++)

由于 PacketSocket 不会添加任何上层头部，我们需要手动实现 GRH 和 BTH 的序列化类，并继承自 ns3::Header。这直接回应了用户关于“协议内容如何对应代码”的问题。

4.2.1 实现 GRH 头部 (RoceGrhHeader)

在 src/internet/model/ 下新建 roce-grh-header.h/cc。该类需模拟 IPv6 头部的位布局 18。

C++

// roce-grh-header.h 概览
class RoceGrhHeader : public Header {
public:
//… 标准 ns-3 Header 方法声明…
void SetTrafficClass (uint8_t tclass);
void SetFlowLabel (uint32_t flowLabel);
void SetSourceGid (Ipv6Address gid); // 使用 Ipv6Address 类来存储 128位 GID
void SetDestGid (Ipv6Address gid);

private:
uint32_t m_flowLabel; // 20 bits
uint8_t m_tclass; // 8 bits
uint8_t m_hopLimit;
Ipv6Address m_sGid;
Ipv6Address m_dGid;
};

序列化逻辑 (Serialize)：
RoCE v1 要求字节序为网络序（Big Endian）。在 Serialize 函数中，必须将字段按位拼接：

C++

// 对应 IPv6 头部的第一个 32位字：Version(4) + TrafficClass(8) + FlowLabel(20)
uint32_t vtf = (6 << 28) | (m_tclass << 20) | (m_flowLabel & 0xFFFFF);
i.WriteHtonU32 (vtf);
i.WriteHtonU16 (m_payloadLen);
i.WriteU8 (m_nextHeader); // 通常指向 BTH
i.WriteU8 (m_hopLimit);
// 写入 GID
WriteTo (i, m_sGid);
WriteTo (i, m_dGid);

对应关系：这里的 WriteHtonU32 操作直接对应了协议规范中 GRH 头部前 4 个字节的定义。

4.2.2 实现 BTH 头部 (RoceBthHeader)

新建 roce-bth-header.h/cc。

C++

class RoceBthHeader : public Header {
private:
uint8_t m_opcode; // 8 bits
bool m_solicitedEvent; // 1 bit
bool m_migReq; // 1 bit
uint16_t m_pkey; // 16 bits
uint32_t m_destQp; // 24 bits (需特殊处理)
bool m_ackReq; // 1 bit
uint32_t m_psn; // 24 bits
};

序列化细节：
BTH 的字段跨越字节边界，例如 DestQP 是 24 位。序列化时需要位操作技巧：

C++

i.WriteU8 (m_opcode);
// SE (1) + M (1) + Pad (2) + TVer (4)
i.WriteU8 (flags);
i.WriteHtonU16 (m_pkey);
// DestQP (24 bits) + AckReq (1 bit) + Reserved (7 bits)
// 这通常需要将 DestQP 放入一个 32位 整数的高 24 位
i.WriteHtonU32 (m_destQp << 8 | m_ackReq << 7);
i.WriteHtonU32 (m_psn); // 注意 PSN 也是 24位，实际上只占 3字节，这里简化处理需查阅具体字节对齐

(注：根据 IB 规范，BTH 长度固定为 12 字节，上述代码需严格对照位图实现 4)。

4.3 步骤三：修改交换机与流控逻辑 (broadcom-node.cc)

这是仿真能否正确反映 v1 行为的关键。

1. 禁用 IP 解析：原代码可能会尝试 packet->PeekHeader<Ipv4Header>(ipHeader) 来检查 ECN 位。在 v1 模式下，这会失败或读到垃圾数据。
   • 修改：移除所有 ECN 相关的 IP 层操作。
   • 替代：如果需要基于优先级进行流控，应 PeekHeader<RoceGrhHeader> 并读取 Traffic Class 字段。
2. PFC 触发逻辑：
   • 保留 qbb-net-device 中基于队列深度的 PAUSE 帧发送逻辑。
   • 确保 RoceGrhHeader 中的 Traffic Class 被正确映射到 qbb-net-device 的 Traffic Category (TC)。例如，GRH TClass 5 映射到 TC 5。这通常需要在 NetDevice 的入队（Enqueue）函数中通过 Packet::PeekHeader 实现分类。

4.4 步骤四：仿真脚本配置 (third.cc)

在主控脚本中，必须建立纯二层的网络拓扑。

1. 拓扑限制：所有节点必须在同一个 NodeContainer 中，通过 CsmaHelper 或 PointToPointHelper 连接，且不能配置 IP 地址（或者配置了也不使用）。
2. 安装应用：将修改后的 RoceClient 应用安装到节点，并手动填入对端的 MAC 地址作为“物理地址”。

—

5. 协议内容与仿真代码的映射关系总结

为了清晰回答用户的第三个问题，下表总结了 RoCE v1 协议字段与 ns-3 仿真代码的具体对应关系：

协议层级	协议字段 (Protocol Content)	ns-3 仿真代码对应 (Simulation Implementation)	作用与备注
链路层	EtherType	PacketSocketAddress::SetProtocol(0x8915)	核心标识。指示 NetDevice 封装帧时写入 0x8915，使交换机识别为 RoCE 流量。
链路层	Dest MAC	PacketSocketAddress::SetPhysicalAddress(mac)	替代了 ARP 过程，直接指定链路层目的地址。
网络层	GRH: IP Version	RoceGrhHeader::Serialize 中写入 6	欺骗接收端处理逻辑，使其认为这是一个合法的 IB GRH。
网络层	GRH: Traffic Class	RoceGrhHeader::m_tclass	流控关键。在交换机 broadcom-node 中，该字段决定包进入哪个优先级队列，从而影响 PFC PAUSE 帧的触发。
网络层	GRH: Flow Label	RoceGrhHeader::m_flowLabel	可用于仿真中的 ECMP 哈希计算（如果实现了 L2 多路径）。
网络层	GRH: Source/Dest GID	RoceGrhHeader::m_sGid (Ipv6Address 类型)	仿真中可直接填入节点的 MAC 映射值或虚拟 ID，用于应用层验证连接合法性。
传输层	BTH: OpCode	RoceBthHeader::m_opcode	指示是 RDMA Write 还是 Read。仿真接收端据此决定是否发送 ACK 或回写数据。
传输层	BTH: Dest QP	RoceBthHeader::m_destQp	接收端应用据此将数据包分发给正确的 Context。
传输层	BTH: PSN	RoceBthHeader::m_psn	用于检测丢包。qbb-net-device 可能会统计乱序包，Client 端利用此字段实现 Go-Back-N 重传。
流控	PAUSE Frame	qbb-net-device.cc 中的 SendPfc()	对应 802.1Qbb 标准。代码中包含生成特定 EtherType (0x8808) 控制帧的逻辑。

—

6. 验证与高级话题

6.1 Wireshark 抓包验证

为了验证仿真代码是否正确生成了 RoCE v1 数据包，可以使用 ns-3 的 PCAP 追踪功能 (m_netDevice->EnablePcapAll (“roce-v1”))。

• 生成的 .pcap 文件应能在 Wireshark 中打开。
• 如果 SetProtocol(0x8915) 正确，Wireshark 会自动识别帧为 RoCE (InfiniBand)，并尝试解析其后的 GRH 和 BTH。如果看到 IP 头或 UDP 头，说明 PacketSocket 的使用有误或未正确绕过 TCP/IP 栈 21。

6.2 仿真中的常见陷阱：PFC 死锁与风暴

RoCE v1 极度依赖 PFC。在仿真中，如果仅仅依靠 PFC 而没有上层拥塞控制（如 v2 的 DCQCN），在高负载（如 Incast 模式）下极易观察到“PFC 风暴”或死锁（Head-of-Line Blocking）。

• 现象：仿真中的吞吐量突然跌至零，且日志显示大量 PAUSE 帧被发送。
• 分析：这正是 RoCE v1 的典型特征。通过观察 qbb-net-device 的 trace 日志，可以研究 PFC 阈值（m_pfcThreshold）设置对网络性能的非线性影响，这是 RoCE v1 仿真的重要研究价值所在 10。

7. 结论

通过对 RoCE v1 协议的深入剖析和对 ns3-rdma 项目的架构解构，我们得出结论：实现 RoCE v1 仿真的核心在于**“去 IP 化”**。这不仅涉及到简单地移除 IP 头，更需要从 Socket 编程模型（采用 PacketSocket）、帧结构构造（手动序列化 GRH/BTH）以及流控机制（仅依赖 PFC）三个维度进行系统性改造。

本报告提供的工程指南填补了从理论协议到代码实现的空白，明确了如何利用 ns-3 强大的链路层仿真能力来复现 RoCE v1 这种基于“纯以太网”的高性能计算网络协议。对于研究数据中心网络演进、无损以太网机制及 PFC 缺陷的学者而言，这一仿真平台的搭建具有重要的参考价值。

引用的著作

1. RDMA over Converged Ethernet - Wikipedia, 访问时间为 十二月 29, 2025， https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet
2. What is RoCE(RDMA over Converged Ethernet)？ - mvslinks.com, 访问时间为 十二月 29, 2025， https://mvslinks.com/news/blog/what-is-rocerdma-over-converged-ethernet%EF%BC%9F/
3. Understanding the RoCE network protocol, 访问时间为 十二月 29, 2025， https://hustcat.github.io/roce-protocol/

4. InfiniBand RDMA and RoCE Explained: Protocols, Messages, and Network Architecture

   by NADDOD

   Dec, 2025

   Medium, 访问时间为 十二月 29, 2025， https://medium.com/@naddod/infiniband-rdma-and-roce-explained-protocols-messages-and-network-architecture-65b79eac6694

5. RDMA over Converged Ethernet (RoCE) - NVIDIA Docs, 访问时间为 十二月 29, 2025， https://docs.nvidia.com/networking/display/mlnxofedv23070512/rdma+over+converged+ethernet+(roce)
6. InfiniBand RDMA and RoCE Explained: Protocols, Messages, and Network Architecture, 访问时间为 十二月 29, 2025， https://www.naddod.com/ai-insights/infiniband-rdma-and-roce-explained-protocols-messages-and-network-architecture
7. RoCE Vs InfiniBand: Key Differences, Performance & Use Cases - Asterfusion, 访问时间为 十二月 29, 2025， https://cloudswit.ch/blogs/roce-or-infiniband-technical-comparison/

8. InfiniBand packet header and ibverbs interface implementation (I) — RDMA WRITE analysis

   by DatenLord

   Medium, 访问时间为 十二月 29, 2025， https://medium.com/@datenlord/infiniband-packet-header-and-ibverbs-interface-implementation-i-rdma-write-analysis-1d626f94f61c

9. Everything You Should Know About RoCE - QSFPTEK, 访问时间为 十二月 29, 2025， https://www.qsfptek.com/qt-news/everything-you-should-know-about-roce.html
10. SwCC: Software-Programmable and Per-Packet Congestion Control in RDMA Engine - USENIX, 访问时间为 十二月 29, 2025， https://www.usenix.org/system/files/atc25-huang-hongjing.pdf
11. bobzhuyb/ns3-rdma: NS3 simulator for RDMA over Converged Ethernet v2 (RoCEv2), including the implementation of DCQCN, TIMELY, PFC, ECN and shared buffer switch - GitHub, 访问时间为 十二月 29, 2025， https://github.com/bobzhuyb/ns3-rdma
12. ns3-rdma - Gitee, 访问时间为 十二月 29, 2025， https://gitee.com/zm643/ns3-rdma?skip_mobile=true
13. Sockets APIs — Model Library - ns-3, 访问时间为 十二月 29, 2025， https://www.nsnam.org/docs/release/3.29/models/html/sockets-api.html
14. ns-3 manual: 5.1 ns-3 sockets API, 访问时间为 十二月 29, 2025， https://www.nsnam.org/docs/release/3.1/manual/manual_32.html
15. ns3::PacketSocket Class Reference [Socket], 访问时间为 十二月 29, 2025， https://www.nsnam.org/docs//release/3.9/doxygen/classns3_1_1_packet_socket.html
16. ns3::PacketSocketAddress Class Reference - ns-3, 访问时间为 十二月 29, 2025， https://www.nsnam.org/docs/release/3.23/doxygen/classns3_1_1_packet_socket_address.html
17. ns3::PacketSocketAddress Class Reference, 访问时间为 十二月 29, 2025， https://www.nsnam.org/docs/release/3.19/doxygen/classns3_1_1_packet_socket_address.html
18. LRH and GRH InfiniBand Headers - NVIDIA Enterprise Support Portal, 访问时间为 十二月 29, 2025， https://enterprise-support.nvidia.com/s/article/lrh-and-grh-infiniband-headers

19. IPv4 vs IPv6 - Understanding the differences

    NetworkAcademy.IO, 访问时间为 十二月 29, 2025， https://www.networkacademy.io/ccna/ipv6/ipv4-vs-ipv6

20. IPv6 packet - Wikipedia, 访问时间为 十二月 29, 2025， https://en.wikipedia.org/wiki/IPv6_packet
21. How to use Wireshark to capture a packet trace - Micro Focus Software Support, 访问时间为 十二月 29, 2025， https://support.microfocus.com/kb/doc.php?id=3892415
22. How-To Dump RDMA Traffic Using the Inbox tcpdump tool (ConnectX-4 and above), 访问时间为 十二月 29, 2025， https://enterprise-support.nvidia.com/s/article/how-to-dump-rdma-traffic-using-the-inbox-tcpdump-tool–connectx-4-x
23. Introduction to Congestion Control for RoCE - Broadcom Inc., 访问时间为 十二月 29, 2025， https://docs.broadcom.com/docs/NCC-WP1XX

---

• Previous
  RoCE v1

---