[要約] RFC 5041は、信頼性のあるトランスポート上での直接データ配置に関する仕様です。その目的は、データ転送の効率を向上させ、ネットワークのパフォーマンスを最適化することです。
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
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
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サイクルを使用できます。これにより、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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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メッセージの境界を保持し、ローカルピアバッファーを匿名（つまり、編集していない）に保持する2番目の受信バッファモデルを提供します。これは、未積載されていないバッファモデルと呼ばれます。
* 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.
* 着信DDPセグメントが順調に到着した場合でも、コピーを必要とせずに、ULPバッファーを再組み立てバッファとして使用できるようにします。これには、完成したULPメッセージのデータ配信から、着信DDPセグメントに含まれる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ストリームで上記の機能を個別に提供し、ULPにllp-streamベースでエクスポートする機能を可能にします。
DDP supports two basic data transfer models - a Tagged Buffer data transfer model and an Untagged Buffer data transfer model.
DDPは、2つの基本的なデータ転送モデルをサポートしています。タグ付きバッファデータ転送モデルと、タグ付きバッファデータ転送モデルです。
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.
タグ付きバッファーデータ転送モデルは、データソースにステアリングタグ（STAG）と呼ばれるULPバッファーの識別子をデータソースに送信するためにデータシンクが必要です。STAGは、ULP定義の方法を使用してデータソースに転送されます。データソースのULPに宛先ULPバッファー用のSTAGがあると、DDPがDDPにSTAGを指定して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はメッセージ指向であるため、データソースが受信ULPバッファーよりも小さいDDPメッセージペイロードを送信したとしても、部分的に満たされた受信ULPバッファーはとにかくULPに配信されます。データソースが、受信ULPバッファーよりも大きいDDPメッセージペイロードを送信すると、エラーが発生します。
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 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固有のメカニズムを通じてULPバッファーをデータソースに宣伝する必要があります。未編成のバッファモデルの場合、エンドツーエンドの明示的な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メッセージは、タグ付きバッファ内の任意のオフセットで開始できます。Untaggedバッファモデルの場合、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.
* タグ付きバッファモデルは、単一のULPバッファー広告を備えたタグ付きバッファーをターゲットにした複数のDDPメッセージを許可します。未編性バッファモデルでは、タグ付きバッファーをターゲットにした各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メッセージは、下層層プロトコル（LLP）最大上層プロトコルデータユニット（MULPDU）に収まることを目的としたDDPセグメントにスライスされます。したがって、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ペイロードを、DDPセグメントが注文不足に到着した場合でも、正しいULPバッファーに直接配置できるようにします。したがって、DDPは、DDPメッセージのDDPセグメントに含まれるULPメッセージに含まれるULPメッセージに含まれるULPメッセージに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 provide in-order, reliable Delivery. Note that DDP has no ordering guarantees between DDP Streams.
DDPのLLPは、接続ごとの単一のLLPデータストリーム（TCP [TCP]など）または接続ごとのデータの複数のLLPストリーム（SCTP [SCTP]など）をサポートする場合があります。ただし、どちらの場合でも、各DDPストリームが独立しており、単一のLLPストリームにマップされるようにDDPが指定されています。特定のDDPストリーム内で、LLPストリームは、順序で信頼できる配信を提供するために必要です。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を介して実行される可能性があります。この仕様には、配信LLPSの信頼性が必要です。
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で定義されている要件を条件として、LLP独立を目的としています。ただし、DDPは、図1に示すように、うまく機能するように作成されたプロトコルファミリーの一部であると定義されていました。各LLPのLLPプロトコル定義については、TCP仕様[MPA]およびストリーム制御伝送プロトコル（SCTP）直接データ配置（DDP）適応[SCTPDDP]のマーカーPDUアラインドフレーミングを参照してください。
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 | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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".
データ配信（配信、配信、配信） - 配信は、特定のメッセージが使用できることを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プロトコルの実装。プロトコル交換または2つのノード間のその他の相互作用を説明する際に、ローカルエンティティを指すために使用されます。
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.
ノード - ネットワークの1つ以上のリンクに接続されたコンピューティングデバイス。このコンテキストのノードは、コンピューターで実行されている特定のアプリケーションまたはプロトコルインスタンス化を指すものではありません。ノードは、ホストコンピューターにインストールされた1つ以上の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プロトコルの実装。プロトコル交換または2つのノード間のその他の相互作用を説明する際に、リモートエンティティを参照するために使用されます。
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 specify a ULP -- they provide a set of semantics that allow a ULP to be designed to utilize RDMA/DDP.
ULP-上層プロトコル。現在参照されているプロトコル層の上のプロトコル層。RDMA/DDPのULPは、オペレーティングシステム（OS）、アプリケーション、適応層、または独自のデバイスになると予想されます。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接続 - 2つのノード上のピア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ストリーム - 2つのノード上のピアLLPレイヤー間の単一のLLPトランスポートレベルのストリームに対応します。1つ以上のLLPストリームは、単一の輸送レベルのLLP接続にマッピングできます。接続ごとの複数のストリーム（SCTPなど）をサポートする輸送プロトコルの場合、LLPストリームは1つの輸送レベルのストリームに対応します。
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-最大上層層プロトコルデータユニット（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".
データ配置（配置、配置、場所） - DDPの場合、この用語は、DDP実装によりデータバッファーに書き込むプロセスを示すために特に使用されます。DDPセグメントには、DDPセグメントULPペイロードのデータ配置を実行するために、受信DDP実装で使用される可能性のある配置情報があります。「データ配信」と「直接データ配置」を参照してください。
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メッセージ - 1つ以上のDDPセグメントに分割されているデータインターチェンジのULP定義ユニット。このセグメンテーションは、基礎となる輸送プロトコルの最大セグメントサイズを尊重するセグメンテーションなど、さまざまな理由で発生する場合があります。
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ストリーム-LLPによって順序付けが定義されているDDPメッセージのシーケンス。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を1つの機能ブロックとして実装するためにデータシンクが必要になる場合があります。
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 Untaggedバッファモデルの場合、DDPメッセージの開始時からオフセット、オクテットのオフセットを指定します。
Message Sequence Number (MSN) - For the DDP Untagged Buffer Model, specifies a sequence number that is increasing with each DDP Message.
メッセージシーケンス番号（MSN） - DDP Untaggedバッファモデルの場合、各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 Untaggedバッファモデルの場合、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.
タグ付きバッファー - スタッグ、タグ付きオフセット、および長さの交換を通じて、リモートピアに明示的に宣伝されるバッファー。
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.
タグ付きオフセット（to） - ノード上のタグ付きバッファー内のオフセット。
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-リモートピアに明示的に宣伝されていないバッファー。
Untagged Buffer Model - A DDP data transfer model used to transfer Untagged Buffers from the Local Peer to the Remote Peer.
Untagged Buffer Model-ローカルピアからリモートピアにタグ付きバッファを転送するために使用されるDDPデータ転送モデル。
Untagged DDP Message - A DDP Message that targets an Untagged Buffer.
編集されていないDDPメッセージ-Taggedバッファを標的とするDDPメッセージ。
Any protocol that can serve as an LLP to DDP MUST meet the following requirements.
LLPからDDPとして機能するプロトコルは、以下の要件を満たす必要があります。
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は以前にLLPに投稿されたDDPセグメントを再セグメント化するためにDDPを要求してはなりません。病理学的条件下では、LLPは、以前に投稿されたDDPセグメント送信要求のキューよりも頻繁に広告されたMulpduを変更する可能性があることに注意してください。この病理学的状態では、LLP送信キューには、メッセージの投稿後に対応するMULPDUの複数の更新が発生したDDPメッセージを含めることができます。したがって、キューに登録された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は、少なくともDDPセグメントをカバーするために、強力なダイジェスト（少なくともCRC32-Cに相当）を提供する必要があります。既存のデータ整合性ダイジェストの一部は十分ではないと考えられており、たとえば単純なチェックサムよりも直接メモリ転送セマンティクスにはより強力なダイジェストが必要であると考えられています。
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 on that LLP Stream after DDP requests the associated DDP Stream to be torn down.
8. LLPが他のLLPストリームとは無関係にLLPストリームの分解をサポートしておらず、特定のDDPストリームでDDPエラーが発生する場合、LLPは関連するLLPストリームに誤ったLLPストリームとしてラベル付けされ、それ以上のデータ転送を許可してはなりません。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には2つの異なるヘッダー形式があります。1つはタグ付きバッファーへのデータ配置用、もう1つは未積載バッファーへのデータ配置用です。2つのモデルの説明については、セクション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ビットには、2つの形式の間で一般的なDDP制御フィールドがあります。これは、[MPA]で定義されているMPAヘッダーに対応するために、16ビットで相殺された図3に以下に示されています。MPAヘッダーは、DDPが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 |
+-+-+-+-+-+-+-+-+
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つに設定する必要があります。DVの値は、DDPストリームで送信または受信されたすべてのDDPセグメントで同じでなければなりません。
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ヘッダーは[MPA]で定義されたMPAヘッダーに対応するために16ビットでオフセットされています。MPAヘッダーは、DDPが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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はULPによって指定された値にrsvdulpフィールドを設定する必要があります。データソースからデータシンクに変更されずに転送されます。データシンクでは、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.
ステアリングタグは、データシンクのタグ付きバッファを識別します。このDDPストリームに対しては、STAGは有効でなければなりません。STAGは、DDPプロトコル仕様の範囲外のメカニズムを介してDDPストリームに関連付けられています。データソースでは、DDPはULPによって指定された値にSTAGフィールドを設定する必要があります。データシンクでは、ULPメッセージが配信されるときにDDPがSTAGフィールドを提供する必要があります。特定のDDPメッセージ内の各DDPセグメントには、このフィールドに同じ値が含まれている必要があり、ULPが提供する値でなければなりません。データソースは、特定のDDPメッセージ内の各DDPセグメントに、このフィールドに同じ値が含まれていることを確認する必要があります。
TO - Tagged Offset: 64 bits.
to-タグ付きオフセット：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.
タグ付きオフセットは、DATAシンクのタグ付きバッファー内のオクテットのオフセットを指定します。ここでは、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ヘッダーは[MPA]で定義されたMPAヘッダーに対応するために16ビットでオフセットされています。MPAヘッダーは、DDPが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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はULPによって指定された値にrsvdulpフィールドを設定する必要があります。データソースからデータシンクに変更されずに転送されます。データシンクでは、ULPメッセージが配信されると、DDPはULPにRSVDulpフィールドを提供する必要があります。特定のDDPメッセージ内の各DDPセグメントには、RSVDULPフィールドに同じ値を含める必要があります。データシンクでは、DDP実装は、特定のDDPメッセージ内の各DDPセグメントのRSVDULPフィールドに同じ値が存在することを確認するために必要ではなく、受信したDDPセグメントのいずれかからULPに値を提供する場合があります。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.
メッセージシーケンス番号は、このDDPセグメントに関連付けられたDDPストリームの特定のキュー番号をターゲットにして、各DDPメッセージで1つ（Modulo 2^32）で増加する必要があるシーケンス番号を指定します。MSNの初期値は1つでなければなりません。MSN値は、0xffffffffの値の後に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.
メッセージオフセットは、この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) |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージは、1つ以上の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ペイロードの配置に2つの基本バッファモデルを使用しています：タグ付きバッファーモデルとUntaggedバッファモデル。
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メッセージを転送します。スタッグはタグ付きバッファを識別します。タグ付きバッファモデルを使用して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.
DDPキュー番号は、ULPによって使用されて、ULPメッセージを受信バッファーの異なるキューに分離します。たとえば、2つのキューがサポートされている場合、ULPは1つのキューを使用してULPの上のアプリケーションによって渡されたバッファーを投稿することができ、ULP固有の制御メッセージによってのみ消費されるバッファーにもう1つのキューを使用できます。これにより、Untaggedバッファーを使用するときに、不透明な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メッセージセグメンテーションは、DDPメッセージ（ULPメッセージを1対1で対応する）を一意に識別し、DDPメッセージの関連DDPセグメントごとに、その部分のオクテットオフセットを指定することにより、実行されます。DDPセグメントに含まれるULPメッセージ。
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オクテットの場合、データソースは2つのDDPセグメントを生成します。ULPペイロードの566オクテット。この例では、最初の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メッセージの場合、LLPの注文の配信特性と組み合わされたSTAGとtoは、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 effectively enable the ULP to implement segmentation and reassembly due to ULP-specific constraints. See [RDMAP] for details of how this is done.
実装者の注：RDMAPなどの一部のULPに有効な実装の1つは、タグ付きDDPメッセージのULPメッセージ境界の回復を直接サポートしないことです。たとえば、ULPは、データシンクのULPがこのデータ転送のために単一の大きなタグ付きバッファーを宣伝している場合でも、データソースでローカルピアをデータソースで使用させることを望む場合があります。この場合、ULPは、複数の連続したULPメッセージに同じSTAGを使用することを選択できます。したがって、STAGの非ゼロの初期と再利用により、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メッセージで使用されたSTAGのイニシャルを詳細に詳細にするUntagged DDPメッセージ（タグ付きDDPメッセージの後に送信）を使用できます。そして最後に、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と初期を指定する必要があります。
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メッセージで。
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タグ付けされたメッセージが16384の初期で2048オクテットで、Mulpduが1500オクテットの場合、データソースは2つのDDPセグメントを生成します。= 17870の2秒、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セグメントを1つだけ消費する必要があります。DDPコントロールとRSVDULPフィールドのみが、ゼロレングスのタグ付きDDPセグメントに対して有効でなければなりません。STAGおよびFIELDSには、ゼロ長さのタグ付きDDPメッセージがないか確認してはなりません。
For either Untagged or Tagged DDP Messages, the Data Sink is not required to verify that the entire ULP Message has been received.
Untaggedまたはタグ付けされた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.
* Untagged DDPメッセージのMOオーダーを増やし、タグ付き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,
* DDPメッセージを最大でULPに1回配信する必要があります。
* 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がUntagged DDPメッセージが配信されたときにULPメッセージの長さをULPに提供する必要があります。ULPメッセージの長さは、未積層DDPメッセージの最後のDDPセグメント（最後のフラグセット）にMOとULPペイロード長を追加することで計算できます。
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メッセージが配信されると、DDPメッセージのRSVDULPフィールドをULPに提供する必要があります。
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接続が1つ以上の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ストリーム断dowarは、両方のエンドポイントでDDP機能を無効にします。接続指向のLLPの場合、DDPストリームの分解により、LLP接続の根底にある断downが生じる可能性があります。
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.
DDPストリームの両方のエンドポイントでDDP分解が同時に発生するようにするのは、ULP次第です。これは、データシンクが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が、DDPストリームのLLP優雅な断downリクエストを受け取ったときに、半分閉鎖されたLLPストリームをサポートしている場合、DDPは半分閉鎖された状態をULPに示し、アウトバウンドデータ転送リクエストを正常に処理し続ける必要があります。このイベントに続いて、地元のPeer 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が、DDPストリームのULP優雅な半分閉鎖要求の受領時に半分閉鎖されたLLPストリームをサポートしている場合、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ヘッダーには、1つ以上の無効なフィールドがあります。
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レイヤーはERRORをULPに報告し（セクション7.2、DDPエラー番号を参照）、エラーですべての未解決のULP要求を完了する必要があります。基礎となるLLPストリームが依然として無傷の場合、DDPは致命的な誤差がULPに示された後、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メッセージが受信および完了し、新しいバッファーが追加されると、両方の数字が動的に変更されます。入ってくるDDPセグメントを処理するのに十分なバッファーが利用できるようにするのはULP次第です。
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セグメントペイロード長の合計と、STAGに登録されている法的オフセットの範囲に収まるToになります。
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はDDPストリームを終了する前にULPが追加のDDPメッセージを1つ送信できるようにする必要があります。
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
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 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 Untaggedバッファエラー0x01無効なQN 0x02無効なMSN-バッファーを使用できない0x03無効なMSN -MSN範囲は無効です0x04無効なMO 0x05 DDPメッセージ
0x3 Rsvd Reserved for the use by the LLP
LLPによる使用のために予約されている0x3 RSVD
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 3723 [RFC3723]によってプロファイルされたRFC 2401 [IPSEC]および関連RFCで指定されたIPSECのバージョンに基づいています。RFCS [RFC4303]、[RFC4306]。RDDPプロトコルの重要な初期のアプリケーションの1つは、ISCSI [ISER]での使用です。RDDPのIPSEC要件は、IPSECの共通プロファイルをISCSIおよびRDDPプロトコルで使用できるようにすることにより、その使用を容易にするためにIPSECの要件に従います。将来、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の脆弱性は、IPを介してTCPやSCTPなどの輸送プロトコルを介して実行されている他のプロトコルよりも大きくありません。サードパーティは、DDPデータシンクに配信されるネットワークにスプーフィングされたパケットを注入することにより、DDP固有の動作を活用するさまざまな攻撃を開始する可能性があります。DDPは直接的または間接的にワイヤー上でメモリアドレスを公開するため、データが配置される前に、無効なSTAGおよびOctet-Level Granularity BaseおよびBounds Checkを含む、各DDPセグメントに配置された配置情報を検証する必要があります。たとえば、サードパーティの敵は、有効な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ストリームを関連付けるためのいくつかのメカニズムがあります。この関連付けに必要な2つのメカニズムは、保護ドメイン（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 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.
保護ドメイン（PD）協会の下で、一意の保護ドメイン識別子（PD ID）が作成され、局所的にDDPストリームのセットに関連付けられます。このメカニズムでは、STAGの使用は、STAGと同じPD IDを持つDDPストリームでのみ許可されます。DDPストリーム上のタグ付きDDPメッセージの着信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を少なくとも1つのDDPストリームに関連付ける必要があります。DDPは、STAGとDDPストリームを関連付けるための保護ドメイン関連および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に依存して、DDPメッセージが伝達されるLLPストリームを確立します。DDP自体は、いずれかのエンドポイントのLLPストリームの有効性を認証するために何もしません。LLPストリームを検証することはULPの責任です。これは、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バッファーに関連付けられた範囲を確立および取り消すメカニズムを提供する必要があります。2. STAGは、ULPによって確立された期間のみ有効です。ULPは、独自の上層プロトコル要件に従って、いつでもそれらを取り消すことができます。DDPは、ULPが雄鹿の妥当性を確立および取り消すメカニズムを提供する必要があります。3. DDPは、ULPがSTAGと特定のDDPストリームとの関連性を伝えるメカニズムを提供する必要があります。4. ULPは、そのメモリ自体にすでにアクセスできる限り、メモリをリモートアクセスにのみ公開する場合があります。5. DDPストリームでSTAGが有効でない場合、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）の2つのコンポーネントを提供する必要があります。
The RNIC MUST implement the DDP wire Protocol and perform the security semantics described below.
RNICは、DDPワイヤプロトコルを実装し、以下に説明するセキュリティセマンティクスを実行する必要があります。
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バッファーと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. 特権的なリソースマネージャーは、ULPSが実際に部分的な相互信頼を共有することを保証するメカニズムがない限り、異なる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が特定のデータバッファーにアクセスする前に特定のデータバッファーにアクセスする権利があることを確認する必要があります。
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 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.
5. 特権的なリソースマネージャーは、地元のピアがかなりのリソースを割り当てることを防ぐ必要があります。RNICが複数のDDPストリームで受信バッファーを共有する機能を提供する場合、RNICと特権リソースマネージャーの組み合わせは、リモートピアがリソースの公正なシェアを超えて消費しようとしているかどうかを検出できる必要があります。攻撃を検出および防止するために対策を適用できます。
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ベースのULPS [TLS]および輸送プロトコルの下で提供されるDTLS [DTLS]セキュリティサービスから提供されるSSLまたはTLSセキュリティサービスから利益を得ることができます。これらのアプローチと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. IPSEC DOI [RFC2407]を使用して、ピア認証、セキュリティ協会の交渉、および主要な管理のためにIKE [RFC2409]をサポートする必要があります。
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削除メッセージの受領をDDPストリームを裂く理由として解釈してはなりません。IPSEC加速ハードウェアは、限られた数のアクティブなIPSECセキュリティアソシエーション（SAS）のみを処理できる可能性があるため、アクティビティが再開された場合、アイドルSASを動的に倒し、新しい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. IKEパラメーターの設定に関する[RFC3723]のセクション2.3.4のガイドラインに従って、広範な構成を必要とせずに高レベルの相互運用性を実現する必要があります。
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.
DDPが有名なポートに接続することによりULPの先験的に有効になった場合、この有名なポートは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。and 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。、「The Internet Key Exchange（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 3723、2004年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 5040、2007年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 5042、2007年10月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年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 5043、2007年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 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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、「The Transport Layer Security（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、 "Internet Small Computer System Interface（ISCSI）リモートダイレクトメモリアクセス（RDMA）拡張）」、RFC 5046、2007年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を使用すると、データをデータシンクの事前定義されたバッファーに直接転送できます。したがって、追加のセグメントが到着する前にそのセグメントが配置された場合、LLP受信ウィンドウセグメントの受信の影響を受ける必要はありません。
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セグメントを廃止できるレートに依存します。セグメント処理が着信パケットレートに追いつかない場合があります。これが発生した場合、着信パケットレートを遅くする合理的な方法の1つは、受信ウィンドウを減らすことです。
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).
LLPは、該当する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. 411 First Avenue S、Suite 600 Seattle、WA 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 Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1 (949) 926-6383 EMail: caitlinb@Broadcom.com
Hari Ghadia Gen10 Technology、Inc。1501 W Shady Grove Road Grand Prairie、TX 75050電話：（972）301 3630電子メール：hghadia@gen10technology.com Alton Parkway Irvine、CA 92619-7013米国電話：1（949949）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 California Avenue Irvine、CA 92617、USA電話：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 USA電話：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 USA電話：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 Corporation Research Triangle Park、NC 27709 USA電話：1（919）248-6075メール：compton_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 USA電話：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 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
Mike Krause Hewlett-Packard Company、43ln 19410 Homestead Road Cupertino、CA 95014 USA電話：1（408）447-3191メール：krause@cup.hp.comまたは97124 USA電話：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 West Chandler Blvd.チャンドラー、AZ 85226 USA電話：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アプライアンス1601 Trapelo Road＃16 MA 02451 USA電話：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 USA電話：1（281）514-2769メール：wight.barron@hp.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 USA Phone: +1 (831) 247-4464 Email: Dave.Garcia@StanfordAlumni.org
Dave Garcia 24100 Hutchinson Rd。Los Gatos、CA 95033 USA電話：1（831）247-4464メール：dave.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
Jeff Hilland Hewlett-Packard Company 20555 SH 249 TX 77070-2698 USA電話：1（281）514-9489メール：jeff.hilland@hp.com
Barry Reinhold Lamprey Networks Durham, NH 03824 USA Phone: +1 (603) 868-8411 EMail: bbr@LampreyNetworks.com
バリーラインホールドランプリーネットワーク、ダーラム、ニューハンプシャー03824 USA電話：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 California Avenue Irvine、CA 92617 USA電話：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 USA電話：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 Burnett Road Austin、TX 78758 USA電話：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 USA電話：1（281）514-5543メール：paul.culley@hp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。