Network Working Group R. Recio
Request for Comments: 5040 B. Metzler
Category: Standards Track IBM Corporation
P. Culley
J. Hilland
Hewlett-Packard Company
D. Garcia
October 2007
A Remote Direct Memory Access Protocol Specification
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
抽象
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation.
この文書では、直接データ配置プロトコル（DDPプロトコル）上で動作リモートダイレクトメモリアクセスプロトコル（RDMAP）を定義します。 RDMAPが読み込まれ、アプリケーションに直接サービスを記述し、中間データをコピーせずに上位層プロトコル（ULP）バッファに直接転送するデータを可能にします提供します。また、カーネルバイパス実装を可能にします。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Architectural Goals ........................................4
1.2. Protocol Overview ..........................................5
1.3. RDMAP Layering .............................................7
2. Glossary ........................................................8
2.1. General ....................................................8
2.2. LLP .......................................................10
2.3. Direct Data Placement (DDP) ...............................11
2.4. Remote Direct Memory Access (RDMA) ........................13
3. ULP and Transport Attributes ...................................15
3.1. Transport Requirements and Assumptions ....................15
3.2. RDMAP Interactions with the ULP ...........................16
4. Header Format ..................................................19
4.1. RDMAP Control and Invalidate STag Field ...................20
4.2. RDMA Message Definitions ..................................23
4.3. RDMA Write Header .........................................24
4.4. RDMA Read Request Header ..................................24
4.5. RDMA Read Response Header .................................26
4.6. Send Header and Send with Solicited Event Header ..........26
4.7. Send with Invalidate Header and Send with SE and
Invalidate Header .........................................26
4.8. Terminate Header ..........................................26
5. Data Transfer ..................................................32
5.1. RDMA Write Message ........................................32
5.2. RDMA Read Operation .......................................33
5.2.1. RDMA Read Request Message ..........................33
5.2.2. RDMA Read Response Message .........................35
5.3. Send Message Type .........................................36
5.4. Terminate Message .........................................37
5.5. Ordering and Completions ..................................38
6. RDMAP Stream Management ........................................41
6.1. Stream Initialization .....................................41
6.2. Stream Teardown ...........................................42
6.2.1. RDMAP Abortive Termination .........................43
7. RDMAP Error Management .........................................43
7.1. RDMAP Error Surfacing .....................................44
7.2. Errors Detected at the Remote Peer on Incoming
RDMA Messages .............................................45
8. Security Considerations ........................................46
8.1. Summary of RDMAP-Specific Security Requirements ...........46
8.1.1. RDMAP (RNIC) Requirements ..........................47
8.1.2. Privileged Resource Manager Requirements ...........48
8.2. Security Services for RDMAP ...............................49
8.2.1. Available Security Services ........................49
8.2.2. Requirements for IPsec Services for RDMAP ..........50
9. IANA Considerations ............................................51
10. References ....................................................52
10.1. Normative References .....................................52
10.2. Informative References ...................................53
Appendix A. DDP Segment Formats for RDMA Messages .................54
A.1. DDP Segment for RDMA Write ................................54
A.2. DDP Segment for RDMA Read Request .........................55
A.3. DDP Segment for RDMA Read Response ........................56
A.4. DDP Segment for Send and Send with Solicited Event ........56
A.5. DDP Segment for Send with Invalidate and Send with SE and
Invalidate ................................................57
A.6. DDP Segment for Terminate .................................58
Appendix B. Ordering and Completion Table .........................59
Appendix C. Contributors ..........................................61
Table of Figures
図の表
Figure 1: RDMAP Layering ...........................................7
Figure 2: Example of MPA, DDP, and RDMAP Header Alignment over TCP .8
Figure 3: DDP Control, RDMAP Control, and Invalidate STag Fields ..20
Figure 4: RDMA Usage of DDP Fields ................................22
Figure 5: RDMA Message Definitions ................................23
Figure 6: RDMA Read Request Header Format .........................24
Figure 7: Terminate Header Format .................................27
Figure 8: Terminate Control Field .................................27
Figure 9: Terminate Control Field Values ..........................29
Figure 10: Error Type to RDMA Message Mapping .....................32
Figure 11: RDMA Write, DDP Segment Format .........................54
Figure 12: RDMA Read Request, DDP Segment Format ..................55
Figure 13: RDMA Read Response, DDP Segment Format .................56
Figure 14: Send and Send with Solicited Event, DDP Segment Format .56
Figure 15: Send with Invalidate and Send with SE and Invalidate,
DDP Segment Format .....................................57
Figure 16: Terminate, DDP Segment Format ..........................58
Figure 17: Operation Ordering .....................................59
Today, communications over TCP/IP typically require copy operations, which add latency and consume significant CPU and memory resources. The Remote Direct Memory Access Protocol (RDMAP) enables removal of data copy operations and enables reduction in latencies by allowing a local application to read or write data on a remote computer's memory with minimal demands on memory bus bandwidth and CPU processing overhead, while preserving memory protection semantics.
今日では、TCP / IP上での通信は、一般的に、待ち時間を追加し、大幅なCPUとメモリリソースを消費コピー操作を、必要としています。リモートダイレクトメモリアクセスプロトコル（RDMAP）は、データのコピー操作の除去を可能にし、保存メモリながら、メモリバス帯域幅とCPU処理のオーバーヘッドの最小限の要求にリモートコンピュータのメモリ上のデータを読み書きするローカルアプリケーションを可能にすることにより、レイテンシを低減することができます保護の意味。
RDMAP is layered on top of Direct Data Placement (DDP) and uses the two buffer models available from DDP. DDP-related terminology is discussed in Section 2.3. As RDMAP builds on DDP, the reader is advised to become familiar with [DDP].
RDMAPは直接データ配置（DDP）の上部に重層し、DDPから利用可能な2つのバッファ・モデルを使用しています。 DDP-関連の用語は、セクション2.3で説明されています。 RDMAPがDDP上に構築されるように、読者は[DDP]に精通することが推奨されます。
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]に記載されているように解釈されます。
RDMAP has been designed with the following high-level architectural goals:
RDMAPには、以下の高レベルアーキテクチャの目標に設計されています：
* Provide a data transfer operation that allows a Local Peer to transfer up to 2^32 - 1 octets directly into a previously Advertised Buffer (i.e., Tagged Buffer) located at a Remote Peer without requiring a copy operation. This is referred to as the RDMA Write data transfer operation.
直接コピー操作を必要とせずに、リモートピアに位置する以前にアドバタイズバッファ（即ち、バッファをタグ付け）に1オクテット - * 32 ^ 2を転送するためにローカルピアを可能にするデータ転送動作を提供します。これは、RDMA書き込みデータ転送動作と呼ばれています。
* Provide a data transfer operation that allows a Local Peer to retrieve up to 2^32 - 1 octets directly from a previously Advertised Buffer (i.e., Tagged Buffer) located at a Remote Peer without requiring a copy operation. This is referred to as the RDMA Read data transfer operation.
コピー操作を必要とせずに、リモートピアに位置直接以前にアドバタイズバッファ（即ち、バッファをタグ）から1オクテット - *ローカルピアは32 ^ 2を取得することができ、データ転送動作を提供します。これは、RDMA読み取りデータ転送動作と呼ばれています。
* Provide a data transfer operation that allows a Local Peer to send up to 2^32 - 1 octets directly into a buffer located at a Remote Peer that has not been explicitly Advertised. This is referred to as the Send (Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate) data transfer operation.
直接明示的にアドバタイズされていないリモートピアに位置バッファに1オクテット - * 2 ^ 32まで送るためのローカルピアを可能にするデータ転送動作を提供します。これは、送信（要請イベントに送信し、無効化して送信し、要請イベントと無効化して送信）、データ転送動作と呼ばれます。
* Enable the local ULP to use the Send Operation Type (includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate) to signal to the remote ULP the Completion of all previous Messages initiated by the local ULP.
*（要請イベントで送る、無効化して送信し、送信含まれており、要請イベントや無効化して送信）送信操作タイプを使用するようにローカルULPを有効にリモートULPにローカルULPによって開始され、以前のすべてのメッセージの完了を通知します。
* Provide for all operations on a single RDMAP Stream to be reliably transmitted in the order that they were submitted.
*確実に彼らが提出された順に送信される単一RDMAPストリーム上のすべての操作を提供します。
* Provide RDMAP capabilities independently for each Stream when the LLP supports multiple data Streams within an LLP connection.
LLPがLLP接続内で複数のデータストリームをサポートしている場合*ストリームごとに独立してRDMAP機能を提供します。
RDMAP provides seven data transfer operations. Except for the RDMA Read operation, each operation generates exactly one RDMA Message. Following is a brief overview of the RDMA Operations and RDMA Messages:
RDMAPは7つのデータ転送動作を提供します。 RDMA読み取り操作を除いて、各操作は、1つのRDMAメッセージを生成します。 RDMAオペレーションとRDMAメッセージの概要を以下に示します。
1. Send - A Send operation uses a Send Message to transfer data from the Data Source into a buffer that has not been explicitly Advertised by the Data Sink. The Send Message uses the DDP Untagged Buffer Model to transfer the ULP Message into the Data Sink's Untagged Buffer.
1.送信 - 送信操作は、明示的にデータシンクによってアドバタイズされていないバッファにデータソースからデータを転送するためのメッセージ送信を使用しています。メッセージ送信は、データシンクのタグなしバッファにULPメッセージを転送するDDPタグなしのバッファモデルを使用しています。
2. Send with Invalidate - A Send with Invalidate operation uses a Send with Invalidate Message to transfer data from the Data Source into a buffer that has not been explicitly Advertised by the Data Sink. The Send with Invalidate Message includes all functionality of the Send Message, with one addition: an STag field is included in the Send with Invalidate Message. After the message has been Placed and Delivered at the Data Sink, the Remote Peer's buffer identified by the STag can no longer be accessed remotely until the Remote Peer's ULP re-enables access and Advertises the buffer.
2.無効化して送信する - 無効化操作で送信明示的にデータシンクによってアドバタイズされていないバッファにデータソースからのデータを転送するために無効化メッセージで送信を使用しています。無効化メッセージを送る1に加えて、メッセージ送信のすべての機能が含まれていますスタッグフィールドは無効化メッセージと送信に含まれています。メッセージは、データシンクに配置され、配信された後、リモートピアのULPは、アクセスを再度有効にしてバッファをアドバタイズするまで、のSTagによって識別されるリモートピアのバッファはもはやリモートでアクセスすることはできません。
3. Send with Solicited Event (Send with SE) - A Send with Solicited Event operation uses a Send with Solicited Event Message to transfer data from the Data Source into an Untagged Buffer at the Data Sink. The Send with Solicited Event Message is similar to the Send Message, with one addition: when the Send with Solicited Event Message has been Placed and Delivered, an Event may be generated at the recipient, if the recipient is configured to generate such an Event.
3.要請イベント（SEと送信）で送信 - Aデータシンクでタグなしバッファへのデータソースからデータを転送する要請イベントメッセージとともに送信を使用する要請イベント動作に送信します。要請イベントメッセージとともに送信つの付加と、送信メッセージに類似している：要請イベントメッセージで送信するとき、受信者がこのようなイベントを生成するように構成されている場合、イベントは、レシピエントに生成することができる、配置し、送達されました。
4. Send with Solicited Event and Invalidate (Send with SE and Invalidate) - A Send with Solicited Event and Invalidate operation uses a Send with Solicited Event and Invalidate Message to transfer data from the Data Source into a buffer that has not been explicitly Advertised by the Data Sink. The Send with Solicited Event and Invalidate Message is similar to the Send with Invalidate Message, with one addition: when the Send with
4.要請イベントと無効化（SEおよび無効化して送信）で送信 - 要請イベントに送信し、無効化動作は、明示によってアドバタイズされていないバッファへのデータソースからデータを転送する要請イベントと無効化メッセージで送信を使用しデータシンク。要請イベントと無効化メッセージを送る1に加えて、無効化メッセージを送るようになります。で送信する場合
Solicited Event and Invalidate Message has been Placed and
Delivered, an Event may be generated at the recipient, if the
recipient is configured to generate such an Event.
5. Remote Direct Memory Access Write - An RDMA Write operation uses an RDMA Write Message to transfer data from the Data Source to a previously Advertised Buffer at the Data Sink.
5.リモートダイレクトメモリアクセスのライト - RDMA書き込み操作はデータシンクで以前にアドバタイズバッファへのデータソースからデータを転送するRDMA書き込みメッセージを使用しています。
The ULP at the Remote Peer, which in this case is the Data Sink,
enables the Data Sink Tagged Buffer for access and Advertises the
buffer's size (length), location (Tagged Offset), and Steering
Tag (STag) to the Data Source through a ULP-specific mechanism.
The ULP at the Local Peer, which in this case is the Data Source,
initiates the RDMA Write operation. The RDMA Write Message uses
the DDP Tagged Buffer Model to transfer the ULP Message into the
Data Sink's Tagged Buffer. Note: the STag associated with the
Tagged Buffer remains valid until the ULP at the Remote Peer
invalidates it or the ULP at the Local Peer invalidates it
through a Send with Invalidate or Send with Solicited Event and
Invalidate.
6. Remote Direct Memory Access Read - The RDMA Read operation transfers data to a Tagged Buffer at the Local Peer, which in this case is the Data Sink, from a Tagged Buffer at the Remote Peer, which in this case is the Data Source. The ULP at the Data Source enables the Data Source Tagged Buffer for access and Advertises the buffer's size (length), location (Tagged Offset), and Steering Tag (STag) to the Data Sink through a ULP-specific mechanism. The ULP at the Data Sink enables the Data Sink Tagged Buffer for access and initiates the RDMA Read operation. The RDMA Read operation consists of a single RDMA Read Request Message and a single RDMA Read Response Message, and the latter may be segmented into multiple DDP Segments.
6.リモートダイレクトメモリアクセス読み取り - この場合には、データソースでリモートピア、でタグ付けバッファから、この場合には、データシンクでローカルピア、、でタグ付けバッファへのRDMA読み取り操作でデータを転送します。データソースでULPは、アクセスのためにデータソースタグ付けバッファを可能とULP特有のメカニズムを介してバッファのサイズ（長さ）、位置（オフセットタグ付き）、およびデータシンクにステアリングタグ（のSTag）をアドバタイズ。データシンクのULPは、アクセスのためにデータシンクタグ付きバッファを有効にし、RDMA読み取り操作を開始します。 RDMA読み取り操作は、単一のRDMA読み取り要求メッセージと単一RDMA読み取り応答メッセージで構成されており、後者は、複数のDDPセグメントに分割されてもよいです。
The RDMA Read Request Message uses the DDP Untagged Buffer Model
to Deliver the STag, starting Tagged Offset, and length for both
the Data Source and Data Sink Tagged Buffers to the Remote Peer's
RDMA Read Request Queue.
The RDMA Read Response Message uses the DDP Tagged Buffer Model to Deliver the Data Source's Tagged Buffer to the Data Sink, without any involvement from the ULP at the Data Source.
RDMA読み取り応答メッセージは、データソース側のULPからのいかなる関与することなく、データシンクへのデータソースのタグ付けバッファを配信するためDDPタグ付きバッファモデルを使用しています。
Note: the Data Source STag associated with the Tagged Buffer remains valid until the ULP at the Data Source invalidates it or the ULP at the Data Sink invalidates it through a Send with
注意：データソースのULPは、それを無効にするか、データシンクのULPはとセンドを通してそれを無効にするまで、タグ付けバッファに関連付けられているデータソースのSTagは有効なまま
Invalidate or Send with Solicited Event and Invalidate. The Data Sink STag associated with the Tagged Buffer remains valid until the ULP at the Data Sink invalidates it.
無効または要請イベントおよび無効化して送信します。データシンクのULPは、それを無効にするまで、タグ付けバッファに関連付けられたデータシンクのSTagは有効なまま。
7. Terminate - A Terminate operation uses a Terminate Message to transfer to the Remote Peer information associated with an error that occurred at the Local Peer. The Terminate Message uses the DDP Untagged Buffer Model to transfer the Message into the Data Sink's Untagged Buffer.
7.終了 - 終了操作がローカルピアで発生したエラーに関連付けられたリモートピア情報を転送する終了メッセージを使用します。終了メッセージは、データシンクのタグなしバッファにメッセージを転送するDDPタグなしのバッファモデルを使用しています。
RDMAP is dependent on DDP, subject to the requirements defined in Section 3.1, "Transport Requirements and Assumptions". Figure 1, "RDMAP Layering", depicts the relationship between Upper Layer Protocols (ULPs), RDMAP, DDP protocol, the framing layer, and the transport. For LLP protocol definitions of each LLP, see [MPA], [TCP], and [SCTP].
RDMAPは、「トランスポートの要件と仮定」、3.1節で定義された要件の対象、DDPに依存しています。図1は、「RDMAPレイヤリング」は、上位層プロトコル（のULP）、RDMAP、DDPプロトコル、フレーミング層、及び輸送の間の関係を示しています。各々のLLPのLLPプロトコル定義については、[MPA]、[TCP]、および[SCTP]参照。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Upper Layer Protocol (ULP) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RDMAP |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DDP protocol |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MPA | |
| | |
+-+-+-+-+-+-+-+-+-+ SCTP |
| | |
| TCP | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RDMAP Layering
図1：RDMAPの階層化
If RDMAP is layered over DDP/MPA/TCP, then the respective headers and ULP Payload are arranged as follows (Note: For clarity, MPA header and CRC fields are included but MPA markers are not shown):
RDMAPがDDP / MPAは/ TCP上に積層されている場合、それぞれのヘッダーとULPペイロードは次のように配置されている（注：明瞭にするために、MPAヘッダおよびCRCフィールドが含まれているが、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TCP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// DDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// RDMA Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ULP Payload //
// (shown with no pad bytes) //
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPA CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of MPA, DDP, and RDMAP Header Alignment over TCP
図2：TCP経由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, and buffer 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, base address, and length in a Send Message destined for the Remote Peer.
広告（アドバタイズ、宣伝、広告、アドバタイズ） - ローカルRDMAバッファがそれに利用可能であること、リモートピアに通知する行為。ノードは、RDMA /タグ付きバッファ識別子のDDPピア（婚前、ベースアドレス、およびバッファ長）を通知することにより、着信RDMA読み取り又はRDMA書き込みアクセスのために利用可能なRDMAバッファを行います。タグ付きバッファ情報のこの広告は、RDMA / DDPによって定義されていないとULPに任されています。典型的な方法は、リモートピア宛てのメッセージ送信にタグ付けバッファのステアリングタグ、ベース・アドレス、および長さを埋め込むローカルピアのためになります。
Completion - Refer to "RDMA Completion" in Section 2.4.
完成 - 2.4節で「RDMA完了」を参照してください。
Completed - See "RDMA Completion" in Section 2.4.
完了 - 2.4節で「RDMA完了」を参照してください。
Complete - See "RDMA Completion" in Section 2.4.
完了 - 2.4節で「RDMA完了」を参照してください。
Completes - See "RDMA Completion" in Section 2.4.
完了 - 2.4節で「RDMA完了」を参照してください。
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メッセージを送受信するには、両方必要になることができることに注意してください。
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" in Section 2.3.
データ配信（配信、配信、配信） - 送達はULPまたは特定のメッセージが使用可能であることを消費者に通知するプロセスとして定義されます。 「配信」の順序を厳密に定義されているが、これは、一般的に任意の順序で発生することがあり、「配置」、より具体的に異なっています。 2.3節の「データの配置」を参照してください。
Delivery - See Data Delivery in Section 2.1.
配信 - セクション2.1でのデータ配信を参照してください。
Delivered - See Data Delivery in Section 2.1.
配信 - セクション2.1でのデータ配信を参照してください。
Delivers - See Data Delivery in Section 2.1.
実現 - セクション2.1でのデータ配信を参照してください。
Fabric - The collection of links, switches, and routers that connect a set of Nodes with RDMA/DDP protocol implementations.
ファブリック - RDMA / DDPプロトコル実装とノードのセットを接続するリンク、スイッチ、ルータのコレクション。
Fence (Fenced, Fences) - To block the current RDMA Operation from executing until prior RDMA Operations have Completed.
フェンス（フェンス、フェンス） - 前RDMA操作が完了するまで実行から現在のRDMA動作をブロックします。
iWARP - A suite of wire protocols comprised of RDMAP, DDP, and MPA. The iWARP protocol suite may be layered above TCP, SCTP, or other transport protocols.
iWARPの - RDMAP、DDP、およびMPAからなるワイヤプロトコルのスイート。 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 Fabric (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 RNICs installed in a host computer.
ノード - ファブリック（ネットワーク）の1つまたは複数のリンクに取り付けられたコンピューティングデバイス。この文脈において、ノードは、コンピュータ上で実行されている特定のアプリケーションまたはプロトコルのインスタンスを指すものではありません。ノードは、ホストコンピュータにインストール一つ以上RNICsからなっていてもよいです。
Placement - See "Data Placement" in Section 2.3.
配置 - 2.3節の「データの配置」を参照してください。
Placed - See "Data Placement" in Section 2.3.
配置 - 2.3節の「データの配置」を参照してください。
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 Network Interface Controller. In this context, this would be a network I/O adapter or embedded controller with iWARP and Verbs functionality.
RNIC - RDMAネットワークインタフェースコントローラ。この文脈では、これは、ネットワークI / OアダプタまたはiWARPの動詞の機能と組み込みコントローラであろう。
RNIC Interface (RI) - The presentation of the RNIC to the Verbs Consumer as implemented through the combination of the RNIC and the RNIC driver.
RNICインタフェース（RI） - RNICおよびRNICドライバの組み合わせを介して実装される動詞消費者にRNICのプレゼンテーション。
Termination - See "RDMAP Abortive Termination" in Section 2.4.
終了 - 2.4節で「RDMAP頓挫終了」を参照してください。
Terminated - See "RDMAP Abortive Termination" in Section 2.4.
終了 - 2.4節で「RDMAP頓挫終了」を参照してください。
Terminate - See "RDMAP Abortive Termination" in Section 2.4.
終了 - 2.4節で「RDMAP頓挫終了」を参照してください。
Terminates - See "RDMAP Abortive Termination" in Section 2.4.
終了 - 2.4節で「RDMAP頓挫終了」を参照してください。
ULP - Upper Layer Protocol. The protocol layer above the one currently being referenced. The ULP for RDMA/DDP is expected to be an 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 - 上位層プロトコル。現在参照中の1以上のプロトコル層。 RDMA / DDPのためのULPは、OS、アプリケーション、アダプテーション層、または独自のデバイスであると予想されます。 RDMA / DDP文書はULPを指定していない - 彼らはULPはRDMA / DDPを利用するように設計することができるように意味のセットを提供します。
ULP Payload - The ULP data that is contained within a single protocol segment or packet (e.g., a DDP Segment).
ULPペイロード - 単一のプロトコルセグメントまたはパケット（例えば、DDPセグメント）内に含まれるULPデータ。
Verbs - An abstract description of the functionality of an RNIC Interface. The OS may expose some or all of this functionality via one or more APIs to applications. The OS will also use some of the functionality to manage the RNIC Interface.
動詞 - RNICインタフェースの機能の抽象的な記述。 OSは、アプリケーションの1つのまたは複数のAPIを経由して、この機能の一部または全てを露出させることができます。 OSはまた、RNICインタフェースを管理するための機能の一部を使用します。
LLP - Lower Layer Protocol. The protocol layer beneath the protocol layer currently being referenced. For example, for DDP, the LLP is SCTP, MPA, or other transport protocols. For RDMA, the LLP is DDP.
LLP - 下位層プロトコル。現在参照されているプロトコル層の下のプロトコル層。例えば、DDPのために、LLPは、SCTP、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ストリーム - 二つのノードのピアLLP層の間の単一LLPトランスポートレベルのストリームに対応します。一つ以上のLLPストリームは、単一のトランスポート・レベルのLLP接続にマッピングすることができます。接続ごとに複数のストリーム（例えば、SCTP）をサポートするトランスポートプロトコルのために、LLPストリームは、一つのトランスポート・レベル・ストリームに対応します。
MULPDU - Maximum ULPDU. The current maximum size of the record that is acceptable for DDP to pass to the LLP for transmission.
MULPDU - 最大ULPDU。 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".
データ配置（配置、置かれ、スポットは） - 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 16-bit field in the DDP Header. The DDP Control Field contains an 8-bit field whose contents are reserved for use by the ULP.
DDP制御フィールド - DDPヘッダ内の固定16ビットのフィールド。 DDP制御フィールドは、そのコンテンツULPによる使用のために予約されている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メッセージ - 一つ以上の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 underlying transport 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 StreamがTCPコネクションに直接マップ、単一のDDP Streamがサポートされています。 DDPは、DDPストリームの間には順序の保証がないことに注意してください。
Direct Data Placement - A mechanism whereby ULP data contained within DDP Segments may be Placed directly into its final destination in memory without processing of the ULP. This may occur even when the DDP Segments arrive out of order. Out-of-order Placement support may require the Data Sink to implement the LLP and DDP as one functional block.
直接データ配置 - DDPセグメント内に含まれるULPデータはULPの処理を行わずにメモリにその最終的な宛先に直接配置することができる機構。 DDPセグメントは順序が狂って到着する場合にも発生する可能性があります。アウトオブオーダー配置のサポートは、一つの機能ブロックとしてLLPおよびDDPを実装するために、データシンクが必要な場合があります。
Direct Data Placement Protocol (DDP) - Also, a wire protocol that supports Direct Data Placement by associating explicit memory buffer placement information with the LLP payload units.
直接データ配置プロトコル（DDP） - また、LLPペイロードユニットと、明示的なメモリ・バッファ配置情報を関連付けることにより、直接データ配置をサポートワイヤプロトコル。
Message Offset (MO) - For the DDP Untagged Buffer Model, specifies the offset, in bytes, from the start of a DDP Message.
メッセージオフセット（MO） - DDPタグなしのバッファモデルの、DDPメッセージの先頭からのバイト数でのオフセットを指定します。
Message Sequence Number (MSN) - For the DDP Untagged Buffer Model, specifies a sequence number that is increasing with each DDP Message.
メッセージシーケンス番号（MSN） - DDPタグなしバッファモデルに対しては、各DDPメッセージで増加しているシーケンス番号を指定します。
Queue Number (QN) - For the DDP Untagged Buffer Model, identifies a destination Data Sink queue for a DDP Segment.
キュー番号（QN） - DDPタグなしバッファモデルについては、DDPセグメントの宛先データシンクキューを識別する。
Steering Tag - An identifier of a Tagged Buffer on a Node, valid as defined within a protocol specification.
ステアリングタグ - プロトコル仕様内で定義されるように有効なノードにタグ付けバッファの識別子。
STag - Steering Tag
STag - ステアリングタグ
Tagged Buffer - A buffer that is explicitly Advertised to the Remote Peer through exchange of an STag, Tagged Offset, and length.
バッファタグ付けされた - 明示のSTagの交換を介してリモートピアにアドバタイズされるバッファを、オフセット、および長さがタグ付けされました。
Tagged Buffer Model - A DDP data transfer model used to transfer Tagged Buffers from the Local Peer to the Remote Peer.
リモートピアにローカルピアからタグ付きバッファを転送するために使用されるDDPデータ転送モデル - バッファモデルをタグ付き。
Tagged DDP Message - A DDP Message that targets a Tagged Buffer.
タグ付きDDPメッセージ - タグ付きバッファを対象とDDPメッセージ。
Tagged Offset (TO) - The offset within a Tagged Buffer on a Node.
ノード上のタグ付けバッファ内のオフセット - （TO）オフセットタグ付けされています。
Untagged Buffer - A buffer that is not explicitly Advertised to the Remote Peer. Untagged Buffers support one of the two available data transfer mechanisms called the Untagged Buffer Model. An Untagged Buffer is used to send asynchronous control messages to the Remote Peer for RDMA Read, Send, and Terminate requests. Untagged Buffers handle Untagged DDP Messages.
タグなしバッファ - 明示的にリモートピアにアドバタイズされていないバッファ。タグの付いていないバッファは、タグなしのバッファ・モデルと呼ばれる2つの利用可能なデータ転送メカニズムのいずれかをサポートします。タグなしバッファは、RDMA読むためのリモートピアに非同期制御メッセージを送信する送信し、要求を終了するために使用されます。タグなしバッファはタグなしDDPメッセージを処理します。
Untagged Buffer Model - A DDP data transfer model used to transfer Untagged Buffers from the Local Peer to the Remote Peer.
タグなしバッファモデル - DDPデータ転送モデルは、リモートピアにローカルピアからタグなしのバッファを転送するために使用されます。
Untagged DDP Message - A DDP Message that targets an Untagged Buffer.
タグなしDDPメッセージ - タグなしバッファを対象とDDPメッセージ。
Completion Queues (CQs) - Logical components of the RNIC Interface that conceptually represent how an RNIC notifies the ULP about the completion of the transmission of data, or the completion of the reception of data; see [RDMASEC].
完了キュー（のCQ） - 概念的RNICは、データの送信、またはデータの受信完了の完了についてULPに通知する方法を表すRNICインタフェースの論理コンポーネント。 [RDMASEC]を参照してください。
Event - An indication provided by the RDMAP layer to the ULP to indicate a Completion or other condition requiring immediate attention.
イベント - 即時の注意を必要とする補完または他の状態を示すためにULPにRDMAP層によって提供される指示。
Invalidate STag - A mechanism used to prevent the Remote Peer from reusing a previous explicitly Advertised STag, until the Local Peer makes it available through a subsequent explicit Advertisement. The STag cannot be accessed remotely until it is explicitly Advertised again.
STagを無効に - 以前明示的にアドバタイズのSTagを再利用するからリモートピアを防止するために使用するメカニズムを、ローカルピアは、後続の明示的な広告を通じて、それを利用できるようになるまで。それが明示的に再びアドバタイズされるまでのSTagは、リモートでアクセスすることはできません。
RDMA Completion (Completion, Completed, Complete, Completes) - For RDMA, Completion is defined as the process of informing the ULP that a particular RDMA Operation has performed all functions specified for the RDMA Operations, including Placement and Delivery. The Completion semantic of each RDMA Operation is distinctly defined.
RDMA完了（完了、完了、完了、を完了が） - RDMAのために、完了は、特定のRDMA動作が配置および送達を含む、RDMAオペレーションに指定されたすべての機能を実行したことをULPに通知するプロセスとして定義されます。各RDMAオペレーションの完了セマンティックがはっきりと定義されます。
RDMA Message - A data transfer mechanism used to fulfill an RDMA Operation.
RDMAメッセージ - RDMA動作を履行するために使用されるデータ転送メカニズム。
RDMA Operation - A sequence of RDMA Messages, including control Messages, to transfer data from a Data Source to a Data Sink. The following RDMA Operations are defined: RDMA Writes, RDMA Read, Send, Send with Invalidate, Send with Solicited Event, Send with Solicited Event and Invalidate, and Terminate.
RDMA操作 - 制御メッセージを含むRDMAメッセージのシーケンスは、データシンクへのデータソースからデータを転送します。以下のRDMA操作が定義されています：RDMAは、RDMA読み取りを書き込み、送信、無効化して送信し、要請イベントで送る、要請イベントおよび無効化して送信し、終了します。
RDMA Protocol (RDMAP) - A wire protocol that supports RDMA Operations to transfer ULP data between a Local Peer and the Remote Peer.
RDMAプロトコル（RDMAP） - ローカルピアとリモートピア間ULPデータを転送するRDMAオペレーションをサポートワイヤプロトコル。
RDMAP Abortive Termination (Termination, Terminated, Terminate, Terminates) - The act of closing an RDMAP Stream without attempting to Complete in-progress and pending RDMA Operations.
RDMAP頓挫（終了終了、終了、終了） - 進行中の完了しようとすると、RDMA操作を保留せずにRDMAPストリームを閉じるの行為。
RDMAP Graceful Termination - The act of closing an RDMAP Stream such that all in-progress and pending RDMA Operations are allowed to Complete successfully.
RDMAP優雅終了 - 進行中のすべての保留中のRDMA操作が正常に完了することが許可されているようなRDMAPストリームを閉じる行為。
RDMA Read - An RDMA Operation used by the Data Sink to transfer the contents of a source RDMA buffer from the Remote Peer to the Local Peer. An RDMA Read operation consists of a single RDMA Read Request Message and a single RDMA Read Response Message.
RDMA読む - ローカルピアにリモートピアからソースRDMAバッファの内容を転送するために、データシンクによって使用されるRDMA操作。 RDMA読み取り操作は、単一のRDMA読み取り要求メッセージと、単一のRDMA読み取り応答メッセージで構成されています。
RDMA Read Request - An RDMA Message used by the Data Sink to request the Data Source to transfer the contents of an RDMA buffer. The RDMA Read Request Message describes both the Data Source and Data Sink RDMA buffers.
RDMA読み取り要求 - RDMAバッファの内容を転送するデータソースを要求するために、データシンクによって使用されるRDMAメッセージ。 RDMA読み取り要求メッセージは、データソースとデータシンクRDMAバッファの両方を説明します。
RDMA Read Request Queue - The queue used for processing RDMA Read Requests. The RDMA Read Request Queue has a DDP Queue Number of 1.
RDMA読み取り要求キュー - RDMA読み取り要求を処理するために使用されるキュー。 RDMA読み取り要求キューは1のDDPキュー番号を持っています。
RDMA Read Response - An RDMA Message used by the Data Source to transfer the contents of an RDMA buffer to the Data Sink, in response to an RDMA Read Request. The RDMA Read Response Message only describes the data sink RDMA buffer.
RDMA読み取り応答 - RDMA読み出し要求に応じて、データシンクにRDMAバッファの内容を転送するデータソースによって使用されるRDMAメッセージ。 RDMA読み取り応答メッセージは、データのみがRDMAバッファをシンクについて説明します。
RDMAP Stream - An association between a pair of RDMAP implementations, possibly on different Nodes, which transfer ULP data using RDMA Operations. There may be multiple RDMAP Streams on a single Node. An RDMAP Stream maps directly to a single DDP Stream.
RDMAPストリーム - RDMAオペレーションを使用して、ULPデータを転送する可能性が異なるノード上RDMAP実装、一対の間の関連付け。単一ノード上で複数のRDMAPのストリームがあるかもしれません。 RDMAPストリームは、単一のDDPストリームに直接マップします。
RDMA Write - An RDMA Operation that transfers the contents of a source RDMA Buffer from the Local Peer to a destination RDMA Buffer at the Remote Peer using RDMA. The RDMA Write Message only describes the Data Sink RDMA buffer.
RDMAライト - RDMAを使用して、リモートピアでの宛先RDMAバッファにローカルピアからソースRDMAバッファの内容を転送RDMA操作。 RDMA書き込みメッセージは、データシンクRDMAバッファを説明します。
Remote Direct Memory Access (RDMA) - A method of accessing memory on a remote system in which the local system specifies the remote location of the data to be transferred. Employing an RNIC in the remote system allows the access to take place without interrupting the processing of the CPU(s) on the system.
リモートダイレクトメモリアクセス（RDMA） - ローカルシステムが転送するデータのリモートの場所を指定したリモート・システム上のメモリにアクセスする方法。リモートシステムでRNICを採用するとアクセスは、システム上のCPU（S）の処理を中断することなく場所を取ることができます。
Send - An RDMA Operation that transfers the contents of a ULP Buffer from the Local Peer to an Untagged Buffer at the Remote Peer.
送信 - リモートピアのタグなしバッファにローカルピアからULPバッファの内容を転送RDMA操作を。
Send Message Type - A Send Message, Send with Invalidate Message, Send with Solicited Event Message, or Send with Solicited Event and Invalidate Message.
要請イベントメッセージを送る、無効化メッセージを送信し、メッセージ送信、または要請イベントと無効化メッセージを送信 - メッセージタイプを送信します。
Send Operation Type - A Send Operation, Send with Invalidate Operation, Send with Solicited Event Operation, or Send with Solicited Event and Invalidate Operation.
要請イベント動作時に送信、または要請イベントおよび無効化動作時に送信、無効化動作時に送信、送信操作 - 操作タイプを送信します。
Solicited Event (SE) - A facility by which an RDMA Operation sender may cause an Event to be generated at the recipient, if the recipient is configured to generate such an Event, when a Send with Solicited Event Message or Send with Solicited Event and Invalidate Message is received. Note: The Local Peer's ULP can use the Solicited Event mechanism to ensure that Messages designated as important to the ULP are handled in an expeditious manner by the Remote Peer's ULP. The ULP at the Local Peer can indicate a given Send Message Type is important by using the Send with Solicited Event Message or Send with Solicited Event and Invalidate Message. The ULP at the Remote Peer can choose to only be notified when valid Send with Solicited Event Messages and/or Send with Solicited Event and Invalidate Messages arrive and handle other valid incoming Send Messages or Send with Invalidate Messages at its leisure.
要請イベント（SE） - RDMAオペレーション送信者は受信者がこのようなイベントを生成するように構成されている場合要請イベントメッセージで送信すると、イベントが受信側で発生させるか、要請イベントと無効化して送信することができるれる施設メッセージが受信されます。注意：ローカルピアのULPは、ULPに重要と指定のメッセージがリモートピアのULPにより、迅速な方法で処理されることを保証するために、要請イベントメカニズムを使用することができます。ローカルピアでのULPは、与えられたメッセージの送信タイプは、要請イベントメッセージを送信するか、要請イベントを送信し、メッセージを無効に使用して重要であることを示すことができます。リモートピアのULPは、メッセージを送信またはそのレジャーで無効化メッセージを送信し、要請イベント・メッセージを送信および/または要請イベントを送信し、メッセージが到着無効と他の有効な流入を扱うときのみ有効通知されるように選択することができます。
Terminate - An RDMA Message used by a Node to pass an error indication to the peer Node on an RDMAP Stream. This operation is for RDMAP use only.
終了 - RDMAPストリーム上のピア・ノードにエラー表示を渡すためにノードによって使用されるRDMAメッセージを。この操作はRDMAPの使用のみのためです。
ULP Buffer - A buffer owned above the RDMAP layer and Advertised to the RDMAP layer either as a Tagged Buffer or an Untagged ULP Buffer.
ULPバッファ - バッファRDMAP層の上に所有しRDMAP層のいずれかにタグ付けバッファまたはタグなしULPバッファとしてアドバタイズ。
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のを介して送信されるデータの境界は保持されます。
RDMAP MUST be layered on top of the Direct Data Placement Protocol [DDP].
RDMAPは直接データ配置プロトコル[DDP]の上に階層化されなければなりません。
RDMAP requires the following DDP support:
RDMAPには、以下のDDPのサポートが必要です。
* RDMAP uses three queues for Untagged Buffers:
* RDMAPはタグなしバッファのための3つのキューを使用しています。
* Queue Number 0 (used by RDMAP for Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate operations).
*キュー番号0（送信のためにRDMAPによって使用される、無効化して送信し、要請イベントを送信し、要請イベントと無効化操作で送信します）。
* Queue Number 1 (used by RDMAP for RDMA Read operations).
*キューナンバー1（RDMA読み取り操作でRDMAPで使用されます）。
* Queue Number 2 (used by RDMAP for Terminate operations).
*キュー番号2（動作を終了するためRDMAPによって使用されます）。
* DDP maps a single RDMA Message to a single DDP Message.
* DDPは、単一のDDPメッセージに単一のRDMAメッセージをマッピングします。
* DDP uses the STag and Tagged Offset provided by the RDMAP for Tagged Buffer Messages (i.e., RDMA Write and RDMA Read Response).
* DDPはのSTagを使用してタグ付きバッファメッセージのRDMAPによって提供されるオフセットタグ付けされた（すなわち、RDMA書き込み及びRDMA読み取り応答）。
* When the DDP layer Delivers an Untagged DDP Message to the RDMAP layer, DDP provides the length of the DDP Message. This ensures that RDMAP does not have to carry a length field in its header.
DDP層はRDMAP層のタグなしDDPメッセージを配信するとき*、DDPは、DDPメッセージの長さを提供します。これはRDMAPは、そのヘッダの長さフィールドを持ち歩く必要がないことを保証します。
* When the RDMAP layer provides an RDMA Message to the DDP layer, DDP must insert the RsvdULP field value provided by the RDMAP layer into the associated DDP Message.
* RDMAP層はDDP層にRDMAメッセージを提供する場合、DDPは、関連DDPメッセージにRDMAP層によって提供RsvdULPフィールド値を挿入する必要があります。
* When the DDP layer Delivers a DDP Message to the RDMAP layer, DDP provides the RsvdULP field.
DDP層はRDMAP層にDDPメッセージを配信するとき*、DDPはRsvdULP場を提供します。
* The RsvdULP field must be 1 octet for DDP Tagged Messages and 5 octets for DDP Untagged Messages.
* RsvdULPフィールドは、DDPタグ付きメッセージおよびタグなしDDPメッセージの5つのオクテットのための1つのオクテットでなければなりません。
* DDP propagates to RDMAP all operation or protection errors (used by RDMAP Terminate) and, when appropriate, the DDP Header fields of the DDP Segment that encountered the error.
* DDPは、（終了RDMAPによって使用される）は、すべての操作または保護エラーをRDMAPに伝播及び、適切な場合、エラーが発生しましたDDPセグメントのDDPヘッダフィールド。
* If an RDMA Operation is aborted by DDP or a lower layer, the contents of the Data Sink buffers associated with the operation are considered indeterminate.
RDMA動作をDDPまたは下位層によって中断された場合*、操作に関連付けられたデータシンクバッファの内容は不確定であると考えられます。
* DDP, in conjunction with the lower layers, provides reliable, in-order Delivery.
* DDPは、下位層に関連して、信頼性、順序配信を提供します。
RDMAP provides the ULP with access to the following RDMA Operations as defined in this specification:
本明細書で定義されるようRDMAPは、以下のRDMAオペレーションへのアクセスをULPを提供します。
* Send
*送信
* Send with Solicited Event
*要請イベントを送ります
* Send with Invalidate
*無効化して送信します
* Send with Solicited Event and Invalidate
*要請イベントおよび無効化して送信します
* RDMA Write
* RDMA書き込み
* RDMA Read
* RDMA読みます
For Send Operation Types, the following are the interactions between the RDMAP layer and the ULP:
操作タイプを送信するために、次はRDMAP層とULPの間の相互作用は、次のとおりです。
* At the Data Source:
*データ・ソースで：
* The ULP passes to the RDMAP layer the following:
* ULPは、次のRDMAP層に渡します。
* ULP Message Length
* ULPメッセージの長さ
* ULP Message
* ULPメッセージ
* An indication of the Send Operation Type, where the valid types are: Send, Send with Solicited Event, Send with Invalidate, or Send with Solicited Event and Invalidate.
*有効なタイプがある操作タイプ、送信の目安：無効化して送信し、要請イベントを送信、送信、または要請イベントおよび無効化して送信します。
* An Invalidate STag, if the Send Operation Type was Send with Invalidate or Send with Solicited Event and Invalidate.
*無効化のSTag、操作タイプを送信する場合は、無効化して送信するか、要請イベントおよび無効化して送信しました。
* When the Send Operation Type Completes, an indication of the Completion results.
*ときは操作タイプを完了、完了結果の表示を送信します。
* At the Data Sink:
*データシンクで：
* If the Send Operation Type Completed successfully, the RDMAP layer passes the following information to the ULP Layer:
送信操作の種類が正常に完了した場合*、RDMAP層は、ULP層に以下の情報を渡します。
* ULP Message Length
* ULPメッセージの長さ
* ULP Message
* ULPメッセージ
* An Event, if the Data Sink is configured to generate an Event.
*イベント、データシンクがイベントを生成するように構成されている場合。
* An Invalidated STag, if the Send Operation Type was Send with Invalidate or Send with Solicited Event and Invalidate.
*無効化さのSTag、送信操作タイプを無効化して送信するか、要請イベントと無効化を送信した場合。
* If the Send Operation Type Completed in error, the Data Sink RDMAP layer will pass up the corresponding error information to the Data Sink ULP and send a Terminate Message to the Data Source RDMAP layer. The Data Source RDMAP layer will then pass up the Terminate Message to the ULP.
*エラーに完成送信操作の種類は、データシンクRDMAP層は、データシンクULPに対応するエラー情報を渡すと、データソースRDMAP層に終了メッセージを送信する場合。データソースRDMAP層は、ULPに終了メッセージを渡します。
For RDMA Write operations, the following are the interactions between the RDMAP layer and the ULP:
RDMA書き込み操作のために、以下ではRDMAP層とULPの間の相互作用です。
* At the Data Source:
*データ・ソースで：
* The ULP passes to the RDMAP layer the following:
* ULPは、次のRDMAP層に渡します。
* ULP Message Length
* ULPメッセージの長さ
* ULP Message
* ULPメッセージ
* Data Sink STag
*データシンクのSTag
* Data Sink Tagged Offset
*データシンクタグ付きオフセット
* When the RDMA Write operation Completes, an indication of the Completion results.
* RDMA書き込み操作は、完了結果の表示を完了します。
* At the Data Sink:
*データシンクで：
* If the RDMA Write completed successfully, the RDMAP layer does not Deliver the RDMA Write to the ULP. It does Place the ULP Message transferred through the RDMA Write Message into the ULP Buffer.
* RDMA書き込みが正常に完了した場合、RDMAP層はULPにRDMA書き込みを配信しません。これは、ULPバッファにRDMA書き込みメッセージを介して転送ULPメッセージを置きありません。
* If the RDMA Write completed in error, the Data Sink RDMAP layer will pass up the corresponding error information to the Data Sink ULP and send a Terminate Message to the Data Source RDMAP layer. The Data Source RDMAP layer will then pass up the Terminate Message to the ULP.
RDMA書き込みがエラーで終了した場合*、データシンクRDMAP層は、データシンクULPに対応するエラー情報を渡すと、データソースRDMAP層に終了メッセージを送信します。データソースRDMAP層は、ULPに終了メッセージを渡します。
For RDMA Read operations, the following are the interactions between the RDMAP layer and the ULP:
RDMA読み取り操作については、以下ではRDMAP層とULPの間の相互作用は、次のとおりです。
* At the Data Sink:
*データシンクで：
* The ULP passes to the RDMAP layer the following:
* ULPは、次のRDMAP層に渡します。
* ULP Message Length
* ULPメッセージの長さ
* Data Source STag
*データソースのSTag
* Data Sink STag
*データシンクのSTag
* Data Source Tagged Offset
*データソースは、オフセットタグ
* Data Sink Tagged Offset
*データシンクタグ付きオフセット
* When the RDMA Read operation Completes, an indication of the Completion results.
* RDMA読み取り操作は、完了結果の表示を完了します。
* At the Data Source:
*データ・ソースで：
* If no error occurred while processing the RDMA Read Request, the Data Source will not pass up any information to the ULP.
* RDMA読み取り要求を処理中にエラーが発生しなかった場合は、データソースがULPに情報を渡しません。
* If an error occurred while processing the RDMA Read Request, the Data Source RDMAP layer will pass up the corresponding error information to the Data Source ULP and send a Terminate Message to the Data Sink RDMAP layer. The Data Sink RDMAP layer will then pass up the Terminate Message to the ULP.
* RDMA読み取り要求を処理中にエラーが発生した場合は、データソースRDMAP層がデータソースULPに対応するエラー情報を渡すと、データシンクRDMAP層に終了メッセージを送信します。データシンクRDMAP層は、ULPに終了メッセージを渡します。
For STags made available to the RDMAP layer, following are the interactions between the RDMAP layer and the ULP:
RDMAP層に利用可能スタッグスため、以下ではRDMAP層とULPの間の相互作用です。
* If the ULP enables an STag, the ULP passes the following to the RDMAP layer:
ULPはのSTagを有効にした場合*、ULPはRDMAP層に次を渡します。
* STag;
* 男性だけの;
* range of Tagged Offsets that are associated with a given STag;
*所与のSTagに関連付けられたタグ付きオフセットの範囲。
* remote access rights (read, write, or read and write) associated with a given, valid STag; and
*リモートアクセス権（読み取り、書き込み、または読み取りと書き込み）与えられた、有効なのSTagに関連付けられています。そして
* association between a given STag and a given RDMAP Stream.
*与えられたのSTagと与えられたRDMAPストリーム間の関連付け。
* If the ULP disables an STag, the ULP passes to the RDMAP layer the STag.
ULPはのSTagを無効にした場合*、ULPはRDMAP層のSTagに渡します。
If an error occurs at the RDMAP layer, the RDMAP layer may pass back error information (e.g., the content of a Terminate Message) to the ULP.
エラーがRDMAP層で発生した場合、RDMAP層はULPにエラー情報（例えば、終了メッセージの内容）バック通過することができます。
The control information of RDMA Messages is included in DDP protocol-defined header fields, with the following exceptions:
RDMAメッセージの制御情報は、次の例外を除いて、DDPプロトコル定義のヘッダフィールドに含まれています。
* The first octet reserved for ULP usage on all DDP Messages in the DDP Protocol (i.e., the RsvdULP Field) is used by RDMAP to carry the RDMA Message Opcode and the RDMAP version. This octet is known as the RDMAP Control Field in this specification. For Send with Invalidate and Send with Solicited Event and Invalidate, RDMAP uses the second through fifth octets, provided by DDP on Untagged DDP Messages, to carry the STag that will be Invalidated.
* DDPプロトコル（すなわち、RsvdULPフィールド）内の全てのDDPメッセージにULPの使用のために予約最初のオクテットは、RDMAメッセージオペコードとRDMAPバージョンを運ぶためにRDMAPによって使用されます。このオクテットは、この仕様でRDMAP制御フィールドとして知られています。無効化して送信し、要請イベントや無効化して送信し、RDMAPが無効になるのSTagを運ぶために、タグなしDDPメッセージにDDPが提供する、第五オクテットを介して第2を使用しています。
* The RDMA Message length is passed by the RDMAP layer to the DDP layer on all outbound transfers.
* RDMAメッセージの長さは、すべての発信転送にDDP層にRDMAP層によって渡されます。
* For RDMA Read Request Messages, the RDMA Read Message Size is included in the RDMA Read Request Header.
* RDMA読み取り要求メッセージについては、RDMA読み取りメッセージサイズは、RDMA読み取り要求ヘッダーに含まれています。
* The RDMA Message length is passed to the RDMAP layer by the DDP layer on inbound Untagged Buffer transfers.
* RDMAメッセージの長さは、インバウンドタグなしバッファ転送にDDP層によってRDMAP層に渡されます。
* Two RDMA Messages carry additional RDMAP headers. The RDMA Read Request carries the Data Sink and Data Source buffer descriptions, including buffer length. The Terminate carries additional information associated with the error that caused the Terminate.
*二つのRDMAメッセージが追加RDMAPヘッダを運びます。 RDMA読み取り要求は、バッファの長さを含むデータシンクとデータソースバッファの説明を、運びます。終了終了原因となったエラーに関連する追加情報を搬送します。
The version of RDMAP defined by this specification uses all 8 bits of the RDMAP Control Field. The first octet reserved for ULP use in the DDP Protocol MUST be used by the RDMAP to carry the RDMAP Control Field. The ordering of the bits in the first octet MUST be as defined in Figure 3, "DDP Control, RDMAP Control, and Invalidate STag Fields". For Send with Invalidate and Send with Solicited Event and Invalidate, the second through fifth octets of the DDP RsvdULP field MUST be used by RDMAP to carry the Invalidate STag. Figure 3 depicts the format of the DDP Control and RDMAP Control fields. (Note: In Figure 3, 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.)
この仕様で定義されたRDMAPのバージョンはRDMAP制御フィールドのすべての8ビットを使用します。 DDPプロトコルにおけるULPの使用のために予約最初のオクテットはRDMAP制御フィールドを運ぶためにRDMAPによって使用されなければなりません。 「DDPコントロール、RDMAP制御、および無効化のSTagフィールド」、図3で定義されるように最初のオクテットのビットの順序でなければなりません。以下のための無効化して送信し、要請イベントと無効化、無効化のSTagを運ぶためにRDMAPによって使用されなければならないDDP RsvdULPフィールドの第五のオクテットを介して第2と送ります。図3は、DDP制御とRDMAPコントロールフィールドのフォーマットを示しています。 （注：DDPは、MPAの上部に積層されている場合は、図3において、DDPヘッダが[MPA]で定義されたMPAヘッダに対応するために16ビットだけオフセットされる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| Resrv | DV| RV|Rsv| Opcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DDP Control, RDMAP Control, and Invalidate STag Fields
図3：DDPコントロール、RDMAPコントロール、および無効化のSTagフィールド
All RDMA Messages handed by the RDMAP layer to the DDP layer MUST define the value of the Tagged flag in the DDP Header. Figure 4, "RDMA Usage of DDP Fields", MUST be used to define the value of the Tagged flag that is handed to the DDP layer for each RDMA Message.
DDP層にRDMAP層によって渡さ全てRDMAメッセージDDPヘッダのタグ付きフラグの値を定義しなければなりません。図4は、「DDPフィールドのRDMAの使用」とは、各RDMAメッセージのDDP層に渡されるタグ付きフラグの値を定義するために使用されなければなりません。
Figure 4 defines the value of the RDMA Opcode field that MUST be used for each RDMA Message.
図4は、各RDMAメッセージのために使用しなければならないRDMAオペコードフィールドの値を定義します。
Figure 4 defines when the STag, Queue Number, and Tagged Offset fields MUST be provided for each RDMA Message.
図4はのSTag、キュー番号、およびタグ付きフィールドをオフセットは、各RDMAメッセージのために提供しなければならないときに定義します。
For this version of the RDMAP, all RDMA Messages MUST have:
RDMAPのこのバージョンでは、すべてのRDMAメッセージを持っている必要があります。
* Bits 24-25; RDMA Version field: 01b for an RNIC that complies with this RDMA protocol specification. 00b for an RNIC that complies with the RDMA Consortium's RDMA protocol specification. Both version numbers are valid. Interoperability is dependent on MPA protocol version negotiation (e.g., MPA marker and MPA CRC).
*ビット24-25。 RDMAバージョンフィールド：このRDMAプロトコル仕様に準拠していますRNICため01B。 RDMAコンソーシアムのRDMAプロトコル仕様に準拠していますRNICため00B。どちらのバージョン番号が有効です。相互運用性（例えば、MPAマーカおよびMPA CRC）MPAプロトコルバージョンネゴシエーションに依存しています。
* Bits 26-27; Reserved. MUST be set to zero by sender, ignored by the receiver.
*ビット26-27。予約済み。受信機で無視し、送信者によってゼロに設定しなければなりません。
* Bits 28-31; OpCode field: see Figure 4.
*ビット28-31。オペコード・フィールド：図4を参照してください。
* Bits 32-63; Invalidate STag. However, this field is only valid for Send with Invalidate and Send with Solicited Event and Invalidate Messages (see Figure 4).
*ビット32-63。 STagを無効にします。無効化して送信し、要請イベントを送信し、メッセージを無効にするためにしかし、このフィールドは（図4を参照）のみ有効です。
For Send, Send with Solicited Event, RDMA Read Request, and Terminate, the Invalidate STag field MUST be set to zero on transmit and ignored by the receiver.
以下のために要請イベント、RDMA読み取り要求を送信し、送信し、終了、無効化クワガタフィールドは、送信時にゼロに設定され、受信機で無視しなければなりません。
-------+-----------+-------+------+-------+-----------+--------------
RDMA | Message | Tagged| STag | Queue | Invalidate| Message
Message| Type | Flag | and | Number| STag | Length
OpCode | | | TO | | | Communicated
| | | | | | between DDP
| | | | | | and RDMAP
-------+-----------+-------+------+-------+-----------+--------------
0000b | RDMA Write| 1 | Valid| N/A | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0001b | RDMA Read | 0 | N/A | 1 | N/A | Yes
| Request | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0010b | RDMA Read | 1 | Valid| N/A | N/A | Yes
| Response | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0011b | Send | 0 | N/A | 0 | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0100b | Send with | 0 | N/A | 0 | Valid | Yes
| Invalidate| | | | |
-------+-----------+-------+------+-------+-----------+--------------
0101b | Send with | 0 | N/A | 0 | N/A | Yes
| SE | | | | |
-------+-----------+-------+------+-------+-----------+--------------
0110b | Send with | 0 | N/A | 0 | Valid | Yes
| SE and | | | | |
| Invalidate| | | | |
-------+-----------+-------+------+-------+-----------+--------------
0111b | Terminate | 0 | N/A | 2 | N/A | Yes
| | | | | |
-------+-----------+-------+------+-------+-----------+--------------
1000b | |
to | Reserved | Not Specified
1111b | |
-------+-----------+-------------------------------------------------
Figure 4: RDMA Usage of DDP Fields
図4：DDPフィールドのRDMAの使用
Note: N/A means Not Applicable.
注意：N / Aは該当なしを意味します。
The following figure defines which RDMA Headers MUST be used on each RDMA Message and which RDMA Messages are allowed to carry ULP Payload:
次の図は、RDMAヘッダは、RDMAメッセージがULPペイロードを運ぶために許可されている各RDMAメッセージとに使用されなければならないかを定義します。
-------+-----------+-------------------+-------------------------
RDMA | Message | RDMA Header Used | ULP Message allowed in
Message| Type | | the RDMA Message
OpCode | | |
| | |
-------+-----------+-------------------+-------------------------
0000b | RDMA Write| None | Yes
| | |
-------+-----------+-------------------+-------------------------
0001b | RDMA Read | RDMA Read Request | No
| Request | Header |
-------+-----------+-------------------+-------------------------
0010b | RDMA Read | None | Yes
| Response | |
-------+-----------+-------------------+-------------------------
0011b | Send | None | Yes
| | |
-------+-----------+-------------------+-------------------------
0100b | Send with | None | Yes
| Invalidate| |
-------+-----------+-------------------+-------------------------
0101b | Send with | None | Yes
| SE | |
-------+-----------+-------------------+-------------------------
0110b | Send with | None | Yes
| SE and | |
| Invalidate| |
-------+-----------+-------------------+-------------------------
0111b | Terminate | Terminate Header | No
| | |
-------+-----------+-------------------+-------------------------
1000b | |
to | Reserved | Not Specified
1111b | |
-------+-----------+-------------------+-------------------------
Figure 5: RDMA Message Definitions
図5：RDMAメッセージの定義
The RDMA Write Message does not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The RDMA Write Message is fully described by the DDP Headers of the DDP Segments associated with the Message.
RDMA書き込みメッセージはRDMAPヘッダーが含まれていません。 RDMAP層は、DDP層RDMAP制御フィールドに進みます。 RDMA書き込みメッセージは、完全メッセージに関連付けられたDDPセグメントのDDPヘッダによって記述されます。
See Appendix A for a description of the DDP Segment format associated with RDMA Write Messages.
RDMA書き込みメッセージに関連したDDPセグメント形式の説明については、付録Aを参照してください。
The RDMA Read Request Message carries an RDMA Read Request Header that describes the Data Sink and Data Source Buffers used by the RDMA Read operation. The RDMA Read Request Header immediately follows the DDP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The following figure depicts the RDMA Read Request Header that MUST be used for all RDMA Read Request Messages:
RDMA読み取り要求メッセージは、データシンクとRDMA読み取り操作で使用するデータソース・バッファを記述するRDMA読み取り要求ヘッダーを運びます。 RDMA読み取り要求ヘッダーはすぐにDDPヘッダの後に続きます。 RDMAP層は、DDP層RDMAP制御フィールドに進みます。次の図は、すべてのRDMA読み取り要求メッセージを使用しなければなりませんRDMA読み取り要求ヘッダーを表しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag (SinkSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Sink Tagged Offset (SinkTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Message Size (RDMARDSZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source STag (SrcSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Source Tagged Offset (SrcTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RDMA Read Request Header Format
図6：RDMA読み出し要求ヘッダーフォーマット
Data Sink Steering Tag: 32 bits.
データシンクステアリングタグ：32ビット。
The Data Sink Steering Tag identifies the Data Sink's Tagged
Buffer. This field MUST be copied, without interpretation,
from the RDMA Read Request into the corresponding RDMA Read
Response; this field allows the Data Sink to place the
returning data. The STag is associated with the RDMAP Stream
through a mechanism that is outside the scope of the RDMAP
specification.
Data Sink Tagged Offset: 64 bits.
データシンクタグ付きオフセット：64ビット。
The Data Sink Tagged Offset specifies the starting offset, in
octets, from the base of the Data Sink's Tagged Buffer, where
the data is to be written by the Data Source. This field is
copied from the RDMA Read Request into the corresponding RDMA
Read Response and allows the Data Sink to place the returning
data. The Data Sink Tagged Offset MAY start at an arbitrary
offset.
The Data Sink STag and Data Sink Tagged Offset fields describe the buffer to which the RDMA Read data is written.
データシンクのSTagとデータシンクタグ付きフィールドは、RDMA読み取りデータが書き込まれるバッファを記述するオフセット。
Note: the DDP layer protects against a wrap of the Data Sink Tagged Offset.
注意：DDP層は、データシンクタグ付きのラップオフセットから保護します。
RDMA Read Message Size: 32 bits.
RDMA読み取りメッセージサイズ：32ビット。
The RDMA Read Message Size is the amount of data, in octets,
read from the Data Source. A single RDMA Read Request
Message can retrieve from 0 to 2^32-1 data octets from the
Data Source.
Data Source Steering Tag: 32 bits.
データソースステアリングタグ：32ビット。
The Data Source Steering Tag identifies the Data Source's
Tagged Buffer. The STag is associated with the RDMAP Stream
through a mechanism that is outside the scope of the RDMAP
specification.
Data Source Tagged Offset: 64 bits.
データソースのタグ付けオフセット：64ビット。
The Tagged Offset specifies the starting offset, in octets,
that is to be read from the Data Source's Tagged Buffer. The
Data Source Tagged Offset MAY start at an arbitrary offset.
The Data Source STag and Data Source Tagged Offset fields describe the buffer from which the RDMA Read data is read.
データソースのSTagおよびデータソースは、オフセットフィールドがRDMA読み取りデータが読み出されるバッファを記述するタグ付き。
See Section 7.2, "Errors Detected at the Remote Peer on Incoming RDMA Messages", for a description of error checking required upon processing of an RDMA Read Request at the Data Source.
データソースのRDMA読み取り要求の処理時に必要なエラーチェックの説明については、7.2節、「受信RDMAメッセージ上のリモートピアで検出されたエラー」を参照してください。
The RDMA Read Response Message does not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The RDMA Read Response Message is fully described by the DDP Headers of the DDP Segments associated with the Message.
RDMA読み取り応答メッセージはRDMAPヘッダーが含まれていません。 RDMAP層は、DDP層RDMAP制御フィールドに進みます。 RDMA読み取り応答メッセージは、完全メッセージに関連付けられたDDPセグメントのDDPヘッダによって記述されます。
See Appendix A for a description of the DDP Segment format associated with RDMA Read Response Messages.
RDMA読み取り応答メッセージに関連したDDPセグメント形式の説明については、付録Aを参照してください。
The Send and Send with Solicited Event Messages do not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The Send and Send with Solicited Event Messages are fully described by the DDP Headers of the DDP Segments associated with the Messages.
送信とはRDMAPヘッダーを含まない要請イベント・メッセージを送信します。 RDMAP層は、DDP層RDMAP制御フィールドに進みます。要請イベントに送信し、送信したメッセージは、完全メッセージに関連付けられたDDPセグメントのDDPヘッダに記載されています。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
送信に関連したDDPセグメント形式の説明については、付録Aを参照してくださいと要請イベント・メッセージを送信します。
The Send with Invalidate and Send with Solicited Event and Invalidate Messages do not include an RDMAP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field and the Invalidate STag field (see section 4.1 RDMAP Control and Invalidate STag Field). The Send with Invalidate and Send with Solicited Event and Invalidate Messages are fully described by the DDP Headers of the DDP Segments associated with the Messages.
無効化して送信し、要請イベントを送るとRDMAPヘッダーを含まないメッセージを無効にします。 RDMAP層は（セクション4.1 RDMAP制御および無効化のSTagフィールドを参照）DDP層RDMAP制御フィールドおよび無効化のSTagフィールドに渡します。無効化して送信し、要請イベントに送信し、無効化メッセージは、完全メッセージに関連付けられたDDPセグメントのDDPヘッダに記載されています。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
送信に関連したDDPセグメント形式の説明については、付録Aを参照してくださいと要請イベント・メッセージを送信します。
The Terminate Message carries a Terminate Header that contains additional information associated with the cause of the Terminate. The Terminate Header immediately follows the DDP header. The RDMAP layer passes to the DDP layer an RDMAP Control Field. The following figure depicts a Terminate Header that MUST be used for the Terminate Message:
終了メッセージ終了の原因に関連する追加情報が含まれて終了ヘッダーを運びます。終了ヘッダー直ちにDDPヘッダの後に続きます。 RDMAP層は、DDP層RDMAP制御フィールドに進みます。次の図は、終了メッセージを使用しなければなりません終了ヘッダーを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Terminate Control | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Segment Length (if any) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
// //
| Terminated DDP Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
| Terminated RDMA Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Terminate Header Format
図7：ヘッダー形式を終了
Terminate Control: 19 bits.
19ビット：コントロールを終了します。
The Terminate Control field MUST have the format defined in
Figure 8 below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Layer | EType | Error Code |HdrCt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Terminate Control Field
図8：コントロールフィールドを終了
* Figure 9, "Terminate Control Field Values", defines the valid values that MUST be used for this field.
*図9は、このフィールドのために使用しなければならない有効な値を定義する「コントロールフィールド値を終了します」。
* Layer: 4 bits.
*レイヤー：4ビット。
Identifies the layer that encountered the error.
エラーが発生しまし層を識別します。
* EType (RDMA Error Type): 4 bits.
* ETYPE（RDMAのエラータイプ）：4ビット。
Identifies the type of error that caused the Terminate. When the error is detected at the RDMAP layer, the RDMAP layer inserts the Error Type into this field. When the error is detected at an LLP layer, an LLP layer creates the Error Type and the DDP layer passes it up to the RDMAP layer, and the RDMAP layer inserts it into this field.
終了原因となったエラーの種類を識別します。エラーがRDMAP層で検出された場合、RDMAP層は、このフィールドにエラーの種類を挿入します。エラーがLLP層で検出された場合、LLP層がエラータイプを作成し、DDP層はRDMAP層にそれを通過し、RDMAP層は、このフィールドに挿入します。
* Error Code: 8 bits.
*エラーコード：8ビット。
This field identifies the specific error that caused the Terminate. When the error is detected at the RDMAP layer, the RDMAP layer creates the Error Code. When the error is detected at an LLP layer, the LLP layer creates the Error Code, the DDP layer passes it up to the RDMAP layer, and the RDMAP layer inserts it into this field.
このフィールドは、終了原因特定のエラーを識別します。エラーがRDMAP層で検出された場合、RDMAP層は、エラーコードを作成します。エラーがLLP層で検出された場合、LLP層がDDP層はRDMAP層にそれを通過し、エラーコードを作成し、RDMAP層は、このフィールドに挿入します。
* HdrCt: 3 bits.
* HdrCt：3ビット。
Header control bits:
ヘッダ制御ビット：
* M: bit 16. DDP Segment Length valid. See Figure 10 for when this bit SHOULD be set.
* M：有効ビット16 DDPセグメント長。このビットがセットされるべき時については、図10を参照してください。
* D: bit 17. DDP Header Included. See Figure 10 for when this bit SHOULD be set.
* D：ビット17. DDPヘッダーが含まれています。このビットがセットされるべき時については、図10を参照してください。
* R: bit 18. RDMAP Header Included. See Figure 10 for when this bit SHOULD be set.
* R：ビット18 RDMAPヘッダーが含まれています。このビットがセットされるべき時については、図10を参照してください。
-------+-----------+-------+-------------+------+--------------------
Layer | Layer | Error | Error Type | Error| Error Code Name
| Name | Type | Name | Code |
-------+-----------+-------+-------------+------+--------------------
| | 0000b | Local | None | None - This error
| | | Catastrophic| | type does not have
| | | Error | | an error code. Any
| | | | | value in this field
| | | | | is acceptable.
| +-------+-------------+------+--------------------
| | | | 00X | Invalid STag
| | | +------+--------------------
| | | | 01X | Base or bounds
| | | | | violation
| | | Remote +------+--------------------
| | 0001b | Protection | 02X | Access rights
| | | Error | | violation
| | | +------+--------------------
0000b | RDMA | | | 03X | STag not associated
| | | | | with RDMAP Stream
| | | +------+--------------------
| | | | 04X | TO wrap
| | | +------+--------------------
| | | | 09X | STag cannot be
| | | | | Invalidated
| | | +------+--------------------
| | | | FFX | Unspecified Error
| +-------+-------------+------+--------------------
| | | | 05X | Invalid RDMAP
| | | | | version
| | | +------+--------------------
| | | | 06X | Unexpected OpCode
| | | Remote +------+--------------------
| | 0010b | Operation | 07X | Catastrophic error,
| | | Error | | localized to RDMAP
| | | | | Stream
| | | +------+--------------------
| | | | 08X | Catastrophic error,
| | | | | global
| | | +------+--------------------
| | | | 09X | STag cannot be
| | | | | Invalidated
| | | +------+--------------------
| | | | FFX | Unspecified Error
-------+-----------+-------+-------------+------+--------------------
0001b | DDP | See DDP Specification [DDP] for a description of
| | the values and names.
-------+-----------+-------+-----------------------------------------
0010b | LLP | For MPA, see MPA Specification [MPA] for a
|(e.g., MPA)| description of the values and names.
-------+-----------+-------+-----------------------------------------
Figure 9: Terminate Control Field Values
図9：コントロールフィールド値を終了
Reserved: 13 bits. This field MUST be set to zero on transmit, ignored on receive.
予約：13ビット。このフィールドは、受信時に無視され、送信時にゼロに設定しなければなりません。
DDP Segment Length: 16 bits
DDPセグメント長：16ビット
The length handed up by the DDP layer when the error was
detected. It MUST be valid if the M bit is set. It MUST be
present when the D bit is set.
Terminated DDP Header: 112 bits for Tagged Messages and 144 bits for Untagged Messages.
終了DDPヘッダ：タグ付きメッセージの112ビットおよびタグなしメッセージの144ビット。
The DDP Header of the incoming Message that is associated
with the Terminate. The DDP Header is not present if the
Terminate Error Type is a Local Catastrophic Error. It MUST
be present if the D bit is set.
Terminated RDMA Header: 224 bits.
RDMAヘッダを終了：224ビット。
The Terminated RDMA Header is only sent back if the terminate
is associated with an RDMA Read Request Message. It MUST be
present if the R bit is set.
If the terminate occurs before the first RDMA Read Request byte is processed, the original RDMA Read Request Header is sent back.
最初のRDMA読み取り要求バイトが処理される前に終了が発生した場合は、オリジナルのRDMA読み取り要求ヘッダが返送されます。
If the terminate occurs after the first RDMA Read Request byte is processed, the RDMA Read Request Header is updated to reflect the current location of the RDMA Read operation that is in process:
終了した場合は、最初のRDMAの読み出し要求のバイトが処理された後、RDMA読み取り要求ヘッダーは、プロセスであるRDMA読み取り操作の現在の場所を反映するように更新されて発生します。
* Data Sink STag = Data Sink STag originally sent in the
RDMA Read Request.
* Data Sink Tagged Offset = Current offset into the Data Sink Tagged Buffer. For example, if the RDMA Read Request was terminated after 2048 octets were sent, then the Data Sink Tagged Offset = the original Data Sink Tagged Offset + 2048.
*データシンクタグ付きデータシンクタグ付きバッファへのオフセット=現在のオフセット。例えば、RDMA読み出し要求が2048のオクテットが送信された後に終了した場合、データシンクタグ付きは、元のデータシンクタグ付きは+ 2048をオフセット=オフセット。
* Data Message size = Number of bytes left to transfer.
*データのメッセージサイズ=バイト数を転送するために残しました。
* Data Source STag = Data Source STag in the RDMA Read Request.
* RDMA読み出し要求におけるデータソースのSTag =データソースのSTag。
* Data Source Tagged Offset = Current offset into the Data Source Tagged Buffer. For example, if the RDMA Read Request was terminated after 2048 octets were sent, then the Data Source Tagged Offset = the original Data Source Tagged Offset + 2048.
*データソースは、データソースのタグ付けバッファへのオフセットのオフセット=現在のタグ付き。 RDMA読み出し要求が2048のオクテットが送信された後に終了した場合たとえば、その後、データソースは、元のデータソースは、+ 2048オフセットタグ付けされた=オフセットタグ付けされています。
Note: if a given LLP does not define any termination codes for the RDMAP Termination message to use, then none would be used for that LLP.
注：所与のLLPは、使用するRDMAP終了メッセージのための任意の終了コードを定義していない場合、いずれもそのLLPのために使用されないであろう。
Figure 10, "Error Type to RDMA Message Mapping", maps layer name and error types to each RDMA Message type:
図10、「RDMAメッセージへのマッピングエラータイプ」、各RDMAメッセージタイプにマップレイヤ名とエラーの種類：
---------+-------------+------------+------------+-----------------
Layer | Error Type | Terminate | Terminate | What type of
Name | Name | Includes | Includes | RDMA Message can
| | DDP Header | RDMA Header| cause the error
| | and DDP | |
| | Segment | |
| | Length | |
---------+-------------+------------+------------+-----------------
| Local | No | No | Any
| Catastrophic| | |
| Error | | |
+-------------+------------+------------+-----------------
| Remote | Yes, if | Yes | Only RDMA Read
RDMA | Protection | possible | | Request, Send
| Error | | | with Invalidate,
| | | | and Send with SE
| | | | and Invalidate
+-------------+------------+------------+-----------------
| Remote | Yes, if | No | Any
| Operation | possible | |
| Error | | |
---------+-------------+------------+------------+-----------------
DDP | See DDP Spec| Yes | No | Any
| [DDP] | | |
---------+-------------+------------+------------+-----------------
LLP | See LLP Spec| No | No | Any
| (e.g., MPA) | | |
Figure 10: Error Type to RDMA Message Mapping
図10：RDMAメッセージへのマッピングエラータイプ
An RDMA Write is used by the Data Source to transfer data to a previously Advertised Tagged Buffer at the Data Sink. The RDMA Write Message has the following semantics:
RDMA書き込みはデータシンクで以前にアドバタイズタグ付けバッファにデータを転送するデータソースで使用されています。 RDMA書き込みメッセージは、以下の意味を持っています：
* An RDMA Write Message MUST reference a Tagged Buffer. That is, the Data Source RDMAP layer MUST request that the DDP layer mark the Message as Tagged.
* RDMA書き込みメッセージは、タグ付きバッファを参照する必要があります。つまり、データソースRDMAP層はDDP層はタグ付きとしてメッセージをマークすることを要求しなければなりません。
* A valid RDMA Write Message MUST NOT be delivered to the Data Sink's ULP (i.e., it is placed by the DDP layer).
*有効なRDMA書き込みメッセージは、データシンクのULP（すなわち、それはDDP層によって配置されます）に配信されてはなりません。
* At the Remote Peer, when an invalid RDMA Write Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced (see Section 7.1, "RDMAP Error Surfacing").
*リモートピアで、無効なRDMA書き込みメッセージは、リモートピアのRDMAP層、エラーが浮上している（7.1節、「RDMAPエラーサーフェス」を参照）に配信されます。
* The Tagged Offset of a Tagged Buffer MAY start at a non-zero value.
*タグ付きバッファのオフセットタグ付き非ゼロ値で開始してもよいです。
* An RDMA Write Message MAY target all or part of a previously Advertised Buffer.
* RDMA書き込みメッセージは、以前にアドバタイズバッファの全部または一部を標的とすることができます。
* The RDMAP does not define how the buffer(s) are used by an outbound RDMA Write or how they are addressed. For example, an implementation of RDMA may choose to allow a gather-list of non-contiguous data blocks to be the source of an RDMA Write. In this case, the data blocks would be combined by the Data Source and sent as a single RDMA Write Message to the Data Sink.
* RDMAPは、バッファ（複数可）、アウトバウンドRDMA書き込みによって使用されているか、それらがどのように対処する方法を定義していません。例えば、RDMAの実装は、非連続的なデータブロックの収集リストは、RDMA書き込みのソースを許可するように選択できます。この場合、データブロックは、データソースによって結合されるだろうとのデータシンクへの単一のRDMA書き込みメッセージとして送信します。
* The Data Source RDMAP layer MUST issue RDMA Write Messages to the DDP layer in the order they were submitted by the ULP.
*データソースRDMAP層は、彼らがULPにより提出された順序でDDP層にRDMA書き込みメッセージを発行しなければなりません。
* At the Data Source, a subsequent Send (Send with Invalidate, Send with Solicited Event, or Send with Solicited Event and Invalidate) Message MAY be used to signal Delivery of previous RDMA Write Messages to the Data Sink, if the ULP chooses to signal Delivery in this fashion.
ULPが合図することを選択した場合*データソースでは、その後の送信（要請イベントで送る、無効化して送信、または要請イベントおよび無効化して送信）メッセージは、データシンクへ前のRDMA書き込みメッセージの配信を知らせるために使用されるかもしれこのやり方で配信。
* If the Local Peer wishes to write to multiple Tagged Buffers on the Remote Peer, the Local Peer MUST use multiple RDMA Write Messages. That is, a single RDMA Write Message can only write to one remote Tagged Buffer.
*ローカルピアがリモートピアに複数のタグ付きバッファへの書き込みを希望する場合は、ローカルピアは、複数のRDMA書き込みメッセージを使用しなければなりません。これは、単一のRDMA書き込みメッセージは一つだけのリモートタグ付けバッファに書き込むことができ、あります。
* The Data Source MAY issue a zero-length RDMA Write Message.
*データソースは、長さゼロのRDMA書き込みメッセージを発行することができます。
The RDMA Read operation MUST consist of a single RDMA Read Request Message and a single RDMA Read Response Message.
RDMA読み取り操作は、単一のRDMA読み取り要求メッセージと、単一のRDMA読み取り応答メッセージで構成する必要があります。
An RDMA Read Request is used by the Data Sink to transfer data from a previously Advertised Tagged Buffer at the Data Source to a Tagged Buffer at the Data Sink. The RDMA Read Request Message has the following semantics:
RDMA読み取り要求は、データシンクでタグ付けバッファにデータソースで以前にアドバタイズタグ付けバッファからデータを転送するために、データシンクによって使用されます。 RDMA読み取り要求メッセージは、次の意味があります。
* An RDMA Read Request Message MUST reference an Untagged Buffer. That is, the Local Peer's RDMAP layer MUST request that the DDP mark the Message as Untagged.
* RDMA読み取り要求メッセージは、タグなしのバッファを参照する必要があります。これはローカルピアのRDMAP層はDDPがタグなしとしてメッセージをマークすることを要求しなければならない、です。
* One RDMA Read Request Message MUST consume one Untagged Buffer.
* 1タグなしのバッファを消費しなければならない一つのRDMA読み取り要求メッセージ。
* The Remote Peer's RDMAP layer MUST process an RDMA Read Request Message. A valid RDMA Read Request Message MUST NOT be delivered to the Data Sink's ULP (i.e., it is processed by the RDMAP layer).
*リモートピアのRDMAP層は、RDMA読み取り要求メッセージを処理しなければなりません。有効なRDMA読み取り要求メッセージは、データシンクのULP（すなわち、それはRDMAP層によって処理される）に配信されてはなりません。
* At the Remote Peer, when an invalid RDMA Read Request Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced (see Section 7.1, "RDMAP Error Surfacing").
無効なRDMA読み取り要求メッセージがリモートピアのRDMAP層に配信されている場合*リモートピアでは、エラーが浮上している（7.1節を参照してください、「RDMAPエラーサーフェス」）。
* An RDMA Read Request Message MUST reference the RDMA Read Request Queue. That is, the Local Peer's RDMAP layer MUST request that the DDP layer set the Queue Number field to one.
* RDMA読み取り要求メッセージは、RDMA読み取り要求キューを参照する必要があります。つまり、ローカルピアのRDMAP層はDDP層は1にキュー番号]フィールドを設定することを要求しなければなりません。
* The Local Peer MUST pass to the DDP layer RDMA Read Request Messages in the order they were submitted by the ULP.
*ローカルピアは、彼らはULPによって提出された順序でDDP層RDMA読み取り要求メッセージに渡す必要があります。
* The Remote Peer MUST process the RDMA Read Request Messages in the order they were sent.
*リモートピアは、それらが送信されたために、RDMA読み取り要求メッセージを処理しなければなりません。
* If the Local Peer wishes to read from multiple Tagged Buffers on the Remote Peer, the Local Peer MUST use multiple RDMA Read Request Messages. That is, a single RDMA Read Request Message MUST only read from one remote Tagged Buffer.
*ローカルピアがリモートピアに複数のタグ付きバッファから読み取るすることを希望する場合は、ローカルピアは、複数のRDMA読み取り要求メッセージを使用しなければなりません。これは、単一RDMA読み取り要求メッセージは、唯一のリモートタグ付けバッファから読み取る必要があります。
* AN RDMA Read Request Message MAY target all or part of a previously Advertised Buffer.
* RDMA読み取り要求メッセージは、以前にアドバタイズバッファの全部または一部を標的とすることができます。
* If the Data Source receives a valid RDMA Read Request Message, it MUST respond with a valid RDMA Read Response Message.
*データソースが有効なRDMA読み取り要求メッセージを受信した場合、それが有効なRDMA読み取り応答メッセージで応じなければなりません。
* The Data Sink MAY issue a zero-length RDMA Read Request Message by setting the RDMA Read Message Size field to zero in the RDMA Read Request Header.
*データシンクは、RDMA読み取りリクエストヘッダにゼロにRDMA読み取りメッセージサイズのフィールドを設定することにより、長さゼロのRDMA読み取り要求メッセージを発行することができます。
* If the Data Source receives a non-zero-length RDMA Read Message Size, the Data Source RDMAP MUST validate the Data Source STag and Data Source Tagged Offset contained in the RDMA Read Request Header.
データソースは、非ゼロ長RDMA読み取りメッセージサイズを受信した場合*、データソースRDMAPは、データソースのSTagおよびデータソースがRDMA読み取りリクエストヘッダに含まれるオフセットタグ付けを検証する必要があります。
* If the Data Source receives an RDMA Read Request Header with the RDMA Read Message Size set to zero, the Data Source RDMAP:
*データソースは、ゼロに設定RDMA読み取りメッセージサイズ、データソースRDMAPでRDMA読み取り要求ヘッダーを受信した場合：
* MUST NOT validate the Data Source STag and Data Source Tagged Offset contained in the RDMA Read Request Header, and
* RDMA読み取りリクエストヘッダに含まれるオフセットタグ付けされたデータソースのSTagおよびデータソースを検証してはならない、と
* MUST respond with a zero-length RDMA Read Response Message.
*長さゼロのRDMA読み取り応答メッセージで応じなければなりません。
The RDMA Read Response Message uses the DDP Tagged Buffer Model to Deliver the contents of a previously requested Data Source Tagged Buffer to the Data Sink, without any involvement from the ULP at the Remote Peer. The RDMA Read Response Message has the following semantics:
RDMA読み取り応答メッセージは、リモートピアでULPからのいかなる関与することなく、データシンクに以前に要求データソースタグ付けバッファの内容を配信するためDDPタグ付きバッファモデルを使用しています。 RDMA読み取り応答メッセージには、以下の意味があります。
* The RDMA Read Response Message for the associated RDMA Read Request Message travels in the opposite direction.
*関連するRDMA読み取り要求メッセージに対するRDMA読み取り応答メッセージは逆方向に移動します。
* An RDMA Read Response Message MUST reference a Tagged Buffer. That is, the Data Source RDMAP layer MUST request that the DDP mark the Message as Tagged.
* RDMA読み取り応答メッセージは、タグ付きバッファを参照する必要があります。つまり、データソースRDMAP層はDDPがタグ付きとしてメッセージをマークすることを要求しなければなりません。
* The Data Source MUST ensure that a sufficient number of Untagged Buffers are available on the RDMA Read Request Queue (Queue with DDP Queue Number 1) to support the maximum number of RDMA Read Requests negotiated by the ULP.
*データソースは、タグなしバッファの十分な数のULPによって交渉RDMA読み取り要求の最大数をサポートするために、RDMA読み取り要求キュー（DDPキューナンバー1とキュー）で利用可能であることを保証しなければなりません。
* The RDMAP layer MUST Deliver the RDMA Read Response Message to the ULP.
* RDMAP層はULPにRDMA読み取り応答メッセージを提供しなければなりません。
* At the Remote Peer, when an invalid RDMA Read Response Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced (see Section 7.1, "RDMAP Error Surfacing").
*リモートピアで、無効RDMA読み取り応答メッセージは、リモートピアのRDMAP層、エラーが浮上している（7.1節、「RDMAPエラーサーフェス」を参照）に配信されます。
* The Tagged Offset of a Tagged Buffer MAY start at a non-zero value.
*タグ付きバッファのオフセットタグ付き非ゼロ値で開始してもよいです。
* The Data Source RDMAP layer MUST pass RDMA Read Response Messages to the DDP layer, in the order that the RDMA Read Request Messages were received by the RDMAP layer, at the Data Source.
*データソースRDMAP層がRDMA読み取り要求メッセージは、データソースで、RDMAP層が受信した順序で、DDP層にRDMA読み取り応答メッセージを渡す必要があります。
* The Data Sink MAY validate that the STag, Tagged Offset, and length of the RDMA Read Response Message are the same as the STag, Tagged Offset, and length included in the corresponding RDMA Read Request Message.
*データシンクは、検証することができるオフセットタグのSTagと、RDMA読み取り応答メッセージの長さがのSTagと同じであることを、オフセット、および長さは、対応するRDMA読み取り要求メッセージに含まれるタグ付き。
* A single RDMA Read Response Message MUST write to one remote Tagged Buffer. If the Data Sink wishes to read multiple Tagged Buffers, the Data Sink can use multiple RDMA Read Request Messages.
*シングルRDMA読み取り応答メッセージは1遠隔タグ付きバッファに書き込む必要があります。データシンクが複数のタグ付きバッファを読みしたい場合は、データシンクは、複数のRDMA読み取り要求メッセージを使用することができます。
The Send Message Type uses the DDP Untagged Buffer Model to transfer data from the Data Source into an Untagged Buffer at the Data Sink.
送信メッセージの種類は、データシンクでタグなしバッファにデータソースからデータを転送するDDPタグなしのバッファモデルを使用しています。
* A Send Message Type MUST reference an Untagged Buffer. That is, the Local Peer's RDMAP layer MUST request that the DDP layer mark the Message as Untagged.
*送信メッセージの種類は、タグなしのバッファを参照する必要があります。これはローカルピアのRDMAP層はDDP層はタグなしとしてメッセージをマークすることを要求しなければならない、です。
* One Send Message Type MUST consume one Untagged Buffer.
* 1つの送信メッセージの種類は、1タグなしのバッファを消費しなければなりません。
* The ULP Message sent using a Send Message Type MAY be less than or equal to the size of the consumed Untagged Buffer. The RDMAP layer communicates to the ULP the size of the data written into the Untagged Buffer.
*送信メッセージタイプを使用して送信されたULPメッセージは以下消費タグなしのバッファのサイズに等しくてもよいです。 RDMAP層はULPにタグなしバッファに書き込まれたデータのサイズを通信します。
* If the ULP Message sent via Send Message Type is larger than the Data Sink's Untagged Buffer, it is an error (see Section 9.1, "RDMAP Error Surfacing").
*メッセージの送信タイプを経由して送信されたULPメッセージは、データシンクのタグなしのバッファよりも大きい場合、それはエラーがある（9.1節を参照してください、「RDMAPエラーサーフェス」）。
* At the Remote Peer, the Send Message Type MUST be Delivered to the Remote Peer's ULP in the order they were sent.
*リモートピアで、送信メッセージの種類は、彼らが送信されたために、リモートピアのULPに送達されなければなりません。
* After the Send with Solicited Event or Send with Solicited Event and Invalidate Message is Delivered to the ULP, the RDMAP MAY generate an Event, if the Data Sink is configured to generate such an Event.
要請イベントを送信するか、要請イベントを送信し、メッセージを無効にULPに配信された後、データシンクは、このようなイベントを生成するように構成されている場合*、RDMAPは、イベントを生成することができます。
* At the Remote Peer, when an invalid Send Message Type is Delivered to the Remote Peer's RDMAP layer, an error is surfaced (see Section 7.1, "RDMAP Error Surfacing").
無効な送信メッセージの種類は、リモートピアのRDMAP層に配信されている場合*リモートピアでは、エラーが浮上している（7.1節を参照してください、「RDMAPエラーサーフェス」）。
* The RDMAP does not specify the structure of the buffer(s) used by an outbound RDMA Write nor does it specify how the buffer(s) are addressed. For example, an implementation of RDMA may choose to allow a gather-list of non-contiguous data blocks to be the source of a Send Message Type. In this case, the data blocks would be combined by the Data Source and sent as a single Send Message Type to the Data Sink.
* RDMAPは、アウトバウンドRDMA書き込みが使用するバッファ（複数可）の構造を指定しておらず、バッファ（複数可）に対処する方法を指定ありません。例えば、RDMAの実装は、非連続的なデータブロックの収集リストは、送信メッセージの種類のソースを許可するように選択できます。この場合、データブロックは、データソースによって結合されるだろうとのデータシンクに、単一の送信メッセージの種類として送信します。
* For a Send Message Type, the Local Peer's RDMAP layer MUST request that the DDP layer set the Queue Number field to zero.
*送信メッセージタイプの場合は、ローカルピアのRDMAP層はDDP層がゼロにキュー番号フィールドを設定することを要求しなければなりません。
* The Local Peer MUST issue Send Message Type Messages in the order they were submitted by the ULP.
*ローカルピアは、彼らはULPによって提出されたために、メッセージの種類メッセージを送信発行しなければなりません。
* The Data Source MAY pass a zero-length Send Message Type. A zero-length Send Message Type MUST consume an Untagged Buffer at the Data Sink. A Send with Invalidate or Send with Solicited Event and Invalidate Message MUST reference an STag. That is, the Local Peer's RDMAP layer MUST pass the RDMA control field and the STag that will be Invalidated to the DDP layer.
*データソースは、長さゼロのメッセージの送信タイプを渡すことができます。長さゼロの送信メッセージタイプはデータシンクでタグなしのバッファを消費しなければなりません。 A無効化して送信するか、要請イベントと無効化メッセージを送るのSTagを参照する必要があります。つまり、ローカルピアのRDMAP層がRDMA制御フィールドとDDP層に無効になるのSTagを渡す必要があります。
* When the Send with Invalidate and Send with Solicited Event and Invalidate Message are Delivered to the Remote Peer's RDMAP layer, the RDMAP layer MUST:
*リモートピアのRDMAP層に配信されたときに無効化して送信し、要請イベントと無効化メッセージを送信し、RDMAP層必要があります。
* Verify the STag that is associated with the RDMAP Stream; and
* RDMAPストリームに関連付けられたSTagを確認してください。そして
* Invalidate the STag if it is associated with the RDMAP Stream; or issue a Terminate Message with the STag Cannot be Invalidated Terminate Error Code, if the STag is not associated with the RDMAP Stream.
*それはRDMAPストリームに関連付けられている場合のSTagを無効に。またはのSTagはRDMAPストリームに関連付けられていない場合のSTagと終了メッセージが、エラーコードを終了無効にすることはできません発行します。
The Terminate Message uses the DDP Untagged Buffer Model to transfer-error-related information from the Data Source into an Untagged Buffer at the Data Sink and then ceases all further communications on the underlying DDP Stream. The Terminate Message has the following semantics:
終了メッセージは、転送エラーに関連する情報をデータソースからデータシンクにタグなしバッファにDDPタグなしのバッファモデルを使用した後、下にあるDDPストリーム上のすべてのさらなる通信を停止します。終了メッセージは以下の意味があります。
* A Terminate Message MUST reference an Untagged Buffer. That is, the Local Peer's RDMAP layer MUST request that the DDP layer mark the Message as Untagged.
* Aタグなしのバッファを参照しなければならないメッセージを終了します。これはローカルピアのRDMAP層はDDP層はタグなしとしてメッセージをマークすることを要求しなければならない、です。
* A Terminate Message references the Terminate Queue. That is, the Local Peer's RDMAP layer MUST request that the DDP layer set the Queue Number field to two.
* Aは、メッセージがキューを終了参照し終了します。つまり、ローカルピアのRDMAP層はDDP層が2にキュー番号]フィールドを設定することを要求しなければなりません。
* One Terminate Message MUST consume one Untagged Buffer.
*一つは、メッセージが1タグなしのバッファを消費しなければならない終了します。
* On a single RDMAP Stream, the RDMAP layer MUST guarantee placement of a single Terminate Message.
*シングルRDMAPストリーム上で、RDMAP層は、単一の終了メッセージの配置を保証しなければなりません。
* A Terminate Message MUST be Delivered to the Remote Peer's RDMAP layer. The RDMAP layer MUST Deliver the Terminate Message to the ULP.
* A終了メッセージは、リモートピアのRDMAP層に送達されなければなりません。 RDMAP層はULPに終了メッセージを提供しなければなりません。
* At the Remote Peer, when an invalid Terminate Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced (see Section 7.1 "RDMAP Error Surfacing").
*終了無効なメッセージがリモートピアのRDMAP層に配信されるリモートピア、で、エラーが（7.1節「RDMAPエラーサーフェス」を参照）浮上しています。
* The RDMAP layer Completes in error all ULP operations that have not been provided to the DDP layer.
* RDMAP層がエラーでDDP層に提供されていないすべてのULP操作を完了します。
* After sending a Terminate Message on an RDMAP Stream, the Local Peer MUST NOT send any more Messages on that specific RDMAP Stream.
* RDMAPストリームに終了メッセージを送信した後、ローカルピアは、その特定のRDMAPストリーム上の任意の複数のメッセージを送ってはいけません。
* After receiving a Terminate Message on an RDMAP Stream, the Remote Peer MAY stop sending Messages on that specific RDMAP Stream.
* RDMAPストリームに終了メッセージを受信した後、リモートピアは、その特定のRDMAPストリーム上のメッセージの送信を停止するかもしれません。
It is important to understand the difference between Placement and Delivery ordering since RDMAP provides quite different semantics for the two.
RDMAPが2のための全く異なる意味を提供するので、配置と配達順序の違いを理解することが重要です。
Note that many current protocols, both as used in the Internet and elsewhere, assume that data is both Placed and Delivered in order. Taking advantage of this fact allowed applications to take a variety of shortcuts. For RDMAP, many of these shortcuts are no longer safe to use, and could cause application failure.
現在の多くのプロトコルは、インターネットで他の場所で使用としても、そのデータが両方に配置され、順番に配信されると仮定していることに注意してください。アプリケーションは、ショートカットの様々なを取ることが許され、この事実を利用して。 RDMAPのために、これらのショートカットの多くは、もはや使用しても安全ではない、とアプリケーションの障害を引き起こす可能性があります。
The following rules apply to implementations of the RDMAP protocol. Note that in these rules, Send includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate:
以下の規則はRDMAPプロトコルの実装に適用されます。これらの規則では、送信、送信無効化して送信し、要請イベントを送信し、要請イベントや無効化して送信含まれていることに注意してください：
1. RDMAP does not provide ordering among Messages on different RDMAP Streams.
1. RDMAPは異なるRDMAPストリーム上のメッセージのうち、発注提供されていません。
2. RDMAP does not provide ordering between operations that are generated from the two ends of an RDMAP Stream.
2. RDMAPはRDMAPストリームの2つの端部から発生される動作との間に順序付けられません。
3. RDMA Messages that use Tagged and Untagged Buffers MAY be Placed in any order. If an application uses overlapping buffers (points different Messages or portions of a single Message at the same buffer), then it is possible that the last incoming write to the Data Sink buffer will not be the last outgoing data sent from the Data Source.
タグ付きおよびタグなしバッファを使用3. RDMAメッセージは、任意の順序で配置することができます。アプリケーションが重複バッファ（点同じ緩衝液で単一のメッセージの異なるメッセージまたはその一部）を使用している場合、データシンクバッファへの最後の着信書き込みデータソースから送信された最後の送信データでない可能性があります。
4. For a Send operation, the contents of an Untagged Buffer at the Data Sink MAY be indeterminate until the Send is Delivered to the ULP at the Data Sink.
送信動作4.送信をデータシンクにULPに送達されるまで、データシンクでタグなしバッファの内容は不定であるかもしれ。
5. For an RDMA Write operation, the contents of the Tagged Buffer at the Data Sink MAY be indeterminate until a subsequent Send is Delivered to the ULP at the Data Sink.
RDMA書き込み動作5.後続の送信は、データシンクにULPに送達されるまで、データシンクでタグ付けバッファの内容は不定であるかもしれ。
6. For an RDMA Read operation, the contents of the Tagged Buffer at the Data Sink MAY be indeterminate until the RDMA Read Response Message has been Delivered at the Local Peer.
RDMA読み取り操作6. RDMA読み取り応答メッセージは、ローカルピアで配信されるまで、データシンクでタグ付けバッファの内容が不確定になる場合があります。
Statements 4, 5, and 6 imply "no peeking" at the data to see if it is done. It is possible for some data to arrive before logically earlier data does, and peeking may cause unpredictable application failure.
ステートメント4、5、および6は、それが行われているかどうかを確認するためのデータで、「何チラッと覗く」を意味するものではありません。論理的に以前のデータがする前に、いくつかのデータが到着することが可能であり、チラッと覗く、予期しないアプリケーション障害を引き起こす可能性があります。
7. If the ULP or Application modifies the contents of Tagged or Untagged Buffers, which are being modified by an RDMA Operation while the RDMAP is processing the RDMA Operation, the state of the Buffers is indeterminate.
ULPまたはアプリケーションがRDMAPがRDMA動作を処理している間RDMA操作によって改変されているタグ付き又はタグなしバッファの内容を変更する場合7は、バッファの状態が不確定です。
8. If the ULP or Application modifies the contents of Tagged or Untagged Buffers, which are read by an RDMA Operation while the RDMAP is processing the RDMA Operation, the results of the read are indeterminate.
8. ULPまたはアプリケーションがRDMAPがRDMA動作を処理している間RDMA動作により読み出されるタグ付き又はタグなしバッファの内容を変更する場合、読み出しの結果が不確定です。
9. The Completion of an RDMA Write or Send Operation at the Local Peer does not guarantee that the ULP Message has yet reached the Remote Peer ULP Buffer or been examined by the Remote ULP.
9. RDMA書き込みの完了またはローカルピアでの動作を送るには、ULPメッセージは、リモートピアULPバッファーにまだ到達しているか、リモートULPによって検討されていることを保証するものではありません。
10. Send Messages MUST be Delivered to the ULP at the Remote Peer after they are Delivered to RDMAP by DDP and in the order that they were Delivered to RDMAP.
10.彼らはDDPで、それらはRDMAPに配信されたことを順番にRDMAPに配信された後、リモートピアでULPに送達されなければならないメッセージを送信します。
Note that DDP ordering rules ensure that this will be the same
order that they were submitted at the Local Peer and that any
prior RDMA Writes have been submitted for ordered Placement at
the Remote Peer. This means that when the ULP sees the Delivery
of the Send, the memory buffers targeted by any preceding RDMA
Writes and Sends are available to be accessed locally or remotely
as authorized. If the ULP overlaps its buffers for different
operations, the data from the RDMA Write or Send may be
overwritten by subsequent RDMA Operations before the ULP receives
and processes the Delivery.
11. RDMA Read Response Messages MUST be Delivered to the ULP at the Remote Peer after they are Delivered to RDMAP by DDP and in the order that the they were Delivered to RDMAP.
彼らはDDPで、それらはRDMAPに配信されたことを順番にRDMAPに配信された後、11 RDMA読み取り応答メッセージは、リモートピアでULPに送達されなければなりません。
DDP ordering rules ensure that this will be the same order that
they were submitted at the Local Peer. This means that when the
ULP sees the Delivery of the RDMA Read Response, the memory
buffers targeted by the RDMA Read Response are available to be
accessed locally or remotely as authorized. If the ULP overlaps its buffers for different operations, the data from the RDMA Read
Response may be overwritten by subsequent RDMA Operations before
the ULP receives and processes the Delivery.
12. RDMA Read Request Messages, including zero-length RDMA Read Requests, MUST NOT start processing at the Remote Peer until they have been Delivered to RDMAP by DDP.
彼らはDDPでRDMAPに配信されるまで、長さゼロのRDMA読み取り要求を含む12 RDMA読み取り要求メッセージは、リモートピアでの処理を開始してはなりません。
Note: the ULP is assured that data written can be read back. For
example, if
a) an RDMA Read Request is issued by the local peer, b) the Request targets the same ULP Buffer as a preceding Send or RDMA Write (in the same direction as the RDMA Read Request), and c) there are no other sources of update for the ULP Buffer,
a）は、RDMA読み取り要求がローカルピアによって発行され、b）の要求が送信先行又はRDMA書き込み（RDMA読み取り要求と同じ方向に）同じULPバッファを標的、およびc）の他のソースが存在しませんULPバッファ用の更新プログラム、
then the Remote Peer will send back the data written by the Send or RDMA Write. That is, for this example, the ULP Buffer is Advertised for use on a series of RDMA Messages, is only valid on the RDMAP Stream for which it is Advertised, and is not locally updated while the series of RDMAP Messages are performed. For this example, order rule (12) assures that subsequent local or remote accesses to the ULP Buffer contain the data written by the Send or RDMA Write.
その後、リモートピアが送信またはRDMA書き込みによって書き込まれたデータを返送します。つまり、この例では、ULPバッファはRDMAメッセージのシリーズで使用するために宣伝され、それが広告され、かつRDMAPの一連のメッセージが実行されている間、ローカルに更新されていないRDMAPストリーム上でのみ有効です。この例では、順序の規則（12）は、後続のローカルまたはリモートのULPバッファへのアクセスを送信またはRDMA書き込みにより書き込まれたデータを含むことを保証します。
RDMA Read Response Messages MAY be generated at the Remote Peer after subsequent RDMA Write Messages or Send Messages have been Placed or Delivered. Therefore, when an application does an RDMA Read Request followed by an RDMA Write (or Send) to the same buffer, it may get the data from the later RDMA Write (or Send) in the RDMA Read Response Message, even though the operations completed in order at the Local Peer. If this behavior is not desired, the Local Peer ULP must Fence the later RDMA write (or Send) by withholding the RDMA Write Message until all outstanding RDMA Read Responses have been Delivered.
RDMA読み取り応答メッセージは、その後のRDMAがメッセージを書き込むか、配置されるか、または配信されたメッセージを送信した後、リモートピアで生成することができます。アプリケーションは、同じバッファに（または送る）RDMA書き込みが続くRDMA読み取り要求をしたときしたがって、それは操作が完了していても、RDMA読み取り応答メッセージの後のRDMA書き込みからデータを取得する（または送る）ことローカルピアのためです。この動作は、後にRDMAライトは、すべての未処理のRDMA読み取り応答が配信されるまで、RDMA書き込みメッセージを保留することで（または送る）、ローカルピアULP必見フェンスを希望されない場合。
13. The RDMAP layer MUST submit RDMA Messages to the DDP layer in the order the RDMA Operations are submitted to the RDMAP layer by the ULP.
13. RDMAP層はRDMA操作がULPによってRDMAP層に提出されているために、DDP層にRDMAメッセージを提出しなければなりません。
14. A Send or RDMA Write Message MUST NOT be considered Complete at the Local Peer (Data Source) until it has been successfully completed at the DDP layer.
14. Aが送るか、それが成功したDDP層で完了するまで、RDMA書き込みメッセージは、ローカルピア（データソース）で完了したとみなされてはなりません。
15. RDMA Operations MUST be Completed at the Local Peer in the order that they were submitted by the ULP.
15. RDMAオペレーションは、それらがULPにより提出された順序でローカルピアで完了する必要があります。
16. At the Data Sink, an incoming Send Message MUST be Delivered to the ULP only after the DDP Message has been Delivered to the RDMAP layer by the DDP layer.
データシンクは、着信メッセージ送信時16. DDPメッセージは、DDP層によってRDMAP層に配信された後にのみULPに送達されなければなりません。
17. RDMA Read Response Message processing at the Remote Peer (reading the specified Tagged Buffer) MUST be started only after the RDMA Read Request Message has been Delivered by the DDP layer (thus, all previous RDMA Messages have been properly submitted for ordered Placement).
リモートピア（指定されたタグ付きのバッファを読んで）で17 RDMA読み取り応答メッセージの処理が（したがって、以前のすべてのRDMAメッセージが適切に注文した配置のために提出されています）RDMA読み取り要求メッセージは、DDP層で配信された後にのみ開始する必要があります。
18. Send Messages MAY be Completed at the Remote Peer (Data Sink) before prior incoming RDMA Read Request Messages have completed their response processing.
18.前に入ってくるRDMA読み取り要求メッセージは、その応答処理を完了する前にメッセージがリモートピア（データシンク）で完了することができる送信します。
19. An RDMA Read operation MUST NOT be Completed at the Local Peer until the DDP layer Delivers the associated incoming RDMA Read Response Message.
DDP層は、関連の着信RDMA読み取り応答メッセージを配信するまで【請求項19】RDMA読み取り操作は、ローカルピアで完成してはなりません。
20. If more than one outstanding RDMA Read Request Messages are supported by both peers, the RDMA Read Response Messages MUST be submitted to the DDP layer on the Remote Peer in the order the RDMA Read Request Messages were Delivered by DDP, but the actual read of the buffer contents MAY take place in any order at the Remote Peer.
20以上の優れたRDMA読み取り要求メッセージは、両方のピアでサポートされている場合は、RDMA読み取り応答メッセージは、RDMA読み取り要求メッセージは、DDPによって配信されたためにリモートピアが、実際の読み取りにDDP層に提出しなければなりませんバッファの内容は、リモートピアで任意の順序で行うことができます。
This simplifies Local Peer Completion processing for RDMA Reads
in that a Delivered RDMA Read Response MUST be sufficient to
Complete the RDMA Read operation.
RDMAP Stream management consists of RDMAP Stream Initialization and RDMAP Stream Termination.
RDMAPストリーム管理はRDMAPストリームの初期化とRDMAPストリームの終了で構成されています。
RDMAP Stream initialization occurs after the LLP Stream has been created (e.g., for DDP/MPA over TCP, the first TCP Segment after the SYN, SYN/ACK exchange). The ULP is responsible for transitioning the LLP Stream into RDMA-enabled mode. The switch to RDMA mode typically occurs sometime after LLP Stream setup. Once in RDMA enabled mode, an implementation MUST send only RDMA Messages across the transport Stream until the RDMAP Stream is torn down.
LLPストリームが作成された後RDMAPストリームの初期化が発生する（例えば、TCP上DDP / MPA、SYN、SYN / ACK交換後の最初のTCPセグメントについて）。 ULPはRDMA対応モードにLLPストリームを移行するための責任があります。 RDMAモードへの切り替えは、一般的にいつかLLPストリームのセットアップ後に発生します。 RDMAPストリームが取り壊されるまで、一度RDMA有効モードでは、実装は、トランスポートストリーム間でのみRDMAメッセージを送らなければなりません。
For each direction of an RDMAP Stream:
RDMAPストリームの各方向について：
* For a given RDMAP Stream, the number of outstanding RDMA Read Requests is limited per RDMAP Stream direction.
*与えられたRDMAPストリームに対して、優れたRDMA読み取り要求の数はRDMAPストリーム方向ごとに制限されています。
* It is the ULP's responsibility to set the maximum number of outstanding, inbound RDMA Read Requests per RDMAP Stream direction.
* RDMAPストリーム方向ごとに優れた、インバウンドRDMA読み取り要求の最大数を設定するにはULPの責任です。
* The RDMAP layer MUST provide the maximum number of outstanding, inbound RDMA Read Requests per RDMAP Stream direction that were negotiated between the ULP and the Local Peer's RDMAP layer. The negotiation mechanism is outside the scope of this specification.
* RDMAP層はULPとローカルピアのRDMAP層との間で交渉されたRDMAPストリーム方向ごとに優れた、インバウンドRDMA読み取り要求の最大数を提供しなければなりません。交渉メカニズムはこの仕様の範囲外です。
* It is the ULP's responsibility to set the maximum number of outstanding, outbound RDMA Read Requests per RDMAP Stream direction.
* RDMAPストリーム方向ごとに優れた、アウトバウンドRDMA読み取り要求の最大数を設定するにはULPの責任です。
* The RDMAP layer MUST provide the maximum number of outstanding, outbound RDMA Read Requests for the RDMAP Stream direction that were negotiated between the ULP and the Local Peer's RDMAP layer. The negotiation mechanism is outside the scope of this specification.
* RDMAP層はULPとローカルピアのRDMAP層との間で交渉されたRDMAPストリーム方向のための優れた、アウトバウンドRDMA読み取り要求の最大数を提供しなければなりません。交渉メカニズムはこの仕様の範囲外です。
* The Local Peer's ULP is responsible for negotiating with the Remote Peer's ULP the maximum number of outstanding RDMA Read Requests for the RDMAP Stream direction. It is recommended that the ULP set the maximum number of outstanding, inbound RDMA Read Requests equal to the maximum number of outstanding, outbound RDMA Read Requests for a given RDMAP Stream direction.
*ローカルピアのULPは、リモートピアのULPとRDMAPストリーム方向のための優れたRDMA読み取り要求の最大数を交渉する責任があります。 ULPが与えられたRDMAPストリーム方向のための優れた、アウトバウンドRDMA読み取り要求の最大数に等しい優れ、インバウンドRDMA読み取り要求の最大数を設定することをお勧めします。
* For outbound RDMA Read Requests, the RDMAP layer MUST NOT exceed the maximum number of outstanding, outbound RDMA Read Requests that were negotiated between the ULP and the Local Peer's RDMAP layer.
*アウトバウンドRDMA読み取り要求に関して、RDMAP層はULPとローカルピアのRDMAP層の間で交渉された優れた、アウトバウンドRDMA読み取り要求の最大数を超えてはなりません。
* For inbound RDMA Read Requests, the RDMAP layer MUST NOT exceed the maximum number of outstanding, inbound RDMA Read Requests that were negotiated between the ULP and the Local Peer's RDMAP layer.
*インバウンドRDMA読み取り要求に関して、RDMAP層はULPとローカルピアのRDMAP層の間で交渉された優れた、インバウンドRDMA読み取り要求の最大数を超えてはなりません。
There are three methods for terminating an RDMAP Stream: ULP Graceful Termination, RDMAP Abortive Termination, and LLP Abortive Termination.
ULP優雅終了、RDMAP頓挫終端、およびLLP頓挫終端：RDMAPストリームを終了させるための3つの方法があります。
The ULP is responsible for performing ULP Graceful Termination. After a ULP Graceful Termination, either side of the Stream can initiate LLP Graceful Termination, using the graceful termination mechanism provided by the LLP.
ULPは、ULP優雅な終了を実行する責任があります。 ULP優雅な終了後、ストリームのいずれかの側は、LLPが提供する優雅な終了メカニズムを使用して、LLP正常な終了を開始することができます。
RDMAP Abortive Termination allows the RDMAP to issue a Terminate Message describing the reason the RDMAP Stream was terminated. The next section (6.2.1, "RDMAP Abortive Termination") describes the RDMAP Abortive Termination in detail.
RDMAP頓挫終了はRDMAPはRDMAPストリームが終了した理由を説明終了メッセージを発行することができます。次のセクション（6.2.1、「RDMAP不稔終端」）が詳細にRDMAP不稔終了を記述する。
LLP Abortive Termination results due to an LLP error and causes the RDMAP Stream to be torn down midstream, without an RDMAP Terminate Message. While this last method is highly undesirable, it is possible, and the ULP should take this into consideration.
LLP誤差にLLP不稔終端結果とRDMAPメッセージを終了することなく、中流を解体するRDMAPストリームを生じさせます。この最後の方法は非常に望ましくないが、それは可能であり、ULPはこれを考慮する必要があります。
RDMAP defines a Terminate operation that SHOULD be invoked when either an RDMAP error is encountered or an LLP error is surfaced to the RDMAP layer by the LLP.
RDMAPはRDMAPエラーのいずれかが発生したか、LLPエラーがLLPによってRDMAP層に浮上されたときに呼び出されるべき終了操作を定義します。
It is not always possible to send the Terminate Message. For example, certain LLP errors may occur that cause the LLP Stream to be torn down a) before RDMAP is aware of the error, b) before RDMAP is able to send the Terminate Message, or c) after RDMAP has posted the Terminate Message to the LLP, but it has not yet been transmitted by the LLP.
終了メッセージを送信することができるとは限りません。 RDMAPのに終了メッセージを投稿した後、例えば、特定のLLPエラーがRDMAPが終了メッセージを送信することができ、b）の前に、それはLLPストリームはRDMAPがエラーを認識しているa）の前に解体させる発生することがあり、またはc） LLPが、それはまだLLPによって送信されていません。
Note that an RDMAP Abortive Termination may entail loss of data. In general, when a Terminate Message is received, it is impossible to tell for sure what unacknowledged RDMA Messages were Completed successfully at the Remote Peer. Thus, the state of all outstanding RDMA Messages is indeterminate, and the Messages SHOULD be considered Completed in error.
RDMAP頓挫終了は、データの損失を伴うことがあります。一般的には、終了メッセージを受信したとき、未確認のRDMAメッセージがリモートピアで成功裏に完了したものを確実に伝えることは不可能です。このように、すべての未処理のRDMAメッセージの状態が不確定である、とのメッセージがエラーで完了したとみなされるべきです。
When a peer sends or receives a Terminate Message, it MAY immediately tear down the LLP Stream. The peer SHOULD perform a graceful LLP teardown to ensure the Terminate Message is successfully Delivered.
ピアが送信または終了メッセージを受信すると、それはすぐにLLPストリームを取り壊す場合があります。ピアは、終了メッセージが正常に配信されていることを確認するために優雅なLLPティアダウンを実行する必要があります。
See Section 4.8, "Terminate Header", for a description of the Terminate Message and its contents. See Section 5.4, "Terminate Message", for a description of the Terminate Message semantics.
終了メッセージとその内容の説明については、セクション4.8、「ヘッダを終了する」を参照してください。終了メッセージの意味の説明については、「メッセージを終了する」、5.4節を参照してください。
The RDMAP protocol does not have RDMAP- or DDP-layer error recovery operations built in. If everything is working, the LLP guarantees will ensure that the Messages are arriving at the destination.
RDMAPプロトコルを内蔵RDMAP-またはDDP-層のエラー回復操作を持っていません。すべてが動作している場合は、LLPの保証はメッセージが目的地に到着していることを確認します。
If errors are detected at the RDMAP or DDP layer, then the RDMAP, DDP, and LLP Streams are Abortively Terminated (see Section 4.8, "Terminate Header").
エラーがRDMAPまたはDDP層で検出された場合、その後RDMAP、DDP、およびLLPストリームはAbortively（「ヘッダを終了」、セクション4.8を参照）が終了しています。
In general, poor implementations or improper ULP programming cause the errors detected at the RDMAP and DDP layers. In these cases, returning a diagnostic termination error Message and closing the RDMAP Stream is far simpler than attempting to maintain the RDMAP Stream, particularly when the cause of the error is not known.
一般に、貧弱な実装または不適切なULPプログラミングはRDMAPとDDP層で検出されたエラーの原因となります。これらのケースでは、診断終了エラーメッセージを返すとRDMAPストリームをクローズすると、エラーの原因は知られていない場合は特に、RDMAPストリームを維持しようとするよりもはるかに簡単です。
If an LLP does not support teardown of a Stream independent of other Streams, and an RDMAP error results in the Termination of a specific Stream, then the LLP MUST label the Stream as an erroneous Stream and MUST NOT allow any further data transfer on that Stream after RDMAP requests the Stream to be torn down.
LLPは、他のストリームのストリームから独立し、特定のストリームの終了でRDMAPエラー結果のティアダウンをサポートしていない場合は、LLPは、誤ったストリームとしてストリームにラベルを付ける必要がありますし、そのストリーム上の任意のさらなるデータ転送を許してはなりませんRDMAPはストリームを要求した後に取り壊されます。
For a specific LLP connection, when all Streams are either gracefully torn down or are labeled as erroneous Streams, the LLP connection MUST be torn down.
すべてのストリームは、いずれかの正常切断され又は誤っストリームとしてラベル付けされている特定のLLP接続については、LLP接続が解体されなければなりません。
Since errors are detected at the Remote Peer (possibly long) after RDMA Messages are passed to the DDP and the LLP at the Local Peer and after the RDMA Operations conveyed by the Messages are Completed, the sender cannot easily determine which of its Messages have been received. (RDMA Reads are an exception to this rule.)
RDMAメッセージがローカルピアでDDPとLLPに渡され、メッセージによって搬送RDMA動作が完了された後、送信者が容易になっている、そのメッセージのかを決定することができない後にエラーがリモートピア（おそらく長い）で検出されているので受け取りました。 （RDMAは、この規則の例外で読み込み。）
For a list of errors returned to the Remote Peer as a result of an Abortive Termination, see Section 4.8, "Terminate Header".
頓挫終了の結果として、リモートピアに返されたエラーのリストについては、「ヘッダーを終了」、4.8節を参照してください。
If an error occurs at the Local Peer, the RDMAP layer MUST attempt to inform the local ULP that the error has occurred.
エラーがローカルピアで発生した場合、RDMAP層は、エラーが発生したローカルULPに通知しようとしなければなりません。
The Local Peer MUST send a Terminate Message for each of the following cases:
ローカルピアは、以下の場合のそれぞれについて、終了メッセージを送らなければなりません。
1. For errors detected while creating RDMA Write, Send, Send with Invalidate, Send with Solicited Event, Send with Solicited Event and Invalidate, or RDMA Read Requests, or other reasons not directly associated with an incoming Message, the Terminate Message and Error code are sent instead of the request. In this case, the Error Type and Error Code fields are included in the Terminate Message, but the Terminated DDP Header and Terminated RDMA Header fields are set to zero.
RDMA書き込みを作成中に検出されたエラーのために1、要請イベントや無効化、またはRDMA読み取り要求、または直接、着信メッセージに関連付けられていない他の理由、終了メッセージやエラーコードを送信し、要請イベントで送る、無効化して送信し、送信します要求の代わりに送信されます。この場合、エラータイプとエラーコードフィールドが終了メッセージに含まれていますが、終端DDPヘッダーと終端RDMAヘッダフィールドはゼロに設定されています。
2. For errors detected on an incoming RDMA Write, Send, Send with Invalidate, Send with Solicited Event, Send with Solicited Event and Invalidate, or Read Response Message (after the Message has been Delivered by DDP), the Terminate Message is sent at the earliest possible opportunity, preferably in the next outgoing RDMA Message. In this case, the Error Type, Error Code, ULP PDU
入ってくるRDMA書き込みに、要請イベントや無効化、または（メッセージはDDPで配信された後の）読んで応答メッセージを送信し、要請イベントで送る、無効化して送信し、送信を検出したエラーの場合2.は、終了メッセージがで送られます好ましくは次の発信RDMAメッセージの中で可能な限り早い機会に、。この場合は、エラーの種類、エラーコード、ULP PDU
Length, and Terminated DDP Header fields are included in the
Terminate Message, but the Terminated RDMA Header field is set to
zero.
3. For errors detected on an incoming RDMA Read Request Message (after the Message has been Delivered by DDP), the Terminate Message is sent at the earliest possible opportunity, preferably in the next outgoing RDMA Message. In this case, the Error Type, Error Code, ULP PDU Length, Terminated DDP Header, and Terminated RDMA Header fields are included in the Terminate Message.
着信RDMA読み取り要求メッセージに検出されたエラー3.（メッセージDDPによって送達された後）、終了メッセージは、好ましくは、次の発信RDMAメッセージの中で、できるだけ早い機会に送信されます。この場合は、エラーの種類、エラーコード、ULP PDUの長さは、DDPヘッダーを終了し、RDMAヘッダフィールドは、終了メッセージに含まれて終了しました。
4. If more than one error is detected on incoming RDMA Messages, before the Terminate Message can be sent, then the first RDMA Message (and its associated DDP Segment) that experienced an error MUST be captured by the Terminate Message, in accordance with rules 2 and 3 above.
4.終了メッセージでエラーが発生した最初のRDMAメッセージ（およびその関連するDDPセグメント）規則に従って、終了メッセージによって捕捉されなければならない、その後、送信することができる前に、複数のエラーが、受信RDMAメッセージで検出された場合2以上3。
On incoming RDMA Writes, RDMA Read Response, Sends, Send with Invalidate, Send with Solicited Event, Send with Solicited Event and Invalidate, and Terminate Messages, the following must be validated:
入ってくるRDMAでは、RDMA読み取り応答を書き込み、要請イベントおよび無効化して送信し、要請イベントで送る、無効化して送信し、送信し、そしてメッセージを終了し、次のように検証する必要があります。
Additionally, on incoming Send with Invalidate and Send with
Solicited Event and Invalidate Messages, the following must also
be validated:
On incoming RDMA Request Messages, the following must be validated:
入ってくるRDMA要求メッセージには、次のことが検証される必要があります。
a. The Data Source STag MUST be valid.
A。データソースのSTagは有効でなければなりません。
b. The Data Source STag MUST be associated to this RDMAP Stream.
B。データソースのSTagはこのRDMAPストリームに関連付ける必要があります。
c. The Data Source Tagged Offset MUST fall in the range of legal offsets associated with the Data Source STag.
C。データソースは、データソースのSTagに関連した法的なオフセットの範囲内にする必要がありますオフセットタグ付き。
d. The sum of the Data Source Tagged Offset and the RDMA Read Message Size MUST fall in the range of legal offsets associated with the Data Source STag.
D。データソースの合計は、オフセットタグ付けとRDMA読み取りメッセージサイズは、データソースのSTagに関連した法的なオフセットの範囲内にする必要があります。
e. The sum of the Data Source Tagged Offset and the RDMA Read Message Size MUST NOT cause the Data Source Tagged Offset to wrap.
電子。データソースの合計は、オフセットタグ付けとRDMA読み取りメッセージサイズは、データソースをラップするオフセットタグ付けがあってはなりません。
This section references the resources that discuss protocol- specific security considerations and implications of using RDMAP with existing security services. A detailed analysis of the security issues around implementation and use of the RDMAP can be found in [RDMASEC].
このセクションでは、プロトコルに固有のセキュリティ上の考慮事項および既存のセキュリティサービスとRDMAPを使用する意味を議論するリソースを参照します。 RDMAPの実装と使用の周りのセキュリティ問題の詳細な分析は、[RDMASEC]で見つけることができます。
[RDMASEC] introduces the RDMA reference model and discusses how the resources of this model are vulnerable to attacks and the types of attack these vulnerabilities are subject to. It also details the levels of Trust available in this peer-to-peer model and how this defines the nature of resource sharing.
[RDMASEC] RDMA参照モデルを紹介し、このモデルのリソースを攻撃し、これらの脆弱性はの対象となる攻撃の種類に対して脆弱である方法について説明します。また、このピア・ツー・ピアモデルで利用可能なトラストのレベルを詳述し、これは、リソース共有の性質を定義する方法について説明します。
The IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [RFC2401] 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], [RFC4835]. 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, and the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RFC 4301 [RFC4301]で指定されたIPSecの新しいバージョンの存在と関連するにもかかわらず、RFC 3723 [RFC3723]でプロファイルとしてRDDPのIPsec要件は、RFC 2401 [RFC2401]および関連するRFCで指定されたIPSecのバージョンに基づいていますRFC [RFC4303]、[RFC4306]、[RFC4835]。 RDDPプロトコルの重要な初期の用途の一つは、iSCSI [のiSER]との使用です。 RDDPのIPsecの要件は、IPsecの共通プロファイルを可能にすることにより、その使用を容易にするためのIPsecのものをiSCSIとRDDPプロトコルで使用するに従ってください。将来的には、RFC 3723は、IPsecの新しいバージョンに更新することができる、そしてどのような更新のIPsecセキュリティ要件は、iSCSIとRDDPプロトコルに均一に適用されるべきです。
[RDMASEC] defines the security requirements for the implementation of the components of the RDMA reference model, namely the RDMA enabled NIC (RNIC) and the Privileged Resource Manager. An RDMAP implementation conforming to this specification MUST conform to these requirements.
【RDMASEC】RDMA参照モデルの構成要素の実装のためのセキュリティ要件を定義する、すなわちRDMAは、NIC（RNIC）および特権リソースマネージャを可能にしました。この仕様に準拠するRDMAP実装は、これらの要件に従わなければなりません。
RDMAP provides several countermeasures for all types of attacks as introduced in [RDMASEC]. In the following, this specification lists all security requirements that MUST be implemented by the RNIC. A more detailed discussion of RNIC security requirements can be found in Section 5 of [RDMASEC].
RDMAPは[RDMASEC]で導入された攻撃のすべてのタイプのいくつかの対策を提供します。以下では、この仕様はRNICによって実装されなければならないすべてのセキュリティ要件を示しています。 RNICのセキュリティ要件のより詳細な議論は[RDMASEC]のセクション5で見つけることができます。
1. An RNIC MUST ensure that a specific Stream in a specific Protection Domain cannot access an STag in a different Protection Domain.
1.アンRNICは、特定の保護ドメイン内の特定のストリームが異なる保護ドメインでのSTagにアクセスできないことを保証しなければなりません。
2. An RNIC MUST ensure that if an STag is limited in scope to a single Stream, no other Stream can use the STag.
2.アンRNICはのSTagを単一のストリームに範囲が限定されている場合、他のストリームは、のSTagを使用しないことを保証しなければなりません。
3. An RNIC MUST ensure that a Remote Peer is not able to access memory outside of 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にULPバッファの関連付けを取り消すとレンジにするためのメカニズムを提供しなければなりません。
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 ensure that a Remote Peer is not able to invalidate an STag enabled for remote access, if the STag is shared on multiple streams.
【請求項7】RNICは、リモートピアがのSTagが複数のストリーム上で共有されている場合、リモートアクセスのために有効のSTagを無効にすることはできないことを確認する必要があります。
8. An RNIC MUST choose the value of STags in a way difficult to predict. It is RECOMMENDED to sparsely populate them over the full available range.
【請求項8】RNICは、予測が困難な方法でスタッグスの値を選択する必要があります。それはまばらフル利用可能な範囲の上にそれらを移入することをお勧めします。
9. An RNIC MUST NOT enable sharing a Completion Queue (CQ) across ULPs that do not share partial mutual trust.
【請求項9】RNICは、部分的な相互信頼を共有していないのULP渡っ完了キュー（CQ）を共有可能にしてはなりません。
10. An RNIC MUST ensure that if a CQ overflows, any Streams that do not use the CQ MUST remain unaffected.
【請求項10】RNICは、CQがオーバーフロー場合、CQを使用していない任意のストリームが影響を受けないままなければならないことを保証しなければなりません。
11. An RNIC implementation SHOULD provide a mechanism to cap the number of outstanding RDMA Read Requests.
【請求項11】RNICの実装では、優れたRDMA読み取り要求の数をキャップするためのメカニズムを提供する必要があります。
12. 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*, and the update is done via a secure protocol, such as IPsec.
12.アンRNICは、ピアが適切に認証されていない限り*、信頼されていないローカルピアまたはリモートピアから直接RNICにロードされるファームウェアを有効にしてはいけません、そして更新がIPsecなどのセキュアプロトコルを介して行われます。
* 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.
With RDMAP, all reservations of local resources are initiated from local ULPs. To protect from local attacks including unfair resource distribution and gaining unauthorized access to RNIC resources, a Privileged Resource Manager (PRM) must be implemented, which manages all local resource allocation. Note that the PRM must not be provided as an independent component, and its functionality can also be implemented as part of the privileged ULP or as part of the RNIC itself.
RDMAPでは、ローカルリソースのすべての予約は、地元のULPから開始されます。不公平な資源配分とRNICリソースへの不正アクセスを獲得するなど、地元の攻撃から保護するには、特権リソースマネージャ（PRM）は、すべてのローカルリソースの割り当てを管理する、実装する必要があります。 PRMは、独立した部品として提供されてはならず、その機能は、また、特権ULPの一部として、またはRNIC自体の一部として実施することができることに留意されたいです。
A PRM implementation must meet the following security requirements (a more detailed discussion of PRM security requirements can be found in Section 5 of [RDMASEC]):
PRMの実装は、次のセキュリティ要件（PRMセキュリティ要件のより詳細な議論は[RDMASEC]のセクション5で見つけることができます）を満たしている必要があります。
1. All Non-Privileged ULP interactions with the RNIC Engine that could affect other ULPs MUST be done using the 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 that different ULPs share Partial Mutual Trust unless there is a mechanism to ensure that the ULPs do indeed share partial mutual trust.
3.特権リソースマネージャは、のULPは確かに部分的相互信頼を共有しないことを保証する仕組みがない限り異なるのULPは、部分的な相互信頼を共有すると仮定してはいけません。
4. If Non-Privileged ULPs are supported, the Privileged Resource Manager MUST verify that the Non-Privileged ULP has the right to access a specific Data Buffer before allowing an STag for which the ULP has access rights to be associated with a specific Data Buffer.
4.非特権のULPがサポートされている場合は、特権リソースマネージャは、非特権ULPは、ULPは、特定のデータ・バッファに関連付けられるアクセス権を持っているのSTagを許可する前に、特定のデータバッファにアクセスする権利を持っていることを確かめなければなりません。
5. The Privileged Resource Manager MUST control the allocation of CQ entries.
5.特権リソースマネージャは、CQエントリの割り当てを制御しなければなりません。
6. The Privileged Resource Manager SHOULD prevent a Local Peer from allocating more than its fair share of resources.
6.特権リソースマネージャは、資源の公正なシェア以上を割り当てるからローカルピアを防ぐべきです。
7. RDMA Read Request Queue resource consumption MUST be controlled by the Privileged Resource Manager such that RDMAP/DDP Streams that do not share Partial Mutual Trust do not share RDMA Read Request Queue resources.
7. RDMA読み取り要求キューリソースの消費量は、部分的な相互信頼を共有していないRDMAP / DDPストリームは、RDMA読み取り要求キューリソースを共有しないような特権リソースマネージャによって制御されなければなりません。
8. If an RNIC provides the ability to share receive buffers across multiple 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.
8. RNICは、複数のストリーム間で受信バッファを共有する機能を提供する場合、RNICおよび特権リソースマネージャの組み合わせは、リモートピアは資源の公正なシェアよりも多くを消費しようとしているかどうかを検出できなければならないローカルようにピアを検出し、攻撃を防ぐための対策を適用することができます。
RDMAP is using IP-based network services to control, read, and write data buffers over the network. Therefore, all exchanged control and data packets are vulnerable to spoofing, tampering, and information disclosure attacks.
RDMAPは、ネットワーク上のデータ・バッファを制御し、読み取り、および書き込みにIPベースのネットワークサービスを使用しています。したがって、すべての制御およびデータパケットがなりすまし、改ざん、及び情報開示攻撃に対して脆弱で交換しました。
RDMAP Streams that are subject to impersonation attacks or Stream hijacking attacks can be authenticated, have their integrity protected, and be protected from replay attacks. Furthermore, confidentiality protection can be used to protect from eavesdropping.
認証を受けることができ、なりすまし攻撃やストリームハイジャック攻撃の対象となっているRDMAPストリームは、その完全性が保護されている、とリプレイ攻撃から保護されます。さらに、機密保護は盗聴から保護するために使用することができます。
The IPsec protocol suite [RFC2401] defines strong countermeasures to protect an IP stream from those attacks. Several levels of protection can guarantee session confidentiality, per-packet source authentication, per-packet integrity, and correct packet sequencing.
IPsecプロトコルスイート[RFC2401]は、それらの攻撃からIPストリームを保護するために強力な対策を規定します。保護のいくつかのレベルでは、パケットごとの送信元認証、パケットごとの整合性、および正しいパケットシーケンスをセッションの機密性を保証することができます。
RDMAP security may also profit from SSL or TLS security services provided for TCP-based ULPs [RFC4346]. Used underneath RDMAP, these security services also provide for stream authentication, data integrity, and confidentiality. As discussed in [RDMASEC], limitations on the maximum packet length to be carried over the network and potentially inefficient out-of-order packet processing at the data sink make SSL and TLS less appropriate for RDMAP than IPsec.
RDMAPのセキュリティは、SSLまたはTCPベースのULP [RFC4346]のために提供TLSのセキュリティサービスから利益があります。 RDMAPの下に使用され、これらのセキュリティサービスは、ストリーム認証、データの整合性、および機密性を提供します。 【RDMASEC]で説明したように、データシンクで最大パケット・ネットワーク上で搬送される長さと潜在的に非効率的なアウトオブオーダーパケット処理上の制限は、IPsecよりRDMAPのSSLおよびTLSはあまり適切で作ります。
If SSL is layered on top of RDMAP, SSL does not protect the RDMAP headers. Thus, a man-in-the-middle attack can still occur by modifying the RDMAP header to incorrectly place the data into the wrong buffer, thus effectively corrupting the data stream.
SSLはRDMAPの上に階層化されている場合は、SSLはRDMAPヘッダを保護することはできません。したがって、中間者攻撃は依然として効果的にデータ・ストリームを破損、誤って間違ったバッファにデータを配置するRDMAPヘッダーを変更することによって起こり得ます。
By remaining independent of ULP and LLP security protocols, RDMAP will benefit from continuing improvements at those layers. Users are provided flexibility to adapt to their specific security requirements and the ability to adapt to future security challenges. Given this, the vulnerabilities of RDMAP to active third-party interference are no greater than any other protocol running over an LLP such as TCP or SCTP.
ULPとLLPセキュリティプロトコルに依存しない残りことで、RDMAPは、これらの層での継続的な改善の恩恵を受ける。ユーザーは、特定のセキュリティ要件と将来の安全保障上の課題に適応する能力に適応するための柔軟性を提供しています。この与えられた、アクティブサードパーティ干渉RDMAPの脆弱性は、TCPまたはSCTPなどのLLP上で稼働している他のプロトコルよりも大きくありません。
Because IPsec is designed to secure arbitrary IP packet streams, including streams where packets are lost, RDMAP can run on top of IPsec without any change. IPsec packets are processed (e.g., integrity checked and possibly decrypted) in the order they are received, and an RDMAP Data Sink will process the decrypted RDMA Messages contained in these packets in the same manner as RDMA Messages contained in unsecured IP packets.
IPsecは、パケットが失われたストリームを含む任意のIPパケットストリームを確保するために設計されているので、RDMAPはそのままのIPsecの上で実行することができます。 IPsecパケットは、それらが受信された順序で（例えば、整合性がチェックされ、おそらく復号化）処理され、そしてRDMAPデータシンクは、保護されていないIPパケットに含まれるRDMAメッセージと同様に、これらのパケットに含まれる復号化されたRDMAメッセージを処理します。
The IP Storage working group has defined the normative IPsec requirements for IP Storage [RFC3723]. Portions of this specification are applicable to the RDMAP. In particular, a compliant implementation of IPsec services for RDMAP 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]を定義しました。この仕様の一部はRDMAPに適用されます。 [RFC3723]のセクション2.3に概説されているよう特に、RDMAPのIPsecサービスの準拠した実装は、要件を満たす必要があります。 [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 a IKE Phase 2 delete message as a reason for tearing down the RDMAP stream. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, idle SAs may be dynamically brought down, and a new SA be brought up again, if activity resumes.
4.それはRDMAPストリームを切断した理由として、IKEフェーズ2削除メッセージの受信を解釈してはいけません。 IPsecの加速ハードウェアのみアクティブIKEフェーズ2つのSAの限られた数を扱うことができるかもしれないので、アイドルSAは動的に下げてもよく、活動が再開場合、新しいSAは、再度起動されます。
5. It MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods [RFC2409] SHOULD NOT be used.
5.それは、事前共有キーを使用してピア認証をサポートしなければなりません、そして、デジタル署名を使用して証明書ベースのピア認証をサポートするかもしれません。公開鍵暗号方式[RFC2409]を使用してピア認証を使用しないでください。
6. It MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers uses a dynamically assigned IP address.
6.これは、IKEメインモードをサポートしなければならないし、アグレッシブモードをサポートする必要があります。ピアのいずれかが動的に割り当てられたIPアドレスを使用する場合、事前共有鍵認証とIKEメインモードを使用しないでください。
7. When digital signatures are used to achieve authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In these cases, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
デジタル署名が認証を達成するために使用されている7、IKEメインモードまたはIKEアグレッシブモードのいずれかを使用することができます。これらのケースでは、IKE交渉は、ローカルポリシーに従って、信頼されている認証局（または当局）を指定するには、IKE証明書要求ペイロード（複数可）を使用する必要があります。 IKE交渉はIKEの認証手順で使用するためのPKI証明書を受け入れる前に、適切な証明書失効リスト（CRL）をチェックする必要があります。
8. 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.
ローカルに格納された秘密情報へのアクセス8（事前共有またはデジタル署名用の秘密鍵）は、適切に秘密情報の妥協は、IKE / IPsecプロトコルのセキュリティ特性を無効にするので、制限されなければなりません。
9. 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.
9.大規模な設定を必要とせずに、相互運用性の高いレベルを達成するためにIKEパラメータの設定の[RFC3723]のセクション2.3.4のガイドラインに従わなければなりません。
Furthermore, implementation and deployment of the IPsec services for RDDP should follow the Security Considerations outlined in Section 5 of [RFC3723].
さらに、RDDPのIPsecサービスの実装と展開は、[RFC3723]のセクション5で概説したセキュリティに関する注意事項に従ってください。
This document requests no direct action from IANA. The following consideration is listed here as commentary.
このドキュメントは、IANAからの直接行動を要求しません。以下の考察は解説としてここに記載されています。
If RDMAP was enabled a priori for a ULP by connecting to a well-known port, this well-known port would be registered for the RDMAP with IANA. The registration of the well-known port will be the responsibility of the ULP specification.
RDMAPは、よく知られたポートに接続することにより、ULPのためのアプリオリを有効にした場合は、このよく知られたポートは、IANAとRDMAPのために登録されます。よく知られているポートの登録はULP仕様の責任になります。
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[DDP]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[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]コ、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターラー、「インターネット小型コンピュータシステムインタフェース（iSCSIの）リモートダイレクトメモリアクセスのための拡張機能（RDMA ）」RFC 5046、2007年10月。
[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.、ベイリー、S.、およびJ.キャリア、 "TCP仕様のためのマーカーPDUアラインフレーミング"、RFC 5044、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]ピンカートン、J.およびE. Deleganes、 "直接データ配置プロトコル（DDP）/リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ"、RFC 5042、2007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
"ISAKMPの解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "TLSプロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
Appendix A. DDP Segment Formats for RDMA Messages
RDMAメッセージの付録A. DDPセグメント形式
This appendix is for information only and is NOT part of the standard. It simply depicts the DDP Segment format for the various RDMA Messages.
この付録では、情報提供のみを目的と標準の一部ではありません。これは単に、様々なRDMAメッセージのDDPセグメントのフォーマットを示しています。
A.1. DDP Segment for RDMA Write
A.1。 RDMA書き込み用DDPセグメント
The following figure depicts an RDMA Write, DDP Segment:
次の図は、RDMA書き込み、DDPセグメントを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Write ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: RDMA Write, DDP Segment Format
図11：RDMA書き込み、DDPセグメントのフォーマット
A.2. DDP Segment for RDMA Read Request
A.2。 RDMA読み出し要求のDDPセグメント
The following figure depicts an RDMA Read Request, DDP Segment:
次の図は、RDMA読み取り要求、DDPセグメントを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (RDMA Read Request) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag (SinkSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Sink Tagged Offset (SinkTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Message Size (RDMARDSZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source STag (SrcSTag) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data Source Tagged Offset (SrcTO) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: RDMA Read Request, DDP Segment format
図12：RDMA読み取り要求、DDPセグメント形式
A.3. DDP Segment for RDMA Read Response
A.3。 RDMA読み取り応答のためのDDPセグメント
The following figure depicts an RDMA Read Response, DDP Segment:
次の図は、RDMA読み取り応答、DDPセグメントを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sink Tagged Offset |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDMA Read Response ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: RDMA Read Response, DDP Segment Format
図13：RDMA読み取り応答、DDPセグメントのフォーマット
A.4. DDP Segment for Send and Send with Solicited Event
A.4。要請イベントを送信し、送信のためのDDPセグメント
The following figure depicts a Send and Send with Solicited Request, DDP Segment:
次の図は、送信を示していると要請要求、DDPセグメントを送信します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Send and Send with Solicited Event, DDP Segment Format
図14：送信し、要請イベント、DDPセグメントのフォーマットで送信
A.5. DDP Segment for Send with Invalidate and Send with SE and Invalidate
A.5。無効化して送信し、SEおよび無効化して送信するためにDDPセグメント
The following figure depicts a Send with Invalidate and Send with Solicited and Invalidate Request, DDP Segment:
次の図は、無効化して送信し、要請を送信し、要求を無効にDDPセグメントを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Send) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ULP Payload |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Send with Invalidate and Send with SE and Invalidate, DDP Segment Format
図15：無効化して送信し、SEと無効化、DDPセグメントのフォーマットで送信
A.6. DDP Segment for Terminate
A.6。終了のためのDDPセグメント
The following figure depicts a Terminate, DDP Segment:
次の図は終了し、DDPセグメントを示しています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Control | RDMA Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Not Used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Queue Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP (Terminate) Message Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Terminate Control | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP Segment Length (if any) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Terminated DDP Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// //
| Terminated RDMA Header (if any) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Terminate, DDP Segment Format
図16：終了、DDPセグメント形式
Appendix B. Ordering and Completion Table
付録B.発注と完了表
The following table summarizes the ordering relationships that are defined in Section 5.5, "Ordering and Completions", from the standpoint of the local peer issuing the two Operations. Note that in the table that follows, Send includes Send, Send with Invalidate, Send with Solicited Event, and Send with Solicited Event and Invalidate.
以下の表は、2つの操作を発行するローカルピアの観点から、5.5節、「注文とさまざまな補完」で定義されている順序関係をまとめたものです。以下の表では、送信は、送信無効化して送信し、要請イベントを送信し、要請イベントや無効化して送信含まれていることに注意してください。
------+-------+----------------+----------------+----------------
First | Later | Placement | Placement | Ordering
Op | Op | guarantee at | guarantee at | guarantee at
| | Remote Peer | Local Peer | Remote Peer
| | | |
------+-------+----------------+----------------+----------------
Send | Send | No placement | Not applicable | Completed in
| | guarantee. If | | order.
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
Send | RDMA | No placement | Not applicable | Not applicable
| Write | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
Send | RDMA | No placement | RDMA Read | RDMA Read
| Read | guarantee | Response | Response
| | between Send | Payload will | Message will
| | Payload and | not be placed | not be
| | RDMA Read | at the local | generated until
| | Request Header | peer until the | Send has been
| | | Send Payload is| Completed
| | | placed at the |
| | | Remote Peer |
------+-------+----------------+----------------+----------------
RDMA | Send | No placement | Not applicable | Not applicable
Write | | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | Not applicable | Not applicable
Write | Write | guarantee. If | |
| | guarantee is | |
| | necessary, see | |
| | footnote 1. | |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | RDMA Read | Not applicable
Write | Read | guarantee | Response |
| | between RDMA | Payload will |
| | Write Payload | not be placed |
| | and RDMA Read | at the local |
| | Request Header | peer until the |
| | | RDMA Write |
| | | Payload is |
| | | placed at the |
| | | Remote Peer |
------+-------+----------------+----------------+----------------
RDMA | Send | No placement | Send Payload | Not applicable
Read | | guarantee | may be placed |
| | between RDMA | at the remote |
| | Read Request | peer before the|
| | Header and Send| RDMA Read |
| | payload | Response is |
| | | generated. |
| | | If guarantee is|
| | | necessary, see |
| | | footnote 2. |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | RDMA Write | Not applicable
Read | Write | guarantee | Payload may be |
| | between RDMA | placed at the |
| | Read Request | Remote Peer |
| | Header and RDMA| before the RDMA|
| | Write payload | Read Response |
| | | is generated. |
| | | If guarantee is|
| | | necessary, see |
| | | footnote 2. |
------+-------+----------------+----------------+----------------
RDMA | RDMA | No placement | No placement | Second RDMA
Read | Read | guarantee of | guarantee of | Read Response
| | the two RDMA | the two RDMA | will not be
| | Read Request | Read Response | generated until
| | Headers | Payloads. | first RDMA Read
| | Additionally, | | Response is
| | there is no | | generated.
| | guarantee that | |
| | the Tagged | |
| | Buffers | |
| | referenced in | |
| | the RDMA Read | |
| | will be read in| |
| | order | |
Figure 17: Operation Ordering
図17：操作の順序
Footnote 1: If the guarantee is necessary, a ULP may insert an RDMA Read operation and wait for it to complete to act as a Fence.
脚注1：保証が必要な場合は、ULPはRDMA読み取り操作を挿入することができ、それがフェンスとして動作するように完了するのを待ちます。
Footnote 2: If the guarantee is necessary, a ULP may wait for the RDMA Read operation to complete before performing the Send.
脚注2：保証が必要な場合は、ULPは、送信を実行する前に完了するために、RDMA読み取り操作を待つことができます。
Appendix C. Contributors
付録C.協力者
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-2769 EMail: dwight.barron@hp.com
ドワイト・バロン、米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-2769 Eメール：dwight.barron@hp.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: 949-926-6383 EMail: caitlinb@broadcom.com
ケイトリンBestlerブロードコム・コーポレーション16215アルトンパークウェイアーバイン、CA 92619から7013 USA電話：949-926-6383 Eメール：caitlinb@broadcom.com
John Carrier Cray, Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 USA Phone: 206-701-2090 EMail: carrier@cray.com
ジョン・キャリアクレイ社411まずアベニューS、スイート600シアトル、WA 98104から2860 USA電話：206-701-2090 Eメール：carrier@cray.com
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
テッド・コンプトンEMCコーポレーションリサーチトライアングルパーク、NC 27709 USA電話：919-248-6075 Eメール：compton_ted@emc.com
Uri Elzur Broadcom Corporation 16215 Alton Parkway Irvine, California 92619-7013 USA Phone: +1 (949) 585-6432 EMail: Uri@Broadcom.com
ウリElzurブロードコム・コーポレーション16215アルトンパークウェイアーバイン、カリフォルニア州92619から7013 USA電話：+1（949）585から6432 Eメール：Uri@Broadcom.com
Hari Ghadia Gen10 Technology, Inc. 1501 W Shady Grove Road Grand Prairie, TX 75050 Phone: (972) 301 3630 EMail: hghadia@gen10technology.com
ハリGhadia GEN10テクノロジー株式会社1501年Wシェイディグローブグランドプレーリー、TX 75050電話：（972）301 3630 Eメール：hghadia@gen10technology.com
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, Arizona 85226 Phone: 480-554-3116 EMail: howard.c.herbert@intel.com
ハワードC.ハーバートインテル社MS CH7-404 5000ウェスト・チャンドラーブルバードチャンドラー、アリゾナ85226電話：480-554-3116 Eメール：howard.c.herbert@intel.com
Mike Ko IBM 650 Harry Rd. San Jose, CA 95120 Phone: (408) 927-2085 EMail: mako@us.ibm.com
マイク・コIBM 650ハリーRdを。サンノゼ、CA 95120電話：（408）927から2085 Eメール：mako@us.ibm.com
Mike Krause Hewlett-Packard Company 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: 408-447-3191 EMail: krause@cup.hp.com
マイク・クラウゼ、米国Hewlett-Packard Company 43LN 19410ホームステッド道路クパチーノ、CA 95014 USA電話：408-447-3191 Eメール：krause@cup.hp.com
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro, Oregon 97124 Phone: 503-712-4106 EMail: dave.b.minturn@intel.com
デイブMinturnのインテルコーポレーションMS JF1-210 5200ノース・イースト・エラムヤングパークウェイヒルズボロ、オレゴン州97124電話：503-712-4106 Eメール：dave.b.minturn@intel.com
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine, California 92619-7013 USA Phone: +1 (949) 926-7149 EMail: MPenna@Broadcom.com
マイク・ペンナブロードコム・コーポレーション16215アルトンパークウェイアーバイン、カリフォルニア州92619から7013 USA電話：+1（949）926から7149 Eメール：MPenna@Broadcom.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com
ジム・ピンカートンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA Eメール：jpink@microsoft.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
Hemalシャーブロードコム・コーポレーション5300カリフォルニアアベニューアーバイン、CA 92617 USA電話：+1（949）926から6941 Eメール：hemal@broadcom.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 8836 EMail: allyn@cisco.com
アリンRomanowシスコシステムズ170 Wタスマン・ドライブサンノゼ、CA 95134 USA電話：+1 408 525 8836 Eメール：allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
トムTalpeyネットワーク・アプライアンス1601 Trapelo道＃16ウォルサム、MA 02451 USA電話：+1（781）768から5329 Eメール：thomas.talpey@netapp.com
Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1-916-570-2707 EMail: pthaler@broadcom.com
パトリシア・ターラーブロードコム・コーポレーション16215アルトンパークウェイアーバイン、CA 92619から7013 USA電話：+ 1-916-570-2707 Eメール：pthaler@broadcom.com
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard MS 5668 Roseville, CA 95747-5668 USA Phone: +1 916 785 5198 EMail: jim_wendt@hp.com
ジム・ウェント、米国Hewlett-Packard Company 8000フットヒルズ大通りMS 5668ローズ、CA 95747から5668 USA電話：+1 916 785 5198 Eメール：jim_wendt@hp.com
Madeline Vega IBM 11400 Burnet Rd. Bld.45-2L-007 Austin, TX 78758 USA Phone: 512-838-7739 EMail: mvega1@us.ibm.com
マデリーンベガIBM 11400バーネットRdを。 Bld.45-2L-007オースティン、TX 78758 USA電話：512-838-7739 Eメール：mvega1@us.ibm.com
Claudia Salzberg IBM 11501 Burnet Rd. Bld.902-5B-014 Austin, TX 78758 USA Phone: 512-838-5156 EMail: salzberg@us.ibm.com
クラウディアSalzbergのIBM 11501バーネットRdを。 Bld.902-5B-014オースティン、TX 78758 USA電話：512-838-5156 Eメール：salzberg@us.ibm.com
Authors' Addresses
著者のアドレス
Renato J. Recio IBM Corp. 11501 Burnett Road Austin, TX 78758 USA Phone: 512-838-3685 EMail: recio@us.ibm.com
レナート・J. Recio IBM社11501バーネット道路オースティン、TX 78758 USA電話：512-838-3685 Eメール：recio@us.ibm.com
Bernard Metzler IBM Research GmbH Zurich Research Laboratory Saeumerstrasse 4 CH-8803 Rueschlikon, Switzerland Phone: +41 44 724 8605 EMail: bmt@zurich.ibm.com
バーナード・メッツラーIBMリサーチ社のチューリッヒ研究所Saeumerstrasse 4 CH-8803リュシュリコン、スイス電話：+41 44 724 8605 Eメール：bmt@zurich.ibm.com
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-5543 EMail: paul.culley@hp.com
ポール・R. Culley、米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-5543 Eメール：paul.culley@hp.com
Jeff Hilland Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-9489 EMail: jeff.hilland@hp.com
ジェフHilland米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-9489 Eメール：jeff.hilland@hp.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 USA Phone: +1 (831) 247-4464 Email: Dave.Garcia@StanfordAlumni.org
デイブ・ガルシア24100ハッチンソンRdのロスガトス、CA 95033 USA電話:. +1（831）247から4464 Eメール：Dave.Garcia@StanfordAlumni.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。