RDMA - IB规范卷1 - 传输层3_不可靠服务

术语

• LNH: Link Next Header

9.8 不可靠服务

IBA 定义了两种不可靠服务：不可靠连接UC（SEND、RDMA WRITE）和不可靠数据报UD（仅限 SEND）。这些服务具有以下特点：

1. 请求方未收到消息接收确认
2. 不保证数据包的顺序
3. 响应方正常验证传入数据包（验证相应的报头字段、CRC 校验）。损坏的数据包可能会被悄悄丢弃，从而导致消息被丢弃。
4. 当检测到传入数据包中的错误（例如数据包丢失/乱序）时，响应方不会停止，而是继续接收传入数据包。
5. 一旦响应方收到按正确顺序排列的完整消息，所有数据都已提交到本地故障区，并且所有适当的有效性校验（包括变量 CRC 校验和不变 CRC 校验）均已完成，则认为操作已完成。对于不可靠连接服务，已完成消息的定义在第 425 页的 9.8.2.2.7 节中给出。
6. 一旦“最后一个”或“唯一一个”数据包提交到结构，请求方即认为消息操作完成。

9.8.1 验证和执行请求

本节适用于不可靠连接服务和不可靠数据报服务。如果服务之间存在差异，则会注明差异。这两种服务之间的主要区别在于，不可靠数据报服务仅限于单数据包消息，而不可靠连接服务则没有此限制。此外，不可靠数据报服务仅限于使用发送功能，这进一步简化了请求验证过程。以下描述了对响应方验证入站请求数据包的要求。C9-165：响应方应验证报头的各个字段，以验证数据包的完整性。此验证过程在第 301 页上的第 9.6 节“数据包传输头验证”中指定。包含无效字段的数据包应由响应方静默丢弃。C9-166：对于使用不可靠连接服务的 HCA，应检查 PSN 以检测无序数据包。通过检查 PSN，响应方可以确定数据包是新请求还是无效数据包。有关此检查的描述，请参阅第 418 页上的第 9.8.2.2.1 节“响应方 - 验证 PSN”。o9-115：如果 TCA 实施不可靠连接服务，则应检查 PSN 以检测无序数据包。通过检查 PSN，响应方可以确定数据包是新请求还是无效数据包。有关此检查的描述，请参阅第 418 页上的第 9.8.2.2.1 节“响应方 - 验证 PSN”。 C9-167：对于使用不可靠连接服务的 HCA，响应方应检查数据包 OpCode 以确定数据包 OpCode 序列是否有效。此检查不适用于不可靠数据报，因为该服务仅限于单数据包消息，因此操作码序列的概念不适用。o9-116：如果 TCA 实现不可靠连接服务，响应方应检查数据包 OpCode 以确定数据包 OpCode 序列是否有效。此检查不适用于不可靠数据报，因为该服务仅限于单数据包消息，因此操作码序列的概念不适用。C9-168：响应方应检查数据包 OpCode 以确定此接收队列是否支持请求的操作。C9-169：响应方应验证其是否具有足够的可用资源来接收消息。必要的资源包括有效的接收 WQE（用于 SEND 或带有立即数据的 RDMA 写操作），以及对于 SEND 请求，足够的缓冲区空间来接收请求。C9-170：对于使用不可靠连接服务的 HCA 响应者，如果请求是 RDMA WRITE 操作，响应者应检查 R_Key。如果发现数据包有效、有序且有足够的资源可用，则响应者将执行该数据包。在执行过程中，响应者可能会遇到本地错误。o9-117：如果 TCA 响应者实现了不可靠连接服务，并且支持 RDMA 操作，则它的行为如下。如果入站请求是 RDMA WRITE 操作，则响应者应检查 R_Key。如果发现数据包有效、有序且有足够的资源可用，则响应者将执行该数据包。在执行过程中，响应者可能会遇到本地错误。 C9-171：对于使用不可靠连接或不可靠数据报服务的HCA响应器，或使用不可靠数据报服务的TCA响应器，响应器在验证入站请求数据包时应遵循图117所示的顺序。o9-118：如果TCA响应器实现不可靠连接服务，则响应器在验证入站请求数据包时应遵循图117所示的顺序。对于不可靠连接服务，响应器应遵循图117所示的顺序, 这些要求在第 418 页的 9.8.2.2 响应者行为中进行了详细讨论。不可靠数据报服务的数据包验证在第 428 页的 9.8.3.2 响应者行为中进行了讨论。

9.8.2 不可靠连接

不可靠连接由两个 QP 之间的一对一对应关系组成。数据包从一个 QP 发送到另一个 QP，但目标 QP 不会生成任何确认。其主要特点是没有向请求方提供交付保证。然而，响应方可以检测到数据损坏和乱序数据包。表 54 总结了不可靠连接服务的特征。

9.8.2.1 请求方行为

本节规定了请求方在生成不可靠连接服务请求数据包时所需的行为。

9.8.2.1.1 请求方 - 生成 PSN

C9-172：对于使用不可靠连接服务的 HCA 请求方，请求方必须在每个请求数据包的 BTH:PSN 字段中放置一个称为当前 PSN 的值。o9-119：如果 TCA 请求方实现了不可靠连接服务，则请求方必须在每个请求数据包的 BTH:PSN 字段中放置一个称为当前 PSN 的值。在连接建立期间，传输层的客户端必须将下一个 PSN 编程为 0 到 16,777,215 之间的任意值。 C9-173：对于使用不可靠连接服务的 HCA 请求者，传输层客户端编程的初始 PSN 应作为 BTH:PSN 显示于请求者生成的第一个请求数据包中 o9-120：如果 TCA 实现不可靠连接服务，则传输层客户端编程的初始 PSN 应作为 BTH:PSN 显示于请求者生成的第一个请求数据包中。C9-174：对于使用不可靠连接服务的 HCA，传输层应仅在发送队列处于适合传输请求数据包的状态时修改（更新）PSN。例如，对于 HCA，当队列对处于 INITIALIZED 状态时，传输层不会更新下一个 PSN。o9-121：如果 TCA 实现不可靠连接服务，则传输层应仅在发送队列处于适合传输请求数据包的状态时修改（更新）PSN。 C9-175：对于使用不可靠连接服务的 HCA，请求者生成的每个请求数据包必须具有一个 PSN 值，该值是前一个请求数据包的 PSN 值的“1”增量（模 2的24次幂）。o9-122：如果 TCA 实现不可靠连接服务，则请求者生成的每个请求数据包必须具有一个 PSN 值，该值是前一个请求数据包的 PSN 值的“1”增量（模 2的24次幂）

9.8.2.1.2 请求者 - 生成操作码

请求者生成的操作码必须符合如下所示的操作码表

C9-176：对于使用不可靠连接服务的 HCA 请求者，请求者必须生成符合有效 OpCode 序列表（如第 417 页表 56 有效 OpCode 序列表所示）的数据包操作码。生成请求数据包时，BTH:Opcode 应符合第 261 页表 38 OpCode 字段中的规定。o9-123：如果 TCA 请求者实现不可靠连接服务，请求者必须生成符合有效 OpCode 序列表（如第 417 页表 56 有效 OpCode 序列表所示）的数据包操作码。生成请求数据包时，BTH:Opcode 应符合第 261 页表 38 OpCode 字段中的规定。

9.8.2.1.3 请求者 - 生成有效载荷

请求者应根据操作码生成有效载荷长度，如下所示：C9-177：对于对于使用不可靠连接服务的 HCA，如果 OpCode 指定“第一个”或“中间”数据包，则数据包有效载荷长度必须为完整的 PMTU 大小。C9-178：对于使用不可靠连接服务的 HCA，如果 OpCode 指定“唯一”数据包，则数据包有效载荷长度必须介于 0 到 PMTU 字节之间。因此，创建零字节长度传输的唯一方法是使用单数据包消息。C9-179：对于使用不可靠连接服务的 HCA，如果 OpCode 指定“最后一个”数据包，则数据包有效载荷长度必须介于 1 到 PMTU 字节之间。o9-124：如果 TCA 实现不可靠连接服务，则它应符合 HCA 对 OpCode 的上述三个要求。

9.8.2.1.4 完成消息发送或 RDMA 写入

C9-180：对于使用不可靠连接服务的 HCA 请求者，当出现以下任一情况时，请求者应认为消息发送（或 RDMA 写入）已完成：请求者已将最后一个数据包的 VCRC 字段的最后一个字节提交到线路（并且未检测到与消息传输相关的本地错误），或者请求者检测到与消息传输相关的本地错误，导致请求者终止发送请求。o9-125：如果 TCA 请求者实现不可靠连接服务，当出现以下任一情况时，请求者应认为消息发送（或 RDMA 写入）已完成：请求者已将最后一个数据包的 VCRC 字段的最后一个字节提交到线路（并且未检测到与消息传输相关的本地错误），或者请求者检测到与消息传输相关的本地错误，导致请求者终止发送请求。请注意，请求方完成发送 WQE 时，响应方的内存状态未知。同样，如果请求方在发送请求数据包时检测到本地错误，则响应方的内存状态也未知。

9.8.2.2 响应方行为

本节规定了响应方在接收入站请求时所需的行为。

9.8.2.2.1 响应方 - 验证 PSN

响应方维护一个预期 PSN 值 (ePSN)，该值用于检测多数据包请求消息中的数据包丢失以及消息丢失。由于每个入站请求数据包的 PSN 都是连续的，并且对于 UC 服务单调递增，因此 PSN 序列的中断表示请求数据包丢失或丢失。C9-181：对于使用不可靠连接服务的 HCA 响应方，响应方应维护一个预期 PSN 值 (ePSN)。这是响应方期望在下一个入站请求数据包的 BTH 中找到的 PSN。o9-126：如果 TCA 响应方实施不可靠连接服务，则响应方应维护预期 PSN 值 (ePSN)。这是响应方期望在下一个入站请求数据包的 BTH 中找到的 PSN。传输客户端可以在建立连接时将响应方的预期 PSN 初始化为 0 到 16,777,215 之间的任意值。但是，由于响应方将接受任何操作码为“first”或“only”的有效数据包，并使用此类数据包中包含的 PSN 的值作为其预期 PSN，因此不需要对响应方的初始预期 PSN 进行编程。有关在连接建立时加载预期 PSN 的机制的完整描述，请参阅第 12 章：通信管理（第 716 页）。仅当队列处于初始化状态时，客户端才能设置初始预期 PSN。客户端在任何其他状态下尝试设置 PSN 都可能被传输层忽略。C9-182：对于使用不可靠连接服务的 HCA，仅当接收队列处于适当状态以接收入站请求数据包时，传输层才应修改（更新）其预期 PSN。例如，对于 HCA，当队列对处于初始化状态时，传输层不会修改 PSN。o9-127：如果 TCA 实现不可靠连接服务，则传输层仅当接收队列处于正确状态以接收入站请求数据包。例如，对于 HCA，当队列对处于初始化状态时，传输层不会修改 PSN。C9-183：对于使用不可靠连接服务的 HCA 响应者，如果入站请求数据包的 PSN 与响应者当前的 ePSN 不完全匹配，则应声明该数据包无序。o9-128：如果 TCA 响应者实施不可靠连接服务，如果入站请求数据包的 PSN 与响应者当前的 ePSN 不完全匹配，则应声明该数据包无序。C9-184：使用不可靠连接服务的 HCA 响应者应执行以下操作。如果在数据包验证期间发现 OpCode 为“first”或“only”的入站请求数据包，则响应者应接受该数据包并接受该请求消息的 PSN 作为其新的 ePSN，无论入站数据包是否无序。无论 ePSN 的先前值如何，都应执行此操作。o9-129：实现不可靠连接服务的 TCA 响应器应按如下方式运行。如果在数据包验证期间发现传入请求数据包的 OpCode 为“first”或“only”，则响应器应接受该数据包，并接受该请求消息的 PSN 作为其新的 ePSN，无论传入数据包是否乱序。无论 ePSN 的先前值如何，都应执行此操作。C9-185：对于使用不可靠连接服务的 HCA 响应器，在执行传入请求之前，响应器应通过将传入 BTH 中的 PSN 与响应器的预期 PSN 进行比较来检查 PSN。响应器用于计算其下一个预期 PSN 的规则应与请求器在计算要插入其下一个请求数据包的 PSN 值时使用的规则相同。这些规则在第 415 页的 9.8.2.1.1 请求方 - 生成 PSN 中给出。o9-130：对于使用不可靠连接服务的 HCA 响应方，在执行入站请求之前，响应方应通过将入站 BTH 中的 PSN 与响应方的预期 PSN 进行比较来检查 PSN。响应方用于计算其下一个预期 PSN 的规则应与请求方计算要插入其下一个请求数据包的 PSN 值时使用的规则相同。这些规则在第 415 页的 9.8.2.1.1 请求方 - 生成 PSN 中给出。o9-131：如果入站消息的 PSN 与响应方的 ePSN 不匹配，则响应方可能会通知其客户端存在一条或多条丢失的消息。响应方通知其客户端的机制超出了本规范的范围。 C9-186：对于使用不可靠连接服务的 HCA 响应器，如果在检测到无序数据包时正在处理多数据包消息，则应静默丢弃当前消息。然后，响应器等待新消息的第一个数据包。当前数据包（无序数据包）可能是新消息的第一个数据包。如果是这样，则应将其视为新消息。o9-132：如果 TCA 响应器实现不可靠连接服务，如果在检测到无序数据包时正在处理多数据包消息，则应静默丢弃当前消息。然后，响应器等待新消息的第一个数据包。当前数据包（无序数据包）可能是新消息的第一个数据包。如果是这样，则应将其视为新消息。“新消息”由 BTH 中的 OpCode 为“first”或“only”的入站请求数据包表示。 “当前消息”是指自最近收到的“第一个”或“唯一”OpCode 以来收到的所有数据包，不包括当前数据包。

9.8.2.2.2 响应方 - 操作码序列检查

请求数据包必须符合有效 OpCode 序列的安排。OpCode 序列通过检查 BTH:OpCode 来确定。C9-187：对于使用不可靠连接服务的 HCA 响应方，响应方应按照以下 (1) 至 (5) 项所述检查数据包 OpCode 的序列：

1. 如果这是建立连接后的第一个数据包，则数据包 OpCode 必须指示“第一个”或“唯一”。OpCode 为“中间”或“最后一个”表示当前消息至少第一个数据包丢失，并表示 OpCode 序列无效。
2. 如果收到的最后一个有效数据包的 OpCode 指示“第一个”，则当前 OpCode 必须指示“中间”或“最后一个”。它还必须与最后一个有效数据包（SEND、RDMA WRITE）中指定的操作类型匹配。当前 OpCode 为“first”或“only”表示前一条消息的最后一个数据包至少丢失，并表示 OpCode 序列无效。
3. 如果收到的最后一个有效数据包的 OpCode 指示“middle”，则当前 OpCode 必须指示“middle”或“last”。它还必须与最后一个有效数据包（SEND 或 RDMA WRITE 请求）中指定的操作类型匹配。当前 OpCode 为“first”或“only” 意味着至少前一个消息的最后一个数据包丢失，并表示 OpCode 序列无效。
4. 如果收到的最后一个有效数据包的 OpCode 指示“last”，则当前 OpCode 必须指示“first”或“only”。当前 OpCode 为“middle”或“last”，则意味着至少当前消息的第一个数据包丢失，并表示 OpCode 序列无效。
5. 如果收到的最后一个有效数据包的 OpCode 指示“only”，则当前 OpCode 必须指示“first”或“only”。当前 OpCode 为“middle”或“last”，则意味着当前消息的第一个数据包丢失，并表示 OpCode 序列无效。

o9-133：如果 TCA 响应方实现了不可靠连接服务，则响应方应按照上述第 (1) 至 (5) 项中的说明检查数据包 OpCode 序列。在出现无效 OpCode 序列时响应方的行为在第 444 页上的第 9.9.3 节响应方行为中指定。C9-188：对于使用不可靠连接服务的 HCA 响应方，如果响应方检测到无效的 OpCode 序列，则应默默丢弃当前消息。然后，响应方等待 OpCode 为“first”或“only”的新入站请求数据包；任何其他入站请求数据包都应默默丢弃。o9-134：如果 TCA 响应方实现不可靠连接服务，并且如果响应方检测到无效的 OpCode 序列，则应默默丢弃当前消息。然后，响应方等待 OpCode 为“first”或“only”的新入站请求数据包；任何其他入站请求数据包都应默默丢弃。“当前消息”是指自最近收到“first”或“only” OpCode 以来收到的所有数据包，不包括当前数据包。 C9-189：对于使用不可靠连接服务的 HCA 响应器，如果导致无效 OpCode 序列的当前数据包的 OpCode 为“first”或“only”，则应将其视为新请求消息的第一个数据包。o9-135：如果 TCA 响应器实现不可靠连接服务，并且导致无效 OpCode 序列的当前数据包的 OpCode 为“first”或“only”，则应将其视为新请求消息的第一个数据包。有效 OpCode 序列列表总结如下表。

9.8.2.2.3 响应方操作码验证

C9-190：对于统一通信 (UC)，响应方应在执行请求之前验证接收队列是否支持所请求的功能（SEND 或 RDMA WRITE），以及 BTH:OpCode 是否未被保留。请注意，在 9.6 节“数据包传输头验证”（第 301 页）中，OpCode 也作为数据包验证的一部分进行了检查，以确保入站数据包包含对不可靠连接服务的请求。 C9-191：响应方应根据第 444 页上的 9.9.3 节“响应方行为”静默丢弃无效的 UC 请求。

9.8.2.2.4 响应方远程访问验证

C9-192：此合规性声明已作废，并由 C9-192.2.1 取代：C9-192.2.1：对于使用不可靠连接服务的 HCA 响应方，如果入站请求用于 RDMA WRITE，且 RETH 中请求的 DMA 长度非零，则应检查以下条件： • RETH 中的 R_Key 字段有效。 • 虚拟地址和长度在与 R_Key 关联的本地定义限制范围内。对于 RDMA WRITE 请求，长度检查基于每个数据包进行，并基于 LRH:PktLen 字段。 • 指定的访问类型（写入）在与 R_Key 关联的本地定义限制范围内。 • 对于 HCA，应根据第 10.2.3 节“保护域”中定义的条件检查保护域。 任何一项检查失败均构成 R_Key 违规。响应方对 R_Key 违规的响应行为在第 9.9.3 节“响应方行为”中指定。o9-136：如果 TCA 响应方实现了不可靠连接服务和 RDMA 功能，则它应符合前述 HCA 合规性声明。C9-193：对于使用不可靠连接服务的 HCA，即使请求包含立即数据，也不应检查 R_Key 字段是否存在零长度的 RDMA WRITE 请求。 o9-137：如果 TCA 响应器实现了不可靠连接服务和 RDMA 功能，则即使请求包含立即数据，也不应检查零长度 RDMA WRITE 请求的 R_Key 字段。

9.8.2.2.5 响应器 - 长度验证

C9-194：对于使用不可靠连接服务的 HCA 响应器，应检查 LRH 的 PktLen 字段，以确认接收 WQE 指定的接收缓冲区中有足够的可用空间。此检查仅适用于 SEND 操作。o9-138：如果 TCA 响应器实现了不可靠连接服务，应检查 LRH 的 PktLen 字段，以确认接收 WQE 指定的接收缓冲区中有足够的可用空间。此检查仅适用于 SEND 操作。还应通过将数据包的长度与 OpCode 进行比较来验证其长度，如下所示：C9-195：对于使用不可靠连接服务的 HCA 响应者，如果 UC BTH：OpCode 指定“第一个”或“中间”数据包，则数据包有效载荷长度必须是完整的 PMTU 大小。o9-139：如果 TCA 响应者实施不可靠连接服务，并且如果 UC BTH：OpCode 指定“第一个”或“中间”数据包，则数据包有效载荷长度必须是完整的 PMTU 大小。C9-196：对于使用不可靠连接服务的 HCA 响应者，如果 UC BTH：OpCode 指定“唯一”数据包，则数据包有效载荷长度必须在零和 PMTU 字节之间。因此，创建零字节长度传输的唯一方法是使用单个数据包消息。 o9-140：如果 TCA 响应器实现不可靠连接服务，并且 UC BTH:OpCode 指定“唯一”数据包，则数据包有效载荷长度必须在 0 到 PMTU 字节之间。因此，创建零字节长度传输的唯一方法是使用单数据包消息。C9-197：对于使用不可靠连接服务的 HCA 响应器，如果 UC BTH:OpCode 指定“最后一个”数据包，则数据包有效载荷长度必须在 1 到 PMTU 字节之间。o9-141：如果 TCA 响应器实现不可靠连接服务，并且 UC BTH:OpCode 指定“最后一个”数据包，则数据包有效载荷长度必须在 1 到 PMTU 字节之间。C9-198：此合规声明已过时且已被删除。o9-142：此合规声明已过时且已被删除。 C9-199：对于使用不可靠连接服务的 HCA 响应者，如果 BTH:OpCode 字段[4:0] 指定了第一个或中间请求数据包（例如，SEND First 或 RDMA WRITE Middle），则填充计数位经验证为 b00，表示不存在填充字节。如果填充计数位非零，则 OpCode 无效。o9-143：如果 TCA 响应者实现了不可靠连接服务，并且 BTH:OpCode 字段[4:0] 指定了第一个或中间请求数据包（例如，SEND First 或 RDMA WRITE Middle），则填充计数位经验证为 b00，表示不存在填充字节。如果填充计数位非零，则 OpCode 无效。如果检测到长度无效的数据包，则该请求为无效请求。响应者的行为是这种情况在 9.9.3.1 节“响应方错误响应”（第 448 页）中进行了说明。

9.8.2.2.6 响应方 - 本地操作验证

有效的入站请求仍可能由于响应方本地的故障（例如，访问本地内存时发生本地内存转换错误）而无法完成。本地错误可能导致接收队列转换为错误状态。有关更多详细信息，请参阅 9.9.3 节“响应方行为”（第 444 页）。

9.8.2.2.7 完成消息接收

响应方在以下情况下认为给定的入站消息已成功完成： • 检测到有效消息的开头，具体表现为 BTH 中存在“首包”或“唯一包”操作码； • 检测到同一有效消息的结尾，具体表现为 BTH 中存在“唯一包”或“末包”操作码，且 PSN 序列中无跳跃； • 成功按顺序接收“首包”和“末包”之间的所有数据包，或成功接收“唯一包”。 • 将消息有效载荷无误地提交到本地故障区； • 成功完成所有相应的有效性检查（包括变量 CRC 和不变 CRC）。 在上述任何步骤中检测到的故障都可能导致或不导致相关的 WQE 错误完成。在某些情况下，例如丢失“首包”，很可能不会有任何 WQE 完成。将被响应方使用。需要注意的是，如果出现错误，则无法保证响应方内存的状态。在检测到错误之前，部分或全部给定数据包可能已提交到响应方内存中。一旦成功完成入站消息接收，响应方将完成当前的工作队列单元 (WQE)。

9.8.3 不可靠数据报

不可靠数据报是一种通信形式，允许源 QP 将每条消息发送到可能存在于相同或多个目标端节点上的多个目标 QP 之一。• 对于每条要发送的消息，必须向请求方提供目标地址（参见第 607 页的 11.2.2.1 创建地址句柄(AH)）、目标 QP、目标 Q_Key 等。有关 HCA 提供的参数，请参见第 672 页的 11.4.1.1 发布发送请求。响应者必须向客户端提供请求者的地址、QP 等。有关 HCA 要求的更多详细信息，请参阅第 684 页上的 11.4.2.1 轮询完成

C9-200：发送 UD 消息的设备应将 UD 消息大小限制为单个数据包。数据包大小不得大于源和目标之间的 PMTU（否则将被丢弃）。C9-201：发送和接收 UD 消息的设备应满足基本不可靠服务的要求（请参阅第 411 页的 9.8 不可靠服务至第 412 页的 9.8.1 验证和执行请求）。C9-202：发送和接收 IBA UD 消息的设备应满足第 431 页的 9.9 错误检测和处理中规定的要求。

9.8.3.1 请求方行为

本节规定了请求方在生成请求数据包时所需的行为。 C9-203：发送 UD 消息的设备应满足第 428 页上的 9.8.3.1.1 生成 PSN 和第 428 页上的 9.8.3.1.2 完成消息发送中规定的要求。

此图显示了不可靠数据报 QP 的两个视图。处理器 1 上的进程 A 与三个进程通信：处理器 2 上的进程 C 和 D，以及处理器 3 上的进程 E。右侧视图显示了软件如何查看连接。发送 Q 中的缓冲区流入已连接 QP 上接收队列中的缓冲区。下方视图提供了一个以硬件为中心的视图，显示了每个已连接 QP 维护的一些状态。由于每个 QP 都没有连接到任何设备，因此每条消息都会选择目的地和其他必要信息（SL、DGID 等）。PSN 在生成时不会被检查

9.8.3.1.1 生成 PSN

C9-204：对于 UD 传输服务上的每条请求消息，请求方应生成 PSN，其增量为前一个请求数据包的 PSN 值，增量为“1”（模 2的24次幂）。QP0 和 QP1 无需增加 PSN。初始 PSN 值应由传输层的客户端在发送队列处于初始化状态时加载，并可初始化为任意 24 位值。在传输请求数据包的过程中，传输层应仅在发送队列处于准备发送状态时修改（更新）PSN。

9.8.3.1.2 完成消息发送

当请求方完成以下操作时，应认为消息发送已完成： • 将数据包 VCRC 字段的最后一个字节提交至线路，并且未检测到与消息传输相关的本地错误。 • 检测到与消息传输相关的本地错误，导致请求方终止发送请求。 请注意，在请求方完成发送 WQE 时，响应方的内存状态未知。同样，如果请求方在发送请求数据包时检测到本地错误，则响应方的内存状态也未知。

9.8.3.2 响应方行为

本节规定了响应方在接收入站请求时所需的行为。9.8.3.2.1 响应方 - 验证 PSN o9-144：对于 UD 传输服务，响应方可以忽略 PSN 字段。某些应用程序（例如基于多播的媒体流）可能会受益于响应方验证 PSN 序列以检测乱序数据包。响应方实现可以这样做，但这超出了 IBA 规范的范围。

9.8.3.2.2 响应方 - 长度验证

C9-205：在执行请求之前，响应方应按照 9.8.3.2.2：响应方 - 长度验证中所述，验证 LRH 的数据包长度字段和 BTH 的填充计数 (PadCnt)。应验证以下特性： • 应检查长度字段，以确认接收 WQE 指定的接收缓冲区中有足够的可用空间。 • 数据包有效载荷长度必须介于 0 到 PMTU 字节（含）之间。 如果检测到长度无效的数据包，则该请求为无效请求，响应方应按照第 444 页第 9.9.3 节“响应方行为”中的规定静默丢弃该请求。然后，响应方等待新的请求数据包。

9.8.3.2.3 响应器操作码验证

C9-206：对于 UD，响应器应在执行请求之前验证请求功能 (SEND) 的 BTH:OpCode 是否受此接收队列支持，且未被保留，否则该请求无效。C9-207：如果 UD 接收队列没有用于保存入站 SEND 请求的条目，则该请求无效。如果请求无效，响应器应将其静默丢弃，如第 444 页第 9.9.3 节“响应器端行为”中所述。

9.8.3.2.4 响应器 - 本地操作验证

有效的入站请求仍可能由于响应器本地故障而无法完成，例如访问本地内存时出现本地内存转换错误。本地错误可能导致接收队列转换为错误状态。有关更多详细信息，请参阅第 444 页第 9.9.3 节“响应器端行为”。

9.8.3.2.5 完成消息接收

响应方在以下情况下认为给定的入站消息已成功完成： • 将消息有效负载无错误地提交到本地故障区 • 成功完成所有适当的有效性检查（包括变量 CRC 和不变 CRC）。 在上述任何步骤中检测到的故障都可能导致或不导致相关的工作队列单元 (WQE) 错误完成。在某些情况下，例如操作码或长度错误，响应方将不会使用任何工作队列单元 (WQE)。需要注意的是，在出现错误的情况下，无法保证响应方内存的状态。在检测到错误之前，部分或全部给定数据包可能已提交到响应方内存中。一旦入站消息接收成功完成，响应方即完成当前的工作队列单元 (WQE)。

9.8.4 原始数据报

前面几节描述了 IBA 规范定义的不同传输协议。除此之外，IBA 还允许 IBA 子网承载其他协议。封装此类流量的 IBA 数据报被称为原始数据报。IBA 定义了两种不同的方法来支持原始数据报。在第 218 页的 7.7.5 节“链路下一报头 (LNH) - 2 位”中，本地路由报头中的两位用于指定 LRH 之后的下一个报头。下表列出了描述原始数据报的两种 LNH 编码。

第一种原始数据报编码方法仅适用于 IPv6 数据报。数据包有效载荷可以包含由 IETF 对 IPv6 报头的“下一个报头”字段编码定义的任何传输或网络协议，但不包括任何指示下一个报头为 IBA 传输报头的编码。C9-208：CA 不得生成出站数据包，并且将丢弃任何 LRH 指示原始数据报且 IPv6“下一个报头”指示 IBA 传输的入站数据包。TCA 可以以任何方式报告此错误。

第二种原始数据报编码方法使用 IBA 定义的原始报头 (RWH)。RWH 包含 16 位以太网类型字段 - RWH 的描述见第 181 页的 5.3 节“原始数据包格式”。RWH 用于定义封装在数据包有效载荷中的协议报头。通常，第二种方法用于允许 IPv6 下一个报头不支持的协议 - 需要注意的是，两种方法都可以用于传输 IPv6 数据报。 o9-145：如果CA实现了对原始数据报的支持，则原始数据报的数据包有效载荷必须始终为模4大小，因为LRH数据包长度以4字节为增量描述长度。如果封装的有效载荷大小不是4字节的倍数，则有效载荷应填充为4字节的倍数。o9-146：如果CA实现了对原始数据报的支持，则用于注入和使用原始数据报的QP应在本地管理，即QP与给定原始数据报服务的关联取决于具体实现。o9-147：如果CA实现了对原始数据报的支持，它可以支持一个或多个用于原始数据报操作的QP。

9.8.4.1 原始数据报数据包大小

IBA MTU定义了IBA传输数据有效载荷的最大大小。 IBA 数据包的最大大小为 MTU+124 字节（参见第 219 页上的 7.7.8 数据包长度 (PktLen) - 11 位）。o9-148：如果 CA 实现了原始数据报支持，并且由于原始数据报不使用 IBA 传输头，因此原始数据报的数据包有效载荷可能大于支持的 MTU（参见第 430 页上的图 119 原始数据报）。下表总结了两种原始数据报类型的最大数据包有效载荷（以及 LRH PktLen 字段的对应值）

参考

IB Spec1.6 卷1第9章