[要約] RFC 6581は、RDMA接続の確立を向上させるための仕様であり、RDMAプロトコルの拡張を提案しています。目的は、接続の効率性と信頼性を向上させ、ネットワークのパフォーマンスを最適化することです。
Internet Engineering Task Force (IETF) A. Kanevsky, Ed.
Request for Comments: 6581 Dell Inc.
Updates: 5043, 5044 C. Bestler, Ed.
Category: Standards Track Nexenta Systems
ISSN: 2070-1721 R. Sharp
Intel
S. Wise
Open Grid Computing
April 2012
Enhanced Remote Direct Memory Access (RDMA) Connection Establishment
拡張リモートダイレクトメモリアクセス（RDMA）接続の確立
Abstract
概要
This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration.
このドキュメントは、リモートダイレクトメモリアクセス（RDMA）接続確立のためのマーカープロトコルデータユニット（PDU）整列フレーム（MPA）ネゴシエーションを拡張することにより、RFC 5043およびRFC 5044を更新します。最初の拡張機能はRFC 5044を拡張し、MPA /伝送制御プロトコル（TCP）を介したピアツーピア接続の確立を可能にします。 2番目の拡張機能は、RDMAレイヤー接続構成の標準化された交換のオプションを提供することにより、RFC 5043とRFC 5044の両方を拡張します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6581.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6581で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Summary of Changes Affecting RFC 5044 ......................4
1.2. Summary of Changes Affecting RFC 5043 ......................4
2. Requirements Language ...........................................4
3. Definitions .....................................................4
4. Motivations .....................................................7
4.1. Standardization of RDMA Read Parameter Configuration .......7
4.2. Enabling MPA Mode ..........................................9
4.3. Lack of Explicit RTR in MPA Request/Reply Exchange ........10
4.4. Limitations on ULP Workaround .............................11
4.4.1. Transport Neutral APIs .............................11
4.4.2. Work/Completion Queue Accounting ...................11
4.4.3. Host-based Implementation of MPA Fencing ...........12
5. Enhanced MPA Connection Establishment ..........................13
6. Enhanced MPA Request/Reply Frames ..............................14
7. Enhanced SCTP Session Control Chunks ...........................15
8. MPA Error Reporting ............................................16
9. Enhanced RDMA Connection Establishment Data ....................17
9.1. IRD and ORD Negotiation ...................................18
9.2. Peer-to-Peer Connection Negotiation .......................20
9.3. Enhanced Connection Negotiation Flow ......................21
10. Interoperability ..............................................21
11. IANA Considerations ...........................................22
12. Security Considerations .......................................23
13. Acknowledgements ..............................................23
14. References ....................................................23
14.1. Normative References .....................................23
14.2. Informative References ...................................24
When used over the Transmission Control Protocol (TCP), the current Remote Direct Data Placement (RDDP) [RFC5041] suite of protocols relies on the MPA [RFC5044] protocol for both connection establishment and for markers for TCP layering.
伝送制御プロトコル（TCP）を介して使用される場合、現在のリモートダイレクトデータ配置（RDDP）[RFC5041]プロトコルスイートは、接続の確立とTCPレイヤリングのマーカーの両方について、MPA [RFC5044]プロトコルに依存しています。
A typical model for establishing an RDMA connection has the following steps:
RDMA接続を確立するための一般的なモデルには、次の手順があります。
o The passive side (responder) Upper Layer Protocol (ULP) listens for connection requests.
o パッシブ側（レスポンダー）の上位層プロトコル（ULP）は、接続要求をリッスンします。
o The active side (initiator) ULP submits a connection request using an RDMA endpoint, the desired destination, and the parameters to be used for the connection. Those parameters include both RDMA-layer characteristics, such as the number of simultaneous RDMA Read Requests to be allowed, and application-specific data.
o アクティブ側（イニシエーター）ULPは、RDMAエンドポイント、目的の宛先、および接続に使用されるパラメーターを使用して、接続要求を送信します。これらのパラメーターには、許可される同時RDMA読み取り要求の数などのRDMAレイヤーの特性と、アプリケーション固有のデータの両方が含まれます。
o The passive side ULP receives a connection request that includes the identity of the active side and the requested connection characteristics. The passive side ULP uses this information to decide whether to accept the connection, and if it is to be accepted, how to create and/or configure the local RDMA endpoint.
o パッシブ側のULPは、アクティブ側のIDと要求された接続特性を含む接続要求を受信します。パッシブ側のULPはこの情報を使用して、接続を受け入れるかどうかを決定し、接続を受け入れる場合は、ローカルRDMAエンドポイントを作成または構成する方法を決定します。
o If accepting, the responder submits its acceptance of the connection request, which in turn generates the accept message to the initiator. This responder accept operation includes the RDMA endpoint to be used and the connection characteristics (both the RDMA configuration and any application-specific Private Data to be transferred to the initiator).
o 受け入れた場合、レスポンダは接続要求の受け入れを送信します。これにより、受け入れメッセージがイニシエータに生成されます。このレスポンダー受け入れ操作には、使用するRDMAエンドポイントと接続特性（RDMA構成とイニシエーターに転送されるアプリケーション固有のプライベートデータの両方）が含まれます。
o The active side receives confirmation that the connection has been accepted, what the configured connection characteristics are, and any application-supplied Private Data.
o アクティブ側は、接続が受け入れられたことの確認、構成された接続特性とは何か、アプリケーションが提供するプライベートデータを受け取ります。
Currently, MPA only supports a client-server model for connection establishment, forcing peer-to-peer applications to interact as though they had a client-server relationship. In addition, negotiation of some parameters specific to the Remote Direct Memory Access Protocol (RDMAP) [RFC5040] are left to ULP negotiation. Providing an optional ULP-independent format for exchanging these parameters would be of benefit to transport neutral RDMA applications.
現在、MPAは接続確立のクライアントサーバーモデルのみをサポートしており、ピアツーピアアプリケーションがクライアントサーバー関係を持っているかのように相互作用するように強制します。さらに、リモートダイレクトメモリアクセスプロトコル（RDMAP）[RFC5040]に固有のいくつかのパラメーターのネゴシエーションは、ULPネゴシエーションに任されています。これらのパラメーターを交換するためのオプションのULPに依存しない形式を提供することは、ニュートラルRDMAアプリケーションを転送するのに役立ちます。
This document enhances the MPA connection setup protocol [RFC5044]. First, it adds exchange and negotiation of the parameters necessary to support RDMA Read Requests. Second, it adds a message that serves as a Ready to Receive (RTR) indication from the initiator to the responder as the last message of connection establishment and adds negotiation of which type of message to use for carrying the RTR indication into MPA Request/Reply Frames.
このドキュメントは、MPA接続セットアッププロトコル[RFC5044]を拡張します。まず、RDMA読み取り要求をサポートするために必要なパラメーターの交換とネゴシエーションを追加します。次に、イニシエーターからレスポンダーへの受信準備（RTR）指示として機能するメッセージを接続確立の最後のメッセージとして追加し、RTA指示をMPA要求/応答に運ぶために使用するメッセージのタイプのネゴシエーションを追加します。フレーム。
RTR indications are optional and are carried by existing RDMA message types, specifically a zero-length FULPDU Send message, a zero-length RDMA Read message, or a zero-length RDMA write message. The presence vs. absence of the RTR indication and the type of RDMA message to use are negotiated by control flags in Enhanced RDMA connection establishment data specified by this document (see Section 9). RDMA implementations are often tightly integrated with application libraries and hardware, hence the flexibility to use more than one type of RDMA message enables implementations to choose message types that are less disruptive to the implementation structure. When an RTR indication is used, and MPA connection setup negotiation indicates support for multiple RDMA message types as RTR indications by both the initiator and responder, the initiator selects one of the supported RDMA message types as the RTR indication at the initiator's sole discretion.
RTR指示はオプションであり、既存のRDMAメッセージタイプ、具体的には長さがゼロのFULPDU送信メッセージ、長さがゼロのRDMA読み取りメッセージ、または長さがゼロのRDMA書き込みメッセージによって伝えられます。 RTR表示の有無と使用するRDMAメッセージのタイプは、このドキュメントで指定されている拡張RDMA接続確立データの制御フラグによってネゴシエートされます（セクション9を参照）。 RDMA実装は、多くの場合、アプリケーションライブラリおよびハードウェアと緊密に統合されているため、複数のタイプのRDMAメッセージを使用できる柔軟性により、実装は、実装構造に影響を与えないメッセージタイプを選択できます。 RTRインジケーションが使用され、MPA接続セットアップネゴシエーションがイニシエーターとレスポンダーの両方によるRTRインジケーションとして複数のRDMAメッセージタイプのサポートを示す場合、イニシエーターはサポートされるRDMAメッセージタイプの1つをイニシエーターの単独の裁量でRTRインジケーションとして選択します。
This document enhances [RFC5043] by adding new Enhanced Session Control Chunks that extend the currently defined Chunks with the addition of Inbound RDMA Read Queue Depth (IRD) and Outbound RDMA Read Queue Depth (ORD) negotiation.
このドキュメントは、インバウンドRDMAリードキューデプス（IRD）とアウトバウンドRDMAリードキューデプス（ORD）ネゴシエーションを追加して、現在定義されているチャンクを拡張する新しい拡張セッションコントロールチャンクを追加することにより、[RFC5043]を拡張します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Active Side: See Initiator.
アクティブ側：イニシエーターを参照してください。
Consumer: The ULPs or applications that lie above MPA and Direct Data Placement (DDP). The Consumer is responsible for making TCP or Stream Control Transmission Protocol (SCTP) connections, starting MPA and DDP connections, and generally controlling operations. See [RFC5044] and [RFC5043].
消費者：MPAおよび直接データ配置（DDP）の上にあるULPまたはアプリケーション。コンシューマーは、TCPまたはストリーム制御伝送プロトコル（SCTP）接続の作成、MPAおよびDDP接続の開始、および一般的に操作の制御を担当します。 [RFC5044]と[RFC5043]を参照してください。
CRC: Cyclic Redundancy Check
CRC：巡回冗長検査
Completion Queue (CQ): A Consumer-accessible queue where the RDMA device reports completions of Work Requests. A Consumer is able to reap completions from a CQ without requiring per-transaction support from the kernel or other privileged entity. See [RDMAC].
完了キュー（CQ）：RDMAデバイスが作業要求の完了を報告する、コンシューマーがアクセス可能なキュー。コンシューマは、カーネルまたは他の特権エンティティからのトランザクションごとのサポートを必要とせずに、CQから完了を取得できます。 [RDMAC]を参照してください。
Completion Queue Entry (CQE): Transport- and device-specific representation of a Work Completion. A CQ holds CQEs. See [RDMAC].
完了キューエントリ（CQE）：作業完了のトランスポート固有およびデバイス固有の表現。 CQはCQEを保持します。 [RDMAC]を参照してください。
FULPDU: Framed Upper Layer Protocol PDU. See FPDU of [RFC5044].
FULPDU：Framed Upper Layer Protocol PDU。 [RFC5044]のFPDUを参照してください。
Inbound RDMA Read Request Queue (IRRQ): A queue that is associated with an RDMA connection that tracks active incoming simultaneous RDMA Read Request Messages. See [RDMAC].
インバウンドRDMA読み取り要求キュー（IRRQ）：アクティブな着信同時RDMA読み取り要求メッセージを追跡するRDMA接続に関連付けられているキュー。 [RDMAC]を参照してください。
Inbound RDMA Read Queue Depth (IRD): The maximum number of incoming simultaneous RDMA Read Request Messages an RDMA connection can handle. See [RDMAC].
インバウンドRDMA読み取りキューの深さ（IRD）：RDMA接続が処理できる、着信同時RDMA読み取り要求メッセージの最大数。 [RDMAC]を参照してください。
Initiator: The endpoint of a connection that sends the MPA Request Frame. The initiator is the active side of the connection establishment. See [RFC5044].
イニシエーター：MPA要求フレームを送信する接続のエンドポイント。イニシエーターは、接続確立のアクティブ側です。 [RFC5044]を参照してください。
IRD: See Inbound RDMA Read Queue Depth.
IRD：インバウンドRDMA読み取りキューの深さを参照してください。
MPA Fencing: MPA responder connection establishment logic that ensures that no ULP messages will be transferred until the initiator's first message has been received.
MPAフェンシング：イニシエーターの最初のメッセージが受信されるまでULPメッセージが転送されないようにするMPAレスポンダー接続確立ロジック。
MPA Request Frame: Data sent from the MPA initiator to the MPA responder during the Startup Phase. See [RFC5044].
MPA要求フレーム：起動フェーズ中にMPAイニシエーターからMPAレスポンダーに送信されるデータ。 [RFC5044]を参照してください。
MPA Reply Frame: Data sent from the MPA responder to the MPA initiator during the Startup Phase. See [RFC5044].
MPA応答フレーム：起動フェーズ中にMPAレスポンダーからMPAイニシエーターに送信されるデータ。 [RFC5044]を参照してください。
ORD: See Outbound RDMA Read Queue Depth.
ORD：アウトバウンドRDMA読み取りキューの深さを参照してください。
Outbound RDMA Read Queue Depth (ORD): The maximum number of simultaneous RDMA Read Requests that can be issued for the RDMA connection. This should be less than or equal to the peer's IRD. See [RDMAC].
アウトバウンドRDMA読み取りキューの深さ（ORD）：RDMA接続に対して発行できる同時RDMA読み取り要求の最大数。これは、ピアのIRD以下でなければなりません。 [RDMAC]を参照してください。
Passive Side: See Responder.
受動側：レスポンダを参照してください。
Private Data: A block of data exchanged between MPA endpoints during initial connection setup. See [RFC5044].
プライベートデータ：初期接続セットアップ中にMPAエンドポイント間で交換されるデータのブロック。 [RFC5044]を参照してください。
Queue Pair (QP): A Queue Pair is the set of Work Queues associated exclusively with a single Endpoint (first defined in [VIA]). The Send Queue (SQ), Receive Queue (RQ), and Inbound RDMA Read Queue (IRQ) are considered to be part of the Queue Pair. The potentially shared Completion Queue (CQ) and Shared Receive Queue (SRQ) are not. See [RDMAC].
キューペア（QP）：キューペアは、単一のエンドポイント（[VIA]で最初に定義）に排他的に関連付けられたワークキューのセットです。送信キュー（SQ）、受信キュー（RQ）、およびインバウンドRDMA読み取りキュー（IRQ）は、キューペアの一部と見なされます。潜在的に共有されている完了キュー（CQ）と共有受信キュー（SRQ）はそうではありません。 [RDMAC]を参照してください。
Remote Peer: The MPA 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. See [RFC5044].
リモートピア：接続の反対側でのMPAプロトコルの実装。 2つのノード間のプロトコル交換またはその他の相互作用を説明するときに、リモートエンティティを参照するために使用されます。 [RFC5044]を参照してください。
Responder: The connection endpoint that responds to an incoming MPA connection request (the MPA Request Frame). The responder is the passive side of the connection establishment. See [RFC5044].
レスポンダ：着信MPA接続要求（MPA要求フレーム）に応答する接続エンドポイント。レスポンダは、接続確立の受動側です。 [RFC5044]を参照してください。
Ready to Receive (RTR): RTR is an indication provided by the last connection establishment message sent from the initiator to the responder. An RTR indicates that the initiator is ready to receive messages and that connection establishment is completed.
Ready to Receive（RTR）：RTRは、イニシエーターからレスポンダーに送信された最後の接続確立メッセージによって提供される指標です。 RTRは、イニシエーターがメッセージを受信する準備ができており、接続の確立が完了したことを示します。
Startup Phase: The initial exchanges of an MPA connection that serves to more fully identify MPA endpoints to each other and pass connection-specific setup information to each other. See [RFC5044].
起動フェーズ：MPAエンドポイントを互いに完全に識別し、接続固有のセットアップ情報を相互に渡すMPA接続の初期交換。 [RFC5044]を参照してください。
Shared Receive Queue (SRQ): A shared pool of Receive Work Requests posted by the Consumer that can be allocated by multiple RDMA endpoints (QP). See [RDMAC].
共有受信キュー（SRQ）：複数のRDMAエンドポイント（QP）によって割り当てることができる、コンシューマーによってポストされた受信作業要求の共有プール。 [RDMAC]を参照してください。
Tagged (DDP) Message: A DDP Message that targets a Tagged Buffer that is explicitly advertised to the Remote Peer through exchange of an STag (memory handle), offset in the memory region identified by STag, and length [RFC5040].
タグ付き（DDP）メッセージ：STag（メモリハンドル）、STagで識別されるメモリ領域内のオフセット、および長さ[RFC5040]の交換を通じてリモートピアに明示的にアドバタイズされるタグ付きバッファをターゲットとするDDPメッセージ。
Untagged (DDP) Message: A DDP Message that targets an Untagged Buffer associated with a queue specified the by Queue Number (QN). [RFC5040].
タグなし（DDP）メッセージ：キュー番号（QN）で指定されたキューに関連付けられたタグなしバッファを対象とするDDPメッセージ。 [RFC5040]。
Work Queue: An element of a QP that allows user-space applications to submit Work Requests directly to network hardware (first defined in [VIA]). Specific Work Queues include the Send Queue (SQ) for transmit requests, Receive Queue (RQ) for receive requests specific to a single endpoint, and Shared Receive Queues (SRQs) for receive requests that can be allocated by one or more endpoints. See [RDMAC].
作業キュー：ユーザー空間アプリケーションが作業要求をネットワークハードウェアに直接送信できるようにするQPの要素（[VIA]で最初に定義）。特定のワークキューには、送信要求の送信キュー（SQ）、単一のエンドポイントに固有の受信要求の受信キュー（RQ）、および1つ以上のエンドポイントで割り当てることができる受信要求の共有受信キュー（SRQ）が含まれます。 [RDMAC]を参照してください。
Work Queue Element (WQE): Transport- and device-specific representation of a Work Request. See [RDMAC].
作業キュー要素（WQE）：作業要求のトランスポート固有およびデバイス固有の表現。 [RDMAC]を参照してください。
Work Request: An elementary object used by Consumers to enqueue a requested operation (WQEs) onto a Work Queue. See [RDMAC].
作業要求：コンシューマーが要求された操作（WQE）を作業キューにエンキューするために使用する基本オブジェクト。 [RDMAC]を参照してください。
The goal of this document is two-fold. The first is to extend support from the current client-server model for RDMA connection setup to a peer-to-peer model. The second is to add negotiation of the RDMA Read Queue size for both sides of an RDMA connection.
このドキュメントの目的は2つあります。 1つ目は、RDMA接続設定の現在のクライアントサーバーモデルからピアツーピアモデルにサポートを拡張することです。 2つ目は、RDMA接続の両側のRDMA読み取りキューサイズのネゴシエーションを追加することです。
Most RDMA applications are developed using a transport-neutral Application Programming Interface (API) to access RDMA services based on a "Queue Pair" paradigm as originally defined by the Virtual Interface Architecture [VIA], refined by the Direct Access Programming Library [DAPL], and most commonly deployed with the OpenFabrics API [OFA].
ほとんどのRDMAアプリケーションは、トランスポートニュートラルアプリケーションプログラミングインターフェース（API）を使用して開発され、仮想インターフェースアーキテクチャ[VIA]によって最初に定義された「キューペア」パラダイムに基づいてRDMAサービスにアクセスし、ダイレクトアクセスプログラミングライブラリ[DAPL]によって改良されます。 、そして最も一般的にはOpenFabrics API [OFA]と共にデプロイされます。
These transport-neutral APIs seek to provide a common set of RDMA services whether the underlying transport is, for example, RDDP over MPA, RDDP over SCTP, or InfiniBand.
これらのトランスポートニュートラルAPIは、基になるトランスポートが、たとえばRDDP over MPA、RDDP over SCTP、またはInfiniBandのいずれであっても、RDMAサービスの共通セットを提供しようとします。
The common model for establishing an RDMA connection has the following steps:
RDMA接続を確立するための一般的なモデルには、次の手順があります。
o The passive side ULP listens for connection requests.
o パッシブ側のULPは接続要求をリッスンします。
o The active side ULP submits a connection request using an RDMA endpoint ("Queue Pair"), the desired destination, and the parameters to be used for the connection. Those parameters include both RDMA-layer characteristics, such as the number of simultaneous RDMA Read Requests to be allowed, and application-specific data (typically referred to as "Private Data").
o アクティブ側のULPは、RDMAエンドポイント（「キューペア」）、目的の宛先、および接続に使用されるパラメーターを使用して、接続要求を送信します。これらのパラメーターには、許可される同時RDMA読み取り要求の数などのRDMAレイヤーの特性と、アプリケーション固有のデータ（通常は「プライベートデータ」と呼ばれます）の両方が含まれます。
o The passive side ULP receives a connection request, which includes the identity of the active side and the requested connection characteristics. The passive side ULP uses this information to decide whether to accept the connection, and if it is to be accepted, how to create and/or configure the RDMA endpoint.
o パッシブ側のULPは、アクティブ側のIDと要求された接続特性を含む接続要求を受信します。パッシブ側のULPはこの情報を使用して、接続を受け入れるかどうかを決定し、接続を受け入れる場合は、RDMAエンドポイントを作成または構成する方法を決定します。
o If accepting, the passive side ULP submits its acceptance of the connection request. This local accept operation includes the RDMA endpoint to be used and the connection characteristics (both the RDMA configuration and any application-specific Private Data to be returned).
o 受け入れる場合、パッシブ側のULPは接続要求の受け入れを送信します。このローカル受け入れ操作には、使用するRDMAエンドポイントと接続特性（RDMA構成と返されるアプリケーション固有のプライベートデータの両方）が含まれます。
o The active side receives confirmation that the connection has been accepted, what the configured connection characteristics are, and any application-supplied Private Data.
o アクティブ側は、接続が受け入れられたことの確認、構成された接続特性とは何か、アプリケーションが提供するプライベートデータを受け取ります。
As currently defined, DDP connection establishment requires the ULP to encode the RDMA configuration in the application-specific Private Data. This results in undesirable duplication of logic to cover RDMA characteristics of both InfiniBand and RDDP for each ULP, and to specify for InfiniBand and RDDP the extraction of the RDMA characteristics for each ULP.
現在定義されているように、DDP接続を確立するには、ULPがアプリケーション固有のプライベートデータにRDMA構成をエンコードする必要があります。これにより、各ULPのInfiniBandとRDDPの両方のRDMA特性をカバーし、各ULPのRDMA特性の抽出をInfiniBandとRDDPに指定するために、ロジックが望ましくない重複を生じます。
Both RDDP and InfiniBand support an initial Private Data exchange; therefore, a standard definition of the RDMA characteristics within the Private Data section would enable common connection establishment APIs to format the RDMA characteristics based on the same API information used when establishing either protocol to form the connection. The application would then only have to indicate that it was using this standard format to enable common connection establishment procedures to apply common code to properly parse these fields and configure the RDMA endpoints accordingly. Exchange of parameters necessary to perform RDMA Read operations is a common usage of the initial Private Data exchange.
RDDPとInfiniBandはどちらも初期のプライベートデータ交換をサポートしています。したがって、プライベートデータセクション内のRDMA特性の標準的な定義により、共通の接続確立APIは、いずれかのプロトコルを確立して接続を形成するときに使用される同じAPI情報に基づいてRDMA特性をフォーマットできます。アプリケーションは、この標準フォーマットを使用して、共通接続確立手順が共通コードを適用してこれらのフィールドを適切に解析し、それに応じてRDMAエンドポイントを構成できることを示すだけで済みます。 RDMA読み取り操作の実行に必要なパラメーターの交換は、最初のプライベートデータ交換の一般的な使用法です。
One of the RDMA operations that is defined in [RDMAC] is an RDMA Read. RDMA Read operations are performed using an untagged message sent from a Queue Pair (QP) on the local endpoint to a QP on the remote endpoint targeting the Inbound RDMA Read Request Queue (QN=1 or Inbound RDMA Read Request Queue (IRRQ)) associated with the connection. RDMA Read responses transfer data associated with each RDMA Read Request from the remote endpoint to the local endpoint using tagged messages. An inbound RDMA Read Request remains on the IRRQ from the time that it is received until the time that the last tagged message associated with the RDMA request is acknowledged. The IRRQ is associated with a QP but is not a Work Queue. Instead, the IRRQ is a stand-alone queue that is used to manage RDMA Read Requests associated with a QP. See [RDMAC], Section 6 for more information regarding QPs and IRRQ. One of the characteristics that must be configured for a QP is the size of the IRRQ. This parameter is called the Inbound RDMA Read Queue Depth (IRD). Another characteristic of a QP that must be configured is a local limit on the number of simultaneous outbound RDMA Read Requests based on the size of the remote endpoint QP's IRRQ. This parameter is call the Outbound RDMA Read Queue Depth (ORD). ORD is used to limit the number of simultaneous RDMA Read Requests such that the local endpoint does not overrun the remote endpoint's IRRQ depth or IRD. Note that outbound RDMA Reads are submitted to a QP's Send Queue at the local peer, not to a separate outbound RDMA Read Request queue on the local peer. The local endpoint uses ORD to strictly limit simultaneous Read Requests so that IRRQ overruns do not occur at the remote endpoint.
[RDMAC]で定義されているRDMA操作の1つは、RDMA読み取りです。 RDMA読み取り操作は、ローカルエンドポイントのキューペア（QP）から、関連付けられたインバウンドRDMA読み取り要求キュー（QN = 1またはインバウンドRDMA読み取り要求キュー（IRRQ））をターゲットとするリモートエンドポイントのQPに送信されるタグなしメッセージを使用して実行されます接続で。 RDMA読み取り応答は、タグ付きメッセージを使用して、各RDMA読み取り要求に関連付けられたデータをリモートエンドポイントからローカルエンドポイントに転送します。インバウンドRDMA読み取り要求は、それが受信されてから、RDMA要求に関連付けられた最後のタグ付きメッセージが確認応答されるまでIRRQに残ります。 IRRQはQPに関連付けられていますが、ワークキューではありません。代わりに、IRRQは、QPに関連付けられたRDMA読み取り要求を管理するために使用されるスタンドアロンキューです。 QPとIRRQの詳細については、[RDMAC]のセクション6を参照してください。 QPに設定する必要がある特性の1つは、IRRQのサイズです。このパラメーターは、インバウンドRDMA読み取りキュー深度（IRD）と呼ばれます。構成する必要があるQPのもう1つの特徴は、リモートエンドポイントQPのIRRQのサイズに基づく、同時送信RDMA読み取り要求の数のローカル制限です。このパラメーターは、Outbound RDMA Read Queue Depth（ORD）と呼ばれます。 ORDは、ローカルエンドポイントがリモートエンドポイントのIRRQ深度またはIRDをオーバーランしないように、同時RDMA読み取り要求の数を制限するために使用されます。アウトバウンドRDMA読み取りは、ローカルピア上のQPの送信キューに送信され、ローカルピア上の別の送信RDMA読み取り要求キューには送信されないことに注意してください。ローカルエンドポイントはORDを使用して同時読み取り要求を厳密に制限し、リモートエンドポイントでIRRQオーバーランが発生しないようにします。
Determination of the values of the ORD and IRD are left to the ULP by the current RDDP suite of protocols and also by [RDMAC]. Since this negotiation of ORD and IRD is typical, it is desirable to provide a common mechanism as described in this document.
ORDとIRDの値の決定は、現在のRDDPプロトコルスイートと[RDMAC]によってULPに任されています。このORDとIRDのネゴシエーションは典型的なものであるため、このドキュメントで説明されているような共通のメカニズムを提供することが望まれます。
MPA defines encoding of DDP Segments in Framed Upper Layer Protocol PDUs (FULPDUs). Generation of FULPDUs requires the ability to periodically insert MPA Markers and to generate the MPA CRC-32c for each frame. Reception may require parsing/removing the markers after using them to identify MPA Frame boundaries and validation of the MPA-CRC32c.
MPAは、Framed Upper Layer Protocol PDU（FULPDU）のDDPセグメントのエンコーディングを定義します。 FULPDUを生成するには、定期的にMPAマーカーを挿入し、フレームごとにMPA CRC-32cを生成する機能が必要です。受信では、マーカーを使用してMPAフレーム境界を識別し、MPA-CRC32cを検証した後で、マーカーの解析/削除が必要になる場合があります。
A major design objective for MPA was to ensure that the resulting TCP stream would be fully compliant for any and all TCP-aware middleboxes. The challenge is that while only some TCP payload streams are a valid stream of MPA FULPDUs, any sequence of bytes is a valid TCP payload stream. The determination that a given stream is in a specific MPA mode cannot be made at the MPA or TCP layer. Therefore, enabling of MPA mode is handled by the ULP.
MPAの主な設計目標は、結果のTCPストリームがすべてのTCP対応ミドルボックスに完全に準拠するようにすることでした。問題は、一部のTCPペイロードストリームのみがMPA FULPDUの有効なストリームであるのに対し、バイトのシーケンスは有効なTCPペイロードストリームであることです。特定のストリームが特定のMPAモードにあるという決定は、MPAまたはTCPレイヤーでは行うことができません。したがって、MPAモードの有効化はULPによって処理されます。
The MPA protocol can be viewed as having two parts:
MPAプロトコルは、次の2つの部分から構成されています。
o a specification of generation and reception of MPA FULPDUs. This is unchanged by enhanced RDMA connection establishment.
o MPA FULPDUの生成と受信の仕様。これは、拡張RDMA接続の確立によって変更されていません。
o a pre-MPA exchange of messages to enable a specific MPA mode for the TCP connection. Enhanced RDMA connection establishment extends this protocol with two new features.
o TCP接続の特定のMPAモードを有効にするためのメッセージの事前MPA交換。拡張RDMA接続の確立により、このプロトコルが2つの新機能で拡張されます。
In typical implementations, generation and reception of MPA FULPDUs is handled by hardware. The exchange of the MPA Request and Reply Frames is then handled by host software. As will be explained, this implementation split impedes applications that are not compatible with the client-server assumptions in the current MPA Request/Reply exchange.
通常の実装では、MPA FULPDUの生成と受信はハードウェアによって処理されます。 MPA要求フレームと応答フレームの交換は、ホストソフトウェアによって処理されます。説明するように、この実装の分割は、現在のMPA要求/応答交換におけるクライアント/サーバーの想定と互換性のないアプリケーションを妨げます。
The exchange of MPA Request and Reply messages to place a TCP connection in MPA mode is specified in [RFC5044]. This protocol provides many benefits to the design of MPA FULPDU hardware:
TCP接続をMPAモードにするためのMPA要求および応答メッセージの交換は、[RFC5044]で指定されています。このプロトコルは、MPA FULPDUハードウェアの設計に多くの利点を提供します。
o The ULP is responsible for specifying the exact MPA Mode (Markers enabled or disabled, CRC-32c enabled or suppressed) and the point in the TCP streams (inbound and outbound) where MPA Frames will begin.
o ULPは、正確なMPAモード（マーカーの有効化または無効化、CRC-32cの有効化または抑制）およびMPAフレームが開始するTCPストリーム（インバウンドおよびアウトバウンド）のポイントを指定する責任があります。
o Before the first MPA Frame is transmitted, all pre-MPA mode TCP payloads will have been acknowledged by the peer. Therefore, it is never necessary to generate a retransmission that mixes pre-MPA and MPA payload.
o 最初のMPAフレームが送信される前に、すべてのpre-MPAモードのTCPペイロードがピアによって確認されています。したがって、プレMPAペイロードとMPAペイロードを混合した再送信を生成する必要はありません。
o Before MPA reception is enabled, all incoming pre-MPA mode TCP payloads will have been acknowledged. Therefore, the host will never receive a TCP segment that mixes pre-MPA and MPA payload.
o MPA受信が有効になる前に、着信するすべてのプレMPAモードのTCPペイロードが確認されます。したがって、ホストは、MPA以前のペイロードとMPAペイロードが混在するTCPセグメントを受信することはありません。
The limitation of the current MPA Request/Reply exchange is that it does not define a Ready to Receive (RTR) indication that the active side would send, so that the passive side can know that the last non-MPA payload (the MPA Reply) had been received.
現在のMPA要求/応答交換の制限は、アクティブ側が送信する受信準備（RTR）表示を定義しないため、パッシブ側は最後の非MPAペイロード（MPA応答）を認識できることです。受け取っていた。
Instead, the role of an RTR indication is piggybacked on the first MPA FULPDU sent by the active side. This is actually a valuable optimization for all applications that fit the classic client-server model. The client only initiates the connection when it has a request to send to the server, and the server has nothing to send until it has received and processed the client request.
代わりに、RTR指示の役割は、アクティブ側から送信された最初のMPA FULPDUに便乗します。これは実際には、従来のクライアントサーバーモデルに適合するすべてのアプリケーションにとって価値のある最適化です。クライアントは、サーバーへの送信要求がある場合にのみ接続を開始し、サーバーは、クライアント要求を受信して処理するまで送信するものはありません。
Even applications where the server sends some configuration data immediately can easily send the same information as application Private Data in the MPA Reply. So the currently defined exchange works for almost all applications.
サーバーが構成データをすぐに送信するアプリケーションでも、MPA応答のアプリケーションのプライベートデータと同じ情報を簡単に送信できます。したがって、現在定義されている交換は、ほとんどすべてのアプリケーションで機能します。
Many peer-to-peer applications, especially those involving cluster calculations (frequently using Message Passing Interface (MPI) [UsingMPI] or [RDS]), have no natural client or server roles ([PPMPI] [OpenMP]). Typically, one member of the cluster is arbitrarily selected to initiate the connection when the distributed task is launched, while the other accepts it. At startup time, however, there is no way to predict which node will have the first message to actually send. Immediately establishing the connections is valuable because it reduces latency once results are ready to transmit and it validates connectivity throughout the cluster.
多くのピアツーピアアプリケーション、特にクラスター計算（頻繁にメッセージパッシングインターフェース（MPI）[UsingMPI]または[RDS]を使用）を含むアプリケーションには、自然なクライアントまたはサーバーの役割（[PPMPI] [OpenMP]）がありません。通常、クラスターの1つのメンバーは、分散タスクの起動時に接続を開始するために任意に選択され、他のメンバーはそれを受け入れます。ただし、起動時に、実際に送信する最初のメッセージがどのノードにあるかを予測する方法はありません。結果を送信する準備ができるとレイテンシが減少し、クラスター全体の接続を検証するため、すぐに接続を確立することは価値があります。
The lack of an explicit RTR indication in the MPA Request/Reply exchange forces all applications to have a first message from the connection initiator, whether or not this matches the application communication model.
MPA要求/応答交換に明示的なRTR指示がないため、これがアプリケーション通信モデルと一致するかどうかに関係なく、すべてのアプリケーションに接続開始者からの最初のメッセージが送信されます。
The requirement that the RDMA connection initiator sends the first message does not appear to be onerous on first examination. The natural question is why the application layer would not simply generate a dummy message when there is no other message to submit.
RDMA接続イニシエーターが最初のメッセージを送信するという要件は、最初の検査では面倒ではないようです。当然のことですが、他に送信するメッセージがないときにアプリケーション層がダミーメッセージを生成しないのはなぜですか。
There are three factors that make this workaround unsuitable for many peer-to-peer applications:
この回避策を多くのピアツーピアアプリケーションに適さないようにする3つの要因があります。
o Transport-Neutral APIs.
o トランスポート中立API。
o Work/Completion Queue Accounting.
o 作業/完了キューアカウンティング。
o Host-based implementation of MPA Fencing.
o MPAフェンシングのホストベースの実装。
Many of these applications access RDMA services using a transport-neutral API such as [DAPL] or [OFA]. Only RDDP over TCP [RFC5044] has a first message requirement. Other RDMA transports, including RDDP over SCTP (see [RFC5043]) and InfiniBand (see [IBTA]), do not.
これらのアプリケーションの多くは、[DAPL]や[OFA]などのトランスポートニュートラルAPIを使用してRDMAサービスにアクセスします。 RDDP over TCP [RFC5044]のみに最初のメッセージ要件があります。 RDDP over SCTP（[RFC5043]を参照）やInfiniBand（[IBTA]を参照）など、他のRDMAトランスポートはサポートしていません。
Application or middleware communications can be expressed as transport-neutral RDMA operations, allowing lower software layers to translate to transport and device specifics. Having a distinct extra message that is required only for one transport undermines the application's goal of being transport neutral.
アプリケーションまたはミドルウェアの通信は、トランスポートニュートラルなRDMA操作として表現でき、下位のソフトウェアレイヤーをトランスポートおよびデバイスの詳細に変換できます。 1つのトランスポートにのみ必要な明確な追加メッセージがあると、アプリケーションのトランスポートニュートラルになるという目標が損なわれます。
RDMA local APIs conventionally use Work Queues to submit requests (Work Queue elements or WQEs) and to asynchronously receive completions (in Completion Queues or CQs).
RDMAローカルAPIは、通常、ワークキューを使用してリクエストを送信し（ワークキューエレメントまたはWQE）、非同期で完了を受信します（完了キューまたはCQ）。
Each Work Request can generate a Completion Queue Entry (CQE). Completions for successful transmit Work Requests are frequently suppressed, but the CQ capacity must account for the possibility that each will complete in error. A CQ can receive completions from multiple Work Queues.
各作業要求は、完了キューエントリ（CQE）を生成できます。正常に送信された作業要求の完了は頻繁に抑制されますが、CQ容量はそれぞれがエラーで完了する可能性を考慮する必要があります。 CQは、複数のワークキューから完了を受け取ることができます。
CQs are defined to allow hardware RDMA implementations to generate CQEs directly to a user-space-mapped buffer. This enables a user-space RDMA Consumer to reap completions without requiring kernel intervention.
CQは、ハードウェアRDMA実装がユーザー空間にマップされたバッファーに直接CQEを生成できるように定義されています。これにより、ユーザー空間のRDMAコンシューマーは、カーネルの介入を必要とせずに完了を取得できます。
A hardware RDMA implementation cannot reasonably wait for an available slot in the CQ. The queue must be sized such that an overflow will not occur. When an overflow does occur, it is considered a catastrophic error and will typically require tearing down all RDMA connections using that CQ.
ハードウェアRDMA実装は、CQで利用可能なスロットを合理的に待つことができません。キューは、オーバーフローが発生しないようなサイズにする必要があります。オーバーフローが発生すると、それは壊滅的なエラーと見なされ、通常、そのCQを使用するすべてのRDMA接続を切断する必要があります。
This style of interface is very efficient, but places a burden on the application to properly size each CQ to match the Work Queues that feed it.
このスタイルのインターフェースは非常に効率的ですが、アプリケーションに負担をかけて、各CQを適切なサイズにして、それを供給するワークキューに一致させます。
While the format of both WQEs and CQEs is transport and device dependent, a transport-neutral API can deal with WQEs and CQEs as abstract transport- and device-neutral objects. Therefore, the number of WQEs and CQEs required for an application can be transport and device neutral.
WQEとCQEの両方の形式はトランスポートとデバイスに依存しますが、トランスポートニュートラルAPIは、WQEとCQEをトランスポートおよびデバイスニュートラルな抽象的なオブジェクトとして扱うことができます。したがって、アプリケーションに必要なWQEおよびCQEの数は、トランスポートおよびデバイスニュートラルにすることができます。
The capacity of the Work Queues and CQs can be calculated in an abstract transport- and device-neutral fashion. If a dummy operation approach is used, it would require lower layers to know the usage model, and would disrupt the calculations by inserting a dummy "operation" Work Request and filtering out the matching completion. The lower layer does not know the usage model on which the queue sizes are built, nor does it know how frequently an insertion will be required.
ワークキューとCQの容量は、トランスポートおよびデバイスに依存しない抽象的な方法で計算できます。ダミー操作アプローチを使用する場合、使用モデルを知るために下位層が必要となり、ダミーの「操作」作業要求を挿入して一致する完了をフィルターで除外することにより、計算を中断します。下位層は、キューサイズが構築されている使用モデルも、挿入が必要になる頻度もわかりません。
Many hardware implementations of RDDP using MPA/TCP do not handle the MPA Request/Reply exchange in hardware, rather they are handled by the host processor in software. With such designs, it is common for the MPA Fencing to be implemented in the user-space, device-specific library (commonly referred to as a 'User Verbs' library or module).
MPA / TCPを使用したRDDPの多くのハードウェア実装は、ハードウェアでMPA要求/応答交換を処理せず、ソフトウェアでホストプロセッサによって処理されます。このような設計では、MPAフェンシングがユーザー空間のデバイス固有のライブラリ（一般に「ユーザー動詞」ライブラリまたはモジュールと呼ばれる）に実装されるのが一般的です。
When the generation and reception of MPA FULPDUs are already dedicated to hardware, a Work Completion can only be generated by an untagged message, since arrival of a message for a tagged buffer does not necessarily generate a completion and is done without any interaction with ULP [RFC5040].
MPA FULPDUの生成と受信がすでにハードウェア専用である場合、タグ付きバッファのメッセージの到着は必ずしも完了を生成するわけではなく、ULPとの相互作用なしに行われるため、作業完了はタグなしメッセージによってのみ生成できます。 RFC5040]。
Below we provide an overview of Enhanced Connection Setup. The goal is to allow standard negotiation of the ORD/IRD setting on both sides of the RDMA connection and/or to negotiate the initial data transfer operation by the initiator when the existing 'client sends first' rule does not match application requirements.
以下に、拡張接続セットアップの概要を示します。目標は、RDMA接続の両側でORD / IRD設定の標準ネゴシエーションを許可すること、および/または既存の「クライアントが最初に送信する」ルールがアプリケーション要件に一致しない場合に、イニシエーターによる初期データ転送操作をネゴシエートすることです。
The RDMA connection initiator sends an MPA Request, as specified in [RFC5044]; the new format defined here allows for:
[RFC5044]で指定されているように、RDMA接続イニシエーターはMPA要求を送信します。ここで定義されている新しいフォーマットでは、
o Standardized negotiation of ORD and IRD.
o ORDとIRDの標準化された交渉。
o Negotiation of RTR functionality and the RDMA message type to use as the RTR indication.
o RTR機能のネゴシエーション、およびRTRインジケーションとして使用するRDMAメッセージタイプ。
The RDMA connection responder processes the MPA Request and generates an MPA Reply, as specified in [RFC5044]; the new format completes the negotiation.
[RFC5044]で指定されているように、RDMA接続レスポンダはMPA要求を処理し、MPA応答を生成します。新しい形式でネゴシエーションが完了します。
The local interface needs to provide a way for a ULP to request the use of explicit RTR indication on a per-application or per-connection basis when an explicit RTR indication will be required. Piggybacking the RTR on a Client's first message is a valuable optimization for most connections.
ローカルインターフェイスは、明示的なRTR表示が必要な場合に、ULPがアプリケーションごとまたは接続ごとに明示的なRTR表示の使用を要求する方法を提供する必要があります。クライアントの最初のメッセージでRTRをピギーバックすることは、ほとんどの接続にとって価値ある最適化です。
The RDMA connection initiator MUST NOT allow any later FULPDUs to be transmitted before the RTR indication. One method to achieve this is to delay notifying the ULP that the RDMA connection has been established until after any required RTR indication has been transmitted.
RDMA接続イニシエーターは、RTR指示の前に、それ以降のFULPDUが送信されることを許可してはなりません（MUST NOT）。これを達成する1つの方法は、必要なRTR指示が送信されるまで、RDMA接続が確立されたことをULPに通知することを遅らせることです。
All MPA exchanges are performed via TCP prior to RDMA establishment, and are therefore signaled via TCP and not via RDMA completion.
すべてのMPA交換はRDMA確立の前にTCPを介して実行されるため、RDMA完了ではなくTCPを介して通知されます。
Enhanced RDMA connection establishment uses an alternate format for MPA Requests and Replies as follows:
拡張RDMA接続の確立では、次のように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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | |
+ Key (16 bytes containing "MPA ID Req Frame") +
4 | (4D 50 41 20 49 44 20 52 65 71 20 46 72 61 6D 65) |
+ Or (16 bytes containing "MPA ID Rep Frame") +
8 | (4D 50 41 20 49 44 20 52 65 70 20 46 72 61 6D 65) |
+ +
12 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 |M|C|R|S| Res | Rev | PD_Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Private Data ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key: Unchanged from [RFC5044].
キー：[RFC5044]から変更なし。
M: Unchanged from [RFC5044].
M：[RFC5044]から変更なし。
C: Unchanged from [RFC5044].
C：[RFC5044]から変更なし。
R: Unchanged from [RFC5044].
R：[RFC5044]から変更なし。
S: One, if the Private Data begins with the enhanced RDMA connection establishment data; 0 otherwise.
S：1つは、プライベートデータが拡張RDMA接続確立データで始まる場合。それ以外の場合は0。
Res: One bit smaller than in [RFC5044]; otherwise unchanged. In [RFC5044], the 'Res' field, in which the newly defined 'S' bit resides, is reserved for future use. [RFC5044] specifies that 'Res' MUST be set to zero when sending and MUST NOT be checked on reception, making use of 'S' bit backwards compatibility with the original MPA Frame format. When the 'S' bit is set to zero, no additional Private Data is used for enhanced RDMA connection establishment; therefore, the resulting MPA Request and Reply Frames are identical to the unenhanced protocol.
Res：[RFC5044]よりも1ビット小さい;それ以外は変更されません。 [RFC5044]では、新しく定義された「S」ビットが存在する「Res」フィールドは、将来の使用のために予約されています。 [RFC5044]は、元のMPAフレーム形式との「S」ビットの下位互換性を利用して、送信時に「Res」をゼロに設定する必要があり、受信時にチェックしてはならないことを指定します。 「S」ビットがゼロに設定されている場合、追加のプライベートデータは拡張RDMA接続の確立に使用されません。したがって、結果のMPA要求フレームと応答フレームは、拡張されていないプロトコルと同じです。
Rev: This field contains the revision of MPA. To use any enhanced connection establishment feature, this MUST be set to two or higher. If no enhanced connection establishment features are desired, it MAY be set to one. A host accepting MPA connections MUST continue to accept MPA Requests with version one, even if it supports version two.
Rev：このフィールドには、MPAのリビジョンが含まれます。拡張接続確立機能を使用するには、これを2以上に設定する必要があります。拡張接続確立機能が必要ない場合は、1に設定できます。 MPA接続を受け入れるホストは、バージョン2をサポートしている場合でも、バージョン1のMPA要求を受け入れ続ける必要があります。
PD_Length: Unchanged from [RFC5044]. This is the total length of the Private Data field, including the enhanced RDMA connection establishment data, if present.
PD_Length：[RFC5044]から変更なし。これは、拡張RDMA接続確立データが存在する場合はそれを含む、プライベートデータフィールドの全長です。
Private Data: Unchanged from [RFC5044]. However, if the 'S' flag is set, Private Data MUST begin with enhanced RDMA connection establishment data (see Section 9).
プライベートデータ：[RFC5044]から変更なし。ただし、「S」フラグが設定されている場合、プライベートデータは拡張RDMA接続確立データで始まる必要があります（セクション9を参照）。
Enhanced RDMA connection establishment uses the first 32 bits of the Private Data field for IRD and ORD negotiation in the "DDP Stream Session Initiate" and "DDP Stream Session Accept" SCTP Session Control Chunks.
拡張RDMA接続の確立では、「DDPストリームセッション開始」および「DDPストリームセッション受け入れ」SCTPセッション制御チャンクのIRDおよびORDネゴシエーションにプライベートデータフィールドの最初の32ビットを使用します。
The type of the SCTP Session Control Chunk is defined by a Function Code (see [RFC4960]). [RFC5043] already defines codes for 'DDP Stream Session Initiate' and 'DDP Stream Session Accept', which are equivalent to an MPA Request Frame and an accepting MPA Reply Frame.
SCTPセッション制御チャンクのタイプは、機能コードによって定義されます（[RFC4960]を参照）。 [RFC5043]は、「DDPストリームセッションの開始」と「DDPストリームセッションの受け入れ」のコードをすでに定義しています。これらは、MPA要求フレームと受け入れ側のMPA応答フレームに相当します。
Enhanced RDMA connection establishment requires three additional function codes listed below:
拡張RDMA接続の確立には、以下にリストする3つの追加機能コードが必要です。
Enhanced DDP Stream Session Initiate: 0x005
拡張DDPストリームセッション開始：0x005
Enhanced DDP Stream Session Accept: 0x006
拡張DDPストリームセッション受け入れ：0x006
Enhanced DDP Stream Session Reject: 0x007
拡張DDPストリームセッション拒否：0x007
The Enhanced Reject function code MUST be used to indicate rejection of enhanced DDP stream session for a configuration that would have been accepted for unenhanced DDP stream session negotiation.
拡張拒否機能コードは、拡張されていないDDPストリームセッションネゴシエーションで受け入れられた構成の拡張DDPストリームセッションの拒否を示すために使用する必要があります。
The enhanced DDP stream session establishment follows the same rules as the standard DDP stream session establishment as defined in [RFC5043]. ULP-supplied Private Data MUST be included for Enhanced DDP Stream Session Initiate, Enhanced DDP Stream Session Accept, and Enhanced DDP Stream Session Reject messages, and MUST follow the enhanced RDMA connection establishment data in the DDP Stream Session Initiate and the Enhanced DDP Stream Session Accept messages.
拡張DDPストリームセッションの確立は、[RFC5043]で定義されている標準DDPストリームセッションの確立と同じルールに従います。 ULP提供のプライベートデータは、Enhanced DDP Stream Session Initiate、Enhanced DDP Stream Session Accept、Enhanced DDP Stream Session Rejectメッセージに含める必要があり、DDP Stream Session InitiateおよびEnhanced DDP Stream Sessionの拡張RDMA接続確立データに従う必要があります。メッセージを受け入れます。
Private Data length MUST NOT exceed 512 bytes in any message, including enhanced RDMA connection establishment data.
プライベートデータの長さは、拡張RDMA接続確立データを含め、どのメッセージでも512バイトを超えてはなりません。
Private Data MUST NOT be included in the DDP Stream Session TERM message.
プライベートデータをDDPストリームセッションのTERMメッセージに含めることはできません。
Received Extended DDP Stream Session Control messages SHOULD be reported to the ULP. If reported, any supplied Private Data MUST be available for the ULP to examine. For example, a received Extended DDP Stream Session Control message is not reported to ULP if none of the requested RTR indication types are supported by the receiver. In this case, the Provider MAY generate a reject reply message indicating which RTR indication types it supports.
受信した拡張DDPストリームセッション制御メッセージは、ULPに報告する必要があります（SHOULD）。報告された場合、ULPが検査できるように、提供されたプライベートデータを使用できる必要があります。たとえば、受信したExtended DDP Stream Session Controlメッセージは、要求されたRTR通知タイプがいずれもレシーバーでサポートされていない場合、ULPに報告されません。この場合、プロバイダーは、サポートするRTR表示タイプを示す拒否応答メッセージを生成できます（MAY）。
The enhanced DDP stream management MUST use the DDP stream session termination function code to terminate a stream established using enhanced DDP stream session function codes.
拡張DDPストリーム管理は、DDPストリームセッション終了関数コードを使用して、拡張DDPストリームセッション関数コードを使用して確立されたストリームを終了する必要があります。
[RFC5043] already supports either side sending the first DDP Message since the Payload Protocol Identifier (PPID) already distinguishes between Session Establishment and DDP Segments. The enhanced RDMA connection establishment provides the ULP a transport-independent way to support the peer-to-peer model.
[RFC5043]は、ペイロードプロトコル識別子（PPID）がすでにセッション確立とDDPセグメントを区別しているため、最初のDDPメッセージを送信する側をすでにサポートしています。拡張RDMA接続の確立により、ULPは、ピアツーピアモデルをサポートするトランスポートに依存しない方法を提供します。
The following additional Legal Sequences of DDP Stream Session messages are defined:
DDPストリームセッションメッセージの以下の追加の法的順序が定義されています。
o Enhanced Active/Passive Session Accepted: as with Section 6.2 of [RFC5043], but with the extended opcodes as defined in this document.
o 受け入れられた拡張アクティブ/パッシブセッション：[RFC5043]のセクション6.2と同じですが、このドキュメントで定義されている拡張オペコードを使用します。
o Enhanced Active/Passive Session Rejected: as with Section 6.3 of [RFC5043], but with the extended opcodes as defined in this document.
o 拒否された拡張アクティブ/パッシブセッション：[RFC5043]のセクション6.3と同じですが、このドキュメントで定義されている拡張オペコードを使用します。
o Enhanced Active/Passive Session Non-ULP Rejected: as with Section 6.4 of [RFC5043], but with the extended opcodes as defined in this document.
o 拡張されたアクティブ/パッシブセッションの非ULP拒否：[RFC5043]のセクション6.4と同様ですが、このドキュメントで定義されている拡張オペコードを使用します。
The RDMA connection establishment protocol is layered upon the protocols defined in [RFC5040] and [RFC5041]. Any enhanced RDMA connection establishment error generates an MPA termination message to a peer. [RFC5040] defines a triplet of protocol layers, error types, and error codes for error specification. MPA negotiation for RDMA connection establishment uses the following layer and error type for MPA error reporting: Layer: 0x2 - LLP Error Type: 0x0 - MPA
RDMA接続確立プロトコルは、[RFC5040]と[RFC5041]で定義されたプロトコルに基づいています。拡張RDMA接続確立エラーは、MPA終了メッセージをピアに生成します。 [RFC5040]は、エラー仕様のプロトコルレイヤー、エラータイプ、およびエラーコードの3つを定義します。 RDMA接続確立のMPAネゴシエーションは、MPAエラー報告に次のレイヤーとエラータイプを使用します。レイヤー：0x2-LLPエラータイプ：0x0-MPA
While [RFC5044] defines four error codes, [RFC5043] does not define any. Enhanced RDMA connection establishment extends the error codes defined in [RFC5044] by adding three new error codes. Thus, enhanced RDMA connection establishment is backward compatible with both [RFC5043] and [RFC5044].
[RFC5044]は4つのエラーコードを定義していますが、[RFC5043]は何も定義していません。拡張RDMA接続の確立は、3つの新しいエラーコードを追加することにより、[RFC5044]で定義されたエラーコードを拡張します。したがって、拡張RDMA接続の確立は、[RFC5043]と[RFC5044]の両方と下位互換性があります。
The following error codes are defined for enhanced RDMA connection establishment negotiation:
次のエラーコードは、拡張RDMA接続確立ネゴシエーション用に定義されています。
Error Code Description
--------------------------------------------------------
0x05 Local catastrophic
0x06 Insufficient IRD resources
0x07 No matching RTR option
Enhanced RDMA connection establishment places the following 32 bits at the beginning of the Private Data field of the MPA Request and Reply Frames or the "DDP Stream Session Initiate" and "DDP Stream Session Accept" SCTP Session Control Chunks. ULP-specified Private Data follows this field. The maximum amount of ULP-specified Private Data is therefore reduced by 4 bytes. Note that this field MUST be sent in network byte order, with the IRD and ORD encoded as 14-bit unsigned integers.
拡張RDMA接続の確立では、MPA要求および応答フレームのプライベートデータフィールドまたは「DDPストリームセッション開始」および「DDPストリームセッション受け入れ」SCTPセッション制御チャンクの先頭に、次の32ビットが配置されます。 ULP指定のプライベートデータはこのフィールドに従います。したがって、ULP指定のプライベートデータの最大量は4バイト削減されます。このフィールドは、IRDとORDが14ビットの符号なし整数としてエンコードされたネットワークバイトオーダーで送信する必要があることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 |A|B| IRD |C|D| ORD |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IRD: Inbound RDMA Read Queue Depth.
IRD：インバウンドRDMA読み取りキューの深さ。
ORD: Outbound RDMA Read Queue Depth.
ORD：アウトバウンドRDMA読み取りキューの深さ。
A: Control Flag for connection model.
A：接続モデルの制御フラグ。
B: Control Flag for use of a zero-length FULPDU (Send) RTR indication.
B：長さゼロのFULPDU（送信）RTR表示を使用するための制御フラグ。
C: Control Flag for use of a zero-length RDMA Write RTR indication.
C：長さゼロのRDMA書き込みRTR指示を使用するための制御フラグ。
D: Control Flag for use of a zero-length RDMA Read RTR indication.
D：長さゼロのRDMA読み取りRTR指示を使用するための制御フラグ。
The IRD and ORD are used for negotiation of Inbound RDMA Read Request Queue depths for both endpoints of the RDMA connection. The IRD is used to configure the depth of the Inbound RDMA Read Request Queue (IRRQ) on each endpoint. ORD is used to limit the number of simultaneous outbound RDMA Read Requests allowed at any given point in time in order to avoid IRRQ overruns at the remote endpoint. In order to describe the negotiation of both local endpoint and remote endpoint ORD and IRD values, four terms are defined:
IRDとORDは、RDMA接続の両方のエンドポイントのインバウンドRDMA読み取り要求キューの深さのネゴシエーションに使用されます。 IRDは、各エンドポイントでインバウンドRDMA読み取り要求キュー（IRRQ）の深さを構成するために使用されます。 ORDは、リモートエンドポイントでのIRRQオーバーランを回避するために、任意の時点で許可される同時送信RDMA読み取り要求の数を制限するために使用されます。ローカルエンドポイントとリモートエンドポイントの両方のORD値とIRD値のネゴシエーションを説明するために、4つの用語が定義されています。
Initiator IRD: The IRD value sent in the MPA Request or "DDP Stream Session Initiate" SCTP Session Control Chunk. This is the value of the initiator's IRD at the time of the MPA Request generation. The responder sets its local ORD value to this value or less. The initiator IRD is the maximum number of simultaneous inbound RDMA Read Requests that the initiator can support for the requested connection.
イニシエーターIRD：MPA要求または「DDPストリームセッション開始」SCTPセッション制御チャンクで送信されたIRD値。これは、MPAリクエスト生成時のイニシエーターのIRDの値です。レスポンダは、ローカルORD値をこの値以下に設定します。イニシエーターIRDは、イニシエーターが要求された接続に対してサポートできる同時インバウンドRDMA読み取り要求の最大数です。
Initiator ORD: The ORD value in the MPA Request or "DDP Stream Session Initiate" SCTP Session Control Chunk. This is the initial value of the initiator's ORD at the time of the MPA Request generation and also a request to the responder to support a responder IRD of at least this value. The initiator ORD is the maximum number of simultaneous outbound RDMA Read operations that the initiator desires the responder to support for the requested connection.
イニシエーターORD：MPA要求または「DDPストリームセッション開始」SCTPセッション制御チャンクのORD値。これは、MPAリクエスト生成時のイニシエーターのORDの初期値であり、少なくともこの値のレスポンダーIRDをサポートするためのレスポンダーへのリクエストでもあります。イニシエーターORDは、イニシエーターが要求された接続のサポートをレスポンダーに要求する同時アウトバウンドRDMA読み取り操作の最大数です。
Responder IRD: The IRD value returned in the MPA Reply or "DDP Stream Session Accept" SCTP Session Control Chunk. This is the actual value that the responder sets for its local IRD. This value is greater than or equal to the initiator ORD for successful negotiations. The responder IRD is the maximum number of simultaneous inbound RDMA Read Requests that the responder actually can support for the requested connection.
レスポンダーIRD：MPA応答または「DDPストリームセッション受け入れ」SCTPセッション制御チャンクで返されるIRD値。これは、レスポンダーがローカルIRDに設定する実際の値です。この値は、ネゴシエーションを成功させるためのイニシエーターORD以上です。レスポンダーIRDは、レスポンダーが実際に要求された接続をサポートできる同時インバウンドRDMA読み取り要求の最大数です。
Responder ORD: The ORD value returned in the MPA Reply or "DDP Stream Session Accept" SCTP Session Control Chunk. This is the actual value that the responder used for ORD and is less than or equal to the initiator IRD for successful negotiations. The responder ORD is the maximum number of simultaneous outbound RDMA Read operations that the responder will allow for the requested connection.
レスポンダーORD：MPA応答または「DDPストリームセッション受け入れ」SCTPセッション制御チャンクで返されるORD値。これは、応答側がORDに使用した実際の値であり、ネゴシエーションを成功させるための開始側IRD以下です。レスポンダーORDは、レスポンダーが要求された接続に対して許可する同時アウトバウンドRDMA読み取り操作の最大数です。
The relationships between these parameters after a successful negotiation is complete are the following:
ネゴシエーションが正常に完了した後のこれらのパラメーター間の関係は次のとおりです。
initiator ORD <= responder IRD
イニシエーターORD <=レスポンダーIRD
responder ORD <= initiator IRD
レスポンダーORD <=イニシエーターIRD
The responder and initiator MUST pass the peer's provided IRD and ORD values to the ULP, in addition to using the values as calculated by the preceding rules.
レスポンダーとイニシエーターは、前述のルールで計算された値を使用することに加えて、ピアから提供されたIRD値とORD値をULPに渡す必要があります。
The responder ORD SHOULD be set to a value less than or equal to the initiator IRD. If the initiator ORD is insufficient to support the selected connection model, the responder IRD MAY be increased; for example, if the initiator ORD is 0 (RDMA Reads will not be used by the ULP) and the responder supports use of a zero-length RDMA Read RTR indication, then the responder IRD can be set to 1. The responder MUST set its ORD at most to the initiator IRD. The responder MAY reject the connection request if the initiator IRD is not sufficient for the ULP-required ORD and specify the required ORD in the MPA Reject Frame responder ORD. Thus, the TERM message MUST contain Layer 2, Error Type 0, Error Code 6.
レスポンダーORDは、イニシエーターIRD以下の値に設定する必要があります（SHOULD）。イニシエーターORDが選択した接続モデルをサポートするには不十分な場合、レスポンダーIRDを増やすことができます。たとえば、イニシエーターORDが0（RDMA読み取りはULPで使用されない）であり、レスポンダーが長さゼロのRDMA読み取りRTR指示の使用をサポートしている場合、レスポンダーIRDは1に設定できます。開始者のIRDに対して最大でORD。イニシエーターIRDがULP必須ORDに十分でない場合、レスポンダーは接続要求を拒否し、MPA拒否フレームレスポンダーORDで必要なORDを指定できます。したがって、TERMメッセージには、レイヤー2、エラータイプ0、エラーコード6が含まれている必要があります。
Upon receiving the MPA Accept Frame from the responder, the initiator MUST set its IRD at least to the responder ORD and its ORD at most to the responder IRD. If the initiator does not have sufficient resources for the required IRD, it MUST send a TERM message to the responder indicating insufficient resources and terminate the connection due to insufficient resources. Thus, the TERM message MUST contain Layer 2, Error Type 0, Error Code 6.
イニシエーターは、レスポンダーからMPA Acceptフレームを受信すると、そのIRDを少なくともレスポンダーORDに設定し、そのORDを最大でレスポンダーIRDに設定する必要があります。イニシエーターが必要なIRDのための十分なリソースを持っていない場合、不十分なリソースを示すTERMメッセージをレスポンダーに送信し、不十分なリソースのために接続を終了する必要があります。したがって、TERMメッセージには、レイヤー2、エラータイプ0、エラーコード6が含まれている必要があります。
The initiator MUST pass the responder provided IRD and ORD to the ULP for both MPA Accept and Reject messages. The initiator ULP can decide its course of action. For example, the initiator ULP may terminate the established connection and renegotiate the responder ORD.
イニシエーターは、MPAのAcceptメッセージとRejectメッセージの両方について、IRDとORDを提供したレスポンダーをULPに渡す必要があります。イニシエーターULPは、その一連のアクションを決定できます。たとえば、イニシエータULPは確立された接続を終了し、レスポンダORDを再ネゴシエートします。
An all ones value (0x3FFF) indicates that automatic negotiation of the IRD or ORD is not desired, and that the ULP will be responsible for it. The responder MUST respond to an initiator ORD value of 0x3FFF by leaving its local endpoint IRD value unchanged and setting the IRD to 0x3FFF in its reply message. The initiator MUST leave its local endpoint ORD value unchanged upon receiving a responder IRD value of 0x3FFF. The responder MUST respond to an initiator IRD value of 0x3FFF by leaving its local endpoint ORD value unchanged, and setting ORD to 0x3FFF in its reply message. The initiator MUST leave its local endpoint IRD value unchanged upon receiving a responder ORD value of 0x3FFF.
すべて1の値（0x3FFF）は、IRDまたはORDの自動ネゴシエーションが望ましくなく、ULPがそれを担当することを示します。レスポンダは、ローカルエンドポイントのIRD値を変更せずに、応答メッセージでIRDを0x3FFFに設定することにより、0x3FFFのイニシエータORD値に応答する必要があります。イニシエーターは、0x3FFFのレスポンダーIRD値を受信すると、ローカルエンドポイントのORD値を変更しないでおく必要があります。レスポンダは、ローカルエンドポイントのORD値を変更せず、応答メッセージでORDを0x3FFFに設定することにより、0x3FFFのイニシエータIRD値に応答する必要があります。イニシエーターは、0x3FFFのレスポンダーORD値を受信すると、ローカルエンドポイントIRD値を変更しないでおく必要があります。
Control Flag A value 1 indicates that a peer-to-peer connection model is being performed, and value 0 indicates a client-server model. Control Flag B value 1 indicates that a zero-length FULPDU (Send) RTR indication is requested for the initiator and supported by the responder, respectively, 0 otherwise. Control Flag C value 1 indicates that a zero-length RDMA Write RTR indication is requested for the initiator and supported by the responder, respectively, 0 otherwise. Control Flag D value 1 indicates that a zero-length RDMA Read RTR indication is requested for the initiator and supported by the responder, respectively, 0 otherwise. The initiator MUST set Control Flag A to 1 for the peer-to-peer model. The initiator MUST set each Control Flag B, C, and D to 1 for each of the options it supports, if Control Flag A is set to 1.
制御フラグ値1は、ピアツーピア接続モデルが実行されていることを示し、値0は、クライアントサーバーモデルを示します。制御フラグBの値1は、長さがゼロのFULPDU（送信）RTR指示がイニシエーターに対して要求され、レスポンダーによってサポートされることを示します。それ以外の場合は0です。制御フラグCの値1は、ゼロ長のRDMA書き込みRTR指示がイニシエーターに対して要求され、レスポンダーによってサポートされることを示します。それ以外の場合は0です。制御フラグDの値1は、ゼロ長のRDMA読み取りRTR指示がイニシエーターに対して要求され、レスポンダーによってそれぞれサポートされていることを示します。それ以外の場合は0です。イニシエーターは、ピアツーピアモデルの制御フラグAを1に設定する必要があります。制御フラグAが1に設定されている場合、イニシエーターは、サポートするオプションごとに各制御フラグB、C、およびDを1に設定する必要があります。
The responder MUST support at least one RTR indication option if it supports Enhanced RDMA connection establishment. If Control Flag A is 1 in the MPA Request message, then the responder MUST set Control Flag A to 1 in the MPA reply message. For each initiator-supported RTR indication option, the responder SHOULD set the corresponding Control Flag if the responder can support that option in an MPA reply. The responder is not required to specify all RTR indication options it supports. The responder MUST set at least one RTR indication option if it supports more than one initiator-specified RTR indication option. The responder MAY include additional RTR indication options it supports, even if not requested by any initiator specified RTR indication options. If the responder does not support any of the initiator-specified RTR indication options, then the responder MUST set at least one RTR indication type option it supports.
レスポンダは、拡張RDMA接続の確立をサポートする場合、少なくとも1つのRTR表示オプションをサポートする必要があります。 MPA要求メッセージで制御フラグAが1の場合、レスポンダはMPA応答メッセージで制御フラグAを1に設定する必要があります。イニシエーターがサポートするRTR表示オプションごとに、レスポンダーがMPA応答でそのオプションをサポートできる場合、レスポンダーは対応する制御フラグを設定する必要があります（SHOULD）。レスポンダは、サポートするすべてのRTR表示オプションを指定する必要はありません。レスポンダは、複数のイニシエータ指定のRTR表示オプションをサポートする場合、少なくとも1つのRTR表示オプションを設定する必要があります。イニシエーターが指定したRTR表示オプションによって要求されない場合でも、レスポンダーは、サポートする追加のRTR表示オプションを含めることができます（MAY）。レスポンダがイニシエータ指定のRTR表示オプションのいずれもサポートしていない場合、レスポンダは、それがサポートする少なくとも1つのRTR表示タイプオプションを設定する必要があります。
Upon receiving the MPA Accept Frame with Control Flag A set to 1, the initiator MUST generate one of the negotiated RTR indications. If the initiator is not able to generate any of the responder-supported RTR indications, then it MUST send a TERM message to the responder indicating failure to negotiate a mutually compatible connection model or RTR option, and terminate the connection. Thus, the TERM message MUST contain Layer 2, Error Type 0, Error Code 7. The ULP can negotiate a ULP-level RTR indication when a Provider-level RTR indication cannot be negotiated.
制御フラグAが1に設定されたMPA Acceptフレームを受信すると、イニシエーターは、ネゴシエートされたRTR指示の1つを生成する必要があります。イニシエータがレスポンダがサポートするRTR指示を生成できない場合、相互に互換性のある接続モデルまたはRTRオプションのネゴシエーションの失敗を示すTERMメッセージをレスポンダに送信し、接続を終了する必要があります。したがって、TERMメッセージには、レイヤー2、エラータイプ0、エラーコード7が含まれている必要があります。プロバイダーレベルのRTRインジケーションをネゴシエートできない場合、ULPはULPレベルのRTRインジケーションをネゴシエートできます。
The initiator MUST set Control Flag A to 0 for the client-server model. The responder MUST set Control Flag A to 0 if Control Flag A is 0 in the request. If Control Flag A is set to 0, then Control Flags B, C, and D MUST also be set to 0. On reception, if Control Flag A is set to 0, then Control Flags B, C, and D MUST be ignored.
イニシエーターは、クライアントサーバーモデルの制御フラグAを0に設定する必要があります。要求で制御フラグAが0の場合、レスポンダは制御フラグAを0に設定する必要があります。制御フラグAが0に設定されている場合、制御フラグB、C、およびDも0に設定する必要があります。受信時に、制御フラグAが0に設定されている場合、制御フラグB、C、およびDは無視する必要があります。
The RTR indication type and ORD/IRD negotiation follows the following order:
RTR指示タイプとORD / IRDネゴシエーションは、次の順序に従います。
initiator (MPA Request) --> The initiator sets Control Flag A to 1 to indicate the peer-to-peer connection model and sets its initial IRD/ORD on the local endpoint of the connection. The initiator also sets Control Flags B, C, and D to 1 for each initiator-supported option of RTR indication.
イニシエーター（MPA要求）->イニシエーターは、ピアツーピア接続モデルを示すために制御フラグAを1に設定し、接続のローカルエンドポイントに初期IRD / ORDを設定します。イニシエーターは、RTR表示のイニシエーターがサポートするオプションごとに、制御フラグB、C、およびDを1に設定します。
responder (MPA Reply) <-- The responder matches the initiator's Control Flag A value and sets ORD/IRD to its local endpoint values based upon the initiator's initial ORD/IRD values and the number of simultaneous RDMA Read Requests required by the ULP. The responder sets Control Flags B, C, and D to 1 for each responder-supported option of RTR indication options for the peer-to-peer connection model. The responder also sets its IRD/ORD to actual values.
レスポンダー（MPA応答）<-レスポンダーは、イニシエーターの制御フラグA値に一致し、イニシエーターの初期ORD / IRD値とULPで必要な同時RDMA読み取り要求の数に基づいて、ORD / IRDをローカルエンドポイント値に設定します。レスポンダは、ピアツーピア接続モデルのRTR表示オプションの各レスポンダサポートオプションに対して、制御フラグB、C、およびDを1に設定します。レスポンダは、IRD / ORDを実際の値に設定します。
initiator (First RDMA Message) --> After the initiator modifies its ORD/IRD to match the responder's values as stated above, the initiator sends the first message of the negotiated RTR indication option. If no matching RTR indication option exists, then the initiator sends a TERM message.
イニシエーター（最初のRDMAメッセージ）->イニシエーターがORD / IRDを変更して上記のようにレスポンダーの値と一致させた後、イニシエーターはネゴシエートされたRTR表示オプションの最初のメッセージを送信します。一致するRTR表示オプションが存在しない場合、イニシエーターはTERMメッセージを送信します。
The initiator or responder MUST generate the TERM message that contains Layer 2, Error Type 0, Error Code 5 when it encounters any error locally for which the special Error Code is not defined in Section 8 before resetting the connection.
イニシエーターまたはレスポンダーは、接続をリセットする前に、セクション8で特別なエラーコードが定義されていないエラーがローカルで発生した場合、レイヤー2、エラータイプ0、エラーコード5を含むTERMメッセージを生成する必要があります。
The initiator requests enhanced RDMA connection establishment by sending an enhanced RDMA establishment request; an enhanced responder is REQUIRED to respond with an enhanced RDMA connection establishment response, whereas an unenhanced responder treats the enhanced request as incorrectly formatted and closes the TCP connection. All responders are REQUIRED to issue unenhanced RDMA connection establishment responses in response to unenhanced RDMA connection establishment requests.
イニシエーターは、拡張RDMA確立要求を送信することにより、拡張RDMA接続確立を要求します。拡張レスポンダは拡張RDMA接続確立応答で応答する必要がありますが、拡張レスポンダは拡張リクエストを誤ってフォーマットされたものとして扱い、TCP接続を閉じます。すべてのレスポンダは、拡張されていないRDMA接続確立要求に応答して、拡張されていないRDMA接続確立応答を発行する必要があります。
The initiator MUST NOT use the enhanced RDMA connection establishment formats or function codes when no enhanced functionality is desired.
イニシエーターは、拡張機能が不要な場合、拡張RDMA接続確立フォーマットまたは機能コードを使用してはなりません（MUST NOT）。
The responder MUST continue to accept unenhanced connection requests.
レスポンダは、拡張されていない接続要求を受け入れ続ける必要があります。
There are three initiator/responder cases that involve enhanced MPA: both the initiator and responder, only the responder, and only the initiator. The enhanced MPA Frame is defined by field 'S' set to 1.
拡張MPAが関与するイニシエーター/レスポンダーのケースは3つあります。イニシエーターとレスポンダーの両方、レスポンダーのみ、およびイニシエーターのみです。拡張MPAフレームは、フィールド「S」が1に設定されることで定義されます。
Enhanced MPA initiator and responder: If the responder receives an enhanced MPA message, it MUST respond with an enhanced MPA message.
拡張MPAイニシエーターとレスポンダー：レスポンダーが拡張MPAメッセージを受信した場合、拡張MPAメッセージで応答する必要があります。
Enhanced MPA responder only: If the responder receives an unenhanced MPA message ('S' is set to 0), it MUST respond with an unenhanced MPA message.
拡張MPAレスポンダーのみ：レスポンダーが拡張されていないMPAメッセージ（ 'S'が0に設定されている）を受信した場合、拡張されていないMPAメッセージで応答する必要があります。
Enhanced MPA initiator only: If the responder receives an enhanced MPA message and it does not support enhanced RDMA connection establishment, it MUST close the TCP connection and exit MPA. From a standard RDMA connection establishment point of view, the enhanced MPA Frame is improperly formatted as stated in [RFC5044]. Thus, both the initiator and responder report TCP connection termination to an application locally. In this case, the initiator MAY attempt to establish an RDMA connection using the unenhanced MPA protocol as defined in [RFC5044] if this protocol is compatible with the application, and let the ULP deal with ORD and IRD and peer-to-peer negotiations.
拡張MPAイニシエーターのみ：レスポンダーが拡張MPAメッセージを受信し、拡張RDMA接続の確立をサポートしていない場合、TCP接続を閉じてMPAを終了する必要があります。標準のRDMA接続確立の観点からは、[RFC5044]で述べられているように、拡張MPAフレームは不適切にフォーマットされています。したがって、イニシエーターとレスポンダーの両方が、TCP接続の終了をローカルでアプリケーションに報告します。この場合、イニシエーターは、このプロトコルがアプリケーションと互換性がある場合、[RFC5044]で定義されている拡張されていないMPAプロトコルを使用してRDMA接続を確立しようとし、ULPがORDおよびIRDとピアツーピアネゴシエーションを処理できるようにします。
A note for potential future enhancements for connection establishment negotiation: It is possible to further extend formatting of Private Data of the MPA Request and Reply Frames and to use other bits from the "Res" field to indicate additional Private Data formatting.
接続確立ネゴシエーションの潜在的な将来の拡張機能に関する注意：MPA要求および応答フレームのプライベートデータのフォーマットをさらに拡張し、「Res」フィールドから他のビットを使用して追加のプライベートデータフォーマットを示すことができます。
IANA has added the following entries to the "SCTP Function Codes for DDP Session Control" registry created by Section 3.5 of [RFC6580]:
IANAは、[RFC6580]のセクション3.5によって作成された「DDPセッション制御用のSCTP機能コード」レジストリに次のエントリを追加しました。
0x0005, Enhanced DDP Stream Session Initiate, [RFC6581]
0x0005、拡張DDPストリームセッション開始、[RFC6581]
0x0006, Enhanced DDP Stream Session Accept, [RFC6581]
0x0006、拡張DDPストリームセッション受け入れ、[RFC6581]
0x0007, Enhanced DDP Stream Session Reject, [RFC6581]
0x0007、拡張DDPストリームセッション拒否、[RFC6581]
IANA has added the following entries to the "MPA Errors" registry created by Section 3.3 of [RFC6580]:
IANAは、[RFC6580]のセクション3.3によって作成された「MPAエラー」レジストリに次のエントリを追加しました。
0x2/0x0/0x05, - MPA Error / Local catastrophic error, [RFC6581]
0x2/0x0/0x06 - MPA Error / Insufficient IRD resources, [RFC6581]
0x2/0x0/0x07 - MPA Error / No matching RTR option, [RFC6581]
The security considerations from RFC 5044 and RFC 5043 apply and the changes in this document do not introduce new security considerations. However, it is recommended that implementations do sanity checking for the input parameters, including ORD, IRD, and the control flags used for RTR indication option negotiation.
RFC 5044およびRFC 5043のセキュリティに関する考慮事項が適用され、このドキュメントの変更により、新しいセキュリティに関する考慮事項が導入されることはありません。ただし、実装では、ORD、IRD、RTR表示オプションのネゴシエーションに使用される制御フラグなどの入力パラメーターの健全性チェックを行うことをお勧めします。
The authors wish to thank Sean Hefty, Dave Minturn, Tom Talpey, David Black, and David Harrington for their valuable contributions and reviews of this document.
この文書の貴重な貢献とレビューをしてくれたSean Hefty、Dave Minturn、Tom Talpey、David Black、David Harringtonに感謝します。
[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月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RFC5040] Recio、R.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「A Remote Direct Memory Access Protocol Specification」、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「Reliable Transportsを介した直接データ配置」、RFC 5041、2007年10月。
[RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, October 2007.
[RFC5043] Bestler、C。およびR. Stewart、「Stream Control Transmission Protocol（SCTP）Direct Data Placement（DDP）Adaptation」、RFC 5043、2007年10月。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007.
[RFC5044] Culley、P.、Elzur、U.、Recio、R.、Bailey、S。、およびJ. Carrier、「Marker PDU Aligned Framing for TCP Specification」、RFC 5044、2007年10月。
[RFC6580] Ko, M. and D. Black, "IANA Registries for the Remote Direct Data Placement (RDDP) Protocols", RFC 6580, April 2012.
[RFC6580] Ko、M。およびD. Black、「リモート直接データ配置（RDDP）プロトコルのIANAレジストリ」、RFC 6580、2012年4月。
[DAPL] "Direct Access Programming Library", <http://www.datcollaborative.org/uDAPL_doc_062102.pdf>.
[DAPL]「ダイレクトアクセスプログラミングライブラリ」、<http://www.datcollaborative.org/uDAPL_doc_062102.pdf>。
[IBTA] "InfiniBand Architecture Specification Release 1.2.1", <http://www.infinibandta.org>.
[IBTA]「InfiniBand Architecture Specification Release 1.2.1」、<http://www.infinibandta.org>。
[OFA] "OFA verbs & APIs", <http://www.openfabrics.org/>.
[OFA]「OFA verbs＆APIs」、<http://www.openfabrics.org/>。
[OpenMP] McGraw-Hill, "Parallel Programming in C with MPI and OpenMP", 2003.
[OpenMP] McGraw-Hill、「Cでの並列プログラミングとMPIおよびOpenMP」、2003年。
[PPMPI] Morgan Kaufmann Publishers Inc., "Parallel Programming with MPI", 2008.
[PPMPI] Morgan Kaufmann Publishers Inc。、「MPIによる並列プログラミング」、2008年。
[RDMAC] "RDMA Protocol Verbs Specification (Version 1.0)", <http://www.rdmaconsortium.org/home/ draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>.
[RDMAC] "RDMA Protocol Verbs Specification（Version 1.0）"、<http://www.rdmaconsortium.org/home/ draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>。
[RDS] Open Fabrics Association, "Reliable Datagram Socket", 2008, <http://www.openfabrics.org/archives/spring2008sonoma>.
[RDS] Open Fabrics Association、「Reliable Datagram Socket」、2008、<http://www.openfabrics.org/archives/spring2008sonoma>。
[UsingMPI] MIT Press, "Using MPI-2: Advanced Features of the Message Passing Interface", 1999.
[UsingMPI] MIT Press、「Using MPI-2：Advanced Features of the Message Passing Interface」、1999。
[VIA] Cameron, Don and Greg Regnier, "Virtual Interface Architecture", Intel, April 2002.
[VIA] Cameron、DonおよびGreg Regnier、「Virtual Interface Architecture」、Intel、2002年4月。
Authors' Addresses
著者のアドレス
Arkady Kanevsky (editor) Dell Inc. One Dell Way, MS PS2-47 Round Rock, TX 78682 USA
Arkady Kanevsky（editor）Dell Inc. One Dell Way、MS PS2-47 Round Rock、TX 78682 USA
Phone: +1-512-728-0000
EMail: arkady.kanevsky@gmail.com
Caitlin Bestler (editor) Nexenta Systems 555 E El Camino Real #104 Sunnyvale, CA 94087 USA
Caitlin Bestler（editor）Nexenta Systems 555 E El Camino Real＃104 Sunnyvale、CA 94087 USA
Phone: +1-949-528-3085
EMail: Caitlin.Bestler@nexenta.com
Robert Sharp Intel LAD High Performance Message Passing, Mailstop: AN1-WTR1 1501 South Mopac, Suite 400 Austin, TX 78746 USA
Robert Sharp Intel LAD高性能メッセージパッシング、Mailstop：AN1-WTR1 1501 South Mopac、Suite 400 Austin、TX 78746 USA
Phone: +1-512-493-3242
EMail: robert.o.sharp@intel.com
Steve Wise Open Grid Computing 4030 Braker Lane STE 130 Austin, TX 78759 USA
Steve Wise Open Grid Computing 4030 Braker Lane STE 130 Austin、TX 78759 USA
Phone: +1-512-343-9196 x101
EMail: swise@opengridcomputing.com