Network Working Group H. Shah
Request for Comments: 5041 Broadcom Corporation
Category: Standards Track J. Pinkerton
Microsoft Corporation
R. Recio
IBM Corporation
P. Culley
Hewlett-Packard Company
October 2007
Network Working Group H. Shah
Request for Comments: 5041 Broadcom Corporation
Category: Standards Track J. Pinkerton
Microsoft Corporation
R. Recio
IBM Corporation
P. Culley
Hewlett-Packard Company
October 2007
Direct Data Placement over Reliable Transports
通过可靠传输直接放置数据
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers.
直接数据放置协议提供信息，将传入数据直接放置到上层协议的接收缓冲区中，而无需中间缓冲区。这将消除与通过中间缓冲区传输数据相关的多余CPU和内存利用率。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Architectural Goals ........................................3
1.2. Protocol Overview ..........................................4
1.3. DDP Layering ...............................................6
2. Glossary ........................................................7
2.1. General ....................................................7
2.2. LLP ........................................................9
2.3. Direct Data Placement (DDP) ................................9
3. Reliable Delivery LLP Requirements .............................12
4. Header Format ..................................................13
4.1. DDP Control Field .........................................13
4.2. DDP Tagged Buffer Model Header ............................14
4.3. DDP Untagged Buffer Model Header ..........................16
4.4. DDP Segment Format ........................................17
5. Data Transfer ..................................................18
5.1. DDP Tagged or Untagged Buffer Models ......................18
5.1.1. Tagged Buffer Model ................................18
1. Introduction ....................................................3
1.1. Architectural Goals ........................................3
1.2. Protocol Overview ..........................................4
1.3. DDP Layering ...............................................6
2. Glossary ........................................................7
2.1. General ....................................................7
2.2. LLP ........................................................9
2.3. Direct Data Placement (DDP) ................................9
3. Reliable Delivery LLP Requirements .............................12
4. Header Format ..................................................13
4.1. DDP Control Field .........................................13
4.2. DDP Tagged Buffer Model Header ............................14
4.3. DDP Untagged Buffer Model Header ..........................16
4.4. DDP Segment Format ........................................17
5. Data Transfer ..................................................18
5.1. DDP Tagged or Untagged Buffer Models ......................18
5.1.1. Tagged Buffer Model ................................18
5.1.2. Untagged Buffer Model ..............................18
5.2. Segmentation and Reassembly of a DDP Message ..............19
5.3. Ordering Among DDP Messages ...............................21
5.4. DDP Message Completion and Delivery .......................21
6. DDP Stream Setup and Teardown ..................................22
6.1. DDP Stream Setup ..........................................22
6.2. DDP Stream Teardown .......................................22
6.2.1. DDP Graceful Teardown ..............................22
6.2.2. DDP Abortive Teardown ..............................23
7. Error Semantics ................................................24
7.1. Errors Detected at the Data Sink ..........................24
7.2. DDP Error Numbers .........................................25
8. Security Considerations ........................................26
8.1. Protocol-Specific Security Considerations .................26
8.2. Association of an STag and a DDP Stream ...................26
8.3. Security Requirements .....................................27
8.3.1. RNIC Requirements ..................................28
8.3.2. Privileged Resources Manager Requirement ...........29
8.4. Security Services for DDP .................................30
8.4.1. Available Security Services ........................30
8.4.2. Requirements for IPsec Services for DDP ............30
9. IANA Considerations ............................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Receive Window Sizing ................................34
Appendix B. Contributors .........................................34
5.1.2. Untagged Buffer Model ..............................18
5.2. Segmentation and Reassembly of a DDP Message ..............19
5.3. Ordering Among DDP Messages ...............................21
5.4. DDP Message Completion and Delivery .......................21
6. DDP Stream Setup and Teardown ..................................22
6.1. DDP Stream Setup ..........................................22
6.2. DDP Stream Teardown .......................................22
6.2.1. DDP Graceful Teardown ..............................22
6.2.2. DDP Abortive Teardown ..............................23
7. Error Semantics ................................................24
7.1. Errors Detected at the Data Sink ..........................24
7.2. DDP Error Numbers .........................................25
8. Security Considerations ........................................26
8.1. Protocol-Specific Security Considerations .................26
8.2. Association of an STag and a DDP Stream ...................26
8.3. Security Requirements .....................................27
8.3.1. RNIC Requirements ..................................28
8.3.2. Privileged Resources Manager Requirement ...........29
8.4. Security Services for DDP .................................30
8.4.1. Available Security Services ........................30
8.4.2. Requirements for IPsec Services for DDP ............30
9. IANA Considerations ............................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Receive Window Sizing ................................34
Appendix B. Contributors .........................................34
Table of Figures
图表
Figure 1: DDP Layering ............................................6
Figure 2: MPA, DDP, and RDMAP Header Alignment ....................7
Figure 3: DDP Control Field ......................................13
Figure 4: Tagged Buffer DDP Header ...............................15
Figure 5: Untagged Buffer DDP Header .............................16
Figure 6: DDP Segment Format .....................................17
Figure 1: DDP Layering ............................................6
Figure 2: MPA, DDP, and RDMAP Header Alignment ....................7
Figure 3: DDP Control Field ......................................13
Figure 4: Tagged Buffer DDP Header ...............................15
Figure 5: Untagged Buffer DDP Header .............................16
Figure 6: DDP Segment Format .....................................17
Note: The capitalization of certain words in this document indicates they are being used with the specific meaning given in the glossary (Section 2).
注：本文件中某些词语的大写表示其使用具有术语表（第2节）中给出的特定含义。
Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol (ULP) to send data to a Data Sink without requiring the Data Sink to Place the data in an intermediate buffer - thus, when the data arrives at the Data Sink, the network interface can Place the data directly into the ULP's buffer. This can enable the Data Sink to consume substantially less memory bandwidth than a buffered model because the Data Sink is not required to move the data from the intermediate buffer to the final destination. Additionally, this can enable the network protocol to consume substantially fewer CPU cycles than if the CPU was used to move the data, and this can remove the bandwidth limitation of only being able to move data as fast as the CPU can copy the data.
直接数据放置协议（DDP）使上层协议（ULP）能够向数据接收器发送数据，而无需数据接收器将数据放置在中间缓冲区中-因此，当数据到达数据接收器时，网络接口可以将数据直接放置到ULP的缓冲区中。这可以使数据接收器消耗的内存带宽大大低于缓冲模型，因为数据接收器不需要将数据从中间缓冲区移动到最终目的地。此外，与使用CPU移动数据相比，这可以使网络协议消耗更少的CPU周期，并且这可以消除仅能够以CPU复制数据的速度移动数据的带宽限制。
DDP preserves ULP record boundaries (messages) while providing a variety of data transfer mechanisms and completion mechanisms to be used to transfer ULP messages.
DDP保留ULP记录边界（消息），同时提供用于传输ULP消息的各种数据传输机制和完成机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
DDP has been designed with the following high-level architectural goals:
DDP的设计具有以下高层架构目标：
* Provide a buffer model that enables the Local Peer to Advertise a named buffer (i.e., a Tag for a buffer) to the Remote Peer, such that across the network the Remote Peer can Place data into the buffer at Remote-Peer-specified locations. This is referred to as the Tagged Buffer Model.
* 提供一种缓冲区模型，使本地对等方能够向远程对等方公布命名缓冲区（即，缓冲区的标记），以便远程对等方可以通过网络将数据放入远程对等方指定位置的缓冲区中。这称为标记缓冲区模型。
* Provide a second receive buffer model that preserves ULP message boundaries from the Remote Peer and keeps the Local Peer's buffers anonymous (i.e., Untagged). This is referred to as the Untagged Buffer Model.
* 提供第二个接收缓冲区模型，该模型保留来自远程对等方的ULP消息边界，并保持本地对等方的缓冲区匿名（即未标记）。这称为未标记缓冲区模型。
* Provide reliable, in-order Delivery semantics for both Tagged and Untagged Buffer Models.
* 为标记和未标记的缓冲区模型提供可靠的顺序交付语义。
* Provide segmentation and reassembly of ULP messages.
* 提供ULP消息的分段和重新组装。
* Enable the ULP Buffer to be used as a reassembly buffer, without a need for a copy, even if incoming DDP Segments arrive out of order. This requires the protocol to separate Data Placement of ULP Payload contained in an incoming DDP Segment from Data Delivery of completed ULP Messages.
* 允许ULP缓冲区用作重新组装缓冲区，而无需复制，即使传入的DDP段出现故障。这要求协议将包含在传入DDP段中的ULP有效负载的数据放置与完成的ULP消息的数据交付分开。
* If the Lower Layer Protocol (LLP) supports multiple LLP Streams within an LLP Connection, provide the above capabilities independently on each LLP Stream and enable the capability to be exported on a per-LLP-Stream basis to the ULP.
* 如果较低层协议（LLP）在一个LLP连接中支持多个LLP流，则在每个LLP流上独立提供上述功能，并使该功能能够在每个LLP流的基础上导出到ULP。
DDP supports two basic data transfer models - a Tagged Buffer data transfer model and an Untagged Buffer data transfer model.
DDP支持两种基本的数据传输模型——标记缓冲区数据传输模型和非标记缓冲区数据传输模型。
The Tagged Buffer data transfer model requires the Data Sink to send the Data Source an identifier for the ULP Buffer, referred to as a Steering Tag (STag). The STag is transferred to the Data Source using a ULP-defined method. Once the Data Source ULP has an STag for a destination ULP Buffer, it can request that DDP send the ULP data to the destination ULP Buffer by specifying the STag to DDP. Note that the Tagged Buffer does not have to be filled starting at the beginning of the ULP Buffer. The ULP Data Source can provide an arbitrary offset into the ULP Buffer.
标记缓冲区数据传输模型要求数据接收器向数据源发送ULP缓冲区的标识符，称为转向标签（STag）。STag使用ULP定义的方法传输到数据源。一旦数据源ULP具有目标ULP缓冲区的STag，它可以通过将STag指定给DDP来请求DDP将ULP数据发送到目标ULP缓冲区。请注意，标记的缓冲区不必从ULP缓冲区开始填充。ULP数据源可以向ULP缓冲区提供任意偏移量。
The Untagged Buffer data transfer model enables data transfer to occur without requiring the Data Sink to Advertise a ULP Buffer to the Data Source. The Data Sink can queue up a series of receive ULP Buffers. An Untagged DDP Message from the Data Source consumes an Untagged Buffer at the Data Sink. Because DDP is message oriented, even if the Data Source sends a DDP Message payload smaller than the receive ULP Buffer, the partially filled receive ULP Buffer is delivered to the ULP anyway. If the Data Source sends a DDP Message payload larger than the receive ULP Buffer, it results in an error.
未标记缓冲区数据传输模型允许数据传输发生，而无需数据接收器向数据源播发ULP缓冲区。数据接收器可以将一系列接收ULP缓冲区排队。来自数据源的未标记DDP消息消耗数据接收器处的未标记缓冲区。因为DDP是面向消息的，所以即使数据源发送的DDP消息有效负载小于接收ULP缓冲区，部分填充的接收ULP缓冲区也会传递到ULP。如果数据源发送的DDP消息有效负载大于接收ULP缓冲区，则会导致错误。
There are several key differences between the Tagged and Untagged Buffer Model:
标记缓冲区模型和未标记缓冲区模型之间有几个关键区别：
* For the Tagged Buffer Model, the Data Source specifies which received Tagged Buffer will be used for a specific Tagged DDP Message (sender-based ULP Buffer management). For the Untagged Buffer Model, the Data Sink specifies the order in which Untagged Buffers will be consumed as Untagged DDP Messages are received (receiver-based ULP Buffer management).
* 对于标记缓冲区模型，数据源指定接收到的哪个标记缓冲区将用于特定的标记DDP消息（基于发送方的ULP缓冲区管理）。对于未标记缓冲区模型，数据接收器指定接收未标记DDP消息时使用未标记缓冲区的顺序（基于接收器的ULP缓冲区管理）。
* For the Tagged Buffer Model, the ULP at the Data Sink must Advertise the ULP Buffer to the Data Source through a ULP
* 对于标记的缓冲区模型，数据接收器处的ULP必须通过ULP向数据源播发ULP缓冲区
specific mechanism before data transfer can occur. For the Untagged Buffer Model, data transfer can occur without an end-to-end explicit ULP Buffer Advertisement. Note, however, that the ULP needs to address flow control issues.
数据传输之前的特定机制。对于未标记的缓冲区模型，数据传输可以在没有端到端显式ULP缓冲区播发的情况下进行。但是，请注意，ULP需要解决流量控制问题。
* For the Tagged Buffer Model, a DDP Message can start at an arbitrary offset within the Tagged Buffer. For the Untagged Buffer Model, a DDP Message can only start at offset 0.
* 对于标记缓冲区模型，DDP消息可以从标记缓冲区内的任意偏移量开始。对于未标记的缓冲区模型，DDP消息只能从偏移量0开始。
* The Tagged Buffer Model allows multiple DDP Messages targeted to a Tagged Buffer with a single ULP Buffer Advertisement. The Untagged Buffer Model requires associating a receive ULP Buffer for each DDP Message targeted to an Untagged Buffer.
* 标记缓冲区模型允许多个DDP消息以单个ULP缓冲区播发的标记缓冲区为目标。未标记缓冲区模型要求为每个以未标记缓冲区为目标的DDP消息关联接收ULP缓冲区。
Either data transfer model Places a ULP Message into a DDP Message. Each DDP Message is then sliced into DDP Segments that are intended to fit within a lower-layer-protocol's (LLP) Maximum Upper Layer Protocol Data Unit (MULPDU). Thus, the ULP can post arbitrarily sized ULP Messages, containing up to 2^32 - 1 octets of ULP Payload, and DDP slices the ULP message into DDP Segments, which are reassembled transparently at the Data Sink.
两种数据传输模型都将ULP消息放入DDP消息中。然后，将每个DDP消息分为DDP段，这些DDP段旨在适合下层协议（LLP）的最大上层协议数据单元（MULPDU）。因此，ULP可以发布任意大小的ULP消息，其中包含多达2^32-1个ULP有效负载八位字节，并且DDP将ULP消息分为DDP段，这些段在数据接收器处透明地重新组装。
DDP provides in-order delivery for the ULP. However, DDP differentiates between Data Delivery and Data Placement. DDP provides enough information in each DDP Segment to allow the ULP Payload in each inbound DDP Segment payloads to be directly Placed into the correct ULP Buffer, even when the DDP Segments arrive out-of-order. Thus, DDP enables the reassembly of ULP Payload contained in DDP Segments of a DDP Message into a ULP Message to occur within the ULP Buffer, therefore eliminating the traditional copy out of the reassembly buffer into the ULP Buffer.
DDP为ULP提供订单交付。然而，DDP区分了数据交付和数据放置。DDP在每个DDP段中提供足够的信息，允许每个入站DDP段有效载荷中的ULP有效载荷直接放入正确的ULP缓冲区，即使DDP段到达时出现故障。因此，DDP允许在ULP缓冲区内将DDP消息的DDP段中包含的ULP有效负载重新组装为ULP消息，从而消除了从重新组装缓冲区到ULP缓冲区的传统拷贝。
A DDP Message's payload is Delivered to the ULP when:
在以下情况下，DDP消息的有效负载被传送到ULP：
* all DDP Segments of a DDP Message have been completely received, and the payload of the DDP Message has been Placed into the associated ULP Buffer,
* DDP消息的所有DDP段都已完全接收，并且DDP消息的有效负载已放入相关的ULP缓冲区，
* all prior DDP Messages have been Placed, and
* 已放置所有先前的DDP消息，并且
* all prior DDP Message Deliveries have been performed.
* 所有先前的DDP消息传递都已执行。
The LLP under DDP may support a single LLP Stream of data per connection (e.g., TCP [TCP]) or multiple LLP Streams of data per connection (e.g., SCTP [SCTP]). But in either case, DDP is specified such that each DDP Stream is independent and maps to a single LLP Stream. Within a specific DDP Stream, the LLP Stream is required to
DDP下的LLP可支持每个连接的单个LLP数据流（例如TCP[TCP]）或每个连接的多个LLP数据流（例如SCTP[SCTP]）。但在这两种情况下，指定DDP时，每个DDP流都是独立的，并且映射到单个LLP流。在特定DDP流中，要求LLP流
provide in-order, reliable Delivery. Note that DDP has no ordering guarantees between DDP Streams.
提供有序、可靠的交货。请注意，DDP在DDP流之间没有订购保证。
A DDP protocol could potentially run over reliable Delivery LLPs or unreliable Delivery LLPs. This specification requires reliable, in order Delivery LLPs.
DDP协议可能会在可靠交付LLP或不可靠交付LLP上运行。本规范要求可靠、有序的交付LLP。
DDP is intended to be LLP independent, subject to the requirements defined in section 3. However, DDP was specifically defined to be part of a family of protocols that were created to work well together, as shown in Figure 1, DDP Layering. For LLP protocol definitions of each LLP, see Marker PDU Aligned Framing for TCP Specification [MPA] and Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation [SCTPDDP].
DDP旨在独立于有限责任合伙，符合第3节规定的要求。然而，DDP被明确定义为一系列协议的一部分，这些协议是为了协同工作而创建的，如图1“DDP分层”所示。有关每个LLP的LLP协议定义，请参阅TCP规范的标记PDU对齐帧[MPA]和流控制传输协议（SCTP）直接数据放置（DDP）适配[SCTPDDP]。
DDP enables direct data Placement capability for any ULP, but it has been specifically designed to work well with Remote Direct Memory Access Protocol (RDMAP) (see [RDMAP]), and is part of the iWARP protocol suite.
DDP支持任何ULP的直接数据放置功能，但它经过专门设计，可与远程直接内存访问协议（RDMAP）配合使用（参见[RDMAP]），并且是iWARP协议套件的一部分。
+-------------------+
| |
| RDMA ULP |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| ULP | RDMAP |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DDP protocol |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MPA | |
| | |
| | |
+-+-+-+-+-+-+-+-+-+ SCTP |
| | |
| TCP | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------+
| |
| RDMA ULP |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| ULP | RDMAP |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DDP protocol |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MPA | |
| | |
| | |
+-+-+-+-+-+-+-+-+-+ SCTP |
| | |
| TCP | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DDP Layering
图1：DDP分层
If DDP is layered below RDMAP and on top of MPA and TCP, then the respective headers and payload are arranged as follows (Note: For clarity, MPA header and CRC are included, but framing markers are not shown.):
如果DDP分层在RDMAP之下，MPA和TCP之上，则相应的报头和有效载荷如下所示（注：为清楚起见，包括MPA报头和CRC，但未显示帧标记）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TCP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// DDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// RDMAP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
// RDMAP ULP Payload //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TCP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// DDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// RDMAP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
// RDMAP ULP Payload //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPA, DDP, and RDMAP Header Alignment
图2:MPA、DDP和RDMAP标题对齐
Advertisement (Advertised, Advertise, Advertisements, Advertises) - The act of informing a Remote Peer that a local RDMA Buffer is available to it. A Node makes available an RDMA Buffer for incoming RDMA Read or RDMA Write access by informing its RDMA/DDP peer of the Tagged Buffer identifiers (STag, base address, length). This Advertisement of Tagged Buffer information is not defined by RDMA/DDP and is left to the ULP. A typical method would be for the Local Peer to embed the Tagged Buffer's Steering Tag, address, and length in a Send message destined for the Remote Peer.
广告（广告、广告、广告、广告）-通知远程对等方本地RDMA缓冲区可用的行为。节点通过通知其RDMA/DDP对等方已标记的缓冲区标识符（STag、基址、长度），为传入的RDMA读或RDMA写访问提供RDMA缓冲区。RDMA/DDP没有定义标记缓冲区信息的播发，而是留给ULP。一种典型的方法是，本地对等方将标记缓冲区的引导标记、地址和长度嵌入到发送给远程对等方的发送消息中。
Data Delivery (Delivery, Delivered, Delivers) - Delivery is defined as the process of informing the ULP or consumer that a particular message is available for use. This is specifically different from "Placement", which may generally occur in any order, while the order of "Delivery" is strictly defined. See "Data Placement".
数据交付（Delivery，Delivered，Delivers）-交付被定义为通知ULP或消费者特定消息可供使用的过程。这与通常在任何订单中出现的“放置”特别不同，而“交付”的订单是严格定义的。见“数据放置”。
Data Sink - The peer receiving a data payload. Note that the Data Sink can be required to both send and receive RDMA/DDP Messages to transfer a data payload.
数据接收器-接收数据有效负载的对等方。请注意，可以要求数据接收器发送和接收RDMA/DDP消息以传输数据有效负载。
Data Source - The peer sending a data payload. Note that the Data Source can be required to both send and receive RDMA/DDP Messages to transfer a data payload.
数据源-发送数据有效负载的对等方。请注意，可以要求数据源发送和接收RDMA/DDP消息以传输数据有效负载。
Delivery (Delivered, Delivers) - See Data Delivery in Section 2.1.
交付（交付，交付）-见第2.1节中的数据交付。
iWARP - A suite of wire protocols comprised of RDMAP [RDMAP], DDP (this specification), and Marker PDU Aligned Framing for TCP (MPA) [MPA]. The iWARP protocol suite may be layered above TCP, SCTP, or other transport protocols.
iWARP—一套有线协议，由RDMAP[RDMAP]、DDP（本规范）和TCP（MPA）[MPA]的标记PDU对齐帧组成。iWARP协议套件可以分层在TCP、SCTP或其他传输协议之上。
Local Peer - The RDMA/DDP protocol implementation on the local end of the connection. Used to refer to the local entity when describing a protocol exchange or other interaction between two Nodes.
本地对等-连接本地端上的RDMA/DDP协议实现。在描述两个节点之间的协议交换或其他交互时，用于引用本地实体。
Node - A computing device attached to one or more links of a network. A Node in this context does not refer to a specific application or protocol instantiation running on the computer. A Node may consist of one or more RDMA Enabled Network Interface Controllers (RNICs) installed in a host computer.
节点-连接到网络的一个或多个链路的计算设备。此上下文中的节点不引用计算机上运行的特定应用程序或协议实例化。节点可以由安装在主机中的一个或多个支持RDMA的网络接口控制器（RNIC）组成。
Placement (Placed, Places) - See "Data Placement" in Section 2.3
放置（放置，放置）-参见第2.3节中的“数据放置”
Remote Peer - The RDMA/DDP protocol implementation on the opposite end of the connection. Used to refer to the remote entity when describing protocol exchanges or other interactions between two Nodes.
远程对等-连接另一端的RDMA/DDP协议实现。在描述两个节点之间的协议交换或其他交互时，用于指代远程实体。
RNIC - RDMA Enabled Network Interface Controller. In this context, this would be a network I/O adapter or embedded controller with iWARP functionality.
RNIC-支持RDMA的网络接口控制器。在这种情况下，这将是一个具有iWARP功能的网络I/O适配器或嵌入式控制器。
ULP - Upper Layer Protocol. The protocol layer above the protocol layer currently being referenced. The ULP for RDMA/DDP is expected to be an Operating System (OS), application, adaptation layer, or proprietary device. The RDMA/DDP documents do not
ULP-上层协议。当前引用的协议层之上的协议层。RDMA/DDP的ULP应为操作系统（OS）、应用程序、适配层或专有设备。RDMA/DDP文件没有
specify a ULP -- they provide a set of semantics that allow a ULP to be designed to utilize RDMA/DDP.
指定ULP——它们提供了一组语义，允许ULP设计为利用RDMA/DDP。
ULP Message - The ULP data that is handed to a specific protocol layer for transmission. Data boundaries are preserved as they are transmitted through iWARP.
ULP消息-传递给特定协议层进行传输的ULP数据。数据边界在通过iWARP传输时被保留。
ULP Payload - The ULP data that is contained within a single protocol segment or packet (e.g., a DDP Segment).
ULP有效负载-包含在单个协议段或数据包（例如DDP段）内的ULP数据。
LLP - Lower Layer Protocol. The protocol layer beneath the protocol layer currently being referenced. For example, for DDP, the LLP is SCTP DDP Adaptation, MPA, or other transport protocols. For RDMA, the LLP is DDP.
LLP-低层协议。当前引用的协议层下的协议层。例如，对于DDP，LLP是SCTP-DDP自适应、MPA或其他传输协议。对于RDMA，LLP为DDP。
LLP Connection - Corresponds to an LLP transport-level connection between the peer LLP layers on two nodes.
LLP连接-对应于两个节点上对等LLP层之间的LLP传输级别连接。
LLP Stream - Corresponds to a single LLP transport-level stream between the peer LLP layers on two Nodes. One or more LLP Streams may map to a single transport-level LLP Connection. For transport protocols that support multiple streams per connection (e.g., SCTP), an LLP Stream corresponds to one transport-level stream.
LLP流-对应于两个节点上对等LLP层之间的单个LLP传输级流。一个或多个LLP流可以映射到单个传输级LLP连接。对于每个连接支持多个流的传输协议（例如，SCTP），LLP流对应于一个传输级流。
MULPDU - Maximum Upper Layer Protocol Data Unit (MULPDU). The current maximum size of the record that is acceptable for DDP to pass to the LLP for transmission.
最大上层协议数据单元（MULPDU）。DDP可以传递给LLP进行传输的记录的当前最大大小。
ULPDU - Upper Layer Protocol Data Unit. The data record defined by the layer above MPA.
ULPDU-上层协议数据单元。MPA以上层定义的数据记录。
Data Placement (Placement, Placed, Places) - For DDP, this term is specifically used to indicate the process of writing to a Data Buffer by a DDP implementation. DDP Segments carry Placement information, which may be used by the receiving DDP implementation to perform Data Placement of the DDP Segment ULP Payload. See "Data Delivery" and "Direct Data Placement".
数据放置（Placement，Placed，Places）-对于DDP，该术语专门用于表示DDP实现写入数据缓冲区的过程。DDP段携带放置信息，接收DDP实现可使用该信息来执行DDP段ULP有效载荷的数据放置。请参阅“数据交付”和“直接数据放置”。
DDP Abortive Teardown - The act of closing a DDP Stream without attempting to complete in-progress and pending DDP Messages.
DDP中止拆卸-关闭DDP流而不尝试完成正在进行和挂起的DDP消息的行为。
DDP Graceful Teardown - The act of closing a DDP Stream such that all in-progress and pending DDP Messages are allowed to complete successfully.
DDP优雅拆卸-关闭DDP流的行为，以便允许所有正在进行和挂起的DDP消息成功完成。
DDP Control Field - A fixed 8-bit field in the DDP Header.
DDP控制字段-DDP标头中的固定8位字段。
DDP Header - The header present in all DDP Segments. The DDP Header contains control and Placement fields that are used to define the final Placement location for the ULP Payload carried in a DDP Segment.
DDP标头-所有DDP段中存在的标头。DDP标头包含控制和放置字段，用于定义DDP段中携带的ULP有效负载的最终放置位置。
DDP Message - A ULP-defined unit of data interchange, which is subdivided into one or more DDP Segments. This segmentation may occur for a variety of reasons, including segmentation to respect the maximum segment size of the underlying transport protocol.
DDP报文—ULP定义的数据交换单元，细分为一个或多个DDP段。这种分段可能由于各种原因而发生，包括为了尊重底层传输协议的最大分段大小而进行的分段。
DDP Segment - The smallest unit of data transfer for the DDP protocol. It includes a DDP Header and ULP Payload (if present). A DDP Segment should be sized to fit within the Lower Layer Protocol MULPDU.
DDP段-DDP协议的最小数据传输单元。它包括DDP标头和ULP有效负载（如果存在）。DDP段的大小应适合较低层协议MULPDU。
DDP Stream - A sequence of DDP messages whose ordering is defined by the LLP. For SCTP, a DDP Stream maps directly to an SCTP stream. For MPA, a DDP Stream maps directly to a TCP connection, and a single DDP Stream is supported. Note that DDP has no ordering guarantees between DDP Streams.
DDP流—DDP消息序列，其顺序由LLP定义。对于SCTP，DDP流直接映射到SCTP流。对于MPA，DDP流直接映射到TCP连接，并且支持单个DDP流。请注意，DDP在DDP流之间没有订购保证。
DDP Stream Identifier (ID) - An identifier for a DDP Stream.
DDP流标识符（ID）-DDP流的标识符。
Direct Data Placement - A mechanism whereby ULP data contained within DDP Segments may be Placed directly into its final destination in memory without processing of the ULP. This may occur even when the DDP Segments arrive out of order. Out-of-order Placement support may require the Data Sink to implement the LLP and DDP as one functional block.
直接数据放置-DDP段中包含的ULP数据可直接放置到内存中的最终目的地，而无需处理ULP的一种机制。即使DDP段到达时出现故障，也可能发生这种情况。无序放置支持可能需要数据接收器将LLP和DDP实现为一个功能块。
Direct Data Placement Protocol (DDP) - Also, a wire protocol that supports Direct Data Placement by associating explicit memory buffer placement information with the LLP payload units.
直接数据放置协议（DDP）-也是一种有线协议，通过将显式内存缓冲区放置信息与LLP有效负载单元关联，支持直接数据放置。
Message Offset (MO) - For the DDP Untagged Buffer Model, specifies the offset, in octets, from the start of a DDP Message.
消息偏移量（MO）-对于DDP未标记缓冲区模型，指定从DDP消息开始的偏移量（以八位字节为单位）。
Message Sequence Number (MSN) - For the DDP Untagged Buffer Model, specifies a sequence number that is increasing with each DDP Message.
消息序列号（MSN）-对于DDP未标记缓冲区模型，指定随每条DDP消息增加的序列号。
Protection Domain (PD) - A mechanism used to associate a DDP Stream and an STag. Under this mechanism, the use of an STag is valid on a DDP Stream if the STag has the same Protection Domain Identifier (PD ID) as the DDP Stream.
保护域（PD）-用于关联DDP流和STag的机制。在此机制下，如果STag与DDP流具有相同的保护域标识符（PD ID），则STag在DDP流上的使用是有效的。
Protection Domain Identifier (PD ID) - An identifier for the Protection Domain.
保护域标识符（PD ID）-保护域的标识符。
Queue Number (QN) - For the DDP Untagged Buffer Model, identifies a destination Data Sink queue for a DDP Segment.
队列号（QN）-对于DDP未标记缓冲区模型，标识DDP段的目标数据接收器队列。
Steering Tag - An identifier of a Tagged Buffer on a Node, valid as defined within a protocol specification.
转向标记-节点上标记缓冲区的标识符，在协议规范中定义有效。
STag - Steering Tag
STag-转向标签
Tagged Buffer - A buffer that is explicitly Advertised to the Remote Peer through exchange of an STag, Tagged Offset, and length.
标记的缓冲区-通过交换STag、标记的偏移量和长度显式地通告给远程对等方的缓冲区。
Tagged Buffer Model - A DDP data transfer model used to transfer Tagged Buffers from the Local Peer to the Remote Peer.
标记缓冲区模型-DDP数据传输模型，用于将标记缓冲区从本地对等点传输到远程对等点。
Tagged DDP Message - A DDP Message that targets a Tagged Buffer.
标记的DDP消息-以标记的缓冲区为目标的DDP消息。
Tagged Offset (TO) - The offset within a Tagged Buffer on a Node.
标记的偏移量（到）-节点上标记的缓冲区内的偏移量。
ULP Buffer - A buffer owned above the DDP layer and Advertised to the DDP layer either as a Tagged Buffer or an Untagged ULP Buffer.
ULP缓冲区-DDP层上拥有的缓冲区，作为标记缓冲区或未标记ULP缓冲区播发给DDP层。
ULP Message Length - The total length, in octets, of the ULP Payload contained in a DDP Message.
ULP消息长度-DDP消息中包含的ULP有效负载的总长度（以八位字节为单位）。
Untagged Buffer - A buffer that is not explicitly Advertised to the Remote Peer.
未标记缓冲区-未显式播发给远程对等方的缓冲区。
Untagged Buffer Model - A DDP data transfer model used to transfer Untagged Buffers from the Local Peer to the Remote Peer.
未标记缓冲区模型-DDP数据传输模型，用于将未标记缓冲区从本地对等点传输到远程对等点。
Untagged DDP Message - A DDP Message that targets an Untagged Buffer.
未标记DDP消息-针对未标记缓冲区的DDP消息。
Any protocol that can serve as an LLP to DDP MUST meet the following requirements.
任何可作为DDP的LLP的协议必须满足以下要求。
1. LLPs MUST expose MULPDU and MULPDU changes. This is required so that the DDP layer can perform segmentation aligned with the MULPDU and can adapt as MULPDU changes come about. The corner case of how to handle outstanding requests during a MULPDU change is covered by the requirements below.
1. LLP必须公开MULPDU和MULPDU更改。这是必需的，以便DDP层可以执行与MULPDU对齐的分段，并且可以随着MULPDU的变化而调整。在MULPDU变更期间如何处理未完成请求的一个关键案例包含在以下需求中。
2. In the event of a MULPDU change, DDP MUST NOT be required by the LLP to re-segment DDP Segments that have been previously posted to the LLP. Note that under pathological conditions the LLP may change the Advertised MULPDU more frequently than the queue of previously posted DDP Segment transmit requests is flushed. Under this pathological condition, the LLP transmit queue can contain DDP Messages for which multiple updates to the corresponding MULPDU have occurred subsequent to posting of the messages. Thus, there may be no correlation between the queued DDP Segment(s) and the LLP's current value of MULPDU.
2. 如果MULPDU发生变更，LLP不得要求DDP重新划分先前已过账至LLP的DDP细分。请注意，在病理条件下，LLP可能会比刷新先前发布的DDP段传输请求队列更频繁地更改播发的MULPDU。在这种病态条件下，LLP传输队列可能包含DDP消息，对于这些消息，在发布消息之后对相应的MULPDU进行了多次更新。因此，排队的DDP段与LLP的MULPDU当前值之间可能没有相关性。
3. The LLP MUST ensure that, if it accepts a DDP Segment, it will transfer it reliably to the receiver or return with an error stating that the transfer failed to complete.
3. LLP必须确保，如果它接受DDP段，它将可靠地将其传输到接收器，或返回一个错误，说明传输未能完成。
4. The LLP MUST preserve DDP Segment and Message boundaries at the Data Sink.
4. LLP必须在数据接收器处保留DDP段和消息边界。
5. The LLP MAY provide the incoming segments out of order for Placement, but if it does, it MUST also provide information that specifies what the sender-specified order was.
5. LLP可能会提供不按顺序排列的输入段，但如果提供，则还必须提供指定发送方指定顺序的信息。
6. LLP MUST provide a strong digest (at least equivalent to CRC32-C) to cover at least the DDP Segment. It is believed that some of the existing data integrity digests are not sufficient, and that direct memory transfer semantics requires a stronger digest than, for example, a simple checksum.
6. LLP必须提供一份强有力的摘要（至少相当于CRC32-C），至少涵盖DDP部分。人们认为，一些现有的数据完整性摘要是不够的，直接内存传输语义需要比简单校验和更强的摘要。
7. On receive, the LLP MUST provide the length of the DDP Segment received. This ensures that DDP does not have to carry a length field in its header.
7. 接收时，LLP必须提供接收的DDP段的长度。这确保了DDP不必在其标头中携带长度字段。
8. If an LLP does not support teardown of an LLP Stream independent of other LLP Streams, and a DDP error occurs on a specific DDP Stream, then the LLP MUST label the associated LLP Stream as an erroneous LLP Stream and MUST NOT allow any further data transfer
8. 如果LLP不支持独立于其他LLP流的LLP流的拆卸，并且特定DDP流上发生DDP错误，则LLP必须将相关LLP流标记为错误LLP流，并且不得允许任何进一步的数据传输
on that LLP Stream after DDP requests the associated DDP Stream to be torn down.
在DDP请求拆除关联的DDP流之后，在该LLP流上。
9. For a specific LLP Stream, the LLP MUST provide a mechanism to indicate that the LLP Stream has been gracefully torn down. For a specific LLP Connection, the LLP MUST provide a mechanism to indicate that the LLP Connection has been gracefully torn down.
9. 对于特定的LLP流，LLP必须提供一种机制来指示LLP流已被正常地拆除。对于特定的LLP连接，LLP必须提供一种机制来指示LLP连接已正常断开。
Note that, if the LLP does not allow an LLP Stream to be torn down independently of the LLP Connection, the above requirements allow the LLP to notify DDP of both events at the same time.
注意，如果LLP不允许独立于LLP连接中断LLP流，则上述要求允许LLP同时通知DDP这两个事件。
10. For a specific LLP Connection, when all LLP Streams are either gracefully torn down or are labeled as erroneous LLP Streams, the LLP Connection MUST be torn down.
10. 对于特定的LLP连接，当所有LLP流都被正常删除或被标记为错误的LLP流时，必须删除LLP连接。
11. The LLP MUST NOT pass a duplicate DDP Segment to the DDP layer after it has passed all the previous DDP Segments to the DDP layer and the associated ordering information for the previous DDP Segments and the current DDP Segment.
11. LLP在将所有先前的DDP段以及先前DDP段和当前DDP段的相关订购信息传递给DDP层后，不得将重复的DDP段传递给DDP层。
DDP has two different header formats: one for Data Placement into Tagged Buffers, and the other for Data Placement into Untagged Buffers. See Section 5.1 for a description of the two models.
DDP有两种不同的头格式：一种用于将数据放置到标记的缓冲区，另一种用于将数据放置到未标记的缓冲区。有关这两种模型的说明，请参见第5.1节。
The first 8 bits of the DDP Header carry a DDP Control Field that is common between the two formats. It is shown below in Figure 3, offset by 16 bits to accommodate the MPA header defined in [MPA]. The MPA header is only present if DDP is layered on top of MPA.
DDP报头的前8位携带两种格式共用的DDP控制字段。如下图3所示，偏移16位以适应[MPA]中定义的MPA头。仅当DDP层叠在MPA顶部时，才会出现MPA集管。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|T|L| Rsvd |DV |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|T|L| Rsvd |DV |
+-+-+-+-+-+-+-+-+
Figure 3: DDP Control Field
图3：DDP控制字段
T - Tagged flag: 1 bit.
T标记标志：1位。
Specifies the Tagged or Untagged Buffer Model. If set to one, the ULP Payload carried in this DDP Segment MUST be Placed into a Tagged Buffer.
指定已标记或未标记的缓冲区模型。如果设置为1，则此DDP段中携带的ULP有效载荷必须放置在带标签的缓冲区中。
If set to zero, the ULP Payload carried in this DDP Segment MUST be Placed into an Untagged Buffer.
如果设置为零，此DDP段中携带的ULP有效负载必须放置在未标记的缓冲区中。
L - Last flag: 1 bit.
L-最后一个标志：1位。
Specifies whether the DDP Segment is the last segment of a DDP Message. It MUST be set to one on the last DDP Segment of every DDP Message. It MUST NOT be set to one on any other DDP Segment.
指定DDP段是否为DDP消息的最后一段。必须在每个DDP消息的最后一个DDP段上将其设置为1。在任何其他DDP段上不得设置为1。
The DDP Segment with the L bit set to 1 MUST be posted to the LLP after all other DDP Segments of the associated DDP Message have been posted to the LLP. For an Untagged DDP Message, the DDP Segment with the L bit set to 1 MUST carry the highest MO.
L位设置为1的DDP段必须在相关DDP报文的所有其他DDP段均已过账至LLP后过账至LLP。对于未标记的DDP消息，L位设置为1的DDP段必须携带最高MO。
If the Last flag is set to one, the DDP Message payload MUST be Delivered to the ULP after:
如果最后一个标志设置为1，则DDP消息有效负载必须在以下时间后发送到ULP：
o Placement of all DDP Segments of this DDP Message and all prior DDP Messages, and
o 放置此DDP消息和所有先前DDP消息的所有DDP段，以及
o Delivery of each prior DDP Message.
o 每个先前DDP消息的传递。
If the Last flag is set to zero, the DDP Segment is an intermediate DDP Segment.
如果最后一个标志设置为零，则DDP段为中间DDP段。
Rsvd - Reserved: 4 bits.
Rsvd-保留：4位。
Reserved for future use by the DDP protocol. This field MUST be set to zero on transmit, and not checked on receive.
保留供DDP协议将来使用。此字段在发送时必须设置为零，在接收时不检查。
DV - Direct Data Placement Protocol Version: 2 bits.
DV-直接数据放置协议版本：2位。
The version of the DDP Protocol in use. This field MUST be set to one to indicate the version of the specification described in this document. The value of DV MUST be the same for all the DDP Segments transmitted or received on a DDP Stream.
正在使用的DDP协议的版本。此字段必须设置为1，以指示本文档中描述的规范版本。对于DDP流上传输或接收的所有DDP段，DV的值必须相同。
Figure 4 shows the DDP Header format that MUST be used in all DDP Segments that target Tagged Buffers. It includes the DDP Control Field previously defined in Section 4.1. (Note: In Figure 4, the DDP Header is offset by 16 bits to accommodate the MPA header defined in [MPA]. The MPA header is only present if DDP is layered on top of MPA.)
图4显示了针对标记缓冲区的所有DDP段中必须使用的DDP头格式。它包括先前在第4.1节中定义的DDP控制字段。（注意：在图4中，DDP头偏移了16位，以容纳[MPA]中定义的MPA头。仅当DDP分层在MPA顶部时，才会出现MPA头。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Rsvd | DV| RsvdULP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TO +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Rsvd | DV| RsvdULP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TO +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Tagged Buffer DDP Header
图4：标记的缓冲区DDP头
T is set to one.
T设置为1。
RsvdULP - Reserved for use by the ULP: 8 bits.
RsvdULP-保留供ULP使用：8位。
The RsvdULP field is opaque to the DDP protocol and can be structured in any way by the ULP. At the Data Source, DDP MUST set RsvdULP Field to the value specified by the ULP. It is transferred unmodified from the Data Source to the Data Sink. At the Data Sink, DDP MUST provide the RsvdULP field to the ULP when the DDP Message is delivered. Each DDP Segment within a specific DDP Message MUST contain the same value for this field. The Data Source MUST ensure that each DDP Segment within a specific DDP Message contains the same value for this field.
RsvdULP字段对于DDP协议是不透明的，可以由ULP以任何方式构造。在数据源，DDP必须将RsvdULP字段设置为ULP指定的值。它未经修改地从数据源传输到数据接收器。在数据接收器，DDP必须在DDP消息传递时向ULP提供RsvdULP字段。特定DDP消息中的每个DDP段必须包含此字段的相同值。数据源必须确保特定DDP消息中的每个DDP段包含此字段的相同值。
STag - Steering Tag: 32 bits.
STag-转向标签：32位。
The Steering Tag identifies the Data Sink's Tagged Buffer. The STag MUST be valid for this DDP Stream. The STag is associated with the DDP Stream through a mechanism that is outside the scope of the DDP Protocol specification. At the Data Source, DDP MUST set the STag field to the value specified by the ULP. At the Data Sink, the DDP MUST provide the STag field when the ULP Message is delivered. Each DDP Segment within a specific DDP Message MUST contain the same value for this field and MUST be the value supplied by the ULP. The Data Source MUST ensure that each DDP Segment within a specific DDP Message contains the same value for this field.
转向标签标识数据接收器的标记缓冲区。STag必须对此DDP流有效。STag通过DDP协议规范范围之外的机制与DDP流相关联。在数据源，DDP必须将STag字段设置为ULP指定的值。在数据接收器，当ULP消息被传递时，DDP必须提供STag字段。特定DDP消息中的每个DDP段必须包含此字段的相同值，并且必须是ULP提供的值。数据源必须确保特定DDP消息中的每个DDP段包含此字段的相同值。
TO - Tagged Offset: 64 bits.
到标记偏移量：64位。
The Tagged Offset specifies the offset, in octets, within the Data Sink's Tagged Buffer, where the Placement of ULP Payload contained in the DDP Segment starts. A DDP Message MAY start at an arbitrary TO within a Tagged Buffer.
标记的偏移量指定数据接收器的标记缓冲区内的偏移量（以八位字节为单位），其中DDP段中包含的ULP有效负载的放置开始。DDP消息可以从标记缓冲区内的任意位置开始。
Figure 5 shows the DDP Header format that MUST be used in all DDP Segments that target Untagged Buffers. It includes the DDP Control Field previously defined in Section 4.1. (Note: In Figure 5, the DDP Header is offset by 16 bits to accommodate the MPA header defined in [MPA]. The MPA header is only present if DDP is layered on top of MPA.)
图5显示了针对未标记缓冲区的所有DDP段中必须使用的DDP头格式。它包括先前在第4.1节中定义的DDP控制字段。（注意：在图5中，DDP头被偏移16位以容纳[MPA]中定义的MPA头。仅当DDP分层在MPA顶部时，才会出现MPA头。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Rsvd | DV| RsvdULP[0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsvdULP[8:39] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MO |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Rsvd | DV| RsvdULP[0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsvdULP[8:39] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MO |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Untagged Buffer DDP Header
图5：未标记的缓冲区DDP头
T is set to zero.
T被设置为零。
RsvdULP - Reserved for use by the ULP: 40 bits.
RsvdULP-保留供ULP使用：40位。
The RsvdULP field is opaque to the DDP protocol and can be structured in any way by the ULP. At the Data Source, DDP MUST set RsvdULP Field to the value specified by the ULP. It is transferred unmodified from the Data Source to the Data Sink. At the Data Sink, DDP MUST provide RsvdULP field to the ULP when the ULP Message is Delivered. Each DDP Segment within a specific DDP Message MUST contain the same value for the RsvdULP field. At the Data Sink, the DDP implementation is NOT REQUIRED to verify that the same value is present in the RsvdULP field of each DDP Segment within a specific DDP Message and MAY provide the value from any one of the received DDP Segment to the ULP when the ULP Message is Delivered.
RsvdULP字段对于DDP协议是不透明的，可以由ULP以任何方式构造。在数据源，DDP必须将RsvdULP字段设置为ULP指定的值。它未经修改地从数据源传输到数据接收器。在数据接收器，当ULP消息被传递时，DDP必须向ULP提供RsvdULP字段。特定DDP消息中的每个DDP段必须包含RsvdULP字段的相同值。在数据接收器，DDP实现不需要验证特定DDP消息中每个DDP段的RsvdULP字段中是否存在相同的值，并且可以在ULP消息传递时，将接收到的DDP段中的任何一个的值提供给ULP。
QN - Queue Number: 32 bits.
QN-队列号：32位。
The Queue Number identifies the Data Sink's Untagged Buffer queue referenced by this header. Each DDP segment within a specific DDP message MUST contain the same value for this field and MUST be the value supplied by the ULP at the Data Source. The Data Source MUST ensure that each DDP Segment within a specific DDP Message contains the same value for this field.
队列号标识此标头引用的数据接收器的未标记缓冲区队列。特定DDP消息中的每个DDP段必须包含此字段的相同值，并且必须是ULP在数据源处提供的值。数据源必须确保特定DDP消息中的每个DDP段包含此字段的相同值。
MSN - Message Sequence Number: 32 bits.
MSN-消息序列号：32位。
The Message Sequence Number specifies a sequence number that MUST be increased by one (modulo 2^32) with each DDP Message targeting the specific Queue Number on the DDP Stream associated with this DDP Segment. The initial value for MSN MUST be one. The MSN value MUST wrap to 0 after a value of 0xFFFFFFFF. Each DDP segment within a specific DDP message MUST contain the same value for this field. The Data Source MUST ensure that each DDP Segment within a specific DDP Message contains the same value for this field.
消息序列号指定一个序列号，该序列号必须增加1（模2^32），每个DDP消息的目标是与此DDP段关联的DDP流上的特定队列号。MSN的初始值必须为1。MSN值必须在0xFFFFFF值之后换行为0。特定DDP消息中的每个DDP段必须包含此字段的相同值。数据源必须确保特定DDP消息中的每个DDP段包含此字段的相同值。
MO - Message Offset: 32 bits.
MO-消息偏移量：32位。
The Message Offset specifies the offset, in octets, from the start of the DDP Message represented by the MSN and Queue Number on the DDP Stream associated with this DDP Segment. The MO referencing the first octet of the DDP Message MUST be set to zero by the DDP layer.
Message Offset（消息偏移量）指定从与此DDP段关联的DDP流上的MSN和队列号表示的DDP消息开始的偏移量（以八位字节为单位）。引用DDP消息第一个八位组的MO必须由DDP层设置为零。
Each DDP Segment MUST contain a DDP Header. Each DDP Segment may also contain ULP Payload. Following is the DDP Segment format:
每个DDP段必须包含一个DDP标头。每个DDP段还可能包含ULP有效载荷。以下是DDP段格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP | |
| Header| ULP Payload (if any) |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP | |
| Header| ULP Payload (if any) |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DDP Segment Format
图6:DDP段格式
DDP supports multi-segment DDP Messages. Each DDP Message is composed of one or more DDP Segments. Each DDP Segment contains a DDP Header. The DDP Header contains the information required by the receiver to Place any ULP Payload included in the DDP Segment.
DDP支持多段DDP消息。每个DDP消息由一个或多个DDP段组成。每个DDP段包含一个DDP标头。DDP报头包含接收机放置DDP段中包含的任何ULP有效载荷所需的信息。
DDP uses two basic buffer models for the Placement of the ULP Payload: Tagged Buffer Model and Untagged Buffer Model.
DDP使用两种基本的缓冲区模型来放置ULP有效负载：标记缓冲区模型和未标记缓冲区模型。
The Tagged Buffer Model is used by the Data Source to transfer a DDP Message into a Tagged Buffer at the Data Sink that has been previously Advertised to the Data Source. An STag identifies a Tagged Buffer. For the Placement of a DDP Message using the Tagged Buffer Model, the STag is used to identify the buffer, and the TO is used to identify the offset within the Tagged Buffer into which the ULP Payload is transferred. The protocol used to Advertise the Tagged Buffer is outside the scope of this specification (i.e., ULP specific). A DDP Message can start at an arbitrary TO within a Tagged Buffer.
数据源使用标记缓冲区模型将DDP消息传输到数据接收器处的标记缓冲区中，该缓冲区先前已通告给数据源。STag标识标记的缓冲区。对于使用标记缓冲区模型放置DDP消息，STag用于识别缓冲区，to用于识别ULP有效负载传输到的标记缓冲区内的偏移量。用于公布标记缓冲区的协议不在本规范的范围内（即ULP特定协议）。DDP消息可以从标记缓冲区内的任意位置开始。
Additionally, a Tagged Buffer can potentially be written multiple times. This might be done for error recovery or because a buffer is being re-used after some ULP specific synchronization mechanism.
此外，标记的缓冲区可能会被写入多次。这样做可能是为了错误恢复，或者是因为在某些特定于ULP的同步机制之后正在重新使用缓冲区。
The Untagged Buffer Model is used by the Data Source to transfer a DDP Message to the Data Sink into a queued buffer.
数据源使用未标记的缓冲区模型将DDP消息传输到数据接收器，并将其传输到队列缓冲区中。
The DDP Queue Number is used by the ULP to separate ULP messages into different queues of receive buffers. For example, if two queues were supported, the ULP could use one queue to post buffers handed to it by the application above the ULP, and it could use the other queue for buffers that are only consumed by ULP-specific control messages. This enables the separation of ULP control messages from opaque ULP Payload when using Untagged Buffers.
ULP使用DDP队列号将ULP消息分离到接收缓冲区的不同队列中。例如，如果支持两个队列，ULP可以使用一个队列发布ULP上方的应用程序交给它的缓冲区，并且可以使用另一个队列发布仅由ULP特定控制消息使用的缓冲区。这使得在使用未标记的缓冲区时，ULP控制消息能够与不透明的ULP有效负载分离。
The DDP Message Sequence Number can be used by the Data Sink to identify the specific Untagged Buffer. The protocol used to communicate how many buffers have been queued is outside the scope of this specification. Similarly, the exact implementation of the buffer queue is outside the scope of this specification.
数据接收器可以使用DDP消息序列号来标识特定的未标记缓冲区。用于通信已排队的缓冲区数量的协议超出了本规范的范围。类似地，缓冲区队列的确切实现不在本规范的范围内。
At the Data Source, the DDP layer MUST segment the data contained in a ULP message into a series of DDP Segments, where each DDP Segment contains a DDP Header and ULP Payload, and MUST be no larger than the MULPDU value Advertised by the LLP. The ULP Message Length MUST be less than 2^32. At the Data Source, the DDP layer MUST send all the data contained in the ULP message. At the Data Sink, the DDP layer MUST Place the ULP Payload contained in all valid incoming DDP Segments associated with a DDP Message into the ULP Buffer.
在数据源处，DDP层必须将ULP消息中包含的数据分段为一系列DDP段，其中每个DDP段包含DDP头和ULP有效负载，并且不得大于LLP公布的MULPDU值。ULP消息长度必须小于2^32。在数据源，DDP层必须发送ULP消息中包含的所有数据。在数据接收器处，DDP层必须将包含在与DDP消息关联的所有有效传入DDP段中的ULP有效负载放入ULP缓冲区。
DDP Message segmentation at the Data Source is accomplished by identifying a DDP Message (which corresponds one-to-one with a ULP Message) uniquely and then, for each associated DDP Segment of a DDP Message, by specifying an octet offset for the portion of the ULP Message contained in the DDP Segment.
通过唯一地识别DDP消息（与ULP消息一一对应），然后针对DDP消息的每个相关DDP段，通过为DDP段中包含的ULP消息部分指定八位字节偏移量，完成数据源处的DDP消息分段。
For an Untagged DDP Message, the combination of the QN and MSN uniquely identifies a DDP Message. The octet offset for each DDP Segment of a Untagged DDP Message is the MO field. For each DDP Segment of a Untagged DDP Message, the MO MUST be set to the octet offset from the first octet in the associated ULP Message (which is defined to be zero) to the first octet in the ULP Payload contained in the DDP Segment.
对于未标记的DDP消息，QN和MSN的组合唯一地标识DDP消息。未标记DDP消息的每个DDP段的八位字节偏移量为MO字段。对于未标记DDP消息的每个DDP段，必须将MO设置为从相关ULP消息中的第一个八位组（定义为零）到DDP段中包含的ULP有效负载中的第一个八位组的八位组偏移量。
For example, if the ULP Untagged Message was 2048 octets, and the MULPDU was 1500 octets, the Data Source would generate two DDP Segments, one with MO = 0, containing 1482 octets of ULP Payload, and a second with MO = 1482, containing 566 octets of ULP Payload. In this example, the amount of ULP Payload for the first DDP Segment was calculated as:
例如，如果ULP未标记消息为2048个八位字节，MULPDU为1500个八位字节，则数据源将生成两个DDP段，一个MO=0，包含1482个八位字节的ULP有效负载，另一个MO=1482，包含566个八位字节的ULP有效负载。在此示例中，第一个DDP段的ULP有效负载量计算为：
1482 = 1500 (MULPDU) - 18 (for the DDP Header)
1482=1500（MULPDU）-18（用于DDP收割台）
For a Tagged DDP Message, the STag and TO, combined with the in-order delivery characteristics of the LLP, are used to segment and reassemble the ULP Message. Because the initial octet offset (the TO field) can be non-zero, recovery of the original ULP Message boundary cannot be done in the general case without an additional ULP Message.
对于带标签的DDP报文，STag和TO与LLP的顺序交付特性相结合，用于分段和重新组装ULP报文。由于初始八位字节偏移量（TO字段）可能为非零，因此在一般情况下，如果没有额外的ULP消息，则无法恢复原始ULP消息边界。
Implementers' note: One implementation, valid for some ULPs such as RDMAP, is to not directly support recovery of the ULP Message boundary for a Tagged DDP Message. For example, the ULP may wish to have the Local Peer use small buffers at the Data Source even when the ULP at the Data Sink has Advertised a single large Tagged Buffer for this data transfer. In this case, the ULP may choose to use the same STag for multiple consecutive ULP Messages. Thus, a non-zero initial TO and re-use of the STag
实施者注意：一个对某些ULP（如RDMAP）有效的实现是不直接支持恢复标记DDP消息的ULP消息边界。例如，ULP可能希望让本地对等方在数据源处使用小缓冲区，即使数据接收器处的ULP已经为该数据传输通告了单个大标记缓冲区。在这种情况下，ULP可以选择对多个连续的ULP消息使用相同的STag。因此，一个非零的STag的初始和重复使用
effectively enable the ULP to implement segmentation and reassembly due to ULP-specific constraints. See [RDMAP] for details of how this is done.
由于ULP特定的约束，有效地使ULP实现分段和重新组装。请参阅[RDMAP]了解如何完成此操作的详细信息。
A different implementation of a ULP could use an Untagged DDP Message (sent after the Tagged DDP Message) that details the initial TO for the STag that was used in the Tagged DDP Message. And finally, another implementation of a ULP could choose to always use an initial TO of zero such that no additional message is required to convey the initial TO used in a Tagged DDP Message.
ULP的不同实现可以使用未标记的DDP消息（在标记的DDP消息之后发送），该消息详细说明标记的DDP消息中使用的STag的初始TO。最后，ULP的另一个实现可以选择始终使用零的初始值，这样就不需要额外的消息来传递标记DDP消息中使用的初始值。
Regardless of whether the ULP chooses to recover the original ULP Message boundary at the Data Sink for a Tagged DDP Message, DDP supports segmentation and reassembly of the Tagged DDP Message. The STag is used to identify the ULP Buffer at the Data Sink, and the TO is used to identify the octet-offset within the ULP Buffer referenced by the STag. The ULP at the Data Source MUST specify the STag and the initial TO when the ULP Message is handed to DDP.
无论ULP是否选择在数据接收器处恢复带标签DDP消息的原始ULP消息边界，DDP都支持带标签DDP消息的分段和重新组装。STag用于标识数据接收器处的ULP缓冲区，to用于标识STag引用的ULP缓冲区内的八位字节偏移量。数据源的ULP必须指定ULP消息传递给DDP时的STag和起始TO。
For each DDP Segment of a Tagged DDP Message, the TO MUST be set to the octet offset from the first octet in the associated ULP Message to the first octet in the ULP Payload contained in the DDP Segment, plus the TO assigned to the first octet in the associated ULP Message.
对于标记的DDP消息的每个DDP段，TO必须设置为从相关ULP消息中的第一个八位组到DDP段中包含的ULP有效负载中的第一个八位组的八位组偏移量，加上分配给相关ULP消息中第一个八位组的TO。
For example, if the ULP Tagged Message was 2048 octets with an initial TO of 16384, and the MULPDU was 1500 octets, the Data Source would generate two DDP Segments: one with TO = 16384, containing the first 1486 octets of ULP payload, and a second with TO = 17870, containing 562 octets of ULP payload. In this example, the amount of ULP payload for the first DDP Segment was calculated as:
例如，如果ULP标记的消息为2048个八位字节，起始TO为16384，MULPDU为1500个八位字节，则数据源将生成两个DDP段：一个TO=16384，包含ULP有效负载的前1486个八位字节；另一个TO=17870，包含ULP有效负载的562个八位字节。在此示例中，第一个DDP段的ULP有效负载量计算为：
1486 = 1500 (MULPDU) - 14 (for the DDP Header)
1486=1500（MULPDU）-14（用于DDP收割台）
A zero-length DDP Message is allowed and MUST consume exactly one DDP Segment. Only the DDP Control and RsvdULP Fields MUST be valid for a zero-length Tagged DDP Segment. The STag and TO fields MUST NOT be checked for a zero-length Tagged DDP Message.
允许使用长度为零的DDP消息，并且必须仅使用一个DDP段。只有DDP控制和RsvdULP字段必须对长度为零的标记DDP段有效。对于长度为零的标记DDP消息，不得检查STag和TO字段。
For either Untagged or Tagged DDP Messages, the Data Sink is not required to verify that the entire ULP Message has been received.
对于未标记或标记的DDP消息，数据接收器无需验证是否已接收到整个ULP消息。
Messages passed through the DDP MUST conform to the ordering rules defined in this section.
通过DDP传递的消息必须符合本节中定义的排序规则。
At the Data Source, DDP:
在数据源，DDP：
* MUST transmit DDP Messages in the order they were submitted to the DDP layer,
* 必须按照提交到DDP层的顺序传输DDP消息，
* SHOULD transmit DDP Segments within a DDP Message in increasing MO order for Untagged DDP Messages, and in increasing TO order for Tagged DDP Messages.
* 对于未标记的DDP消息，应按递增顺序在DDP消息内传输DDP段，对于标记的DDP消息，应按递增顺序在DDP消息内传输DDP段。
At the Data Sink, DDP (Note: The following rules are motivated by LLP implementations that separate Placement and Delivery.):
在数据接收器，DDP（注意：以下规则是由分开放置和交付的LLP实现驱动的）：
* MAY perform Placement of DDP Segments out of order,
* 可能会无序放置DDP段，
* MAY perform Placement of a DDP Segment more than once,
* 可以多次放置DDP段，
* MUST Deliver a DDP Message to the ULP at most once,
* 必须最多向ULP发送一次DDP消息，
* MUST Deliver DDP Messages to the ULP in the order they were sent by the Data Source.
* 必须按照数据源发送的顺序将DDP消息发送到ULP。
At the Data Source, DDP Message transfer is considered completed when the reliable, in-order transport LLP has indicated that the transfer will occur reliably. Note that this in no way restricts the LLP from buffering the data at either the Data Source or Data Sink. Thus, at the Data Source, completion of a DDP Message does not necessarily mean that the Data Sink has received the message.
在数据源，当可靠的顺序传输LLP指示传输将可靠进行时，DDP消息传输被视为已完成。请注意，这并不限制LLP在数据源或数据接收器处缓冲数据。因此，在数据源处，DDP消息的完成并不一定意味着数据接收器已经接收到该消息。
At the Data Sink, DDP MUST Deliver a DDP Message if and only if all of the following are true:
在数据接收器，DDP必须在且仅在以下所有条件均为真时发送DDP消息：
* the last DDP Segment of the DDP Message had its Last flag set,
* DDP消息的最后一个DDP段设置了最后一个标志，
* all of the DDP Segments of the DDP Message have been Placed,
* DDP消息的所有DDP段都已放置，
* all preceding DDP Messages have been Placed, and
* 已放置前面的所有DDP消息，并且
* each preceding DDP Message has been Delivered to the ULP.
* 前面的每条DDP消息都已发送到ULP。
At the Data Sink, DDP MUST provide the ULP Message Length to the ULP when an Untagged DDP Message is Delivered. The ULP Message Length may be calculated by adding the MO and the ULP Payload length in the last DDP Segment (with the Last flag set) of an Untagged DDP Message.
在数据接收器处，当未标记的DDP消息被传递时，DDP必须向ULP提供ULP消息长度。ULP消息长度可以通过将MO和ULP有效负载长度添加到未标记DDP消息的最后一个DDP段（设置了最后一个标志）中来计算。
At the Data Sink, DDP MUST provide the RsvdULP Field of the DDP Message to the ULP when the DDP Message is delivered.
在数据接收器，DDP必须在DDP消息传递时向ULP提供DDP消息的RsvdULP字段。
This section describes LLP independent issues related to DDP Stream setup and teardown.
本节描述与DDP流设置和拆卸相关的LLP独立问题。
It is expected that the ULP will use a mechanism outside the scope of this specification to establish an LLP Connection, and that the LLP Connection will support one or more LLP Streams (e.g., MPA/TCP or SCTP). After the LLP sets up the LLP Stream, it will enable a DDP Stream on a specific LLP Stream at an appropriate point.
预计ULP将使用本规范范围之外的机制来建立LLP连接，并且LLP连接将支持一个或多个LLP流（例如，MPA/TCP或SCTP）。LLP设置LLP流后，将在适当的点启用特定LLP流上的DDP流。
The ULP is required to enable both endpoints of an LLP Stream for DDP data transfer at the same time, in both directions; this is necessary so that the Data Sink can properly recognize the DDP Segments.
ULP需要同时在两个方向上为DDP数据传输启用LLP流的两个端点；这是必要的，以便数据接收器能够正确识别DDP段。
DDP MUST NOT independently initiate Stream Teardown. DDP either responds to a stream being torn down by the LLP or processes a request from the ULP to tear down a stream. DDP Stream teardown disables DDP capabilities on both endpoints. For connection-oriented LLPs, DDP Stream teardown MAY result in underlying LLP Connection teardown.
DDP不得单独启动流拆卸。DDP要么响应LLP中断的流，要么处理ULP中断流的请求。DDP流拆卸在两个端点上禁用DDP功能。对于面向连接的LLP，DDP流断开可能会导致底层LLP连接断开。
It is up to the ULP to ensure that DDP teardown happens on both endpoints of the DDP Stream at the same time; this is necessary so that the Data Sink stops trying to interpret the DDP Segments.
由ULP确保DDP流的两个端点上同时发生DDP拆卸；这是必要的，以便数据接收器停止尝试解释DDP段。
If the Local Peer ULP indicates graceful teardown, the DDP layer on the Local Peer SHOULD ensure that all ULP data would be transferred before the underlying LLP Stream and Connection are torn down, and any further data transfer requests by the Local Peer ULP MUST return an error.
如果本地对等ULP指示正常拆卸，则本地对等上的DDP层应确保在底层LLP流和连接中断之前传输所有ULP数据，并且本地对等ULP的任何进一步数据传输请求必须返回错误。
If the DDP layer on the Local Peer receives a graceful teardown request from the LLP, any further data received after the request is considered an error and MUST cause the DDP Stream to be abortively torn down.
如果本地对等上的DDP层从LLP接收到一个优雅的拆卸请求，则在该请求之后接收到的任何进一步数据都将被视为错误，并且必须导致DDP流被中止拆卸。
If the Local Peer LLP supports a half-closed LLP Stream, on the receipt of an LLP graceful teardown request of the DDP Stream, DDP SHOULD indicate the half-closed state to the ULP, and continue to process outbound data transfer requests normally. Following this event, when the Local Peer ULP requests graceful teardown, DDP MUST indicate to the LLP that it SHOULD perform a graceful close of the other half of the LLP Stream.
如果本地对等LLP支持半关闭的LLP流，则在收到DDP流的LLP优雅拆卸请求时，DDP应向ULP指示半关闭状态，并继续正常处理出站数据传输请求。在此事件之后，当本地对等ULP请求优雅的拆卸时，DDP必须向LLP指示它应该对LLP流的另一半执行优雅的关闭。
If the Local Peer LLP supports a half-closed LLP Stream, on the receipt of a ULP graceful half-closed teardown request of the DDP Stream, DDP SHOULD keep data reception enabled on the other half of the LLP Stream.
如果本地对等LLP支持半封闭LLP流，则在接收到DDP流的ULP半封闭拆卸请求时，DDP应在LLP流的另一半上保持启用数据接收。
As previously mentioned, DDP does not independently terminate a DDP Stream. Thus, any of the following fatal errors on a DDP Stream MUST cause DDP to indicate to the ULP that a fatal error has occurred:
如前所述，DDP不会独立终止DDP流。因此，DDP流上的以下任何致命错误都必须导致DDP向ULP指示发生了致命错误：
* Underlying LLP Connection or LLP Stream is lost.
* 基础LLP连接或LLP流丢失。
* Underlying LLP reports a fatal error.
* 底层LLP报告一个致命错误。
* DDP Header has one or more invalid fields.
* DDP标头有一个或多个无效字段。
If the LLP indicates to the ULP that a fatal error has occurred, the DDP layer SHOULD report the error to the ULP (see Section 7.2, DDP Error Numbers) and complete all outstanding ULP requests with an error. If the underlying LLP Stream is still intact, DDP SHOULD continue to allow the ULP to transfer additional DDP Messages on the outgoing half connection after the fatal error was indicated to the ULP. This enables the ULP to transfer an error syndrome to the Remote Peer. After indicating to the ULP a fatal error has occurred, the DDP Stream MUST NOT be terminated until the Local Peer ULP indicates to the DDP layer that the DDP Stream should be abortively torn down.
如果LLP向ULP指示发生了致命错误，DDP层应向ULP报告该错误（请参阅第7.2节，DDP错误编号），并完成所有未完成的ULP请求，并显示错误。如果基础LLP流仍然完好无损，则在向ULP指示致命错误后，DDP应继续允许ULP在传出的半连接上传输额外的DDP消息。这使ULP能够将错误综合征传输到远程对等方。在向ULP指示发生致命错误后，在本地对等ULP向DDP层指示DDP流应被中止之前，不得终止DDP流。
All LLP errors reported to DDP SHOULD be passed up to the ULP.
所有报告给DDP的LLP错误都应传递给ULP。
For non-zero-length Untagged DDP Segments, the DDP Segment MUST be validated before Placement by verifying:
对于非零长度未标记的DDP段，必须在放置前验证DDP段，方法是验证：
1. The QN is valid for this stream.
1. QN对此流有效。
2. The QN and MSN have an associated buffer that allows Placement of the payload.
2. QN和MSN有一个相关的缓冲区，允许放置有效负载。
Implementers' note: DDP implementations SHOULD consider lack of an associated buffer as a system fault. DDP implementations MAY try to recover from the system fault using LLP means in a ULP-transparent way. DDP implementations SHOULD NOT permit system faults to occur repeatedly or frequently. If there is not an associated buffer, DDP implementations MAY choose to disable the stream for the reception and report an error to the ULP at the Data Sink.
实施者注意：DDP实现应该考虑缺少一个相关的缓冲区作为系统故障。DDP实现可以尝试以ULP透明的方式使用LLP手段从系统故障中恢复。DDP实施不应允许系统故障重复或频繁发生。如果没有相关的缓冲区，DDP实现可以选择禁用接收流，并向数据接收器处的ULP报告错误。
3. The MO falls in the range of legal offsets associated with the Untagged Buffer.
3. MO落在与未标记缓冲区相关的法定偏移范围内。
4. The sum of the DDP Segment payload length and the MO falls in the range of legal offsets associated with the Untagged Buffer.
4. DDP段有效负载长度和MO之和落在与未标记缓冲区相关的法定偏移范围内。
5. The Message Sequence Number falls in the range of legal Message Sequence Numbers, for the queue defined by the QN. The legal range is defined as being between the MSN value assigned to the first available buffer for a specific QN and the MSN value assigned to the last available buffer for a specific QN.
5. 对于QN定义的队列，消息序列号在合法消息序列号的范围内。法定范围定义为指定QN的第一个可用缓冲区的MSN值与指定QN的最后一个可用缓冲区的MSN值之间的范围。
Implementers' note: for a typical Queue Number, the lower limit of the Message Sequence Number is defined by whatever DDP Messages have already been completed. The upper limit is defined by however many message buffers are currently available for that queue. Both numbers change dynamically as new DDP Messages are received and completed, and new buffers are added. It is up to the ULP to ensure that sufficient buffers are available to handle the incoming DDP Segments.
实施者注意：对于典型的队列号，消息序列号的下限由已经完成的DDP消息定义。上限由该队列当前可用的消息缓冲区数量定义。这两个数字随着新DDP消息的接收和完成以及新缓冲区的添加而动态变化。由ULP确保有足够的缓冲区来处理传入的DDP段。
For non-zero-length Tagged DDP Segments, the segment MUST be validated before Placement by verifying:
对于非零长度标记的DDP段，必须在放置前验证该段，方法是验证：
1. The STag is valid for this stream.
1. STag对该流有效。
2. The STag has an associated buffer that allows Placement of the payload.
2. STag有一个相关的缓冲区，允许放置有效负载。
3. The TO falls in the range of legal offsets registered for the STag.
3. TO在为STag登记的法定补偿范围内。
4. The sum of the DDP Segment payload length and the TO falls in the range of legal offsets registered for the STag.
4. DDP段有效负载长度和TO的总和在STag注册的合法偏移范围内。
5. A 64-bit unsigned sum of the DDP Segment payload length and the TO does not wrap.
5. DDP段有效负载长度和TO的64位无符号和不换行。
If the DDP layer detects any of the receive errors listed in this section, it MUST cease placing the remainder of the DDP Segment and report the error(s) to the ULP. The DDP layer SHOULD include in the error report the DDP Header, the type of error, and the length of the DDP segment, if available. DDP MUST silently drop any subsequent incoming DDP Segments. Since each of these errors represents a failure of the sending ULP or protocol, DDP SHOULD enable the ULP to send one additional DDP Message before terminating the DDP Stream.
如果DDP层检测到本节中列出的任何接收错误，则必须停止放置DDP段的其余部分，并向ULP报告错误。DDP层应在错误报告中包括DDP头、错误类型和DDP段的长度（如果可用）。DDP必须以静默方式删除任何后续传入的DDP段。由于这些错误中的每一个都表示发送ULP或协议失败，DDP应使ULP能够在终止DDP流之前发送一条额外的DDP消息。
The following error numbers MUST be used when reporting errors to the ULP. They correspond to the checks enumerated in section 7.1. Each error is subdivided into a 4-bit Error Type and an 8-bit Error Code.
向ULP报告错误时，必须使用以下错误编号。它们对应于第7.1节中列举的检查。每个错误细分为4位错误类型和8位错误代码。
Error Error
Type Code Description
----------------------------------------------------------
0x0 0x00 Local Catastrophic
Error Error
Type Code Description
----------------------------------------------------------
0x0 0x00 Local Catastrophic
0x1 Tagged Buffer Error 0x00 Invalid STag 0x01 Base or bounds violation 0x02 STag not associated with DDP Stream 0x03 TO wrap 0x04 Invalid DDP version
0x1标记的缓冲区错误0x00无效STag 0x01基本或边界冲突0x02 STag未与DDP流0x03关联以包装0x04无效DDP版本
0x2 Untagged Buffer Error 0x01 Invalid QN 0x02 Invalid MSN - no buffer available 0x03 Invalid MSN - MSN range is not valid 0x04 Invalid MO 0x05 DDP Message too long for available buffer 0x06 Invalid DDP version
0x2未标记缓冲区错误0x01无效QN 0x02无效MSN-无可用缓冲区0x03无效MSN-MSN范围无效0x04无效MO 0x05 DDP消息对于可用缓冲区0x06无效DDP版本太长
0x3 Rsvd Reserved for the use by the LLP
0x3 Rsvd保留供LLP使用
This section discusses both protocol-specific considerations and the implications of using DDP with existing security mechanisms. The security requirements for the DDP implementation are provided at the end of the section. A more detailed analysis of the security issues around the implementation and the use of the DDP can be found in [RDMASEC].
本节讨论特定于协议的注意事项以及在现有安全机制中使用DDP的含义。本节末尾提供了DDP实施的安全要求。关于DDP实施和使用的安全问题的更详细分析，请参见[RDMASEC]。
The IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [IPSEC] and related RFCs, as profiled by RFC 3723 [RFC3723], despite the existence of a newer version of IPsec specified in RFC 4301 [RFC4301] and related RFCs [RFC4303], [RFC4306]. One of the important early applications of the RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec requirements follow those of IPsec in order to facilitate that usage by allowing a common profile of IPsec to be used with iSCSI and the RDDP protocols. In the future, RFC 3723 may be updated to the newer version of IPsec; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RDDP的IPsec要求基于RFC 2401[IPsec]和相关RFC中规定的IPsec版本，如RFC 3723[RFC3723]所述，尽管存在RFC 4301[RFC4301]和相关RFC[RFC4303]、[RFC4306]中规定的较新版本的IPsec。RDDP协议的一个重要早期应用是与iSCSI[iSER]一起使用；RDDP的IPsec要求遵循IPsec的要求，以便通过允许将IPsec的公共配置文件与iSCSI和RDDP协议一起使用来促进这种使用。将来，RFC 3723可能会更新到IPsec的较新版本；任何此类更新的IPsec安全要求都应统一适用于iSCSI和RDDP协议。
The vulnerabilities of DDP to active third-party interference are no greater than any other protocol running over transport protocols such as TCP and SCTP over IP. A third party, by injecting spoofed packets into the network that are Delivered to a DDP Data Sink, could launch a variety of attacks that exploit DDP-specific behavior. Since DDP directly or indirectly exposes memory addresses on the wire, the Placement information carried in each DDP Segment must be validated, including invalid STag and octet-level granularity base and bounds check, before any data is Placed. For example, a third-party adversary could inject random packets that appear to be valid DDP Segments and corrupt the memory on a DDP Data Sink. Since DDP is IP transport protocol independent, communication security mechanisms such as IPsec [IPSEC] may be used to prevent such attacks.
DDP对主动第三方干扰的脆弱性不比通过传输协议（如TCP和SCTP over IP）运行的任何其他协议大。第三方通过向网络中注入发送到DDP数据接收器的伪造数据包，可以发动各种攻击，利用DDP特定的行为。由于DDP直接或间接地公开线路上的内存地址，因此在放置任何数据之前，必须验证每个DDP段中携带的放置信息，包括无效的STag和八位元级粒度基数和边界检查。例如，第三方对手可能会注入看似有效DDP段的随机数据包，并损坏DDP数据接收器上的内存。由于DDP是独立于IP传输协议的，因此可以使用诸如IPsec[IPsec]之类的通信安全机制来防止此类攻击。
There are several mechanisms for associating an STag and a DDP Stream. Two required mechanisms for this association are a Protection Domain (PD) association and a DDP Stream association.
有几种机制将STag和DDP流关联起来。此关联所需的两种机制是保护域（PD）关联和DDP流关联。
Under the Protection Domain (PD) association, a unique Protection Domain Identifier (PD ID) is created and used locally to associate an STag with a set of DDP Streams. Under this mechanism, the use of the STag is only permitted on the DDP Streams that have the same PD ID as the STag. For an incoming DDP Segment of a Tagged DDP Message on a
在保护域（PD）关联下，将创建唯一的保护域标识符（PD ID），并在本地使用该标识符将STag与一组DDP流关联。在该机制下，仅允许在与STag具有相同PD ID的DDP流上使用STag。用于网络上已标记DDP消息的传入DDP段
DDP Stream, if the PD ID of the DDP Stream is not the same as the PD ID of the STag targeted by the Tagged DDP Message, then the DDP Segment is not Placed, and the DDP layer MUST surface a local error to the ULP. Note that the PD ID is locally defined and cannot be directly manipulated by the Remote Peer.
DDP流，如果DDP流的PD ID与标记的DDP消息所针对的STag的PD ID不同，则不放置DDP段，并且DDP层必须向ULP显示本地错误。请注意，PD ID是本地定义的，不能由远程对等方直接操作。
Under the DDP Stream association, a DDP Stream is identified locally by a unique DDP Stream identifier (ID). An STag is associated with a DDP Stream by using a DDP Stream ID. In this case, for an incoming DDP Segment of a Tagged DDP Message on a DDP Stream, if the DDP Stream ID of the DDP Stream is not the same as the DDP Stream ID of the STag targeted by the Tagged DDP Message, then the DDP Segment is not Placed and the DDP layer MUST surface a local error to the ULP. Note that the DDP Stream ID is locally defined and cannot be directly manipulated by the Remote Peer.
在DDP流关联下，DDP流由唯一的DDP流标识符（ID）在本地标识。STag通过使用DDP流ID与DDP流相关联。在这种情况下，对于DDP流上标记的DDP消息的传入DDP段，如果DDP流的DDP流ID与标记的DDP消息所针对的STag的DDP流ID不同，然后不放置DDP段，DDP层必须向ULP显示局部错误。请注意，DDP流ID是本地定义的，不能由远程对等方直接操作。
A ULP SHOULD associate an STag with at least one DDP Stream. DDP MUST support Protection Domain association and DDP Stream association mechanisms for associating an STag and a DDP Stream.
ULP应将STag与至少一个DDP流相关联。DDP必须支持保护域关联和DDP流关联机制，以关联STag和DDP流。
[RDMASEC] defines the security model and general assumptions for RDMAP/DDP. This subsection provides the security requirements for the DDP implementation. For more details on the type of attacks, type of attackers, trust models, and resource sharing for the DDP implementation, the reader is referred to [RDMASEC].
[RDMASEC]定义了RDMAP/DDP的安全模型和一般假设。本小节规定了DDP实施的安全要求。有关DDP实现的攻击类型、攻击者类型、信任模型和资源共享的更多详细信息，请参阅[RDMASEC]。
DDP has several mechanisms that deal with a number of attacks. These attacks include, but are not limited to:
DDP有几种机制来处理一些攻击。这些攻击包括但不限于：
1. Connection to/from an unauthorized or unauthenticated endpoint. 2. Hijacking of a DDP Stream. 3. Attempts to read or write from unauthorized memory regions. 4. Injection of RDMA Messages within a stream on a multi-user operating system by another application.
1. 与未经授权或未经验证的端点的连接。2.劫持DDP流。3.尝试从未经授权的内存区域读取或写入。4.另一个应用程序在多用户操作系统的流中注入RDMA消息。
DDP relies on the LLP to establish the LLP Stream over which DDP Messages will be carried. DDP itself does nothing to authenticate the validity of the LLP Stream of either of the endpoints. It is the responsibility of the ULP to validate the LLP Stream. This is highly desirable due to the nature of DDP.
DDP依赖LLP建立LLP流，DDP消息将通过该流进行传输。DDP本身不验证任一端点的LLP流的有效性。ULP负责验证LLP流。由于DDP的性质，这是非常可取的。
Hijacking of an DDP Stream would require that the underlying LLP Stream is hijacked. This would require knowledge of Advertised Buffers in order to directly Place data into a user buffer. Therefore, this is constrained by the same techniques mentioned to guard against attempts to read or write from unauthorized memory regions.
劫持DDP流需要劫持底层LLP流。这需要了解广告缓冲区，以便直接将数据放入用户缓冲区。因此，这受到上述相同技术的限制，以防止尝试从未经授权的内存区域读取或写入。
DDP does not require a node to open its buffers to arbitrary attacks over the DDP Stream. It may access ULP memory only to the extent that the ULP has enabled and authorized it to do so. The STag access control model is defined in [RDMASEC]. Specific security operations include:
DDP不需要节点打开其缓冲区以抵御DDP流上的任意攻击。它只能在ULP已启用并授权的范围内访问ULP内存。STag访问控制模型在[RDMASEC]中定义。具体的安全行动包括：
1. STags are only valid over the exact byte range established by the ULP. DDP MUST provide a mechanism for the ULP to establish and revoke the TO range associated with the ULP Buffer referenced by the STag. 2. STags are only valid for the duration established by the ULP. The ULP may revoke them at any time, in accordance with its own upper layer protocol requirements. DDP MUST provide a mechanism for the ULP to establish and revoke STag validity. 3. DDP MUST provide a mechanism for the ULP to communicate the association between a STag and a specific DDP Stream. 4. A ULP may only expose memory to remote access to the extent that it already had access to that memory itself. 5. If an STag is not valid on a DDP Stream, DDP MUST pass the invalid access attempt to the ULP. The ULP may provide a mechanism for terminating the DDP Stream.
1. STAG仅在ULP建立的确切字节范围内有效。DDP必须为ULP提供一种机制，以建立和撤销与STag引用的ULP缓冲区相关联的to范围。2.STAG仅在ULP确定的期限内有效。ULP可根据其自身的上层协议要求随时撤销这些协议。DDP必须为ULP提供建立和撤销STag有效性的机制。3.DDP必须为ULP提供一种机制，以传递STag和特定DDP流之间的关联。4.ULP只能将内存暴露给远程访问，直到它本身已经可以访问该内存为止。5.如果STag在DDP流上无效，DDP必须将无效访问尝试传递给ULP。ULP可提供用于终止DDP流的机制。
Further, DDP provides a mechanism that directly Places incoming payloads in user-mode ULP Buffers. This avoids the risks of prior solutions that relied upon exposing system buffers for incoming payloads.
此外，DDP提供了一种机制，可以直接将传入的有效负载放置在用户模式ULP缓冲区中。这避免了以前的解决方案依赖于为传入有效负载公开系统缓冲区的风险。
For the DDP implementation, two components MUST be provided: an RDMA-enabled NIC (RNIC) and a Privileged Resource Manager (PRM).
对于DDP实现，必须提供两个组件：支持RDMA的NIC（RNIC）和特权资源管理器（PRM）。
The RNIC MUST implement the DDP wire Protocol and perform the security semantics described below.
RNIC必须实现DDP wire协议并执行以下描述的安全语义。
1. An RNIC MUST ensure that a specific DDP Stream in a specific Protection Domain cannot access an STag in a different Protection Domain.
1. RNIC必须确保特定保护域中的特定DDP流不能访问不同保护域中的STag。
2. An RNIC MUST ensure that if an STag is limited in scope to a single DDP Stream, no other DDP Stream can use the STag.
2. RNIC必须确保，如果STag的作用域限于单个DDP流，则其他DDP流不能使用该STag。
3. An RNIC MUST ensure that a Remote Peer is not able to access memory outside the buffer specified when the STag was enabled for remote access.
3. RNIC必须确保远程对等方无法访问STag启用远程访问时指定的缓冲区之外的内存。
4. An RNIC MUST provide a mechanism for the ULP to establish and revoke the association of a ULP Buffer to an STag and TO range.
4. RNIC必须为ULP提供一种机制，以建立和撤销ULP缓冲区与STag和范围的关联。
5. An RNIC MUST provide a mechanism for the ULP to establish and revoke read, write, or read and write access to the ULP Buffer referenced by an STag.
5. RNIC必须为ULP提供一种机制，以建立和撤销对STag引用的ULP缓冲区的读、写或读写访问。
6. An RNIC MUST ensure that the network interface can no longer modify an Advertised Buffer after the ULP revokes remote access rights for an STag.
6. RNIC必须确保ULP撤销STag的远程访问权限后，网络接口不能再修改播发缓冲区。
7. An RNIC MUST NOT enable firmware to be loaded on the RNIC directly from an untrusted Local Peer or Remote Peer, unless the Peer is properly authenticated (by a mechanism outside the scope of this specification. The mechanism presumably entails authenticating that the remote ULP has the right to perform the update), and the update is done via a secure protocol, such as IPsec.
7. RNIC不得允许固件直接从不受信任的本地对等方或远程对等方加载到RNIC上，除非对等方经过适当的身份验证（通过本规范范围外的机制。该机制可能需要验证远程ULP有权执行更新），更新是通过一个安全协议完成的，比如IPsec。
The PRM MUST implement the security semantics described below.
PRM必须实现下面描述的安全语义。
1. All Non-Privileged ULP interactions with the RNIC Engine that could affect other ULPs MUST be done using the Privileged Resource Manager as a proxy.
1. 所有可能影响其他ULP的与RNIC引擎的非特权ULP交互必须使用特权资源管理器作为代理来完成。
2. All ULP resource allocation requests for scarce resources MUST also be done using a Privileged Resource Manager.
2. 稀缺资源的所有ULP资源分配请求也必须使用特权资源管理器完成。
3. The Privileged Resource Manager MUST NOT assume different ULPs share Partial Mutual Trust unless there is a mechanism to ensure that the ULPs do indeed share partial mutual trust.
3. 特权资源管理器不得假定不同的ULP共享部分互信，除非有机制确保ULP确实共享部分互信。
4. If Non-Privileged ULPs are supported, the Privileged Resource Manager MUST verify that the Non-Privileged ULP has the right to access a specific Data Buffer before allowing an STag for which the ULP has access rights to be associated with a specific Data Buffer.
4. 如果支持非特权ULP，特权资源管理器必须验证非特权ULP有权访问特定数据缓冲区，然后才能允许ULP有权访问的STag与特定数据缓冲区关联。
5. The Privileged Resource Manager SHOULD prevent a Local Peer from allocating more than its fair share of resources. If an RNIC provides the ability to share receive buffers across multiple DDP Streams, the combination of the RNIC and the Privileged Resource
5. 特权资源管理器应防止本地对等方分配超过其公平份额的资源。如果RNIC提供跨多个DDP流共享接收缓冲区的能力，则RNIC和特权资源的组合
Manager MUST be able to detect if the Remote Peer is attempting to consume more than its fair share of resources so that the Local Peer can apply countermeasures to detect and prevent the attack.
Manager必须能够检测远程对等方是否试图消耗超过其公平份额的资源，以便本地对等方可以应用对策来检测和防止攻击。
DDP uses IP-based network services; therefore, all exchanged DDP Segments are vulnerable to spoofing, tampering and information disclosure attacks. If a DDP Stream may be subject to impersonation attacks, or stream hijacking attacks, it is highly RECOMMENDED that the DDP Stream be authenticated, integrity protected, and protected from replay attacks. It MAY use confidentiality protection to protect from eavesdropping.
DDP使用基于IP的网络服务；因此，所有交换的DDP段都容易受到欺骗、篡改和信息泄露攻击。如果DDP流可能受到模拟攻击或流劫持攻击，强烈建议对DDP流进行身份验证、完整性保护并防止重播攻击。它可以使用保密保护来防止窃听。
IPsec can be used to protect against the packet injection attacks outlined above. Because IPsec is designed to secure arbitrary IP packet streams, including streams where packets are lost, DDP can run on top of IPsec without any change.
IPsec可用于防止上述数据包注入攻击。由于IPsec设计用于保护任意IP数据包流，包括数据包丢失的数据流，因此DDP可以在IPsec上运行而无需任何更改。
DDP security may also profit from SSL or TLS security services provided for TCP or SCTP based ULPs [TLS] as well as from DTLS [DTLS] security services provided beneath the transport protocol. See [RDMASEC] for further discussion of these approaches and the rationale for selection of IPsec security services for the RDDP protocols.
DDP安全还可以从为基于TCP或SCTP的ULP[TLS]提供的SSL或TLS安全服务以及在传输协议下提供的DTLS[DTLS]安全服务中获益。有关这些方法的进一步讨论以及为RDDP协议选择IPsec安全服务的基本原理，请参见[RDMASEC]。
IPsec packets are processed (e.g., integrity checked and possibly decrypted) in the order they are received, and a DDP Data Sink will process the decrypted DDP Segments contained in these packets in the same manner as DDP Segments contained in unsecured IP packets.
IPsec数据包按照接收顺序进行处理（例如，完整性检查并可能解密），DDP数据接收器将以与不安全IP数据包中包含的DDP段相同的方式处理这些数据包中包含的解密DDP段。
The IP Storage working group has defined the normative IPsec requirements for IP Storage [RFC3723]. Portions of this specification are applicable to the DDP. In particular, a compliant implementation of IPsec services MUST meet the requirements as outlined in Section 2.3 of [RFC3723]. Without replicating the detailed discussion in [RFC3723], this includes the following requirements:
IP存储工作组定义了IP存储的标准IPsec要求[RFC3723]。本规范的部分内容适用于DDP。特别是，IPsec服务的兼容实现必须满足[RFC3723]第2.3节中概述的要求。在不复制[RFC3723]中的详细讨论的情况下，这包括以下要求：
1. The implementation MUST support IPsec ESP [RFC2406], as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
1. 实现必须支持IPsec ESP[RFC2406]，以及IPsec的重播保护机制。使用ESP时，必须使用每包数据源身份验证、完整性和重播保护。
2. It MUST support ESP in tunnel mode and MAY implement ESP in transport mode.
2. 它必须在隧道模式下支持ESP，并且可以在传输模式下实施ESP。
3. It MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407].
3. 它必须支持IKE[RFC2409]，以便使用IPsec DOI[RFC2407]进行对等身份验证、安全关联协商和密钥管理。
4. It MUST NOT interpret the receipt of an IKE delete message as a reason for tearing down the DDP stream. Since IPsec acceleration hardware may only be able to handle a limited number of active IPsec Security Associations (SAs), idle SAs may be dynamically brought down and a new SA be brought up again, if activity resumes.
4. 它不能将收到IKE delete消息解释为中断DDP流的原因。由于IPsec加速硬件可能只能处理有限数量的活动IPsec安全关联（SA），因此如果活动继续，空闲SA可能会动态关闭，并重新启动新SA。
5. It MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods [RFC2409] SHOULD NOT be used.
5. 它必须支持使用预共享密钥的对等身份验证，并且可能支持使用数字签名的基于证书的对等身份验证。不应使用使用公钥加密方法[RFC2409]的对等身份验证。
6. It MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers uses a dynamically assigned IP address.
6. 它必须支持IKE主模式，并且应该支持攻击模式。当任一对等方使用动态分配的IP地址时，不应使用带有预共享密钥身份验证的IKE主模式。
7. Access to locally stored secret information (pre-shared or private key for digital signing) must be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
7. 必须适当限制对本地存储的秘密信息（用于数字签名的预共享或私钥）的访问，因为泄露秘密信息会使IKE/IPsec协议的安全属性无效。
8. It MUST follow the guidelines of Section 2.3.4 of [RFC3723] on the setting of IKE parameters to achieve a high level of interoperability without requiring extensive configuration.
8. 它必须遵循[RFC3723]第2.3.4节关于IKE参数设置的指南，以实现高水平的互操作性，而无需大量配置。
Furthermore, implementation and deployment of the IPsec services for DDP should follow the Security Considerations outlined in Section 5 of [RFC3723].
此外，DDP IPsec服务的实施和部署应遵循[RFC3723]第5节中概述的安全注意事项。
This document requests no direct action from IANA. The following consideration is listed here as commentary.
本文件不要求IANA采取直接行动。以下考虑事项列为评注。
If DDP were enabled a priori for a ULP by connecting to a well-known port, this well-known port would be registered for the DDP with IANA. The registration of the well-known port would be the responsibility of the ULP specification.
如果通过连接到一个已知端口为ULP预先启用了DDP，则该已知端口将向IANA注册DDP。著名港口的注册将由ULP规范负责。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和Atkinson，R.，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和Carrel，D.，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., Travostino, F., "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，Travostino，F.，“通过IP保护块存储协议”，RFC 37232004年4月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[MPA] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007.
[MPA]Culley，P.，Elzur，U.，Recio，R.，Bailey，S.，和J.Carrier，“TCP规范的标记PDU对齐框架”，RFC 5044，2007年10月。
[RDMAP] Recio, R., Culley, P., Garcia, D., and J. Hilland, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RDMAP]Recio，R.，Culley，P.，Garcia，D.，和J.Hilland，“远程直接内存访问协议规范”，RFC 50402007年10月。
[RDMASEC] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RDMASEC]Pinkerton，J.和E.Deleganes，“直接数据放置协议（DDP）/远程直接内存访问协议（RDMAP）安全”，RFC 50422007年10月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[SCTPDDP] Bestler, C. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, October 2007.
[SCTPDDP]Bestler，C.和R.Stewart，“流控制传输协议（SCTP）直接数据放置（DDP）自适应”，RFC 50432007年10月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[iSER]Ko，M.，Chadalapaka，M.，Hufferd，J.，Elzur，U.，Shah，H.，和P.Thaler，“用于远程直接内存访问（RDMA）的互联网小型计算机系统接口（iSCSI）扩展”，RFC 50462007年10月。
This appendix provides guidance to LLP implementers.
本附录为LLP实施者提供指导。
Reliable, sequenced, LLPs include a mechanism to Advertise the amount of receive buffer space a sender may consume. This is generally called a "receive window".
可靠、有序的LLP包括一种机制，用于公布发送方可能消耗的接收缓冲区空间量。这通常称为“接收窗口”。
DDP allows data to be transferred directly to predefined buffers at the Data Sink. Accordingly, the LLP receive window size need not be affected by the reception of a DDP Segment, if that segment is placed before additional segments arrive.
DDP允许数据直接传输到数据接收器的预定义缓冲区。因此，如果在附加段到达之前放置了DDP段，则LLP接收窗口大小不需要受到DDP段的接收的影响。
The LLP implementation SHOULD maintain an Advertised receive window large enough to enable a reasonable number of segments to be outstanding at one time. The amount to Advertise depends on the desired data rate, and the expected or actual round-trip delay between endpoints.
LLP实施应保持一个足够大的广告接收窗口，以允许一次有合理数量的段处于未完成状态。播发量取决于所需的数据速率以及端点之间的预期或实际往返延迟。
The amount of actual buffers maintained to "back up" the receive window is left up to the implementation. This amount will depend on the rate that DDP Segments can be retired; there may be some cases where segment processing cannot keep up with the incoming packet rate. If this occurs, one reasonable way to slow the incoming packet rate is to reduce the receive window.
为“备份”接收窗口而维护的实际缓冲区数量由实现决定。这一数额将取决于DDP段的退役率；在某些情况下，段处理可能无法跟上传入的数据包速率。如果发生这种情况，降低传入数据包速率的一个合理方法是减少接收窗口。
Note that the LLP should take care to comply with the applicable RFCs; for instance, for TCP, receivers are highly discouraged from "shrinking" the receive window (reducing the right edge of the window after it has been Advertised).
请注意，有限责任合伙企业应注意遵守适用的RFC；例如，对于TCP，强烈建议接收者不要“缩小”接收窗口（在播发后缩小窗口的右边缘）。
Many thanks to the following individuals for their contributions.
非常感谢以下个人的贡献。
John Carrier Cray Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 Phone: 206-701-2090 EMail: carrier@cray.com
John Carrier Cray Inc.华盛顿州西雅图第一大道S 411号600室98104-2860电话：206-701-2090电子邮件：carrier@cray.com
Hari Ghadia Gen10 Technology, Inc. 1501 W Shady Grove Road Grand Prairie, TX 75050 Phone: (972) 301 3630 EMail: hghadia@gen10technology.com
Hari Ghadia Gen10 Technology，Inc.德克萨斯州大草原Shady Grove路西1501号75050电话：（972）301 3630电子邮件：hghadia@gen10technology.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-6383 EMail: caitlinb@Broadcom.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine，CA 92619-7013美国电话：+1（949）926-6383电子邮件：caitlinb@Broadcom.com
Uri Elzur Broadcom Corporation 5300 California Avenue Irvine, CA 92617, USA Phone: 949.926.6432 EMail: uri@broadcom.com
Uri Elzur Broadcom Corporation美国加利福尼亚州欧文市加利福尼亚大道5300号92617电话：949.926.6432电子邮件：uri@broadcom.com
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-7149 EMail: MPenna@Broadcom.com
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine，CA 92619-7013美国电话：+1（949）926-7149电子邮件：MPenna@Broadcom.com
Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-8635 EMail: pthaler@broadcom.com
Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine，CA 92619-7013美国电话：+1（949）926-8635电子邮件：pthaler@broadcom.com
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: +1 (919) 248-6075 EMail: compton_ted@emc.com
泰德·康普顿美国北卡罗来纳州三角研究园EMC公司电话：+1（919）248-6075电子邮件：康普顿_ted@emc.com
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard Roseville, CA 95747-5668 USA Phone: +1 (916) 785-5198 EMail: jim_wendt@hp.com
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard Roseville，CA 95747-5668美国电话：+1（916）785-5198电子邮件：Jim_wendt@hp.com
Mike Krause Hewlett-Packard Company, 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: +1 (408) 447-3191 EMail: krause@cup.hp.com
Mike Krause Hewlett-Packard Company，地址：美国加利福尼亚州库比蒂诺市霍姆斯特德路19410号，邮编：95014电话：+1（408）447-3191电子邮件：krause@cup.hp.com
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro, OR 97124 USA Phone: +1 (503) 712-4106 EMail: dave.b.minturn@intel.com
Dave Minturn Intel Corporation MS JF1-210 5200东北Elam Young Parkway Hillsboro，或97124美国电话：+1（503）712-4106电子邮件：Dave.b。minturn@intel.com
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, AZ 85226 USA Phone: +1 (480) 554-3116 EMail: howard.c.herbert@intel.com
霍华德C.赫伯特英特尔公司MS CH7-404 5000西钱德勒大道。美国亚利桑那州钱德勒85226电话：+1（480）554-3116电子邮件：howard.c。herbert@intel.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
Tom Talpey Network Appliance 1601 Trapelo Road#16 Waltham，MA 02451美国电话：+1（781）768-5329电子邮件：thomas。talpey@netapp.com
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-2769 EMail: Dwight.Barron@Hp.com
德怀特·巴伦·惠普公司20555 SH 249德克萨斯州休斯顿77070-2698美国电话：+1（281）514-2769电子邮件：德怀特。Barron@Hp.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 USA Phone: +1 (831) 247-4464 Email: Dave.Garcia@StanfordAlumni.org
戴夫·加西亚美国加利福尼亚州洛斯加托斯哈钦森路24100号电话：+1（831）247-4464电子邮件：戴夫。Garcia@StanfordAlumni.org
Jeff Hilland Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-9489 EMail: jeff.hilland@hp.com
杰夫·希尔兰·惠普公司20555 SH 249德克萨斯州休斯顿77070-2698美国电话：+1（281）514-9489电子邮件：杰夫。hilland@hp.com
Barry Reinhold Lamprey Networks Durham, NH 03824 USA Phone: +1 (603) 868-8411 EMail: bbr@LampreyNetworks.com
Barry Reinhold Lamprey Networks Durham，NH 03824美国电话：+1（603）868-8411电子邮件：bbr@LampreyNetworks.com
Authors' Addresses
作者地址
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
Hemal Shah Broadcom Corporation美国加利福尼亚州欧文市加利福尼亚大道5300号92617电话：+1（949）926-6941电子邮件：hemal@broadcom.com
James Pinkerton Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 (425) 705-5442 EMail: jpink@microsoft.com
James Pinkerton Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电话：+1（425）705-5442电子邮件：jpink@microsoft.com
Renato Recio IBM Corporation 11501 Burnett Road Austin, TX 78758 USA Phone: +1 (512) 838-1365 EMail: recio@us.ibm.com
Renato Recio IBM Corporation美国德克萨斯州奥斯汀伯内特路11501号78758电话：+1（512）838-1365电子邮件：recio@us.ibm.com
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: +1 (281) 514-5543 EMail: paul.culley@hp.com
Paul R.Culley Hewlett-Packard Company 20555 SH 249德克萨斯州休斯顿77070-2698美国电话：+1（281）514-5543电子邮件：Paul。culley@hp.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.