[要約] RFC 5044は、TCPのためのマーカーPDUによるフレーミングの仕様を定めたものであり、要約すると以下のようになります。1. マーカーPDUを使用してTCPフレームを整列させる方法を定義する。 2. マーカーPDUは、TCPセッション内の特定のポイントでフレームの境界を示すために使用される。 3. 目的は、TCPフレームの整列を改善し、ネットワークのパフォーマンスを向上させることである。
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
TCP仕様用のマーカーPDUアラインドフレーミング
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.
マーカーPDUアライメントフレーミング（MPA）は、RFC 5041で説明されているように、TCPと直接データ配置プロトコル（DDP）の間の「適応層」として機能するように設計されています。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.
直接データ配置プロトコル[DDP]は、TCP [RFC793]で使用する場合、記録境界を検出するメカニズムが必要です。DDPレコードは、このドキュメントによって上層プロトコルデータユニットと呼ばれます。上層層プロトコルデータユニット（ULPDU）の境界を特定する機能は、DDPを使用してULPDUヘッダーに掲載された制御情報に基づいてアプリケーションバッファーにデータを直接配置するハードウェアネットワークアダプターに役立ちます。これは、パケットが順番に到着することを必要とせずに行うことができます。この機能の潜在的な利点は、メモリコピーのオーバーヘッドの回避と、オーダーまたはドロップされたパケットを処理するためのメモリ要件が小さいことです。
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.
一般化されたフレーミングメカニズムについては、多くのアプローチが提案されています。本質的に確率的なものもあれば、決定論的なものもあります。確率的アプローチの例は、ユーザーデータ内の他の場所でその値を防ぐ方法がないため、Octetストリームに埋め込まれた検出可能な値によって特徴付けられます。ある条件下では、受信者がアプリケーションデータを検出可能な値として誤って解釈する可能性があるため、確率です。これらの条件下では、プロトコルは受け入れられない頻度で故障する可能性があります。1つの決定論的アプローチは、オクテットストリームの既知の場所に埋め込まれたコントロールによって特徴付けられます。受信機は、組み込みコントロールを含むことが知られている場所でのデータストリームのみを調べることを保証できるため、プロトコルはアプリケーションデータを組み込み制御データと誤解することはありません。オーダーアウトオブオーダーパケットを明確に処理するには、決定論的なアプローチが望ましいです。
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プロトコルは、決定論的アプローチを使用してTCPを介して実行されるDDPのフレーミングメカニズムを提供します。これにより、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.
3. ULPは、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はFPDUをTCPに配信します。
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送信者は、FPDUをTCPストリームに入れます。送信者が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.
5. 受信機が最適化される場合とそうでない場合があります。MPA/TCPが最適化されている場合、TCPペイロードにTCPペイロード注文情報をMPAに渡すことから、TCPペイロードをMPAに渡すことを分離する場合があります。どちらの場合でも、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レシーバーは、ストリーム内の完全なFPDUを見つけて組み立て、その完全性を検証し、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は、完全なULPDUSをDDPに提供します。MPAは、MPAペイロード注文情報を渡すことから、DDPに渡すMPAペイロードをDDPに分離することもできます。
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セグメントがFPDU（FPDUアライメント）で始まるようにデータストリームをセグメント化することができます。これには、受信機に大きな利点があります。セグメントがAligned 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レシーバーにより、MPA実装のDDPが順調に受信される可能性のあるULPDUSの開始を見つけることができます。また、実装がULPDU全体を受信したかどうかを判断することもできます。その結果、MPAはすぐに使用するために、注文不足のULPDUSをDDPに渡すことができます。これにより、MPA実装のDDPが、到着時にULPDUをアプリケーションバッファーの適切な場所に配置することにより、大量の中間ストレージを節約できるようになります。
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.
注文不足のULPDUを回収するレシーバーの機能はオプションであり、起動中に送信機に宣言されています。受信者が秩序外の回復をサポートしていないと宣言した場合、送信機は制御情報を秩序外の回復に必要なデータストリームに追加しません。
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を処理しません。この場合、MPAは、最後のバイトがTCPから到着したときに各ULPDUをDDPに渡します。
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).
注文外のULPDUの回復をサポートするMPA実装は、送信者がそれらを送信したときにULPDUの順序を示すメカニズムをサポートし、中間セグメントが到着したときに示す必要があります。これらのメカニズムにより、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の一部のユーザーは、TCPチェックサムが望まれるほど強くないことに注目しています（[CRCTCP]を参照）。[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チェックを無効にすることができます。ただし、ネットワークを介したエンドツーエンド接続に、CRCが有効になっているMPAと少なくとも同じくらい良いデータの整合性があることが明らかでない限り、CRCを有効にする必要があります（たとえば、IPSECが端から端まで実装されている場合）。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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の上にあるULPSまたはアプリケーション。消費者は、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のバイトストリーム注文を使用して、配信がいつ可能かを判断します。これは、「PDUをDDPに渡す」とは特に異なります。これは一般に任意の順序で発生する可能性がありますが、配信の順序は厳密に定義されています。
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].
EMSS-効果的な最大セグメントサイズ。EMSSは、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セグメントには整数数のFPDUが含まれています。FPDUアラインメントを備えたTCPセグメントにより、他のTCPセグメントが到着または以前のセグメントと組み合わせることなく、含まれるFPDUを即座に処理できます。
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はFPDUの交換を開始します。
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は、FPDUヘッダーがTCPセグメントの開始時に正確に（ワイヤー上のTCPヘッダーのすぐ後ろ）にあるときに整列されています。
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).
イニシエーター - MPA要求フレームを送信する接続のエンドポイント、つまり実際にデータを送信する最初の接続（これはTCP synを送信するものではない可能性があります）。
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 -AWARE 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デバイス上の1つ以上のMPAで構成されている場合があります。
PAD - A 1-3 octet group of zeros used to fill an FPDU to an exact modulo 4 size.
PAD -FPDUを正確なModulo 4サイズに埋めるために使用されるゼロの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/DDP/MPA接続に結び付けるRDMAコンセプト（[Verbs -RDMA]および[RDMASEC]を参照）。
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接続要求（マップリクエストフレーム）に応答する接続エンドポイント。これは、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では、MPAに送信者から受信機へのDDPレコード境界を維持する必要があります。TCPでMPAを使用してデータを送信する場合、DDPはMPAにレコード（ULPDU）を提供します。MPAは、TCPの信頼できる伝送能力を使用してデータを送信し、適切な追加情報をTCPストリームに挿入して、MPAレシーバーがレコード境界情報を見つけられるようにします。
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つのFPDUに含まれるULPDUが1つあるように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.
標準のTCPスタックを介したMPAは、通常、FPDUがTCPのEMSSに等しい場合、TCPヘッダーとFPDUアライメントを提供できます。最適化されたMPA/TCPスタックは、FPDUがTCPのEMSS以下である限り、アライメントを維持することもできます。FPDUアライメントは一般に受信機によって望まれるため、DDPはMPAと協力して、FPDUSの長さが通常の条件下でEMSを超えないようにします。これは、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は、64768オクテットを超えるULPDUをMPAに投稿してはなりません。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にはIPデータグラムの最大長が65535オクテットになる必要があります。MPAがFPDUアライメントをサポートできるようにするには、FPDUの最大サイズがIPデータグラム内に適合する必要があります。したがって、64768オクテットのULPDU制限は、最大IPデータグラムの長さを取得して導出され、IPv4ヘッダー、TCPヘッダー、IPv4オプション、TCPオプション、および最悪のMPAオーバーヘッドの合計の最大合計長を減算しました。そして、結果を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.
MTUのリンク、IPSECに必要な追加ヘッダーの使用など、ほとんどの状況では、ほとんどの実装では、Mulpduがほとんどの実装で理論的最大値よりも大幅に小さくなることに注意してください。
On receive, MPA MUST pass each ULPDU with its length to DDP when it has been validated.
受信時に、MPAは検証されたときに各ULPDUをその長さでDDPに渡す必要があります。
If an MPA implementation supports passing out-of-order ULPDUs to DDP, the MPA implementation SHOULD:
MPAの実装がDDPへの順序外のULPDUを通過することをサポートする場合、MPA実装は次のとおりです。
* Pass each ULPDU with its length to DDP as soon as it has been fully received and validated.
* 各ULPDUをその長さでDDPに完全に受信および検証したらすぐに渡します。
* 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の順序を示すメカニズムを提供します。可能なメカニズムの1つは、各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（および以前のULPDU）が完了した時期（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が閉じた、または接続を閉じ始めたことを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 FPDUに使用する必要があります。明確な目的のために、マーカーは図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ヘッダー自体、PAD、CRC、またはULPDU内に該当するマーカーの長さは含まれません。16ビットのULPDU長さフィールドは、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.
PAD：PADフィールドは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ビット。CRCSが有効になっている場合、このフィールドにはCRC32CのCRC32Cチェック値が含まれています。これは、CRC32Cを使用してFPDUの全体を検証するために使用されます。セクション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).
予約済み：予約済みフィールドは、送信時にゼロに設定し、受信時に無視する必要があります（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ポインターは、長さ16ビットの相対ポインターであり、ULPDUの長さフィールドの先頭からマーカー全体の最初のオクテットまでのTCPストリームのオクテットの数を示す署名されていない整数として解釈されます。最も重要な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マーカーは、パケットが順番に受信されたときにFPDUの開始を識別するために使用されます。これは、データストリームの固定間隔でマーカーを見つけ（TCPシーケンス番号と相関している）、マーカー値を使用して先行FPDUスタートを見つけることによって行われます。
All MPA Markers are included in the containing FPDU CRC calculation (when both CRCs and Markers are in use).
すべてのMPAマーカーは、含まれるFPDU CRC計算に含まれています（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).
秩序外のFPDUを見つけてULPDUをDDPに渡すMPAレシーバーの機能は、実装依存です。MPA/DDPを使用すると、データストリームにマーカーの挿入を要求するために、この方法で順序外のFPDUを処理できるレシーバーが許可されます。受信者がこの方法で順序外のFPDUを扱うことができない場合、送信者にマーカーの挿入を無効にする場合があります。すべてのMPA送信者は、その使用が対立する受信機によって宣言されたときにマーカーを生成できる必要があります（セクション7.1、接続セットアップを参照）。
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-OCTET周期間隔でデータストリームにマーカーを挿入する必要があります。マーカーには、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ビットの相対バックポインターです。FPDUPTRは、マーカーがFPDUの間に落ちない限り、ULPDU長いフィールドの先頭からマーカーの最初のオクテットまでの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).
0x0000のFPDUPTR値は特別なケースです。マーカーがFPDU（前のFPDU CRCフィールドと次のFPDUのULPDU長さフィールドの間）の間に正確に落ちるときに使用されます。この場合、マーカーは次のFPDUに含まれていると見なされます。マーカーは、マーカーに続くFPDUのCRC計算に含める必要があります（CRCが生成またはチェックされている場合）。したがって、0x0000のFPDUPTR値は、マーカーの直後にFPDUヘッダー（ULPDUの長さフィールド）があることを意味します。
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.
すべてのFPDUは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番目のオクテットごとに挿入する必要があります。その結果、最初のマーカーのFPDUPTR値は0x0000です。最初のマーカーがOctetシーケンス番号seqstartで始まる場合、マーカーが挿入され、マーカーの最初のオクテットが残りの（seqnum -seqstart）mod 512の残りの場合、octetシーケンス番号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-OCTETのマルチプルがゼロのモジュロ512に落ちる可能性は低いです。MPA接続がTCPシーケンス番号11で開始された場合、1番目のマーカーは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が複数のマーカーを含めるのに十分な大きさである場合、それらはすべてTCPストリームの同じポイントを指す必要があります。FPDUのULPDU長さフィールドの最初のオクテットです。
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.
マーカー間隔に複数のFPDU（FPDUSが小さい）が含まれている場合、マーカーがFPDUの間に落ちない限り、マーカーを含む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.
MPAレシーバーは、データをDDPに渡すときにULPDU境界を保持する必要があります。MPAレシーバーは、マーカー、ヘッダー、およびCRCではなく、ULPDUデータとULPDUの長さをDDPに渡す必要があります。
An MPA implementation MUST implement CRC support and MUST either:
MPAの実装は、CRCサポートを実装する必要があり、次のいずれかを実装する必要があります。
(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.
ホストリクエストCRC抑制を行うという管理上の決定は、関与するTCP接続が少なくともエンドツーエンドのCRC32Cと同じくらい強力な検出されないエラーからの保護を提供することを保証しない限り、行うべきではありません。IPSECの暗号化整合性チェックのエンドツーエンドの使用は、そのような保護を提供する方法の1つであり、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を必要としないと宣言した場合、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フィールドは、HeaderおよびData Digestsの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.
1) マーカーがULPDUの長さフィールドの直前にない場合、CRC-32Cは、ULPDU長の最初のオクテットからすべてのULPDUおよびマーカー（存在する場合）を介して、パッドの最後のオクテット（存在する場合）に計算されます。、包括的。パッドの直後にマーカーがある場合、マーカーはこの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.
2) マーカーがFPDUのULPDU長いフィールドの最初のオクテットの直前に（つまり、マーカーがFPDUの間に落ち、したがって2番目のFPDUに含める必要がある）場合、CRC-32Cは最初のオクテットから計算されます。マーカーは、ULPDUの長さヘッダーを介して、すべてのULPDUおよびマーカー（存在する場合）を通って、パッドの最後のオクテット（存在する場合）に包括的です。
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.
無効なFPDUを処理する手順は、セクション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.
以下は、Streamの最初のFPDUとして送信されたFPDUの例の注釈付きヘックスダンプです。そのため、マーカーから始まります。FPDUには、42個のOctet 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 0004 00 ULPDU長さ0005 2A 0006 41 DDP制御フィールド、最終フラグセットで送信000C 00 DDPキュー= 0 000D 00 000E 00 000F 00 00000 00 DDP MSN = 1 0011 00 0012 00 0013 01 0014 00 DDP MO = 0 0015 000016 00 0017 000018 0018 00 DDP SEWS DATE of Zeros）...002F 00 0030 52 CRC32C 0031 23 0032 99 0033 83
Figure 5: Annotated Hex Dump of an FPDU
図5：FPDUの注釈付きヘックスダンプ
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に送信されたストリームの2番目の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制御フィールド：最終フラグで送信セット01EF 43 01F0 00予約（DDP STAG位置付きDDP STAG位置）01F1 00 01F2 00 01F3 00MSN = 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 DDP SENDデータ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は、最大上層層プロトコルデータユニット（MULPDU）をFPDUで最大のULPDUフィッティングのサイズとして定義します。空のTCPセグメントの場合、MulpduはEMSSからFPDUオーバーヘッド（6オクテット）からマーカーとパッドオクテットのスペースを差し引いたものです。
The maximum ULPDU Length for a single ULPDU when Markers are present MUST be computed as:
マーカーが存在する場合の単一のULPDUの最大ULPDU長は、次のように計算する必要があります。
MULPDU = EMSS - (6 + 4 * Ceiling(EMSS / 512) + EMSS 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:
マーカーが存在しない場合の単一のULPDUの最大ULPDU長は、次のように計算する必要があります。
MULPDU = EMSS - (6 + EMSS 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を参照）。1つ以上のFPDUがすでにTCPセグメントに詰め込まれている場合、それに応じてMulpduが減少する可能性があります。
DDP SHOULD provide ULPDUs that are as large as possible, but less than or equal to MULPDU.
DDPは、可能な限り大きいが、Mulpdu以下のULPDUを提供する必要があります。
If the TCP implementation needs to adjust EMSS to support MTU changes or changing TCP options, the MULPDU value is changed accordingly.
TCPの実装でEMSSを調整して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.
特定のまれな状況では、EMSSのサイズが128オクテット以下で縮小する場合があります。これが発生した場合、TCP送信者のMPAは、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.
1つ以上のFPDUがすでにTCPセグメントに詰め込まれている場合、残りの部屋が128オクテット未満になるように、MPAは128より小さい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.
次のセクションでは、MPAとTCPとの相互作用について説明します。このセクションでは、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.
MPA送信機は、セクション4.5で説明されているようにMulpDUを計算する必要があります。TCP実装でEMSをMPAによって決定できる場合、その値を使用する必要があります。送信側のTCP実装でEMSSを報告できない場合、MPAは現在のMTU値を使用して、さまざまな予想されるヘッダーサイズを考慮してFPDUサイズの可能性を確立する必要があります。
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スタックが提示する施設を使用して、TCPトランスミッターがFPDU境界でTCPセグメントを開始するようにする必要があります。複数のFPDUは、TCPセグメントに完全に含まれている限り、EMSS計算によって決定されるように、単一の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.
たとえば、現在のEMSSにサイズのFPDUバッファーをTCPソケットに渡し、TCP_Nodelayソケットオプションを使用してNagle [RFC896]アルゴリズムを無効にすると、通常、FPDUから始まるセグメントの多くが生じます。
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を慎重に使用できることに注意してください。将来のFPDUのMulpduを調整して、現在のEMSSに基づいてセグメントとの整合性を再確立できます。
* 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の変化によるEMSSの変化。
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で説明されているように、ULPDU_Lengthフィールドを使用してFPDU境界を識別する必要があります。受信機はマーカーを利用してFPDU境界の一貫性を確認できますが、FPDU境界を決定するためにマーカーを調べる必要はありません。
An MPA receiver MUST first verify the FPDU before passing the ULPDU to DDP. To do this, the receiver MUST:
MPAレシーバーは、ULPDUをDDPに渡す前に、最初に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レシーバーはULPDUをDDPに渡します。
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：順序付けられたTCPストリームでは、FPDUが有効なCRCを持っている場合の現在のFPDUのULPDU長さフィールドを使用して、次の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：FPDUのオーダーオブオブオーダー受信をサポートする最適化されたMPA/TCPレシーバー（セクション4.3、MPAマーカーを参照）の場合、マーカーを常に使用してFPDUの開始を見つけることができます（有効なCRCを持つ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：マーカーを使用してFPDUを見つけたため、最適化されたMPA/TCPレシーバーは、ULPDUの長さフィールド（有効なCRCを持つFPDUから）を使用して次のFPDU境界を確立することにより、次の隣接する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の長さフィールド（セクション4を参照）を使用して、ULPDUをDDPに転送する前にFPDU全体が存在するかどうかを判断する必要があります。
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では、消費者が、送信者と受信機の両方のOctetストリームの同じ場所にある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拡張機能は、Endpointで一度に両方向に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.
これは、よく知られているポートまたはサービスロケータープロトコルを使用して、MPAのDDPが操作する予定の適切なポートを見つけることで実現できます。
* 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（および他のULPS）のDDPが使用されることを確立し、MPAが動作を開始するOctetストリームのポイントを正確に見つけます。このような交渉プロトコルは、この仕様の範囲外であることに注意してください。このようなプロトコルの単純化された例を図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.
スタートアップフェーズは、正しいMPAセットアップ、交換CRCおよびマーカー構成を検証し、DDP接続を完了する前にエンドポイント間でプライベートデータを渡すために使用されます。このフェーズでは、特にフォーマットされたフレームは、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.
2番目の異なるフェーズは、FPDUSが関連するすべてのルール（CRC、マーカー、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つのエンドポイントを区別します。これは非常にarbitrary意的であり、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.
注：両方のエンドポイントが、アクティブ/アクティブ接続と呼ばれることもあると同時に接続を行うことが許可される可能性が、ワークグループによって考慮され、拒否されました。この決定にはいくつかの動機がありました。1つは、この施設を必要とするアプリケーションが少ないということでした（このドキュメントの時点では理論に他なりません）。もう1つは、施設が後で説明した「デュアルスタック」デザインで、いくつかの実装の困難を生み出したことです。最後の問題は、スタートアップでの拒否された接続を扱うことで、少なくとも追加のフレームタイプが必要であり、プロトコルを複雑にするためのより多くの回復アクションが必要だったことでした。これらの問題のいずれも圧倒的ではありませんでしたが、グループと実装者はこれらの問題を解決するための作業を行うように動機付けられていませんでした。このプロトコルには、これらのアクティブ/アクティブな起動の試みを検出する方法が含まれているため、拒否され、エラーが報告されます。
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は、どの側がイニシエーターまたはレスポンダーであるかを決定する責任があります。クライアント/サーバータイプULPSの場合、これは簡単です。ピアピアULPS（TCPスタイルのアクティブ/アクティブスタートアップを利用する可能性がある）の場合、一部のメカニズム（この仕様で定義されていない）を確立する必要があります。または、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フレーム」または（バイト順）に設定する必要があります。レスポンダーモードの受信機は、このフィールドを同じ値で確認し、接続を閉じて、他の値が検出された場合はローカルにエラーを報告する必要があります。レスポンダーモード送信者は、このフィールドを固定値「MPA ID repフレーム」または（バイト順）に設定する必要があります。イニシエーターモードレシーバーは、このフィールドを同じ値で確認し、接続を閉じて、他の値が検出された場合はローカルにエラーを報告する必要があります。
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：このビットは、エンドポイントの必要なマーカーの使用を宣言します。MPA要求フレームでこのビットが「1」である場合、イニシエーターは、レスポンダーから送信されたFPDUでマーカーが必要であると宣言します。MPA応答フレームで「1」に設定すると、このビットは、イニシエーターから送信されたFPDUでマーカーが必要であると宣言します。受信した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 Replyフレームでは、このビットは拒否された接続ビットです。これは、プライベートデータに記載されている接続パラメーターの受け入れ「0」または拒否「1」を示すために、レスポンダーULPによって設定されています。
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レシーバーはPD_Length値とプライベートデータをULPに渡す必要があります。
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.
プライベートデータ：このフィールドには、ULPSによって定義された値が含まれている場合や、存在しない場合があります。プライベートデータフィールドの長さは0〜512オクテットでなければなりません。ULPSは、これらの制限内でこのフィールドをサイズ、設定、検証する方法を定義します。プライベートデータの使用法については、セクション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.
2. MPAがレスポンダーモードで開始されると、MPAの実装は、完全なMPA/DDP操作を入力する前にMPA要求フレームが受信および検証されるまで待機する必要があります。
If the MPA Request Frame is improperly formatted, the implementation MUST close the TCP connection and exit MPA.
MPA要求フレームが不適切にフォーマットされている場合、実装はTCP接続を閉じて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がサプリングしたプライベートデータが含まれる場合があります。実装はMPAを終了し、TCP接続を開いたままにする必要があります。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 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.
MPA要求フレームが適切にフォーマットされ、プライベートデータが許容できる場合、実装は拒否された接続ビットが「0」に設定されたMPA応答フレームを返す必要があります。MPA応答フレームには、ULPがサプリングしたプライベートデータが含まれる場合があります。対応者は、受信したデータをFPDUSとして解釈し、受け取ったULPDUをDDPに渡す準備をする必要があります。
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.
注：リクエストと返信フレームが受信されるまでマーカーを処理する受信者の能力は不明であるため、これが発生する前にFPDUを送信することは不可能です。
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.
MPA応答フレームが不適切にフォーマットされている場合、実装はTCP接続を閉じて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」に設定されている場合、実装はMPAを終了し、TCP接続を開いたままにする必要があります。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として解釈し、DDP ulpDUSをFPDUSとして送信します。
4. MPA Responder mode implementations MUST receive and validate at least one FPDU before sending any FPDUs or Markers.
4. MPAレスポンダーモードの実装は、FPDUまたはマーカーを送信する前に、少なくとも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.
注：この要件は、FPDUが到着する前にイニシエーターの時間をフル操作に導入するために、イニシエーターでの潜在的な人種条件を避けるために存在します。これはまた、大まかなコンセンサスに達する前に、ワークグループでいくつかの議論の対象となりました。この要件を排除すると、一部のタイプのアプリケーションでより速いスタートアップが可能になります。ただし、特定の実装（特に「デュアルスタック」）がはるかに難しくなります。
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リクエスト、および返信フレーム形式を参照）、TCP/DDP接続を閉じ、ERRORが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.
6. 受信したプライベートデータフィールドは、接続をさらに検証し、DDPまたはその他のULPパラメーターをセットアップするために、両端で消費者が使用できます。イニシエーターULPは、プライベートデータフィールドを検証した結果、TCP/MPA/DDP接続を閉じることができます。Responderは、Private Dataの検証が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).
7. 最初のFPDUが送信される場合、マーカーが有効になる場合、送信された最初のオクテットは特別なマーカー0x00000000であり、その後FPDU（FPDUのULPDU長さフィールド）の開始が続きます。マーカーが有効になっていない場合、送信された最初のオクテットはFPDU（FPDUのULPDU長さフィールド）の開始です。
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応答フレームの違いを使用して、誤った「イニシエーター/イニシエーター」スタートアップをチェックする必要があります。実装は、Responderモードで開始されたときに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の実装は、スタートアップフレームのセット全体を待っている間、合理的なタイムアウトを実装する必要があります。これにより、特定のサービス拒否攻撃が防止されます。ULPSは、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".
* アクティブおよびパッシブ側は、おそらくソケットAPIを使用して、通常の方法でTCP接続を起動します。彼らは、ある量のストリーミングモードデータを交換します。ある時点で、片側（MPAイニシエーター）は、「こんにちは、MPA/DDPモードに行きましょう」と効果的に言うストリーミングモードデータを送信します。
* 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レスポンダー）がこのストリーミングモードメッセージを取得すると、消費者は「私はあなたのこんにちはを認め、現在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.
* 開始消費者は、MPAリクエストフレームを送信するイニシエーターモードでMPAスタートアップを有効にします。この例にはプライベートデータメッセージは必要ないと想定されていますが、そうすることは可能です。開始MPA（および消費者）は、MPA接続が受け入れられるのを待ちます。
* 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.
* 接続要求を受け入れるために、応答する消費者は適切なAPIを使用してTCP/MPA接続をDDPエンドポイントに結合し、MPA/DDPをフル操作に可能にします。フル操作に進む過程で、MPAはMPA応答フレームを送信します。MPA/DDPは、FPDUを送信する前に最初の着信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.
* 開始MPAはMPA返信フレームを受け取り、このメッセージを消費者に報告します。消費者はMPA/DDP接続を受け入れるか、TCP接続を閉じてリセットしてプロセスを中止できます。
* 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.
* 接続が許容可能であると判断すると、開始消費者は適切なAPIを使用してTCP/MPA接続をDDPエンドポイントに結合し、MPA/DDPを完全に動作させます。MPA/DDPは、MPA FPDUとして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エンドポイント（インフィニバンドおよび[動詞RDMA]のキューペア、またはQPと呼ばれる）は、保護ドメインに関連付けられている必要があります。保護ドメインに関連付けられる前に、受信操作をエンドポイントに投稿することはできません。実際、インフィニバンドと提案された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クライアントのIDに依存するアプリケーションがいくつかあります。たとえば、ユーザーセッションで複数の接続が必要な場合、これらすべての接続が単一の保護ドメインを使用することが非常に望ましいです。注：保護ドメインの使用については、[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).
Infiniband、dat apis [dat-api]、およびit-api [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.
プライベートデータを使用して、接続の両端がRDMA読み取り容量などの問題に互換性のあるRDMAエンドポイントを構成していることを確認することもできます（[RDMAP]を参照）。クライアントのIDの確立など、さらに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.
このプライベートデータを交換する方法はいくつかあります。たとえば、Infiniband仕様には、実際に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.
大量のプライベートデータまたはより多くの交渉が必要な場合、MPAを有効にする前にTCPストリーミングモードメッセージを交換することができます。
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).
注：TCP接続シーケンスでMPAが開始されるときの正確な順序は、実装依存です。上記の図は、1つの可能なシーケンスを示しています。また、レスポンダーの「syn-ack」へのイニシエーター「ACK」は、MPA要求フレームを含む同じTCPセグメントに結合することができます（TCP RFCSで許可されています）。
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.
* アクティブサイド（消費者の開始）は、TCPエンドポイント（MPA/DDP/RDMAにアップグレードし、プライベートデータが予想される）から宛先アドレスとポートへの接続を要求します。
* 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.
* パッシブ側（応答消費者）は、通常どおりTCP接続要求を受け取り、INETDやTCPServerなどの通常の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.
* 開始消費者は、InitiatorモードのMPAスタートアップが、送信するプライベートデータメッセージを含む初期MPAリクエストフレームを送信できるようにします。開始MPA（および消費者）は、MPA接続が受け入れられるのも待ち、返されたプライベートデータも待ちます。
* 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接続を閉じたり、RETURNメッセージで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.
* 接続要求を受け入れるために、応答する消費者は適切なAPIを使用してTCP/MPA接続をDDPエンドポイントに結合し、MPA/DDPをフル操作に可能にします。完全操作に進む過程で、MPAはMPA Replyフレームを送信します。これには、適切な消費者対応を含む消費者が提供するプライベートデータが含まれます。MPA/DDPは、FPDUを送信する前に最初の着信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」に設定し、TCP接続を閉じる可能性がある、ULPサプライされたプライベートデータ（拒否の理由で）を使用してMPA返信フレームを送信します。
* 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.
* 開始MPAは、プライベートデータメッセージを使用してMPA Replyフレームを受信し、提供されたプライベートデータを含む消費者にこのメッセージを報告します。
If the "Rejected Connection" bit is set to a '1', MPA will close the TCP connection and exit.
「拒否された接続」ビットが「1」に設定されている場合、MPAはTCP接続と終了を閉じます。
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.
「拒否された接続」ビットが「0」に設定され、MPAの応答フレームプライベートデータから接続が許容できると判断すると、開始消費者は適切なAPIを使用してTCP/MPA接続をDDPエンドポイントに結合しますしたがって、MPA/DDPをフル操作に可能にします。MPA/DDPは、MPA FPDUとして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の実装は、一般に「デュアルスタック」アーキテクチャの一部として実装されると予想されます。1つのスタックは従来のTCPスタックで、通常はソケットインターフェイスAPI（アプリケーションプログラミングインターフェイス）があります。2番目のスタックは、独自のAPIを備えたMPA/DDPスタックと、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.
TCP接続セットアップは通常、TCPスタックで行われます。これにより、通常の命名メカニズムとアドレス指定メカニズムを使用できます。また、セキュリティの脅威に対する接続のセットアップを「強化」するために使用されるメカニズムは、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).
MPAがDDPにDDPにDDPに提供する必要があります。TCP接続の優雅な閉鎖がTCPによって受信されていることを認識してください（例：FINが受信されます）。
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接続は、閉じられ、終了した、または紛失しました。これには、タイムアウトによる紛失、レトリが多すぎる、RESTのRECONIS、またはFINが受け取ったFINが含まれます。
2 Received MPA CRC does not match the calculated value for the FPDU.
受信した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.
3 CRCが有効である場合、MPAマーカー（有効な場合）を受信し、ULPDUの長さフィールドはFPDUの開始に同意しません。以前のULPDUの長さフィールドから決定されたFPDU開始がMPAマーカーの位置と一致しない場合、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があらゆるタイプのエラーを提供したら、その半分の接続に追加のFPDUを渡したり配信したりしてはなりません。
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.
MPAは、その接続の受信側で検出されたエラーに続いて半分接続にFPDUを配信しないため、DDPのULPは接続を解体すると予想されます。これは、1つ以上の最後のメッセージが反対側の半分の接続で送信されるまで発生しない場合があります。これにより、診断エラーメッセージを送信できます。
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ヘッダーは含まれていません。MPAレシーバーは、FPDU境界に適切に配置された場合、FPDUとして検証できないパケットが到着したときにDDPにエラーを報告します。サードパーティは、TCP、MPA、およびDDPに有効なパケットを送信することもできますが、有効なバッファーをターゲットにしないこともできます。これらのタイプの攻撃は最終的に接続の喪失をもたらし、したがって、DOS（サービス拒否）攻撃の一種になります。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の動作とは無関係に、サードパーティはICMPメッセージを使用して、パスMTUを非常に小さなサイズに減らすことができ、パフォーマンスが同様に深刻な影響を与えることができます。ICMPパケットのPATH 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ストリームは確立された状態でTCPストリームを必要とするため、特定の種類の従来の形式のワイヤ攻撃は適用されません。MPAストリームを確立するためにエンドツーエンドの握手が発生している必要があります。したがって、適用されるスプーフィングの唯一の形式は、リモートノードがパケットを送信および受信できる場合のものです。しかし、この制限があっても、ストリームはまだ次のスプーフィング攻撃にさらされています。
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.
ネットワークベースの攻撃者は、法的MPA/DDP/RDMAPピアになりすまし（法的IPアドレスをスプーフィングすることにより）、被害者と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.
ネットワークベースの攻撃者が、MPAによって受け入れられるパケットを削除、注入、リプレイ、または変更する機能を備えている場合（たとえば、TCPシーケンス番号が正しい、FPDUは有効であるなど）、ストリームはに公開できます。中間の攻撃。攻撃者は、[DDP]と[RDMAP]のサービスを使用して、関連するデータバッファーの内容を読み取ったり、関連するデータバッファーの内容を変更したり、バッファーへのさらなるアクセスを無効にしたりする可能性があります。接続セットアップシーケンスやTCPに対するその他の攻撃を使用して、サービスの拒否を引き起こすことができます。この形式の攻撃の唯一の対策は、MPA/DDP/RDMAPストリームを確保する（つまり、整合性保護）か、中間のタイプの攻撃を防ぐための物理的セキュリティを提供しようとすることです。
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などのエンドツーエンドの整合性の保護と認証です。ストリームまたはセッションレベルの認証と整合性保護が使用されない場合、中間の攻撃が発生し、スプーフィングと改ざんを可能にします。
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ストリームに適用できます。
1. Session confidentiality - protects against eavesdropping.
1. セッションの機密性 - 盗聴から保護します。
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. パケットごとの整合性 - FPDUのネットワークベースの変更（DDPサービスを通じてバッファーコンテンツに間接的に影響を与える）によって行われた改ざんから保護します。
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."
「チャネルバインディングの概念により、アプリケーションは、異なるネットワークレイヤーでの2つの安全なチャネルのエンドポイントが、あるチャネルでの認証を他のチャネルでセッション保護に結合することによって同じであることを証明できます。チャネルバインディングの使用により、アプリケーションが委任できるようになります。より低いレイヤーへのセッション保護。これにより、一部のアプリケーションのパフォーマンスが大幅に向上する可能性があります。」
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パケットに含まれるFPDUと同じ方法でこれらのパケットに含まれる復号化されたFPDUを処理します。
MPA implementations MUST implement IPsec as described in Section 9.4 below. The use of IPsec is up to ULPs and administrators.
MPAの実装は、以下のセクション9.4で説明されているようにIPSECを実装する必要があります。IPSECの使用は、ULPSおよび管理者に任されています。
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加速ハードウェアは限られた数のアクティブなインターネットキーエクスチェンジプロトコル（IKE）フェーズ2セキュリティアソシエーション（SAS）のみを処理できる可能性があるため、フェーズ2の削除メッセージは、数字を維持する手段としてIDLE SASに対して送信される場合があります。アクティブフェーズ2 SASの最小限。IKE Phase 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 3723 may be updated to the newer version of IPsec; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RDDPのIPSEC要件は、RFC 3723 [RFC3723]によってプロファイルされたRFC 3723 [RFC3723]で紹介されているように、RFC 2401 [RFC2401]および関連RFCで指定されたIPSECのバージョンに基づいています。RFCS。RDDPプロトコルの重要な初期のアプリケーションの1つは、ISCSI [ISER]での使用です。RDDPのIPSEC要件は、IPSECの共通プロファイルをISCSIおよびRDDPプロトコルで使用できるようにすることにより、その使用を容易にするためにIPSECの要件に従います。将来、RFC 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に任されています。
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を使用して左側に表示されている機能を使用して開始できます。または、右側に表示されている機能を使用して開始し、接続セットアップのポイントで左側に移行できます。MPAは、セクション7.1.2で説明されているように、「完全な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スタックとインターフェイスを引き続き使用しています。
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を封じ込めるのに十分な大きさのEMSSを使用すると、すべてのTCPセグメントの最初のオクテットがFPDUで始まるように、発信TCPストリームをセグメント化します。複数のFPDUは、TCPセグメントに完全に含まれている限り、単一のTCPセグメントに詰め込むことができます。
* Report the current EMSS from the TCP to the MPA transmit layer.
* 現在のEMSSをTCPからMPA送信層に報告します。
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およびEMSSの変更中、またはTCPの受信ウィンドウサイズ（RWIN）が小さすぎると、上記のセグメンテーションルールに準拠していないFPDUを送信する必要がある場合があります。
A possible, but less desirable, alternative is to use IP fragmentation on accepted FPDUs to deal with MTU reductions or extremely small EMSS.
可能性のある、しかしあまり望ましくない代替案は、受け入れられたFPDUでIP断片化を使用して、MTU削減または非常に小さなEMSSに対処することです。
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セグメンテーション境界を保持しようとする必要があります。
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.
最適化されたMPA/TCP送信者は、DDPメッセージが十分に大きい場合、単一のFPDUでTCPセグメントをEMSSに記入します。DDPメッセージはTCPセグメントに正確に適合しない可能性があるため、「メッセージテール」が発生することが多く、単一のTCPセグメントよりも小さいFPDUになります。さらに、一部のDDPメッセージはEMSSよりもかなり短い場合があります。小さな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.
別の可能性は、アプリケーションが応答を待つ前に複数のメッセージ（FPDU）を同じエンドポイントに送信している可能性があることです。この場合、セグメンテーションポリシーは、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実装は、多くの場合、Nagle [RFC896]アルゴリズムを利用して、往復レイテンシが十分に大きくなるとセグメントがACKが到着する前にセグメントを完全に埋めることができるようにします。アルゴリズムは、ULPがセグメントを埋めることができるまで、またはACKが遠くから到着するまでTCPセグメントの送信を遅らせることにより、これを行います。したがって、このアルゴリズムは、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スタックで使用すると、Nagleおよび同様のアルゴリズムは、TCPセグメントに複数のFPDUを「梱包」する可能性があります。
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は複数のFPDUをTCPセグメントに詰め込むことができます。これが行われると、TCPセグメントはより完全に利用できますが、FPDUSのサイズの制約により、セグメントはEMSSに埋められない場合があります。残りのTCPセグメントスペースのサイズをDDPに通知する動的マルプドゥは、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.
MPAレシーバーは、複数のFPDUを含むTCPセグメントの処理をさらに行うことに注意してください。これは、一部の受信機の実装のパフォーマンスに影響を与える可能性があります。
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.
NagleがDDP/MPAで役立つかどうかを判断するのはULP次第です。MPA/DDPを利用することが期待されるアプリケーションの多くは、Nagleによって引き起こされる追加の遅延を回避することを好むことに注意してください。このようなシナリオでは、送信機に梱包する機会が最小限に抑えられ、受信機がこの予想される動作に対してパフォーマンスを最適化することを選択できると予想されています。
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実装は、利用可能なFPDUをTCPセグメントに詰めて、セグメントがEMSSに満たされるようにすることができます。TCPセグメントが送信用に準備されているときにTCPセグメントを埋めるのに十分でない場合、TCPはセグメントを部分的に埋めたり、Nagleアルゴリズムを使用してULPがより多くのデータを投稿するのを待っています。
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の処理をサポートするSIDE 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 RFCSが必要とする他のチェックに合格している必要があります。
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).
これは、データを使用する前に完全に注文する必要があることを意味するものではありません。実装は、順序外セグメントを受け入れ、それらをサック[RFC2018]、およびギャップを埋めるために必要なセグメントを受信する前に、すぐにMPAに渡すことができます。MPAは、これらのセグメントが完全なFPDUである場合、または完全なFPDUに結合して、到着時にULPDUをDDPに渡すことを許可することができます。DDPは、渡されたULPDUを使用してDDPセグメントを「配置」します（詳細については[DDP]を参照）。
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計算と受信したFPDUのその他のチェックを実行するため、MPA/TCP実装により、データを既に受信および処理したTCPセグメントは（TCP Rectries中に発生する可能性がある）既に受信および処理されたFPDUを上書きしないようにします。これにより、複製データが既に検証されたFPDUを破損する可能性が回避されます。
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セグメントの順序を示すメカニズムを提供します。考えられるメカニズムの1つは、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ストリーム）が完了した時期を示すメカニズムも提供します。考えられるメカニズムの1つは、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).
MPAは、ULPDUが完了したときにDDPに順序付けと完了の適応症を使用します。MPAはFPDUをDDPに配信します。DDPは適応症を使用して、詳細についてはメッセージをDDPコンシューマーに「配信」します（詳細については[DDP]を参照）。
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は、上記の2つのメカニズムを利用して、DDPの消費者が同意する配信セマンティクスを確立します。これらのセマンティクスは、[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へのセグメントのオーダーアウトオブオーダーの通過と組み合わせると、受信したデータの大幅なバッファリングとコピーを回避できます。
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セグメントの境界でFPDUを開始するため、受信最適化された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.
一部のMPA送信者は、TCPの実装が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にマーカーが存在する（有効）により、最適化されたMPA/TCPレシーバーがこれらの障害にもかかわらずFPDUを回復することができますが、受信機で追加のバッファリングを利用する必要がある場合があります。
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と完全な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.
* TCPセグメント内の複数のFPDUは、順番または順番に整列し、完全に含まれています。これらは、検証されたらすぐにDDPに渡すことができ、注文が確立されたときに配信できます。
* 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セグメントにおける無整成または不完全なFPDU（および潜在的に他の完全なFPDU）の組み合わせ：FPDUが完全に存在する場合、または既に利用可能な部分を完了することができる場合、検証されたとすぐにDDPに渡すことができます。注文が確立されたとき。
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消費者に対して透明です。
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をフラグメントしないように設定する必要があります。したがって、PATH MTUが変更されると、中間デバイスが大きすぎる場合はIPデータグラムをドロップし、Source MTUが変更されたことをソースTCPに伝えるICMPメッセージで返信します。これにより、TCPは新しいパスMTUサイズに適合したセグメントを放出します。したがって、ほとんどの条件下での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フラグメントをドロップし、[RFC792]（断片化が必要とDFセット）に従ってICMPメッセージで返信して、リモートピアにTCPセグメントのサイズを変更するよう指示します。
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メッセージが生成されることをお勧めします。
3. multiple IP reassembly buffers, of effectively unlimited size.
3. 効果的に無制限のサイズの複数のIP再組み立てバッファー。
4. support an IP reassembly buffer for the largest IP datagram (64 KB).
4. 最大のIPデータグラム（64 kb）のIP再組み立てバッファーをサポートします。
5. support for a large IP reassembly buffer that could span multiple IP datagrams.
5. 複数のIPデータグラムにまたがる可能性のある大規模なIP再組み立てバッファーのサポート。
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はTCP ACKです。これは、完全なIPデータグラムがTCPに配信された場合にのみ発生する可能性があります。このため、最悪の場合、病理学的シナリオでは、最大の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].
リモートピアがICMP MTUの更新を受信したときにデータストリームの再セグメント化を実装しない場合、反対側のピアが大きすぎるトランスポートセグメントサイズを使用して再送信を続けるため、進行状況を停止することが可能であることに注意してください。このデッドロックシナリオは、接続セットアップ後にファブリックMTU（ラストホップMTUではない）が減少した場合と変わりません。また、リモートノードの動作は[RFC1122]に準拠していません。
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でTCPを使用する場合、またはMPA FPDUが複数の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アライメントの紛失は多くの場合、FPDUが不完全であることを意味するため、TCP実装のMPAには、ローカルに接続されたリンクのMTU以下のFPDUを回復するのに十分な大きさの再組み立てバッファーが必要です（これは可能な限り最大の広告TCPでなければなりませんパスmtu）。MTUが140オクテットより小さい場合、最小FPDUサイズをサポートするために少なくとも140オクテットのバッファーが必要です。140のオクテットでは、128の最小マルプドゥ、2オクテットのパッド、ULPDU_LENGTH 2、CRCの4、および可能なマーカーのスペースを可能にします。いつものように、追加のバッファリングはパフォーマンスを向上させる可能性があります。
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アルゴリズムをデッドロックすることが可能であることに注意してください。PATH MTUが削減された場合、FPDUアライメントでは、データストリームを新しいPATH MTUに再セグメント化するためにソースTCPが必要です。ソースMPAはこの条件を検出し、MPAセグメントサイズを削減しますが、既にソースTCPに掲載されているFPDUは再セグメント化され、FPDUアライメントが失われます。宛先がTCP再組み立てバッファをサポートしていない場合、これらのセグメントは決して成功裏に送信できず、プロトコルがデッドロックします。
When a complete FPDU is received, processing continues normally.
完全なFPDUを受信すると、通常は処理が続きます。
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の分析であり、MPAをTCPと（典型的なTCP実装の変更とともに）統合して、システム全体のバッファリングとオーバーヘッドを削減することが役立つ理由です。
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のハイレベルの目標の1つは、直接データ配置プロトコル[DDP]と組み合わせると、DDPペイロードの最終上層層プロトコル（ULP）バッファーへの注文外配置を可能にする場合、十分な情報を提供することです。DDPは、ULPバッファーがULPバッファーを使用できることをULPに通知するULPバッファーにデータを配置する行為を分離することに注意してください。DDP用語では、前者は「配置」として定義され、後者は「配信」として定義されます。MPAは、TCPセグメントが順番に到着したときの最終的なULPバッファー位置での直接データ配置のサポートを含む、ULPへのデータの順序配信をサポートしています。事実上、目標は、TCPを受信するために事前にポストされたULPバッファーを使用することです。TCP（MPAおよびDDPを使用）によるULPプロトコルデータユニット（PDU）の再組み立てが、ULPバッファーで、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送信者がHeaderアラインメントを行うことを好みます。ここでは、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) TCPセグメントにはFPDUの積分数があること（経路MTUが変化していない条件下）。
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ワイヤの動作にほとんど効果がないことを示しています。
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ダイジェストが必要です。MPAはこれらの機能をTCPストリームに追加して、TCPを介したDDPがSCTPよりも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が輸送層から兆候を受け取ることができます。フレーミング層として、MPAはDDP PDUの内容を認識していません。これは、DDPへの配達のために完全なPDUを受け取っており、必要に応じて再組み立てしたことだけです。
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は基礎となるファブリックのEMSよりも大きくないMPA A 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.
この条件が発生しない場合のエッジケースは処理されますが、高速パス上にいる必要はありません。
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には、Hostメモリの正しい場所に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セグメントは自己記述的であるため、ULP受信バッファーにULPペイロードをすぐに配置することができないDDPセグメントが故障している可能性があります。
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へのデータ配信は、データが送信された順序で保証されています。DDPは、TCPが完全なバイトストリームを認めた後のULPへのデータ配信のみを示します。
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.
ヘッダーアライメントと完全なFPDUが一般的なケースである場合、重要な受信機の最適化を実現できます。最適化により、受信機では大幅に少ないバッファーを利用し、FPDUあたりの計算が少なくなります。正味の効果は、TCPベースのソリューションが経済的な方法で10G以上にスケーリングできるようにする「フロースルー」レシーバーを構築する機能です。最適化は、複数のプロトコルレイヤー（データリンクレイヤー（イーサネットなど）、ネットワークおよびトランスポートレイヤー（TCP/IPなど）、さらにはTCPの上のULP（例：MPA））を処理する受信機のハードウェア実装に特に関連しています。/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アプローチは、ULPのバッファーをTCP受信バッファとして使用できるようにするためです。アプリケーションが十分な量のバッファリングを事前ポストし、各TCPセグメントが適切なアプリケーションバッファーにペイロードを配置するのに十分な情報を持っている場合、オーダーアウトオブオーダーTCPセグメントが到着すると、ULPバッファーに直接配置される可能性があります。ただし、配置情報を備えた完全なFPDUが受信機が利用できる場合にのみ配置でき、FPDUの内容にはデータを正しいULPバッファーに配置するのに十分な情報が含まれています（たとえば、DDPヘッダーが利用可能です）。
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
Where K1 and K2 are implementation-dependent constants and EMSS is the effective maximum segment size.
ここで、K1とK2は実装依存定数とEMSSが有効な最大セグメントサイズです。
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の接続と1500 BのEMSを持つ1 GB/秒リンクには、15 MBのメモリが必要です。多くの場合、接続の数はネットワーク速度でスケールを使用し、高速で状況を悪化させました。
FPDU Alignment would allow the receiver to allocate BufferSizeAF (Buffer Size, Aligned FPDU) octets:
FPDUのアライメントにより、受信者はバッファ型を割り当てることができます（バッファーサイズ、アライメントされたFPDU）オクテット：
BufferSizeAF = K2 * EMSS
buffersizeaf = k2 * emss
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.
同じ条件で。FPDUアラインされたレシーバーは、KBの〜100の範囲のメモリを必要とする場合があります。これは、オンチップメモリに可能であり、「フロースルー」デザインを有効にします。宛先バッファに直接配置されます。接続のほとんどが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年間、これが事実であり、傾向は継続すると予想されています。イーサネットの速度は1000（10メガビット/秒から10ギガビット/秒まで）でスケーリングされていますが、ボリュームCPUアーキテクチャのバス帯域幅は〜2 Mb/secから〜2 gb/秒までスケーリングされています（PC-XTバスからPCIへ-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アライメントアプローチを使用すると、ネットワーク速度が向上するにつれて、受信バッファリングが優雅にスケーリングされる（つまり、線形スケーリングよりも少ない）と予想されます。
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セグメントで運ばれるという仮定があります。実際には、FPDUアライメントがない場合、FPDUは2つ以上のTCPセグメントで運ぶことができます（たとえば、PATH MTUが削減された場合）。
----++-----------------------------++-----------------------++-----
+---||---------------+ +--------||--------+ +----------||----+
| 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オクテットストリームに自由に配置されていないAligned 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など）（順に、または順番に）を掲載することは次のとおりです。
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.)
1. ネットワークレイヤー処理（IPフラグメントではないと仮定すると、データリンクレイヤーフレーム全体に1つのIPデータグラムが含まれています。IPフラグメントはローカルバッファーで再組み立てする必要があります。これはパフォーマンス最適化の目標ではありません。）
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. 5タプル（IP SRC、IP DST、TCP SRCポート、TCP DSTポート、プロトコル）を使用して、着信TCPセグメントを分類します。
3. Find FPDU message boundaries.
3. FPDUメッセージの境界を見つけます。
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).
TCPセグメントが順調になっている場合は、受信機が管理したMPA状態情報を使用して、以前のFPDUメッセージ（＃n-1）が現在のTCPセグメントXで終了する場所を計算します（以前、MPAレシーバーがFPDUの最初の部分を処理したときに＃n-1、MPA長フィールドを使用してFPDU＃n-1を完了するために残りのバイト数を計算しました）。
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の2番目の部分のローカルバッファー、2番目の部分、長さのホストバッファーアドレス）。
Calculate the octet offset into the TCP segment for the next FPDU #N.
次のFPDU #NのTCPセグメントにOctetオフセットを計算します。
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セグメントのバッファリングが必要です。MPAベースのマーカーを使用して、FPDU境界がどこにあるかを計算します。
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.
完全なFPDUが利用可能な場合、上記の注文のアルゴリズムと同様の手順が使用されます。ただし、欠落セグメントが到着すると、CRCが欠落セグメントの場合に計算された後、このTCPセグメントをCRCエンジンを介して実行する必要があるため、追加の複雑さがあります。
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：TCPヘッダーの直後に配置されたFPDU
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.
1) データリンクレイヤー処理（フレーム全体） - 通常、CRC計算を含みます。
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.)
2) ネットワークレイヤー処理（IPフラグメントではないと仮定すると、データリンクレイヤーフレーム全体に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).
a. 5タプル（IP SRC、IP DST、TCP SRCポート、TCP DSTポート、プロトコル）を使用して、着信TCPセグメントを分類します。
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.
a. ヘッダーが整列していない場合は、前のセクションで定義されているアルゴリズムを参照してください。
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.
5) TCPセグメントが順番または順調になっている場合、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）FPDUパッキングを処理するために、TCPセグメント内のすべてのFPDUが消費されるまで＃5にループします。
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セグメントを分類し、維持されるフローの1つに関連付ける必要があります。NO 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アラインドレシーバーアルゴリズムは大幅に単純です。FPDUの一部を局所的にバッファリングする必要はありません。状態情報へのアクセスも実質的に簡素化されます。通常のケースでは、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.
Aligned 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受信のアルゴリズムに従う必要があります。
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はEMSSをMPAに公開します。MPAはEMSSを使用してMulpDUを計算し、それをDDPに公開します。これはULPです。DDPはMulpDUを使用してペイロードをセグメント化して、MPAから送信される各FPDUが完全に1つのTCPセグメントに適合するようにします。これはワイヤプロトコルに影響を与えず、この情報の公開は、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 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層に提供されるULP（つまり、MPA上のDDP）メッセージは、Mulpduサイズにセグメント化されます。ULPメッセージのサイズはMulpDUによって制限されているため、単一のULPメッセージを単一のTCPセグメントにカプセル化できると想定されています。したがって、一般的なケースでは、放出されるTCPセグメントの数は増加しません。より小さなULPメッセージの場合、送信者はパッキングを適用することもできます。つまり、送信者はできるだけ多くの完全なFPDUを1つのTCPセグメントに詰めます。常に完全なFPDUを持つという要件は、放出されるTCPセグメントの数を増やす可能性があります。通常、ULPメッセージのサイズは、数バイトから複数のEMSS（たとえば、64 kbytes）までさまざまです。場合によっては、ULPは送信のために一度に複数のメッセージを投稿し、送信者に梱包の機会を与えることがあります。複数のFPDUが送信に利用可能であり、FPDUがTCPセグメントにカプセル化され、TCPセグメントに次の完全なFPDUを含める余地がない場合、別のTCPセグメントが送信されます。このコーナーケースでは、TCPセグメントの一部はフルサイズではありません。最悪のシナリオでは、ULPはEMSS/2 1であり、伝送に使用できる複数のメッセージを持つFPDUサイズを選択できます。このFPDUサイズの選択が不十分な場合、平均TCPセグメントサイズはEMSSの約1/2であり、放出されるTCPセグメントの数は、すべてのTCPで整数数の完全なFPDUをカプセル化する要件なしに可能なものの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/OSを使用したスループットアプリケーションは、EMSSを最大限に活用することが期待されています。（EMSと比較して）多くの小さな顕著なバッファーを備えた別のクラスのアプリケーションは、該当する場合は梱包を使用することが期待されています。トランザクション指向のアプリケーションも最適です。
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は、元々送信された正確なセグメント（[RFC793]、セクション2.6および3.7（「ウィンドウの管理」の下）および[RFC1122]、セクション4.2.2.15を参照）の再送信をサポートしています。ありそうもないイベントでは、元のセグメントの一部がリモートピア（たとえば、付録A.4に記載されているように、ミドルボックスの再セグメント化の中間箱と非最適化されたMPA/TCP送信者の再セグメント）によって受信され、認められています。欠落しているオクテットのみを再送信することにより、より適切に利用可能な帯域幅の利用が可能になる場合があります。最適化されたMPA/TCPがFPDUを完了した場合、わずかな帯域幅損失がある可能性があります。
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セグメント数の変更が影響を与える可能性のある別の領域は、スロースタートと輻輳回避の領域です。アルゴリズムは、最終的にはセグメントが削除されたために、輻輳のソースのオーバーヘッドペンセグメントに焦点を当てているため、スロースタートの指数増加は1秒あたりのセグメントで測定されます。最適化されたMPA/TCPのスロースタート指数帯域幅の成長は、TCP実装に似ています。混雑回避により、パケットドロップ後に回復する際に利用可能な帯域幅の線形成長が可能になります。スロースタートの分析と同様に、最適化されたMPA/TCPはアルゴリズムの動作を変化させません。したがって、セグメントとEMSSの平均サイズは、送信者の帯域幅成長の評価における主要な要因ではありません。最適化された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セグメントの数に最も大きな影響を及ぼします。特定のULPSの最悪の効果（EMSS/2 1の平均メッセージサイズ/EMSS）は、TCPセグメントの数の最大2倍の増加と認識によって制限されます。実際には、その効果はわずかになると予想されます。
Appendix C. IETF Implementation Interoperability with RDMA Consortium Protocols
付録C. RDMAコンソーシアムプロトコルとの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コンソーシアムプロトコルドキュメント（Draft-Culley-IWARP-MPA-V1.0.PDF [RDMA-MPA]、Draft-Shah-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リクエスト/返信フレームの交換がなければ、RDMAC RNICがIETF RNICと相互運用できるようにするための標準的なメカニズムはありません。ULPがよく知られているポートを使用してRDMAモードですぐにIETF RNICを起動したとしても（つまり、MPAリクエスト/返信メッセージを交換せずに）、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要求/返信フレームを実装する必要があります。次のセクションでは、ストリーミングからRDMAモードへの変換前のMPA要求/返信フレームの交換後の結果について説明します。
Three types of RNICs are considered:
3種類のRNICが考慮されます。
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のアップグレード - RDMAモードに変換する前に、MPA要求/返信フレームをストリーミングモードで交換するULPまたはその他のサポートエンティティを備えたRDMACプロトコルを実装するRNIC。
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 RNICとのみ相互運用できます。
Permissive IETF RNIC - an RNIC implementing the IETF protocols that is capable of implementing the RDMAC protocols on a per-connection basis.
Permissive 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.
MPA、DDP、およびRDMAPバージョンとMPAマーカーとCRCにこれらの3つのRNICタイプで使用される値を図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.
図14：MPAマーカーとMPA CRCのRNICタイプの接続パラメーター、有効= 1、無効= 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プロトコル（バージョンはゼロ）を生成するか、IETFプロトコル（バージョンIS 1）を使用します。
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.
MPAリクエスト/返信フレームの交換中、各ピアはMPAリビジョン、マーカー選好（M：0 =無効、1 =有効）、およびCRC好みを提供します。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).
MPAリクエスト/返信フレームの情報から、各側は、DDP/RDMAPプロトコルのバージョンフィールド（V：0 = RDMAC、1 = IETF）と各ハーフ接続のマーカーの状態を設定します。DDPとRDMAPの間で、バージョンの混合は許可されていません。さらに、DDPおよびRDMAPバージョンは2つの方向で同一でなければなりません。RNICは、ワイヤー上のRDMACプロトコル（バージョンはゼロ）を生成するか、IETFプロトコル（バージョンIS 1）を使用します。
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を生成およびチェックする必要があります。
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は、両方のピアがMPAリクエスト/返信フレームを交換するという事実にもかかわらず、非頻度のIETF RNICが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 = 0がrdmac ddp/rdmapバージョンで、v = 1はietf ddp/rdmacバージョン、m = 0はmpaマーカーがmpaマーカーであることを意味する右下隅の異なるrnicタイプの交差点で表示されます。無効になり、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交渉
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はREVフィールドがゼロに設定され、MおよびCビットが1に設定されたMPA要求フレームを送信します。非頻度のIETF RNICは、DDPおよびRDMAPに使用するバージョン番号を動的にダウングレードできないため、REVフィールドを1つに等しくrevフィールドでMPA応答フレームを送信し、接続を優雅に閉じます。
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イニシエーターである場合、REVフィールドが1に等しいMPA要求フレームを送信します。RDMAC RNICのULPまたはサポートエンティティは、REVフィールドがゼロに等しく、Mビットが1に設定されたMPA応答フレームで応答します。非頻度のIETF RNICは、MPA応答フレームの互換性のないREVフィールドを読み取った後、接続を優雅に閉じます。
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 REQ/REPフレームのREVフィールドからRDMAC RNICを認識し、RDMAC RNICに対応するために受信マーカー状態とDDP/RDMAPバージョンを調整します。その結果、MPAレスポンダーとして、寛容なIETF RNICは、Mビットがゼロに設定されたMPA応答フレームを返すことはありません。このケースは、図16に該当しない（n/a）として示されています。
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要求メッセージを準備し、改訂をゼロに設定し、MビットとCビットを1に設定します。
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レスポンダーはMPA要求メッセージを受信し、改訂フィールドをチェックします。RDMAC DDP/RDMAPヘッダーを生成できるため、リビジョンをゼロに設定し、MおよびCビットを1に設定したMPA返信メッセージを送信します。Responderは、ULPにバージョンゼロDDP/RDMAPメッセージを生成していることを通知する必要があります。
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イニシエーターである場合、MPAリクエストフレームがREVフィールドを1つに設定する準備をします。MPAリクエストフレームのMビットの値に関係なく、RDMAC RNICのULPまたはその他のサポートエンティティは、ゼロに等しいREVとMビットが1に設定された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 ReplyフレームのREVフィールドを読み取り、そのピアがRDMAC RNICであることを発見した場合、バージョンゼロDDP/RDMAPメッセージを生成し、MPAマーカーとCRCを有効にする必要があることをULPに通知する必要があります。
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であるか、許容されない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.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、「Internet Small Computer Systems Interface（ISCSI）」、RFC 3720、2004年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、RFC 2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、RFC 3723、2004年4月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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] Pinkerton、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] Stone J.、Partridge、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 collaborative、 "kdapl（Kernel Direct Access Programming Library）およびUDAPL（ユーザーDirect Access Programming Library）"、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] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「信頼できる輸送を介した直接データ配置」、RFC 5041、2007年10月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)" RFC 5046, October 2007.
[Iser] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、 "Internet Small Computer System Interface（ISCSI）リモートダイレクトメモリアクセス（RDMA）拡張）「RFC 5046、2007年10月。
[IT-API] The Open Group, "Interconnect Transport API (IT-API)" Version 2.1, http://www.opengroup.org.
[IT-API]オープングループ、「Interconnect Transport 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-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.、Garcia、D.、Hilland、J。、およびB. Metzler、「リモートダイレクトメモリアクセスプロトコル仕様」、RFC 5040、2007年10月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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] Bailey、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.、Mogul、J.、Talpey、T。、およびS. Bailey、「IP問題ステートメント上のリモートダイレクトメモリアクセス（RDMA）」、RFC 4297、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[VERBS-RMDA] "RDMA Protocol Verbs Specification", RDMA Consortium standard, April 2003, <http://www.rdmaconsortium.org/ home/draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>.
[Verbs-RMDA]「RDMAプロトコル動詞仕様」、RDMAコンソーシアムスタンダード、2003年4月、<http://www.rdmaconsortium.org/ home/draft-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
ドワイト・バロン・ヒューレット・パッカード・カンパニー20555 SH 249ヒューストン、テキサス州77070-2698 USA電話：281-514-2769メール：wight.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
ジェフチェイスコンピュータサイエンスデューク大学ダーラム、ダーラム、ノースカロライナ州27708-0129米国電話：1 919 660 6559メール：chase@cs.duke.edu
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
Ted Compton EMC Corporation Research Triangle Park、NC 27709 USA電話：919-248-6075メール：compton_ted@emc.com
Dave Garcia 24100 Hutchinson Rd. Los Gatos, CA 95033 Phone: 831 247 4464 EMail: Dave.Garcia@StanfordAlumni.org
Dave Garcia 24100 Hutchinson Rd。Los Gatos、CA 95033電話：831 247 4464メール：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 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
Hari Ghadia Gen10 Technology、Inc。1501 W Shady Grove Road Grand Prairie、TX 75050電話：（972）301 3630電子メール：hghadia@gen10technology.com Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd.チャンドラー、AZ 85226電話：480-554-3116メール：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
Jeff Hilland Hewlett-Packard Company 20555 SH 249 TX 77070-2698 USA電話：281-514-9489メール：jeff.hilland@hp.com
Mike Ko IBM 650 Harry Rd. San Jose, CA 95120 Phone: (408) 927-2085 EMail: mako@us.ibm.com
Mike Ko IBM 650 Harry Rd。カリフォルニア州サンノゼ95120電話：（408）927-2085メール：mako@us.ibm.com
Mike Krause Hewlett-Packard Corporation, 43LN 19410 Homestead Road Cupertino, CA 95014 USA Phone: +1 (408) 447-3191 EMail: krause@cup.hp.com
Mike Krause Hewlett-Packard Corporation、43ln 19410 Homestead Road Cupertino、CA 95014 USA電話：1（408）447-3191メール：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
Dave Minturn Intel Corporation MS JF1-210 5200 North East Elam Young Parkway Hillsboro、Oregon 97124電話：503-712-4106メール：dave.b.minturn@intel.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
Jim Pinkerton Microsoft、Inc。One Microsoft Way Redmond、WA 98052 USAメール：jpink@microsoft.com Hemal Shah Broadcom Corporation 5300 California Avenue Irvine、CA 92617 USA電話：1（949）926-6941メール：hemal@broadcom.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408 525 8836 EMail: allyn@cisco.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose、CA 95134 USA電話：1 408 525 8836メール：allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
Tom Talpey Networkアプライアンス1601 Trapelo Road＃16 MA 02451 USA電話：1（781）768-5329メール：thomas.talpey@netapp.com
Patricia Thaler Broadcom 16215 Alton Parkway Irvine, CA 92618 Phone: 916 570 2707 EMail: pthaler@broadcom.com
Patricia Thaler Broadcom 16215 Alton Parkway Irvine、CA 92618電話：916 570 2707メール：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
Jim Wendt Hewlett Packard Corporation 8000 Foothills Boulevard MS 5668 Roseville、CA 95747-5668 USA電話：1 916 785 5198メール：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
Jim Williams Emulex Corporation 580 Main Street Bolton、MA 01740 USA電話：1 978 779 7224メール：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
Paul R. Culley Hewlett-Packard Company 20555 SH 249ヒューストン、テキサス77070-2698 USA電話：281-514-5543メール：paul.culley@hp.com
Uri Elzur 5300 California Avenue Irvine, CA 92617, USA Phone: 949.926.6432 EMail: uri@broadcom.com
Uri Elzur 5300 California Avenue Irvine、CA 92617、USA電話：949.926.6432メール：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
Renato J Recio IBM Internal Zip 9043 11400 Burnett Road Austin、Texas 78759電話：512-838-3685メール：recio@us.ibm.com
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA Phone: +1 978 689 1614 EMail: steph@sandburst.com
Stephen Bailey Sandburst Corporation 600 Federal Street Andover、MA 01810 USA電話：1 978 689 1614メール：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
John Carrier Cray Inc. 411 First Avenue S、Suite 600 Seattle、WA 98104-2860電話：206-701-2090メール：carrier@cray.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。