Network Working Group P. Culley
Request for Comments: 5044 Hewlett-Packard Company
Category: Standards Track U. Elzur
Broadcom Corporation
R. Recio
IBM Corporation
S. Bailey
Sandburst Corporation
J. Carrier
Cray Inc.
October 2007
Marker PDU Aligned Framing for TCP 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
抽象
Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level.
RFC 5041に記載されているようにマーカーPDU配向フレーミング（MPA）は、TCPと直接データプレースメントプロトコル（DDP）との間の「適合層」として機能するように設計されたそれ保存を添加しながら、TCPの信頼性、順序配信を保持DDPが必要となる高レベルのプロトコルのレコード境界の。 MPAは、該当するTCPのRFCに完全に準拠しており、既存のTCP実装で利用することができます。 MPAは、実装にバッファリング要件を削減し、システムレベルでのパフォーマンスを改善するために、TCP、MPAとDDPを組み合わせた統合型の実装をサポートしています。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Protocol Overview ..........................................5
2. Glossary ........................................................8
3. MPA's Interactions with DDP ....................................11
4. MPA Full Operation Phase .......................................13
4.1. FPDU Format ...............................................13
4.2. Marker Format .............................................14
4.3. MPA Markers ...............................................14
4.4. CRC Calculation ...........................................16
4.5. FPDU Size Considerations ..................................21
5. MPA's interactions with TCP ....................................22
5.1. MPA transmitters with a standard layered TCP ..............22
5.2. MPA receivers with a standard layered TCP .................23
6. MPA Receiver FPDU Identification ...............................24
7. Connection Semantics ...........................................24
7.1. Connection Setup ..........................................24
7.1.1. MPA Request and Reply Frame Format .................26
7.1.2. Connection Startup Rules ...........................28
7.1.3. Example Delayed Startup Sequence ...................30
7.1.4. Use of Private Data ................................33
7.1.4.1. Motivation ................................33
7.1.4.2. Example Immediate Startup Using
Private Data ..............................35
7.1.5. "Dual Stack" Implementations .......................37
7.2. Normal Connection Teardown ................................38
8. Error Semantics ................................................39
9. Security Considerations ........................................40
9.1. Protocol-Specific Security Considerations .................40
9.1.1. Spoofing ...........................................40
9.1.1.1. Impersonation .............................41
9.1.1.2. Stream Hijacking ..........................41
9.1.1.3. Man-in-the-Middle Attack ..................41
9.1.2. Eavesdropping ......................................42
9.2. Introduction to Security Options ..........................42
9.3. Using IPsec with MPA ......................................43
9.4. Requirements for IPsec Encapsulation of MPA/DDP ...........43
10. IANA Considerations ...........................................44
Appendix A. Optimized MPA-Aware TCP Implementations ...............45
A.1. Optimized MPA/TCP Transmitters ............................46
A.2. Effects of Optimized MPA/TCP Segmentation .................46
A.3. Optimized MPA/TCP Receivers ...............................48
A.4. Re-segmenting Middleboxes and Non-Optimized MPA/TCP
Senders ...................................................49
A.5. Receiver Implementation ...................................50
A.5.1. Network Layer Reassembly Buffers ...................51
A.5.2. TCP Reassembly Buffers .............................52
Appendix B. Analysis of MPA over TCP Operations ...................52
B.1. Assumptions ...............................................53
B.1.1. MPA Is Layered beneath DDP .........................53
B.1.2. MPA Preserves DDP Message Framing ..................53
B.1.3. The Size of the ULPDU Passed to MPA Is Less Than
EMSS Under Normal Conditions .......................53
B.1.4. Out-of-Order Placement but NO Out-of-Order Delivery.54
B.2. The Value of FPDU Alignment ...............................54
B.2.1. Impact of Lack of FPDU Alignment on the Receiver
Computational Load and Complexity ..................56
B.2.2. FPDU Alignment Effects on TCP Wire Protocol ........60
Appendix C. IETF Implementation Interoperability with RDMA
Consortium Protocols ..................................62
C.1. Negotiated Parameters ......................................63
C.2. RDMAC RNIC and Non-Permissive IETF RNIC ....................64
C.2.1. RDMAC RNIC Initiator ................................65
C.2.2. Non-Permissive IETF RNIC Initiator ..................65
C.2.3. RDMAC RNIC and Permissive IETF RNIC .................65
C.2.4. RDMAC RNIC Initiator ................................66
C.2.5. Permissive IETF RNIC Initiator ......................67
C.3. Non-Permissive IETF RNIC and Permissive IETF RNIC ..........67
Normative References ..............................................68
Informative References ............................................68
Contributors ......................................................70
Table of Figures
図の表
Figure 1: ULP MPA TCP Layering .....................................5
Figure 2: FPDU Format .............................................13
Figure 3: Marker Format ...........................................14
Figure 4: Example FPDU Format with Marker .........................16
Figure 5: Annotated Hex Dump of an FPDU ...........................19
Figure 6: Annotated Hex Dump of an FPDU with Marker ...............20
Figure 7: Fully Layered Implementation ............................22
Figure 8: MPA Request/Reply Frame .................................26
Figure 9: Example Delayed Startup Negotiation .....................31
Figure 10: Example Immediate Startup Negotiation ..................35
Figure 11: Optimized MPA/TCP Implementation .......................45
Figure 12: Non-Aligned FPDU Freely Placed in TCP Octet Stream .....56
Figure 13: Aligned FPDU Placed Immediately after TCP Header .......58
Figure 14: Connection Parameters for the RNIC Types ...............63
Figure 15: MPA Negotiation between an RDMAC RNIC and a
Non-Permissive IETF RNIC ...............................65
Figure 16: MPA Negotiation between an RDMAC RNIC and a Permissive
IETF RNIC ..............................................66
Figure 17: MPA Negotiation between a Non-Permissive IETF RNIC and
a Permissive IETF RNIC .................................67
This section discusses the reason for creating MPA on TCP and a general overview of the protocol.
このセクションでは、TCPプロトコルの概要にMPAを作成する理由を説明します。
The Direct Data Placement protocol [DDP], when used with TCP [RFC793], requires a mechanism to detect record boundaries. The DDP records are referred to as Upper Layer Protocol Data Units by this document. The ability to locate the Upper Layer Protocol Data Unit (ULPDU) boundary is useful to a hardware network adapter that uses DDP to directly place the data in the application buffer based on the control information carried in the ULPDU header. This may be done without requiring that the packets arrive in order. Potential benefits of this capability are the avoidance of the memory copy overhead and a smaller memory requirement for handling out-of-order or dropped packets.
TCP [RFC793]で使用する直接データ配置プロトコル[DDP]は、レコード境界を検出するための機構が必要。 DDPレコードは、この文書で上位層プロトコルデータユニットと呼ばれています。上位層プロトコルデータユニット（ULPDU）境界の位置を特定する能力は直接ULPDUヘッダで運ばれた制御情報に基づいてアプリケーションバッファにデータを配置するDDPを使用するハードウェア・ネットワーク・アダプタに有用です。これは、パケットが順番に到着することを必要とせずに行うことができます。この能力の潜在的な利点は、オーバーヘッドメモリコピーの回避やアウトオブオーダーまたは廃棄されたパケット処理するための小さなメモリ要件です。
Many approaches have been proposed for a generalized framing mechanism. Some are probabilistic in nature and others are deterministic. An example probabilistic approach is characterized by a detectable value embedded in the octet stream, with no method of preventing that value elsewhere within user data. It is probabilistic because under some conditions the receiver may incorrectly interpret application data as the detectable value. Under these conditions, the protocol may fail with unacceptable frequency. One deterministic approach is characterized by embedded controls at known locations in the octet stream. Because the receiver can guarantee it will only examine the data stream at locations that are known to contain the embedded control, the protocol can never misinterpret application data as being embedded control data. For unambiguous handling of an out-of-order packet, a deterministic approach is preferred.
多くのアプローチが一般化フレーミングメカニズムのために提案されています。いくつかは本質的に確率論的であり、他は決定されています。例えば確率的アプローチは、ユーザデータ内の他の場所にその値を防止ない方法で、オクテットストリームに埋め込まれた検出値によって特徴付けられます。いくつかの条件の下で受信機が誤って検出値としてアプリケーションデータを解釈することができるので、それは確率的です。これらの条件下では、プロトコルは許容できない頻度で失敗することがあります。一つの決定論的なアプローチは、オクテットストリームの既知の位置に埋め込ま制御することを特徴とします。受信機は、それが唯一の組み込み制御を含むことが知られている場所で、データストリームを調べることを保証することができますので、プロトコルは、制御データを埋め込まれているとして、アプリケーションデータを誤って解釈することはできません。アウトオブオーダーパケットの明確な取り扱いのために、決定論的アプローチが好ましいです。
The MPA protocol provides a framing mechanism for DDP running over TCP using the deterministic approach. It allows the location of the ULPDU to be determined in the TCP stream even if the TCP segments arrive out of order.
MPAプロトコルは、DDPは、決定論的アプローチを使用してTCP上で動作するためのフレーミング機構を提供します。これは、TCPセグメントは順序が狂って到着てもULPDUの位置は、TCPストリーム内で決定することができます。
The layering of PDUs with MPA is shown in Figure 1, below.
MPAとPDUの積層は、以下、図1に示されています。
+------------------+
| ULP client |
+------------------+ <- Consumer messages
| DDP |
+------------------+ <- ULPDUs
| MPA* |
+------------------+ <- FPDUs (containing ULPDUs)
| TCP* |
+------------------+ <- TCP Segments (containing FPDUs)
| IP etc. |
+------------------+
* These may be fully layered or optimized together.
Figure 1: ULP MPA TCP Layering
図1：ULP MPA TCP階層化
MPA is described as an extra layer above TCP and below DDP. The operation sequence is:
MPAは、余分な層TCP上記とDDP以下のように記載されています。動作シーケンスは次のとおりです。
1. A TCP connection is established by ULP action. This is done using methods not described by this specification. The ULP may exchange some amount of data in streaming mode prior to starting MPA, but is not required to do so.
1. TCP接続がULPの作用によって確立されています。これは、この仕様で説明されていないメソッドを使用して行われます。 ULPは、MPAを開始する前に、ストリーミングモードでのデータのいくつかの量を交換してもよいが、そうする必要はありません。
2. The Consumer negotiates the use of DDP and MPA at both ends of a connection. The mechanisms to do this are not described in this specification. The negotiation may be done in streaming mode, or by some other mechanism (such as a pre-arranged port number).
2.消費者は、接続の両端のDDPとMPAの使用をネゴシエート。これを実行するためのメカニズムは、本明細書に記載されていません。ネゴシエーションは、ストリーミングモードで、または（例えば、前に配置されたポート番号のような）いくつかの他のメカニズムによって行うことができます。
3. The ULP activates MPA on each end in the Startup Phase, either as an Initiator or a Responder, as determined by the ULP. This mode verifies the usage of MPA, specifies the use of CRC and Markers, and allows the ULP to communicate some additional data via a Private Data exchange. See Section 7.1, Connection Setup, for more details on the startup process.
ULPによって決定されるよう3. ULPは、イニシエータまたはレスポンダのいずれかとして、始動段階中の各端部にMPAを活性化します。このモードは、MPAの使用状況を確認するCRCとマーカーの使用を指定し、ULPは、プライベートデータ交換を経て、いくつかの追加データを通信することができます。起動プロセスの詳細については、セクション7.1、接続設定を参照してください。
4. At the end of the Startup Phase, the ULP puts MPA (and DDP) into Full Operation and begins sending DDP data as further described below. In this document, DDP data chunks are called ULPDUs. For a description of the DDP data, see [DDP].
スタートアップフェーズの終わり4. ULPはフルオペレーションにMPA（およびDDP）を置き、さらに以下に説明するようにDDPデータの送信を開始します。この文書では、DDPデータチャンクはULPDUsと呼ばれています。 DDPデータの説明については、[DDP]参照。
Following is a description of data transfer when MPA is in Full Operation.
MPAはフルオペレーションである場合は、次のデータ転送の説明です。
1. DDP determines the Maximum ULPDU (MULPDU) size by querying MPA for this value. MPA derives this information from TCP or IP, when it is available, or chooses a reasonable value.
1. DDPは、この値にMPAを照会することによって、最大ULPDU（MULPDU）サイズを決定します。 MPAは、それが利用可能な場合、TCPやIPからこの情報を得て、または適切な値を選択します。
2. DDP creates ULPDUs of MULPDU size or smaller, and hands them to MPA at the sender.
2. DDPはMULPDUサイズ以下のULPDUsを作成し、送信側でMPAにそれらを渡します。
3. MPA creates a Framed Protocol Data Unit (FPDU) by prepending a header, optionally inserting Markers, and appending a CRC field after the ULPDU and PAD (if any). MPA delivers the FPDU to TCP.
3. MPAは、必要に応じて、ヘッダを付加マーカーを挿入し、ULPDUとPAD（もしあれば）の後にCRCフィールドを付加することにより額縁プロトコルデータユニット（FPDU）を作成します。 MPAは、TCPへのFPDUを提供します。
4. The TCP sender puts the FPDUs into the TCP stream. If the sender is optimized MPA/TCP, it segments the TCP stream in such a way that a TCP Segment boundary is also the boundary of an FPDU. TCP then passes each segment to the IP layer for transmission.
4. TCPの送信者はTCPストリームにのFPDUsを置きます。送信者は、MPA / TCP、TCPセグメントの境界もFPDUの境界であるような方法でそれセグメントTCPストリームを最適化されている場合。 TCPは、次に、送信のためにIP層に各セグメントを通過します。
5. The receiver may or may not be optimized. If it is optimized MPA/TCP, it may separate passing the TCP payload to MPA from passing the TCP payload ordering information to MPA. In either case, RFC-compliant TCP wire behavior is observed at both the sender and receiver.
前記受信機は、または最適化してもしなくてもよいです。それはMPA / TCP最適化されている場合は、MPAに発注情報をTCPペイロードを渡すからMPAへのTCPペイロードを渡して分離することができます。いずれの場合においても、RFCに準拠したTCPワイヤの動作は、送信側と受信側の両方で観察されます。
6. The MPA receiver locates and assembles complete FPDUs within the stream, verifies their integrity, and removes MPA Markers (when present), ULPDU_Length, PAD, and the CRC field.
6. MPA受信機は、検索し、ストリーム内のFPDUs完全に組み立て、それらの完全性を検証し、そしてMPAマーカー（存在する場合）、ULPDU_Length、PAD、及びCRCフィールドを除去します。
7. MPA then provides the complete ULPDUs to DDP. MPA may also separate passing MPA payload to DDP from passing the MPA payload ordering information.
7. MPAは、DDPへの完全なULPDUsを提供します。 MPAはまた、注文情報MPAペイロードを通過するDDPにMPAペイロードを通る分離することができます。
A fully layered MPA on TCP is implemented as a data stream ULP for TCP and is therefore RFC compliant.
TCP上の完全層状MPAは、TCPのデータストリームULPとして実装され、したがって、RFCに準拠しています。
An optimized DDP/MPA/TCP uses a TCP layer that potentially contains some additional behaviors as suggested in this document. When DDP/MPA/TCP are cross-layer optimized, the behavior of TCP (especially sender segmentation) may change from that of the un-optimized implementation, but the changes are within the bounds permitted by the TCP RFC specifications, and will interoperate with an un-optimized TCP. The additional behaviors are described in Appendix A and are not normative; they are described at a TCP interface layer as a convenience. Implementations may achieve the described functionality using any method, including cross-layer optimizations between TCP, MPA, and DDP.
最適化されたDDP / MPA / TCPは、この文書で提案されているように、潜在的にいくつかの追加の動作が含まれているTCP層を使用しています。 DDP / MPA / TCPは、クロスレイヤ最適化されている場合、TCP（特に送信者セグメンテーション）の挙動は、非最適化された実装のものから変更することができるが、変更は、TCP RFC仕様により許容範囲内であり、と相互運用します最適化されていないTCP。追加の動作は、付録Aに記載されており、規範的ではありませんされています。それらは便宜的にTCPの界面層で説明されています。実装はTCP、MPA、およびDDPとの間のクロスレイヤ最適化を含む任意の方法を使用して説明された機能性を、達成することができます。
An optimized DDP/MPA/TCP sender is able to segment the data stream such that TCP segments begin with FPDUs (FPDU Alignment). This has significant advantages for receivers. When segments arrive with aligned FPDUs, the receiver usually need not buffer any portion of the segment, allowing DDP to place it in its destination memory immediately, thus avoiding copies from intermediate buffers (DDP's reason for existence).
最適化されたDDP / MPA / TCP送信側は、TCPセグメントのFPDUs（FPDUアラインメント）で始まるように、データストリームセグメントに可能です。これは、受信機のための重要な利点を有しています。セグメントが整列のFPDUsで到着すると、受信機は、通常、従って中間バッファ（存在のDDPの理由）からコピーを回避する、DDPは直ちにその宛先メモリ内に配置することができ、セグメントの任意の部分をバッファリングする必要はありません。
An optimized DDP/MPA/TCP receiver allows a DDP on MPA implementation to locate the start of ULPDUs that may be received out of order. It also allows the implementation to determine if the entire ULPDU has been received. As a result, MPA can pass out-of-order ULPDUs to DDP for immediate use. This enables a DDP on MPA implementation to save a significant amount of intermediate storage by placing the ULPDUs in the right locations in the application buffers when they arrive, rather than waiting until full ordering can be restored.
最適化されたDDP / MPA / TCP受信機は、順序が狂って受信されてもよいULPDUsの開始を見つけるためにMPA実装にDDPを可能にします。また、全体のULPDUが受信された場合、実装が決定することができます。その結果、MPAはすぐに使用するためにDDPへのアウトオブオーダーULPDUs渡すことができます。これは、彼らが到着したときにアプリケーション・バッファの右の場所でULPDUsを置くのではなく、完全な秩序が回復することが可能になるまで待つことによって、中間貯蔵、かなりの量を節約するためにMPA実装にDDPを可能にします。
The ability of a receiver to recover out-of-order ULPDUs is optional and declared to the transmitter during startup. When the receiver declares that it does not support out-of-order recovery, the transmitter does not add the control information to the data stream needed for out-of-order recovery.
アウトオブオーダーULPDUs回復する受信機の能力は任意であり、起動時に送信機に宣言しました。受信機は、それはアウトオブオーダー回復をサポートしていないことを宣言した場合、送信側は、アウト・オブ・オーダー回復のために必要なデータストリームに制御情報を付加しません。
If the receiver is fully layered, then MPA receives a strictly ordered stream of data and does not deal with out-of-order ULPDUs. In this case, MPA passes each ULPDU to DDP when the last bytes arrive from TCP, along with the indication that they are in order.
受信機が完全に層状のであれば、MPAは、データの厳密に注文したストリームを受信し、アウトオブオーダーULPDUsに対処しません。最後のバイトは、それらが順序であることを示すと共に、TCPから到着したとき、この場合に、MPAは、DDPに各ULPDUを渡します。
MPA implementations that support recovery of out-of-order ULPDUs MUST support a mechanism to indicate the ordering of ULPDUs as the sender transmitted them and indicate when missing intermediate segments arrive. These mechanisms allow DDP to reestablish record ordering and report Delivery of complete messages (groups of records).
欠落中間セグメントが到着したとき、送信者がそれらを透過して示すように、アウトオブオーダULPDUsの回復をサポートするMPA実装はULPDUsの順序を示すためのメカニズムをサポートしなければなりません。これらのメカニズムは、DDPは、レコードの順序を再確立し、完全なメッセージ（レコードのグループ）の配信を報告することができます。
MPA also addresses enhanced data integrity. Some users of TCP have noted that the TCP checksum is not as strong as could be desired (see [CRCTCP]). Studies such as [CRCTCP] have shown that the TCP checksum indicates segments in error at a much higher rate than the underlying link characteristics would indicate. With these higher error rates, the chance that an error will escape detection, when using only the TCP checksum for data integrity, becomes a concern. A stronger integrity check can reduce the chance of data errors being missed.
MPAはまた、強化されたデータの整合性に対処しています。 TCPの一部のユーザーは、（[CRCTCP]参照）TCPチェックサムが望まれる可能性がほど強くはないことに留意しています。このような【CRCTCP]などの研究では、TCPチェックサムが示すであろう下にあるリンクの特性よりもはるかに高いレートで誤差のセグメントを示していることを示しています。これらのより高いエラー率では、データの整合性のための唯一のTCPチェックサムを使用しているときにエラーが、検出を逃れるだろうチャンスは、問題となります。データエラーの可能性を減らすことができ、より強い整合性チェックを逃したされています。
MPA includes a CRC check to increase the ULPDU data integrity to the level provided by other modern protocols, such as SCTP [RFC4960]. It is possible to disable this CRC check; however, CRCs MUST be enabled unless it is clear that the end-to-end connection through the network has data integrity at least as good as an MPA with CRC enabled (for example, when IPsec is implemented end to end). DDP's ULP expects this level of data integrity and therefore the ULP does not have to provide its own duplicate data integrity and error recovery for lost data.
MPAは、SCTP [RFC4960]などの他の近代的なプロトコルによって提供されるレベルにULPDUデータの整合性を高めるためにCRCチェックを含みます。このCRCチェックを無効にすることが可能です。ネットワークを介してエンド・ツー・エンドの接続が（IPsecは端と端を実現する場合、例えば）CRCとMPAと少なくとも同程度に良好なデータの整合性が有効になっていることが明らかでない限りしかし、CRCは有効にする必要があります。 DDPのULPは、データの整合性のこのレベルを期待し、したがって、ULPは、失われたデータのために、独自の重複データの整合性とエラー回復を提供する必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Consumer - the ULPs or applications that lie above MPA and DDP. The Consumer is responsible for making TCP connections, starting MPA and DDP connections, and generally controlling operations.
消費者 - MPAとDDPの上にあるのULPやアプリケーション。消費者は、TCP接続を行うMPAとDDP接続を開始し、一般的に動作を制御する責任があります。
CRC - Cyclic Redundancy Check.
CRC - 巡回冗長検査。
Delivery - (Delivered, Delivers) - For MPA, Delivery is defined as the process of informing DDP that a particular PDU is ordered for use. A PDU is Delivered in the exact order that it was sent by the original sender; MPA uses TCP's byte stream ordering to determine when Delivery is possible. This is specifically different from "passing the PDU to DDP", which may generally occur in any order, while the order of Delivery is strictly defined.
デリバリー - （配信、配信） - MPAの場合、配信は、特定のPDUを使用するために順序付けされていることをDDPを通知するプロセスとして定義されます。 PDUは、それが元の送信者によって送信された正確な順序で送達されます。 MPAは、配達が可能であるかを決定するためにTCPのバイトストリームの順序付けを使用しています。配信の順序を厳密に定義されているが、これは、一般的に任意の順序で発生することがあり、「DDPへPDUを渡す」より具体的に異なっています。
EMSS - Effective Maximum Segment Size. EMSS is the smaller of the TCP maximum segment size (MSS) as defined in RFC 793 [RFC793], and the current path Maximum Transmission Unit (MTU) [RFC1191].
エムス - 効果的な最大セグメントサイズ。エムスは、RFC 793 [RFC793]で定義されるようにTCP最大セグメントサイズ（MSS）の小さい、電流経路の最大転送単位（MTU）[RFC1191]。
FPDU - Framed Protocol Data Unit. The unit of data created by an MPA sender.
FPDUは - プロトコルデータユニットに入れます。 MPAの送信者によって作成されたデータの単位。
FPDU Alignment - The property that an FPDU is Header Aligned with the TCP segment, and the TCP segment includes an integer number of FPDUs. A TCP segment with an FPDU Alignment allows immediate processing of the contained FPDUs without waiting on other TCP segments to arrive or combining with prior segments.
FPDU整列 - FPDUがTCPセグメントと整列ヘッダであり、TCPセグメントのFPDUsの整数を含むプロパティ。 FPDU整列したTCPセグメントが到着する他のTCPセグメントに待機または前のセグメントと結合することなく含まのFPDUsの即時処理を可能にします。
FPDU Pointer (FPDUPTR) - This field of the Marker is used to indicate the beginning of an FPDU.
FPDUポインタ（FPDUPTR） - マーカーのこの分野はFPDUの始まりを示すために使用されます。
Full Operation (Full Operation Phase) - After the completion of the Startup Phase, MPA begins exchanging FPDUs.
フル動作（フル稼働相） - スタートアップ段階の完了後、MPAは、のFPDUsを交換し始めます。
Header Alignment - The property that a TCP segment begins with an FPDU. The FPDU is Header Aligned when the FPDU header is exactly at the start of the TCP segment (right behind the TCP headers on the wire).
ヘッダーの配置 - TCPセグメントがFPDUで始まるプロパティ。 FPDUヘッダー（右ワイヤ上のTCPヘッダの後ろに）TCPセグメントの開始時に正確である場合FPDUヘッダー整列されます。
Initiator - The endpoint of a connection that sends the MPA Request Frame, i.e., the first to actually send data (which may not be the one that sends the TCP SYN).
イニシエータ - （TCP SYNを送信一つでなくてもよい）は、実際にデータを送信するためのMPA要求フレームを送信し、接続、すなわち、第一のエンドポイント。
Marker - A four-octet field that is placed in the MPA data stream at fixed octet intervals (every 512 octets).
マーカー - 固定されたオクテットの間隔（各512オクテット）にMPAデータストリームに配置される4オクテットフィールド。
MPA-aware TCP - A TCP implementation that is aware of the receiver efficiencies of MPA FPDU Alignment and is capable of sending TCP segments that begin with an FPDU.
MPA対応TCP - MPA FPDU整列の受信効率を認識しており、FPDUで始まるTCPセグメントを送信することが可能なTCPの実装。
MPA-enabled - MPA is enabled if the MPA protocol is visible on the wire. When the sender is MPA-enabled, it is inserting framing and Markers. When the receiver is MPA-enabled, it is interpreting framing and Markers.
MPA対応 - MPAプロトコルはワイヤに表示されている場合MPAが有効になっています。送信者がMPA-有効になっている場合、それはフレーミングやマーカーを挿入しています。受信機は、MPA-有効になっている場合、それはフレーミングやマーカーを解釈しています。
MPA Request Frame - Data sent from the MPA Initiator to the MPA Responder during the Startup Phase.
MPA要求フレーム - スタートアップフェイズMPAレスポンダにMPAイニシエータから送信されたデータ。
MPA Reply Frame - Data sent from the MPA Responder to the MPA Initiator during the Startup Phase.
MPAは、フレームを返信する - データは、スタートアップ段階MPAイニシエータにMPAレスポンダから送信されます。
MPA - Marker-based ULP PDU Aligned Framing for TCP protocol. This document defines the MPA protocol.
MPA - TCPプロトコルのためのマーカーベースのULP PDU同盟フレーミング。この文書では、MPAプロトコルを定義します。
MULPDU - Maximum ULPDU. The current maximum size of the record that is acceptable for DDP to pass to MPA for transmission.
MULPDU - 最大ULPDU。 DDPは、送信のためにMPAに渡すために許容されるレコードの現在の最大サイズ。
Node - A computing device attached to one or more links of a network. A Node in this context does not refer to a specific application or protocol instantiation running on the computer. A Node may consist of one or more MPA on TCP devices installed in a host computer.
ノード - ネットワークの1つ以上のリンクに取り付けられたコンピューティングデバイス。この文脈において、ノードは、コンピュータ上で実行されている特定のアプリケーションまたはプロトコルのインスタンスを指すものではありません。ノードは、ホストコンピュータにインストールされているTCPデバイス上で一つ以上のMPAからなるものであってもよいです。
PAD - A 1-3 octet group of zeros used to fill an FPDU to an exact modulo 4 size.
PAD - 正確モジュロ4サイズにFPDUを充填するために使用されるゼロの1-3オクテット基。
PDU - Protocol data unit
PDU - プロトコルデータユニット
Private Data - A block of data exchanged between MPA endpoints during initial connection setup.
プライベートデータ - データのブロックは、初期接続のセットアップ時にMPAエンドポイント間で交換しました。
Protection Domain - An RDMA concept (see [VERBS-RDMA] and [RDMASEC]) that ties use of various endpoint resources (memory access, etc.) to the specific RDMA/DDP/MPA connection.
保護ドメイン - RDMA概念（[動詞-RDMA]および[RDMASEC]参照）、特定のRDMA / DDP / MPA接続に種々のエンドポイントリソース（メモリアクセス、等）の使用を結びつけます。
RDDP - A suite of protocols including MPA, [DDP], [RDMAP], an overall security document [RDMASEC], a problem statement [RFC4297], an architecture document [RFC4296], and an applicability document [APPL].
RDDP - MPA、[DDP]、[RDMAP]、全体的なセキュリティドキュメント[RDMASEC]、問題文[RFC4297]、アーキテクチャドキュメント[RFC4296]、および適用ドキュメント[APPL]を含む一連のプロトコル。
RDMA - Remote Direct Memory Access; a protocol that uses DDP and MPA to enable applications to transfer data directly from memory buffers. See [RDMAP].
RDMA - リモートダイレクトメモリアクセス。 DDPとMPAを使用するプロトコルは、メモリバッファから直接データを転送するアプリケーションを可能にします。 [RDMAP]を参照してください。
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.
リモートピア - 接続の反対側にMPAプロトコルの実装。 2つのノード間のプロトコル交換又は他の相互作用を記述するときに、リモートエンティティを参照するために使用。
Responder - The connection endpoint that responds to an incoming MPA connection request (the MAP Request Frame). This may not be the endpoint that awaited the TCP SYN.
レスポンダ - 受信MPA接続要求（MAP要求フレーム）に応答接続エンドポイント。これは、TCP SYNを待っていたエンドポイントではないかもしれません。
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.
起動フェーズ - より完全に互いにMPAエンドポイントを識別し、相互に接続固有設定情報を渡すのに役立つMPA接続の初期の交換。
ULP - Upper Layer Protocol. The protocol layer above the protocol layer currently being referenced. The ULP for MPA is DDP [DDP].
ULP - 上位層プロトコル。現在参照されているプロトコル層の上のプロトコル層。 MPAのためのULPは、DDP [DDP]です。
ULPDU - Upper Layer Protocol Data Unit. The data record defined by the layer above MPA (DDP). ULPDU corresponds to DDP's DDP segment.
ULPDU - 上位層プロトコルデータユニット。 MPA（DDP）上記層によって定義されるデータレコード。 ULPDUはDDPのDDPセグメントに対応します。
ULPDU_Length - A field in the FPDU describing the length of the included ULPDU.
ULPDU_Length - 含まULPDUの長さを記述するFPDUのフィールド。
DDP requires MPA to maintain DDP record boundaries from the sender to the receiver. When using MPA on TCP to send data, DDP provides records (ULPDUs) to MPA. MPA will use the reliable transmission abilities of TCP to transmit the data, and will insert appropriate additional information into the TCP stream to allow the MPA receiver to locate the record boundary information.
DDPは、送信側から受信側にDDPのレコード境界を維持するために、MPAが必要です。データを送信するためにTCP上でMPAを使用する場合は、DDPは、MPAにレコード（ULPDUs）を提供します。 MPAは、データを送信するためにTCPの信頼性の高い伝送能力を使用し、MPA受信機は、レコード境界の情報を見つけることができるようにTCPストリームに適切な追加情報を挿入します。
As such, MPA accepts complete records (ULPDUs) from DDP at the sender and returns them to DDP at the receiver.
そのため、MPAは、送信側でDDPからの完全な記録（ULPDUs）を受け入れ、受信機でDDPに返します。
MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU contained in one FPDU.
MPAは、1つのULPDU 1つのFPDUに含まれているがあることがULPDUは、カプセル化しなければなりません。
MPA over a standard TCP stack can usually provide FPDU Alignment with the TCP Header if the FPDU is equal to TCP's EMSS. An optimized MPA/TCP stack can also maintain alignment as long as the FPDU is less than or equal to TCP's EMSS. Since FPDU Alignment is generally desired by the receiver, DDP cooperates with MPA to ensure FPDUs' lengths do not exceed the EMSS under normal conditions. This is done with the MULPDU mechanism.
FPDUがTCPのエムスと等しい場合は、標準のTCPスタックオーバーMPAは、通常、TCPヘッダでFPDU整列を提供することができます。最適化されたMPA / TCPスタックはまた、長いFPDUがTCPのエムス以下であるように位置合わせを維持することができます。 FPDU整列は、一般的に受信機によって望まれるので、DDPはのFPDUs'の長さは、通常の条件下でエムスを超えないようにMPAと協働します。これはMULPDUメカニズムで行われています。
MPA MUST provide information to DDP on the current maximum size of the record that is acceptable to send (MULPDU). DDP SHOULD limit each record size to MULPDU. The range of MULPDU values MUST be between 128 octets and 64768 octets, inclusive.
MPAは、（MULPDU）を送信することが許容されるレコードの現在の最大サイズにDDPに情報を提供しなければなりません。 DDPはMULPDUに、各レコードのサイズを制限する必要があります。 MULPDU値の範囲は、128オクテットおよび64768オクテットの間で包括的でなければなりません。
The sending DDP MUST NOT post a ULPDU larger than 64768 octets to MPA. DDP MAY post a ULPDU of any size between one and 64768 octets; however, MPA is not REQUIRED to support a ULPDU Length that is greater than the current MULPDU.
送信DDPは、MPAに64768オクテットより大きいULPDUを投稿してはなりません。 DDPは1と64768オクテットの間で任意のサイズのULPDUを投稿すること;しかし、MPAは、現在MULPDUより大きいULPDUの長さをサポートする必要はありません。
While the maximum theoretical length supported by the MPA header ULPDU_Length field is 65535, TCP over IP requires the IP datagram maximum length to be 65535 octets. To enable MPA to support FPDU Alignment, the maximum size of the FPDU must fit within an IP datagram. Thus, the ULPDU limit of 64768 octets was derived by taking the maximum IP datagram length, subtracting from it the maximum total length of the sum of the IPv4 header, TCP header, IPv4 options, TCP options, and the worst-case MPA overhead, and then rounding the result down to a 128-octet boundary.
MPAヘッダULPDU_Lengthフィールドでサポートされている理論上の最大長は65535ですが、IP上のTCPは65535個のオクテットであることをIPデータグラムの最大の長さが必要です。 FPDU整列をサポートするために、MPAを有効にするには、FPDUの最大サイズは、IPデータグラム内に適合しなければなりません。従って、64768オクテットのULPDU限界は、それからIPv4ヘッダ、TCPヘッダ、IPv4オプション、TCPオプション、及びワーストケースMPAオーバーヘッドの和の最大合計長さを減算、最大IPデータグラムの長さを取ることにより得られましたその後、128オクテット境界に結果を切り捨て。
Note that MULPDU will be significantly smaller than the theoretical maximum in most implementations for most circumstances, due to link MTUs, use of extra headers such as required for IPsec, etc.
など、IPsecのために必要に応じて、余分なヘッダの使用、MULPDUは、のMTUをリンクするために起因するほとんどの状況のためのほとんどの実装で理論的な最大よりも大幅に小さくなることに注意してください
On receive, MPA MUST pass each ULPDU with its length to DDP when it has been validated.
それが確認された場合、受信に、MPAは、DDPに、その長さで各ULPDUを通過しなければなりません。
If an MPA implementation supports passing out-of-order ULPDUs to DDP, the MPA implementation SHOULD:
MPA実装はアウトオブオーダーULPDUs DDPに渡してサポートしている場合は、MPA実装する必要があります。
* Pass each ULPDU with its length to DDP as soon as it has been fully received and validated.
*それは完全に受信および検証されているとすぐにDDPにその長さで各ULPDUを渡します。
* Provide a mechanism to indicate the ordering of ULPDUs as the sender transmitted them. One possible mechanism might be providing the TCP sequence number for each ULPDU.
*送信者がそれらを送信するようULPDUsの順序を示すためのメカニズムを提供します。一つの可能なメカニズムは、各ULPDUのためのTCPシーケンス番号を提供することがあります。
* Provide a mechanism to indicate when a given ULPDU (and prior ULPDUs) are complete (Delivered to DDP). One possible mechanism might be to allow DDP to see the current outgoing TCP ACK sequence number.
*とき与えられたULPDU（前ULPDUs）を示すためのメカニズムを提供します（DDPに配信）が完了しています。 1つの可能な機構は、DDPは、現在の発信TCP ACKのシーケンス番号を確認できるようにするかもしれません。
* Provide an indication to DDP that the TCP has closed or has begun to close the connection (e.g., received a FIN).
* TCPが閉じているか（例えば、FINを受信した）接続を閉じ始めていることをDDPに指示を与えます。
MPA MUST provide the protocol version negotiated with its peer to DDP. DDP will use this version to set the version in its header and to report the version to [RDMAP].
MPAは、DDPのピアと交渉プロトコル・バージョンを提供しなければなりません。 DDPは、そのヘッダ内のバージョンを設定し、[RDMAP]のバージョンを報告するために、このバージョンを使います。
The following sections describe the main semantics of the Full Operation Phase of MPA.
次のセクションでは、MPAの完全運用フェーズの主な意味を説明します。
MPA senders create FPDUs out of ULPDUs. The format of an FPDU shown below MUST be used for all MPA FPDUs. For purposes of clarity, Markers are not shown in Figure 2.
MPAの送信者は、ULPDUsの外のFPDUsを作成します。以下に示すFPDUの形式は、すべてのMPAのFPDUsのために使用されなければなりません。明確にするために、マーカーは、図2に示されていません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULPDU_Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
~ ULPDU ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PAD (0-3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FPDU Format
図2：FPDUのフォーマット
ULPDU_Length: 16 bits (unsigned integer). This is the number of octets of the contained ULPDU. It does not include the length of the FPDU header itself, the pad, the CRC, or of any Markers that fall within the ULPDU. The 16-bit ULPDU Length field is large enough to support the largest IP datagrams for IPv4 or IPv6.
ULPDU_Length：16ビット（符号なし整数）。これは、含まれているULPDUのオクテットの数です。これは、FPDUヘッダーの長さ自体、パッド、CRC、またはULPDU内に入る任意のマーカーを含んでいません。 16ビットのULPDU Lengthフィールドは、IPv4またはIPv6のための最大のIPデータグラムをサポートするのに十分な大きさです。
PAD: The PAD field trails the ULPDU and contains between 0 and 3 octets of data. The pad data MUST be set to zero by the sender and ignored by the receiver (except for CRC checking). The length of the pad is set so as to make the size of the FPDU an integral multiple of four.
パッド：パッドフィールドはULPDUを歩道やデータの0〜3オクテットが含まれています。パッドデータは、送信者によってゼロに設定され、（CRCチェックを除く）受信機で無視しなければなりません。 FPDUのサイズ4の整数倍になるようにパッドの長さが設定されています。
CRC: 32 bits. When CRCs are enabled, this field contains a CRC32c check value, which is used to verify the entire contents of the FPDU, using CRC32c. See Section 4.4, CRC Calculation. When CRCs are not enabled, this field is still present, may contain any value, and MUST NOT be checked.
CRC：32ビット。 CRCのが有効になっている場合は、このフィールドはCRC32Cを使用して、FPDUの全体の内容を確認するために使用されCRC32Cチェック値を、含まれています。 4.4節、CRCの計算を参照してください。 CRCが有効でない場合は、このフィールドはまだ存在して、任意の値を含むことができ、かつチェックされてはなりません。
The FPDU adds a minimum of 6 octets to the length of the ULPDU. In addition, the total length of the FPDU will include the length of any Markers and from 0 to 3 pad octets added to round-up the ULPDU size.
FPDUはULPDUの長さに6つのオクテットの最小値を追加します。加えて、FPDUの全長は、任意のマーカーの長さとラウンドアップULPDUサイズに添加0~3パッドオクテットからを含むであろう。
The format of a Marker MUST be as specified in Figure 3:
マーカーのフォーマットは、図3に指定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | FPDUPTR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Marker Format
図3：マーカーのフォーマット
RESERVED: The Reserved field MUST be set to zero on transmit and ignored on receive (except for CRC calculation).
RESERVED：Reservedフィールドは、送信時にゼロに設定され、（CRC計算を除く）受信時には無視されなければなりません。
FPDUPTR: The FPDU Pointer is a relative pointer, 16 bits long, interpreted as an unsigned integer that indicates the number of octets in the TCP stream from the beginning of the ULPDU Length field to the first octet of the entire Marker. The least significant two bits MUST always be set to zero at the transmitter, and the receivers MUST always treat these as zero for calculations.
FPDUPTR：FPDUポインタULPDU Lengthフィールドの先頭からの全マーカーの最初のオクテットにTCPストリームのオクテットの数を示す符号なし整数として解釈さ16ビット長の相対的なポインタです。最下位2ビットは常に送信機においてゼロに設定しなければなりません、そして受信機は常に計算にはゼロとしてこれらを扱う必要があります。
MPA Markers are used to identify the start of FPDUs when packets are received out of order. This is done by locating the Markers at fixed intervals in the data stream (which is correlated to the TCP sequence number) and using the Marker value to locate the preceding FPDU start.
MPAマーカは、パケットが順序が狂って受信されるのFPDUsの開始を識別するために使用されます。これは、（TCPシーケンス番号に対応付けられている）データストリームに一定間隔でマーカーを配置し、先行FPDU開始を見つけるためにマーカ値を使用することによって行われます。
All MPA Markers are included in the containing FPDU CRC calculation (when both CRCs and Markers are in use).
（大腸がん及びマーカーの両方が使用されている場合）、すべてのMPAマーカを含むFPDU CRC計算に含まれます。
The MPA receiver's ability to locate out-of-order FPDUs and pass the ULPDUs to DDP is implementation dependent. MPA/DDP allows those receivers that are able to deal with out-of-order FPDUs in this way to require the insertion of Markers in the data stream. When the receiver cannot deal with out-of-order FPDUs in this way, it may disable the insertion of Markers at the sender. All MPA senders MUST be able to generate Markers when their use is declared by the opposing receiver (see Section 7.1, Connection Setup).
アウト・オブ・オーダーのFPDUs見つけて、DDPにULPDUsを渡すMPA受信機の能力は実装依存です。 MPA / DDPは、データストリーム中のマーカーの挿入を必要とするように、このようにアウトオブオーダーのFPDUsに対処することができ、それらのレシーバを使用できます。受信機は、このようにアウトオブオーダーのFPDUsに対処できない場合は、送信者のマーカーの挿入を無効にすることができます。その使用は反対側の受信機（7.1節、接続設定を参照）によって宣言されたときにすべてのMPAの送信者は、マーカーを生成できなければなりません。
When Markers are enabled, MPA senders MUST insert a Marker into the data stream at a 512-octet periodic interval in the TCP Sequence Number Space. The Marker contains a 16-bit unsigned integer referred to as the FPDUPTR (FPDU Pointer).
マーカーを有効にすると、MPAの送信者は、TCPシーケンス番号空間における512オクテットの定期的な間隔でデータストリームにマーカーを挿入しなければなりません。マーカーFPDUPTR（FPDUポインタ）と呼ばれる16ビットの符号なし整数を含んでいます。
If the FPDUPTR's value is non-zero, the FPDU Pointer is a 16-bit relative back-pointer. FPDUPTR MUST contain the number of octets in the TCP stream from the beginning of the ULPDU Length field to the first octet of the Marker, unless the Marker falls between FPDUs. Thus, the location of the first octet of the previous FPDU header can be determined by subtracting the value of the given Marker from the current octet-stream sequence number (i.e., TCP sequence number) of the first octet of the Marker. Note that this computation MUST take into account that the TCP sequence number could have wrapped between the Marker and the header.
FPDUPTRの値が非ゼロである場合、FPDUポインタは16ビットの相対的バックポインタです。マーカーはのFPDUsの間にある場合を除きFPDUPTRは、ULPDU Lengthフィールドの先頭からマーカーの最初のオクテットにTCPストリームのオクテットの数を含まなければなりません。したがって、前FPDUヘッダーの最初のオクテットの位置は、マーカーの最初のオクテットの現在のオクテットストリーム・シーケンス番号（すなわち、TCPシーケンス番号）から所定のマーカーの値を減算することによって決定することができます。この計算は、TCPシーケンス番号がマーカーとヘッダの間で包まれている可能性を考慮に入れなければならないことに注意してください。
An FPDUPTR value of 0x0000 is a special case -- it is used when the Marker falls exactly between FPDUs (between the preceding FPDU CRC field and the next FPDU's ULPDU Length field). In this case, the Marker is considered to be contained in the following FPDU; the Marker MUST be included in the CRC calculation of the FPDU following the Marker (if CRCs are being generated or checked). Thus, an FPDUPTR value of 0x0000 means that immediately following the Marker is an FPDU header (the ULPDU Length field).
0000のFPDUPTR値は特殊なケースである - マーカーは、（前のFPDU CRCフィールドと次FPDUのULPDU Lengthフィールド間）のFPDUsの間に正確に収まる場合に使用されます。この場合には、マーカーは、以下のFPDUに含まれると考えられます。 （CRCが生成または確認されている場合）マーカーは、マーカー以下FPDUのCRC計算に含まれなければなりません。従って、0000のFPDUPTR値が直ちにマーカーを以下はFPDUヘッダー（ULPDU Lengthフィールド）であることを意味します。
Since all FPDUs are integral multiples of 4 octets, the bottom two bits of the FPDUPTR as calculated by the sender are zero. MPA reserves these bits so they MUST be treated as zero for computation at the receiver.
すべてのFPDUsが4つのオクテットの整数倍であるので、送信者によって計算さFPDUPTRの下2ビットはゼロです。 MPAは、それらが受信機での計算にはゼロとして処理しなければならないので、これらのビットを予約します。
When Markers are enabled (see Section 7.1, Connection Setup), the MPA Markers MUST be inserted immediately preceding the first FPDU of Full Operation Phase, and at every 512th octet of the TCP octet stream thereafter. As a result, the first Marker has an FPDUPTR value of 0x0000. If the first Marker begins at octet sequence number SeqStart, then Markers are inserted such that the first octet of the Marker is at octet sequence number SeqNum if the remainder of (SeqNum - SeqStart) mod 512 is zero. Note that SeqNum can wrap.
マーカーは、（セクション7.1、接続設定を参照）が有効になっている場合は、MPAマーカーはすぐに全運用フェーズの最初のFPDUの前に挿入され、その後、TCPオクテットストリームのすべての512番目のオクテットでなければなりません。その結果、第1のマーカー0000のFPDUPTR値を有します。 512 MOD - （SeqStart SEQNUM）がゼロである第一のマーカーは、オクテットシーケンス番号SeqStartで始まる場合、マーカーは、残りがあればマーカの最初のオクテットはオクテットシーケンス番号SEQNUMになるように挿入されています。 SEQNUMを包むことに注意してください。
For example, if the TCP sequence number were used to calculate the insertion point of the Marker, the starting TCP sequence number is unlikely to be zero, and 512-octet multiples are unlikely to fall on a modulo 512 of zero. If the MPA connection is started at TCP sequence number 11, then the 1st Marker will begin at 11, and subsequent Markers will begin at 523, 1035, etc.
TCPシーケンス番号がマーカーの挿入ポイントを計算するために使用された場合、例えば、出発TCPシーケンス番号がゼロである可能性が低い、512オクテットの倍数はモジュロゼロの512上に落下しそうにありません。 MPA接続がTCPシーケンス番号11で開始された場合、第一マーカーは11で開始され、その後のマーカーは523、1035、などで開始されます
If an FPDU is large enough to contain multiple Markers, they MUST all point to the same point in the TCP stream: the first octet of the ULPDU Length field for the FPDU.
FPDUのためのULPDUの長さフィールドの最初のオクテット：FPDUが複数のマーカーを含むのに十分な大きさである場合、それらはTCPストリーム内の同じポイントにすべて指している必要があります。
If a Marker interval contains multiple FPDUs (the FPDUs are small), the Marker MUST point to the start of the ULPDU Length field for the FPDU containing the Marker unless the Marker falls between FPDUs, in which case the Marker MUST be zero.
マーカー間隔（のFPDUsが小さい）複数のFPDUsを含む場合マーカーはマーカーはゼロでなければならない場合のFPDUs、間にある場合を除き、マーカーは、マーカーを含むFPDUためULPDU長フィールドの開始を指していなければなりません。
The following example shows an FPDU containing a Marker.
次の例では、マーカーを含むFPDUを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULPDU Length (0x0010) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| ULPDU (octets 0-9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (0x0000) | FPDU ptr (0x000C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ULPDU (octets 10-15) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PAD (2 octets:0,0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example FPDU Format with Marker
図4：マーカーを持つ例FPDUのフォーマット
MPA Receivers MUST preserve ULPDU boundaries when passing data to DDP. MPA Receivers MUST pass the ULPDU data and the ULPDU Length to DDP and not the Markers, headers, and CRC.
DDPにデータを渡すときMPAレシーバはULPDU境界を保存しなければなりません。 MPA受信機はULPDUデータとDDPにULPDUの長さとしないマーカー、ヘッダ、及びCRCに合格しなければなりません。
An MPA implementation MUST implement CRC support and MUST either:
MPA実装は、CRCのサポートとMUSTのいずれかを実装する必要があります。
(1) always use CRCs; the MPA provider is not REQUIRED to support an administrator's request that CRCs not be used.
（1）常にCRCを使用します。 MPAプロバイダは、CRCが使用できない管理者の要求をサポートする必要はありません。
or
または
(2a) only indicate a preference not to use CRCs on the explicit request of the system administrator, via an interface not defined in this spec. The default configuration for a connection MUST be to use CRCs.
（2A）のみ、この仕様で定義されていないインタフェースを介して、システム管理者の明示的な要求にCRCを使用しない嗜好を示しています。接続のデフォルト設定は、CRCを使用することでなければなりません。
(2b) disable CRC checking (and possibly generation) if both the local and remote endpoints indicate preference not to use CRCs.
（2b）は、ローカルとリモートの両方のエンドポイントがCRCを使用しない好みを示す場合、CRCチェック（そしておそらく世代）無効。
An administrative decision to have a host request CRC suppression SHOULD NOT be made unless there is assurance that the TCP connection involved provides protection from undetected errors that is at least as strong as an end-to-end CRC32c. End-to-end usage of an IPsec cryptographic integrity check is among the ways to provide such protection, and the use of channel bindings [NFSv4CHANNEL] by the ULP can provide a high level of assurance that the IPsec protection scope is end-to-end with respect to the ULP.
関連するTCP接続は、エンドツーエンドのCRC32Cと少なくとも同じ強さの未検出エラーからの保護を提供することを保証がない限り、ホスト要求CRC抑制を持って行政決定がなされるべきではありません。 IPsecの暗号化、整合性チェックのエンドツーエンドの使用は、そのような保護を提供する方法の中で、ULPによるチャネルバインディングの使用[NFSv4CHANNEL]は、IPsec保護範囲は、エンドツーであるという保証の高いレベルを提供することができますULPに関して終わります。
The process MUST be invisible to the ULP.
プロセスはULPには見えなければなりません。
After receipt of an MPA startup declaration indicating that its peer requires CRCs, an MPA instance MUST continue generating and checking CRCs until the connection terminates. If an MPA instance has declared that it does not require CRCs, it MUST turn off CRC checking immediately after receipt of an MPA mode declaration indicating that its peer also does not require CRCs. It MAY continue generating CRCs. See Section 7.1, Connection Setup, for details on the MPA startup.
接続が終了するまで、そのピアがCRCを必要とすることを示すMPA始動宣言を受信した後、MPAインスタンスが生成および検査CRCを継続しなければなりません。 MPAのインスタンスは、それがCRCを必要としないことを宣言した場合、それはそのピアにもCRCを必要としないことを示すMPAモード宣言の受領直後にCRCチェックをオフにする必要があります。これは、CRCを生成し続けることができます。 MPAの起動の詳細については、セクション7.1、接続設定を参照してください。
When sending an FPDU, the sender MUST include a CRC field. When CRCs are enabled, the CRC field in the MPA FPDU MUST be computed using the CRC32c polynomial in the manner described in the iSCSI Protocol [iSCSI] document for Header and Data Digests.
FPDUを送信する場合、送信側は、CRCフィールドを含まなければなりません。 CRCが有効になっている場合、MPA FPDUのCRCフィールドは、ヘッダとデータダイジェストのiSCSIプロトコル[iSCSIの】文書に記載された方法でCRC32C多項式を用いて計算されなければなりません。
The fields which MUST be included in the CRC calculation when sending an FPDU are as follows:
次のようにFPDUを送信するときにCRC計算に含まれなければならないフィールドは、以下のとおりです。
1) If a Marker does not immediately precede the ULPDU Length field, the CRC-32c is calculated from the first octet of the ULPDU Length field, through all the ULPDU and Markers (if present), to the last octet of the PAD (if present), inclusive. If there is a Marker immediately following the PAD, the Marker is included in the CRC calculation for this FPDU.
マーカーは直ちにULPDU Lengthフィールドに先行しない場合1）、CRC-32cはULPDU長フィールドの最初のオクテットから、すべてのULPDU及びマーカー（存在する場合）を介して、IF（PADの最後のオクテットに計算されます存在）、包括的。マーカーは、PADの直後に存在する場合、マーカーは、このFPDUのためのCRC計算に含まれています。
2) If a Marker immediately precedes the first octet of the ULPDU Length field of the FPDU, (i.e., the Marker fell between FPDUs, and thus is required to be included in the second FPDU), the CRC-32c is calculated from the first octet of the Marker, through the ULPDU Length header, through all the ULPDU and Markers (if present), to the last octet of the PAD (if present), inclusive.
マーカーは直ちにFPDUのULPDU Lengthフィールド（すなわち、マーカのFPDUsの間に落ちたので、第二FPDUに含まれることが必要とされる）の最初のオクテットに先行する場合は2）、CRC-32cは最初から計算されますマーカーのオクテット、ULPDU長ヘッダを介して、すべてのULPDU及びマーカー（存在する場合）、PADの最後のオクテット（存在する場合）に、包括スルー。
3) After calculating the CRC-32c, the resultant value is placed into the CRC field at the end of the FPDU.
3）CRC-32Cを計算した後、得られた値はFPDUの末尾にCRCフィールドに置かれます。
When an FPDU is received, and CRC checking is enabled, the receiver MUST first perform the following:
FPDUが受信され、かつCRCチェックが有効になっている場合、受信機は最初に以下を実行する必要があります。
1) Calculate the CRC of the incoming FPDU in the same fashion as defined above.
上記で定義した1）と同じ方法で、着信FPDUのCRCを計算します。
2) Verify that the calculated CRC-32c value is the same as the received CRC-32c value found in the FPDU CRC field. If not, the receiver MUST treat the FPDU as an invalid FPDU.
2）計算されたCRC-32C値はFPDU CRCフィールドに見つかった受信CRC-32C値と同じであることを確認します。そうでない場合、受信機は無効FPDUとしてFPDUを扱わなければなりません。
The procedure for handling invalid FPDUs is covered in Section 8, Error Semantics.
無効のFPDUsを処理するための手順は、エラーの意味、セクション8に覆われています。
The following is an annotated hex dump of an example FPDU sent as the first FPDU on the stream. As such, it starts with a Marker. The FPDU contains a 42 octet ULPDU (an example DDP segment) which in turn contains 24 octets of the contained ULPDU, which is a data load that is all zeros. The CRC32c has been correctly calculated and can be used as a reference. See the [DDP] and [RDMAP] specification for definitions of the DDP Control field, Queue, MSN, MO, and Send Data.
以下は、ストリームの最初のFPDUとして送信例示FPDUの注釈付き六角ダンプです。このように、それはマーカーで始まります。 FPDUは、今度はすべてゼロであるデータロードで含まULPDUの24個のオクテットを含んでいる42オクテットULPDU（例えばDDPセグメント）を含みます。 CRC32Cが正しく計算されており、リファレンスとして使用することができます。 DDP制御フィールド、キュー、MSN、MOの定義については、[DDP]と[RDMAP]仕様を参照してください、そしてデータを送信します。
Octet Contents Annotation
Count
0000 00 Marker: Reserved 0001 00 0002 00 Marker: FPDUPTR 0003 00 0004 00 ULPDU Length 0005 2a 0006 41 DDP Control Field, Send with Last flag set 0007 43 0008 00 Reserved (DDP STag position with no STag) 0009 00 000a 00 000b 00 000c 00 DDP Queue = 0 000d 00 000e 00 000f 00 0010 00 DDP MSN = 1 0011 00 0012 00 0013 01 0014 00 DDP MO = 0 0015 00 0016 00 0017 00 0018 00 DDP Send Data (24 octets of zeros) ... 002f 00 0030 52 CRC32c 0031 23 0032 99 0033 83
0000 00マーカー：予約0001 00 0002 00マーカー：FPDUPTR 0003 00 0004 00 ULPDU長0005図2a 0006 41 DDP制御フィールド、最終フラグセット0007 43 0008 00リザーブ（NOのSTagとDDPスタッグ位置）で送信0009 00 000A 00 000B 00 000C 00 DDPキュー= 0 000D 00 000E 00 000F 00 0010 00 DDP MSN = 1 0011 00 0012 00 0013 01 0014 00 DDP MO = 0 0015 00 0016 00 0017 00 0018 00 DDPは、データ（ゼロの24オクテット）を送ります... 002F 00 0030 52 CRC32C 0031 23 0032 99 0033 83
Figure 5: Annotated Hex Dump of an FPDU
図5：FPDUの注釈付きHEXダンプ
The following is an example sent as the second FPDU of the stream where the first FPDU (which is not shown here) had a length of 492 octets and was also a Send to Queue 0 with Last Flag set. This example contains a Marker.
以下は、（ここでは示されていない）最初のFPDUが492オクテットの長さを有し、また、最終フラグが設定された0のキューに送信たストリームの第二FPDUとして送信例です。この例では、マーカーが含まれています。
Octet Contents Annotation Count
オクテット内容注釈カウント
01ec 00 Length 01ed 2a 01ee 41 DDP Control Field: Send with Last Flag set 01ef 43 01f0 00 Reserved (DDP STag position with no STag) 01f1 00 01f2 00 01f3 00 01f4 00 DDP Queue = 0 01f5 00 01f6 00 01f7 00 01f8 00 DDP MSN = 2 01f9 00 01fa 00 01fb 02 01fc 00 DDP MO = 0 01fd 00 01fe 00 01ff 00 0200 00 Marker: Reserved 0201 00 0202 00 Marker: FPDUPTR 0203 14 0204 00 DDP Send Data (24 octets of zeros) ... 021b 00 021c 84 CRC32c 021d 92 021e 58 021f 98
01ec 00長01ed 2aは01ee 41 DDP制御フィールド：43 01f0 00リザーブ（NOのSTagとDDPスタッグ位置）01f1 00 01f2 00 01f3 00 01f4 00 DDPキュー= 0 01f5 00 01f6 00 01f7 00 01f8 00 DDP 01ef設定最終フラグで送信MSN = 2 01f9 00 01fa 00 01fb 02 01fc 00 DDP MO = 0 01fd 00 01fe 00 01FF 00 0200 00マーカー：予約0201 00 0202 00マーカー：FPDUPTR 0203 14 0204 00 DDPデータを送信する（ゼロの24オクテット）... 021b 00 021C 84 CRC32C 021d 92 021e 58 021f 98
Figure 6: Annotated Hex Dump of an FPDU with Marker
図6：マーカーでFPDUの注釈付き六角ダンプ
MPA defines the Maximum Upper Layer Protocol Data Unit (MULPDU) as the size of the largest ULPDU fitting in an FPDU. For an empty TCP Segment, MULPDU is EMSS minus the FPDU overhead (6 octets) minus space for Markers and pad octets.
MPAはFPDU最大のULPDU継手の大きさとして最大上位層プロトコルデータユニット（MULPDU）を定義します。空のTCPセグメントに対して、MULPDUマーカーとパッドオクテット用エムスマイナスFPDUオーバーヘッド（6つのオクテット）マイナスの空間です。
The maximum ULPDU Length for a single ULPDU when Markers are
present MUST be computed as:
MULPDU = EMSS - (6 + 4 * Ceiling(EMSS / 512) + EMSS mod 4)
MULPDU =エムス - （6 + 4 *天井（エムス/ 512）+エムスMOD 4）
The formula above accounts for the worst-case number of Markers.
式は、上記マーカーの最悪の場合の数を占めます。
The maximum ULPDU Length for a single ULPDU when Markers are NOT
present MUST be computed as:
MULPDU = EMSS - (6 + EMSS mod 4)
MULPDU =エムス - （6 +エムスMOD 4）
As a further optimization of the wire efficiency an MPA implementation MAY dynamically adjust the MULPDU (see Section 5 for latency and wire efficiency trade-offs). When one or more FPDUs are already packed into a TCP Segment, MULPDU MAY be reduced accordingly.
ワイヤ効率の更なる最適化としてMPA実装は動的MULPDU（待ち時間とワイヤ効率のトレードオフについては、セクション5を参照）を調整してもよいです。一の以上のFPDUsがすでにTCPセグメントに詰め込まれている場合、MULPDUはそれに応じて減少させることができます。
DDP SHOULD provide ULPDUs that are as large as possible, but less than or equal to MULPDU.
DDPは、できるだけ大きいULPDUsを提供するが、以下MULPDUに等しくなければなりません。
If the TCP implementation needs to adjust EMSS to support MTU changes or changing TCP options, the MULPDU value is changed accordingly.
TCP実装はMTUの変更または変更するTCPオプションをサポートするために、エムスを調整する必要がある場合、MULPDU値はそれに応じて変更されます。
In certain rare situations, the EMSS may shrink below 128 octets in size. If this occurs, the MPA on TCP sender MUST NOT shrink the MULPDU below 128 octets and is not required to follow the segmentation rules in Section 5.1 and Appendix A.
特定のまれな状況では、エムスは、サイズが128オクテット未満に縮小することができます。この問題が発生した場合、MPA TCPの送信側が128オクテットの下MULPDUを縮小してはならないし、セクション5.1および付録Aにセグメンテーション規則に従う必要はありません
If one or more FPDUs are already packed into a TCP segment, such that the remaining room is less than 128 octets, MPA MUST NOT provide a MULPDU smaller than 128. In this case, MPA would typically provide a MULPDU for the next full sized segment, but may still pack the next FPDU into the small remaining room, provide that the next FPDU is small enough to fit.
一の以上のFPDUsが既にTCPセグメントに詰め込まれている場合、残りの部屋はMPAは、この場合MULPDU未満128を提供してはいけません未満128オクテットようなものであること、MPAは、典型的には、次のフルサイズのセグメントにMULPDUを提供しますが、それでも次のFPDUが収まるほど小さいことを提供し、小さな残りの部屋に次のFPDUを詰めることがあります。
The value 128 is chosen as to allow DDP designers room for the DDP Header and some user data.
値128は、DDPヘッダといくつかのユーザデータのDDPデザイナールームを可能にするように選択されます。
The following sections describe MPA's interactions with TCP. This section discusses using a standard layered TCP stack with MPA attached above a TCP socket. Discussion of using an optimized MPA-aware TCP with an MPA implementation that takes advantage of the extra optimizations is done in Appendix A.
次のセクションでは、TCPとのMPAの相互作用を記述する。このセクションでは、TCPソケット上に取り付けられたMPAと標準層状TCPスタックを使用して説明します。余分な最適化機能を活用してMPAの実装に最適化されたMPA-意識TCPを使用しての議論は、付録Aで行われます
+-----------------------------------+
| +-----+ +-----------------+ |
| | MPA | | Other Protocols | |
| +-----+ +-----------------+ |
| || || |
| ----- socket API -------------- |
| || |
| +-----+ |
| | TCP | |
| +-----+ |
| || |
| +-----+ |
| | IP | |
| +-----+ |
+-----------------------------------+
Figure 7: Fully Layered Implementation
図7：完全に階層化実装
The Fully layered implementation is described for completeness; however, the user is cautioned that the reduced probability of FPDU alignment when transmitting with this implementation will tend to introduce a higher overhead at optimized receivers. In addition, the lack of out-of-order receive processing will significantly reduce the value of DDP/MPA by imposing higher buffering and copying overhead in the local receiver.
完全に積層実装は、完全性のために記載されています。しかし、ユーザは、この実装で送信FPDU整列の低下確率が最適化された受信機でより高いオーバーヘッドを導入する傾向があることが警告されます。また、アウト・オブ・オーダの受信処理の不足が顕著にローカル受信機でより高い緩衝コピーのオーバーヘッドを課すことによってDDP / MPAの値を減少させます。
MPA transmitters SHOULD calculate a MULPDU as described in Section 4.5. If the TCP implementation allows EMSS to be determined by MPA, that value should be used. If the transmit side TCP implementation is not able to report the EMSS, MPA SHOULD use the current MTU value to establish a likely FPDU size, taking into account the various expected header sizes.
4.5節で説明したようにMPA送信機はMULPDUを計算する必要があります。 TCP実装はエムスをMPAによって決定されることを可能にする場合は、その値を使用する必要があります。送信側TCP実装はエムスを報告することができない場合には、MPAは考慮に入れ、様々な予想されるヘッダのサイズを取って、おそらくFPDUサイズを確立するために、現在のMTU値を使用する必要があります。
MPA transmitters SHOULD also use whatever facilities the TCP stack presents to cause the TCP transmitter to start TCP segments at FPDU boundaries. Multiple FPDUs MAY be packed into a single TCP segment as determined by the EMSS calculation as long as they are entirely contained in the TCP segment.
MPA送信機はまた、TCPスタックがFPDU境界でTCPセグメントを開始するには、TCPの送信を引き起こすために提示どんな施設使用すべきです。複数のFPDUsであれば、それらが完全にTCPセグメントに含まれるようにエムス計算によって決定されるように単一のTCPセグメントに詰め込まれるかもしれません。
For example, passing FPDU buffers sized to the current EMSS to the TCP socket and using the TCP_NODELAY socket option to disable the Nagle [RFC896] algorithm will usually result in many of the segments starting with an FPDU.
例えば、通過FPDUバッファはTCPソケットへの電流エムスに大きさと通常FPDU始まるセグメントの多くをもたらすネーグル[RFC896]アルゴリズムを無効にするTCP_NODELAYソケットオプションを使用して。
It is recognized that various effects can cause an FPDU Alignment to be lost. Following are a few of the effects:
様々な効果がFPDU整列が失われる可能性がありますことを認識されています。効果のいくつかは次のとおりです。
* ULPDUs that are smaller than the MULPDU. If these are sent in a continuous stream, FPDU Alignment will be lost. Note that careful use of a dynamic MULPDU can help in this case; the MULPDU for future FPDUs can be adjusted to re-establish alignment with the segments based on the current EMSS.
* MULPDUよりも小さいULPDUs。これらは連続ストリームで送信された場合は、FPDU整列が失われます。ダイナミックMULPDUの慎重な使用は、この場合には助けることができることに注意してください。 MULPDU将来のFPDUsの現在エムスに基づいてセグメントを有する再確立位置合わせするように調整することができます。
* Sending enough data that the TCP receive window limit is reached. TCP may send a smaller segment to exactly fill the receive window.
* TCPはウィンドウの上限に達したことを受け、十分なデータを送信します。 TCPは正確に受信ウィンドウを埋めるために小さなセグメントを送信することができます。
* Sending data when TCP is operating up against the congestion window. If TCP is not tracking the congestion window in segments, it may transmit a smaller segment to exactly fill the receive window.
* TCPは輻輳ウィンドウに対して、最大動作しているときにデータを送信します。 TCPは、セグメントの輻輳ウィンドウを追跡していない場合、それは正確に受信ウィンドウを埋めるために小さなセグメントを送信することができます。
* Changes in EMSS due to varying TCP options, or changes in MTU.
*による様々なTCPオプションにエムスの変更、またはMTUの変更。
If FPDU Alignment with TCP segments is lost for any reason, the alignment is regained after a break in transmission where the TCP send buffers are emptied. Many usage models for DDP/MPA will include such breaks.
TCPセグメントとFPDU整列が何らかの理由で失われた場合、アライメントはTCPはバッファが空にされている送信、送信の中断後に回復しています。 DDP / MPAのための多くの使用モデルは、このような休憩が含まれます。
MPA receivers are REQUIRED to be able to operate correctly even if alignment is lost (see Section 6).
MPA受信機が正しく整列が失われた場合でも動作することが可能であることが要求されている（第6節を参照してください）。
MPA receivers will get TCP data in the usual ordered stream. The receivers MUST identify FPDU boundaries by using the ULPDU_LENGTH field, as described in Section 6. Receivers MAY utilize markers to check for FPDU boundary consistency, but they are NOT required to examine the markers to determine the FPDU boundaries.
MPA受信機は、通常注文の流れでTCPデータを取得します。受信機は、セクションで説明したように6レシーバはFPDU境界の整合性をチェックするためのマーカーを利用することができるが、それらはFPDU境界を決定するためのマーカーを検討する必要はありませんが、ULPDU_LENGTHフィールドを使って、FPDU境界を特定しなければなりません。
An MPA receiver MUST first verify the FPDU before passing the ULPDU to DDP. To do this, the receiver MUST:
MPA受信機は、最初のDDPにULPDUを渡す前に、FPDUを確かめなければなりません。これを行うには、受信する必要があります。
* locate the start of the FPDU unambiguously,
*明確FPDUの開始を見つけ、
* verify its CRC (if CRC checking is enabled).
*（CRCチェックが有効になっている場合）、そのCRCを確認します。
If the above conditions are true, the MPA receiver passes the ULPDU to DDP.
上記の条件に該当する場合、MPA受信機は、DDPにULPDUを渡します。
To detect the start of the FPDU unambiguously one of the following MUST be used:
明確FPDUの開始を検出するには、次のいずれかを使用しなければなりません。
1: In an ordered TCP stream, the ULPDU Length field in the current FPDU when FPDU has a valid CRC, can be used to identify the beginning of the next FPDU.
1：FPDUが有効なCRCを持っているとき命じたTCPストリーム、ULPDU Lengthフィールドには、現在のFPDUでは、次のFPDUの始まりを識別するために使用することができます。
2: For optimized MPA/TCP receivers that support out-of-order reception of FPDUs (see Section 4.3, MPA Markers) a Marker can always be used to locate the beginning of an FPDU (in FPDUs with valid CRCs). Since the location of the Marker is known in the octet stream (sequence number space), the Marker can always be found.
2：最適化されたMPA / TCPのためのFPDUsのアウトオブオーダー受付（4.3節、MPAマーカーを参照）マーカーをサポートする受信機は、常に（有効なCRCを持つのFPDUs中）FPDUの始まりを見つけるために使用することができます。マーカーの位置をオクテットストリーム（シーケンス番号空間）で知られているので、マーカーは常に見つけることができます。
3: Having found an FPDU by means of a Marker, an optimized MPA/TCP receiver can find following contiguous FPDUs by using the ULPDU Length fields (from FPDUs with valid CRCs) to establish the next FPDU boundary.
3：は、最適化されたMPA / TCP受信機は次のFPDU境界を確立する（有効なCRCを持つのFPDUsから）ULPDUの長さフィールドを使用して、連続したのFPDUs次見つけることができるマーカーの手段によってFPDUを発見しました。
The ULPDU Length field (see Section 4) MUST be used to determine if the entire FPDU is present before forwarding the ULPDU to DDP.
ULPDU Lengthフィールド（セクション4を参照）全体FPDUをDDPにULPDUを転送する前に存在しているかどうかを決定するために使用されなければなりません。
CRC calculation is discussed in Section 4.4 above.
CRC計算は、上記のセクション4.4で説明されています。
MPA requires that the Consumer MUST activate MPA, and any TCP enhancements for MPA, on a TCP half connection at the same location in the octet stream at both the sender and the receiver. This is required in order for the Marker scheme to correctly locate the Markers (if enabled) and to correctly locate the first FPDU.
MPAは、消費者が送信者と受信者の両方でのオクテットストリームの同じ場所でのTCPの半分の接続で、MPAのためにMPA、および任意のTCPの拡張機能を有効にする必要がありする必要があります。これは、マーカー方式は（有効な場合）が正しくマーカーを見つけるために、正しく最初のFPDUを検索するために必要です。
MPA, and any TCP enhancements for MPA are enabled by the ULP in both directions at once at an endpoint.
MPA、およびMPAのための任意のTCPの拡張機能は、エンドポイントで一度に両方の方向にULPで有効になっています。
This can be accomplished several ways, and is left up to DDP's ULP:
これにはいくつかの方法を達成することができ、DDPのULPに任されています。
* DDP's ULP MAY require DDP on MPA startup immediately after TCP connection setup. This has the advantage that no streaming mode negotiation is needed. An example of such a protocol is shown in Figure 10: Example Immediate Startup negotiation.
* DDPのULPは、すぐにTCP接続設定後MPAの起動時にDDPが必要な場合があります。これは何のストリーミングモードのネゴシエーションを必要としない利点があります。例即時起動ネゴシエーション：そのようなプロトコルの例が図10に示されています。
This may be accomplished by using a well-known port, or a service
locator protocol to locate an appropriate port on which DDP on
MPA is expected to operate.
* DDP's ULP MAY negotiate the start of DDP on MPA sometime after a normal TCP startup, using TCP streaming data exchanges on the same connection. The exchange establishes that DDP on MPA (as well as other ULPs) will be used, and exactly locates the point in the octet stream where MPA is to begin operation. Note that such a negotiation protocol is outside the scope of this specification. A simplified example of such a protocol is shown in Figure 9: Example Delayed Startup negotiation on page 33.
* DDPのULPは、同じ接続上でTCPストリーミングデータ交換を使用して、いつか、通常のTCPの起動後、MPAにDDPの開始を交渉することができます。交換は、MPAにDDP（ならびに他のULP）が使用されることを確立し、正確MPAが動作を開始するオクテットストリーム内の点の位置を特定します。このような交渉プロトコルは、本明細書の範囲外であることに留意されたいです。そのようなプロトコルの単純化した例を図9に示されている実施例は、33ページのスタートアップネゴシエーションを遅延しました。
An MPA endpoint operates in two distinct phases.
MPAのエンドポイントは、2つの異なる相で動作します。
The Startup Phase is used to verify correct MPA setup, exchange CRC and Marker configuration, and optionally pass Private Data between endpoints prior to completing a DDP connection. During this phase, specifically formatted frames are exchanged as TCP byte streams without using CRCs or Markers. During this phase a DDP endpoint need not be "bound" to the MPA connection. In fact, the choice of DDP endpoint and its operating parameters may not be known until the Consumer supplied Private Data (if any) has been examined by the Consumer.
スタートアップフェーズは、DDPの接続を完了する前にエンドポイント間のプライベートデータを補正MPAセットアップ、交換CRCマーカーの設定を確認し、必要に応じて渡すために使用されます。このフェーズでは、具体的にフォーマットされたフレームのCRCは、またはマーカーを使用せずにTCPバイトストリームとして交換されます。この段階でDDP終点は、MPA接続に「バウンド」である必要はありません。 （もしあれば）消費者によって検討されている消費者は、プライベートデータを供給するまで実際には、DDP終点とその動作パラメータの選択は知られていない可能性が。
The second distinct phase is Full Operation during which FPDUs are sent using all the rules that pertain (CRCs, Markers, MULPDU restrictions, etc.). A DDP endpoint MUST be "bound" to the MPA connection at entry to this phase.
第二の別個の相をフルオペレーションのFPDUsその間は（大腸がん、マーカー、MULPDU制限など）に関するすべてのルールを使用して送信されます。 DDPエンドポイントは、この段階の入口でMPA接続への「バウンド」でなければなりません。
When Private Data is passed between ULPs in the Startup Phase, the ULP is responsible for interpreting that data, and then placing MPA into Full Operation.
プライベートデータは、スタートアップ段階でのULPの間で渡されると、ULPは、そのデータを解釈して、フルオペレーションにMPAを配置するための責任があります。
Note: The following text differentiates the two endpoints by calling them Initiator and Responder. This is quite arbitrary and is NOT related to the TCP startup (SYN, SYN/ACK sequence). The Initiator is the side that sends first in the MPA startup sequence (the MPA Request Frame).
注意：次のテキストは、イニシエータとレスポンダそれらを呼び出すことにより、2つのエンドポイントを区別します。これは非常に任意であり、TCPの起動（SYN、SYN / ACKシーケンス）に関連していません。イニシエータは、MPAの起動シーケンス（MPA要求フレーム）の最初の送信側です。
Note: The possibility that both endpoints would be allowed to make a connection at the same time, sometimes called an active/active connection, was considered by the work group and rejected. There were several motivations for this decision. One was that applications needing this facility were few (none other than theoretical at the time of this document). Another was that the facility created some implementation difficulties, particularly with the "dual stack" designs described later on. A last issue was that dealing with rejected connections at startup would have required at least an additional frame type, and more recovery actions, complicating the protocol. While none of these issues was overwhelming, the group and implementers were not motivated to do the work to resolve these issues. The protocol includes a method of detecting these active/active startup attempts so that they can be rejected and an error reported.
注：両方のエンドポイントが同時に接続を行うことが許されるという可能性は、時々、アクティブ/アクティブな接続と呼ばれ、作業グループで検討し、拒否されました。この決定のためのいくつかの動機がありました。一つは、この機能を必要とするアプリケーションは、（この文書の時点での理論上の他でもない）少なかったということでした。もう一つは、特に後述する「デュアルスタック」のデザインで、施設は、いくつかの実装の難しさを作成したということでした。最後の問題は、起動時に拒否された接続に対処するプロトコルを複雑に、少なくとも追加のフレームタイプ、およびより多くの回復アクションを必要としていたことでした。これらの問題のどれもが圧倒的だったが、グループや実装は、これらの問題を解決するために仕事をする動機はなかったです。プロトコルは、彼らが拒否することができ、エラーが報告されたように、これらのアクティブ/アクティブ起動の試みを検出する方法を含みます。
The ULP is responsible for determining which side is Initiator or Responder. For client/server type ULPs, this is easy. For peer-peer ULPs (which might utilize a TCP style active/active startup), some mechanism (not defined by this specification) must be established, or some streaming mode data exchanged prior to MPA startup to determine which side starts in Initiator and which starts in Responder MPA mode.
ULPは、イニシエータまたはレスポンダである側面を決定する責任があります。クライアント/サーバ型のULPの場合、これは簡単です。 （TCPスタイルアクティブ/アクティブ起動を利用するかもしれない）ピアツーピアのULPのために、（この仕様で定義されていない）、いくつかのメカニズムが確立されなければならない、またはいくつかのストリーミングモードデータがイニシエータで開始する側決定する前MPA始動に交換しましたレスポンダMPAモードで起動します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Res | Rev | PD_Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Private Data ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPA Request/Reply Frame
図8：MPA要求/応答フレーム
Key: This field contains the "key" used to validate that the sender is an MPA sender. Initiator mode senders MUST set this field to the fixed value "MPA ID Req Frame" or (in byte order) 4D 50 41 20 49 44 20 52 65 71 20 46 72 61 6D 65 (in hexadecimal). Responder mode receivers MUST check this field for the same value, and close the connection and report an error locally if any other value is detected. Responder mode senders MUST set this field to the fixed value "MPA ID Rep Frame" or (in byte order) 4D 50 41 20 49 44 20 52 65 70 20 46 72 61 6D 65 (in hexadecimal). Initiator mode receivers MUST check this field for the same value, and close the connection and report an error locally if any other value is detected.
キー：このフィールドは、送信者がMPAの送信者であることを検証するために使用される「キー」が含まれています。イニシエータモードの送信者は、固定値 "MPA ID Reqフレーム" または（16進数）（バイト順）4D 50 41 20 49 44 20 52 65 71 20 46 72 61 6D 65にこのフィールドを設定しなければなりません。レスポンダモード受信機は、同じ値のため、このフィールドを確認し、接続を閉じて、他の値が検出された場合、ローカルにエラーを報告しなければなりません。応答モードの送信者は、固定値 "MPA ID担当フレーム" または（16進数）（バイト順）4D 50 41 20 49 44 20 52 65 70 20 46 72 61 6D 65にこのフィールドを設定しなければなりません。イニシエータモード受信機は、同じ値のため、このフィールドを確認し、接続を閉じて、他の値が検出された場合、ローカルにエラーを報告しなければなりません。
M: This bit declares an endpoint's REQUIRED Marker usage. When this bit is '1' in an MPA Request Frame, the Initiator declares that Markers are REQUIRED in FPDUs sent from the Responder. When set to '1' in an MPA Reply Frame, this bit declares that Markers are REQUIRED in FPDUs sent from the Initiator. When in a received MPA Request Frame or MPA Reply Frame and the value is '0', Markers MUST NOT be added to the data stream by that endpoint. When '1' Markers MUST be added as described in Section 4.3, MPA Markers.
M：このビットは、エンドポイントのREQUIREDマーカーの使用を宣言します。このビットは、MPA要求フレームに「1」である場合には、イニシエータは、マーカーは、レスポンダから送信されたのFPDUsで必要とされていることを宣言します。 MPA応答フレームに「1」に設定すると、このビットはマーカーがのFPDUsで必要とされていることを宣言し、イニシエータから送信されます。受信されたMPA要求フレームまたはMPAフレームを返信し、値が「0」である場合、マーカーは、そのエンドポイントによってデータストリームに追加してはいけません。セクション4.3、MPAマーカーで説明したように「1」マーカーを追加する必要があります。
C: This bit declares an endpoint's preferred CRC usage. When this field is '0' in the MPA Request Frame and the MPA Reply Frame, CRCs MUST not be checked and need not be generated by either endpoint. When this bit is '1' in either the MPA Request Frame or MPA Reply Frame, CRCs MUST be generated and checked by both endpoints. Note that even when not in use, the CRC field remains present in the FPDU. When CRCs are not in use, the CRC field MUST be considered valid for FPDU checking regardless of its contents.
C：このビットは、エンドポイントの優先CRCの使用を宣言します。このフィールドは、MPA要求フレームとMPAの応答フレームに「0」である場合には、CRCがチェックされてはならず、いずれかのエンドポイントによって生成される必要がありません。このビットは、MPA要求フレームまたはMPAの応答フレームのいずれかに「1」である場合には、CRCは、両方のエンドポイントによって生成され、チェックしなければなりません。でも、使用しないときは、CRCフィールドはFPDU中に存在し続けることに注意してください。 CRCが使用されていない場合は、CRCフィールドはFPDUは関係なく、その内容のチェックのために有効であると見なされなければなりません。
R: This bit is set to zero, and not checked on reception in the MPA Request Frame. In the MPA Reply Frame, this bit is the Rejected Connection bit, set by the Responders ULP to indicate acceptance '0', or rejection '1', of the connection parameters provided in the Private Data.
R：このビットはゼロに設定され、MPA要求フレームで受信時にチェックされません。 MPAの応答フレームでは、このビットは、受け入れを示すために、レスポンダULPによって設定された拒否接続ビットは、「0」、または拒否「1」、プライベートデータ内に設けられた接続パラメータ。
Res: This field is reserved for future use. It MUST be set to zero when sending, and not checked on reception.
RES：このフィールドは、将来の使用のために予約されています。これは、送信時にゼロに設定し、受信時にチェックされていませんしなければなりません。
Rev: This field contains the revision of MPA. For this version of the specification, senders MUST set this field to one. MPA receivers compliant with this version of the specification MUST check this field. If the MPA receiver cannot interoperate with the received version, then it MUST close the connection and report an error locally. Otherwise, the MPA receiver should report the received version to the ULP.
REV：このフィールドは、MPAの改正を含みます。このバージョンの仕様では、送信者は1つに、このフィールドを設定しなければなりません。このバージョンの仕様に準拠MPA受信機は、このフィールドをチェックしなければなりません。 MPA受信機は、受信したバージョンと相互運用することができないなら、それは接続を閉じなければなりません、そしてローカルにエラーを報告します。それ以外の場合は、MPA受信機はULPに受け取ったバージョンを報告する必要があります。
PD_Length: This field MUST contain the length in octets of the Private Data field. A value of zero indicates that there is no Private Data field present at all. If the receiver detects that the PD_Length field does not match the length of the Private Data field, or if the length of the Private Data field exceeds 512 octets, the receiver MUST close the connection and report an error locally. Otherwise, the MPA receiver should pass the PD_Length value and Private Data to the ULP.
PD_Length：このフィールドは、プライベートデータフィールドのオクテットの長さを含まなければなりません。ゼロの値は、まったくのプライベートデータフィールドが存在することを示しています。受信機はPD_Lengthフィールドはプライベートデータフィールドの長さと一致しないことを検出した場合はプライベートデータフィールドの長さが512個のオクテットを超える場合、または、受信機は接続を閉じ、ローカルにエラーを報告しなければなりません。それ以外の場合は、MPA受信機はULPにPD_Length値およびプライベートデータを渡す必要があります。
Private Data: This field may contain any value defined by ULPs or may not be present. The Private Data field MUST be between 0 and 512 octets in length. ULPs define how to size, set, and validate this field within these limits. Private Data usage is further discussed in Section 7.1.4.
プライベートデータ：このフィールドには、のULPによって定義された任意の値が含まれていてもよいか、存在しないかもしれません。プライベートデータフィールドの長さは0と512オクテットの間でなければなりません。 ULPは、どのようにサイズを定義し、セット、およびこれらの範囲内で、このフィールドを検証します。プライベートデータの使用はさらに、セクション7.1.4で説明されています。
The following rules apply to MPA connection Startup Phase:
次の規則がMPA接続スタートアップフェーズに適用されます。
1. When MPA is started in the Initiator mode, the MPA implementation MUST send a valid MPA Request Frame. The MPA Request Frame MAY include ULP-supplied Private Data.
1. MPAは、イニシエータモードで起動すると、MPAの実装は、有効なMPA要求フレームを送らなければなりません。 MPA要求フレームはULP-供給プライベートデータを含むことができます。
2. When MPA is started in the Responder mode, the MPA implementation MUST wait until an MPA Request Frame is received and validated before entering Full MPA/DDP Operation.
MPAは、レスポンダモードで起動されるとMPA要求フレームを受信し、全MPA / DDP操作に入る前に検証されるまで、2は、MPAの実装が待たなければなりません。
If the MPA Request Frame is improperly formatted, the
implementation MUST close the TCP connection and exit MPA.
If the MPA Request Frame is properly formatted but the Private Data is not acceptable, the implementation SHOULD return an MPA Reply Frame with the Rejected Connection bit set to '1'; the MPA Reply Frame MAY include ULP-supplied Private Data; the implementation MUST exit MPA, leaving the TCP connection open. The ULP may close TCP or use the connection for other purposes.
MPA要求フレームが正しくフォーマットが、プライベートデータが許容可能でない場合、実装は「1」に設定拒否の接続ビットでMPA応答フレームを返すべきです。 MPAの応答フレームは、ULP-供給プライベートデータを含むことができます。実装は、TCPコネクションのオープンを残して、MPAを終了する必要があります。 ULPは、TCPを閉じたり、他の目的のために接続を使用することができます。
If the MPA Request Frame is properly formatted and the Private Data is acceptable, the implementation SHOULD return an MPA Reply Frame with the Rejected Connection bit set to '0'; the MPA Reply
MPA要求フレームが適切にフォーマットされ、プライベートデータが許容されている場合は、実装が「0」に設定され拒否された接続ビットでMPA応答フレームを返すべきです。 MPA返信
Frame MAY include ULP-supplied Private Data; and the Responder SHOULD prepare to interpret any data received as FPDUs and pass any received ULPDUs to DDP.
フレームはULP-供給プライベートデータを含むことができます。そして、レスポンダのFPDUsとして受信したデータを解釈するために準備し、任意に渡す必要がDDPにULPDUsを受けました。
Note: Since the receiver's ability to deal with Markers is unknown until the Request and Reply Frames have been received, sending FPDUs before this occurs is not possible.
注意：マーカーに対処するための受信機の能力が要求されるまで不明であるので、応答フレームは、これは不可能です発生する前のFPDUsを送信し、受信されています。
Note: The requirement to wait on a Request Frame before sending a Reply Frame is a design choice. It makes for a well-ordered sequence of events at each end, and avoids having to specify how to deal with situations where both ends start at the same time.
注意：応答フレームを送信する前に要求フレームを待つための要件は、設計上の選択です。これは、各端でのイベントのほか、順序付けられたシーケンスになり、その両端が同時に開始状況に対処する方法を指定する必要がなくなります。
3. MPA Initiator mode implementations MUST receive and validate an MPA Reply Frame.
3. MPAイニシエータモードの実装はMPAの応答フレームを受信して検証する必要があります。
If the MPA Reply Frame is improperly formatted, the
implementation MUST close the TCP connection and exit MPA.
If the MPA Reply Frame is properly formatted but is the Private Data is not acceptable, or if the Rejected Connection bit is set to '1', the implementation MUST exit MPA, leaving the TCP connection open. The ULP may close TCP or use the connection for other purposes.
MPA応答フレームが適切にフォーマットされるがされている場合はプライベートデータは許容されない、または拒否された接続ビットが「1」に設定されている場合、実装は、TCP接続を開いたままに、MPAを終了する必要があります。 ULPは、TCPを閉じたり、他の目的のために接続を使用することができます。
If the MPA Reply Frame is properly formatted and the Private Data is acceptable, and the Reject Connection bit is set to '0', the implementation SHOULD enter Full MPA/DDP Operation Phase; interpreting any received data as FPDUs and sending DDP ULPDUs as FPDUs.
MPA応答フレームは、適切にフォーマットし、プライベートデータが許容され、かつ拒否接続ビットが「0」に設定され、実装は完全MPA / DDP運用フェーズを入力する必要がありますされている場合は、 FPDUsとして任意の受信データを解釈してのFPDUsとしてDDP ULPDUsを送信します。
4. MPA Responder mode implementations MUST receive and validate at least one FPDU before sending any FPDUs or Markers.
4. MPAレスポンダモードの実装は、任意のFPDUsまたはマーカーを送信する前に、少なくとも1つのFPDUを受信して検証する必要があります。
Note: This requirement is present to allow the Initiator time to
get its receiver into Full Operation before an FPDU arrives,
avoiding potential race conditions at the Initiator. This
was also subject to some debate in the work group before
rough consensus was reached. Eliminating this requirement
would allow faster startup in some types of applications.
However, that would also make certain implementations
(particularly "dual stack") much harder.
5. If a received "Key" does not match the expected value (see Section 7.1.1, MPA Request and Reply Frame Format) the TCP/DDP connection MUST be closed, and an error returned to the ULP.
5.受信した「キー」は（セクション7.1.1、MPA Requestを参照し、フレームフォーマットを返信）期待値と一致しない場合、TCP / DDP接続を閉じなければならない、とエラーがULPに戻りました。
6. The received Private Data fields may be used by Consumers at either end to further validate the connection and set up DDP or other ULP parameters. The Initiator ULP MAY close the TCP/MPA/DDP connection as a result of validating the Private Data fields. The Responder SHOULD return an MPA Reply Frame with the "Reject Connection" bit set to '1' if the validation of the Private Data is not acceptable to the ULP.
前記受信されたプライベートデータフィールドは、さらに、接続を検証するために両端に消費者によって使用され、DDPまたは他のULPパラメータを設定することができます。イニシエータULPは、プライベートデータフィールドを検証した結果、TCP / MPA / DDP接続を閉じます。 Responderはプライベートデータの検証はULPに受け入れられない場合は、「接続拒否」「1」に設定ビットでMPA応答フレームを返すべきです。
7. When the first FPDU is to be sent, then if Markers are enabled, the first octets sent are the special Marker 0x00000000, followed by the start of the FPDU (the FPDU's ULPDU Length field). If Markers are not enabled, the first octets sent are the start of the FPDU (the FPDU's ULPDU Length field).
最初のFPDUが送信されるときに7.、その後、マーカーが有効になっている場合は、送信された最初のオクテットはFPDU（FPDUのULPDU Lengthフィールド）の開始に続いて、特別なマーカー0x00000000のです。マーカーが有効でない場合は、送信された最初のオクテットはFPDU（FPDUのULPDU Lengthフィールド）の開始です。
8. MPA implementations MUST use the difference between the MPA Request Frame and the MPA Reply Frame to check for incorrect "Initiator/Initiator" startups. Implementations SHOULD put a timeout on waiting for the MPA Request Frame when started in Responder mode, to detect incorrect "Responder/Responder" startups.
8. MPA実装は間違って「イニシエータ/イニシエータ」スタートアップをチェックするためにMPA要求フレームとMPA応答フレーム間の差を使用しなければなりません。実装は正しくない「レスポンダ/レスポンダ」スタートアップを検出するために、レスポンダモードで起動したときにMPA要求フレームを待っているにタイムアウトを置くべきです。
9. MPA implementations MUST validate the PD_Length field. The buffer that receives the Private Data field MUST be large enough to receive that data; the amount of Private Data MUST not exceed the PD_Length or the application buffer. If any of the above fails, the startup frame MUST be considered improperly formatted.
9. MPA実装はPD_Lengthフィールドを検証する必要があります。プライベートデータフィールドを受信バッファがそのデータを受信するのに十分な大きさでなければなりません。プライベートデータの量がPD_Lengthまたはアプリケーションバッファを超えてはなりません。上記のいずれかが失敗した場合は、起動時のフレームが正しくフォーマット考えなければなりません。
10. MPA implementations SHOULD implement a reasonable timeout while waiting for the entire set of startup frames; this prevents certain denial-of-service attacks. ULPs SHOULD implement a reasonable timeout while waiting for FPDUs, ULPDUs, and application level messages to guard against application failures and certain denial-of-service attacks.
起動フレームのセット全体を待っている間10. MPA実装は妥当なタイムアウトを実装する必要があります。これは、特定のサービス拒否攻撃を防ぎます。 ULPは、アプリケーションの障害や特定のサービス拒否攻撃を防ぐためにのFPDUs、ULPDUsを待っている間に適切なタイムアウトを実装し、アプリケーションレベルのメッセージをすべきです。
A variety of startup sequences are possible when using MPA on TCP. Following is an example of an MPA/DDP startup that occurs after TCP has been running for a while and has exchanged some amount of streaming data. This example does not use any Private Data (an example that does is shown later in Section 7.1.4.2, Example Immediate Startup Using Private Data), although it is perfectly legal to include the Private Data. Note that since the example does not use any Private Data, there are no ULP interactions shown between receiving "startup frames" and putting MPA into Full Operation.
TCP上でMPAを使用した場合、起動シーケンスの様々な可能性があります。以下は、TCPは、しばらくの間、実行されていると、ストリーミングデータのいくつかの量を交換した後に発生したMPA / DDPスタートアップの一例です。プライベートデータを含めることは完全に合法であるが、この例では、（後のセクション7.1.4.2に示されてい例は、例即時起動がプライベートデータを使用して）すべてのプライベートデータを使用していません。例では、任意のプライベートデータを使用していないので、「スタートアップ・フレーム」を受信し、フルオペレーションにMPAを置く間に示されるいかなるULP相互作用が存在しないことに注意してください。
Initiator Responder
イニシエータレスポンダ
+---------------------------+
|ULP streaming mode |
| <Hello> request to |
| transition to DDP/MPA | +---------------------------+
| mode (optional). | --------> |ULP gets request; |
+---------------------------+ | enables MPA Responder |
| mode with last (optional)|
| streaming mode |
| <Hello Ack> for MPA to |
| send. |
+---------------------------+ |MPA waits for incoming |
|ULP receives streaming | <-------- | <MPA Request Frame>. |
| <Hello Ack>; | +---------------------------+
|Enters MPA Initiator mode; |
|MPA sends |
| <MPA Request Frame>; |
|MPA waits for incoming | +---------------------------+
| <MPA Reply Frame>. | - - - - > |MPA receives |
+---------------------------+ | <MPA Request Frame>. |
|Consumer binds DDP to MPA; |
|MPA sends the |
| <MPA Reply Frame>. |
|DDP/MPA enables FPDU |
+---------------------------+ | decoding, but does not |
|MPA receives the | < - - - - | send any FPDUs. |
| <MPA Reply Frame> | +---------------------------+
|Consumer binds DDP to MPA; |
|DDP/MPA begins Full |
| Operation. |
|MPA sends first FPDU (as | +---------------------------+
| DDP ULPDUs become | ========> |MPA receives first FPDU. |
| available). | |MPA sends first FPDU (as |
+---------------------------+ | DDP ULPDUs become |
<====== | available). |
+---------------------------+
Figure 9: Example Delayed Startup Negotiation
図9：例遅延スタートアップネゴシエーション
An example Delayed Startup sequence is described below:
例えば遅延スタートアップシーケンスについて説明します。
* Active and passive sides start up a TCP connection in the
usual fashion, probably using sockets APIs. They exchange
some amount of streaming mode data. At some point, one side
(the MPA Initiator) sends streaming mode data that
effectively says "Hello, let's go into MPA/DDP mode".
* When the remote side (the MPA Responder) gets this streaming mode message, the Consumer would send a last streaming mode message that effectively says "I acknowledge your Hello, and am now in MPA Responder mode". The exchange of these messages establishes the exact point in the TCP stream where MPA is enabled. The Responding Consumer enables MPA in the Responder mode and waits for the initial MPA startup message.
*リモート側（MPA Responderが）このストリーミングモードメッセージを取得すると、消費者は、効果的に「私はこんにちは、あなたを認め、かつMPAレスポンダ・モードになりましたよ」と言う最後のストリーミングのモードメッセージを送信します。これらのメッセージの交換は、MPAが有効になっているTCPストリームの正確な位置を確立します。対応の消費者は、レスポンダモードでMPAを可能にし、初期MPA起動メッセージを待ちます。
* The Initiating Consumer would enable MPA startup in the
Initiator mode which then sends the MPA Request Frame. It is
assumed that no Private Data messages are needed for this
example, although it is possible to do so. The Initiating
MPA (and Consumer) would also wait for the MPA connection to
be accepted.
* The Responding MPA would receive the initial MPA Request Frame and would inform the Consumer that this message arrived. The Consumer can then accept the MPA/DDP connection or close the TCP connection.
*対応MPAは、初期のMPA要求フレームを受け取ることになると、このメッセージが到着した消費者に通知します。消費者は、その後、MPA / DDP接続を受け入れるか、またはTCP接続を閉じることができます。
* To accept the connection request, the Responding Consumer would use an appropriate API to bind the TCP/MPA connections to a DDP endpoint, thus enabling MPA/DDP into Full Operation. In the process of going to Full Operation, MPA sends the MPA Reply Frame. MPA/DDP waits for the first incoming FPDU before sending any FPDUs.
*接続要求を受け入れるには、対応の消費者は、このようにフルオペレーションにMPA / DDPを有効にする、DDP終点にTCP / MPA接続をバインドするために、適切なAPIを使用します。フルオペレーションに行くの過程では、MPAは、MPAの応答フレームを送信します。 MPA / DDPは、任意のFPDUsを送信する前に、最初の着信FPDUを待ちます。
* If the initial TCP data was not a properly formatted MPA Request Frame, MPA will close or reset the TCP connection immediately.
*初期TCPデータが適切な形式のMPA要求フレームでなかった場合は、MPAはすぐにTCPコネクションを閉じるか、リセットされます。
* The Initiating MPA would receive the MPA Reply Frame and
would report this message to the Consumer. The Consumer can
then accept the MPA/DDP connection, or close or reset the TCP
connection to abort the process.
* On determining that the connection is acceptable, the Initiating Consumer would use an appropriate API to bind the TCP/MPA connections to a DDP endpoint thus enabling MPA/DDP into Full Operation. MPA/DDP would begin sending DDP messages as MPA FPDUs.
*接続が許容可能であると判断された場合には、開始の消費者はフルオペレーションにMPA / DDPを有効にするため、DDP終点にTCP / MPA接続をバインドするために、適切なAPIを使用します。 MPA / DDPは、MPAのFPDUsとしてDDPメッセージの送信を開始します。
This section is advisory in nature, in that it suggests a method by which a ULP can deal with pre-DDP connection information exchange.
それはULPがプレDDP接続情報交換に対処することができる方法を提案しているという点で、このセクションでは、本質的に顧問です。
Prior RDMA protocols have been developed that provide Private Data via out-of-band mechanisms. As a result, many applications now expect some form of Private Data to be available for application use prior to setting up the DDP/RDMA connection. Following are some examples of the use of Private Data.
前RDMAプロトコルは、帯域外の機構を介してプライベートデータを提供する開発されています。その結果、多くのアプリケーションは現在、プライベートデータのいくつかのフォームがDDP / RDMA接続をセットアップする前に、アプリケーションの使用のために利用できることを期待しています。以下は、プライベートデータの使用のいくつかの例です。
An RDMA endpoint (referred to as a Queue Pair, or QP, in InfiniBand and the [VERBS-RDMA]) must be associated with a Protection Domain. No receive operations may be posted to the endpoint before it is associated with a Protection Domain. Indeed under both the InfiniBand and proposed RDMA/DDP verbs [VERBS-RDMA] an endpoint/QP is created within a Protection Domain.
（インフィニバンドと[動詞-RDMA]で、キュー・ペア、またはQPとも呼ばれる）RDMAエンドポイントは、保護ドメインに関連付けられなければなりません。いいえ、それが保護ドメインに関連付けされる前に操作がエンドポイントに掲示することができる受信しません。実際インフィニバンド提案RDMA / DDP動詞[動詞-RDMA]の両方で、エンドポイント/ QPは、保護ドメイン内に作成されます。
There are some applications where the choice of Protection Domain is dependent upon the identity of the remote ULP client. For example, if a user session requires multiple connections, it is highly desirable for all of those connections to use a single Protection Domain. Note: Use of Protection Domains is further discussed in [RDMASEC].
保護ドメインの選択は、リモートULPクライアントのアイデンティティに依存しているいくつかのアプリケーションがあります。ユーザーセッションは複数の接続を必要とする場合、例えば、それは、単一の保護ドメインを使用するために、これらのすべての接続のために非常に望ましいです。注意：保護ドメインの使用は、さらに[RDMASEC]で議論されています。
InfiniBand, the DAT APIs [DAT-API], and the IT-API [IT-API] all provide for the active-side ULP to provide Private Data when requesting a connection. This data is passed to the ULP to allow it to determine whether to accept the connection, and if so with which endpoint (and implicitly which Protection Domain).
インフィニバンド、DATのAPI [DAT-API]、およびIT-API [IT-API]すべての接続を要求するときにプライベートデータを提供するために、アクティブ側のULPを提供します。このデータは、接続を受け入れるかどうかを判断できるようにするためにULPに渡され、そのエンドポイント（および暗黙的にその保護ドメイン）とそうであればされます。
The Private Data can also be used to ensure that both ends of the connection have configured their RDMA endpoints compatibly on such matters as the RDMA Read capacity (see [RDMAP]). Further ULP-specific uses are also presumed, such as establishing the identity of the client.
プライベートデータは、（[RDMAP]参照）接続の両端がRDMA読み取り能力などの事項について互換性それらのRDMAエンドポイントが設定されていることを保証するために使用することができます。また、ULP-特定の用途はまた、クライアントのアイデンティティを確立するよう、推定されます。
Private Data is also allowed for when accepting the connection, to allow completion of any negotiation on RDMA resources and for other ULP reasons.
プライベートデータは、RDMAリソース上や他のULPの理由から、任意の交渉の完了を可能にするために、接続を受け付けた場合に許可されています。
There are several potential ways to exchange this Private Data. For example, the InfiniBand specification includes a connection management protocol that allows a small amount of Private Data to be exchanged using datagrams before actually starting the RDMA connection.
このプライベートデータを交換するには、いくつかの潜在的な方法があります。例えば、インフィニバンド仕様はプライベート少量のデータが実際にRDMA接続を開始する前に、データグラムを使用して交換されることを可能にする接続管理プロトコルを含みます。
This document allows for small amounts of Private Data to be exchanged as part of the MPA startup sequence. The actual Private Data fields are carried in the MPA Request Frame and the MPA Reply Frame.
この文書では、MPAの起動シーケンスの一部として交換されるプライベート少量のデータが可能になります。実際のプライベートデータフィールドは、MPA要求フレームとMPAの応答フレームに搭載されています。
If larger amounts of Private Data or more negotiation is necessary, TCP streaming mode messages may be exchanged prior to enabling MPA.
プライベートデータ以上の交渉のより多くの量が必要な場合、TCPストリーミングモードメッセージは、MPAを有効にする前に交換することができます。
Initiator Responder
イニシエータレスポンダ
+---------------------------+
|TCP SYN sent. | +--------------------------+
+---------------------------+ --------> |TCP gets SYN packet; |
+---------------------------+ | sends SYN-Ack. |
|TCP gets SYN-Ack | <-------- +--------------------------+
| sends Ack. |
+---------------------------+ --------> +--------------------------+
+---------------------------+ |Consumer enables MPA |
|Consumer enables MPA | |Responder mode, waits for |
|Initiator mode with | | <MPA Request frame>. |
|Private Data; MPA sends | +--------------------------+
| <MPA Request Frame>; |
|MPA waits for incoming | +--------------------------+
| <MPA Reply Frame>. | - - - - > |MPA receives |
+---------------------------+ | <MPA Request Frame>. |
|Consumer examines Private |
|Data, provides MPA with |
|return Private Data, |
|binds DDP to MPA, and |
|enables MPA to send an |
| <MPA Reply Frame>. |
|DDP/MPA enables FPDU |
+---------------------------+ |decoding, but does not |
|MPA receives the | < - - - - |send any FPDUs. |
| <MPA Reply Frame>. | +--------------------------+
|Consumer examines Private |
|Data, binds DDP to MPA, |
|and enables DDP/MPA to |
|begin Full Operation. |
|MPA sends first FPDU (as | +--------------------------+
|DDP ULPDUs become | ========> |MPA receives first FPDU. |
|available). | |MPA sends first FPDU (as |
+---------------------------+ |DDP ULPDUs become |
<====== |available). |
+--------------------------+
Figure 10: Example Immediate Startup Negotiation
図10：例即時スタートアップ交渉
Note: The exact order of when MPA is started in the TCP connection sequence is implementation dependent; the above diagram shows one possible sequence. Also, the Initiator "Ack" to the Responder's "SYN-Ack" may be combined into the same TCP segment containing the MPA Request Frame (as is allowed by TCP RFCs).
注意：MPAは、TCPの接続シーケンス中に開始されたときの正確な順序は実装依存です。上記の図は、一つの可能なシーケンスを示します。また、イニシエータレスポンダの「SYN-ACK」に「ACK」は、（TCP RFCで許可されているように）MPA要求フレームを含む同じTCPセグメントに結合されてもよいです。
The example immediate startup sequence is described below:
例えば、即時起動シーケンスを以下に記載されています。
* The passive side (Responding Consumer) would listen on the TCP destination port, to indicate its readiness to accept a connection.
*パッシブ側（対応消費者）は、接続を受け入れるためにその準備状況を示すために、TCP宛先ポート上で聞くでしょう。
* The active side (Initiating Consumer) would request a
connection from a TCP endpoint (that expected to upgrade to
MPA/DDP/RDMA and expected the Private Data) to a destination
address and port.
* The Initiating Consumer would initiate a TCP connection to the destination port. Acceptance/rejection of the connection would proceed as per normal TCP connection establishment.
*開始消費者は、宛先ポートへのTCP接続を開始します。接続の受け入れ/拒否は、通常のTCPコネクションの確立ごとのように進行します。
* The passive side (Responding Consumer) would receive the TCP connection request as usual allowing normal TCP gatekeepers, such as INETD and TCPserver, to exercise their normal safeguard/logging functions. On acceptance of the TCP connection, the Responding Consumer would enable MPA in the Responder mode and wait for the initial MPA startup message.
*パッシブ側（消費者に対応）は、それらの通常のセーフガード/ログ機能を発揮するために、INETDやtcpserverはいつものようにできるように、通常のTCPゲートキーパーとして、TCP接続要求を受け取ることになります。 TCPコネクションの受け入れには、対応の消費者は、レスポンダモードでMPAを可能にし、初期MPA起動メッセージを待ちます。
* The Initiating Consumer would enable MPA startup in the
Initiator mode to send an initial MPA Request Frame with its
included Private Data message to send. The Initiating MPA
(and Consumer) would also wait for the MPA connection to be
accepted, and any returned Private Data.
* The Responding MPA would receive the initial MPA Request Frame with the Private Data message and would pass the Private Data through to the Consumer. The Consumer can then accept the MPA/DDP connection, close the TCP connection, or reject the MPA connection with a return message.
*対応MPAは、プライベートデータメッセージで初期MPA要求フレームを受け取ることになると消費者に通じプライベートデータを渡します。消費者は、その後、MPA / DDP接続を受け入れるTCP接続を閉じる、または戻りメッセージとのMPA接続を拒否することができます。
* To accept the connection request, the Responding Consumer would use an appropriate API to bind the TCP/MPA connections to a DDP endpoint, thus enabling MPA/DDP into Full Operation. In the process of going to Full Operation, MPA sends the MPA Reply Frame, which includes the Consumer-supplied Private Data containing any appropriate Consumer response. MPA/DDP waits for the first incoming FPDU before sending any FPDUs.
*接続要求を受け入れるには、対応の消費者は、このようにフルオペレーションにMPA / DDPを有効にする、DDP終点にTCP / MPA接続をバインドするために、適切なAPIを使用します。フルオペレーションに行くの過程では、MPAは、任意の適切な消費者の反応を含む消費者が提供するプライベートデータを含んでいるMPA応答フレームを送信します。 MPA / DDPは、任意のFPDUsを送信する前に、最初の着信FPDUを待ちます。
* If the initial TCP data was not a properly formatted MPA Request Frame, MPA will close or reset the TCP connection immediately.
*初期TCPデータが適切な形式のMPA要求フレームでなかった場合は、MPAはすぐにTCPコネクションを閉じるか、リセットされます。
* To reject the MPA connection request, the Responding Consumer would send an MPA Reply Frame with any ULP-supplied Private Data (with reason for rejection), with the "Rejected Connection" bit set to '1', and may close the TCP connection.
* MPA接続要求を拒否するには、対応消費者は「1」に設定ビットが「拒否された接続」で、（拒否の理由を含む）すべてのULP-供給プライベートデータとMPAの応答フレームを送信して、TCP接続を閉じることがあります。
* The Initiating MPA would receive the MPA Reply Frame with the
Private Data message and would report this message to the
Consumer, including the supplied Private Data.
If the "Rejected Connection" bit is set to a '1', MPA will
close the TCP connection and exit.
If the "Rejected Connection" bit is set to a '0', and on determining from the MPA Reply Frame Private Data that the connection is acceptable, the Initiating Consumer would use an appropriate API to bind the TCP/MPA connections to a DDP endpoint thus enabling MPA/DDP into Full Operation. MPA/DDP would begin sending DDP messages as MPA FPDUs.
「拒否された接続」ビットは、接続が許容可能であるフレームプライベートデータを返信MPAから決定する上で「0」に設定されている場合は、開始消費者はDDP終点にTCP / MPA接続をバインドするために、適切なAPIを使用しますこれフルオペレーションにMPA / DDPを可能にします。 MPA / DDPは、MPAのFPDUsとしてDDPメッセージの送信を開始します。
MPA/DDP implementations are commonly expected to be implemented as part of a "dual stack" architecture. One stack is the traditional TCP stack, usually with a sockets interface API (Application Programming Interface). The second stack is the MPA/DDP stack with its own API, and potentially separate code or hardware to deal with the MPA/DDP data. Of course, implementations may vary, so the following comments are of an advisory nature only.
MPA / DDP実装は、一般に「デュアルスタック」アーキテクチャの一部として実装されることが期待されます。一つのスタックは、通常のソケットインタフェースAPI（アプリケーション・プログラミング・インターフェース）で、従来のTCPスタックです。第二のスタックは、MPA / DDPは、独自のAPIとスタック、MPA / DDPデータに対処するため、潜在的に別々のコード又はハードウェアです。もちろん、実装は変更される場合がありますので、次のようなコメントは顧問性質のものです。
The use of the two stacks offers advantages:
2つのスタックを使用することは利点があります。
TCP connection setup is usually done with the TCP stack. This
allows use of the usual naming and addressing mechanisms. It
also means that any mechanisms used to "harden" the connection
setup against security threats are also used when starting
MPA/DDP.
Some applications may have been originally designed for TCP, but are "enhanced" to utilize MPA/DDP after a negotiation reveals the capability to do so. The negotiation process takes place in TCP's streaming mode, using the usual TCP APIs.
一部のアプリケーションは、もともとTCPのために設計されているかもしれませんが、交渉がそうする機能を明らかにした後、MPA / DDPを利用するために、「強化」されています。交渉プロセスは、通常のTCP APIを使用して、TCPのストリーミングモードで行われます。
Some new applications, designed for RDMA or DDP, still need to exchange some data prior to starting MPA/DDP. This exchange can be of arbitrary length or complexity, but often consists of only a small amount of Private Data, perhaps only a single message. Using the TCP streaming mode for this exchange allows this to be done using well-understood methods.
RDMAかDDPのために設計されたいくつかの新しいアプリケーションは、まだMPA / DDPを開始する前に、いくつかのデータを交換する必要があります。この交換は、任意の長さまたは複雑さのものとすることが、しばしばプライベートデータのごく少量、おそらく単一のメッセージから構成することができます。この交換のためのTCPストリーミングモードを使用すると、これは十分に理解の方法を用いて行うことができるようになります。
The main disadvantage of using two stacks is the conversion of an active TCP connection between them. This process must be done with care to prevent loss of data.
2つのスタックを使用することの主な欠点は、それらの間のアクティブなTCP接続の変換です。このプロセスは、データの損失を防ぐために、注意して行わなければなりません。
To avoid some of the problems when using a "dual stack" architecture, the following additional restrictions may be required by the implementation:
「デュアルスタック」アーキテクチャを使用した場合の問題のいくつかを回避するために、次の追加の制限が実装によって必要となる場合があります。
1. Enabling the DDP/MPA stack SHOULD be done only when no incoming stream data is expected. This is typically managed by the ULP protocol. When following the recommended startup sequence, the Responder side enters DDP/MPA mode, sends the last streaming mode data, and then waits for the MPA Request Frame. No additional streaming mode data is expected. The Initiator side ULP receives the last streaming mode data, and then enters DDP/MPA mode. Again, no additional streaming mode data is expected.
1. DDP / MPAスタックを有効にするには着信ストリームデータが期待されていない場合にのみ行われるべきです。これは通常、ULPプロトコルによって管理されています。推奨起動シーケンスを以下の場合は、レスポンダ側はDDP / MPAモードに入り、最後のストリーミングモードデータを送信し、MPA要求フレームを待ちます。追加のストリーミングモードデータが期待されていません。イニシエータ側ULPは最後のストリーミングモードのデータを受信し、DDP / MPAモードに入ります。ここでも、追加のストリーミングモードデータが期待されていません。
2. The DDP/MPA MAY provide the ability to send a "last streaming message" as part of its Responder DDP/MPA enable function. This allows the DDP/MPA stack to more easily manage the conversion to DDP/MPA mode (and avoid problems with a very fast return of the MPA Request Frame from the Initiator side).
2. DDP / MPAは、そのレスポンダDDP / MPA機能を有効にするの一環として、「最後のストリーミングメッセージ」を送信する能力を提供することができます。これはDDP / MPAスタックがより簡単にDDP / MPAモードへの変換を管理する（およびイニシエータ側からMPA要求フレームの非常に高速な復帰の問題を回避）することができます。
Note: Regardless of the "stack" architecture used, TCP's rules MUST be followed. For example, if network data is lost, re-segmented, or re-ordered, TCP MUST recover appropriately even when this occurs while switching stacks.
注意：に関係なく使用される「スタック」アーキテクチャの、TCPのルールに従わなければなりません。ネットワークデータは、失われた再セグメント化、または再注文された場合、TCPは、スタックを切り替えながら、これが発生した場合でも、適切に回復しなければなりません。
Each half connection of MPA terminates when DDP closes the corresponding TCP half connection.
DDPが対応するTCP半分接続が閉じられたときにMPAのそれぞれの半分接続が終了します。
A mechanism SHOULD be provided by MPA to DDP for DDP to be made aware that a graceful close of the TCP connection has been received by the TCP (e.g., FIN is received).
機構は、TCP接続のグレースフルクローズ（例えば、FINを受信した）TCPによって受信されたことを知らされるべきDDPためDDPにMPAによって提供されるべきです。
The following errors MUST be detected by MPA and the codes SHOULD be provided to DDP or other Consumer:
次のエラーがMPAによって検出されなければならないとコードは、DDPまたは他の消費者に提供されるべきです。
Code Error
コードエラー
1 TCP connection closed, terminated, or lost. This includes lost by timeout, too many retries, RST received, or FIN received.
1つのTCP接続は、閉じ終了、または失われました。これは、RSTが受信、タイムアウトであまりにも多くの再試行を紛失したり、FINを受信しています。
2 Received MPA CRC does not match the calculated value for the FPDU.
2受信MPA CRCはFPDUの計算値と一致していません。
3 In the event that the CRC is valid, received MPA Marker (if enabled) and ULPDU Length fields do not agree on the start of an FPDU. If the FPDU start determined from previous ULPDU Length fields does not match with the MPA Marker position, MPA SHOULD deliver an error to DDP. It may not be possible to make this check as a segment arrives, but the check SHOULD be made when a gap creating an out-of-order sequence is closed and any time a Marker points to an already identified FPDU. It is OPTIONAL for a receiver to check each Marker, if multiple Markers are present in an FPDU, or if the segment is received in order.
CRCが有効である場合には3、（有効な場合）MPAマーカを受信し、ULPDUの長さフィールドはFPDUの開始に同意しません。 FPDUがMPAマーカ位置と一致していない前のULPDUの長さフィールドから求め始めた場合、MPAは、DDPにエラーを提供すべきです。既に同定FPDUにマーカーポイントセグメントが到着するように、このチェックを行うことが可能ではないかもしれないが、アウト・オブ・オーダーシーケンスを作成ギャップが閉じられたときにチェックがなされるべきであるといつでも。受信機は、各マーカーを確認するために、複数のマーカーはFPDUに存在する場合、又はセグメントが順に受信された場合には、任意です。
4 Invalid MPA Request Frame or MPA Response Frame received. In this case, the TCP connection MUST be immediately closed. DDP and other ULPs should treat this similar to code 1, above.
4無効なMPA要求フレームまたはMPA応答フレームを受信しました。この場合、TCP接続はすぐに閉じていなければなりません。 DDPと他のULPは、上記のコード1に、これは似て扱う必要があります。
When conditions 2 or 3 above are detected, an optimized MPA/TCP implementation MAY choose to silently drop the TCP segment rather than reporting the error to DDP. In this case, the sending TCP will retry the segment, usually correcting the error, unless the problem was at the source. In that case, the source will usually exceed the number of retries and terminate the connection.
上記条件2又は3が検出されると、最適化されたMPA / TCPの実装は静かDDPへエラーを報告するのではなく、TCPセグメントをドロップすることを選ぶかもしれ。問題は、元であった場合を除き、この場合、送信側TCPは、通常、誤り訂正、セグメントを再試行します。その場合、ソースは、通常、再試行回数を超えて接続を終了します。
Once MPA delivers an error of any type, it MUST NOT pass or deliver any additional FPDUs on that half connection.
MPAは、どのようなタイプのエラーを提供したら、それはその半分接続上の任意の追加のFPDUsを渡すか、または提供してはなりません。
For Error codes 2 and 3, MPA MUST NOT close the TCP connection following a reported error. Closing the connection is the responsibility of DDP's ULP.
エラーコード2と3については、MPAは、報告されたエラー、次のTCP接続を閉じてはなりません。接続を閉じると、DDPのULPの責任です。
Note that since MPA will not Deliver any FPDUs on a half
connection following an error detected on the receive side of
that connection, DDP's ULP is expected to tear down the
connection. This may not occur until after one or more last
messages are transmitted on the opposite half connection. This
allows a diagnostic error message to be sent.
This section discusses the security considerations for MPA.
このセクションでは、MPAのためのセキュリティの考慮事項について説明します。
The vulnerabilities of MPA to third-party attacks are no greater than any other protocol running over TCP. A third party, by sending packets into the network that are delivered to an MPA receiver, could launch a variety of attacks that take advantage of how MPA operates. For example, a third party could send random packets that are valid for TCP, but contain no FPDU headers. An MPA receiver reports an error to DDP when any packet arrives that cannot be validated as an FPDU when properly located on an FPDU boundary. A third party could also send packets that are valid for TCP, MPA, and DDP, but do not target valid buffers. These types of attacks ultimately result in loss of connection and thus become a type of DOS (Denial Of Service) attack. Communication security mechanisms such as IPsec [RFC2401, RFC4301] may be used to prevent such attacks.
サードパーティの攻撃へのMPAの脆弱性は、TCP上で実行されている他のプロトコルよりも大きくありません。第三者は、MPA受信機に配信されているネットワークにパケットを送信することにより、MPAがどのように動作するかを利用するさまざまな攻撃を起動することができます。例えば、第三者はTCPのために有効ですが、何のFPDUヘッダーが含まれていないランダムなパケットを送信することができます。すべてのパケットが正しくFPDU境界上にあるときには、FPDUとして検証することはできません到着したときMPA受信機は、DDPにエラーを報告します。第三者はまたTCP、MPA、およびDDPのために有効ですが、有効なバッファをターゲットとしないパケットを送信することができます。これらのタイプの攻撃は、最終的には、接続の損失をもたらすため、DoS（Denial of Service）攻撃のタイプになります。このようにIPsec [RFC2401、RFC4301]などの通信のセキュリティメカニズムは、そのような攻撃を防ぐために使用されてもよいです。
Independent of how MPA operates, a third party could use ICMP messages to reduce the path MTU to such a small size that performance would likewise be severely impacted. Range checking on path MTU sizes in ICMP packets may be used to prevent such attacks.
MPAがどのように動作するかの独立した第三者は、そのパフォーマンスは同様に深刻な影響を受けることになるような小さなサイズにパスMTUを減らすためにICMPメッセージを使用することができます。 ICMPパケットでパスMTUサイズにチェック範囲は、このような攻撃を防ぐために使用することができます。
[RDMAP] and [DDP] are used to control, read, and write data buffers over IP networks. Therefore, the control and the data packets of these protocols are vulnerable to the spoofing, tampering, and information disclosure attacks listed below. In addition, connection to/from an unauthorized or unauthenticated endpoint is a potential problem with most applications using RDMA, DDP, and MPA.
[RDMAP]と[DDP]、制御読み取り、およびIPネットワーク上でデータバッファを書き込むために使用されます。したがって、制御およびこれらのプロトコルのデータパケットは、下記のなりすまし、改ざん、及び情報開示攻撃に対して脆弱です。また、不正または認証されていないエンドポイントからの/への接続はRDMA、DDP、およびMPAを使用するほとんどのアプリケーションとの潜在的な問題です。
Spoofing attacks can be launched by the Remote Peer or by a network based attacker. A network-based spoofing attack applies to all Remote Peers. Because the MPA Stream requires a TCP Stream in the ESTABLISHED state, certain types of traditional forms of wire attacks do not apply -- an end-to-end handshake must have occurred to establish the MPA Stream. So, the only form of spoofing that applies is one when a remote node can both send and receive packets. Yet even with this limitation the Stream is still exposed to the following spoofing attacks.
スプーフィング攻撃は、リモートピアによって、またはネットワークベースの攻撃者によって起動することができます。ネットワークベースのスプーフィング攻撃は、すべてのリモートピアに適用されます。 MPAストリームがESTABLISHED状態でのTCPストリームを必要とするため、ワイヤ攻撃の伝統的な形式の特定の種類は適用されません - エンドツーエンドのハンドシェイクがMPAストリームを確立するために発生していなければなりません。リモート・ノードがパケットを送受信することができ、両方のときに、適用されるスプーフィングの唯一の形式は1です。しかし、でも、この制限をストリームは、まだ以下のスプーフィング攻撃にさらされています。
A network-based attacker can impersonate a legal MPA/DDP/RDMAP peer (by spoofing a legal IP address) and establish an MPA/DDP/RDMAP Stream with the victim. End-to-end authentication (i.e., IPsec or ULP authentication) provides protection against this attack.
ネットワークベースの攻撃者は、（合法のIPアドレスを偽装して）法的MPA / DDP / RDMAPピアを偽装し、被害者とのMPA / DDP / RDMAPストリームを確立することができます。エンドツーエンドの認証（すなわち、IPSecまたはULP認証）この攻撃に対する保護を提供します。
Stream hijacking happens when a network-based attacker follows the Stream establishment phase, and waits until the authentication phase (if such a phase exists) is completed successfully. He can then spoof the IP address and redirect the Stream from the victim to its own machine. For example, an attacker can wait until an iSCSI authentication is completed successfully, and hijack the iSCSI Stream.
ストリームハイジャックは、ネットワークベースの攻撃者がストリーム確立フェーズの後に続く場合に発生し、（例えば位相が存在する場合）が正常に完了し、認証フェーズまで待機します。彼はその後、IPアドレスを偽装して、独自のマシンに被害者からのストリームをリダイレクトすることができます。例えば、攻撃者がiSCSI認証が正常に完了するまで待機し、iSCSIのストリームをハイジャックすることができます。
The best protection against this form of attack is end-to-end integrity protection and authentication, such as IPsec, to prevent spoofing. Another option is to provide physical security. Discussion of physical security is out of scope for this document.
この形式の攻撃に対する最善の保護は、なりすましを防ぐために、IPsecなどのエンド・ツー・エンドの完全性保護と認証、です。別のオプションは、物理的なセキュリティを提供することです。物理的なセキュリティの議論はこの文書の範囲外です。
If a network-based attacker has the ability to delete, inject, replay, or modify packets that will still be accepted by MPA (e.g., TCP sequence number is correct, FPDU is valid, etc.), then the Stream can be exposed to a man-in-the-middle attack. The attacker could potentially use the services of [DDP] and [RDMAP] to read the contents of the associated Data Buffer, to modify the contents of the associated Data Buffer, or to disable further access to the buffer. Other attacks on the connection setup sequence and even on TCP can be used to cause denial of service. The only countermeasure for this form of attack is to either secure the MPA/DDP/RDMAP Stream (i.e., integrity protect) or attempt to provide physical security to prevent man-in-the-middle type attacks.
ネットワークベースの攻撃者が（例えば、TCPシーケンス番号が正しいか、FPDUはなど、有効である）を削除する能力を持って、注入し、リプレイ、または静止MPAによって受理されるパケットを変更した場合は、ストリームに露出させることができますman-in-the-middle攻撃。攻撃者は、潜在的に関連するデータバッファの内容を変更するため、またはバッファへのさらなるアクセスを無効にするために、関連するデータバッファの内容を読み取るために、[DDP]および[RDMAP]のサービスを使用することができます。接続設定シーケンス上、さらにはTCP上の他の攻撃は、サービス拒否を引き起こすために使用することができます。この形式の攻撃のための唯一の対策は（すなわち、完全性を保護する）MPA / DDP / RDMAPストリームを確保するかのman-in-the-middleタイプの攻撃を防ぐために、物理的なセキュリティを提供しようとするかのいずれかです。
The best protection against this form of attack is end-to-end integrity protection and authentication, such as IPsec, to prevent spoofing or tampering. If Stream or session level authentication and integrity protection are not used, then a man-in-the-middle attack can occur, enabling spoofing and tampering.
この形式の攻撃に対する最善の防御は、なりすましや改ざんを防ぐために、IPsecなどのエンド・ツー・エンドの完全性保護と認証、です。ストリームまたはセッションレベルの認証と完全性の保護が使用されていない場合は、man-in-the-middle攻撃は、なりすましや改ざんを有効に、発生する可能性があります。
Another approach is to restrict access to only the local subnet/link and provide some mechanism to limit access, such as physical security or 802.1.x. This model is an extremely limited deployment scenario and will not be further examined here.
別のアプローチは、ローカルサブネット/リンクへのアクセスを制限し、そのような物理的なセキュリティまたは802.1.x.として、アクセスを制限するいくつかのメカニズムを提供することですこのモデルは、非常に限られた展開シナリオであり、さらに、ここで検討されることはありません。
Generally speaking, Stream confidentiality protects against eavesdropping. Stream and/or session authentication and integrity protection are a counter measurement against various spoofing and tampering attacks. The effectiveness of authentication and integrity against a specific attack depend on whether the authentication is machine-level authentication (as the one provided by IPsec) or ULP authentication.
一般的に言えば、ストリームの機密性は、盗聴から保護します。ストリームおよび/またはセッション認証と完全性保護は、様々ななりすましや改ざん攻撃に対するカウンタ測定されています。特定の攻撃に対しての認証と完全性の有効性は、認証が（IPSecで提供されるものとして）マシンレベルの認証またはULP認証であるかどうかに依存します。
The following security services can be applied to an MPA/DDP/RDMAP Stream:
次のセキュリティサービスは、MPA / DDP / RDMAPストリームに適用することができます。
2. Per-packet data source authentication - protects against the following spoofing attacks: network-based impersonation, Stream hijacking, and man in the middle.
ネットワークベースの偽装、ストリームのハイジャック、および男性真ん中に： - 2パケット単位のデータソース認証は、次のスプーフィング攻撃から保護します。
3. Per-packet integrity - protects against tampering done by network-based modification of FPDUs (indirectly affecting buffer content through DDP services).
3.パケットごとの整合性は、 - （間接的にDDPサービスを介してバッファの内容に影響を与える）のFPDUsのネットワークベースの変更によって行わ改ざんから保護します。
4. Packet sequencing - protects against replay attacks, which is a special case of the above tampering attack.
4.パケットシーケンシング - 上記の改ざん攻撃の特殊なケースである、リプレイ攻撃から保護します。
If an MPA/DDP/RDMAP Stream may be subject to impersonation attacks, or Stream hijacking attacks, it is recommended that the Stream be authenticated, integrity protected, and protected from replay attacks. It may use confidentiality protection to protect from eavesdropping (in case the MPA/DDP/RDMAP Stream traverses a public network).
MPA / DDP / RDMAPストリームは、なりすまし攻撃、またはストリームのハイジャック攻撃を受ける可能性がある場合、ストリームが認証することを推奨完全性を保護し、リプレイ攻撃から保護されています。これは、（場合にはMPA / DDP / RDMAPストリームは、公衆ネットワークを通過する）盗聴から保護するために機密保護を使用することができます。
IPsec is capable of providing the above security services for IP and TCP traffic.
IPsecはIPとTCPトラフィックのために上記のセキュリティサービスを提供することが可能です。
ULP protocols may be able to provide part of the above security services. See [NFSv4CHAN] for additional information on a promising approach called "channel binding". From [NFSv4CHAN]:
ULPプロトコルは、上記のセキュリティサービスの一部を提供することができます。 「チャネル結合」と呼ばれる有望なアプローチに関する追加情報については、[NFSv4CHAN]を参照してください。 [NFSv4CHAN]から：
"The concept of channel bindings allows applications to prove
that the end-points of two secure channels at different network
layers are the same by binding authentication at one channel to
the session protection at the other channel. The use of channel bindings allows applications to delegate session protection to
lower layers, which may significantly improve performance for
some applications."
IPsec can be used to protect against the packet injection attacks outlined above. Because IPsec is designed to secure individual IP packets, MPA can run above IPsec without change. IPsec packets are processed (e.g., integrity checked and decrypted) in the order they are received, and an MPA receiver will process the decrypted FPDUs contained in these packets in the same manner as FPDUs contained in unsecured IP packets.
IPsecは上記で概説したパケットインジェクション攻撃から保護するために使用することができます。 IPsecは、個々のIPパケットを確保するために設計されているため、MPAは変更せずにIPsecの上で実行することができます。 IPsecパケットは、それらが受信された順序で（例えば、整合性がチェックされ、復号化）処理され、MPA受信機は保護されていないIPパケットに含まれるのFPDUsと同様に、これらのパケットに含まれる復号化のFPDUsを処理します。
MPA implementations MUST implement IPsec as described in Section 9.4 below. The use of IPsec is up to ULPs and administrators.
以下のセクション9.4に記載されるようにMPA実装はIPsecを実装しなければなりません。 IPsecの使用はのULPと管理者に任されています。
The IP Storage working group has spent significant time and effort to define the normative IPsec requirements for IP storage [RFC3723]. Portions of that specification are applicable to a wide variety of protocols, including the RDDP protocol suite. In order not to replicate this effort, an MPA on TCP implementation MUST follow the requirements defined in RFC 3723, Sections 2.3 and 5, including the associated normative references for those sections.
IPストレージワーキンググループは、IPストレージのための規範のIPsec要件[RFC3723]を定義するために多大な時間と労力を費やしてきました。その仕様の部分はRDDPプロトコルスイートなどの多種多様なプロトコルにも適用可能です。この努力を複製しないようにするためには、TCPの実装上のMPAは、RFC 3723で定義された要件に従わなければならない、これらのセクションのための関連する規範的な参照を含むセクション2.3と5、。
Additionally, since IPsec acceleration hardware may only be able to handle a limited number of active Internet Key Exchange Protocol (IKE) Phase 2 security associations (SAs), Phase 2 delete messages MAY be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down a DDP/RDMA Stream. Rather, it is preferable to leave the Stream up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing Streams up and down.
また、IPsecのアクセラレーションハードウェアだけなので数を維持する手段として、アイドルSAのために送られるかもしれないアクティブなインターネット鍵交換プロトコル（IKE）フェーズ2セキュリティアソシエーションの限られた数（SAS）、フェーズ2は、メッセージを削除を処理することができるかもしれません最小のアクティブフェーズ2つのSA。 IKEフェーズ2削除メッセージの受信は、DDP / RDMAストリームを切断する理由として解釈されてはいけません。むしろ、アップストリームを残すことが好ましく、追加のトラフィックが、それに送信された場合、それを保護するために別のIKEフェーズ2 SAを起動します。これは、継続的にアップとダウンストリームをもたらす可能性を回避できます。
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. 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
RFC 4301 [RFC4301]で指定されたIPSecの新しいバージョンの存在と関連するにもかかわらず、RFC 3723 [RFC3723]でプロファイルとしてRDDPのIPsec要件は、RFC 2401 [RFC2401]および関連するRFCで指定されたIPSecのバージョンに基づいていますRFCの。 RDDPプロトコルの重要な初期の用途の一つは、iSCSI [のiSER]との使用です。 RDDPのIPsecの要件は、IPsecの共通プロファイルを可能にすることにより、その使用を容易にするためのIPsecのものをiSCSIとRDDPプロトコルで使用するに従ってください。将来的には、RFC
3723 may be updated to the newer version of IPsec; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
3723は、IPsecの新しいバージョンに更新することができます。そのような更新のIPsecセキュリティ要件は、iSCSIとRDDPプロトコルに均一に適用されるべきです。
Note that there are serious security issues if IPsec is not implemented end-to-end. For example, if IPsec is implemented as a tunnel in the middle of the network, any hosts between the peer and the IPsec tunneling device can freely attack the unprotected Stream.
IPsecは、エンドツーエンドの実装されていない場合は、重大なセキュリティ上の問題があることに注意してください。 IPsecは、ネットワークの中央のトンネルとして実装されている場合、例えば、ピアとのIPsecトンネルデバイスとの間の任意のホストは自由に保護されていないストリームを攻撃することができます。
No IANA actions are required by this document.
いいえIANAのアクションは、この文書で必要ありません。
If a well-known port is chosen as the mechanism to identify a DDP on MPA on TCP, the well-known port must be registered with IANA. Because the use of the port is DDP specific, registration of the port with IANA is left to DDP.
よく知られたポートはTCP上でMPAにDDPを識別するための仕組みとして選択されている場合は、よく知られたポートは、IANAに登録する必要があります。ポートの使用はDDP固有のものですので、IANAのポートの登録はDDPに委ねられています。
Appendix A. Optimized MPA-Aware TCP Implementations
付録A. MPA-AwareのTCPの実装を最適化
This appendix is for information only and is NOT part of the standard.
この付録では、情報提供のみを目的と標準の一部ではありません。
This appendix covers some Optimized MPA-aware TCP implementation guidance to implementers. It is intended for those implementations that want to send/receive as much traffic as possible in an aligned and zero-copy fashion.
この付録では、実装にはいくつかの最適化されたMPA-意識TCP実装ガイダンスをカバーしています。それは、整列し、ゼロコピーの方法でできるだけ多くのトラフィックを送信/受信したいものを実装するためのものです。
+-----------------------------------+
| +-----------+ +-----------------+ |
| | Optimized | | Other Protocols | |
| | MPA/TCP | +-----------------+ |
| +-----------+ || |
| \\ --- socket API --- |
| \\ || |
| \\ +-----+ |
| \\ | TCP | |
| \\ +-----+ |
| \\ // |
| +-------+ |
| | IP | |
| +-------+ |
+-----------------------------------+
Figure 11: Optimized MPA/TCP Implementation
図11：最適化されたMPA / TCPの実装
The diagram above shows a block diagram of a potential implementation. The network sub-system in the diagram can support traditional sockets-based connections using the normal API as shown on the right side of the diagram. Connections for DDP/MPA/TCP are run using the facilities shown on the left side of the diagram.
上の図は、潜在的な実装のブロック図を示しています。図中のネットワークサブシステムは、図の右側に示すように、通常のAPIを使用して、伝統的なソケットベースの接続をサポートすることができます。 DDP / MPA / TCPの接続は、図の左側に示す機能を使用して実行されます。
The DDP/MPA/TCP connections can be started using the facilities shown on the left side using some suitable API, or they can be initiated using the facilities shown on the right side and transitioned to the left side at the point in the connection setup where MPA goes to "Full MPA/DDP Operation Phase" as described in Section 7.1.2.
DDP / MPA / TCP接続は、いくつかの適切なAPIを使用して、左側に示す機能を使用して開始することができ、またはそれらを右側に示すの設備を使用して開始し、接続設定どこにある時点で左側に移行することができます第7.1.2項で説明したようにMPAは「フルMPA / DDP運用フェーズ」になります。
The optimized MPA/TCP implementations (left side of diagram and described below) are only applicable to MPA. All other TCP applications continue to use the standard TCP stacks and interfaces shown in the right side of the diagram.
最適化されたMPA / TCPの実装（図の側面を残し、以下に説明する）は、MPAにのみ適用可能です。他のすべてのTCPアプリケーションは、図の右側に示される標準的なTCPスタックとインターフェースを使用し続けます。
A.1. Optimized MPA/TCP Transmitters
A.1。最適化されたMPA / TCPトランスミッタ
The various TCP RFCs allow considerable choice in segmenting a TCP stream. In order to optimize FPDU recovery at the MPA receiver, an optimized MPA/TCP implementation uses additional segmentation rules.
様々なTCP RFCはTCPストリームを分割するにはかなりの選択肢を可能にします。 MPA受信機でFPDU回復を最適化するために、最適化されたMPA / TCPの実装では、追加のセグメント化ルールを使用します。
To provide optimum performance, an optimized MPA/TCP transmit side implementation should be enabled to:
最適なパフォーマンスを実現するには、最適化されたMPA / TCP送信側の実装はに有効にする必要があります。
* With an EMSS large enough to contain the FPDU(s), segment the outgoing TCP stream such that the first octet of every TCP segment begins with an FPDU. Multiple FPDUs may be packed into a single TCP segment as long as they are entirely contained in the TCP segment.
* FPDU（単数または複数）を含有するのに十分な大きエムス、セグメント毎にTCPセグメントの最初のオクテットがFPDUで始まるように発信TCPストリームと。複数のFPDUsであれば、それらが完全にTCPセグメントに含まれているような単一のTCPセグメントに充填されてもよいです。
* Report the current EMSS from the TCP to the MPA transmit layer.
* MPA送信層にTCPから現在エムスを報告します。
There are exceptions to the above rule. Once an ULPDU is provided to MPA, the MPA/TCP sender transmits it or fails the connection; it cannot be repudiated. As a result, during changes in MTU and EMSS, or when TCP's Receive Window size (RWIN) becomes too small, it may be necessary to send FPDUs that do not conform to the segmentation rule above.
上記の規則には例外があります。 ULPDUはMPAに提供されると、MPA / TCP送信者は、それを送信または接続に失敗しました。それは否認することはできません。 MTUとエムスの変化の間に、結果として、またはTCPの受信ウィンドウサイズ（RWIN）が小さくなりすぎると、上記のセグメント化規則に準拠していないのFPDUsを送信する必要があるかもしれません。
A possible, but less desirable, alternative is to use IP fragmentation on accepted FPDUs to deal with MTU reductions or extremely small EMSS.
可能な限り、あまり望ましく、代替は、MTUの削減または非常に小さいエムスに対処するために受け入れられたのFPDUsにIPフラグメンテーションを使用することです。
Even when alignment with TCP segments is lost, the sender still formats the FPDU according to FPDU format as shown in Figure 2.
TCPセグメントを有するアライメントが失われた場合でも、図2に示すように、送信者は依然としてFPDUフォーマットに従ってFPDUをフォーマット。
On a retransmission, TCP does not necessarily preserve original TCP segmentation boundaries. This can lead to the loss of FPDU Alignment and containment within a TCP segment during TCP retransmissions. An optimized MPA/TCP sender should try to preserve original TCP segmentation boundaries on a retransmission.
再送信では、TCPは、必ずしも元TCPセグメンテーション境界を保持しません。これは、TCP再送時のTCPセグメント内FPDU整列し、封じ込めの損失につながることができます。最適化されたMPA / TCPの送信側は、再送上の元のTCPセグメンテーションの境界を維持しようとする必要があります。
A.2. Effects of Optimized MPA/TCP Segmentation
A.2。最適化されたMPA / TCPセグメンテーションの影響
Optimized MPA/TCP senders will fill TCP segments to the EMSS with a single FPDU when a DDP message is large enough. Since the DDP message may not exactly fit into TCP segments, a "message tail" often occurs that results in an FPDU that is smaller than a single TCP segment. Additionally, some DDP messages may be considerably shorter than the EMSS. If a small FPDU is sent in a single TCP segment, the result is a "short" TCP segment.
DDPメッセージが十分に大きいときに最適化されたMPA / TCPの送信者は、単一のFPDUでエムスへのTCPセグメントを記入します。 DDPメッセージが正確にTCPセグメントに収まらない可能性があるため、「メッセージテール」は、しばしば、単一のTCPセグメントよりも小さいFPDUをもたらすことが起こります。さらに、いくつかのDDPメッセージは、エムスよりもかなり短くてもよいです。小さなFPDUが単一のTCPセグメントに送信された場合、結果は「短い」TCPセグメントです。
Applications expected to see strong advantages from Direct Data Placement include transaction-based applications and throughput applications. Request/response protocols typically send one FPDU per TCP segment and then wait for a response. Under these conditions, these "short" TCP segments are an appropriate and expected effect of the segmentation.
直接データの配置からの強い利点が見込まアプリケーションは、トランザクションベースのアプリケーションとスループットのアプリケーションが含まれます。要求/応答プロトコルは、通常、TCPセグメントごとに1つのFPDUを送信し、応答を待ちます。これらの条件下で、これらの「短い」TCPセグメントは、セグメント化の適切かつ期待される効果です。
Another possibility is that the application might be sending multiple messages (FPDUs) to the same endpoint before waiting for a response. In this case, the segmentation policy would tend to reduce the available connection bandwidth by under-filling the TCP segments.
別の可能性は、アプリケーションが応答を待っている前に、同じエンドポイントに複数のメッセージ（のFPDUs）を送信するかもしれないということです。この場合、セグメンテーションポリシーは、アンダーフィルTCPセグメントによって使用可能な接続の帯域幅を減少させる傾向があります。
Standard TCP implementations often utilize the Nagle [RFC896] algorithm to ensure that segments are filled to the EMSS whenever the round-trip latency is large enough that the source stream can fully fill segments before ACKs arrive. The algorithm does this by delaying the transmission of TCP segments until a ULP can fill a segment, or until an ACK arrives from the far side. The algorithm thus allows for smaller segments when latencies are shorter to keep the ULP's end-to-end latency to reasonable levels.
標準のTCP実装は、多くの場合、往復待ち時間はACKが到着する前に、ソースストリームが完全にセグメントを満たすことができる十分な大きさであるときはいつでもセグメントはエムスに満たされることを保証するためにネーグル[RFC896]のアルゴリズムを利用します。アルゴリズムは、ULPセグメントを満たすことができるまで、TCPセグメントの伝送を遅延させることによってこれを行う、またはACKが遠い側から到着するまで。待ち時間が合理的な水準にULPのエンドツーエンドのレイテンシを保つために短いとき、アルゴリズムは、このように小さなセグメントが可能になります。
The Nagle algorithm is not mandatory to use [RFC1122].
Nagleアルゴリズムは、[RFC1122]を使用することは必須ではありません。
When used with optimized MPA/TCP stacks, Nagle and similar algorithms can result in the "packing" of multiple FPDUs into TCP segments.
最適化されたMPA / TCPスタックと共に使用される場合、ネーグルと同様のアルゴリズムは、TCPセグメントに複数のFPDUsの「パッキング」をもたらすことができます。
If a "message tail", small DDP messages, or the start of a larger DDP message are available, MPA may pack multiple FPDUs into TCP segments. When this is done, the TCP segments can be more fully utilized, but, due to the size constraints of FPDUs, segments may not be filled to the EMSS. A dynamic MULPDU that informs DDP of the size of the remaining TCP segment space makes filling the TCP segment more effective.
「メッセージテール」、小さなDDPメッセージ、またはより大きなDDPメッセージの開始が利用可能な場合は、MPAは、TCPセグメントに複数のFPDUsを詰めることがあります。これが行われるとき、TCPセグメントがより完全に利用される、しかし、のFPDUsのサイズの制約に起因することができ、セグメントはエムスに充填されなくてもよいです。残りのTCPセグメント空間の大きさDDPを通知動的MULPDUは、TCPセグメントがより効果的に充填することができます。
Note that MPA receivers do more processing of a TCP segment that
contains multiple FPDUs; this may affect the performance of some
receiver implementations.
It is up to the ULP to decide if Nagle is useful with DDP/MPA. Note that many of the applications expected to take advantage of MPA/DDP prefer to avoid the extra delays caused by Nagle. In such scenarios, it is anticipated there will be minimal opportunity for packing at the transmitter and receivers may choose to optimize their performance for this anticipated behavior.
それはネーグルはDDP / MPAで有用かどうかを判断するためにULP次第です。 MPA / DDPを利用することが期待アプリケーションの多くは、ネーグルによって引き起こされる余分な遅延を回避することを好むことに注意してください。このようなシナリオでは、この予想される動作のために彼らのパフォーマンスを最適化することもできます送信機と受信機で包装のための最小限の機会があるだろう期待されています。
Therefore, the application is expected to set TCP parameters such that it can trade off latency and wire efficiency. Implementations should provide a connection option that disables Nagle for MPA/TCP similar to the way the TCP_NODELAY socket option is provided for a traditional sockets interface.
したがって、アプリケーションは、それが待ち時間とワイヤ効率をトレードオフすることができるようにTCPパラメータを設定することが期待されます。実装はTCP_NODELAYソケットオプションは、伝統的なソケットインタフェースのために提供される方法に類似したMPA / TCPのNagleを無効にする接続オプションを提供する必要があります。
When latency is not critical, application is expected to leave Nagle enabled. In this case, the TCP implementation may pack any available FPDUs into TCP segments so that the segments are filled to the EMSS. If the amount of data available is not enough to fill the TCP segment when it is prepared for transmission, TCP can send the segment partly filled, or use the Nagle algorithm to wait for the ULP to post more data.
待ち時間が重要ではない場合は、アプリケーションはネーグルを有効にしておくことが予想されます。セグメントはエムスに充填されているように、この場合には、TCPの実装では、TCPセグメントに利用可能な任意のFPDUsをパックしてもよいです。利用可能なデータの量は、それが伝送のために準備されたときにTCPセグメントを満たすのに十分でない場合、TCPは、部分的に満たされたセグメントを送ったり、より多くのデータを投稿するULPを待つためにNagleアルゴリズムを使用することができます。
A.3. Optimized MPA/TCP Receivers
A.3。最適化されたMPA / TCPレシーバ
When an MPA receive implementation and the MPA-aware receive side TCP implementation support handling out-of-order ULPDUs, the TCP receive implementation performs the following functions:
MPAは、実装を受け取り、MPA-を意識するとアウトオブオーダーULPDUs取り扱い側TCPの実装のサポートを受け、TCPは、実装は次の機能を実行受信：
1) The implementation passes incoming TCP segments to MPA as soon as they have been received and validated, even if not received in order. The TCP layer commits to keeping each segment before it can be passed to the MPA. This means that the segment must have passed the TCP, IP, and lower layer data integrity validation (i.e., checksum), must be in the receive window, must be part of the same epoch (if timestamps are used to verify this), and must have passed any other checks required by TCP RFCs.
1）実装は、すぐに彼らは順番に受信されない場合でも、受信および検証されているようMPAへの着信TCPセグメントを渡します。 TCP層は、それがMPAに渡すことができる前に、各セグメントを維持するにコミットします。 （タイムスタンプは、これを検証するために使用されている場合）、このセグメントは、TCP、IP、および下位レイヤデータの整合性の検証（すなわち、チェックサム）を合格していなければならないことを意味し、受信ウィンドウ内にある必要があり、同じエポックの一部でなければならない、とTCP RFCで必要な任意の他のチェックに合格している必要があります。
This is not to imply that the data must be completely ordered
before use. An implementation can accept out-of-order segments,
SACK them [RFC2018], and pass them to MPA immediately, before the
reception of the segments needed to fill in the gaps. MPA
expects to utilize these segments when they are complete FPDUs or
can be combined into complete FPDUs to allow the passing of
ULPDUs to DDP when they arrive, independent of ordering. DDP
uses the passed ULPDU to "place" the DDP segments (see [DDP] for
more details).
Since MPA performs a CRC calculation and other checks on received FPDUs, the MPA/TCP implementation ensures that any TCP segments that duplicate data already received and processed (as can happen during TCP retries) do not overwrite already received and processed FPDUs. This avoids the possibility that duplicate data may corrupt already validated FPDUs.
MPAは、CRC計算および受信のFPDUsに他のチェックを実行するので、MPA / TCPの実装では、既に受信され（TCP再試行中に発生することができたように）処理されたデータを複製する任意のTCPセグメントが受信済みとのFPDUsを処理上書きしないことを保証します。これは、データが破損しているすでにのFPDUsを検証して複製する可能性を回避します。
2) The implementation provides a mechanism to indicate the ordering of TCP segments as the sender transmitted them. One possible mechanism might be attaching the TCP sequence number to each segment.
2）実装では、送信者がそれらを送信としてTCPセグメントの順序を示すための機構を提供します。一つの可能なメカニズムは、各セグメントにTCPシーケンス番号を付けることがあります。
3) The implementation also provides a mechanism to indicate when a given TCP segment (and the prior TCP stream) is complete. One possible mechanism might be to utilize the leading (left) edge of the TCP Receive Window.
3）実装はまた、所与のTCPセグメント（前TCPストリーム）が完了したときを示すための機構を提供します。一つの可能なメカニズムは、TCP受信ウィンドウの（左）リーディングエッジを利用するかもしれません。
MPA uses the ordering and completion indications to inform DDP
when a ULPDU is complete; MPA Delivers the FPDU to DDP. DDP uses
the indications to "deliver" its messages to the DDP consumer
(see [DDP] for more details).
DDP on MPA utilizes the above two mechanisms to establish the Delivery semantics that DDP's consumers agree to. These semantics are described fully in [DDP]. These include requirements on DDP's consumer to respect ownership of buffers prior to the time that DDP delivers them to the Consumer.
MPAにDDPは、DDPの消費者は、に同意配信セマンティクスを確立するために、上記の2つのメカニズムを利用しています。これらのセマンティクスは[DDP]で完全に記述されています。これらは、DDPの消費者の要件はDDPが消費者に配信時間前にバッファの所有権を尊重することを含んでいます。
The use of SACK [RFC2018] significantly improves network utilization and performance and is therefore recommended. When combined with the out-of-order passing of segments to MPA and DDP, significant buffering and copying of received data can be avoided.
SACK [RFC2018]の使用が大幅にネットワーク使用率とパフォーマンスを向上させ、したがって、推奨されます。 MPAとDDPセグメントへのアウトオブオーダ通過と組み合わせた場合、有意なバッファリングと、受信したデータのコピーを回避することができます。
A.4. Re-Segmenting Middleboxes and Non-Optimized MPA/TCP Senders
A.4。再セグメント化のMiddleboxesと非最適化されたMPA / TCP送信者
Since MPA senders often start FPDUs on TCP segment boundaries, a receiving optimized MPA/TCP implementation may be able to optimize the reception of data in various ways.
MPAの送信者は、しばしば、TCPセグメント境界上のFPDUsを開始するので、受信最適化されたMPA / TCPの実装は、様々な方法でデータの受信を最適化することができるかもしれません。
However, MPA receivers MUST NOT depend on FPDU Alignment on TCP segment boundaries.
しかし、MPA受信機はTCPセグメント境界でFPDU整列に依存してはなりません。
Some MPA senders may be unable to conform to the sender requirements because their implementation of TCP is not designed with MPA in mind. Even for optimized MPA/TCP senders, the network may contain "middleboxes" which modify the TCP stream by changing the segmentation. This is generally interoperable with TCP and its users and MPA must be no exception.
TCPのそれらの実装は、心の中でMPAに設計されていないため、一部のMPAの送信者は送信者の要件に適合できない場合があります。でも、最適化されたMPA / TCPの送信者のために、ネットワークは、セグメンテーションを変更することにより、TCPストリームを変更する「ミドルボックス」を含んでいてもよいです。これは例外である必要があります一般的にTCPおよびそのユーザーとMPAとの相互運用が可能です。
The presence of Markers in MPA (when enabled) allows an optimized MPA/TCP receiver to recover the FPDUs despite these obstacles, although it may be necessary to utilize additional buffering at the receiver to do so.
そうする受信機で追加のバッファリングを利用することが必要かもしれないが（有効）MPAにおけるマーカーの存在は、これらの障害にもかかわらずのFPDUsを回復するために最適化されたMPA / TCP受信を可能にします。
Some of the cases that a receiver may have to contend with are listed below as a reminder to the implementer:
受信機は、実装者へのメモとして以下に列挙されていると競合しなければならないことがいくつかの例：
* A single aligned and complete FPDU, either in order or out of order: This can be passed to DDP as soon as validated, and Delivered when ordering is established.
*シングル整列し、完全なFPDUを、順番にまたは秩序のうちいずれか：これは、すぐに検証としてDDPに渡され、注文が確定されたときに配信することができます。
* Multiple FPDUs in a TCP segment, aligned and fully contained, either in order or out of order: These can be passed to DDP as soon as validated, and Delivered when ordering is established.
これらは、すぐに検証としてDDPに渡され、注文が確定されたときに配信することができます：TCPセグメント、整列し、完全に含まれる、順番にまたは秩序のうちのいずれかで*複数のFPDUs。
* Incomplete FPDU: The receiver should buffer until the remainder of the FPDU arrives. If the remainder of the FPDU is already available, this can be passed to DDP as soon as validated, and Delivered when ordering is established.
*不完全FPDU：FPDUの残りが到着するまで受信機はバッファべきです。 FPDUの残りの部分はすでに利用可能である場合、これはすぐに検証としてDDPに渡すことができ、かつ秩序が確立されたときにお届けします。
* Unaligned FPDU start: The partial FPDU must be combined with its preceding portion(s). If the preceding parts are already available, and the whole FPDU is present, this can be passed to DDP as soon as validated, and Delivered when ordering is established. If the whole FPDU is not available, the receiver should buffer until the remainder of the FPDU arrives.
*アンアラインドFPDUが開始：部分FPDUは、その前の部分（単数または複数）と組み合わされなければなりません。前の部分はすでに利用可能であり、全体のFPDUが存在する場合、これはすぐに検証としてDDPに渡すことができ、かつ確立されたご注文時にお届けします。全体FPDUが利用できない場合FPDUの残りが到着するまで、受信機バッファべきです。
* Combinations of unaligned or incomplete FPDUs (and potentially other complete FPDUs) in the same TCP segment: If any FPDU is present in its entirety, or can be completed with portions already available, it can be passed to DDP as soon as validated, and Delivered when ordering is established.
*同じTCPセグメントにアラインされていないまたは不完全のFPDUs（及び潜在的に他の完全のFPDUs）の組み合わせ：任意FPDUは、その全体に存在する、または既に利用可能な部分で完了することができる場合、それは、すぐに検証としてDDPに渡すことができ、そして順序付けが確立されたときにお届けします。
A.5. Receiver Implementation
A.5。レシーバの実装
Transport & Network Layer Reassembly Buffers:
トランスポート＆ネットワーク層リアセンブリ・バッファ：
The use of reassembly buffers (either TCP reassembly buffers or IP fragmentation reassembly buffers) is implementation dependent. When MPA is enabled, reassembly buffers are needed if out-of-order packets arrive and Markers are not enabled. Buffers are also needed if FPDU alignment is lost or if IP fragmentation occurs. This is because the incoming out-of-order segment may not contain enough information for MPA to process all of the FPDU. For cases where a re-segmenting middlebox is present, or where the TCP sender is not optimized, the presence of Markers significantly reduces the amount of buffering needed.
再組み立てバッファ（TCP再組み立てバッファまたはIPフラグメンテーション再構築バッファのいずれか）の使用は実装依存です。 MPAが有効になっている場合はアウトオブオーダーパケットが到着し、マーカーが有効化されていない場合は、再組み立てバッファが必要とされています。 FPDU整列が失われた場合やIPフラグメンテーションが発生した場合、バッファも必要とされています。着信アウト・オブ・オーダのセグメントがMPAはFPDUのすべてを処理するための十分な情報が含まれていない可能性があるためです。再セグメント化するミドルが存在している、またはTCPの送信者が最適化されていない場合は、マーカーの存在は大幅に必要なバッファリングの量を減らすための例。
Recovery from IP fragmentation is transparent to the MPA Consumers.
IPフラグメンテーションからの回復はMPA消費者に対して透過的です。
A.5.1 Network Layer Reassembly Buffers
A.5.1ネットワーク層リアセンブリ・バッファ
The MPA/TCP implementation should set the IP Don't Fragment bit at the IP layer. Thus, upon a path MTU change, intermediate devices drop the IP datagram if it is too large and reply with an ICMP message that tells the source TCP that the path MTU has changed. This causes TCP to emit segments conformant with the new path MTU size. Thus, IP fragments under most conditions should never occur at the receiver. But it is possible.
MPA / TCPの実装では、IP層でビットを断片化しないIPを設定する必要があります。したがって、それが大きすぎる場合は、パスMTUの変更時に、中間デバイスは、IPデータグラムをドロップし、パスMTUが変更されたソースTCPを告げるICMPメッセージで返信。これは、新しいパスMTUサイズに準拠したセグメントを放出するTCPの原因となります。このように、ほとんどの条件の下でIPフラグメントは、受信機で発生することはありません。しかし、それは可能です。
There are several options for implementation of network layer reassembly buffers:
ネットワーク層の再組み立てバッファの実装のためのいくつかのオプションがあります。
1. drop any IP fragments, and reply with an ICMP message according to [RFC792] (fragmentation needed and DF set) to tell the Remote Peer to resize its TCP segment.
1.任意のIPフラグメントをドロップし、そのTCPセグメントのサイズを変更するリモートピアに通知するために、[RFC792]（フラグメンテーション必要とDFセット）に応じてICMPメッセージで返信。
2. support an IP reassembly buffer, but have it of limited size (possibly the same size as the local link's MTU). The end node would normally never Advertise a path MTU larger than the local link MTU. It is recommended that a dropped IP fragment cause an ICMP message to be generated according to RFC 792.
2. IP再組み立てバッファをサポートしていますが、限られたサイズ（ローカルリンクのMTUとしておそらく同じサイズ）のそれを持っています。エンド・ノードは、通常、ローカルリンクMTUよりも大きなパスMTUを宣伝することはありません。ドロップされたIPフラグメントは、RFC 792に応じて生成されるICMPメッセージを引き起こすことをお勧めします。
4. support an IP reassembly buffer for the largest IP datagram (64 KB).
4.最大IPデータグラム（64キロバイト）のためのIP再アセンブリバッファをサポートします。
5. support for a large IP reassembly buffer that could span multiple IP datagrams.
複数のIPデータグラムをまたがることができ、大きなIP組立バッファ5.サポート。
An implementation should support at least 2 or 3 above, to avoid dropping packets that have traversed the entire fabric.
実装は、ファブリック全体を横断したパケットを落とさないように、上記少なくとも2つまたは3つをサポートしなければなりません。
There is no end-to-end ACK for IP reassembly buffers, so there is no flow control on the buffer. The only end-to-end ACK is a TCP ACK, which can only occur when a complete IP datagram is delivered to TCP. Because of this, under worst case, pathological scenarios, the largest IP reassembly buffer is the TCP receive window (to buffer multiple IP datagrams that have all been fragmented).
IP再組み立てバッファのためのエンドツーエンドのACKはありませんので、バッファには、フロー制御はありません。唯一のエンド・ツー・エンドのACKは、完全なIPデータグラムがTCPに配信されている場合にのみ発生する可能性がTCP ACK、です。このため、最悪の場合、病理学的なシナリオの下で、最大のIP再アセンブリバッファは、TCPウィンドウを受け取る（すべての断片化された複数のIPデータグラムをバッファリングする）です。
Note that if the Remote Peer does not implement re-segmentation of the data stream upon receiving the ICMP reply updating the path MTU, it is possible to halt forward progress because the opposite peer would continue to retransmit using a transport segment size that is too large. This deadlock scenario is no different than if the fabric MTU (not last-hop MTU) was reduced after connection setup, and the remote node's behavior is not compliant with [RFC1122].
パスMTUを更新返信リモートピアがICMPを受信すると、データストリームの再分割を実装していない場合は反対側のピアが大きすぎる輸送セグメントサイズを使用して再送信し続けるので、前進を停止することが可能であることに注意してください。このデッドロックのシナリオは違いはありません生地のMTU（いない最後のホップMTU）は接続設定後に減少、およびリモートノードの動作は、[RFC1122]に準拠していないされた場合よりも。
A.5.2 TCP Reassembly Buffers
A.5.2 TCPリアセンブリ・バッファ
A TCP reassembly buffer is also needed. TCP reassembly buffers are needed if FPDU Alignment is lost when using TCP with MPA or when the MPA FPDU spans multiple TCP segments. Buffers are also needed if Markers are disabled and out-of-order packets arrive.
TCP再組み立てバッファも必要とされています。 MPAとき、またはMPA FPDUが複数のTCPセグメントにまたがるとTCPを使用した場合FPDU整列が失われた場合、TCP再組み立てバッファが必要とされています。マーカーが無効になっているとアウトオブオーダーパケットが到着した場合、バッファも必要とされています。
Since lost FPDU Alignment often means that FPDUs are incomplete, an MPA on TCP implementation must have a reassembly buffer large enough to recover an FPDU that is less than or equal to the MTU of the locally attached link (this should be the largest possible Advertised TCP path MTU). If the MTU is smaller than 140 octets, a buffer of at least 140 octets long is needed to support the minimum FPDU size. The 140 octets allow for the minimum MULPDU of 128, 2 octets of pad, 2 of ULPDU_Length, 4 of CRC, and space for a possible Marker. As usual, additional buffering is likely to provide better performance.
FPDU整列を失ったので、多くの場合のFPDUsが不完全であることを、TCPの実装上のMPAが、以下、これは可能な最大アドバタイズTCPでなければなりません（ローカルに接続されたリンクのMTUに等しいFPDUを回復するのに十分な大き組立バッファを持たなければならないことを意味しますパスMTU）。 MTUが140オクテットよりも小さい場合には、少なくとも140オクテットのバッファは、長い最小FPDUサイズをサポートするために必要とされます。 140個のオクテットが可能マーカーの最小パッド128、2オクテットULPDU_Lengthの2、CRCの4のMULPDU、及び空間を可能にします。いつものように、追加のバッファリングは、より優れたパフォーマンスを提供する可能性があります。
Note that if the TCP segments were not stored, it would be possible to deadlock the MPA algorithm. If the path MTU is reduced, FPDU Alignment requires the source TCP to re-segment the data stream to the new path MTU. The source MPA will detect this condition and reduce the MPA segment size, but any FPDUs already posted to the source TCP will be re-segmented and lose FPDU Alignment. If the destination does not support a TCP reassembly buffer, these segments can never be successfully transmitted and the protocol deadlocks.
TCPセグメントが格納されていなかったならば、MPAアルゴリズムをデッドロックすることが可能であることに注意してください。パスMTUを小さくすると、FPDUアライメントは、新しいパスMTUへの再セグメントのデータストリームにソースTCPが必要です。ソースMPAは、この状態を検出し、MPAセグメントのサイズを小さくするが、任意のFPDUsはすでに再セグメント化され、FPDU整列を失うことになりますソースTCPに掲載されます。宛先はTCP再アセンブリバッファをサポートしていない場合は、これらのセグメントが正常に送信されないと、プロトコルのデッドロックすることができません。
When a complete FPDU is received, processing continues normally.
完全なFPDUが受信されると、処理が正常に継続します。
Appendix B. Analysis of MPA over TCP Operations
TCPオペレーションを超えるMPAの付録B.分析
This appendix is for information only and is NOT part of the standard.
この付録では、情報提供のみを目的と標準の一部ではありません。
This appendix is an analysis of MPA on TCP and why it is useful to integrate MPA with TCP (with modifications to typical TCP implementations) to reduce overall system buffering and overhead.
この付録では、TCP上のMPAの分析であり、なぜシステム全体のバッファリングとオーバーヘッドを減らすために（典型的TCPの実装に変更を加えて）TCPとMPAを統合するのに有用です。
One of MPA's high-level goals is to provide enough information, when combined with the Direct Data Placement Protocol [DDP], to enable out-of-order placement of DDP payload into the final Upper Layer Protocol (ULP) Buffer. Note that DDP separates the act of placing data into a ULP Buffer from that of notifying the ULP that the ULP Buffer is available for use. In DDP terminology, the former is defined as "Placement", and the later is defined as "Delivery". MPA supports in-order Delivery of the data to the ULP, including support for Direct Data Placement in the final ULP Buffer location when TCP segments arrive out of order. Effectively, the goal is to use the pre-posted ULP Buffers as the TCP receive buffer, where the reassembly of the ULP Protocol Data Unit (PDU) by TCP (with MPA and DDP) is done in place, in the ULP Buffer, with no data copies.
MPAの高レベルの目標の一つは、直接データプレースメントプロトコル[DDP]と組み合わせた場合、最終的な上位層プロトコル（ULP）バッファにDDPペイロードのアウト・オブ・オーダの配置を可能にするために、十分な情報を提供することです。 DDPはULPバッファが使用可能であることをULPに通知することからULPバッファにデータを配置する動作を分離することに留意されたいです。 DDP用語では、前者は「配置」と定義され、以降は「配達」と定義されます。 MPAは、TCPセグメントは順序が狂って到着最終ULPバッファロケーションに直接データを配置するためのサポートを含むULPへのデータのインオーダー配信をサポート。効果的に、目標は、（MPAとDDP付き）TCPによるULPプロトコルデータユニット（PDU）の再組み立てをして、ULPバッファーで、場所で行われているバッファを、TCP受信として前投稿ULPバッファを使用することです何のデータをコピーしません。
This appendix walks through the advantages and disadvantages of the TCP sender modifications proposed by MPA:
この付録では、MPAによって提案されたTCPの送信者変更の利点と欠点をウォークスルー：
1) that MPA prefers that the TCP sender to do Header Alignment, where a TCP segment should begin with an MPA Framing Protocol Data Unit (FPDU) (if there is payload present).
1）MPAは、TCP送信者）は、ペイロードが存在する場合は、TCPセグメントが（MPAフレーミングプロトコルデータユニット（FPDU）で始まるべきヘッダアライメント、実行することを好むこと。
2) that there be an integral number of FPDUs in a TCP segment (under conditions where the path MTU is not changing).
2）のFPDUsの整数パスMTUが変更されない条件下で、TCPセグメント（）内に存在すること。
This appendix concludes that the scaling advantages of FPDU Alignment are strong, based primarily on fairly drastic TCP receive buffer reduction requirements and simplified receive handling. The analysis also shows that there is little effect to TCP wire behavior.
この付録では、FPDU整列のスケーリング利点は主に、かなり思い切ったTCPに基づいて、強いバッファ削減要求を受信し、単純化されたハンドリング受けると結論づけています。分析はまた、TCPのワイヤ動作にはほとんど影響があることを示しています。
B.1. Assumptions
B.1。仮定
B.1.1 MPA Is Layered beneath DDP
B.1.1 MPAは、DDPの下に積層されています
MPA is an adaptation layer between DDP and TCP. DDP requires preservation of DDP segment boundaries and a CRC32c digest covering the DDP header and data. MPA adds these features to the TCP stream so that DDP over TCP has the same basic properties as DDP over SCTP.
MPAは、DDPとTCPの間にアダプテーション層です。 DDPは、DDPセグメント境界とDDPヘッダとデータをカバーCRC32Cダイジェストの保存を必要とします。 TCP経由DDPはSCTPを超えるDDPと同じ基本的な性質を持つようにMPAは、TCPストリームにこれらの機能が追加されます。
B.1.2. MPA Preserves DDP Message Framing
B.1.2。 MPAは、DDPメッセージフレーミングを保持します
MPA was designed as a framing layer specifically for DDP and was not intended as a general-purpose framing layer for any other ULP using TCP.
MPAは、特にDDPのためのフレーミング層として設計し、TCPを使用して、他のULPのための汎用フレーミング層として意図されていませんでした。
A framing layer allows ULPs using it to receive indications from the transport layer only when complete ULPDUs are present. As a framing layer, MPA is not aware of the content of the DDP PDU, only that it has received and, if necessary, reassembled a complete PDU for Delivery to the DDP.
フレーミング層のULPが完了ULPDUsが存在する場合にのみ、トランスポート層からの指示を受信するためにそれを使用可能にします。フレーミング層としては、MPAは、DDPへの配信のための完全なPDUを再組み立てに必要な場合には、受信しただけで、DDP PDUの内容を認識していません。
B.1.3. The Size of the ULPDU Passed to MPA Is Less Than EMSS under Normal Conditions
B.1.3。 MPAに渡さULPDUのサイズは、通常の条件下でエムスよりも少ないです
To make reception of a complete DDP PDU on every received segment possible, DDP passes to MPA a PDU that is no larger than the EMSS of the underlying fabric. Each FPDU that MPA creates contains sufficient information for the receiver to directly place the ULP payload in the correct location in the correct receive buffer.
可能なすべての受信セグメントに完全なDDP PDUの受信を行うために、DDPは、MPAに下地織物のエムスより大きくないPDUを渡します。 MPAが作成する各FPDU直接受信バッファ正確に正しい位置にULPペイロードを配置するための受信機のための十分な情報を含みます。
Edge cases when this condition does not occur are dealt with, but do not need to be on the fast path.
この状態が発生していないエッジケースを扱っているが、高速パス上にある必要はありません。
B.1.4. Out-of-Order Placement but NO Out-of-Order Delivery
B.1.4。アウト・オブ・オーダー配置が、NOアウトオブオーダー配信
DDP receives complete DDP PDUs from MPA. Each DDP PDU contains the information necessary to place its ULP payload directly in the correct location in host memory.
DDPは、MPAから完全なDDP PDUを受け取ります。各DDP PDUは、ホスト・メモリ内の正しい位置に直接そのULPペイロードを配置するのに必要な情報を含みます。
Because each DDP segment is self-describing, it is possible for DDP segments received out of order to have their ULP payload placed immediately in the ULP receive buffer.
各DDPセグメントが自己記述型であるので、DDPセグメントが順序から外れて受信されたそれらのULPペイロードは直ちにULPに置か受信バッファ有することが可能です。
Data delivery to the ULP is guaranteed to be in the order the data was sent. DDP only indicates data delivery to the ULP after TCP has acknowledged the complete byte stream.
ULPへのデータの配信は、データが送信された順序であることが保証されます。 TCPは、完全なバイトストリームを認めた後にDDPはULPへのデータ配信を示しています。
B.2. The Value of FPDU Alignment
B.2。 FPDU整列の値
Significant receiver optimizations can be achieved when Header Alignment and complete FPDUs are the common case. The optimizations allow utilizing significantly fewer buffers on the receiver and less computation per FPDU. The net effect is the ability to build a "flow-through" receiver that enables TCP-based solutions to scale to 10G and beyond in an economical way. The optimizations are especially relevant to hardware implementations of receivers that process multiple protocol layers -- Data Link Layer (e.g., Ethernet), Network and Transport Layer (e.g., TCP/IP), and even some ULP on top of TCP (e.g., MPA/DDP). As network speed increases, there is an increasing desire to use a hardware-based receiver in order to achieve an efficient high performance solution.
ヘッダ配置と完全のFPDUsは一般的なケースである場合に有意な受信機の最適化を実現することができます。最適化は、受信機とFPDUあたり少ない計算に有意に少ないバッファを利用することができます。正味の効果は、経済的な方法で10Gにし、超えて拡張するTCPベースのソリューションを可能にし、「フロースルー」受信機を構築する能力です。 TCP（例えば、MPAの上のデータリンク層（例えば、イーサネット）、ネットワークとトランスポート層（例えば、TCP / IP）、さらにいくつかULP - 最適化は、複数のプロトコル層を処理する受信機のハードウェア実装に特に関連しています/ DDP）。ネットワークの速度が増加すると、効率的な高性能ソリューションを達成するために、ハードウェアベースの受信機を使用するための増加が望まれています。
A TCP receiver, under worst-case conditions, has to allocate buffers (BufferSizeTCP) whose capacities are a function of the bandwidth-delay product. Thus:
TCP受信機は、最悪の場合の条件の下で、その容量帯域幅遅延積の関数であるバッファ（BufferSizeTCP）を割り当てなければなりません。したがって
BufferSizeTCP = K * bandwidth [octets/second] * Delay [seconds].
BufferSizeTCP = Kの*帯域幅[オクテット/秒] *ディレイ[秒]。
Where bandwidth is the end-to-end bandwidth of the connection, delay is the round-trip delay of the connection, and K is an implementation-dependent constant.
帯域幅は、接続のエンドツーエンドの帯域幅である場合、遅延は、接続の往復遅延であり、Kは実装依存の定数です。
Thus, BufferSizeTCP scales with the end-to-end bandwidth (10x more buffers for a 10x increase in end-to-end bandwidth). As this buffering approach may scale poorly for hardware or software implementations alike, several approaches allow reduction in the amount of buffering required for high-speed TCP communication.
したがって、BufferSizeTCPは、エンドツーエンドの帯域幅（エンド・ツー・エンドの帯域幅で10倍増加の10倍以上のバッファ）に比例します。このバッファリングアプローチは同様のハードウェアまたはソフトウェア実装のために不十分スケーリングすることができるように、いくつかのアプローチは、高速TCP通信に必要なバッファリングの量の減少を可能にします。
The MPA/DDP approach is to enable the ULP's Buffer to be used as the TCP receive buffer. If the application pre-posts a sufficient amount of buffering, and each TCP segment has sufficient information to place the payload into the right application buffer, when an out-of-order TCP segment arrives it could potentially be placed directly in the ULP Buffer. However, placement can only be done when a complete FPDU with the placement information is available to the receiver, and the FPDU contents contain enough information to place the data into the correct ULP Buffer (e.g., there is a DDP header available).
MPA / DDPアプローチは、TCP受信バッファとして使用するULPのバッファを可能にすることです。アプリケーションプリポストバッファリングのに十分な量、及び各TCPセグメントが正しいアプリケーションバッファにペイロードを配置するのに十分な情報を持っている場合、アウト・オブ・オーダのTCPセグメントが到着したとき、それは潜在的にULPバッファ内に直接配置することができます。配置情報との完全なFPDUが受信機に利用可能であり、FPDU内容（例えば、使用可能DDPヘッダが存在する）正しいULPバッファにデータを配置するための十分な情報が含まれている場合しかし、配置のみを行うことができます。
For the case when the FPDU is not aligned with the TCP segment, it may take, on average, 2 TCP segments to assemble one FPDU. Therefore, the receiver has to allocate BufferSizeNAF (Buffer Size, Non-Aligned FPDU) octets:
FPDUがTCPセグメントと整列していない場合のために、これは、1つのFPDUを組み立てるために、平均して、2つのTCPセグメントをとることができます。したがって、受信機はBufferSizeNAF（バッファサイズ、非同盟FPDU）オクテットを割り当てなければなりません。
BufferSizeNAF = K1* EMSS * number_of_connections + K2 * EMSS
BufferSizeNAF = K1 *エムス* NUMBER_OF_CONNECTIONS + K2の*のエムス
Where K1 and K2 are implementation-dependent constants and EMSS is the effective maximum segment size.
ここで、K1およびK2は実装依存定数であり、エムスは、効果的な最大セグメントサイズです。
For example, a 1 GB/sec link with 10,000 connections and an EMSS of 1500 B would require 15 MB of memory. Often the number of connections used scales with the network speed, aggravating the situation for higher speeds.
たとえば10,000接続を有する1ギガバイト/秒のリンク1500 Bのエムスは、メモリの15メガバイトを必要とするであろう。多くの場合、接続の数は、高速化のために、状況を悪化させ、ネットワーク速度とスケールを使用しました。
FPDU Alignment would allow the receiver to allocate BufferSizeAF (Buffer Size, Aligned FPDU) octets:
FPDU整列は、受信機がBufferSizeAF（バッファサイズ、配向FPDU）オクテットを割り当てることができるようになります。
BufferSizeAF = K2 * EMSS
BufferSizeAF = K2の*のエムス
for the same conditions. An FPDU Aligned receiver may require memory in the range of ~100s of KB -- which is feasible for an on-chip memory and enables a "flow-through" design, in which the data flows through the network interface card (NIC) and is placed directly in the destination buffer. Assuming most of the connections support FPDU Alignment, the receiver buffers no longer scale with number of connections.
同じ条件のため。オンチップメモリのための実現可能であり、データは、ネットワークインタフェースカード（NIC）とを通って流れる「フロースルー」設計を可能にする - FPDU配向受信機は〜KBの100Sの範囲のメモリを必要とするかもしれません宛先バッファに直接配置されています。接続の想定すると、ほとんどはFPDU整列、接続数と受信バッファもはや規模をサポートしています。
Additional optimizations can be achieved in a balanced I/O sub-system -- where the system interface of the network controller provides ample bandwidth as compared with the network bandwidth. For almost twenty years this has been the case and the trend is expected to continue. While Ethernet speeds have scaled by 1000 (from 10 megabit/sec to 10 gigabit/sec), I/O bus bandwidth of volume CPU architectures has scaled from ~2 MB/sec to ~2 GB/sec (PC-XT bus to PCI-X DDR). Under these conditions, the FPDU Alignment approach allows BufferSizeAF to be indifferent to network speed. It is primarily a function of the local processing time for a given frame.
ネットワークコントローラのシステム・インタフェースは、ネットワーク帯域幅と比較して、十分な帯域幅を提供 - 追加の最適化は、バランスのとれたI / Oサブシステムで達成することができます。ほぼ20年間、これはそうなっていると傾向が続くと予想されます。イーサネット速度が（10メガビット/秒から10ギガビット/秒）1000でスケーリングしているが、ボリュームのCPUアーキテクチャのI / Oバス帯域幅はPCIに約2 GB /秒（PC-XTバスに約2 MB /秒からスケーリングしています-X DDR）。これらの条件下で、FPDU整列のアプローチはBufferSizeAFは、ネットワークの速度に無関心にすることができます。これは主に、所与のフレームのためのローカル処理時間の関数です。
Thus, when the FPDU Alignment approach is used, receive buffering is expected to scale gracefully (i.e., less than linear scaling) as network speed is increased.
したがって、FPDU整列アプローチを使用した場合、バッファリングが正常に拡張することが期待される受信（すなわち、線形スケーリング未満）ネットワークの速度などを増加させます。
B.2.1. Impact of Lack of FPDU Alignment on the Receiver Computational Load and Complexity
B.2.1。レシーバ計算負荷と複雑さにFPDU整列の不足の影響
The receiver must perform IP and TCP processing, and then perform FPDU CRC checks, before it can trust the FPDU header placement information. For simplicity of the description, the assumption is that an FPDU is carried in no more than 2 TCP segments. In reality, with no FPDU Alignment, an FPDU can be carried by more than 2 TCP segments (e.g., if the path MTU was reduced).
それはFPDUヘッダ配置情報を信頼する前に、受信機は、IPおよびTCP処理を実行し、FPDU CRCチェックを実行しなければなりません。説明を簡単にするため、仮定はFPDUがない2つの以上のTCPセグメントで運ばれることです。 （経路MTUが減少した場合、例えば、）実際には、無FPDU整列で、FPDUは、2つの以上のTCPセグメントによって実施することができます。
----++-----------------------------++-----------------------++-----
+---||---------------+ +--------||--------+ +----------||----+
| TCP Seg X-1 | | TCP Seg X | | TCP Seg X+1 |
+---||---------------+ +--------||--------+ +----------||----+
----++-----------------------------++-----------------------++-----
FPDU #N-1 FPDU #N
Figure 12: Non-Aligned FPDU Freely Placed in TCP Octet Stream
図12：自由にTCPオクテットストリームに置い非同盟FPDU
The receiver algorithm for processing TCP segments (e.g., TCP segment #X in Figure 12) carrying non-aligned FPDUs (in order or out of order) includes:
（順番に又は順不同）TCPセグメントを処理するための受信機のアルゴリズム（例えば、図12のTCPセグメント#X）を有する非整列のFPDUsを含みます：
Data Link Layer processing (whole frame) -- typically including a CRC calculation.
データリンク層処理（フレーム全体） - 通常、CRCの計算を含みます。
1. Network Layer processing (assuming not an IP fragment, the
whole Data Link Layer frame contains one IP datagram. IP
fragments should be reassembled in a local buffer. This is
not a performance optimization goal.)
2. Transport Layer processing -- TCP protocol processing, header and checksum checks.
2.トランスポート層処理 - TCPプロトコル処理、ヘッダとチェックサムをチェックします。
a. Classify incoming TCP segment using the 5 tuple (IP SRC,
IP DST, TCP SRC Port, TCP DST Port, protocol).
a. Get MPA state information for the connection.
A。接続のためのMPAの状態情報を取得します。
If the TCP segment is in order, use the receiver-managed
MPA state information to calculate where the previous
FPDU message (#N-1) ends in the current TCP segment X.
(previously, when the MPA receiver processed the first
part of FPDU #N-1, it calculated the number of bytes
remaining to complete FPDU #N-1 by using the MPA Length
field).
Get the stored partial CRC for FPDU #N-1.
FPDU＃N-1のために保存された部分CRCを取得します。
Complete CRC calculation for FPDU #N-1 data (first portion of TCP segment #X).
FPDU＃N-1のデータのための完全なCRC計算（TCPセグメント#Xの最初の部分）。
Check CRC calculation for FPDU #N-1.
FPDU＃N-1のためのCRC計算を確認してください。
If no FPDU CRC errors, placement is allowed.
無FPDU CRCエラー場合は、配置が許可されます。
Locate the local buffer for the first portion of FPDU#N-1, CopyData(local buffer of first portion of FPDU #N-1, host buffer address, length).
FPDU＃N-1の最初の部分のためのローカルバッファを見つけ、のCopyData（FPDU＃N-1の最初の部分のローカルバッファ、ホストバッファアドレス、長さ）。
Compute host buffer address for second portion of FPDU #N-1.
FPDU＃N-1の第2の部分のためのホストバッファアドレスを計算します。
CopyData (local buffer of second portion of FPDU #N-1, host buffer address for second portion, length).
CopyData（FPDU＃N-1、第二の部分のためのホストバッファアドレス、長さの第二の部分のローカルバッファ）。
Calculate the octet offset into the TCP segment for the next FPDU #N.
次のFPDU＃NのためにTCPセグメントにオフセットオクテットを計算します。
Start calculation of CRC for available data for FPDU. #N
FPDUのために利用可能なデータのためのCRCの計算を開始します。 #N
Store partial CRC results for FPDU #N.
FPDU＃Nのための部分的なCRC結果を保存します。
Store local buffer address of first portion of FPDU #N.
FPDU＃Nの第一の部分のローカルバッファアドレスを格納します。
No further action is possible on FPDU #N, before it is completely received.
それは完全に受信される前に、これ以上のアクションは、FPDU＃Nに可能ではありません。
If the TCP segment is out of order, the receiver must buffer the data until at least one complete FPDU is received. Typically, buffering for more than one TCP segment per connection is required. Use the MPA-based Markers to calculate where FPDU boundaries are.
TCPセグメントが故障している場合、受信機は、少なくとも1つの完全なFPDUを受信するまでデータをバッファリングしなければなりません。典型的には、接続ごとに複数のTCPセグメントのバッファリングが必要です。 FPDU境界がどこにあるかを計算するためにMPAベースのマーカーを使用してください。
When a complete FPDU is available, a similar
procedure to the in-order algorithm above is used.
There is additional complexity, though, because when
the missing segment arrives, this TCP segment must be
run through the CRC engine after the CRC is
calculated for the missing segment.
If we assume FPDU Alignment, the following diagram and the algorithm below apply. Note that when using MPA, the receiver is assumed to actively detect presence or loss of FPDU Alignment for every TCP segment received.
我々はFPDU整列を想定した場合、以下の図およびアルゴリズムを以下適用されます。 MPAを使用する場合、受信機は、積極的にすべてのTCPセグメントが受信のために存在またはFPDU整列の損失を検出するものとします。
+--------------------------+ +--------------------------+
+--|--------------------------+ +--|--------------------------+
| | TCP Seg X | | | TCP Seg X+1 |
+--|--------------------------+ +--|--------------------------+
+--------------------------+ +--------------------------+
FPDU #N FPDU #N+1
Figure 13: Aligned FPDU Placed Immediately after TCP Header
図13：整列FPDU TCPヘッダの直後に配置
The receiver algorithm for FPDU Aligned frames (in order or out of order) includes:
FPDU配向するための受信機アルゴリズムは、（順番に又は順不同）を含むフレーム。
1) Data Link Layer processing (whole frame) -- typically
including a CRC calculation.
2) Network Layer processing (assuming not an IP fragment, the whole Data Link Layer frame contains one IP datagram. IP fragments should be reassembled in a local buffer. This is not a performance optimization goal.)
IPフラグメントをないと仮定2）ネットワーク層処理（、全体のData Link Layerフレームは1つのIPデータグラムが含まれています。IPフラグメントが、これはパフォーマンスの最適化目標ではありません。ローカルバッファで再構築する必要があります。）
3) Transport Layer processing -- TCP protocol processing, header and checksum checks.
3）トランスポート層処理 - TCPプロトコル処理、ヘッダとチェックサムをチェックします。
a. Classify incoming TCP segment using the 5 tuple (IP SRC,
IP DST, TCP SRC Port, TCP DST Port, protocol).
4) Check for Header Alignment (described in detail in Section 6). Assuming Header Alignment for the rest of the algorithm below.
4）第6節に詳細に記載ヘッダアライメント（）をチェックします。以下のアルゴリズムの残りのためのヘッダアライメントを仮定。
a. If the header is not aligned, see the algorithm defined
in the prior section.
5) If TCP segment is in order or out of order, the MPA header is at the beginning of the current TCP payload. Get the FPDU length from the FPDU header.
TCPセグメントが順序で、または故障している場合は5）、MPAヘッダは、現在のTCPペイロードの先頭にあります。 FPDUヘッダーからFPDU長を取得します。
6) Calculate CRC over FPDU.
6）FPDU上CRCを計算します。
7) Check CRC calculation for FPDU #N.
7）FPDU＃NのためのCRC計算を確認してください。
8) If no FPDU CRC errors, placement is allowed.
8）なしFPDU CRCエラー場合は、配置が許可されます。
9) CopyData(TCP segment #X, host buffer address, length).
9）のCopyData（TCPセグメント#X、ホストバッファアドレス、長さ）。
10) Loop to #5 until all the FPDUs in the TCP segment are consumed in order to handle FPDU packing.
10）ループを＃5へのTCPセグメント内のすべてのFPDUsがFPDUパッキングを処理するために消費されるまで。
Implementation note: In both cases, the receiver has to classify the incoming TCP segment and associate it with one of the flows it maintains. In the case of no FPDU Alignment, the receiver is forced to classify incoming traffic before it can calculate the FPDU CRC. In the case of FPDU Alignment, the operations order is left to the implementer.
実装注：両方の場合において、受信機は、着信TCPセグメントを分類し、それが維持フローのいずれに関連付けなければなりません。無FPDU整列の場合、受信機は、それがFPDU CRCを計算することができます前に、着信トラフィックを分類することを余儀なくされます。 FPDU整列の場合には、オペレーションの順序は、実装者に委ねられます。
The FPDU Aligned receiver algorithm is significantly simpler. There is no need to locally buffer portions of FPDUs. Accessing state information is also substantially simplified -- the normal case does not require retrieving information to find out where an FPDU starts and ends or retrieval of a partial CRC before the CRC calculation can commence. This avoids adding internal latencies, having multiple data passes through the CRC machine, or scheduling multiple commands for moving the data to the host buffer.
FPDU同盟の受信機アルゴリズムを大幅に単純です。 FPDUsのローカルバッファ部分への必要はありません。状態情報にアクセスすることも大幅に簡略化された - CRC計算が開始する前に、通常の場合はFPDUが起動し、終了または部分CRCの検索場所を見つけるための情報を取得する必要がありません。これは、複数のデータを有するCRC機を通過し、内部レイテンシを追加する、またはホストバッファにデータを移動させるための複数のコマンドをスケジュールすることを回避します。
The aligned FPDU approach is useful for in-order and out-of-order reception. The receiver can use the same mechanisms for data storage in both cases, and only needs to account for when all the TCP segments have arrived to enable Delivery. The Header Alignment, along with the high probability that at least one complete FPDU is found with every TCP segment, allows the receiver to perform data placement for out-of-order TCP segments with no need for intermediate buffering. Essentially, the TCP receive buffer has been eliminated and TCP reassembly is done in place within the ULP Buffer.
整列FPDUアプローチは、インオーダーおよびアウトオブオーダ受信するのに有用です。受信機は両方のケースでのデータ保存のために同じメカニズムを使用し、唯一のすべてのTCPセグメントが配信を可能にするために到着したときを説明するために必要であることができます。ヘッダアライメントは、少なくとも1つの完全なFPDUがあらゆるTCPセグメントに見出される高い確率と共に、受信機は、中間バッファを必要とせず、アウト・オブ・オーダのTCPセグメントのデータ配置を行うことができます。基本的に、TCP受信バッファが解消されたとTCPの再構築は、ULPバッファ内の場所で行われています。
In case FPDU Alignment is not found, the receiver should follow the algorithm for non-aligned FPDU reception, which may be slower and less efficient.
FPDU整列が見つからなかった場合には、受信機は遅く、それほど効率的であり得る非整列FPDU受信用アルゴリズムに従うべきです。
B.2.2. FPDU Alignment Effects on TCP Wire Protocol
B.2.2。 TCPワイヤプロトコル上のFPDU整列の影響
In an optimized MPA/TCP implementation, TCP exposes its EMSS to MPA. MPA uses the EMSS to calculate its MULPDU, which it then exposes to DDP, its ULP. DDP uses the MULPDU to segment its payload so that each FPDU sent by MPA fits completely into one TCP segment. This has no impact on wire protocol, and exposing this information is already supported on many TCP implementations, including all modern flavors of BSD networking, through the TCP_MAXSEG socket option.
最適化されたMPA / TCPの実装では、TCPは、MPAへのエムスを公開します。 MPAは、それがその後、DDP、そのULPに公開し、そのMULPDUを、計算にエムスを使用しています。 MPAによって送られた各FPDUは、1つのTCPセグメントに完全に収まるようにDDPセグメントにそのペイロードをMULPDUを使用します。これは、ワイヤプロトコルには影響しませんし、この情報を暴露することは、すでにTCP_MAXSEGソケットオプションを通じて、BSDネットワーキングのすべての近代的な味を含む多くのTCP実装、サポートされています。
In the common case, the ULP (i.e., DDP over MPA) messages provided to the TCP layer are segmented to MULPDU size. It is assumed that the ULP message size is bounded by MULPDU, such that a single ULP message can be encapsulated in a single TCP segment. Therefore, in the common case, there is no increase in the number of TCP segments emitted. For smaller ULP messages, the sender can also apply packing, i.e., the sender packs as many complete FPDUs as possible into one TCP segment. The requirement to always have a complete FPDU may increase the number of TCP segments emitted. Typically, a ULP message size varies from a few bytes to multiple EMSSs (e.g., 64 Kbytes). In some cases, the ULP may post more than one message at a time for transmission, giving the sender an opportunity for packing. In the case where more than one FPDU is available for transmission and the FPDUs are encapsulated into a TCP segment and there is no room in the TCP segment to include the next complete FPDU, another
一般的なケースでは、TCP層に設けられたULP（すなわち、MPA上DDP）メッセージがMULPDUサイズにセグメント化されます。 ULPメッセージサイズが単一ULPメッセージは単一のTCPセグメント内にカプセル化することができるように、MULPDUによって囲まれているものとします。したがって、一般的なケースでは、放出されたTCPセグメントの数の増加はありません。小さなULPメッセージの場合、送信者はまた、梱包を適用することができ、すなわち、送信者が1つのTCPセグメントにできるだけ多くの完全なFPDUsをパックします。常に完全なFPDUを持っているという要件は、放出されたTCPセグメントの数を増大させることができます。典型的には、ULPメッセージサイズは、複数EMSSs（例えば、64バイト）に数バイトから変化します。いくつかのケースでは、ULPは、送信者に梱包のための機会を与えて、送信用の一度に複数のメッセージを投稿することがあります。複数のFPDUがTCPセグメントにカプセル化された送信とのFPDUsのために利用可能であり、次の完全なFPDU、別のものを含むためにTCPセグメントに空きがない場合に
TCP segment is sent. In this corner case, some of the TCP segments are not full size. In the worst-case scenario, the ULP may choose an FPDU size that is EMSS/2 +1 and has multiple messages available for transmission. For this poor choice of FPDU size, the average TCP segment size is therefore about 1/2 of the EMSS and the number of TCP segments emitted is approaching 2x of what is possible without the requirement to encapsulate an integer number of complete FPDUs in every TCP segment. This is a dynamic situation that only lasts for the duration where the sender ULP has multiple non-optimal messages for transmission and this causes a minor impact on the wire utilization.
TCPセグメントが送信されます。このコーナーの場合、TCPセグメントの一部は、フルサイズではありません。最悪のシナリオでは、ULPはエムス/ 2 +1であり、送信のために利用可能な複数のメッセージを有するFPDUサイズを選択することができます。 FPDUサイズのこの貧弱な選択のために、平均TCPセグメントサイズは、従って、約1/2エムスのであり、放射されたTCPセグメントの数は、すべてのTCPに完全のFPDUsの整数をカプセル化する必要なしに可能であるものの2倍に近づいていますセグメント。これは、送信者ULPは、送信用の複数の非最適なメッセージを持っており、これは、ワイヤの使用率に与える影響は軽微の原因となる期間持続する動的な状況です。
However, it is not expected that requiring FPDU Alignment will have a measurable impact on wire behavior of most applications. Throughput applications with large I/Os are expected to take full advantage of the EMSS. Another class of applications with many small outstanding buffers (as compared to EMSS) is expected to use packing when applicable. Transaction-oriented applications are also optimal.
しかし、FPDU整列を必要とするほとんどのアプリケーションのワイヤ行動に測定可能な影響を与えることが期待されていません。大規模なI / Oを持つスループットのアプリケーションはエムスをフルに活用することが期待されています。 （エムスと比較して）多くの小さな優れたバッファを使用したアプリケーションの別のクラスは、適用可能な場合、パッキンを使用することが期待されています。トランザクション指向のアプリケーションにも最適です。
TCP retransmission is another area that can affect sender behavior. TCP supports retransmission of the exact, originally transmitted segment (see [RFC793], Sections 2.6 and 3.7 (under "Managing the Window") and [RFC1122], Section 4.2.2.15). In the unlikely event that part of the original segment has been received and acknowledged by the Remote Peer (e.g., a re-segmenting middlebox, as documented in Appendix A.4, Re-Segmenting Middleboxes and Non-Optimized MPA/TCP Senders), a better available bandwidth utilization may be possible by retransmitting only the missing octets. If an optimized MPA/TCP retransmits complete FPDUs, there may be some marginal bandwidth loss.
TCPの再送は、送信者の行動に影響を与えることができる別の領域です。 TCP（セクション4.2.2.15、[RFC793]、セクション2.6および3.7（） "ウィンドウの管理" 下と[RFC1122]を参照）正確な、元々送信されたセグメントの再送信をサポートします。元のセグメントの一部は、リモートピア（例えば、再セグメント化、ミドル、付録A.4に記載されているように、再セグメント化のMiddleboxesと非最適化されたMPA / TCP送信者）が受信したと認められていること万一、でより良い利用可能な帯域幅の使用率は行方不明のオクテットを再送信することによって可能です。最適化されたMPA / TCPは、完全なFPDUsを再送信する場合は、いくつかの限界帯域幅の損失があるかもしれません。
Another area where a change in the TCP segment number may have impact is that of slow start and congestion avoidance. Slow-start exponential increase is measured in segments per second, as the algorithm focuses on the overhead per segment at the source for congestion that eventually results in dropped segments. Slow-start exponential bandwidth growth for optimized MPA/TCP is similar to any TCP implementation. Congestion avoidance allows for a linear growth in available bandwidth when recovering after a packet drop. Similar to the analysis for slow start, optimized MPA/TCP doesn't change the behavior of the algorithm. Therefore, the average size of the segment versus EMSS is not a major factor in the assessment of the bandwidth growth for a sender. Both slow start and congestion avoidance for an optimized MPA/TCP will behave similarly to any TCP sender and allow an optimized MPA/TCP to enjoy the theoretical performance limits of the algorithms.
TCPセグメント数の変化が影響を有することができる別の領域は、スロースタートと輻輳回避のものです。アルゴリズムは、最終的に廃棄さのセグメントになる輻輳のソースでセグメント当たりのオーバーヘッドに焦点を当てたように指数関数的な増加は、秒あたりのセグメントで測定されたスロースタート。最適化されたMPA / TCPのための指数関数的な帯域幅の成長をスロースタート任意のTCPの実装に似ています。パケットドロップ後の回復時に輻輳回避は、利用可能な帯域幅で直線的な成長が可能になります。スロースタートのための分析と同様に、最適化されたMPA / TCPは、アルゴリズムの動作を変更しません。したがって、エムス対セグメントの平均サイズは、送信側の帯域幅成長の評価における主要な要因ではありません。最適化されたMPA / TCPのためのスロースタートと輻輳回避の両方が任意のTCP送信者と同様に動作し、アルゴリズムの理論的な性能限界を楽しむために最適化されたMPA / TCPを許可します。
In summary, the ULP messages generated at the sender (e.g., the amount of messages grouped for every transmission request) and message size distribution has the most significant impact over the number of TCP segments emitted. The worst-case effect for certain ULPs (with average message size of EMSS/2+1 to EMSS) is bounded by an increase of up to 2x in the number of TCP segments and acknowledges. In reality, the effect is expected to be marginal.
要約すると、ULPメッセージ（例えば、すべての送信要求のグループ化されたメッセージの量）送信側で生成されたメッセージのサイズ分布は、放出されたTCPセグメントの数で最も大きな影響を有します。 （エムスエムスへ/ 2 + 1の平均メッセージサイズを有する）特定のULPのための最悪の場合の効果は、TCPセグメントの数が2倍と認めるまでの増加によって制限されます。実際には、効果が限界であると期待されます。
Appendix C. IETF Implementation Interoperability with RDMA Consortium Protocols
RDMAコンソーシアムプロトコルと付録C. IETFの実装の相互運用性
This appendix is for information only and is NOT part of the standard.
この付録では、情報提供のみを目的と標準の一部ではありません。
This appendix covers methods of making MPA implementations interoperate with both IETF and RDMA Consortium versions of the protocols.
この付録では、MPA実装がプロトコルのIETFとRDMAコンソーシアム両方のバージョンと相互運用する製造方法をカバーします。
The RDMA Consortium created early specifications of the MPA/DDP/RDMA protocols, and some manufacturers created implementations of those protocols before the IETF versions were finalized. These protocols are very similar to the IETF versions making it possible for implementations to be created or modified to support either set of specifications.
RDMAコンソーシアムは、MPA / DDP / RDMAプロトコルの初期の仕様を作成し、IETFのバージョンが確定される前に、いくつかのメーカーは、これらのプロトコルの実装を作成しました。これらのプロトコルは、それが可能な実装が作成または仕様のいずれかのセットをサポートするように変更することができるようにすることIETFのバージョンと非常によく似ています。
For those interested, the RDMA Consortium protocol documents (draft-culley-iwarp-mpa-v1.0.pdf [RDMA-MPA], draft-shah-iwarp-ddp-v1.0.pdf [RDMA-DDP], and draft-recio-iwarp-rdmac-v1.0.pdf [RDMA-RDMAC]) can be obtained at http://www.rdmaconsortium.org/home.
これらの興味、RDMAコンソーシアムプロトコルドキュメント（ドラフトculley-iWARPの-MPA-v1.0.pdf [RDMA-MPA]、ドラフトシャー-iWARPの-DDP-v1.0.pdf [RDMA-DDP]、およびドラフトのための-recio-iWARPの-RDMAC-v1.0.pdf [RDMA-RDMAC]）http://www.rdmaconsortium.org/homeで得ることができます。
In this section, implementations of MPA/DDP/RDMA that conform to the RDMAC specifications are called RDMAC RNICs. Implementations of MPA/DDP/RDMA that conform to the IETF RFCs are called IETF RNICs.
このセクションでは、RDMAC仕様に準拠MPA / DDP / RDMAの実装はRDMAC RNICsと呼ばれます。 IETFのRFCに準拠MPA / DDP / RDMAの実装は、IETF RNICsと呼ばれています。
Without the exchange of MPA Request/Reply Frames, there is no standard mechanism for enabling RDMAC RNICs to interoperate with IETF RNICs. Even if a ULP uses a well-known port to start an IETF RNIC immediately in RDMA mode (i.e., without exchanging the MPA Request/Reply messages), there is no reason to believe an IETF RNIC will interoperate with an RDMAC RNIC because of the differences in the version number in the DDP and RDMAP headers on the wire.
MPA要求/応答フレームの交換をせずに、IETF RNICsと相互運用できるようにRDMAC RNICsを有効にするための標準的なメカニズムはありません。 ULPは（/ MPA要求を交換することなく、すなわち、メッセージを返信）すぐRDMAモードでIETF RNICを開始するには、よく知られているポートを使用している場合でも、IETF RNICが原因のRDMAC RNICと相互運用しますと信じる理由はありませんワイヤ上のDDPとRDMAPヘッダーにバージョン番号の違い。
Therefore, the ULP or other supporting entity at the RDMAC RNIC must implement MPA Request/Reply Frames on behalf of the RNIC in order to negotiate the connection parameters. The following section describes the results following the exchange of the MPA Request/Reply Frames before the conversion from streaming to RDMA mode.
したがって、RDMAC RNICでULPまたは他のサポートエンティティは、接続パラメータを交渉するために、RNICに代わってフレームを返信/ MPA要求を実装する必要があります。以下のセクションでは、MPA要求の交換を、以下の結果を記述する/ RDMAモードへのストリーミングから変換前のフレームを返信します。
C.1. Negotiated Parameters
C.1。交渉さパラメータ
Three types of RNICs are considered:
RNICsの3種類とみなされます。
Upgraded RDMAC RNIC - an RNIC implementing the RDMAC protocols that has a ULP or other supporting entity that exchanges the MPA Request/Reply Frames in streaming mode before the conversion to RDMA mode.
RDMAC RNICアップグレード - MPA要求を交換ULPまたは他の支持エンティティを有するRDMACプロトコルを実装RNICを/ RDMAモードに変換する前に、ストリーミング・モードでフレームを返信します。
Non-permissive IETF RNIC - an RNIC implementing the IETF protocols that is not capable of implementing the RDMAC protocols. Such an RNIC can only interoperate with other IETF RNICs.
非許容IETF RNIC - RDMACプロトコルを実装することができないIETFプロトコルを実装RNIC。このようなRNICは他のIETF RNICsと相互運用することができます。
Permissive IETF RNIC - an RNIC implementing the IETF protocols that is capable of implementing the RDMAC protocols on a per-connection basis.
許容IETF RNIC - 接続ごとにRDMACプロトコルを実装することが可能なIETFプロトコルを実装RNIC。
The Permissive IETF RNIC is recommended for those implementers that want maximum interoperability with other RNIC implementations.
寛容なIETF RNICは他のRNICの実装との最大の相互運用性をしたいものを実装することをお勧めします。
The values used by these three RNIC types for the MPA, DDP, and RDMAP versions as well as MPA Markers and CRC are summarized in Figure 14.
これら三つのRNIC MPA、DDPとRDMAPバージョンのタイプならびにMPAマーカとCRCで使用される値は、図14に要約されています。
+----------------++-----------+-----------+-----------+-----------+
| RNIC TYPE || DDP/RDMAP | MPA | MPA | MPA |
| || Version | Revision | Markers | CRC |
+----------------++-----------+-----------+-----------+-----------+
+----------------++-----------+-----------+-----------+-----------+
| RDMAC || 0 | 0 | 1 | 1 |
| || | | | |
+----------------++-----------+-----------+-----------+-----------+
| IETF || 1 | 1 | 0 or 1 | 0 or 1 |
| Non-permissive || | | | |
+----------------++-----------+-----------+-----------+-----------+
| IETF || 1 or 0 | 1 or 0 | 0 or 1 | 0 or 1 |
| permissive || | | | |
+----------------++-----------+-----------+-----------+-----------+
Figure 14: Connection Parameters for the RNIC Types
for MPA Markers and MPA CRC, enabled=1, disabled=0.
It is assumed there is no mixing of versions allowed between MPA, DDP, and RDMAP. The RNIC either generates the RDMAC protocols on the wire (version is zero) or uses the IETF protocols (version is one).
MPA、DDPとRDMAP間許容バージョンのない混合が存在しないものとします。 RNICのいずれかは、ワイヤ上RDMACプロトコルを生成する（バージョンがゼロである）、または（バージョンが1である）IETFプロトコルを使用します。
During the exchange of the MPA Request/Reply Frames, each peer provides its MPA Revision, Marker preference (M: 0=disabled, 1=enabled), and CRC preference. The MPA Revision provided in the MPA Request Frame and the MPA Reply Frame may differ.
、及びCRC嗜好：MPA要求/フレームを返信の交換中、各ピアは、そのMPAリビジョン、マーカー優先（0 =無効、1 =有効M）を提供します。 MPAの要求フレームとMPAの応答フレームで提供MPAリビジョンが異なる場合があります。
From the information in the MPA Request/Reply Frames, each side sets the Version field (V: 0=RDMAC, 1=IETF) of the DDP/RDMAP protocols as well as the state of the Markers for each half connection. Between DDP and RDMAP, no mixing of versions is allowed. Moreover, the DDP and RDMAP version MUST be identical in the two directions. The RNIC either generates the RDMAC protocols on the wire (version is zero) or uses the IETF protocols (version is one).
DDP / RDMAPプロトコル：（0 = RDMAC、1 = IETF V）ならびに各半分の接続のためのマーカーの状態MPA要求の情報から/フレームを返信、各側は、バージョンフィールドを設定します。 DDPとRDMAPの間に、バージョンのない混合は許されません。また、DDPとRDMAPバージョンは、二つの方向で同一でなければなりません。 RNICのいずれかは、ワイヤ上RDMACプロトコルを生成する（バージョンがゼロである）、または（バージョンが1である）IETFプロトコルを使用します。
In the following sections, the figures do not discuss CRC negotiation because there is no interoperability issue for CRCs. Since the RDMAC RNIC will always request CRC use, then, according to the IETF MPA specification, both peers MUST generate and check CRCs.
CRCのための相互運用性の問題はありませんので、以下のセクションでは、数字はCRCの交渉については説明しません。 RDMAC RNICは、常にCRC使用を要求するので、その後、IETF MPA仕様によれば、両方のピアを生成し、CRCをチェックしなければなりません。
C.2. RDMAC RNIC and Non-Permissive IETF RNIC
C.2。 RDMAC RNICと非許容IETF RNIC
Figure 15 shows that a Non-permissive IETF RNIC cannot interoperate with an RDMAC RNIC, despite the fact that both peers exchange MPA Request/Reply Frames. For a Non-permissive IETF RNIC, the MPA negotiation has no effect on the DDP/RDMAP version and it is unable to interoperate with the RDMAC RNIC.
図15は、非許容IETF RNICは、両方のピアがMPA要求/応答フレームを交換するという事実にもかかわらず、RDMAC RNICと相互運用することができないことを示しています。非許容IETF RNICに関しては、MPA交渉はDDP / RDMAPバージョンには影響しませんし、RDMAC RNICと相互運用することができません。
The rows in the figure show the state of the Marker field in the MPA Request Frame sent by the MPA Initiator. The columns show the state of the Marker field in the MPA Reply Frame sent by the MPA Responder. Each type of RNIC is shown as an Initiator and a Responder. The connection results are shown in the lower right corner, at the intersection of the different RNIC types, where V=0 is the RDMAC DDP/RDMAP version, V=1 is the IETF DDP/RDMAC version, M=0 means MPA Markers are disabled, and M=1 means MPA Markers are enabled. The negotiated Marker state is shown as X/Y, for the receive direction of the Initiator/Responder.
図の行は、MPA、イニシエータによって送信されたMPA要求フレームにマーカーフィールドの状態を示しています。列は、MPAレスポンダによって送信されたMPA応答フレームにマーカーフィールドの状態を示しています。 RNICの各タイプは、イニシエータとレスポンダとして示されています。接続結果は、V = 1、M IETF DDP / RDMACバージョンであり、V = 0 RDMAC DDP / RDMAPバージョンである異なるRNICタイプの交差点で、右下隅に示されている= 0は、MPAマーカがあることを意味します無効、およびM = 1は、MPAマーカーが有効になっていることを意味します。イニシエータ/レスポンダの方向を受け取るために交渉マーカー状態は、X / Yとして示されています。
+---------------------------++-----------------------+
| MPA || MPA |
| CONNECT || Responder |
| MODE +-----------------++-------+---------------+
| | RNIC || RDMAC | IETF |
| | TYPE || | Non-permissive|
| | +------++-------+-------+-------+
| | |MARKER|| M=1 | M=0 | M=1 |
+---------+----------+------++-------+-------+-------+
+---------+----------+------++-------+-------+-------+
| | RDMAC | M=1 || V=0 | close | close |
| | | || M=1/1 | | |
| +----------+------++-------+-------+-------+
| MPA | | M=0 || close | V=1 | V=1 |
|Initiator| IETF | || | M=0/0 | M=0/1 |
| |Non-perms.+------++-------+-------+-------+
| | | M=1 || close | V=1 | V=1 |
| | | || | M=1/0 | M=1/1 |
+---------+----------+------++-------+-------+-------+
Figure 15: MPA Negotiation between an RDMAC RNIC and a Non-Permissive IETF RNIC
図15：RDMAC RNICと非許容IETF RNICとの間のMPAネゴシエーション
C.2.1. RDMAC RNIC Initiator
C.2.1。 RDMAC RNICイニシエータ
If the RDMAC RNIC is the MPA Initiator, its ULP sends an MPA Request Frame with Rev field set to zero and the M and C bits set to one. Because the Non-permissive IETF RNIC cannot dynamically downgrade the version number it uses for DDP and RDMAP, it would send an MPA Reply Frame with the Rev field equal to one and then gracefully close the connection.
RDMAC RNICは、MPA開始剤である場合、そのULPは改訂フィールドとMPA要求フレームはゼロに設定され、M及びCのビットが1に設定さ送ります。非許容IETF RNICがダイナミックにそれがDDPとRDMAPに使用するバージョン番号をダウングレードすることはできませんので、それは1に等しい改訂フィールドとMPAの応答フレームを送信して、優雅に接続を閉じます。
C.2.2. Non-Permissive IETF RNIC Initiator
C.2.2。非許容IETF RNICイニシエータ
If the Non-permissive IETF RNIC is the MPA Initiator, it sends an MPA Request Frame with Rev field equal to one. The ULP or supporting entity for the RDMAC RNIC responds with an MPA Reply Frame that has the Rev field equal to zero and the M bit set to one. The Non-permissive IETF RNIC will gracefully close the connection after it reads the incompatible Rev field in the MPA Reply Frame.
非許容IETF RNICがMPAイニシエータである場合、それは1に等しいRev分野があるMPA Requestフレームを送信します。 ULP又はRDMAC RNICの支持エンティティがゼロに等しいRev分野およびMが1に設定されたビットMPA応答フレームで応答します。それはMPAの応答フレームに互換性のない改訂フィールドを読み取った後、非許容IETF RNICは優雅に接続を閉じます。
C.2.3. RDMAC RNIC and Permissive IETF RNIC
C.2.3。 RDMAC RNICと寛容なIETF RNIC
Figure 16 shows that a Permissive IETF RNIC can interoperate with an RDMAC RNIC regardless of its Marker preference. The figure uses the same format as shown with the Non-permissive IETF RNIC.
図16は、許容IETF RNICにかかわらず、そのマーカ嗜好のRDMAC RNICと相互運用することができることを示しています。図は、非許容IETF RNICで示すように同じフォーマットを使用します。
+---------------------------++-----------------------+
| MPA || MPA |
| CONNECT || Responder |
| MODE +-----------------++-------+---------------+
| | RNIC || RDMAC | IETF |
| | TYPE || | Permissive |
| | +------++-------+-------+-------+
| | |MARKER|| M=1 | M=0 | M=1 |
+---------+----------+------++-------+-------+-------+
+---------+----------+------++-------+-------+-------+
| | RDMAC | M=1 || V=0 | N/A | V=0 |
| | | || M=1/1 | | M=1/1 |
| +----------+------++-------+-------+-------+
| MPA | | M=0 || V=0 | V=1 | V=1 |
|Initiator| IETF | || M=1/1 | M=0/0 | M=0/1 |
| |Permissive+------++-------+-------+-------+
| | | M=1 || V=0 | V=1 | V=1 |
| | | || M=1/1 | M=1/0 | M=1/1 |
+---------+----------+------++-------+-------+-------+
Figure 16: MPA Negotiation between an RDMAC RNIC and a Permissive IETF RNIC
図16：RDMAC RNICおよび許容的IETF RNICとの間のMPAネゴシエーション
A truly Permissive IETF RNIC will recognize an RDMAC RNIC from the Rev field of the MPA Req/Rep Frames and then adjust its receive Marker state and DDP/RDMAP version to accommodate the RDMAC RNIC. As a result, as an MPA Responder, the Permissive IETF RNIC will never return an MPA Reply Frame with the M bit set to zero. This case is shown as a not applicable (N/A) in Figure 16.
真に許容的IETF RNICは、MPA必須/担当フレームの改訂フィールドからRDMAC RNICを認識し、次いでRDMAC RNICを収容するためにそのマーカーを受ける状態およびDDP / RDMAPバージョンを調整します。 Mがゼロに設定ビットが結果として、MPAレスポンダとして、寛容なIETF RNICは、MPAの応答フレームを返すことはありません。この場合は、図16に該当なし（N / A）として示されています。
C.2.4. RDMAC RNIC Initiator
C.2.4。 RDMAC RNICイニシエータ
When the RDMAC RNIC is the MPA Initiator, its ULP or other supporting entity prepares an MPA Request message and sets the revision to zero and the M bit and C bit to one.
RDMAC RNICは、MPA開始剤である場合、そのULPまたは他の支持エンティティがMPA Requestメッセージを作成し、一方にゼロに改訂及びMビット及びCビットをセットします。
The Permissive IETF Responder receives the MPA Request message and checks the revision field. Since it is capable of generating RDMAC DDP/RDMAP headers, it sends an MPA Reply message with revision set to zero and the M and C bits set to one. The Responder must inform its ULP that it is generating version zero DDP/RDMAP messages.
寛容なIETF ResponderはMPA Requestメッセージを受信して、リビジョンフィールドをチェックします。それはRDMAC DDP / RDMAPヘッダーを生成することができるので、リビジョンとMPAの応答メッセージがゼロに設定され、M及びCのビットが1に設定さ送ります。 Responderは、それは、バージョンゼロDDP / RDMAPメッセージを生成しているそのULPに通知しなければなりません。
C.2.5 Permissive IETF RNIC Initiator
C.2.5寛容なIETF RNICイニシエータ
If the Permissive IETF RNIC is the MPA Initiator, it prepares the MPA Request Frame setting the Rev field to one. Regardless of the value of the M bit in the MPA Request Frame, the ULP or other supporting entity for the RDMAC RNIC will create an MPA Reply Frame with Rev equal to zero and the M bit set to one.
寛容なIETF RNICがMPAイニシエータである場合、それは1つに改訂フィールドを設定MPA要求フレームを準備します。かかわらず、MPA要求フレーム内のMビットの値の、RDMAC RNIC用ULPまたは他の支持エンティティがゼロに等しいRevおよびMとMPAの応答フレームを作成し、いずれかに設定ビット。
When the Initiator reads the Rev field of the MPA Reply Frame and finds that its peer is an RDMAC RNIC, it must inform its ULP that it should generate version zero DDP/RDMAP messages and enable MPA Markers and CRC.
イニシエータはフレームを返信MPAの改訂フィールドを読み取り、そのピアがRDMAC RNICであることを発見した場合、それは、バージョンゼロDDP / RDMAPメッセージを生成し、MPAマーカーとCRCを有効にする必要があり、そのULPに通知しなければなりません。
C.3. Non-Permissive IETF RNIC and Permissive IETF RNIC
C.3。非許容IETF RNICと寛容なIETF RNIC
For completeness, Figure 17 below shows the results of MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC. The important point from this figure is that an IETF RNIC cannot detect whether its peer is a Permissive or Non-permissive RNIC.
完全を期すために、図17は、以下の非許容IETF RNICおよび許容的IETF RNICとの間のMPAネゴシエーションの結果を示します。この図から、重要な点は、IETF RNICは、そのピアが許可的あるいは非許容RNICであるか否かを検出することができないということです。
+---------------------------++-------------------------------+
| MPA || MPA |
| CONNECT || Responder |
| MODE +-----------------++---------------+---------------+
| | RNIC || IETF | IETF |
| | TYPE || Non-permissive| Permissive |
| | +------++-------+-------+-------+-------+
| | |MARKER|| M=0 | M=1 | M=0 | M=1 |
+---------+----------+------++-------+-------+-------+-------+
+---------+----------+------++-------+-------+-------+-------+
| | | M=0 || V=1 | V=1 | V=1 | V=1 |
| | IETF | || M=0/0 | M=0/1 | M=0/0 | M=0/1 |
| |Non-perms.+------++-------+-------+-------+-------+
| | | M=1 || V=1 | V=1 | V=1 | V=1 |
| | | || M=1/0 | M=1/1 | M=1/0 | M=1/1 |
| MPA +----------+------++-------+-------+-------+-------+
|Initiator| | M=0 || V=1 | V=1 | V=1 | V=1 |
| | IETF | || M=0/0 | M=0/1 | M=0/0 | M=0/1 |
| |Permissive+------++-------+-------+-------+-------+
| | | M=1 || V=1 | V=1 | V=1 | V=1 |
| | | || M=1/0 | M=1/1 | M=1/0 | M=1/1 |
+---------+----------+------++-------+-------+-------+-------+
Figure 17: MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC.
図17：非許容IETF RNICおよび許容的IETF RNICとの間のMPA交渉。
Normative References
引用規格
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[iSCSIの】Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RDMASEC] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RDMASEC]ピンカートン、J.およびE. Deleganes、 "直接データ配置プロトコル（DDP）/リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ"、RFC 5042、2007年10月。
Informative References
参考文献
[APPL] Bestler, C. and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007.
[APPL] Bestler、C.とL. Coene、 "リモートダイレクトメモリアクセスプロトコル（RDMA）と直接データ配置（DDP）の適用"、RFC 5045、2007年10月。
[CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000.
【CRCTCP]ストーンJ.、ヤマウズラ、C.、 "CRCとTCPチェックサムが合わないときは"、ACM SIGCOMM、2000年9月。
[DAT-API] DAT Collaborative, "kDAPL (Kernel Direct Access Programming Library) and uDAPL (User Direct Access Programming Library)", Http://www.datcollaborative.org.
[DAT-API] DAT共同、 "kDAPL（カーネルダイレクトアクセスプログラミングライブラリ）とのuDAPL（ユーザーダイレクトアクセスプログラミングライブラリ）"、Http://www.datcollaborative.org。
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[DDP]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)" RFC 5046, October 2007.
[のiSER]コ、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターラー、「インターネット小型コンピュータシステムインタフェース（iSCSIの）リモートダイレクトメモリアクセスのための拡張機能（RDMA ）」RFC 5046、2007年10月。
[IT-API] The Open Group, "Interconnect Transport API (IT-API)" Version 2.1, http://www.opengroup.org.
[IT-API]オープングループ、 "インターコネクトトランスポートAPI（IT-API）" バージョン2.1、http://www.opengroup.org。
[NFSv4CHAN] Williams, N., "On the Use of Channel Bindings to Secure Channels", Work in Progress, June 2006.
[NFSv4CHAN]ウィリアムズ、N.、「チャンネルを確保するためにチャネルバインディングの使用について」、進歩、2006年6月での作業。
[RDMA-DDP] "Direct Data Placement over Reliable Transports (Version 1.0)", RDMA Consortium, October 2002, <http://www.rdmaconsortium.org/home/draft-shah-iwarp-ddp-v1.0.pdf>.
[RDMA-DDP] "信頼性の高いトランスポート上で直接データ配置（バージョン1.0）"、RDMAコンソーシアム、2002年10月、<http://www.rdmaconsortium.org/home/draft-shah-iwarp-ddp-v1.0.pdf >。
[RDMA-MPA] "Marker PDU Aligned Framing for TCP Specification (Version 1.0)", RDMA Consortium, October 2002, <http://www.rdmaconsortium.org/home/draft-culley-iwarp-mpa-v1.0.pdf>.
[RDMA-MPA] "TCP仕様のためのマーカーPDU同盟フレーミング（バージョン1.0）"、RDMAコンソーシアム、2002年10月、<http://www.rdmaconsortium.org/home/draft-culley-iwarp-mpa-v1.0。 PDF>。
[RDMA-RDMAC] "An RDMA Protocol Specification (Version 1.0)", RDMA Consortium, October 2002, <http://www.rdmaconsortium.org/home/draft-recio-iwarp-rdmac-v1.0.pdf>.
[RDMA-RDMAC] "RDMAプロトコル仕様（バージョン1.0）"、RDMAコンソーシアム、2002年10月、<http://www.rdmaconsortium.org/home/draft-recio-iwarp-rdmac-v1.0.pdf>。
[RDMAP] Recio, R., Culley, P., Garcia, D., Hilland, J., and B. Metzler, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RDMAP] Recio、R.、Culley、P.、ガルシア、D.、Hilland、J.、およびB.メッツラー、 "リモートダイレクトメモリアクセスプロトコル仕様"、RFC 5040、2007年10月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC4296] Bailey, S. and T. Talpey, "The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols", RFC 4296, December 2005.
[RFC4296]ベイリー、S.とT. Talpey、 "インターネットプロトコル上で直接データ配置（DDP）とリモートダイレクトメモリアクセス（RDMA）のアーキテクチャ"、RFC 4296、2005年12月。
[RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005.
[RFC4297] Romanow、A.、モーグル、J.、Talpey、T.、およびS.ベイリー、 "リモートダイレクトメモリアクセスIP問題文上（RDMA）"、RFC 4297、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[VERBS-RMDA] "RDMA Protocol Verbs Specification", RDMA Consortium standard, April 2003, <http://www.rdmaconsortium.org/ home/draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>.
[動詞-RMDA] "RDMAプロトコル動詞仕様"、RDMAコンソーシアムの標準、2003年4月、<http://www.rdmaconsortium.org/ホーム/ドラフト-hilland-iWARPの-動詞-v1.0を-RDMAC.pdf>。
Contributors
協力者
Dwight Barron Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-2769 EMail: dwight.barron@hp.com
ドワイト・バロン、米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-2769 Eメール：dwight.barron@hp.com
Jeff Chase Department of Computer Science Duke University Durham, NC 27708-0129 USA Phone: +1 919 660 6559 EMail: chase@cs.duke.edu
コンピュータサイエンスデューク大学のジェフ・チェイス部門ダーラム、NC 27708-0129 USA電話：+1 919 660 6559 Eメール：chase@cs.duke.edu
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
テッド・コンプトンEMCコーポレーションリサーチトライアングルパーク、NC 27709 USA電話：919-248-6075 Eメール：compton_ted@emc.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 Phone: 831 247 4464 EMail: Dave.Garcia@StanfordAlumni.org
デイブ・ガルシア24100ハッチンソンRdのロスガトス、CA 95033電話:. 831 247 4464 Eメール：Dave.Garcia@StanfordAlumni.org
Hari Ghadia Gen10 Technology, Inc. 1501 W Shady Grove Road Grand Prairie, TX 75050 Phone: (972) 301 3630 EMail: hghadia@gen10technology.com
ハリGhadia GEN10テクノロジー株式会社1501年Wシェイディグローブグランドプレーリー、TX 75050電話：（972）301 3630 Eメール：hghadia@gen10technology.com
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, AZ 85226 Phone: 480-554-3116 EMail: howard.c.herbert@intel.com
ハワードC.ハーバートインテル社MS CH7-404 5000ウェスト・チャンドラーブルバードチャンドラー、AZ 85226電話：480-554-3116 Eメール：howard.c.herbert@intel.com
Jeff Hilland Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-9489 EMail: jeff.hilland@hp.com
ジェフHilland米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-9489 Eメール：jeff.hilland@hp.com
Mike Ko IBM 650 Harry Rd. San Jose, CA 95120 Phone: (408) 927-2085 EMail: mako@us.ibm.com
マイク・コIBM 650ハリーRdを。サンノゼ、CA 95120電話：（408）927から2085 Eメール：mako@us.ibm.com
Mike Krause Hewlett-Packard Corporation, 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: +1 (408) 447-3191 EMail: krause@cup.hp.com
マイク・クラウゼヒューレット・パッカード株式会社、43LN 19410ホームステッド道路クパチーノ、CA 95014 USA電話：+1（408）447から3191 Eメール：krause@cup.hp.com
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro, Oregon 97124 Phone: 503-712-4106 EMail: dave.b.minturn@intel.com
デイブMinturnのインテルコーポレーションMS JF1-210 5200ノース・イースト・エラムヤングパークウェイヒルズボロ、オレゴン州97124電話：503-712-4106 Eメール：dave.b.minturn@intel.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com
ジム・ピンカートンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA Eメール：jpink@microsoft.com
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
Hemalシャーブロードコム・コーポレーション5300カリフォルニアアベニューアーバイン、CA 92617 USA電話：+1（949）926から6941 Eメール：hemal@broadcom.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 8836 EMail: allyn@cisco.com
アリンRomanowシスコシステムズ170 Wタスマン・ドライブサンノゼ、CA 95134 USA電話：+1 408 525 8836 Eメール：allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
トムTalpeyネットワーク・アプライアンス1601 Trapelo道＃16ウォルサム、MA 02451 USA電話：+1（781）768から5329 Eメール：thomas.talpey@netapp.com
Patricia Thaler Broadcom 16215 Alton Parkway Irvine, CA 92618 Phone: 916 570 2707 EMail: pthaler@broadcom.com
パトリシア・ターラーのBroadcom 16215アルトンパークウェイアーバイン、CA 92618電話：916 570 2707 Eメール：pthaler@broadcom.com
Jim Wendt Hewlett Packard Corporation 8000 Foothills Boulevard MS 5668 Roseville, CA 95747-5668 USA Phone: +1 916 785 5198 EMail: jim_wendt@hp.com
ジム・ウェントヒューレット・パッカード株式会社8000フットヒルズ大通りMS 5668ローズ、CA 95747から5668 USA電話：+1 916 785 5198 Eメール：jim_wendt@hp.com
Jim Williams Emulex Corporation 580 Main Street Bolton, MA 01740 USA Phone: +1 978 779 7224 EMail: jim.williams@emulex.com
ジム・ウィリアムズのEmulex社580メインストリートボルトン、MA 01740 USA電話：+1 978 779 7224 Eメール：jim.williams@emulex.com
Authors' Addresses
著者のアドレス
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-5543 EMail: paul.culley@hp.com
ポール・R. Culley、米国Hewlett-Packard Company 20555 SH 249ヒューストン、TX 77070から2698 USA電話：281-514-5543 Eメール：paul.culley@hp.com
Uri Elzur 5300 California Avenue Irvine, CA 92617, USA Phone: 949.926.6432 EMail: uri@broadcom.com
ウリElzur 5300カリフォルニアアベニューアーバイン、CA 92617、USA電話：949.926.6432 Eメール：uri@broadcom.com
Renato J Recio IBM Internal Zip 9043 11400 Burnett Road Austin, Texas 78759 Phone: 512-838-3685 EMail: recio@us.ibm.com
レナート・J Recio IBM内部ジップ9043 11400バーネット道路オースティン、テキサス州78759電話：512-838-3685 Eメール：recio@us.ibm.com
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA Phone: +1 978 689 1614 EMail: steph@sandburst.com
スティーブン・ベイリーSandburst社600連邦ストリートアンドーバー、MA 01810 USA電話：+1 978 689 1614 Eメール：steph@sandburst.com
John Carrier Cray Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 Phone: 206-701-2090 EMail: carrier@cray.com
ジョン・キャリアのCray Inc.の411まずアベニューS、スイート600シアトル、WA 98104から2860電話：206-701-2090 Eメール：carrier@cray.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。