[要約] RFC 5040は、リモートダイレクトメモリアクセス（RDMA）プロトコルの仕様を定めたものであり、RDMAの目的は、ネットワーク上での高速なデータ転送を実現することです。
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.
* 地元のピアがコピー操作を必要とせずにリモートピアにある以前に宣伝されたバッファー（つまり、タグ付きバッファー）に直接最大2^32-1オクテットを転送できるようにするデータ転送操作を提供します。これは、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.
* コピー操作を必要とせずに、リモートピアにある以前に宣伝されたバッファー（つまり、タグ付きバッファー）から、ローカルピアが最大2^32-1オクテットを直接取得できるようにするデータ転送操作を提供します。これは、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.
* 地元のピアが明示的に宣伝されていないリモートピアにあるバッファーに直接最大2^32-1オクテットを送信できるデータ転送操作を提供します。これは、send（invalidateで送信、勧誘されたイベントで送信、勧誘されたイベントと無効化とともに送信）と呼ばれます。
* 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. 送信-Send操作は、送信メッセージを使用して、データソースからデータをバッファに転送し、データシンクによって明示的に宣伝されていないバッファーに転送されます。送信メッセージは、DDP Untaggedバッファモデルを使用して、ULPメッセージをData SinkのUntaggedバッファーに転送します。
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. 無効な送信-Nevalidate操作を備えた送信は、Data Sinkによって明示的に宣伝されていないバッファーにデータを転送するために、無効なメッセージ付きの送信を使用します。Invalidateメッセージ付きの送信には、送信メッセージのすべての機能が含まれており、1つの追加が含まれています。SendInvalidateメッセージ付きのSENDフィールドが含まれています。メッセージが配置され、データシンクに配信された後、STAGによって識別されたリモートピアバッファーには、リモートピアのULPが再びアクセスしてバッファに宣伝するまでリモートにアクセスできなくなります。
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とともに送信） - 勧誘されたイベント操作を備えた送信は、勧誘されたイベントメッセージ付きの送信を使用して、データソースからデータシンクの未編性バッファーにデータを転送します。勧誘されたイベントメッセージ付きの送信は、送信メッセージに似ています。1回の追加：勧誘されたイベントメッセージ付きの送信が配置され、配信された場合、受信者がそのようなイベントを生成するように構成されている場合、イベントが受信者に生成される場合があります。
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 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.
4. 勧誘されたイベントで送信して無効化（SEと無効化して送信） - 勧誘されたイベントと無効な操作を備えた送信は、勧誘されたイベントで送信を使用し、データソースからデータをデータソースからバッファーに転送してデータソースに転送します。シンク。勧誘されたイベントと無効なメッセージを備えた送信は、1回の追加で送信された送信に似ています。1回の追加：勧誘されたイベントと無効なメッセージが配置され、配信された場合、受信者が設定されている場合、イベントを受信者に生成することができます。そのようなイベントを生成します。
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.
この場合、データシンクであるリモートピアのULPは、アクセス用のデータシンクタグ付きバッファーを有効にし、バッファーのサイズ（長さ）、位置（タグ付きオフセット）、およびステアリングタグ（STAG）をデータソースに宣伝します。ULP固有のメカニズム。この場合、データソースであるローカルピアのULPは、RDMA書き込み操作を開始します。RDMA書き込みメッセージは、DDPタグ付きバッファモデルを使用して、ULPメッセージをデータシンクのタグ付きバッファーに転送します。注：タグ付きバッファーに関連付けられたSTAGは、リモートピアのULPがそれを無効にするまで有効なままです。
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.
RDMA読み取りリクエストメッセージは、DDP Untaggedバッファモデルを使用して、データソースとデータシンクの両方のバッファーのSTAG、起動タグ付きオフセット、およびリモートピアのRDMA読み取りリクエストキューを提供します。
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読み取り応答メッセージは、DDPタグ付きバッファモデルを使用して、データソースのULPから関与することなく、データソースのタグ付きバッファーをデータシンクに配信します。
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 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.
注：タグ付きバッファーに関連付けられたデータソースのSTAGは、データソースのULPがそれを無効にするまで有効なままです。タグ付きバッファに関連付けられたデータシンクの雄鹿は、データシンクのULPが無効になるまで有効なままです。
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. 終了 - 終了操作は、EXTERINETメッセージを使用して、ローカルピアで発生したエラーに関連するリモートピア情報に転送します。Terminateメッセージは、DDP Untagged Bufferモデルを使用して、メッセージをデータシンクのタグ付きバッファーに転送します。
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はDDPに依存しており、セクション3.1「輸送要件と仮定」で定義されている要件を条件としています。図1「RDMAP層状」は、上層プロトコル（ULPS）、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ピアにタグ付きバッファー識別子（STAG、ベースアドレス、およびバッファーの長さ）を通知することにより、着信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つ以上のリンクに接続されたコンピューティングデバイス。このコンテキストのノードは、コンピューターで実行されている特定のアプリケーションまたはプロトコルインスタンス化を指すものではありません。ノードは、ホストコンピューターにインストールされた1つ以上のRNICで構成されている場合があります。
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ネットワークインターフェイスコントローラー。これに関連して、これはIWARPおよび動詞の機能を備えたネットワークI/Oアダプターまたは組み込みコントローラーです。
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-上層プロトコル。現在参照されているプロトコル層の上。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ストリーム - 2つのノード上のピアLLPレイヤー間の単一のLLPトランスポートレベルのストリームに対応します。1つ以上のLLPストリームは、単一の輸送レベルのLLP接続にマッピングできます。接続ごとの複数のストリーム（SCTPなど）をサポートする輸送プロトコルの場合、LLPストリームは1つの輸送レベルのストリームに対応します。
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メッセージ - 1つ以上のDDPセグメントに分割されているデータインターチェンジのULP定義ユニット。このセグメンテーションは、基礎となる輸送プロトコルの最大セグメントサイズを尊重するセグメンテーションなど、さまざまな理由で発生する場合があります。
DDP Segment - The smallest unit of data transfer for the DDP protocol. It includes a DDP Header and ULP Payload (if present). A DDP Segment should be sized to fit within the 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ストリームはTCP接続に直接マップされ、単一のDDPストリームがサポートされています。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を1つの機能ブロックとして実装するためにデータシンクが必要になる場合があります。
Direct Data Placement Protocol (DDP) - Also, a wire protocol that supports Direct Data Placement by associating explicit memory buffer placement information with the LLP payload units.
ダイレクトデータ配置プロトコル（DDP） - また、明示的なメモリバッファーの配置情報をLLPペイロードユニットに関連付けることにより、直接データ配置をサポートするワイヤプロトコル。
Message Offset (MO) - For the DDP Untagged Buffer Model, specifies the offset, in bytes, from the start of a DDP Message.
メッセージオフセット（MO） - DDP Untaggedバッファモデルの場合、DDPメッセージの開始からバイト単位でオフセットを指定します。
Message Sequence Number (MSN) - For the DDP Untagged Buffer Model, specifies a sequence number that is increasing with each DDP Message.
メッセージシーケンス番号（MSN） - DDP Untaggedバッファモデルの場合、各DDPメッセージで増加しているシーケンス番号を指定します。
Queue Number (QN) - For the DDP Untagged Buffer Model, identifies a destination Data Sink queue for a DDP Segment.
キュー番号（QN） - DDP Untaggedバッファモデルの場合、DDPセグメントの宛先データシンクキューを識別します。
Steering Tag - An identifier of a Tagged Buffer on a Node, valid as defined within a protocol specification.
ステアリングタグ - プロトコル仕様内で定義されているように有効なノード上のタグ付きバッファーの識別子。
STag - Steering Tag
STAG-ステアリングタグ
Tagged Buffer - A buffer that is explicitly Advertised to the Remote Peer through exchange of an STag, Tagged Offset, and length.
タグ付きバッファー - スタッグ、タグ付きオフセット、および長さの交換を通じて、リモートピアに明示的に宣伝されるバッファー。
Tagged Buffer Model - A DDP data transfer model used to transfer Tagged Buffers from the Local Peer to the Remote Peer.
タグ付きバッファモデル - タグ付きバッファーをローカルピアからリモートピアに転送するために使用されるDDPデータ転送モデル。
Tagged DDP Message - A DDP Message that targets a Tagged Buffer.
タグ付きDDPメッセージ - タグ付きバッファをターゲットにするDDPメッセージ。
Tagged Offset (TO) - The offset within a Tagged Buffer on a Node.
タグ付きオフセット（to） - ノード上のタグ付きバッファー内のオフセット。
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.
Untagged Buffer-リモートピアに明示的に宣伝されていないバッファー。編集されていないバッファーは、Untaggedバッファーモデルと呼ばれる2つの利用可能なデータ転送メカニズムのいずれかをサポートしています。未編成のバッファーを使用して、RDMAのリクエスト、送信、および終了のために、リモートピアに非同期制御メッセージを送信します。塗装されていないバッファーは、塗装されていないDDPメッセージを処理します。
Untagged Buffer Model - A DDP data transfer model used to transfer Untagged Buffers from the Local Peer to the Remote Peer.
Untagged Buffer Model-ローカルピアからリモートピアにタグ付きバッファを転送するために使用されるDDPデータ転送モデル。
Untagged DDP Message - A DDP Message that targets an Untagged Buffer.
編集されていないDDPメッセージ-Taggedバッファを標的とするDDPメッセージ。
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].
完了キュー（CQS） - 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.
イベント - rdmapレイヤーによってULPに提供される表示が、即時の注意を必要とする完了またはその他の条件を示すために提供されます。
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を再利用するのを防ぐために使用されるメカニズム。スタッグは、再び明示的に宣伝されるまで、リモートでアクセスすることはできません。
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） - RDMA操作をサポートして、ローカルピアとリモートピア間のULPデータを転送するワイヤープロトコル。
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読み取りリクエストキューには、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の処理を中断することなくアクセスできます。
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.
終了 - ノードで使用されるRDMAメッセージは、RDMAPストリーム上のピアノードにエラー表示を渡すために使用されます。この操作は、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レイヤーの上に所有され、タグ付きバッファーまたはタグ付きULPバッファーとしてRDMAPレイヤーに宣伝されているバッファー。
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がRDMA読み取り操作に使用）。
* Queue Number 2 (used by RDMAP for Terminate operations).
* キュー番号2（操作を終了するためにRDMAPが使用）。
* DDP maps a single RDMA Message to a single DDP Message.
* DDPは、単一のRDMAメッセージを単一のDDPメッセージにマップします。
* DDP uses the STag and Tagged Offset provided by the RDMAP for Tagged Buffer Messages (i.e., RDMA Write and RDMA Read Response).
* DDPは、タグ付きバッファーメッセージにRDMAPによって提供されるSTAGとタグ付きオフセットを使用します（つまり、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はRDMAPレイヤーによって提供されるRSVDULPフィールド値を関連するDDPメッセージに挿入する必要があります。
* When the DDP layer Delivers a DDP Message to the RDMAP layer, DDP provides the RsvdULP field.
* DDPレイヤーがDDPメッセージをRDMAPレイヤーに配信すると、DDPはRSVDULPフィールドを提供します。
* The RsvdULP field must be 1 octet for DDP Tagged Messages and 5 octets for DDP Untagged Messages.
* rsvdulpフィールドは、DDPタグ付きメッセージの場合は1オクテットで、DDPのタグなしメッセージでは5オクテットでなければなりません。
* 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 For Send Operation Types, 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メッセージ
* 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.
* 送信操作タイプが無効で送信された場合、または勧誘されたイベントで送信され、無効化されている場合、無効な雄鹿。
* 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
* データシンクスタッグ
* 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レイヤーはRDMA書き込みをULPに提供しません。RDMA書き込みメッセージを介してULPバッファーに転送された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
* データシンクスタッグ
* 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に渡し、Data Sink RDMAPレイヤーに終端メッセージを送信します。データシンクRDMAPレイヤーは、ExtenateメッセージをULPに渡します。
For STags made available to the RDMAP layer, following are the interactions between the RDMAP layer and the ULP:
RDMAPレイヤーが利用できるようにされたSTAGSの場合、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;
* 特定の雄鹿に関連付けられているタグ付きオフセットの範囲。
* 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.
* 特定の雄鹿と特定のRDMAPストリームとの関連。
* If the ULP disables an STag, the ULP passes to the RDMAP layer the STag.
* ULPがSTAGを無効にすると、ULPはRDMAPレイヤーにパスを通過します。
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プロトコルのすべてのDDPメッセージ（つまり、RSVDULPフィールド）のULP使用のために予約された最初のオクテットは、RDMAPがRDMAメッセージOpCodeとRDMAPバージョンを運ぶために使用します。このオクテットは、この仕様でRDMAP制御フィールドとして知られています。RDMAPは、無効なイベントと無効なイベントで送信して送信するために、2番目から5番目のオクテットを使用します。
* The RDMA Message length is passed by the RDMAP layer to the DDP layer on all outbound transfers.
* RDMAメッセージの長さは、すべてのアウトバウンド転送でRDMAPレイヤーによってDDPレイヤーに渡されます。
* 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メッセージの長さは、インバウンドUntaggedバッファー転送の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.
* 2つの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制御フィールドを運ぶために使用する必要があります。最初のオクテットのビットの順序は、図3「DDPコントロール、RDMAP制御、およびスタッグフィールドの無効化」で定義されている必要があります。無効なイベントと無効なイベントで送信して送信するには、DDP RSVDulpフィールドの2番目から5番目のオクテットをRDMAPで使用して、無効なSTAGを運ぶ必要があります。図3は、DDP制御およびRDMAP制御フィールドの形式を示しています。（注：図3では、DDPヘッダーは[MPA]で定義されたMPAヘッダーに対応するために16ビットでオフセットされています。MPAヘッダーは、DDPがMPAの上に層状になった場合にのみ存在します。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L| Resrv | DV| RV|Rsv| Opcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invalidate STag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DDP Control, RDMAP Control, and Invalidate STag Fields
図3：DDPコントロール、RDMAP制御、およびスタッグフィールドを無効にします
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.
RDMAPレイヤーによってDDPレイヤーに渡されるすべての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は、各RDMAメッセージに対してSTAG、キュー番号、タグ付きオフセットフィールドをいつ提供する必要があるかを定義します。
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バージョンフィールド：01bこのRDMAプロトコル仕様に準拠したRNICの場合。RDMAコンソーシアムのRDMAプロトコル仕様に準拠したRNICの00B。両方のバージョン番号が有効です。相互運用性は、MPAプロトコルバージョンのネゴシエーション（MPAマーカーやMPA CRCなど）に依存します。
* 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;スタッグを無効にします。ただし、このフィールドは、無効なイベントと無効なメッセージで送信し、送信するのにのみ有効です（図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の読み取りリクエスト、および終了すると、無効なSTAGフィールドを送信中にゼロに設定し、受信機によって無視する必要があります。
-------+-----------+-------+------+-------+-----------+--------------
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レイヤーは、RDMAP制御フィールドをDDPレイヤーに通過します。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レイヤーは、RDMAP制御フィールドをDDPレイヤーに通過します。次の図は、すべての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.
データシンクステアリングタグは、データシンクのタグ付きバッファを識別します。このフィールドは、RDMA読み取りリクエストから対応するRDMA読み取り応答への解釈なしでコピーする必要があります。このフィールドを使用すると、データシンクは返信データを配置できます。STAGは、RDMAP仕様の範囲外のメカニズムを介してRDMAPストリームに関連付けられています。
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.
データシンクのタグ付けされたオフセットは、データがデータソースによって記述されるデータシンクのタグ付きバッファーのベースから、オクテットの開始オフセットを指定します。このフィールドは、RDMA読み取り要求から対応するRDMA読み取り応答にコピーされ、データシンクが返信データを配置できるようにします。オフセットのタグ付けされたデータシンクは、任意のオフセットで開始する場合があります。
The Data Sink STag and Data Sink Tagged Offset fields describe the buffer to which the RDMA Read data is written.
データシンクとデータシンクのタグ付けされたオフセットフィールドは、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.
RDMAの読み取りメッセージサイズは、データソースから読み取られるデータの量です。単一のRDMA読み取り要求メッセージは、データソースから0から2^32-1データオクテットを取得できます。
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.
データソースステアリングタグは、データソースのタグ付きバッファを識別します。STAGは、RDMAP仕様の範囲外のメカニズムを介してRDMAPストリームに関連付けられています。
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レイヤーは、RDMAP制御フィールドをDDPレイヤーに通過します。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レイヤーは、RDMAP制御フィールドをDDPレイヤーに通過します。勧誘されたイベントメッセージで送信および送信は、メッセージに関連付けられたDDPセグメントのDDPヘッダーによって完全に記述されます。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
SendおよびSendに関連付けられたDDPセグメント形式の説明については、勧誘されたイベントメッセージを参照してください。
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レイヤーは、DDPレイヤーにRDMAP制御フィールドと無効なSTAGフィールドに通過します（セクション4.1 RDMAP制御とSTAGフィールドの無効化を参照）。無効なイベントと無効なメッセージを備えた送信と送信は、メッセージに関連付けられたDDPセグメントのDDPヘッダーによって完全に記述されます。
See Appendix A for a description of the DDP Segment format associated with Send and Send with Solicited Event Messages.
SendおよびSendに関連付けられたDDPセグメント形式の説明については、勧誘されたイベントメッセージを参照してください。
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レイヤーは、RDMAP制御フィールドを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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
終了制御フィールドには、以下の図8に定義された形式が必要です。
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.
エラーが検出されたときにDDP層によって引き渡される長さ。Mビットが設定されている場合は有効でなければなりません。Dビットが設定されているときに存在する必要があります。
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.
終端に関連付けられている着信メッセージのDDPヘッダー。終端エラータイプが局所壊滅的なエラーである場合、DDPヘッダーは存在しません。Dビットが設定されている場合は、存在する必要があります。
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.
終了したRDMAヘッダーは、終端がRDMA読み取り要求メッセージに関連付けられている場合にのみ送信されます。Rビットが設定されている場合は、存在する必要があります。
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 Stag = Data Sink Stagは元々RDMA読み取りリクエストで送信されました。
* 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.
* データシンクタグ付きオフセット=データシンクタグ付きバッファーへの電流オフセット。たとえば、2048オクテットが送信された後にRDMA読み取り要求が終了した場合、データシンクにタグ付けされたオフセット=元のデータシンクがオフセット2048にタグ付けされました。
* Data Message size = Number of bytes left to transfer.
* データメッセージサイズ=転送するバイト数。
* Data Source STag = Data Source STag in the RDMA Read Request.
* データソースSTAG = RDMA読み取りリクエストのデータソース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.
* データソースタグ付きオフセット=データソースタグ付きバッファーへの電流オフセット。たとえば、2048オクテットが送信された後にRDMA読み取り要求が終了した場合、データソースがオフセット=オフセットをタグ付けしたタグ付けされたタグ付けされたオフセット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書き込みメッセージは、1つのリモートタグ付きバッファーにのみ書き込むことができます。
* 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読み取りリクエストメッセージは、1つの未編成バッファーを消費する必要があります。
* 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読み取り要求メッセージは、1つのリモートタグ付きバッファーからのみ読み取る必要があります。
* 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は、RDMA読み取りリクエストヘッダーに含まれるデータソースのSTAGおよびデータソースのタグ付きオフセットを検証する必要があります。
* If the Data Source receives an RDMA Read Request Header with the RDMA Read Message Size set to zero, the Data Source RDMAP:
* データソースがRDMA読み取り要求ヘッダーを受信した場合、RDMA読み取りメッセージサイズがゼロに設定されている場合、データソースRDMAP：
* 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読み取り応答メッセージは、DDPタグ付きバッファモデルを使用して、リモートピアのULPからの関与なしに、以前に要求されたデータソースのタグ付きバッファーの内容をデータシンクに配信します。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レイヤーは、RDMA読み取り応答メッセージをULPに配信する必要があります。
* 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.
* データシンクは、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 Untaggedバッファモデルを使用して、データソースからデータシンクの未積層バッファーにデータを転送します。
* 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レイヤーは、UNPAGEDバッファーに書き込まれたデータのサイズを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.
* データソースは、ゼロの長さの送信メッセージタイプを渡すことができます。ゼロの長さの送信メッセージタイプは、データシンクでタグ付きバッファーを消費する必要があります。無効な送信または勧誘されたイベントで送信し、無効なメッセージは雄鹿を参照する必要があります。つまり、ローカルピアのRDMAPレイヤーは、DDPレイヤーに無効にされるRDMA制御フィールドと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ストリームに関連付けられている雄鹿を確認します。と
* 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が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:
Terminateメッセージは、DDP Untagged Bufferモデルを使用して、データソースからデータシンクの未編成バッファーに転送された情報を転送し、基礎となる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.
* 終了メッセージは、攻撃されていないバッファーを参照する必要があります。つまり、ローカルピアの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.
* 終了メッセージは、終了キューを参照します。つまり、ローカルピアのRDMAPレイヤーは、DDPレイヤーがキュー番号フィールドを2に設定するように要求する必要があります。
* One Terminate Message MUST consume one Untagged Buffer.
* 1つの終了メッセージは、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.
* 終了メッセージは、リモートピアの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ストリームの両端から生成される操作間で順序付けを提供しません。
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.
5. RDMA書き込み操作の場合、データシンクのタグ付きバッファーの内容は、後続の送信がデータシンクの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.
6. RDMA読み取り操作の場合、データシンクのタグ付きバッファーの内容は、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.
7. ULPまたはアプリケーションが、RDMA動作中にRDMA操作によって変更されているタグ付きまたはタグ付きバッファーの内容を変更する場合、バッファーの状態は不確定です。
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またはアプリケーションが、RDMAの操作が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.
DDPの注文規則は、これが地元のピアで提出されたのと同じ順序であり、以前のRDMAの執筆がリモートピアでの注文配置のために提出されたことを確認することに注意してください。これは、ULPが送信の配信を見ると、前のRDMAの書き込みと送信によって標的とされたメモリバッファーが、許可されているようにローカルまたはリモートでアクセスできることを意味します。ULPが異なる操作のバッファーを重複させると、ULPが配信を受信して処理する前に、RDMAの書き込みまたは送信からのデータが後続のRDMA操作によって上書きされる可能性があります。
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.
11. RDMA読み取り応答メッセージは、DDPによってRDMAPに配信された後、RDMAPに配信された後、リモートピアで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.
DDP注文ルールは、これが地元のピアで提出されたのと同じ順序になることを確認します。これは、ULPがRDMA読み取り応答の配信を見ると、RDMA読み取り応答の標的となるメモリバッファーが、承認されているようにローカルまたはリモートでアクセスできることを意味します。ULPが異なる操作のバッファーを重複させると、ULPが配信を受信および処理する前に、RDMA読み取り応答からのデータが後続のRDMA操作によって上書きされる場合があります。
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.
12. RDMA読み取りリクエストメッセージは、ゼロ長RDMA読み取りリクエストを含む、DDPによってRDMAPに配信されるまで、リモートピアで処理を開始してはなりません。
Note: the ULP is assured that data written can be read back. For example, if
注：ULPは、記述されたデータを読み戻すことができると確信しています。たとえば、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書き込みと同じULPバッファーをターゲットにします（RDMA読み取り要求と同じ方向）、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メッセージが実行されている間はローカルに更新されません。この例では、Orderルール（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書き込み（または送信）からデータを取得する場合があります。地元のピアで順番に。この動作が望ましくない場合、ローカルピアULPは、すべての未解決のRDMA読み取り応答が配信されるまで、RDMA書き込みメッセージを源泉徴収して、後のRDMA書き込み（または送信）をフェンスする必要があります。
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. 送信またはRDMAの書き込みメッセージは、DDPレイヤーで正常に完了するまで、ローカルピア（データソース）で完了したと見なされないでください。
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読み取り応答メッセージ処理リモートピア（指定されたタグ付きバッファーの読み取り）は、DDPレイヤーによってRDMA読み取りリクエストメッセージが配信された後にのみ起動する必要があります（したがって、以前のRDMAメッセージはすべて、順序付けられた配置のために適切に送信されました）。
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.
19. DDPレイヤーが関連する着信RDMA読み取り応答メッセージを配信するまで、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.
これにより、RDMA読み取り応答がRDMA読み取り操作を完了するには十分でなければならないという点で、RDMA読み取りのローカルピア完成処理が簡素化されます。
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.
RDMAPストリームの初期化は、LLPストリームが作成された後に発生します（たとえば、Syn、Syn/ACK Exchange後の最初のTCPセグメントであるTCPを介したDDP/MPAの場合）。ULPは、LLPストリームをRDMA対応モードに移行する責任があります。RDMAモードへの切り替えは、通常、LLPストリームのセットアップ後に発生します。RDMA有効モードになったら、実装はRDMAPストリームが取り壊されるまで、トランスポートストリーム全体に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ストリームの場合、RDMAPストリームの方向ごとに、未解決のRDMA読み取りリクエストの数が制限されています。
* 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は、RDMAPストリーム方向の未解決のRDMA読み取り要求の最大数のリモートピアULPと交渉する責任があります。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.
* Autbound 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.
RDMAPストリームを終了するには、ULPの優雅な終了、RDMAP中絶終了、LLPの中絶終了の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.
終端メッセージを送信することは常に可能ではありません。たとえば、特定のLLPエラーが発生する場合があり、LLPストリームが取り壊されます。a）RDMAPがエラーを認識する前、b）RDMAPが終端メッセージを送信する前、またはc）終了メッセージを投稿した後にrdmapが送信されることがあります。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、「Extenateメッセージ」を参照してください。
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ストリームが中止されます（セクション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.
1. RDMAの書き込み、送信、無効なイベントで送信、勧誘イベントと無効なイベントで送信、RDMAの読み取りリクエスト、または着信メッセージに直接関連付けられていないその他の理由で送信された場合、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 Length, and Terminated DDP Header fields are included in the Terminate Message, but the Terminated RDMA Header field is set to zero.
2. 着信RDMAの書き込みで検出されたエラー、送信、無効なイベントで送信、勧誘イベントで送信、勧誘されたイベントと無効なメッセージ、または読み取り応答メッセージ（メッセージがDDPによって配信された後）、終了メッセージは最も早くに送信されます可能性のある機会、できれば次の発信RDMAメッセージで。この場合、エラータイプ、エラーコード、ULP PDU長、および終了したDDPヘッダーフィールドが終端メッセージに含まれていますが、終了したRDMAヘッダーフィールドはゼロに設定されています。
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.
3. 着信RDMA読み取りリクエストメッセージで検出されたエラーの場合（メッセージがDDPによって配信された後）、最古の機会に終了メッセージが送信されます。この場合、エラータイプ、エラーコード、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メッセージで複数のエラーが検出された場合、終端メッセージが送信される前に、エラーを発生した最初のRDMAメッセージ（および関連するDDPセグメント）は、ルール2およびルール2および、およびルール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の読み取り応答、送信、無効な送信、勧誘されたイベントとの送信、勧誘されたイベントと無効化で送信、メッセージを終了すると、以下を検証する必要があります。
1. The DDP layer MUST validate all DDP Segment fields.
1. DDP層は、すべてのDDPセグメントフィールドを検証する必要があります。
2. The RDMA OpCode MUST be valid.
2. RDMAオペコードは有効でなければなりません。
3. The RDMA Version MUST be valid.
3. RDMAバージョンは有効でなければなりません。
Additionally, on incoming Send with Invalidate and Send with Solicited Event and Invalidate Messages, the following must also be validated:
さらに、入力を無効化して送信して、勧誘されたイベントと無効なメッセージで送信すると、以下も検証する必要があります。
4. The Invalidate STag MUST be valid.
4. 無効なSTAGは有効でなければなりません。
5. The STag MUST be associated to this RDMAP Stream.
5. STAGは、このRDMAPストリームに関連付けられている必要があります。
On incoming RDMA Request Messages, the following must be validated:
着信RDMAリクエストメッセージについては、以下を検証する必要があります。
1. The DDP layer MUST validate all Untagged DDP Segment fields.
1. DDPレイヤーは、すべての攻撃されていないDDPセグメントフィールドを検証する必要があります。
2. The RDMA OpCode MUST be valid.
2. RDMAオペコードは有効でなければなりません。
3. The RDMA Version MUST be valid.
3. RDMAバージョンは有効でなければなりません。
4. For non-zero length RDMA Read Request Messages:
4. ゼロ以外の長さの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.
e. データソースのタグ付けされたオフセットと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.
RDDPのIPSEC要件は、RFC 3723 [RFC3723]によってプロファイルされたRFC 3723 [RFC3723]で紹介されているように、RFC 2401 [RFC2401]および関連RFCで指定されたIPSECのバージョンに基づいています。RFCS [RFC4303]、[RFC4306]、[RFC4835]。RDDPプロトコルの重要な初期のアプリケーションの1つは、ISCSI [ISER]での使用です。RDDPのIPSEC要件は、IPSECの共通プロファイルをISCSIおよびRDDPプロトコルで使用できるようにすることにより、その使用を容易にするためにIPSECの要件に従います。将来、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および範囲に関連性を確立および取り消すためのメカニズムを提供する必要があります。
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にファームウェアを直接ロードできるようにしてはなりません。
* 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.
* この仕様の範囲外のメカニズムによって。このメカニズムは、リモートULPがアップデートを実行する権利を持っていることを認証することを伴うと思われます。
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の実装は、次のセキュリティ要件を満たす必要があります（[RDMASEC]のセクション5にあるPRMセキュリティ要件の詳細については、詳細を確認できます）：
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が特定のデータバッファーにアクセスする前に特定のデータバッファーにアクセスする権利があることを確認する必要があります。
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セキュリティは、TCPベースのULPS [RFC4346]に提供されるSSLまたはTLSセキュリティサービスから利益を得ることもあります。RDMAPの下で使用されるこれらのセキュリティサービスは、ストリーム認証、データの整合性、および機密性も提供します。[RDMASEC]で説明したように、最大パケット長の制限は、ネットワーク上で運ばれ、データシンクでの潜在的に非効率的なオーダーアウト外のパケット処理により、SSLとTLSはIPSECよりもRDMAPに適していません。
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に適用されます。特に、RDMAPのIPSECサービスの準拠の実装は、[RFC3723]のセクション2.3に概説されているように、要件を満たす必要があります。[RFC3723]の詳細な議論を複製することなく、これには次の要件が含まれます。
1. The implementation MUST support IPsec ESP [RFC2406], as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
1. 実装は、IPSEC ESP [RFC2406]とIPSECのリプレイ保護メカニズムをサポートする必要があります。ESPを利用する場合、パケットごとのデータ原点認証、整合性、およびリプレイ保護を使用する必要があります。
2. It MUST support ESP in tunnel mode and MAY implement ESP in transport mode.
2. トンネルモードでESPをサポートする必要があり、ESPを輸送モードに実装する場合があります。
3. It MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407].
3. IPSEC DOI [RFC2407]を使用して、ピア認証、セキュリティ協会の交渉、および主要な管理のためにIKE [RFC2409]をサポートする必要があります。
4. It MUST NOT interpret the receipt of 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 SASのみを処理できる可能性があるため、アクティビティが再開された場合、アイドルSASを動的に倒し、新しいSAが再び育てられる可能性があります。
5. It MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods [RFC2409] SHOULD NOT be used.
5. 事前共有キーを使用してピア認証をサポートし、デジタル署名を使用した証明書ベースのピア認証をサポートする必要があります。公開キー暗号化方法[RFC2409]を使用したピア認証は使用しないでください。
6. It MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers uses a dynamically assigned IP address.
6. IKEメインモードをサポートする必要があり、積極的なモードをサポートする必要があります。いずれかのピアが動的に割り当てられたIPアドレスを使用している場合、事前に共有キー認証を備えたIKEメインモードは使用しないでください。
7. 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] Shah、H.、Pinkerton、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] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、 "Internet Small Computer System Interface（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.、Bailey、S。、およびJ. Carrier、「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] Pinkerton、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Tseng、J.、Walker、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「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。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
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セグメント形式を単に描写します。
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セグメント形式
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セグメント形式
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セグメント形式
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セグメント形式で送信して送信
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セグメント形式で送信
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セグメント形式
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読み取り操作が完了するのを待つ場合があります。
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-2769 EMail: dwight.barron@hp.com
ドワイト・バロン・ヒューレット・パッカード・カンパニー20555 SH 249ヒューストン、テキサス州77070-2698 USA電話：281-514-2769メール：wight.barron@hp.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: 949-926-6383 EMail: caitlinb@broadcom.com
Caitlin Bestler Broadcom Corporation 16215 Alton Parkway Irvine、CA 92619-7013 USA電話：949-926-6383メール：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 Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
John Carrier Cray、Inc。411 First Avenue S、Suite 600シアトル、ワシントン州98104-2860 USA電話：206-701-2090メール：Carrier@cray.com Ted Compton EMC Corporation Research Triangle Park、NC 27709 USA電話：919-248-6075メール：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
Uri Elzur Broadcom Corporation 16215 Alton Parkway Irvine、California 92619-7013 USA電話：1（949）585-6432メール：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
Hari Ghadia Gen10 Technology、Inc。1501 W Shady Grove Road Grand Prairie、TX 75050電話：（972）301 3630メール：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 West Chandler Blvd.アリゾナ州チャンドラー85226電話：480-554-3116メール：howard.c.herbert@intel.com
Mike Ko IBM 650 Harry Rd. San Jose, CA 95120 Phone: (408) 927-2085 EMail: mako@us.ibm.com
Mike Ko IBM 650 Harry Rd。カリフォルニア州サンノゼ95120電話：（408）927-2085メール：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 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
Mike Krause Hewlett-Packard Company 43LN 19410 Homestead Road Cupertino、CA 95014 USA電話：408-447-3191メール：krause@cup.hp.com Dave Minturn Intel Corporation：503-712-4106メール：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
Mike Penna Broadcom Corporation 16215 Alton Parkway Irvine、California 92619-7013 USA電話：1（949）926-7149メール：mpenna@broadcom.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com
Jim Pinkerton Microsoft、Inc。One Microsoft Way Redmond、WA 98052 USAメール：jpink@microsoft.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine、CA 92617 USA電話：1（949）926-6941メール：hemal@broadcom.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 8836 EMail: allyn@cisco.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose、CA 95134 USA電話：1 408 525 8836メール：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 Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine, CA 92619-7013 USA Phone: +1-916-570-2707 EMail: pthaler@broadcom.com
Tom Talpey Network Appliance 1601 Trapelo Road＃16 Waltham、MA 02451 USA電話：1（781）768-5329メール：thomas.talpey@netapp.com Patricia Thaler Broadcom Corporation 16215 Alton Parkway Irvine、CA 92619-7013 USA電話：916-570-2707メール：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
Jim Wendt Hewlett-Packard Company 8000 Foothills Boulevard MS 5668 Roseville、CA 95747-5668 USA電話：1 916 785 5198メール：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
Madeline Vega IBM 11400 Burnet Rd。Bld.45-2L-007テキサス州オースティン78758 USA電話：512-838-7739メール：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
Claudia Salzberg IBM 11501 Burnet Rd。BLD.902-5B-014テキサス州オースティン78758 USA電話：512-838-5156メール：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
Renato J. Recio IBM Corp. 11501 Burnett Road Austin、TX 78758 USA電話：512-838-3685メール：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
Bernard Metzler IBM Research GmbH Zurich Research Laboratory Saeumerstrasse 4 CH-8803 Rueschlikon、Switzerland電話：41 44 724 8605メール：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
Paul R. Culley Hewlett-Packard Company 20555 SH 249ヒューストン、テキサス77070-2698 USA電話：281-514-5543メール：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
Jeff Hilland Hewlett-Packard Company 20555 SH 249 TX 77070-2698 USA電話：281-514-9489メール：jeff.hilland@hp.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 USA Phone: +1 (831) 247-4464 Email: Dave.Garcia@StanfordAlumni.org
Dave Garcia 24100 Hutchinson Rd。Los Gatos、CA 95033 USA電話：1（831）247-4464メール：dave.garcia@stanfordalumni.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。