RFC5044 日本語訳
5044 Marker PDU Aligned Framing for TCP Specification. P. Culley, U.Elzur, R. Recio, S. Bailey, J. Carrier. October 2007. (Format: TXT=168918 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Culleyがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5044年のヒューレット・パッカード会社カテゴリ: 標準化過程U.Elzur Broadcom社のR.Recio IBM社のS.べイリーSandburst社のJ.キャリヤーザリガニ株式会社2007年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Aligned Framing(MPA)は、TCPとDirect Data Placementプロトコル(DDP)の間の「適合層」として働くようにRFC5041で説明されるように設計されています。 それはDDPが必要とする上位レベル・プロトコル境界の記録の保存を加えている間、TCPの信頼できて、注文している配送を保存します。 MPAは適切なTCP RFCsと共に完全に言いなりになって、既存のTCP実装と共に利用できます。 また、MPAは実装における要件をバッファリングしながら減少して、向上するためにTCP、MPA、およびDDPを結合する統合実装にシステムレベルにおける性能をサポートします。
Culley, et al. Standards Track [Page 1] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[1ページ]。
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
1. 序論…4 1.1. 動機…4 1.2. 概要について議定書の中で述べてください…5 2. 用語集…8 3. DDPとのMPAの相互作用…11 4. MPAの完全な運用段階…13 4.1. FPDU形式…13 4.2. マーカー形式…14 4.3. MPAマーカー…14 4.4. CRC計算…16 4.5. FPDUサイズ問題…21 5. TCPとのMPAの相互作用…22 5.1. 規格があるMPA送信機はTCPを層にしました…22 5.2. 規格があるMPA受信機はTCPを層にしました…23 6. MPA受信機FPDU識別…24 7. 接続意味論…24 7.1. 接続セットアップ…24 7.1.1. MPA要求と回答は形式を縁どっています…26 7.1.2. 接続始動は統治されます…28 7.1.3. 例は始動系列を遅らせました…30 7.1.4. 個人的なデータの使用…33 7.1.4.1. 動機…33 7.1.4.2. 個人的なデータを使用する例の即座の始動…35 7.1.5. 「デュアルスタック」実装…37 7.2. 正常な接続分解…38 8. 誤り意味論…39 9. セキュリティ問題…40 9.1. プロトコル特有のセキュリティ問題…40 9.1.1. だまします…40 9.1.1.1. ものまね…41 9.1.1.2. ハイジャックを流してください…41 9.1.1.3. 中央の男性攻撃…41 9.1.2. 盗聴…42 9.2. セキュリティオプションへの序論…42 9.3. MPAとIPsecを使用します…43 9.4. MPA/DDPのIPsecカプセル化のための要件…43 10. IANA問題…44 付録A.はMPA意識しているTCP実装を最適化しました…45 A.1。 MPA/TCP送信機を最適化します…46 A.2。 最適化されたMPA/TCP分割の効果…46 A.3。 MPA/TCP受信機を最適化します…48 A.4。 再区分Middleboxesと非最適化されたMPA/TCP Senders…49 A.5。 受信機実装…50 A.5.1。 ネットワーク層Reassemblyバッファ…51
Culley, et al. Standards Track [Page 2] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[2ページ]。
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
A.5.2。 TCP Reassemblyバッファ…52 TCP操作の上のMPAの付録B.分析…52 B.1。 仮定…53 B.1.1。 MPAはDDPの下で層にされます…53 B.1.2。 MPAはDDPメッセージ縁どりを保存します…53 B.1.3。 MPAに渡されたULPDUのサイズはエムスより正常な状況では少ないです…53 B.1.4。 不適切なプレースメントにもかかわらず、いいえの不適切な配送.54B.2。 FPDU整列の値…54 B.2.1。 受信機のコンピュータの荷重と複雑さにおけるFPDU整列の不足の影響…56 B.2.2。 TCPワイヤへのFPDU整列効果は議定書を作ります…RDMA共同体プロトコルがある60付録C.IETF実装相互運用性…62 C.1。 パラメタを交渉します…63 C.2。 RDMAC RNICと非寛大なIETF RNIC…64 C.2.1。 RDMAC RNIC創始者…65 C.2.2。 非寛大なIETF RNIC創始者…65 C.2.3。 RDMAC RNICと寛大なIETF RNIC…65 C.2.4。 RDMAC RNIC創始者…66 C.2.5。 寛大なIETF RNIC創始者…67 C.3。 非寛大なIETF RNICと寛大なIETF RNIC…67 標準の参照…68 有益な参照…68人の貢献者…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
図1: ULP MPA TCPレイヤリング…5 図2: FPDU形式…13 図3: マーカー形式…14 図4: マーカーがある例のFPDU形式…16 図5: FPDUの十六進法ダンプを注釈します…19 図6: マーカーとのFPDUの十六進法ダンプを注釈します…20 図7: 実装を完全に層にします…22エイト環: MPA要求/回答フレーム…26 図9: 例は始動交渉を遅らせました…31 図10: 例の即座の始動交渉…35 図11: MPA/TCP実装を最適化します…45 図12: 非同盟のFPDUはTCP八重奏ストリームで自由に入賞しました…56 図13: 並べられたFPDUはTCPヘッダー直後入賞しました…58 図14: RNICタイプへの接続パラメタ…63 図15: RDMAC RNICと非寛大なIETF RNICとのMPA交渉…65 図16: RDMAC RNICと寛大なIETF RNICとのMPA交渉…66 図17: 非寛大なIETF RNICと寛大なIETF RNICとのMPA交渉…67
Culley, et al. Standards Track [Page 3] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[3ページ]。
1. Introduction
1. 序論
This section discusses the reason for creating MPA on TCP and a general overview of the protocol.
このセクションはMPAをTCPに作成する理由とプロトコルの概要について論じます。
1.1. Motivation
1.1. 動機
The Direct Data Placement protocol [DDP], when used with TCP [RFC793], requires a mechanism to detect record boundaries. The DDP records are referred to as Upper Layer Protocol Data Units by this document. The ability to locate the Upper Layer Protocol Data Unit (ULPDU) boundary is useful to a hardware network adapter that uses DDP to directly place the data in the application buffer based on the control information carried in the ULPDU header. This may be done without requiring that the packets arrive in order. Potential benefits of this capability are the avoidance of the memory copy overhead and a smaller memory requirement for handling out-of-order or dropped packets.
TCP[RFC793]と共に使用されると、Direct Data Placementプロトコル[DDP]は、境界の記録を検出するためにメカニズムを必要とします。 DDP記録はこのドキュメントによってUpper LayerプロトコルData Unitsと呼ばれます。 Upper LayerプロトコルData Unit(ULPDU)境界の場所を見つける能力は直接ULPDUヘッダーで運ばれた制御情報に基づくアプリケーションバッファのデータを置くのにDDPを使用するハードウェアネットワークアダプターの役に立ちます。 パケットが整然とした状態で到着する必要でない、これをするかもしれません。 この能力の潜在的利益は故障しているか下げられたパケットを扱うためのメモリコピーオーバーヘッドと、よりわずかなメモリ要件の回避です。
Many approaches have been proposed for a generalized framing mechanism. Some are probabilistic in nature and others are deterministic. An example probabilistic approach is characterized by a detectable value embedded in the octet stream, with no method of preventing that value elsewhere within user data. It is probabilistic because under some conditions the receiver may incorrectly interpret application data as the detectable value. Under these conditions, the protocol may fail with unacceptable frequency. One deterministic approach is characterized by embedded controls at known locations in the octet stream. Because the receiver can guarantee it will only examine the data stream at locations that are known to contain the embedded control, the protocol can never misinterpret application data as being embedded control data. For unambiguous handling of an out-of-order packet, a deterministic approach is preferred.
多くのアプローチが一般化された縁どりメカニズムのために提案されました。 或るものは現実に確率的です、そして、他のものは決定論的です。 例の確率論的アプローチは八重奏ストリームに埋め込まれた検出可能な値によって特徴付けられます、利用者データの中のほかの場所でその値を防ぐメソッドなしで。 受信機が検出可能な値としていくつかの条件のもとで不当にアプリケーションデータを解釈するかもしれないので、それは確率的です。 これらの条件で、容認できない頻度に応じて、プロトコルは失敗するかもしれません。 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ストリームで断固としているのを許容します。
Culley, et al. Standards Track [Page 4] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[4ページ]。
1.2. Protocol Overview
1.2. プロトコル概要
The layering of PDUs with MPA is shown in Figure 1, below.
MPAとのPDUsのレイヤリングは以下の図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.
+------------------+ | ULPクライアント| +------------------+ <消費者メッセージ| DDP| +------------------+ <ULPDUs| MPA*| +------------------+ <FPDUs(ULPDUsを含んでいます)| TCP*| +------------------+ <TCPセグメント(FPDUsを含んでいます)| IPなど | +------------------+ 完全に一緒に層にされるか、または最適化されていて、これらがそうするかもしれない*。
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. Consumerは接続の両端で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はStartup Phaseへの各端のMPAを動かします、InitiatorかResponderとして、ULPによって決定されるように。 このモードは、MPAの使用法を確かめて、CRCとMarkersの使用を指定して、ULPが兵士のData交換でいくつかの追加データを伝えるのを許容します。 始動プロセスに関するその他の詳細に関してセクション7.1、Connection Setupを見てください。
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. Startup Phaseの端では、ULPはMPA(そして、DDP)をFull Operationに入れて、以下でさらに説明されているとしてDDPデータを送り始めます。 本書では、DDPデータ塊はULPDUsと呼ばれます。 DDPデータの記述に関しては、[DDP]を見てください。
Culley, et al. Standards Track [Page 5] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[5ページ]。
Following is a description of data transfer when MPA is in Full Operation.
MPAがFull Operationにあるとき、以下に、データ転送の記述があります。
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について質問することによって、Maximum 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はヘッダーをprependingすることによって、FramedプロトコルData Unit(FPDU)を作成します、ULPDUとPAD(もしあれば)の後に任意にMarkersを挿入して、CRC野原を追加して。 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送付者はTCPストリームにFPDUsを入れます。 送付者が最適化されたMPA/TCPであるなら、それはまた、TCP Segment境界が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ペイロード注文情報を通過するよりMPAにMPAへのTCPペイロードを移りながら、分離するかもしれません。 どちらの場合ではも、RFC対応することのTCPワイヤの振舞いは送付者と受信機の両方で観測されます。
6. The MPA receiver locates and assembles complete FPDUs within the
stream, verifies their integrity, and removes MPA Markers (when
present), ULPDU_Length, PAD, and the CRC field.
6. MPA受信機は、ストリームの中で完全なFPDUsを場所を見つけて、組み立てて、彼らの保全について確かめて、MPA Markers(存在しているとき)、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ペイロードを切り離すかもしれません。
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と共に共同利用するでしょう。 追加振舞いは、Appendix Aで説明されて、規範的ではありません。 それらはTCPインタフェース層で便利と説明されます。 実装はTCPと、MPAと、DDPの間の交差している層の最適化を含むどんなメソッドも使用する説明された機能性を実現するかもしれません。
Culley, et al. Standards Track [Page 6] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[6ページ]。
An optimized DDP/MPA/TCP sender is able to segment the data stream such that TCP segments begin with FPDUs (FPDU Alignment). This has significant advantages for receivers. When segments arrive with aligned FPDUs, the receiver usually need not buffer any portion of the segment, allowing DDP to place it in its destination memory immediately, thus avoiding copies from intermediate buffers (DDP's reason for existence).
最適化されたDDP/MPA/TCP送付者がデータが流すセグメントにできるので、TCPセグメントはFPDUs(FPDU Alignment)と共に始まります。 これには、受信機のための重要な利点があります。 セグメントが並べられた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が、アプリケーションバッファの正しい位置で入賞するのによるかなりの量の中間的ストレージがULPDUsであると保存するのを可能にします。
The ability of a receiver to recover out-of-order ULPDUs is optional and declared to the transmitter during startup. When the receiver declares that it does not support out-of-order recovery, the transmitter does not add the control information to the data stream needed for out-of-order recovery.
受信機が故障しているULPDUsを回収する能力は、任意であり、始動の間、送信機に宣言されます。 受信機が、不適切な回復をサポートしないと宣言するとき、送信機は不適切な回復に必要であるデータ・ストリームに制御情報を加えません。
If the receiver is fully layered, then MPA receives a strictly ordered stream of data and does not deal with out-of-order ULPDUs. In this case, MPA passes each ULPDU to DDP when the last bytes arrive from TCP, along with the indication that they are in order.
受信機が完全に層にされるなら、MPAはデータの厳密に命令されたストリームを受けて、故障しているULPDUsに対処しません。 最後のバイトがこの場合TCPから到着するとき、MPAは各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).
故障しているULPDUsの回復をサポートするMPA実装は、送付者が彼らを伝えたのでULPDUsの注文を示して、なくなった中間的セグメントがいつ到着するかを示すためにメカニズムをサポートしなければなりません。 これらのメカニズムで、DDPは完全なメッセージ(記録のグループ)の記録的な注文とレポートDeliveryを復職させることができます。
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
MPAは他の現代のプロトコルによって提供されたレベルにULPDUデータ保全を増強するためにCRCチェックを含んでいます、SCTP[RFC4960]などのように。 このCRCチェックを無効にするのは可能です。 しかしながら、終わりから終わりとのネットワークを通した接続がデータ保全をCRCが有効にされているMPAと少なくとも同じくらい良くするのが、明確でない場合CRCsを有効にしなければならない、(
Culley, et al. Standards Track [Page 7] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[7ページ]。
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.
終わりが終わるためにIPsecに実装されるときの例 DDPのULPはこのレベルのデータ保全を予想します、そして、したがって、ULPはそれ自身の重複データ保全とエラー回復をロストデータに提供する必要はありません。
2. Glossary
2. 用語集
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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かアプリケーション。 Consumerは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に関しては、Deliveryは特定のPDUが使用のために注文されることをDDPに知らせるプロセスと定義されます。 PDUはそれが元の送り主によって送られた正確なオーダーでDeliveredです。 MPAは、Deliveryがいつ可能であるかを決定するのにTCPのバイト・ストリーム注文を使用します。 これは「PDUをDDPに渡します」と明確に異なっています(一般に、順不同に起こるかもしれません)、厳密にDeliveryの注文を定義しますが。
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].
エムス--有効な最大のセグメントサイズ。 エムスはRFC793[RFC793]で定義されるTCPの最大のセグメントサイズ(MSS)、および現在の経路Maximum Transmission Unitで、より小さい(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 Alignment--、特性、FPDUがTCPセグメント、およびTCPセグメントがあるHeader AlignedであることはFPDUsの整数を含んでいます。 他のTCPセグメントで到着するのを待っているか、または先のセグメントに結合しないで、FPDU AlignmentがあるTCPセグメントは含まれたFPDUsの即時処理を許します。
FPDU Pointer (FPDUPTR) - This field of the Marker is used to indicate
the beginning of an FPDU.
FPDU Pointer(FPDUPTR)--Markerのこの分野は、FPDUの始まりを示すのに使用されます。
Full Operation (Full Operation Phase) - After the completion of the
Startup Phase, MPA begins exchanging FPDUs.
完全なOperation(完全なOperation Phase)--Startup Phaseの完成の後に、MPAはFPDUsを交換し始めます。
Culley, et al. Standards Track [Page 8] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[8ページ]。
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).
ヘッダーAlignment--TCPセグメントがFPDUと共に始める特性。 FPDUヘッダーがちょうどTCPセグメント(ワイヤの上のTCPヘッダーの後ろで正しい)の始めにあるとき、FPDUはHeader Alignedです。
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 Request Frame(すなわち、実際に、データ(TCP SYNを送るものでないかもしれない)を送る1番目)を送る接続の終点。
Marker - A four-octet field that is placed in the MPA data stream at
fixed octet intervals (every 512 octets).
マーカー--固定八重奏間隔(512の八重奏毎)におけるMPAデータ・ストリームに置かれる4八重奏の野原。
MPA-aware TCP - A TCP implementation that is aware of the receiver
efficiencies of MPA FPDU Alignment and is capable of sending TCP
segments that begin with an FPDU.
MPA意識しているTCP--MPA FPDU Alignmentの受信機効率を意識していて、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によって可能にされるとき、それは縁どりとMarkersを挿入しています。 受信機がMPAによって可能にされるとき、それは縁どりとMarkersを解釈しています。
MPA Request Frame - Data sent from the MPA Initiator to the MPA
Responder during the Startup Phase.
MPA Request Frame--データはStartup Phaseの間、MPA InitiatorからMPA Responderまで発信しました。
MPA Reply Frame - Data sent from the MPA Responder to the MPA
Initiator during the Startup Phase.
MPA Reply Frame--データはStartup Phaseの間、MPA ResponderからMPA Initiatorまで発信しました。
MPA - Marker-based ULP PDU Aligned Framing for TCP protocol. This
document defines the MPA protocol.
MPA--TCPのためのマーカーベースのULP PDU Aligned Framingは議定書を作ります。 このドキュメントは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個以上のリンクに付きました。 Nodeは、コンピュータで動きながら、このような関係においては特定のアプリケーションかプロトコル具体化を示しません。 NodeはホストコンピュータにインストールされたTCPデバイスの上の1MPAから成るかもしれません。
PAD - A 1-3 octet group of zeros used to fill an FPDU to an exact
modulo 4 size.
PAD--ゼロ1-3八重奏グループが以前はよくFPDUを正確な法4サイズまでいっぱいにしていました。
PDU - Protocol data unit
PDU--プロトコルデータ単位
Private Data - A block of data exchanged between MPA endpoints during
initial connection setup.
個人的なData--初期の接続の間にMPA終点の間で交換された1ブロックのデータはセットアップされます。
Culley, et al. Standards Track [Page 9] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[9ページ]。
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.
保護Domain--結びつきが使用する特定の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.
リモートPeer--MPAは接続の反対端で実装について議定書の中で述べます。 2Nodesの間のプロトコル交換か他の相互作用について説明するとき、リモート実体について言及するのにおいて、使用されています。
Responder - The connection endpoint that responds to an incoming MPA
connection request (the MAP Request Frame). This may not be the
endpoint that awaited the TCP SYN.
応答者--入って来るMPA接続要求(MAP Request Frame)に応じる接続終点。 これは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.
始動Phase--以上に勤める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の分野。
Culley, et al. Standards Track [Page 10] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[10ページ]。
3. MPA's Interactions with DDP
3. DDPとのMPAの相互作用
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は記録(ULPDUs)をMPAに供給します。 MPAは、TCPがデータを送る信頼できるトランスミッション能力を使用して、MPA受信機が境界の記録情報の場所を見つけるのを許容するためにTCPの流れの中に適切な追加情報を挿入するでしょう。
As such, MPA accepts complete records (ULPDUs) from DDP at the sender and returns them to DDP at the receiver.
そういうものとして、MPAは送付者でDDPから完全な記録(ULPDUs)を受け入れて、受信機で彼らをDDPに返します。
MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU contained in one FPDU.
MPA MUSTは、1FPDUに含まれた1ULPDUがまさにあるように、ULPDUを要約します。
MPA over a standard TCP stack can usually provide FPDU Alignment with the TCP Header if the FPDU is equal to TCP's EMSS. An optimized MPA/TCP stack can also maintain alignment as long as the FPDU is less than or equal to TCP's EMSS. Since FPDU Alignment is generally desired by the receiver, DDP cooperates with MPA to ensure FPDUs' lengths do not exceed the EMSS under normal conditions. This is done with the MULPDU mechanism.
FPDUがTCPのエムスと等しいなら、通常、標準のTCPスタックの上のMPAはTCP HeaderをFPDU Alignmentに提供できます。 また、最適化されたMPA/TCPスタックはFPDUがTCPの、よりエムス以下である限り、整列を維持できます。 FPDU Alignmentが受信機によって一般に望まれているので、DDPはFPDUsの長さが正常な状況ではエムスを超えていないのを保証するためにMPAと協力します。 MULPDUメカニズムでこれをします。
MPA MUST provide information to DDP on the current maximum size of the record that is acceptable to send (MULPDU). DDP SHOULD limit each record size to MULPDU. The range of MULPDU values MUST be between 128 octets and 64768 octets, inclusive.
MPA MUSTは発信するのにおいて許容できる記録(MULPDU)の現在の最大サイズで情報をDDPに提供します。 DDP SHOULDは各レコード・サイズを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の八重奏よりMPAに大きいULPDUを掲示してはいけません。 DDPはどんなサイズ1〜64768八重奏のULPDUも掲示するかもしれません。 しかしながら、MPAは現在のMULPDUよりすばらしいULPDU Lengthを支持するREQUIREDではありません。
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 Alignmentを支持するのを可能にするために、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.
MULPDUが理論上の最大よりほとんどの事情のためのほとんどの実現でかなり小さくなることに注意してください、MTUsをリンクするのにおいて当然です、IPsecなどに必要であるような余分なヘッダーの使用
Culley, et al. Standards Track [Page 11] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[11ページ]。
On receive, MPA MUST pass each ULPDU with its length to DDP when it has been validated.
オンである、受信してください、そして、それが有効にされたとき、MPA MUSTは長さで各ULPDUをDDPに渡します。
If an MPA implementation supports passing out-of-order ULPDUs to DDP, the MPA implementation SHOULD:
MPA実現が、DDP、MPA実現SHOULDに故障しているULPDUsを渡すのを支持するなら:
* 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台の可能なメカニズムがTCP一連番号を各ULPDUに供給しているかもしれません。
* Provide a mechanism to indicate when a given ULPDU (and prior
ULPDUs) are complete (Delivered to DDP). One possible mechanism
might be to allow DDP to see the current outgoing TCP ACK
sequence number.
* メカニズムを提供して、与えられたULPDU(そして、先のULPDUs)がいつであるかを完全な状態で(DDPに渡します)示してください。 1台の可能なメカニズムはDDPが現在の外向的なTCP ACK一連番号を見るのを許容することであるかもしれません。
* Provide an indication to DDP that the TCP has closed or has begun
to close the connection (e.g., received a FIN).
* TCPが閉じ始めたか、または接続(例えば、FINを受ける)を終え始めたというDDPへの指示を提供してください。
MPA MUST provide the protocol version negotiated with its peer to DDP. DDP will use this version to set the version in its header and to report the version to [RDMAP].
MPA MUSTは同輩と交渉されたプロトコルバージョンをDDPに提供します。 DDPは、ヘッダーにバージョンをはめ込んで、[RDMAP]にバージョンを報告するのにこのバージョンを使用するでしょう。
Culley, et al. Standards Track [Page 12] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[12ページ]。
4. MPA Full Operation Phase
4. MPA稼業フェーズ
The following sections describe the main semantics of the Full Operation Phase of MPA.
以下のセクションはMPAのFull Operation Phaseの主な意味論について説明します。
4.1. FPDU Format
4.1. FPDU形式
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を作成します。 すべてのMPA FPDUsに以下で見せられたFPDUの形式を使用しなければなりません。 明快の目的のために、Markersは図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_長さ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ ~ ~ ULPDU~| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PAD(0-3 八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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_の長さ: 16ビット(符号のない整数)。 これは含まれたULPDUの八重奏の数です。 それはFPDUヘッダー自体の長さを含んでいません、パッド、CRC、または、どんなMarkersでも、それがULPDUの中で低下します。 16ビットのULPDU Length分野はIPv4かIPv6のために最も大きいIPデータグラムを支えることができるくらい大きいです。
PAD: The PAD field trails the ULPDU and contains between 0 and 3 octets of data. The pad data MUST be set to zero by the sender and ignored by the receiver (except for CRC checking). The length of the pad is set so as to make the size of the FPDU an integral multiple of four.
以下を水増ししてください。 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を使用して。(価値は、FPDUの全体のコンテンツについて確かめるのに使用されます)。 セクション4.4、CRC計算を見てください。 CRCsが有効にされないとき、この分野は、まだ存在していて、どんな値も含むかもしれなくて、チェックされてはいけません。
Culley, et al. Standards Track [Page 13] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[13ページ]。
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は最低6つの八重奏をULPDUの長さに加えます。 さらに、FPDUの全長はどんなMarkersの長さも含むでしょう、そして、0〜3つのパッド八重奏がULPDUサイズを擦り取りに加えました。
4.2. Marker Format
4.2. マーカー形式
The format of a Marker MUST be as specified in Figure 3:
Markerの形式が図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| FPDUPTR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Marker Format
図3: マーカー形式
RESERVED: The Reserved field MUST be set to zero on transmit and ignored on receive (except for CRC calculation).
予約される: 伝わって、無視されて、Reserved分野がゼロにオンなセットであるに違いない、オンである、受信してください(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 Pointerは相対的なポインタです、長さ16ビットです、TCPの流れにおける、八重奏の数をULPDU Length分野の始まりから全体のMarkerの最初の八重奏に示す符号のない整数として解釈されて。 いつも最も重要でない2ビットを送信機のゼロに設定しなければなりません、そして、受信機は計算のためにいつもゼロとしてこれらを扱わなければなりません。
4.3. MPA Markers
4.3. MPAマーカー
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 Markersは、故障していた状態でパケットが受け取られているときのFPDUsの始まりを特定するのに使用されます。 定期的にデータ・ストリーム(TCP一連番号に関連する)でMarkersの場所を見つけて、前のFPDU始めの場所を見つけるのにMarker値を使用することによって、これをします。
All MPA Markers are included in the containing FPDU CRC calculation (when both CRCs and Markers are in use).
すべてのMPA Markersが含んでいるFPDU CRC計算に含まれています(CRCsとMarkersの両方が使用中であるときに)。
The MPA receiver's ability to locate out-of-order FPDUs and pass the ULPDUs to DDP is implementation dependent. MPA/DDP allows those receivers that are able to deal with out-of-order FPDUs in this way to require the insertion of Markers in the data stream. When the receiver cannot deal with out-of-order FPDUs in this way, it may disable the insertion of Markers at the sender. All MPA senders MUST be able to generate Markers when their use is declared by the opposing receiver (see Section 7.1, Connection Setup).
故障しているFPDUsの場所を見つけて、ULPDUsをDDPに渡すMPA受信機の性能は実現に依存しています。 MPA/DDPはデータ・ストリームへのMarkersの挿入を必要とするこのように故障しているFPDUsに対処できるそれらの受信機を許容します。 受信機がこのように故障しているFPDUsに対処できないなら、それは送付者でMarkersの挿入を無効にするかもしれません。 彼らの使用が反対している受信機によって宣言されるとき(セクション7.1を見てください、Connection Setup)、すべてのMPA送付者がMarkersを発生させることができなければなりません。
Culley, et al. Standards Track [Page 14] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[14ページ]。
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).
Markersが有効にされるとき、MPA送付者はTCP Sequence Number Spaceの512八重奏の周期的な間隔におけるデータ・ストリームの中にMarkerを挿入しなければなりません。 MarkerはFPDUPTR(FPDU Pointer)と呼ばれた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 Pointerは16ビットの相対的なバック・ポインタです。 FPDUPTR MUSTはULPDU Length分野の始まりからMarkerの最初の八重奏にTCPの流れにおける、八重奏の数を含んでいます、MarkerがFPDUsの間に落ちない場合。 したがって、前のFPDUヘッダーの最初の八重奏の位置は、Markerの最初の八重奏の現在の八重奏流れの一連番号(すなわち、TCP一連番号)から与えられたMarkerの値を引き算することによって、決定できます。 この計算がTCP一連番号がMarkerとヘッダーの間で包装したかもしれないアカウントを連れていかなければならないことに注意してください。
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).
0×0000のFPDUPTR値は特別なケースです--MarkerがちょうどFPDUs(前のFPDU CRC分野と次のFPDUのULPDU Length分野の間の)の間に落ちるとき、それは使用されています。 この場合、以下のFPDUにMarkerが含まれると考えられます。 Markerに続くFPDUのCRC計算にMarkerを含まなければなりません(CRCsが発生するか、またはチェックされているなら)。 したがって、0×0000のFPDUPTR値は、すぐにMarkerに続くのが、FPDUヘッダー(ULPDU Length分野)であることを意味します。
Since all FPDUs are integral multiples of 4 octets, the bottom two bits of the FPDUPTR as calculated by the sender are zero. MPA reserves these bits so they MUST be treated as zero for computation at the receiver.
すべてのFPDUsが4の整数倍であるので、八重奏、計算されるとしての送付者によるFPDUPTRの2ビットの下部はゼロです。 MPAがこれらのビットを予約するので、計算のためのゼロとして受信機にそれらを扱わなければなりません。
When Markers are enabled (see Section 7.1, Connection Setup), the MPA Markers MUST be inserted immediately preceding the first FPDU of Full Operation Phase, and at every 512th octet of the TCP octet stream thereafter. As a result, the first Marker has an FPDUPTR value of 0x0000. If the first Marker begins at octet sequence number SeqStart, then Markers are inserted such that the first octet of the Marker is at octet sequence number SeqNum if the remainder of (SeqNum - SeqStart) mod 512 is zero. Note that SeqNum can wrap.
Markersがその後有効にされるとき(セクション7.1を見てください、Connection Setup)、すぐにFull Operation Phaseの最初のFPDUに先行しながら挿入される、およびTCP八重奏の流れのあらゆる512番目の八重奏にはMPA Markersがあるに違いありません。 その結果、最初のMarkerには、0×0000のFPDUPTR値があります。 最初のMarkerが八重奏一連番号SeqStartで始まるなら、Markersは、Markerの最初の八重奏が(SeqNum--SeqStart)モッズ512の残りがゼロであるなら八重奏一連番号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一連番号がMarkerの挿入先について計算するのに使用されたなら、始めのTCP一連番号はゼロでありそうにはありません、そして、512八重奏の倍数はゼロの法512に落ちそうにはありません。 MPA接続がTCP一連番号11で始められて、次に、最初のMarkerが11時に始まって、その後のMarkersが523、1035年に始まるなら、などです。
Culley, et al. Standards Track [Page 15] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[15ページ]。
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が複数のMarkersを含むことができるくらい大きいなら、彼らは皆、TCPの流れで同じポイントを示さなければなりません: FPDUのためのULPDU Length分野の最初の八重奏。
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.
Marker間隔が複数のFPDUsを含んでいるなら(FPDUsは小さいです)、MarkerはMarkerがFPDUsの間に落ちない場合Markerを含むFPDUのためにULPDU Length分野の始まりを示さなければなりません、その場合、Markerがゼロであるに違いありません。
The following example shows an FPDU containing a Marker.
以下の例は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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の長さ(0×0010)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | ULPDU(八重奏0-9)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×0000) | FPDU ptr(0x000C)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ULPDU(八重奏10-15)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PAD(2つの八重奏: 0、0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example FPDU Format with Marker
図4: マーカーがある例のFPDU形式
MPA Receivers MUST preserve ULPDU boundaries when passing data to DDP. MPA Receivers MUST pass the ULPDU data and the ULPDU Length to DDP and not the Markers, headers, and CRC.
データをDDPに通過するとき、MPA ReceiversはULPDU境界を保持しなければなりません。 MPA ReceiversはMarkers、ヘッダー、およびCRCではなく、DDPにULPDUデータとULPDU Lengthを渡さなければなりません。
4.4. CRC Calculation
4.4. CRC計算
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) いつもCRCsを使用してください。 MPAプロバイダーはCRCsが使用されないというアドミニストレータの要求を支持するREQUIREDではありません。
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)はシステム管理者の明白な要求のときにCRCsを使用しないように優先を示すだけです、この仕様に基づき定義されなかったインタフェースを通して。 接続のためのデフォルト設定はCRCsを使用することでなければなりません。
Culley, et al. Standards Track [Page 16] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[16ページ]。
(2b) disable CRC checking (and possibly generation) if both the local
and remote endpoints indicate preference not to use CRCs.
(2b) 両方の地方の、そして、遠く離れた終点がCRCsを使用しないように好みを示すかどうかチェックする(そして、ことによると世代)CRCを無効にしてください。
An administrative decision to have a host request CRC suppression SHOULD NOT be made unless there is assurance that the TCP connection involved provides protection from undetected errors that is at least as strong as an end-to-end CRC32c. End-to-end usage of an IPsec cryptographic integrity check is among the ways to provide such protection, and the use of channel bindings [NFSv4CHANNEL] by the ULP can provide a high level of assurance that the IPsec protection scope is end-to-end with respect to the ULP.
ホストにTCP接続がかかわった保証がない場合CRC抑圧SHOULD NOTが作られるよう要求させるという管理的意思決定は非検出された誤りからの終わりから終わりへのCRC32cと少なくとも同じくらい強い保護を提供します。 そのような保護を提供する方法の中にIPsecの暗号の保全チェックの終わりから終わりへの用法があります、そして、ULPによるチャンネル結合[NFSv4CHANNEL]の使用はULPに関してIPsec保護範囲が終わらせる終わりであるという高いレベルを保証を提供できます。
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.
同輩がCRCsを必要とするのを示すMPA始動宣言の領収書の後に、MPA例は、接続が終わるまで、CRCsを発生して、チェックし続けなければなりません。 MPA例が、CRCsを必要としないと宣言したなら、それは同輩もCRCsを必要としないのを示すMPAモード宣言の領収書直後チェックするCRCをオフにしなければなりません。 それは、CRCsを発生させ続けるかもしれません。 MPA始動に関する詳細に関してセクション7.1、Connection Setupを見てください。
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分野を入れなければなりません。 CRCsが有効にされるとき、CRCはHeaderとData DigestsのためのiSCSIプロトコル[iSCSI]ドキュメントで説明された方法で計算された使用がCRC32c多項式であったなら中でMPA FPDU MUSTをさばきます。
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) MarkerがすぐにULPDU Length分野に先行しないなら、CRC-32cはすべてのULPDUとMarkersを通したULPDU Length分野の最初の八重奏から計算されるのと(現在)です、PADの最後の八重奏に(存在しているなら)、包括的です。 すぐにPADに続くMarkerがあれば、Markerはこの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) MarkerがすぐにFPDUのULPDU Length分野の最初の八重奏に先行するなら(すなわち、MarkerはFPDUsの間で低下して、その結果、第2FPDUに含まれなければなりません)、CRC-32cはMarkerの最初の八重奏からULPDU Lengthヘッダー、すべてのULPDUとMarkersを通して計算されるのと(現在)です、PADの最後の八重奏に(存在しているなら)、包括的です。
3) After calculating the CRC-32c, the resultant value is placed into
the CRC field at the end of the FPDU.
3) CRC-32cについて計算した後に、結果の値はFPDUの端にCRC分野に置かれます。
Culley, et al. Standards Track [Page 17] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[17ページ]。
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.
Error Semantics、取り扱いの無効のFPDUsのための手順はセクション8でカバーされています。
The following is an annotated hex dump of an example FPDU sent as the first FPDU on the stream. As such, it starts with a Marker. The FPDU contains a 42 octet ULPDU (an example DDP segment) which in turn contains 24 octets of the contained ULPDU, which is a data load that is all zeros. The CRC32c has been correctly calculated and can be used as a reference. See the [DDP] and [RDMAP] specification for definitions of the DDP Control field, Queue, MSN, MO, and Send Data.
↓これはFPDUが流れのときに最初のFPDUとして送った例の注釈された十六進法ダンプです。 そういうものとして、それはMarkerから始まります。 FPDUは順番にすべてゼロであるデータ負荷である含まれたULPDUの24の八重奏を含む42八重奏ULPDU(例のDDPセグメント)を含んでいます。 CRC32cを正しく計算して、参照として使用できます。 DDP Control分野、Queue、MSN、MO、およびSend Dataの定義のための[DDP]と[RDMAP]仕様を見てください。
Culley, et al. Standards Track [Page 18] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[18ページ]。
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マーカー: FPDUPTR0003 00 0004 00ULPDU Length0005 2a0006 41DDP Control Field、LastとSendはセット0007 43 0008 00Reservedに旗を揚げさせます。(DDP STagは1 0011 00 0012 00 0013 01 0014 00DDP STag) 0009 00 000a00 000b00 000c00DDP Queue=0 000d00 000e00 000f00 0010 00DDP MSN=MOなしで=0 0015 00 0016 00 0017 00 0018 00DDP Send Data(ゼロの24の八重奏)を置きます… 002f00 0030 52CRC32c0031 23 0032 99 0033 83
Figure 5: Annotated Hex Dump of an FPDU
図5: FPDUの注釈された十六進法ダンプ
Culley, et al. Standards Track [Page 19] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[19ページ]。
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.
↓これは流れの第2FPDUが最初のFPDU(ここに示されない)が492の八重奏の長さを持って、また、Last FlagとQueue0へのSendであったところにセットしたので送られた例です。 この例はMarkerを含んでいます。
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
01ec00長さの01ed 2a 01ee41DDP制御フィールド: 0 2 01f9 00 01fa 00 01fb 02 01fc00DDP Last Flagセット01ef 43 01f0 00Reserved(STagがSTagなしで置くDDP)01f1 00 01f2 00 01f3 00 01f4 00DDP Queue=0 01f5 00 01f6 00 01f7 00 01f8 00DDP MSN=MO=01fd 00 01fe 00 01ffで、00 0200 00Markerを送ってください: 控え目な0201 00 0202 00マーカー: FPDUPTR0203 14 0204 00DDP Send Data(ゼロの24の八重奏)… 021b00 021c84CRC32c 021d92 021e58 021f98
Figure 6: Annotated Hex Dump of an FPDU with Marker
図6: マーカーとのFPDUの注釈された十六進法ダンプ
Culley, et al. Standards Track [Page 20] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[20ページ]。
4.5. FPDU Size Considerations
4.5. 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はMaximum Upper LayerプロトコルData Unit(MULPDU)をFPDUをうまくはめ込む最も大きいULPDUのサイズと定義します。 空のTCP Segmentに関しては、MULPDUはMarkersとパッド八重奏のためのスペースを引いたFPDUオーバーヘッド(6つの八重奏)を引いたエムスです。
The maximum ULPDU Length for a single ULPDU when Markers are
present MUST be computed as:
Markersが存在しているとき、以下として独身のULPDUのための最大のULPDU Lengthを計算しなければなりません。
MULPDU = EMSS - (6 + 4 * Ceiling(EMSS / 512) + EMSS mod 4)
MULPDUがエムスと等しい、-(6+4*天井(エムス/512)+エムスのモッズ風の4)
The formula above accounts for the worst-case number of Markers.
Markersの最悪の場合番号のための公式上記のアカウント。
The maximum ULPDU Length for a single ULPDU when Markers are NOT
present MUST be computed as:
Markersが存在していないとき、以下として独身のULPDUのための最大のULPDU Lengthを計算しなければなりません。
MULPDU = EMSS - (6 + EMSS mod 4)
MULPDUがエムスと等しい、-(6+エムスのモッズ風の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を見てください)。 いつ、1FPDUsがあるかが既にTCP Segment、MULPDU MAYに詰め込みました。それに従って、減少します。
DDP SHOULD provide ULPDUs that are as large as possible, but less than or equal to MULPDU.
DDP SHOULDはできるだけ大きいULPDUs、しかし、よりMULPDUを提供します。
If the TCP implementation needs to adjust EMSS to support MTU changes or changing TCP options, the MULPDU value is changed accordingly.
TCP実現が、MTU変化かTCPオプションを変えるのを支持するようにエムスを調整する必要があるなら、それに従って、MULPDU値を変えます。
In certain rare situations, the EMSS may shrink below 128 octets in size. If this occurs, the MPA on TCP sender MUST NOT shrink the MULPDU below 128 octets and is not required to follow the segmentation rules in Section 5.1 and Appendix A.
あるまれな状況で、エムスはサイズにおける128未満の八重奏を縮めるかもしれません。 これが起こるなら、TCP送付者の上のMPAはMULPDUを128未満の八重奏まで縮めてはいけなくて、セクション5.1とAppendix 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.
1FPDUsが残っている部屋が128未満の八重奏であるように既にTCPセグメントに詰め込まれるなら、MPA MUST NOTは128より小さくMULPDUを提供します。 この場合、MPAは次の完全な大きさで分けられたセグメントにMULPDUを通常提供するでしょうが、まだ小さい残っている部屋に次のFPDUに詰め込んでいるかもしれなくて、次のFPDUが合うことができるくらい小さいのを供給してください。
The value 128 is chosen as to allow DDP designers room for the DDP Header and some user data.
値128はDDP Headerといくつかの利用者データのDDPデザイナー部屋を許容するほど選ばれています。
Culley, et al. Standards Track [Page 21] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[21ページ]。
5. MPA's interactions with TCP
5. TCPとのMPAの相互作用
The following sections describe MPA's interactions with TCP. This section discusses using a standard layered TCP stack with MPA attached above a TCP socket. Discussion of using an optimized MPA- aware TCP with an MPA implementation that takes advantage of the extra optimizations is done in Appendix A.
以下のセクションはTCPとのMPAの相互作用について説明します。 このセクションは、TCPソケットの上に取り付けられるMPAと共に標準の層にされたTCPスタックを使用すると論じます。 Appendix Aで余分な最適化を利用するMPA実現との最適化されたMPA意識しているTCPを使用する議論をします。
+-----------------------------------+
| +-----+ +-----------------+ |
| | MPA | | Other Protocols | |
| +-----+ +-----------------+ |
| || || |
| ----- socket API -------------- |
| || |
| +-----+ |
| | TCP | |
| +-----+ |
| || |
| +-----+ |
| | IP | |
| +-----+ |
+-----------------------------------+
+-----------------------------------+ | +-----+ +-----------------+ | | | MPA| | 他のプロトコル| | | +-----+ +-----------------+ | | || || | | ----- ソケット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.
Fullyは層にしました。実現は完全性のために説明されます。 しかしながら、ユーザはこの実現で伝わるとFPDU整列の減少している確率が、最適化された受信機で、より高いオーバーヘッドを導入する傾向があると警告されます。 さらに、故障することの不足は、より高いバッファリングを課すことによってDDP/MPAの値をかなり減少させて、地方の受信機にオーバーヘッドをコピーしながら、処理を受けます。
5.1. MPA transmitters with a standard layered TCP
5.1. 規格があるMPA送信機はTCPを層にしました。
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送信機SHOULDはセクション4.5で説明されるようにMULPDUについて計算します。 TCP実現が、エムスがMPAによって決定されるのを許容するなら、その値は使用されるべきです。 TCP実現が、エムス、現在のMTUが評価するMPA SHOULD使用がありそうな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送信機SHOULDはTCPスタックがTCP送信機がFPDU境界におけるTCPセグメントを始めることを引き起こすために提示するどんな施設も使用します。 複数のFPDUsがそれらがTCPセグメントに完全に含まれている限り、エムス計算で決定するただ一つのTCPセグメントに詰め込まれるかもしれません。
Culley, et al. Standards Track [Page 22] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[22ページ]。
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.
例えば、TCPソケットへの現在のエムスに大きさで分けられて、ネーグル[RFC896]アルゴリズムを無効にするのにTCP_NODELAYソケットオプションを使用することでバッファをFPDUに渡すと、通常、FPDUから始まるセグメントの多くがもたらされるでしょう。
It is recognized that various effects can cause an FPDU Alignment to be lost. Following are a few of the effects:
様々な効果でFPDU Alignmentをなくす場合があると認められます。 以下に、効果のいくつかがあります:
* 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 Alignmentをなくすでしょう。 ダイナミックなMULPDUの慎重な使用がこの場合助けることができることに注意してください。 現在のエムスに基づくセグメントで整列を復職させるように将来のFPDUsのためのMULPDUを調整できます。
* Sending enough data that the TCP receive window limit is reached.
TCP may send a smaller segment to exactly fill the receive
window.
* TCPが受け取る十分なデータを送って、窓の限界に達しています。 TCPが、より小さいセグメントをまさに中詰めに送るかもしれない、窓を受けてください。
* Sending data when TCP is operating up against the congestion
window. If TCP is not tracking the congestion window in
segments, it may transmit a smaller segment to exactly fill the
receive window.
* TCPが混雑ウィンドウに直面して作動しているとき、データを送ります。 TCPがセグメントで混雑ウィンドウを追跡していないなら、まさにいっぱいになるように、より小さいセグメントを伝えるかもしれない、窓を受けてください。
* Changes in EMSS due to varying TCP options, or changes in MTU.
* エムスにおける変化は異なったTCPオプション、またはMTUにおける変化がそうします。
If FPDU Alignment with TCP segments is lost for any reason, the alignment is regained after a break in transmission where the TCP send buffers are emptied. Many usage models for DDP/MPA will include such breaks.
どんな理由でもTCPセグメントがあるFPDU Alignmentをなくすなら、トランスミッションにおけるTCPが発信するところでバッファが空にされている休みの後に整列を取り戻します。 DDP/MPAの多くの用法モデルがそのような中断を入れるでしょう。
MPA receivers are REQUIRED to be able to operate correctly even if alignment is lost (see Section 6).
整列が無くなっても(セクション6を見てください)、MPA受信機は正しく作動できるREQUIREDです。
5.2. MPA receivers with a standard layered TCP
5.2. 規格があるMPA受信機はTCPを層にしました。
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境界を決定するためにマーカーを調べる必要はありません。
Culley, et al. Standards Track [Page 23] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[23ページ]。
6. MPA Receiver FPDU Identification
6. MPA受信機FPDU識別
An MPA receiver MUST first verify the FPDU before passing the ULPDU to DDP. To do this, the receiver MUST:
ULPDUをDDPに渡す前に、MPA受信機は最初に、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つを使用しなければなりません:
1: In an ordered TCP stream, the ULPDU Length field in the current
FPDU when FPDU has a valid CRC, can be used to identify the
beginning of the next FPDU.
1: FPDUであるときに、命令されたTCPストリームでは、現在のFPDUのULPDU Length分野は有効なCRCを持って、次のFPDUの始まりを特定するのに使用できます。
2: For optimized MPA/TCP receivers that support out-of-order
reception of FPDUs (see Section 4.3, MPA Markers) a Marker can
always be used to locate the beginning of an FPDU (in FPDUs with
valid CRCs). Since the location of the Marker is known in the
octet stream (sequence number space), the Marker can always be
found.
2: 最適化されたMPA/TCPに関しては、FPDU(有効なCRCsとFPDUsの)の始まりの場所を見つけるのにいつもFPDUs(セクション4.3を見てください、MPA Markers)の故障しているレセプションがMarkerであるとサポートする受信機は使用できます。 Markerの位置が八重奏ストリーム(一連番号スペース)で知られているので、いつもMarkerを見つけることができます。
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: Marker、最適化されたMPA/TCP受信機によるFPDUがそうすることができるのがわかったので、次のFPDU境界を証明するのに、ULPDU Length分野(有効なCRCsとFPDUsからの)を使用することによって、次の隣接のFPDUsを見つけてください。
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をDDPに送る前に全体のFPDUが存在しているかどうか決定するのに、ULPDU Length分野(セクション4を見る)を使用しなければなりません。
CRC calculation is discussed in Section 4.4 above.
上のセクション4.4でCRC計算について議論します。
7. Connection Semantics
7. 接続意味論
7.1. Connection Setup
7.1. 接続設定
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は、ConsumerがMPAのためにMPA、およびどんなTCP増進も起動しなければならないのを必要とします、送付者と受信機の両方の八重奏ストリームにおける同じ位置でのTCP半分接続に関して。Marker体系が正しく、Markers(可能にされるなら)の場所を見つけて、正しく最初のFPDUの場所を見つけるのにこれが必要です。
MPA, and any TCP enhancements for MPA are enabled by the ULP in both directions at once at an endpoint.
MPA、およびMPAのためのどんなTCP増進もそうです。すぐに、終点でULPによって両方の方向に可能にされます。
Culley, et al. Standards Track [Page 24] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[24ページ]。
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 MAYはTCP接続設定直後MPA始動でDDPを必要とします。 これには、いいえがモード交渉を流して、必要である利点があります。 そのようなプロトコルに関する例は図10に示されます: 例のImmediate Startup交渉。
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 MAYは通常のTCP始動の後にいつかMPAにおけるDDPで開始を交渉します、同じ接続のときにTCPのストリーミングのデータ交換を使用して。 交換は、MPA(他のULPsと同様に)の上のDDPが使用されるのを確立して、まさに、八重奏ストリームにおけるMPAが活動を開始することになっているポイントの場所を見つけます。 この仕様の範囲の外にそのような交渉プロトコルがあることに注意してください。 そのようなプロトコルに関する簡単な例は図9に示されます: 33ページにおける例のDelayed Startup交渉。
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.
Startup Phaseは、正しいMPAセットアップ、交換CRC、およびMarker構成について確かめて、DDP接続を終了する前に任意に兵士のDataを終点の間に渡すのに使用されます。 この段階の間、CRCsかMarkersを使用しないで、TCPバイト・ストリームとして明確にフォーマットされたフレームを交換します。 この段階の間、DDP終点はMPA接続に「縛られる必要はありません」。 事実上、兵士のData(もしあれば)に供給されたConsumerがConsumerによって調べられるまで、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は関係するすべての規則(CRCs、Markers、MULPDU制限など)を使用させられるFull Operationです。 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.
兵士のDataがStartup PhaseのULPsの間で渡されるとき、ULPはそのデータを解釈して、次に、MPAをFull Operationに置くのに責任があります。
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).
以下に注意してください。 それらをInitiatorとResponderと呼ぶことによって、以下のテキストは2つの終点を差別化します。 これは、かなり任意であり、TCP始動(SYN、SYN/ACK系列)に関連しません。 Initiatorは最初にMPA始動系列(MPA Request Frame)を送る側です。
Culley, et al. Standards Track [Page 25] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[25ページ]。
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つはこの施設を必要とするアプリケーションがわずかであったという(このドキュメント時点のまさしく理論上の)ことでした。 別のものは施設が特に「デュアルスタック」デザインが後で説明されているいくつかの実装困難を作成したということでした。 最後の問題は始動で拒絶された接続に対処するのが少なくとも追加フレームタイプ、および、より多くの回復動作を必要としただろうということでした、プロトコルを複雑にして。 これらの問題のいずれも圧倒的でなかった間、グループとimplementersは、これらの問題を解決するために仕事をするために動機づけられませんでした。 プロトコルがこれらのアクティブであるか活発な始動試みを検出するメソッドを含んでいるので、それらを拒絶できて、誤りは報告しました。
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.
どの側がInitiatorかそれともResponderであるかを決定するのにULPは責任があります。 クライアント/サーバタイプULPsに関しては、これは簡単です。 同輩同輩ULPs(TCPのスタイルのアクティブであるか活発な始動を利用するかもしれない)に関しては、何らかのメカニズム(この仕様で、定義されない)が確立しているに違いありませんか、またはいくつかのストリーミングのモードデータが決定するInitiatorで始めに面があって、Responder MPAモードで始まるMPA始動の前に交換されています。
7.1.1 MPA Request and Reply Frame Format
7.1.1 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 ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | | + キー(「MPA ID Reqフレーム」を含む16バイト)+4| (4D50 41 20 49 44 20 52 65 71 20 46 72 61 6D65) | + +か(「MPA IDレップフレーム」を含む16バイト)8| (4D50 41 20 49 44 20 52 65 70 20 46 72 61 6D65) | + + 12 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 |M|C|R| Res| 回転| PD_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ 個人的なデータ~| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPA Request/Reply Frame
エイト環: MPA要求/回答フレーム
Culley, et al. Standards Track [Page 26] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[26ページ]。
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フレーム」か(バイトオーダーにおける)4D50 41 20 49 44 20 52 65 71 20 46 72 61 6D65(16進の)にこの分野を設定しなければなりません。 他の値が検出されるなら、応答者モード受信機は、同じ値がないかどうかこの分野をチェックして、接続を終えて、局所的に誤りを報告しなければなりません。 応答者モード送付者は一定の価値「MPA IDレップフレーム」か(バイトオーダーにおける)4D50 41 20 49 44 20 52 65 70 20 46 72 61 6D65(16進の)にこの分野を設定しなければなりません。 他の値が検出されるなら、創始者モード受信機は、同じ値がないかどうかこの分野をチェックして、接続を終えて、局所的に誤りを報告しなければなりません。
M: This bit declares an endpoint's REQUIRED Marker usage. When this
bit is '1' in an MPA Request Frame, the Initiator declares that
Markers are REQUIRED in FPDUs sent from the Responder. When set
to '1' in an MPA Reply Frame, this bit declares that Markers are
REQUIRED in FPDUs sent from the Initiator. When in a received
MPA Request Frame or MPA Reply Frame and the value is '0',
Markers MUST NOT be added to the data stream by that endpoint.
When '1' Markers MUST be added as described in Section 4.3, MPA
Markers.
M: このビットは、終点のREQUIRED Markerが用法であると宣言します。 このビットがMPA Request Frameの'1'であるときに、Initiatorは、MarkersがResponderから送られたFPDUsのREQUIREDであると宣言します。 MPA Reply Frameの'1'に設定されると、このビットは、MarkersがInitiatorから送られたFPDUsのREQUIREDであると宣言します。 いつ、容認されたMPA Request FrameかMPA Reply Frameと値には、'0'、Markersがあるかはその終点によってデータ・ストリームに加えられてはいけません。 MPA Markers、'1'Markersが加えなければならないとき、セクション4.3で説明されるように、加えられてください。
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 Request FrameとMPA Reply Frameの'0'であるときに、CRCsはチェックされてはいけなくて、どちらの終点によっても生成される必要はありません。 このビットがMPA Request FrameかMPA Reply Frameのどちらかの'1'であるときに、両方の終点でCRCsを生成されて、チェックしなければなりません。 どんな使用にも、CRC分野がFPDUに存在していたままで残っていなかったら、それに注意してください。 CRCsが使用中でないときに、コンテンツにかかわらずチェックするFPDUに有効であるとCRC分野を考えなければなりません。
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 Request Frameのレセプションでゼロに合わせて、このビットがチェックしないように設定されます。 MPA Reply Frameでは、このビットは接続パラメタの承認'0'、または拒絶'1'が兵士のDataに供給されるのを示すようにResponders ULPによって設定されたRejected Connectionビットです。
Res: This field is reserved for future use. It MUST be set to zero
when sending, and not checked on reception.
Res: この分野は今後の使用のために予約されます。 それを、発信するとき、ゼロに設定して、レセプションでチェックしてはいけません。
Culley, et al. Standards Track [Page 27] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[27ページ]。
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.
回転: この分野は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_の長さ: この分野は兵士のData分野の八重奏における長さを含まなければなりません。 ゼロの値は、全く現在でない兵士のData分野があるのを示します。 受信機がそれを検出するならPD_Length分野が兵士のData分野の長さに合っていないか、兵士のData分野の長さが512の八重奏を超えているなら、受信機は、接続を終えて、局所的に誤りを報告しなければなりません。 さもなければ、MPA受信機はPD_Length値と兵士のDataを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によって定義されたどんな値も含むかもしれないか、または存在していないかもしれません。 兵士のData分野は長さが0〜512の八重奏であるに違いありません。 ULPsは設定されたサイズへのその方法を定義して、これらの限界の中でこの分野を有効にします。 セクション7.1.4で個人的なData用法についてさらに議論します。
7.1.2. Connection Startup Rules
7.1.2. 接続始動規則
The following rules apply to MPA connection Startup Phase:
以下の規則はMPA接続Startup Phaseに適用されます:
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がInitiatorモードで始動されるとき、MPA実装は有効なMPA Request Frameを送らなければなりません。 MPA Request FrameはULPによって供給された兵士のDataを含むかもしれません。
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がResponderモードで始動されるとき、Full MPA/DDP Operationに入る前にMPA Request Frameが受け取られて、有効にされるまで、MPA実装は待たなければなりません。
If the MPA Request Frame is improperly formatted, the
implementation MUST close the TCP connection and exit MPA.
MPA Request Frameが不適切にフォーマットされるなら、実装は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 Request Frameが適切にフォーマットされますが、兵士のDataが許容できないなら、実装SHOULDは'1'に設定されたRejected ConnectionビットでMPA Reply Frameを返します。 MPA Reply FrameはULPによって供給された兵士のDataを含むかもしれません。 TCP接続を開いた状態でおいて、実装はMPAを出なければなりません。 ULPは他の目的にTCPを閉じるか、または接続を使用するかもしれません。
If the MPA Request Frame is properly formatted and the Private
Data is acceptable, the implementation SHOULD return an MPA Reply
Frame with the Rejected Connection bit set to '0'; the MPA Reply
MPA Request Frameが適切にフォーマットされて、兵士のDataが許容できるなら、実装SHOULDは'0'に設定されたRejected ConnectionビットでMPA Reply Frameを返します。 MPA回答
Culley, et al. Standards Track [Page 28] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[28ページ]。
Frame MAY include ULP-supplied Private Data; and the Responder
SHOULD prepare to interpret any data received as FPDUs and pass
any received ULPDUs to DDP.
フレームはULPによって供給された兵士のDataを含むかもしれません。 そして、Responder SHOULDはFPDUsとして受け取られたどんなデータも解釈して、どんな容認されたULPDUsも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.
以下に注意してください。 Markersに対処する受信機の性能がRequestとReply Framesを受け取るまで未知であるので、これが起こる前にFPDUsを送るのは可能ではありません。
Note: The requirement to wait on a Request Frame before sending a
Reply Frame is a design choice. It makes for a well-ordered
sequence of events at each end, and avoids having to specify
how to deal with situations where both ends start at the same
time.
以下に注意してください。 Reply Frameを送る前にRequest Frameで待っているという要件はデザイン選択です。 それは、各端のときにイベントの秩序立っている系列になって、両端が同時に始まるところで状況に対処する方法を指定しなければならないのを避けます。
3. MPA Initiator mode implementations MUST receive and validate an
MPA Reply Frame.
3. MPA Initiatorモード実装は、MPA Reply Frameを受けて、有効にしなければなりません。
If the MPA Reply Frame is improperly formatted, the
implementation MUST close the TCP connection and exit MPA.
MPA Reply Frameが不適切にフォーマットされるなら、実装は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 Reply Frameが適切にフォーマットされますが、兵士であるなら、Dataが許容できないか、またはRejected Connectionビットが'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 Reply Frameが適切にフォーマットされて、兵士のDataが許容できて、Reject Connectionビットが'0'に設定されるなら、実装SHOULDはFull MPA/DDP Operation Phaseに入ります。 FPDUsとしてどんな受信データも解釈して、FPDUsとしてDDP ULPDUsを送ります。
4. MPA Responder mode implementations MUST receive and validate at
least one FPDU before sending any FPDUs or Markers.
4. どんなFPDUsやMarkersも送る前に、MPA Responderモード実装は、少なくとも1FPDUを受けて、有効にしなければなりません。
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.
以下に注意してください。 この要件は受信機をFull Operationに手に入れるFPDUが到着する前のInitiator時に許容するために存在しています、Initiatorで潜在的競合条件を避けて。 また、荒いコンセンサスに達する前にこれも仕事グループにおける何らかの討論を受けることがありました。 この要件を排除すると、何人かのタイプのアプリケーションにおける、より速い始動は許されるでしょう。 しかしながら、それで、また、ある実装(特に「デュアルスタック」)ははるかに困難になるでしょう。
5. If a received "Key" does not match the expected value (see
Section 7.1.1, MPA Request and Reply Frame Format) the TCP/DDP
connection MUST be closed, and an error returned to the ULP.
5. 容認された「キー」が期待値に合っていないなら(セクション7.1の.1、MPA Request、およびReply Frame Formatを見てください)、TCP/DDP接続は終えなければなりませんでした、そして、誤りはULPに戻りました。
Culley, et al. Standards Track [Page 29] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[29ページ]。
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. 容認された兵士のData分野は、どちらの終わりにもさらに接続を有効にして、DDPか他のULPパラメタをセットアップするのにConsumersによって使用されるかもしれません。 兵士のData分野を有効にすることの結果、Initiator ULPはTCP/MPA/DDP接続を終えるかもしれません。 Responder SHOULDは兵士のDataの合法化がULPに許容できないなら'1'に設定された「廃棄物接続」ビットでMPA Reply Frameを返します。
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が送られることになっているなら、Markersが有効にされるなら、送られた最初の八重奏はFPDU(FPDUのULPDU Length分野)の始まりがいうことになった特別なMarker0x00000000です。 Markersが有効にされないなら、送られた最初の八重奏はFPDU(FPDUのULPDU Length分野)の始まりです。
8. MPA implementations MUST use the difference between the MPA
Request Frame and the MPA Reply Frame to check for incorrect
"Initiator/Initiator" startups. Implementations SHOULD put a
timeout on waiting for the MPA Request Frame when started in
Responder mode, to detect incorrect "Responder/Responder"
startups.
8. MPA実装は、不正確な「創始者/創始者」始動がないかどうかチェックするのにMPA Request FrameとMPA Reply Frameの違いを使用しなければなりません。 実装SHOULDは不正確な「応答者/応答者」始動を検出するためにResponderモードで始められるとMPA Request Frameを待つのにタイムアウトを置きます。
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分野を有効にしなければなりません。 兵士のData野原を受けるバッファはそのデータを受け取ることができるくらい大きくなければなりません。 兵士のDataの量は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実装SHOULDは全体のセットの始動フレームを待っている間、妥当なタイムアウトを実装します。 これはあるサービス不能攻撃を防ぎます。 ULPs SHOULDはFPDUs、ULPDUs、およびアプリケーション失敗とあるサービス不能攻撃に用心するアプリケーションレベルメッセージを待っている間、妥当なタイムアウトを実装します。
7.1.3. Example Delayed Startup Sequence
7.1.3. 例の遅れた始動系列
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始動に関する例があります。 この例が少しの兵士のDataも使用しない、(それがする例、Example Immediate Startup Using兵士のData、示された後のコネセクション7.1.4が.2である、)、兵士のDataを含んでいるのが完全に法的ですが。 例が少しの兵士のDataも使用しないので「始動フレーム」を受けて、Full OperationにMPAを入れるとき示されたULP相互作用が全くないことに注意してください。
Culley, et al. Standards Track [Page 30] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[30ページ]。
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). |
+---------------------------+
+---------------------------+ |ULPのストリーミングのモード| | こんにちは、>が要求する<。| | DDP/MPAへの変遷| +---------------------------+ | モード(任意の)。 | -------->| ULPは要求を得ます。 | +---------------------------+ | MPA Responderを有効にします。| | 最終が(任意)であることでのモード| | ストリーミングのモード| | <、こんにちは、MPAのためのAck>。| | 発信してください。 | +---------------------------+ |MPAは入来を待っています。| |ULPはストリーミングを受けます。| <、-、-、-、-、-、-、--、| <MPAはフレーム>を要求します。 | | <、こんにちは、Ack>。 | +---------------------------+ |MPA Initiatorモードを入れます。 | |MPAは発信します。| | <MPAはフレーム>を要求します。 | |MPAは入来を待っています。| +---------------------------+ | <MPA回答フレーム>。 | - - - - >| MPAは受信します。| +---------------------------+ | <MPAはフレーム>を要求します。 | |消費者はMPAにDDPを縛ります。 | |MPAは発信します。| | <MPA回答フレーム>。 | |DDP/MPAはFPDUを有効にします。| +---------------------------+ | しかし、解読するのはそうしません。| |MPAは受信します。| <--、--、--、-| あらゆるFPDUsを送ってください。 | | <MPA回答フレーム>。| +---------------------------+ |消費者はMPAにDDPを縛ります。 | |DDP/MPAはFullを始めます。| | 操作。 | |MPAは最初のFPDUを送ります。(as| +---------------------------+ | DDP ULPDUsはなります。| ========>| MPAは最初のFPDUを受けます。 | | 利用可能). | |MPA sends first FPDU (as | +---------------------------+ | DDP ULPDUs become | <====== | available). | +---------------------------+
Figure 9: Example Delayed Startup Negotiation
図9: 例の遅れた始動交渉
Culley, et al. Standards Track [Page 31] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[31ページ]。
An example Delayed Startup sequence is described below:
例のDelayed Startup系列は以下で説明されます:
* 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 Initiator)は事実上、「こんにちは、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 Responder)がこのストリーミングのモードメッセージを得るとき、Consumerは事実上、「私は、あなたのHelloを承認して、現在、MPA Responderモードでいます」と言う最後のストリーミングのモードメッセージを送るでしょう。 これらのメッセージの交換はTCPストリームにおけるMPAが有効にされる正確なポイントを確立します。 Responding ConsumerはResponderモードで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.
* Initiating ConsumerはMPA Request Frameがその時発信するInitiatorモードにおけるMPA始動を可能にするでしょう。 そうするのが可能ですが、兵士のDataメッセージは全くこの例に必要でないと思われます。 また、Initiating MPA(そして、Consumer)は、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.
* Responding MPAは、初期のMPA Request Frameを受けて、このメッセージが到着したことをConsumerに知らせるでしょう。 Consumerは次に、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.
* Responding ConsumerはDDP終点にTCP/MPA接続を縛るのに適切なAPIを使用するでしょう、接続要求を受け入れるなら、その結果、MPA/DDPをFull Operationに可能にします。 Full Operationに行くことの途中に、MPAはMPA Reply Frameを送ります。 どんなFPDUsも送る前に、MPA/DDPは最初の入って来る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 Request Frameでなかったなら、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.
* Initiating MPAはMPA Reply Frameを受けて、このメッセージをConsumerに報告するでしょう。 Consumerは、プロセスを中止するためにTCP接続を次に、MPA/DDP接続を受け入れるか、終えるか、またはリセットできます。
* 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.
* 接続が許容できることを決定すると、Initiating Consumerは、その結果、DDP終点にTCP/MPA接続を縛るのにMPA/DDPをFull Operationに可能にしながら、適切なAPIを使用するでしょう。 MPA/DDPは、MPA FPDUsとしてDDPメッセージを送り始めるでしょう。
Culley, et al. Standards Track [Page 32] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[32ページ]。
7.1.4. Use of Private Data
7.1.4. 個人的なデータの使用
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接続情報交換に対処できるメソッドを示すので。
7.1.4.1. Motivation
7.1.4.1. 動機
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.
バンドで出ているメカニズムで兵士のDataを提供する先のRDMAプロトコルを開発してあります。その結果、多くのアプリケーションが、現在、DDP/RDMA接続をセットアップする前に兵士のDataの何らかのフォームがアプリケーション使用に利用可能であると予想します。 以下に、兵士のDataの使用に関するいくつかの例があります。
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終点(インフィニバンドと[VERBS-RDMA]にQueue Pair、またはQPと呼ばれる)はProtection Domainに関連しているに違いありません。 いいえは操作を受けます。それがProtection Domainに関連している前に終点に掲示されるかもしれません。 本当にインフィニバンドと提案されたRDMA/DDP動詞[VERBS-RDMA]の両方の下では、終点/QPはProtection Domainの中で作成されます。
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].
いくつかの利用がProtection Domainの選択がリモートULPクライアントのアイデンティティに依存しているところにあります。 例えば、ユーザセッションが複数の接続を必要とするなら、それらの接続が皆、独身のProtection Domainを使用するのは、非常に望ましいです。 以下に注意してください。 [RDMASEC]でさらにProtection Domainsの使用について議論します。
InfiniBand, the DAT APIs [DAT-API], and the IT-API [IT-API] all provide for the active-side ULP to provide Private Data when requesting a connection. This data is passed to the ULP to allow it to determine whether to accept the connection, and if so with which endpoint (and implicitly which Protection Domain).
インフィニバンド、DAT API[DAT API]、およびIT API[IT API]は、接続を要求するとき、兵士のDataを提供するためにアクティブなサイドULPにすべて備えます。 このデータが接続を受け入れるかどうか決定するのを許容して、そうだとすれば、どの終点でULPに通過されるか、(それとなく、どのProtection Domain)
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 Read容量のような件でそれらのRDMA終点を矛盾なく構成したのを保証するのに兵士のDataを使用できます([RDMAP]を見てください)。 また、さらなる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理由のためのどんな交渉の完成も許すために接続を受け入れるとき、個人的なDataは考慮されます。
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.
この兵士のDataを交換するいくつかの潜在的方法があります。 例えば、インフィニバンド仕様は少量の兵士のDataが交換されるのを実際にRDMA接続を始める前にデータグラムを使用することで許容する接続管理プロトコルを含んでいます。
Culley, et al. Standards Track [Page 33] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[33ページ]。
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.
このドキュメントは、少量の兵士のためにDataがMPA始動系列の一部として交換されるのを許容します。 実際の兵士のData野原はMPA Request FrameとMPA Reply Frameで運ばれます。
If larger amounts of Private Data or more negotiation is necessary, TCP streaming mode messages may be exchanged prior to enabling MPA.
兵士のDataか、より多くの交渉の多く以上の量が必要であるなら、MPAを有効にする前に、TCPのストリーミングのモードメッセージを交換するかもしれません。
Culley, et al. Standards Track [Page 34] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[34ページ]。
7.1.4.2. Example Immediate Startup Using Private Data
7.1.4.2. 個人的なデータを使用する例の即座の始動
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). |
+--------------------------+
+---------------------------+ |TCP SYNは発信しました。 | +--------------------------+ +---------------------------+ -------->| TCPはSYNパケットを得ます。 | +---------------------------+ | SYN-Ackを送ります。 | |TCPはSYN-Ackを手に入れます。| <、-、-、-、-、-、-、-- +--------------------------+ | Ackを送ります。 | +---------------------------+ -------->+--------------------------+ +---------------------------+ |消費者はMPAを有効にします。| |消費者はMPAを有効にします。| |応答者モード、待ち| |創始者モード| | <MPA Requestは>を縁どっています。 | |個人的なデータ。 MPAは発信します。| +--------------------------+ | <MPAはフレーム>を要求します。 | |MPAは入来を待っています。| +--------------------------+ | <MPA回答フレーム>。 | - - - - >| MPAは受信します。| +---------------------------+ | <MPAはフレーム>を要求します。 | |消費者は兵士を調べます。| |データ、MPAに提供します。| |兵士のDataを返してください。| |そしてMPAにDDPを縛る。| |MPAが発信するのを可能にします。| | <MPA回答フレーム>。 | |DDP/MPAはFPDUを有効にします。| +---------------------------+ |しかし、解読するのはそうしません。| |MPAは受信します。| <--、--、--、-|あらゆるFPDUsを送ってください。 | | <MPA回答フレーム>。 | +--------------------------+ |消費者は兵士を調べます。| |データ、MPAへのひものDDP| |そして、DDP/MPAを有効にします。| |Full Operationを始めてください。 | |MPAは最初のFPDUを送ります。(as| +--------------------------+ |DDP ULPDUsはなります。| ========>| MPAは最初のFPDUを受けます。 | |利用可能). | |MPA sends first FPDU (as | +---------------------------+ |DDP ULPDUs become | <====== |available). | +--------------------------+
Figure 10: Example Immediate Startup Negotiation
図10: 例の即座の始動交渉
Note: The exact order of when MPA is started in the TCP connection
sequence is implementation dependent; the above diagram shows one
possible sequence. Also, the Initiator "Ack" to the Responder's
"SYN-Ack" may be combined into the same TCP segment containing
the MPA Request Frame (as is allowed by TCP RFCs).
以下に注意してください。 MPAがTCP接続系列で始動される時に関する正確なオーダーは実装に依存しています。 上のダイヤグラムは1つの可能な系列を示しています。 また、Responderの"SYN-Ack"へのInitiator"Ack"はMPA Request Frameを含む同じTCPセグメントに結合されるかもしれません(TCP RFCsによって許容されているように)。
Culley, et al. Standards Track [Page 35] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[35ページ]。
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.
* 受け身側(Consumerを反応させる)は、接続を受け入れる準備を示すために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.
* アクティブ側(Consumerを開始する)はTCP終点(それは、MPA/DDP/RDMAにアップグレードすると予想して、兵士のDataを予想した)から送付先アドレスとポートまでの接続を要求するでしょう。
* 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.
* Initiating Consumerは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.
* 受け身側(Consumerを反応させる)は、彼らの通常の安全装置/伐採機能を運動させるためにINETDやTCPserverなどの普通のTCP門番を許容しながら、通常通りのTCP接続要求を受け取るでしょう。 TCP接続の承認のときに、Responding ConsumerはResponderモードで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.
* Initiating Consumerは、InitiatorモードにおけるMPA始動が発信する含まれている兵士のDataメッセージがある初期のMPA Request Frameを送るのを可能にするでしょう。 また、Initiating MPA(そして、Consumer)は、MPA接続が受け入れられるのを待っているでしょう、そして、いずれも兵士のDataを返しました。
* The Responding MPA would receive the initial MPA Request Frame
with the Private Data message and would pass the Private Data
through to the Consumer. The Consumer can then accept the
MPA/DDP connection, close the TCP connection, or reject the MPA
connection with a return message.
* Responding MPAは兵士のDataメッセージで初期のMPA Request Frameを受けて、Consumerに終えた兵士のDataを渡すでしょう。 Consumerは次に、MPA/DDP接続を受け入れるか、TCP接続を終えるか、またはリターンメッセージとのMPA関係を拒絶できます。
* To accept the connection request, the Responding Consumer would
use an appropriate API to bind the TCP/MPA connections to a DDP
endpoint, thus enabling MPA/DDP into Full Operation. In the
process of going to Full Operation, MPA sends the MPA Reply
Frame, which includes the Consumer-supplied Private Data
containing any appropriate Consumer response. MPA/DDP waits for
the first incoming FPDU before sending any FPDUs.
* Responding ConsumerはDDP終点にTCP/MPA接続を縛るのに適切なAPIを使用するでしょう、接続要求を受け入れるなら、その結果、MPA/DDPをFull Operationに可能にします。 Full Operationに行くことの途中に、MPAはMPA Reply Frameを送ります。(MPA Reply Frameはどんな適切なConsumer応答も含むConsumerによって供給された兵士のDataを含んでいます)。 どんなFPDUsも送る前に、MPA/DDPは最初の入って来る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 Request Frameでなかったなら、MPAはすぐに、TCP接続を終えるか、またはリセットするでしょう。
Culley, et al. Standards Track [Page 36] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[36ページ]。
* 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.
* Responding Consumerは、MPA接続要求を拒絶するために、どんなULPによって供給された兵士のData(不合格理由がある)、'1'に設定された「拒絶された接続」ビットでもMPA Reply Frameを送って、TCP接続を終えるかもしれません。
* The Initiating MPA would receive the MPA Reply Frame with the
Private Data message and would report this message to the
Consumer, including the supplied Private Data.
* Initiating MPAは兵士のDataメッセージでMPA Reply Frameを受けて、このメッセージをConsumerに報告するでしょう、供給された兵士のDataを含んでいて。
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 Reply Frame兵士のDataから接続が許容できることを決定するとき「拒絶された接続」ビットが設定されるなら、Initiating Consumerは、その結果、DDP終点にTCP/MPA接続を縛るのにMPA/DDPをFull Operationに可能にしながら、適切なAPIを使用するでしょう。 MPA/DDPは、MPA FPDUsとしてDDPメッセージを送り始めるでしょう。
7.1.5. "Dual Stack" Implementations
7.1.5. 「デュアルスタック」実装
MPA/DDP implementations are commonly expected to be implemented as part of a "dual stack" architecture. One stack is the traditional TCP stack, usually with a sockets interface API (Application Programming Interface). The second stack is the MPA/DDP stack with its own API, and potentially separate code or hardware to deal with the MPA/DDP data. Of course, implementations may vary, so the following comments are of an advisory nature only.
「デュアルスタック」アーキテクチャの一部としてMPA/DDP実装が実装されると一般的に予想されます。 あるスタックは通常ソケットインタフェースAPI(アプリケーションProgramming Interface)がある伝統的なTCPスタックです。 2番目のスタックは、MPA/DDPデータに対処するそれ自身のAPIがあるMPA/DDPスタックと、潜在的に別々のコードかハードウェアです。 もちろん、実装が異なるかもしれないので、以下のコメントは顧問に自然であるだけです。
The use of the two stacks offers advantages:
2つのスタックの使用は利点を示します:
TCP connection setup is usually done with the TCP stack. This
allows use of the usual naming and addressing mechanisms. It
also means that any mechanisms used to "harden" the connection
setup against security threats are also used when starting
MPA/DDP.
通常、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の前にいくつかのデータを交換する必要があります。 この交換は、任意の長さか複雑さがあることができますが、少量の兵士のDataだけ、恐らくただ一つのメッセージだけからしばしば成ります。 この交換にTCPのストリーミングのモードを使用するのは、これがよく理解されているメソッドを使用し終わっているのを許容します。
Culley, et al. Standards Track [Page 37] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[37ページ]。
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スタックSHOULDを有効にして、してください。 これはULPプロトコルによって通常管理されます。 お勧めの始動順序に従うと、Responder側は、DDP/MPAモードに入って、最後のストリーミングのモードデータを送って、MPA Request Frameを待っています。 どんな追加ストリーミングのモードデータも予想されません。 Initiatorサイド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 MAYはDDP/MPAが有効にするResponderの一部としての「最後のストリーミングのメッセージ」機能を送る能力を提供します。 これで、DDP/MPAスタックは、より容易にDDP/MPAモードに変換を管理できます(Initiator側からMPA Request Frameの非常に速い復帰に関する問題を避けてください)。
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 MUSTは適切に回復します。
7.2. Normal Connection Teardown
7.2. 正常な接続分解
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).
メカニズムSHOULD、MPAによってDDPに提供されて、DDPをTCP接続の優雅な閉鎖がTCPによって受け取られたのを(例えば、FINは受け取られています)意識するようにしてください。
Culley, et al. Standards Track [Page 38] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[38ページ]。
8. Error Semantics
8. 誤り意味論
The following errors MUST be detected by MPA and the codes SHOULD be provided to DDP or other Consumer:
MPAとコードSHOULDは以下の誤りを検出しなければなりません。DDPか他のConsumerに供給してください:
Code Error
コード誤り
1 TCP connection closed, terminated, or lost. This includes lost
by timeout, too many retries, RST received, or FIN received.
1 TCP接続は、閉じたか、終わったか、または損をしました。 タイムアウト、あまりに多くの再試行、受け取られたRST、または受けられたFINによって失われて、これは含んでいます。
2 Received MPA CRC does not match the calculated value for the
FPDU.
2 容認されたMPA CRCはFPDUのための計算された値に合っていません。
3 In the event that the CRC is valid, received MPA Marker (if
enabled) and ULPDU Length fields do not agree on the start of an
FPDU. If the FPDU start determined from previous ULPDU Length
fields does not match with the MPA Marker position, MPA SHOULD
deliver an error to DDP. It may not be possible to make this
check as a segment arrives, but the check SHOULD be made when a
gap creating an out-of-order sequence is closed and any time a
Marker points to an already identified FPDU. It is OPTIONAL for
a receiver to check each Marker, if multiple Markers are present
in an FPDU, or if the segment is received in order.
3 CRCが有効である場合、容認されたMPA Marker(可能にされるなら)とULPDU Length分野はFPDUの始まりに同意しません。 前のULPDU Length分野から決定しているFPDU始めがMPA Marker位置に合わせないなら、MPA SHOULDは誤りをDDPに提供します。 セグメントとしてこのチェックをするのが到着して、唯一のチェックがSHOULDであることが可能であるのが、ギャップであるときに、作られて、不適切な系列を作成するのが閉じられるということであるということでないかもしれません、そして、いつでも、Markerは既に特定されたFPDUを示します。 それは受信機が各MarkerをチェックするOPTIONALです、複数のMarkersが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 Request FrameかMPA Response Frameが受信しました。 この場合、TCP接続はすぐに、閉店しなければなりません。 DDPと他のULPsは上で1をコード化するために同様の状態でこれを扱うはずです。
When conditions 2 or 3 above are detected, an optimized MPA/TCP implementation MAY choose to silently drop the TCP segment rather than reporting the error to DDP. In this case, the sending TCP will retry the segment, usually correcting the error, unless the problem was at the source. In that case, the source will usually exceed the number of retries and terminate the connection.
上記の状態2か3が検出されるとき、最適化されたMPA/TCP実装は、誤りをDDPに報告するより静かにむしろTCPセグメントを下げるのを選ぶかもしれません。 この場合、発信しているTCPはセグメントを再試行するでしょう、通常、エラーを修正して、問題がソースになかったなら。 その場合、ソースは、通常、再試行の数を超えて、接続を終えるでしょう。
Once MPA delivers an error of any type, it MUST NOT pass or deliver any additional FPDUs on that half connection.
MPAがいったんどんなタイプの誤りも提供すると、それは、その半分接続のときに少しの追加FPDUsも渡してはいけませんし、また提供してはいけません。
For Error codes 2 and 3, MPA MUST NOT close the TCP connection following a reported error. Closing the connection is the responsibility of DDP's ULP.
Errorコード2と3のために、報告された誤りに続いて、MPA MUST NOTは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が半分接続でのどんなFPDUsもどんなDeliverにも望んでいないのでそれに注意してください、オンである、その接続の側面を受け取ってください、そして、DDPのULPが下に接続を苦しませると予想されます。 最後の1つ以上のメッセージが反対の半分接続のときに送られた後までこれは起こらないかもしれません。 これは、診断エラーメッセージが送られるのを許容します。
Culley, et al. Standards Track [Page 39] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[39ページ]。
9. Security Considerations
9. セキュリティ問題
This section discusses the security considerations for MPA.
このセクションはMPAのためにセキュリティ問題について論じます。
9.1. Protocol-Specific Security Considerations
9.1. プロトコル特有のセキュリティ問題
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受信機はどんなパケットも到着するときのDDPへのFPDU境界に適切に位置している場合FPDUとして有効にすることができない誤りを報告します。 また、第三者はTCP、MPA、およびDDPに、有効なパケットを送ることができましたが、有効なバッファを狙わないでください。 これらのタイプの攻撃は、結局、接続の損失をもたらして、その結果、一種のDOS(否定Of Service)攻撃になります。 IPsec[RFC2401、RFC4301]などのコミュニケーションセキュリティー対策は、そのような攻撃を防ぐのに使用されるかもしれません。
Independent of how MPA operates, a third party could use ICMP messages to reduce the path MTU to such a small size that performance would likewise be severely impacted. Range checking on path MTU sizes in ICMP packets may be used to prevent such attacks.
MPAがどう作動するかから独立しています、第三者は経路MTUを同様に厳しく性能に影響を与えるくらいの小型まで減少させるICMPメッセージを使用できました。 ICMPパケットで経路MTUサイズについて検査する範囲は、そのような攻撃を防ぐのに使用されるかもしれません。
[RDMAP] and [DDP] are used to control, read, and write data buffers over IP networks. Therefore, the control and the data packets of these protocols are vulnerable to the spoofing, tampering, and information disclosure attacks listed below. In addition, connection to/from an unauthorized or unauthenticated endpoint is a potential problem with most applications using RDMA, DDP, and MPA.
[RDMAP]と[DDP]は、IPネットワークの上にデータバッファを制御して、読んで、書くのに使用されます。 したがって、これらのプロトコルのコントロールとデータ・パケットはスプーフィング、改ざん、および以下に記載された情報公開攻撃に被害を受け易いです。 さらに、権限のないか非認証された終点からの/との接続はRDMA、DDP、およびMPAを使用するほとんどのアプリケーションの潜在的な問題です。
9.1.1. Spoofing
9.1.1. スプーフィング
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.
Remote Peerかネットワークが攻撃に着手できるスプーフィングは攻撃者を基礎づけました。 ネットワークベースのスプーフィング攻撃はすべてのRemote Peersに適用されます。 MPA StreamがESTABLISHED状態でTCP Streamを必要とするので、あるタイプの伝統的な形式のワイヤ攻撃は適用されません--終わりから終わりとの握手はMPA Streamを証明するために起こったに違いありません。 それで、遠隔ノードがともにパケットを送って、受けることができるとき、適用される唯一の形式のスプーフィングは1です。 しかし、この制限があっても、Streamはまだ以下のスプーフィング攻撃に暴露されています。
Culley, et al. Standards Track [Page 40] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[40ページ]。
9.1.1.1. Impersonation
9.1.1.1. ものまね
A network-based attacker can impersonate a legal MPA/DDP/RDMAP peer (by spoofing a legal IP address) and establish an MPA/DDP/RDMAP Stream with the victim. End-to-end authentication (i.e., IPsec or ULP authentication) provides protection against this attack.
ネットワークベースの攻撃者は、法的なMPA/DDP/RDMAP同輩(法的なIPアドレスを偽造するのによる)をまねて、犠牲者と共にMPA/DDP/RDMAP Streamを設立できます。 終わりから終わりへの認証(すなわち、IPsecかULP認証)はこの攻撃に対する保護を提供します。
9.1.1.2. Stream Hijacking
9.1.1.2. ストリームハイジャック
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.
ストリームハイジャックは、ネットワークベースの攻撃者がStream確立段階の後をつけると起こって、認証フェーズ(そのようなフェーズが存在しているなら)が首尾よく完成するまで、待っています。 彼は、次に、IPアドレスを偽造して、犠牲者からそれ自身のマシンまでStreamを向け直すことができます。 例えば、攻撃者は、iSCSI認証が首尾よく終了するまで待っていて、iSCSI Streamをハイジャックできます。
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などの認証です。 別のオプションは物理的なセキュリティを提供することです。 このドキュメントのための範囲の外に物理的なセキュリティの議論があります。
9.1.1.3. Man-in-the-Middle Attack
9.1.1.3. 介入者攻撃
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は有効ですなど)、中央の男性に対する攻撃であるとStreamを暴露することができます。 攻撃者は、関連Data Bufferのコンテンツを読むか、関連Data Bufferのコンテンツを変更するか、またはバッファへのさらなるアクセスを無効にするのに潜在的に[DDP]と[RDMAP]のサービスを利用できました。 サービスの否定を引き起こすのに接続設定系列と、そして、TCPさえに対する他の攻撃を使用できます。 この形式の攻撃のための唯一の対策は、MPA/DDP/RDMAP Stream(すなわち、保全は保護される)を固定するか、または中央の男性タイプ攻撃を防ぐために物理的なセキュリティを提供するのを試みることです。
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などの認証です。 Streamかセッションレベル認証と保全保護が使用されていないなら、介入者攻撃は起こることができます、スプーフィングと改ざんを可能にして。
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のように。 このモデルは、非常に限られた展開シナリオであり、ここでさらに調べられないでしょう。
Culley, et al. Standards Track [Page 41] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[41ページ]。
9.1.2. Eavesdropping
9.1.2. 盗聴
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.
概して、Stream秘密性は盗聴から守ります。 流れてください、そして、セッション認証と保全保護は様々なスプーフィングと改ざん攻撃に対するカウンタ測定です。 認証の有効性と特定の攻撃に対する保全は認証がマシンレベル認証(IPsecによって提供されたものとしての)かそれともULP認証であるかに依存します。
9.2. Introduction to Security Options
9.2. セキュリティオプションへの序論
The following security services can be applied to an MPA/DDP/RDMAP Stream:
MPA/DDP/RDMAP Streamに以下のセキュリティー・サービスを適用できます:
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. 1パケットあたりのデータ送信端末認証--以下のスプーフィング攻撃から守ります: ネットワークベースのものまね、Streamハイジャック、および中央の男性。
3. Per-packet integrity - protects against tampering done by
network-based modification of FPDUs (indirectly affecting buffer
content through DDP services).
3. 1パケットあたりの保全--FPDUs(間接的に、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 Streamはものまね攻撃、またはStreamハイジャック攻撃を受けることがあるかもしれないなら、Streamが認証されるのが、お勧めであり、保全は、反射攻撃から保護して、保護されました。 それは、盗聴から保護するのに秘密性保護を使用するかもしれません(MPA/DDP/RDMAP Streamが公衆通信回線を横断するといけないので)。
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
「チャンネル結合の概念で、アプリケーションは、異なったネットワーク層における2個の安全なチャンネルのエンドポイントがもう片方のチャンネルで1個のチャンネルでセッション保護と拘束力がある認証で同じであると立証できます。」 チャンネルの使用
Culley, et al. Standards Track [Page 42] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[42ページ]。
bindings allows applications to delegate session protection to
lower layers, which may significantly improve performance for
some applications."
「結合で、アプリケーションは、セッション保護がいくつかのアプリケーションのために性能をかなり向上させるかもしれない層を下ろすのを代表として派遣することができます。」
9.3. Using IPsec with MPA
9.3. MPAとIPsecを使用します。
IPsec can be used to protect against the packet injection attacks outlined above. Because IPsec is designed to secure individual IP packets, MPA can run above IPsec without change. IPsec packets are processed (e.g., integrity checked and decrypted) in the order they are received, and an MPA receiver will process the decrypted FPDUs contained in these packets in the same manner as FPDUs contained in unsecured IP packets.
上に概説されたパケット注射攻撃から守るのにIPsecを使用できます。 IPsecが個々のIPがパケットであると機密保護するように設計されているので、MPAはIPsecの上で変化なしで稼働できます。 IPsecパケットによるオーダーで処理された(例えばチェックされて、解読された保全)それらが受け取られていて、MPA受信機がこれらのパケットに非機密保護しているIPパケットに含まれたFPDUsと同じ方法で含まれた解読されたFPDUsを処理するということです。
MPA implementations MUST implement IPsec as described in Section 9.4 below. The use of IPsec is up to ULPs and administrators.
MPA実装は以下のセクション9.4で説明されるようにIPsecを実装しなければなりません。 IPsecの使用はULPsと管理者次第です。
9.4. Requirements for IPsec Encapsulation of MPA/DDP
9.4. MPA/DDPのIPsecカプセル化のための要件
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 Storageワーキンググループは重要な時間とIP格納[RFC3723]のための標準のIPsec要件を定義するための努力を過ごしました。 その仕様の部分はRDDPプロトコル群を含むさまざまなプロトコルに適切です。 この努力を模写しない命令では、TCP実現でのMPAはRFC3723で定義された要件に続かなければなりません、セクション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加速ハードウェアが(SAs)、Phase2が削除するアクティブなインターネット・キー・エクスチェンジプロトコル(IKE)フェーズ2セキュリティ協会の限られた数を扱うことができるだけであるかもしれないので、使用されていないSAsのためにメッセージを送るかもしれません、アクティブなPhase2SAsの数を最小限に保つ手段として。 IKE Phase2の領収書はメッセージを削除します。引き裂く理由がDDP/RDMA Streamより倒すとき、解釈されてはいけません。 むしろ、Streamが上げる休暇、それを保護するために別のIKE Phase2SAを持って来るためにそれで追加交通を送るなら、望ましいです。 これは絶えずStreamsを上下に持って来る可能性を避けます。
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
RDDPがIPsecのバージョンに基づいているので、IPsec要件は、RFC2401[RFC2401]で指定して、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるようにRFCsを関係づけて、RFCsを関係づけました。 RDDPプロトコルの重要な早めの応用の1つはiSCSI[iSER]との彼らの使用です。 RDDPのIPsec要件は、IPsecの一般的なプロフィールがiSCSIとRDDPプロトコルと共に使用されるのを許容することによってその用法を容易にするためにIPsecのものに続きます。 未来、RFCで
Culley, et al. Standards Track [Page 43] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[43ページ]。
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.
IPsecの、より新しいバージョンに3723をアップデートするかもしれません。 どんなそのようなものの要件もアップデートする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トンネリング装置の間のどんなホストも自由に保護のないStreamを攻撃できます。
10. IANA Considerations
10. IANA問題
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に残されます。
Culley, et al. Standards Track [Page 44] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[44ページ]。
Appendix A. Optimized MPA-Aware TCP Implementations
付録のA.の最適化されたMPA意識しているTCP実現
This appendix is for information only and is NOT part of the standard.
この付録は、情報だけのためにあって、規格の一部ではありません。
This appendix covers some Optimized MPA-aware TCP implementation guidance to implementers. It is intended for those implementations that want to send/receive as much traffic as possible in an aligned and zero-copy fashion.
この付録は何らかのOptimized MPA意識しているTCP実施要項をimplementersにカバーしています。 それはできるだけ並べられて無コピーしているファッションで多くの交通を送りたいか、または受けたがっているそれらの実現のために、意図します。
+-----------------------------------+
| +-----------+ +-----------------+ |
| | Optimized | | Other Protocols | |
| | MPA/TCP | +-----------------+ |
| +-----------+ || |
| \\ --- socket API --- |
| \\ || |
| \\ +-----+ |
| \\ | TCP | |
| \\ +-----+ |
| \\ // |
| +-------+ |
| | IP | |
| +-------+ |
+-----------------------------------+
+-----------------------------------+ | +-----------+ +-----------------+ | | | 最適化されます。| | 他のプロトコル| | | | MPA/TCP| +-----------------+ | | +-----------+ || | | \\ --- ソケット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.
左側で見せられた施設を使用しいくつかの適当なAPIを使用することでDDP/MPA/TCP接続を始めることができますか、またはポイントで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スタックとインタフェースを使用し続けています。
Culley, et al. Standards Track [Page 45] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[45ページ]。
A.1. Optimized MPA/TCP Transmitters
A.1。 最適化されたMPA/TCP送信機
The various TCP RFCs allow considerable choice in segmenting a TCP stream. In order to optimize FPDU recovery at the MPA receiver, an optimized MPA/TCP implementation uses additional segmentation rules.
様々なTCP RFCsは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(s)を含むことができるくらい大きいエムス、セグメントによる出発しているTCPが流れるので、あらゆるTCPセグメントの最初の八重奏はFPDUと共に始まります。 彼らがTCPセグメントに完全に含まれている限り、複数のFPDUsがただ一つのTCPセグメントに詰め込まれるかもしれません。
* Report the current EMSS from the TCP to the MPA transmit layer.
* 現在の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/TCP送付者がMPAに、それを伝えるか、または接続に失敗するということです。 それを否認できません。 MTUとエムスにおける変化かTCPのReceive Windowサイズ(RWIN)が小さくなり過ぎるとき、その結果、発信するために、分割に従わないFPDUsが上で統治するのが必要であるかもしれません。
A possible, but less desirable, alternative is to use IP fragmentation on accepted FPDUs to deal with MTU reductions or extremely small EMSS.
可能な、しかし、それほど望ましくない代替手段はMTU減少か非常に小さいエムスと取り引きするのに受け入れられたFPDUsでIP断片化を使用することです。
Even when alignment with TCP segments is lost, the sender still formats the FPDU according to FPDU format as shown in Figure 2.
TCPセグメントがある整列が無くなるときさえ、FPDU形式に従って、送付者は図2に示されるようにまだ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 retransmissionsの間、TCPセグメントの中でFPDU Alignmentと封じ込めの損失を出すことができます。 最適化されたMPA/TCP送付者は「再-トランスミッション」の上の元のTCP分割境界を保持しようとするべきです。
A.2. Effects of Optimized MPA/TCP Segmentation
A.2。 最適化されたMPA/TCP分割の効果
Optimized MPA/TCP senders will fill TCP segments to the EMSS with a single FPDU when a DDP message is large enough. Since the DDP message may not exactly fit into TCP segments, a "message tail" often occurs that results in an FPDU that is smaller than a single TCP segment. Additionally, some DDP messages may be considerably shorter than the EMSS. If a small FPDU is sent in a single TCP segment, the result is a "short" TCP segment.
DDPメッセージが十分大きいときに、最適化されたMPA/TCP送付者は独身のFPDUでエムスへのTCPセグメントを満たすでしょう。 DDPメッセージがまさにTCPセグメントに収まらないかもしれないので、ただ一つのTCPセグメントより小さいFPDUをもたらす「メッセージテール」はしばしば起こります。 さらに、いくつかのDDPメッセージがエムスよりかなり短いかもしれません。 ただ一つのTCPセグメントで小さいFPDUを送るなら、結果は「短い」TCPセグメントです。
Culley, et al. Standards Track [Page 46] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[46ページ]。
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.
アプリケーションは、Direct Data Placementからの強い利点がトランザクション・ベース・アプリケーションとスループットアプリケーションを含んでいるのを見ると予想しました。 要求/応答プロトコルは、TCPセグメントあたり1FPDUを通常送って、次に、応答を待っています。 これらの条件で、これらの「短い」TCPセグメントは分割の適切で予想された効果です。
Another possibility is that the application might be sending multiple messages (FPDUs) to the same endpoint before waiting for a response. In this case, the segmentation policy would tend to reduce the available connection bandwidth by under-filling the TCP segments.
別の可能性は応答を待つ前にアプリケーションが複数のメッセージ(FPDUs)を同じ終点に送るかもしれないということです。 この場合、分割方針は、利用可能な接続帯域幅を充填してTCPが区分する下の減少させる傾向があるでしょう。
Standard TCP implementations often utilize the Nagle [RFC896] algorithm to ensure that segments are filled to the EMSS whenever the round-trip latency is large enough that the source stream can fully fill segments before ACKs arrive. The algorithm does this by delaying the transmission of TCP segments until a ULP can fill a segment, or until an ACK arrives from the far side. The algorithm thus allows for smaller segments when latencies are shorter to keep the ULP's end-to-end latency to reasonable levels.
標準のTCP実現は、往復の潜在がACKsが到着する前にソースの流れがセグメントを完全にいっぱいにすることができるくらい大きいときはいつも、セグメントがエムスにいっぱいにされるのを保証するのにしばしばネーグル[RFC896]アルゴリズムを利用します。 アルゴリズムは、ULPがセグメントをいっぱいにすることができるか、またはACKが反対側から到着するまでTCPセグメントの送信を遅らせることによって、これをします。 潜在がULPの終わりから終わりが妥当な水準への潜在であることを保つために、より短いときに、その結果、アルゴリズムは、より小さいセグメントを考慮します。
The Nagle algorithm is not mandatory to use [RFC1122].
ネーグルアルゴリズムは、[RFC1122]を使用するために義務的ではありません。
When used with optimized MPA/TCP stacks, Nagle and similar algorithms can result in the "packing" of multiple FPDUs into TCP segments.
最適化されたMPA/TCPスタックと共に使用されると、ネーグルと同様のアルゴリズムはTCPセグメントへの複数のFPDUsの「パッキング」をもたらすことができます。
If a "message tail", small DDP messages, or the start of a larger DDP message are available, MPA may pack multiple FPDUs into TCP segments. When this is done, the TCP segments can be more fully utilized, but, due to the size constraints of FPDUs, segments may not be filled to the EMSS. A dynamic MULPDU that informs DDP of the size of the remaining TCP segment space makes filling the TCP segment more effective.
より大きいDDPメッセージの「メッセージテール」、小さいDDPメッセージ、または始まりが利用可能であるなら、MPAは複数のFPDUsにTCPセグメントに詰め込むかもしれません。 これが完了していると、TCPセグメントをより完全に利用できますが、FPDUsのサイズ規制のため、セグメントはエムスにいっぱいにされないかもしれません。 残っているTCPセグメントスペースのサイズのDDPを知らせるダイナミックなMULPDUはTCPセグメントをいっぱいにするのをより効果的にします。
Note that MPA receivers do more processing of a TCP segment that
contains multiple FPDUs; this may affect the performance of some
receiver implementations.
MPA受信機が複数のFPDUsを含む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.
ネーグルがDDP/MPAによって役に立つかどうか決めるのは、ULP次第です。 MPA/DDPを利用すると予想されたアプリケーションの多くが、ネーグルによって引き起こされた余分な遅れを避けるのを好むことに注意してください。 そのようなシナリオでは、送信機で荷造りする最小量の機会があると予期されて、受信機は、この予期された振舞いによって彼らの性能を最適化するのを選ぶかもしれません。
Culley, et al. Standards Track [Page 47] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[47ページ]。
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のためにネーグルを無能にする接続オプションを提供するべきです。
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実現は、セグメントがエムスにいっぱいにされるように、どんな利用可能なFPDUsにもTCPセグメントに詰め込むかもしれません。 有効なデータ量がいっぱいにするために十分でない、それがあるとき、TCPセグメントはトランスミッションの用意をして、TCPは一部いっぱいにされたセグメントを送ることができます、または、ネーグルアルゴリズムを使用して、ULPが、より多くのデータを掲示するのを待ってください。
A.3. Optimized MPA/TCP Receivers
A.3。 最適化されたMPA/TCP受信機
When an MPA receive implementation and the MPA-aware receive side TCP implementation support handling out-of-order ULPDUs, the TCP receive implementation performs the following functions:
MPAであるときには実現を受けてください。そうすれば、MPA意識しているサイドTCP実現サポート取り扱いの故障しているULPDUsを受けてください、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) それらが受け取られて、有効にされるとすぐに、実現は入って来るTCPセグメントをMPAに通過します、オーダーに受け取られないでも。 それをMPAに通過できる前にTCP層はキープへの各セグメントを遂行します。 セグメントが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).
これは、使用の前にデータを完全に注文しなければならないのを含意しないためのものです。 実現が不適切なセグメントを受け入れることができて、SACKがそれら[RFC2018]であり、パスはギャップを埋めるのに必要であるセグメントのレセプションのすぐ前のMPAへのそれらです。 MPAはそれらが完全なFPDUsであるときに、これらのセグメントを利用すると予想するか、または彼らが到着すると、ULPDUsの通過をDDPに許すために完全なFPDUsに結合できます、注文の如何にかかわらず。 DDPは、DDPセグメントを「置くこと」に通っているULPDUを使用します(その他の詳細に関して[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計算と他のチェックを容認されたFPDUsに実行するので、MPA/TCP実現は、重複データが既に受けて、処理した(TCP再試行の間起こることができるとき)どんなTCPセグメントも既に受け取られていていて処理されたFPDUsを上書きしないのを確実にします。 これは重複データが既に有効にされたFPDUsを崩壊させるかもしれない可能性を避けます。
Culley, et al. Standards Track [Page 48] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[48ページ]。
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 Receive Windowの主な(左)縁を利用することであるかもしれません。
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は、DDPの消費者が同意するDelivery意味論を証明するのに上の2つのメカニズムを利用します。 これらの意味論は[DDP]で完全に説明されます。 これらはDDPがそれらをConsumerに渡す時の前にバッファの所有権を尊敬するというDDPの消費者に関する要件を含んでいます。
The use of SACK [RFC2018] significantly improves network utilization and performance and is therefore recommended. When combined with the out-of-order passing of segments to MPA and DDP, significant buffering and copying of received data can be avoided.
SACK[RFC2018]の使用は、ネットワーク利用と性能をかなり向上させて、したがって、お勧めです。 MPAとDDPにセグメントを通過する故障に結合されると、受信データの重要なバッファリングとコピーを避けることができます。
A.4. Re-Segmenting Middleboxes and Non-Optimized MPA/TCP Senders
A.4。 再区分Middleboxesと非最適化されたMPA/TCP Senders
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送付者がしばしばFPDUsを始動するので、TCPセグメント境界、実現がそうする受信の最適化されたMPA/TCPではいろいろデータのレセプションを最適化できてください。
However, MPA receivers MUST NOT depend on FPDU Alignment on TCP segment boundaries.
しかしながら、MPA受信機はTCPセグメント境界のFPDU Alignmentによってはいけません。
Some MPA senders may be unable to conform to the sender requirements because their implementation of TCP is not designed with MPA in mind. Even for optimized MPA/TCP senders, the network may contain "middleboxes" which modify the TCP stream by changing the segmentation. This is generally interoperable with TCP and its users and MPA must be no exception.
彼らのTCPの実現がMPAと共に念頭に設計されていないので、何人かのMPA送付者は送付者要件に従うことができないかもしれません。 最適化されたMPA/TCP送付者に関してはさえ、ネットワークは分割を変えることによってTCPの流れを変更する「middleboxes」を含むかもしれません。 一般に、これは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(可能にされると)でのMarkersの存在は、これらの障害にもかかわらず、最適化されたMPA/TCP受信機にFPDUsを回収させます、そうするのに受信機での追加バッファリングを利用するのが必要であるかもしれませんが。
Culley, et al. Standards Track [Page 49] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[49ページ]。
Some of the cases that a receiver may have to contend with are listed below as a reminder to the implementer:
受信機が競争しなければならないかもしれないケースのいくつかが思い出させるものとして以下にimplementerに記載されています:
* A single aligned and complete FPDU, either in order or out of
order: This can be passed to DDP as soon as validated, and
Delivered when ordering is established.
* 整然としているか故障している独身の並べられて完全なFPDU: 有効にされるとき、これをDDPに通過できます、そして、注文するとき、Deliveredは設立されます。
* 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セグメントの並べられて、完全に含まれて、整然としているか故障している複数のFPDUs: 有効にされるとき、これらをDDPに通過できます、そして、注文するとき、Deliveredは設立されます。
* 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に通過できます、そして、注文するとき、Deliveredは設立されます。
* 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に通過できます、そして、注文するとき、Deliveredは設立されます。 全体のFPDUが利用可能でないなら、FPDUの残りが到着するまで、受信機はバッファリングするはずです。
* Combinations of unaligned or incomplete FPDUs (and potentially
other complete FPDUs) in the same TCP segment: If any FPDU is
present in its entirety, or can be completed with portions
already available, it can be passed to DDP as soon as validated,
and Delivered when ordering is established.
* 同じTCPセグメントにおける、非同盟の、または、不完全なFPDUs(そして、潜在的に他の完全なFPDUs)の組み合わせ: 何かFPDUを全体として存在しているか、または部分が既に利用可能な状態で完成できるなら、有効にされるとき、それをDDPに通過できます、そして、注文するとき、Deliveredは設立されます。
A.5. Receiver Implementation
A.5。 受信機実現
Transport & Network Layer Reassembly Buffers:
輸送とネットワーク層Reassemblyバッファ:
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 reassemblyバッファかIP断片化再アセンブリバッファのどちらか)の使用は実現に依存しています。 MPAが有効にされるとき、再アセンブリバッファは故障しているなら必要であることで、パケットが到着して、Markersが有効にされないということです。 また、FPDU整列が無くなるか、またはIP断片化が起こるなら、バッファが必要です。 これは入って来る不適切なセグメントがMPAがFPDUのすべてを処理できるくらいの情報を含まないかもしれないからです。 再区分middleboxが出席しているか、またはTCP送付者が最適化されていないケースのために、Markersの存在は必要な状態でバッファリングの量をかなり減少させます。
Recovery from IP fragmentation is transparent to the MPA Consumers.
IP断片化からの回復はMPA Consumersに透明です。
Culley, et al. Standards Track [Page 50] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[50ページ]。
A.5.1 Network Layer Reassembly Buffers
A.5.1ネットワーク層Reassemblyバッファ
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実現はどんなFragmentもIP層で噛み付かなかったIPドンを設定するべきです。 したがって、経路MTU変化では、中間的装置は、それが大き過ぎるならIPデータグラムを落として、経路MTUが変化したとソースTCPに言うICMPメッセージで返答します。 これで、TCPは新しい経路MTUサイズがあるセグメントconformantを放ちます。 したがって、ほとんどの状態の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. [RFC792](必要である断片化とDFはセットした)に応じてICMPメッセージでどんなIP断片、および回答も落として、TCPセグメントをリサイズするようにRemote Peerに言ってください。
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断片がRFC792に応じて発生するべき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データグラム(64KB)のための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に渡すときだけ、そのTCP ACKは起こることができます)。 これのために、最悪の場合、病理学的なシナリオの下では、最も大きいIP再アセンブリバッファはTCPが窓(すべて断片化された複数のIPデータグラムをバッファリングする)を受けるということです。
Note that if the Remote Peer does not implement re-segmentation of the data stream upon receiving the ICMP reply updating the path MTU, it is possible to halt forward progress because the opposite peer would continue to retransmit using a transport segment size that is too large. This deadlock scenario is no different than if the fabric MTU (not last-hop MTU) was reduced after connection setup, and the remote node's behavior is not compliant with [RFC1122].
反対の同輩は、大き過ぎる輸送セグメントサイズを使用することで再送し続けているでしょう、したがって、Remote Peerが経路MTUをアップデートするICMP回答を受け取るときのデータ・ストリームの再分割を実行しないなら、前進の進歩を止めるのが可能であることに注意してください。 この行き詰まりシナリオは織物MTU(最後にMTUを飛び越さない)が接続設定の後に減少したか、そして、遠隔ノードの振舞いほど[RFC1122]と共に言いなりになった状態で異なっていません。
Culley, et al. Standards Track [Page 51] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[51ページ]。
A.5.2 TCP Reassembly Buffers
A.5.2 TCP Reassemblyバッファ
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 reassemblyバッファが必要です。 MPAとTCPを使用するとき、FPDU Alignmentが無くなるか、またはMPA FPDUが複数のTCPセグメントにかかるとき、TCP reassemblyバッファが必要です。 バッファはまた、Markersが障害があって故障しているなら必要であることで、パケットが到着するということです。
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 Alignmentが、しばしばFPDUsが不完全であることを意味するので、TCP実現でのMPAは再アセンブリバッファを局所的に添付のリンクの、よりMTU以下であるFPDUを回収できるくらい大きくしなければなりません(これは可能な限り大きいAdvertised TCP経路MTUであるべきです)。 MTUが140の八重奏より小さいなら、少なくとも140の八重奏に関するバッファが、最小のFPDUサイズを支持するのに長い間、必要です。 140の八重奏が128、2の最小のMULPDUのためにパッドの八重奏、2ULPDU_Length、4CRC、および可能なMarkerのためのスペースを許容します。 いつものように、追加バッファリングは、より良い性能を提供しそうです。
Note that if the TCP segments were not stored, it would be possible to deadlock the MPA algorithm. If the path MTU is reduced, FPDU Alignment requires the source TCP to re-segment the data stream to the new path MTU. The source MPA will detect this condition and reduce the MPA segment size, but any FPDUs already posted to the source TCP will be re-segmented and lose FPDU Alignment. If the destination does not support a TCP reassembly buffer, these segments can never be successfully transmitted and the protocol deadlocks.
TCPセグメントが格納されないなら、行き詰まるのが可能であることに注意してください。MPAアルゴリズム。 経路MTUが減少するなら、FPDU Alignmentはデータが新しい経路MTUに流す再セグメントにソースTCPを必要とします。 ソースMPAがこの状態を検出して、MPAセグメントサイズを減少させますが、既にソースTCPに掲示されたどんなFPDUsも再区分されて、FPDU Alignmentをなくすでしょう。 目的地がTCP reassemblyバッファを支持しないなら、これらのセグメントは、首尾よく伝えられてプロトコル行き詰まりであるはずがありません。
When a complete FPDU is received, processing continues normally.
完全なFPDUが受け取られているとき、通常、処理は続きます。
Appendix B. Analysis of MPA over TCP Operations
TCP操作の上のMPAの付録B.分析
This appendix is for information only and is NOT part of the standard.
この付録は、情報だけのためにあって、規格の一部ではありません。
This appendix is an analysis of MPA on TCP and why it is useful to integrate MPA with TCP (with modifications to typical TCP implementations) to reduce overall system buffering and overhead.
この付録はTCPと総合体系バッファリングとオーバーヘッドを下げるためにTCP(典型的なTCP実現への変更がある)とMPAを統合するのが役に立つ理由におけるMPAの分析です。
One of MPA's high-level goals is to provide enough information, when combined with the Direct Data Placement Protocol [DDP], to enable out-of-order placement of DDP payload into the final Upper Layer Protocol (ULP) Buffer. Note that DDP separates the act of placing data into a ULP Buffer from that of notifying the ULP that the ULP Buffer is available for use. In DDP terminology, the former is defined as "Placement", and the later is defined as "Delivery". MPA supports in-order Delivery of the data to the ULP, including support for Direct Data Placement in the final ULP Buffer location when TCP segments arrive out of order. Effectively, the goal is to use the
MPAのハイレベルの目標の1つは十分な情報を提供することです、最終的なUpper Layerプロトコル(ULP)バッファにDDPペイロードの不適切なプレースメントを可能にするためにDirect Data Placementプロトコル[DDP]に結合されると。 DDPがデータをULP Bufferが使用に利用可能であるようにULPに通知するものからULP Bufferに置く行為を切り離すことに注意してください。 DDP用語では、前者は「プレースメント」と定義されます、そして、後は「配送」と定義されます。 MPAはオーダーにおける、データのDeliveryをULPに支持します、TCPセグメントが故障していた状態で到着するとき、最終的なULP Buffer位置にDirect Data Placementのサポートを含んでいて。 事実上、使用には目標があります。
Culley, et al. Standards Track [Page 52] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[52ページ]。
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.
TCPとしてのあらかじめ掲示されたULP BuffersはTCP(MPAとDDPがある)によるULPプロトコルData Unit(PDU)の再アセンブリが適所で行われるバッファを受け取ります、ULP Bufferで、データコピーなしで。
This appendix walks through the advantages and disadvantages of the TCP sender modifications proposed by MPA:
この付録はTCPの利点と難点でMPAによって提案された送付者変更を歩きます:
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は、Header AlignmentをするTCP送付者がMPA FramingプロトコルData Unit(FPDU)と共に始めるのを好みます。そこでは、TCPセグメントはそうするべきです。 (存在しているペイロードがあれば。)
2) that there be an integral number of FPDUs in a TCP segment (under
conditions where the path MTU is not changing).
そこに、いてください。2) それ、TCPセグメント(状態の下経路MTUが変えていない)の整数のFPDUs。
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.
この付録は、強く、主としてかなり抜本的なTCP受信バッファ減少要件に基づいていて、簡素化されたFPDU Alignmentのスケーリング利点が取り扱いを受けると結論を下します。 また、分析は、TCPワイヤの振舞いへの効果がほとんどないのを示します。
B.1. Assumptions
B.1。 仮定
B.1.1 MPA Is Layered beneath DDP
B.1.1 MPAはDDPの下で層にされます。
MPA is an adaptation layer between DDP and TCP. DDP requires preservation of DDP segment boundaries and a CRC32c digest covering the DDP header and data. MPA adds these features to the TCP stream so that DDP over TCP has the same basic properties as DDP over SCTP.
MPAはDDPとTCPの間の適合層です。 DDPはDDPヘッダーとデータを含んでいるDDPセグメント境界とCRC32cダイジェストの保存を必要とします。 MPAがTCPの流れにこれらの特徴を加えるので、TCPの上のDDPはSCTPの上にDDPと同じ基礎特性を持っています。
B.1.2. MPA Preserves DDP Message Framing
B.1.2。 MPAジャムDDPメッセージ縁どり
MPA was designed as a framing layer specifically for DDP and was not intended as a general-purpose framing layer for any other ULP using TCP.
MPAは、特にDDPのために縁どり層として設計されて、いかなる他のULPのためにも汎用縁どり層としてTCPを使用することで意図しませんでした。
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.
完全なULPDUsが存在しているときだけ、縁どり層で、それを使用するULPsはトランスポート層から指摘を受けることができます。 それは、縁どり層として、MPAがDDP PDUの内容を意識していなくて、受信して、必要なら、Deliveryのために完全なPDUをDDPに組み立て直すだけでした。
B.1.3. The Size of the ULPDU Passed to MPA Is Less Than EMSS under
Normal Conditions
B.1.3。 MPAに渡されたULPDUのサイズはエムスより正常な状況では少ないです。
To make reception of a complete DDP PDU on every received segment possible, DDP passes to MPA a PDU that is no larger than the EMSS of the underlying fabric. Each FPDU that MPA creates contains sufficient information for the receiver to directly place the ULP payload in the correct location in the correct receive buffer.
あらゆる容認されたセグメントにおける完全なDDP PDUのレセプションを可能にするように、DDPは基本的な織物のエムスほど大きくないPDUをMPAに渡します。 MPAが作成する各FPDUは受信機が正しい受信バッファに直接ULPペイロードを正しい位置に置くことができるくらいの情報を含んでいます。
Culley, et al. Standards Track [Page 53] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[53ページ]。
Edge cases when this condition does not occur are dealt with, but do not need to be on the fast path.
この状態が現れないと、縁のケースは、対処されていますが、高速経路にある必要はありません。
B.1.4. Out-of-Order Placement but NO Out-of-Order Delivery
B.1.4。 不適切なプレースメントにもかかわらず、不適切な配送がありません。
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 PDUsを受けます。 各DDP PDUはホストメモリに直接正しい位置にULPペイロードを置くのに必要な情報を含んでいます。
Because each DDP segment is self-describing, it is possible for DDP segments received out of order to have their ULP payload placed immediately in the ULP receive buffer.
それぞれのDDPセグメントが自己説明であるので、DDPにおいて、それらのULPペイロードをすぐULPに置かせるためには故障していた状態で受け取られたセグメントがバッファを受け取るのは、可能です。
Data delivery to the ULP is guaranteed to be in the order the data was sent. DDP only indicates data delivery to the ULP after TCP has acknowledged the complete byte stream.
ULPへのデータ配送はオーダーにあるように、データが送られたのが保証されます。 TCPが完全なバイト・ストリームを承諾した後にDDPはデータ配送をULPに示すだけです。
B.2. The Value of FPDU Alignment
B.2。 FPDU整列の値
Significant receiver optimizations can be achieved when Header Alignment and complete FPDUs are the common case. The optimizations allow utilizing significantly fewer buffers on the receiver and less computation per FPDU. The net effect is the ability to build a "flow-through" receiver that enables TCP-based solutions to scale to 10G and beyond in an economical way. The optimizations are especially relevant to hardware implementations of receivers that process multiple protocol layers -- Data Link Layer (e.g., Ethernet), Network and Transport Layer (e.g., TCP/IP), and even some ULP on top of TCP (e.g., MPA/DDP). As network speed increases, there is an increasing desire to use a hardware-based receiver in order to achieve an efficient high performance solution.
Header Alignmentと完全なFPDUsがよくある例であるときに、重要な受信機最適化を達成できます。 最適化で、受信機の上のかなり少ないバッファと、より少ない1FPDUあたりの計算を利用します。 ネットの効果はTCPベースの解決策が経済的な方法で10Gと以遠に比例するのを可能にする「流れ突き抜けている」受信機を造る能力です。 最適化は複数のプロトコル層を処理する受信機のハードウェア実装に特に関連しています--データLink Layer(例えば、イーサネット)、Network、Transport Layer(例えば、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は終わりから終わりへの帯域幅(以上が終わりから終わりへの帯域幅の10x増加のためにバッファリングする10x)で比例します。 アプローチがハードウェアかソフトウェア実行のために同じく不十分にスケーリングするかもしれないこのバッファリングとして、いくつかのアプローチが高速TCPコミュニケーションに必要であるバッファリングの量の減少を許します。
Culley, et al. Standards Track [Page 54] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[54ページ]。
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のBufferがTCP受信バッファとして使用されるのを可能にすることです。 -アウトであるときに、アプリケーションが十分な量のバッファリングをあらかじめ掲示して、それぞれのTCPセグメントに正しいアプリケーションバッファの中にペイロードを置くことができるくらいの情報があるなら、オーダーTCPでは、セグメントは到着します。潜在的に直接ULP Bufferにそれは置くことができました。 しかしながら、プレースメント情報がある完全なFPDUが受信機に利用可能であるときにだけ、プレースメントができます、そして、FPDU内容は正しいULP Bufferにデータを置くことができるくらいの情報を含んでいます(例えば、手があいている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セグメントに並べられないときのケースのために、かかるかもしれません、平均的に、1FPDUを組み立てる2つのTCPセグメント。 したがって、受信機はBufferSizeNAF(バッファSize、Nonによって並べられたFPDU)に八重奏を割り当てなければなりません:
BufferSizeNAF = K1* EMSS * number_of_connections + K2 * EMSS
BufferSizeNAFは_接続+ケーツー*エムスのK1*エムス*番号_と等しいです。
Where K1 and K2 are implementation-dependent constants and EMSS is the effective maximum segment size.
K1とケーツーがどこの実現依存する定数とエムスであるかは有効な最大のセグメントサイズです。
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.
例えば、1500年のBの1万の接続とエムスとの1GB/秒のリンクは15MBのメモリを必要とするでしょう。 より高い速度のために状況を悪化させて、しばしば、ポートの数はネットワーク速度に従ったスケールを使用しました。
FPDU Alignment would allow the receiver to allocate BufferSizeAF (Buffer Size, Aligned FPDU) octets:
FPDU Alignmentは受信機にBufferSizeAF(バッファSize、Aligned FPDU)に八重奏を割り当てさせるでしょう:
BufferSizeAF = K2 * EMSS
BufferSizeAFはケーツー*エムスと等しいです。
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 Aligned受信機は、KB(チップに関するメモリに可能である)の~100sの範囲でメモリを必要とするかもしれなくて、「流れ突き抜けている」デザインを可能にします。(データは、それでネットワーク・インターフェース・カード(NIC)を通して流れて、直接目的地バッファに置かれます)。 接続の大部分がFPDU Alignmentを支持すると仮定して、受信機バッファはもうポートの数で比例しません。
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.
バランスのとれている入出力サブシステムでネットワーク回線容量と比べてネットワーク制御装置のシステム・インタフェースが十分な帯域幅を供給するところに追加最適化を達成できます。 およそ20年間、これはそうです、そして、傾向が続くと予想されます。 イーサネット速度は1000年(10メガビット/秒から10ギガビット/秒までの)までに比例しましたが、ボリュームCPU構造のI/Oバス帯域幅は2GB/秒2MB/秒の~、から~まで比例しました(PC-XTはPCI-X DDRにバスで行きます)。 これらの条件で、FPDU Alignmentアプローチは、BufferSizeAFがネットワーク速度にありきたりであることを許容します。 それは主として与えられたフレームへのローカル処理時間の関数です。
Culley, et al. Standards Track [Page 55] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[55ページ]。
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 Alignmentアプローチが使用されているときにはバッファリングしながら、受信してください。ネットワーク速度が増加されているのに従って優雅(すなわち、直線的なスケーリングより少ない)に比例すると予想されます。
B.2.1. Impact of Lack of FPDU Alignment on the Receiver Computational
Load and Complexity
B.2.1。 受信機のコンピュータの荷重と複雑さへのFPDU整列の不足の影響
The receiver must perform IP and TCP processing, and then perform FPDU CRC checks, before it can trust the FPDU header placement information. For simplicity of the description, the assumption is that an FPDU is carried in no more than 2 TCP segments. In reality, with no FPDU Alignment, an FPDU can be carried by more than 2 TCP segments (e.g., if the path MTU was reduced).
受信機は、IPとTCP処理を実行して、次に、FPDU CRCチェックを実行しなければなりません、FPDUヘッダープレースメント情報を信じることができる前に。 記述の簡単さのために、仮定はFPDUが2つ未満のTCPセグメントで運ばれるということです。 FPDU Alignmentがなければ、ほんとうは、2つ以上のTCPセグメントでFPDUを運ぶことができます(例えば、経路MTUが減少したなら)。
----++-----------------------------++-----------------------++-----
+---||---------------+ +--------||--------+ +----------||----+
| TCP Seg X-1 | | TCP Seg X | | TCP Seg X+1 |
+---||---------------+ +--------||--------+ +----------||----+
----++-----------------------------++-----------------------++-----
FPDU #N-1 FPDU #N
----++-----------------------------++-----------------------++----- +---||---------------+ +--------||--------+ +----------||----+ | TCP Seg X-1| | TCP Seg X| | TCP Seg X+1| +---||---------------+ +--------||--------+ +----------||----+ ----++-----------------------------++-----------------------++----- FPDU#N-1 FPDU#N
Figure 12: Non-Aligned FPDU Freely Placed in TCP Octet Stream
図12: 自由にTCP八重奏の流れに置かれた非同盟のFPDU
The receiver algorithm for processing TCP segments (e.g., TCP segment #X in Figure 12) carrying non-aligned FPDUs (in order or out of order) includes:
(整然とするか故障する)で非同盟のFPDUsを運ぶ処理TCPセグメント(例えば、図12のTCPセグメント#X)のための受信機アルゴリズムは:
Data Link Layer processing (whole frame) -- typically including a CRC calculation.
データLink Layer処理(全体のフレーム)--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. ネットワークLayer処理(どんなIP断片も仮定しないで、全体のData Link Layerフレームは1個のIPデータグラムを含んでいます。 IP断片はローカルのバッファで組み立て直されるべきです。 これはパフォーマンスの最適化目標ではありません。)
2. Transport Layer processing -- TCP protocol processing, header
and checksum checks.
2. 輸送Layer処理--TCPプロトコル処理、ヘッダー、およびチェックサムはチェックします。
a. Classify incoming TCP segment using the 5 tuple (IP SRC,
IP DST, TCP SRC Port, TCP DST Port, protocol).
a。 5tupleを使用して、入って来るTCPセグメントを分類してください(IP SRC(IP DST、TCP SRC Port、TCP DST Port)は議定書を作ります)。
Culley, et al. Standards Track [Page 56] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[56ページ]。
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 Length分野を使用することによって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データ(TCPセグメント#Xの最初の一部)のためのCRC計算を終了してください。
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セグメントに相殺された八重奏について計算してください。
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で可能ではありません。
Culley, et al. Standards Track [Page 57] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[57ページ]。
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が受け取られているまで、受信機はデータをバッファリングしなければなりません。 1接続あたり1つ以上のTCPセグメントのためのバッファリングが通常、必要です。 MPAベースのMarkersを使用して、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がなくなったセグメントのために計算された後にCRCエンジンを通ってこのTCPセグメントを走らせなければならないので、追加複雑さがあります。
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 Alignmentを仮定するなら、以下のダイヤグラムと以下のアルゴリズムは適用されます。 MPAを使用するとき、受信機が活発に存在を検出すると思われたか、またはあらゆるTCPセグメントのためのFPDU Alignmentの損失が受信されたことに注意してください。
+--------------------------+ +--------------------------+
+--|--------------------------+ +--|--------------------------+
| | TCP Seg X | | | TCP Seg X+1 |
+--|--------------------------+ +--|--------------------------+
+--------------------------+ +--------------------------+
FPDU #N FPDU #N+1
+--------------------------+ +--------------------------+ +--|--------------------------+ +--|--------------------------+ | | TCP Seg X| | | TCP Seg X+1| +--|--------------------------+ +--|--------------------------+ +--------------------------+ +--------------------------+ FPDU#N FPDU#N+1
Figure 13: Aligned FPDU Placed Immediately after TCP Header
図13: TCPヘッダー直後置かれた並べられたFPDU
Culley, et al. Standards Track [Page 58] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[58ページ]。
The receiver algorithm for FPDU Aligned frames (in order or out of order) includes:
FPDU Alignedフレーム(整然としているか故障している)への受信機アルゴリズムは:
1) Data Link Layer processing (whole frame) -- typically
including a CRC calculation.
1) データLink Layer処理(全体のフレーム) -- 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) ネットワークLayer処理(どんなIP断片も仮定しないで、全体のData Link Layerフレームは1個のIPデータグラムを含んでいます。 IP断片はローカルのバッファで組み立て直されるべきです。 これはパフォーマンスの最適化目標ではありません。)
3) Transport Layer processing -- TCP protocol processing, header
and checksum checks.
3) 輸送Layer処理--TCPプロトコル処理、ヘッダー、およびチェックサムはチェックします。
a. Classify incoming TCP segment using the 5 tuple (IP SRC,
IP DST, TCP SRC Port, TCP DST Port, protocol).
a。 5tupleを使用して、入って来るTCPセグメントを分類してください(IP SRC(IP DST、TCP SRC Port、TCP DST Port)は議定書を作ります)。
4) Check for Header Alignment (described in detail in Section
6). Assuming Header Alignment for the rest of the algorithm
below.
4) Header Alignment(セクション6で詳細に説明される)がないかどうかチェックしてください。 以下のアルゴリズムの残りのためにHeader Alignmentを仮定します。
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セグメントが整然とするか、または不適切であるなら、現在のTCPペイロードの始めに、MPAヘッダーがあります。 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) TCPセグメントのすべてのFPDUsが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つにそれを関連づけなければなりません。 FPDU Alignmentがない場合では、FPDU CRCについて計算できる前に受信機はやむを得ず入って来る交通を分類します。 FPDU Alignmentの場合では、操作命令はimplementerに残されます。
Culley, et al. Standards Track [Page 59] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[59ページ]。
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 Aligned受信機アルゴリズムはかなり簡単です。 局所的にFPDUsの一部をバッファリングする必要は全くありません。 また、州の情報にアクセスするのは実質的に簡素化されます--正常なケースは、どこでFPDUが始まって、終わるか、またはCRC計算の前の部分的なCRCの検索が始まることができるかを見つけるために情報を検索するのを必要としません。 これは、内部の潜在を加えるのを避けます、CRCマシンを通して複数のデータパスを持っているか、またはデータをホストバッファに動かすために複数のコマンドの計画をして。
The aligned FPDU approach is useful for in-order and out-of-order reception. The receiver can use the same mechanisms for data storage in both cases, and only needs to account for when all the TCP segments have arrived to enable Delivery. The Header Alignment, along with the high probability that at least one complete FPDU is found with every TCP segment, allows the receiver to perform data placement for out-of-order TCP segments with no need for intermediate buffering. Essentially, the TCP receive buffer has been eliminated and TCP reassembly is done in place within the ULP Buffer.
並べられたFPDUアプローチは注文していて故障しているレセプションの役に立ちます。 受信機は、どちらの場合もデータ保存に同じメカニズムを使用できて、Deliveryを有効にするのにすべてのTCPセグメントが到着した時の間、説明する必要があるだけです。 Header Alignmentは受信機に少なくとも1完全なFPDUがあらゆるTCPセグメントで見つけられる高い確率と共に中間的バッファリングの必要性なしで不適切なTCPセグメントのためのデータプレースメントを実行させます。 本質的には、TCP受信バッファを排除しました、そして、ULP Bufferの中で適所でTCP reassemblyをします。
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 Alignmentが見つけられないといけないので、受信機は非同盟のFPDUレセプションのためのアルゴリズムに従うはずです。(レセプションは、より遅くて、それほど効率的でないかもしれません)。
B.2.2. FPDU Alignment Effects on TCP Wire Protocol
B.2.2。 TCPワイヤプロトコルへのFPDU整列効果
In an optimized MPA/TCP implementation, TCP exposes its EMSS to MPA. MPA uses the EMSS to calculate its MULPDU, which it then exposes to DDP, its ULP. DDP uses the MULPDU to segment its payload so that each FPDU sent by MPA fits completely into one TCP segment. This has no impact on wire protocol, and exposing this information is already supported on many TCP implementations, including all modern flavors of BSD networking, through the TCP_MAXSEG socket option.
最適化されたMPA/TCP実現では、TCPはエムスをMPAに露出します。 MPAは、MULPDUについて計算するのにエムスを使用します。(次に、それはDDP、ULPにMULPDUを露出します)。 DDPがセグメントへのペイロードのMULPDUを使用するので、MPAによって送られた各FPDUは1つのTCPセグメントに完全に収まります。 これで、ワイヤへの影響は全く議定書を作りません、そして、この情報を露出するのは多くのTCP実現のときに既に支持されます、BSDネットワークのすべての現代の風味を含んでいて、TCP_MAXSEGソケットオプションで。
In the common case, the ULP (i.e., DDP over MPA) messages provided to the TCP layer are segmented to MULPDU size. It is assumed that the ULP message size is bounded by MULPDU, such that a single ULP message can be encapsulated in a single TCP segment. Therefore, in the common case, there is no increase in the number of TCP segments emitted. For smaller ULP messages, the sender can also apply packing, i.e., the sender packs as many complete FPDUs as possible into one TCP segment. The requirement to always have a complete FPDU may increase the number of TCP segments emitted. Typically, a ULP message size varies from a few bytes to multiple EMSSs (e.g., 64 Kbytes). In some cases, the ULP may post more than one message at a time for transmission, giving the sender an opportunity for packing. In the case where more than one FPDU is available for transmission and the FPDUs are encapsulated into a TCP segment and there is no room in the TCP segment to include the next complete FPDU, another
よくある例では、TCP層に提供されたULP(すなわち、MPAの上のDDP)メッセージはMULPDUサイズまで区分されます。 ULPメッセージサイズはMULPDUで境界があると思われます、ただ一つのTCPセグメントでただ一つのULPメッセージを要約できるように。 したがって、よくある例にはセグメントが放ったTCPの数の増加が全くありません。 また、より小さいULPメッセージに関しては、送付者はパッキング(1つのTCPセグメントにできるだけ多くのすなわち、送付者群れの完全なFPDUs)を適用できます。 いつも完全なFPDUを持っているという要件はセグメントが放ったTCPの数を増加させるかもしれません。 通常、ULPメッセージサイズは数バイトから複数のEMSSs(例えば、64キロバイト)に異なります。 いくつかの場合、ULPはトランスミッションのために一度に1つ以上のメッセージを掲示するかもしれません、パッキングの機会を送付者に与えて。 場合では、1FPDUがどこでトランスミッションに入手できるか、そして、FPDUsはTCPセグメントに要約されます、そして、次の完全なFPDUを含むように、TCPセグメントには余地が全くありません、別
Culley, et al. Standards Track [Page 60] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[60ページ]。
TCP segment is sent. In this corner case, some of the TCP segments are not full size. In the worst-case scenario, the ULP may choose an FPDU size that is EMSS/2 +1 and has multiple messages available for transmission. For this poor choice of FPDU size, the average TCP segment size is therefore about 1/2 of the EMSS and the number of TCP segments emitted is approaching 2x of what is possible without the requirement to encapsulate an integer number of complete FPDUs in every TCP segment. This is a dynamic situation that only lasts for the duration where the sender ULP has multiple non-optimal messages for transmission and this causes a minor impact on the wire utilization.
TCPセグメントを送ります。 この角の場合では、TCPセグメントのいくつかがフルサイズではありません。 下手をすると、ULPはエムス/2+1であるFPDUサイズを選ぶかもしれなくて、トランスミッションに利用可能な複数のメッセージを持っています。 FPDUサイズのこの不十分な選択のために、したがって、平均したTCPセグメントサイズはおよそ1/2人のエムスです、そして、セグメントが放ったTCPの数は何があらゆるTCPセグメントの完全なFPDUsの整数を要約するという要件なしで可能であるかに関する2xにアプローチしています。 これは送付者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 Alignmentを必要とするのがほとんどのアプリケーションのワイヤ働きに測定できる影響力を持たないと予想されます。 大きいI/OSとのスループットアプリケーションがエムスを最大限に利用すると予想されます。 適切であるときに、多くの小さい傑出しているバッファ(エムスと比べて)があるもう1人のクラスのアプリケーションがパッキングを使用すると予想されます。 また、取引指向のアプリケーションも最適です。
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 retransmissionは送付者の振舞いに影響できる別の領域です。 [RFC793]、セクション2.6、3.7(「窓を管理します」の下の)、および[RFC1122]を見てください、セクション4.2。TCPが正確で、元々伝えられたセグメントの「再-トランスミッション」を支持する、(.2 .15)。 より良い利用可能な帯域幅利用はなくなった八重奏だけを再送することによって、オリジナルのセグメントのその部分がありそうもない出来事では、Remote Peer(例えば、Appendix A.4、Reを区分しているMiddleboxes、およびNonによって最適化されたMPA/TCPに記録されるようにmiddleboxを再区分するSenders)によって受け取られて、承認されたのが可能であるかもしれません。 最適化されたMPA/TCPが完全なFPDUsを再送するなら、いくらかのマージンの帯域幅の損失があるかもしれません。
Another area where a change in the TCP segment number may have impact is that of slow start and congestion avoidance. Slow-start exponential increase is measured in segments per second, as the algorithm focuses on the overhead per segment at the source for congestion that eventually results in dropped segments. Slow-start exponential bandwidth growth for optimized MPA/TCP is similar to any TCP implementation. Congestion avoidance allows for a linear growth in available bandwidth when recovering after a packet drop. Similar to the analysis for slow start, optimized MPA/TCP doesn't change the behavior of the algorithm. Therefore, the average size of the segment versus EMSS is not a major factor in the assessment of the bandwidth growth for a sender. Both slow start and congestion avoidance for an optimized MPA/TCP will behave similarly to any TCP sender and allow an optimized MPA/TCP to enjoy the theoretical performance limits of the algorithms.
TCPセグメント番号における変化が影響力を持っているかもしれない別の領域は遅れた出発と輻輳回避のものです。 遅れた出発急激な増加は1秒あたりのセグメントで測定されます、アルゴリズムが結局低下しているセグメントをもたらす混雑のためにソースで1セグメントあたりのオーバーヘッドに焦点を合わせるとき。 遅れた出発の最適化されたMPA/TCPにおける指数の帯域幅の成長はどんなTCP実現とも同様です。 パケット滴の後に回復するとき、輻輳回避は利用可能な帯域幅で直線的な成長を考慮します。 遅れた出発のための分析と同様であることで、最適化されたMPA/TCPはアルゴリズムの振舞いを変えません。 したがって、セグメント対エムスの平均のサイズは送付者のための帯域幅の成長の査定で重要な要因ではありません。 最適化されたMPA/TCPのための遅れた出発と輻輳回避の両方が、同様にどんなTCP送付者にも振る舞って、最適化されたMPA/TCPがアルゴリズムの理論上の性能限界を楽しむのを許容するでしょう。
Culley, et al. Standards Track [Page 61] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[61ページ]。
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(平均で、エムス/2+1のサイズをエムスへ通信させる)があるという最悪の場合効果は上の増加で中のTCPの数が区分して、承認する2xにバウンドしました。 ほんとうは、効果がマージンであると予想されます。
Appendix C. IETF Implementation Interoperability with RDMA Consortium
Protocols
RDMA共同体プロトコルがある付録C.IETF実現相互運用性
This appendix is for information only and is NOT part of the standard.
この付録は、情報だけのためにあって、規格の一部ではありません。
This appendix covers methods of making MPA implementations interoperate with both IETF and RDMA Consortium versions of the protocols.
この付録はMPA実現をIETFとプロトコルのRDMA Consortiumバージョンの両方で共同利用させる方法をカバーしています。
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 Consortiumは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.
興味を持っているものにおいて、 http://www.rdmaconsortium.org/home でRDMA Consortiumプロトコルドキュメント(草稿culley-iwarp-mpa-v1.0.pdf[RDMA-MPA]、草稿iwarp-ddp-v1.0.pdf王[RDMA-DDP]、および草稿-recio-iwarp-rdmac-v1.0.pdf[RDMA-RDMAC])を入手できます。
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 RFCsに従う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 Request/回答Framesの交換がなければ、RDMAC RNICsがIETF RNICsと共に共同利用するのを可能にするためのどんな標準のメカニズムもありません。 ULPがすぐRDMAモード(すなわち、MPA Request/応答メッセージを交換することのない)でIETF RNICを始動するのにウェルノウンポートを使用しても、IETF RNICがバージョン番号の違いのためにRDMAC RNICと共にワイヤの上のDDPとRDMAPヘッダーに共同利用すると信じる理由が全くありません。
Therefore, the ULP or other supporting entity at the RDMAC RNIC must implement MPA Request/Reply Frames on behalf of the RNIC in order to negotiate the connection parameters. The following section describes the results following the exchange of the MPA Request/Reply Frames before the conversion from streaming to RDMA mode.
したがって、何らかのRDMAC RNICで実体を支持するULPは、RNICを代表して接続パラメタを交渉するためにMPA Request/回答Framesを実行しなければなりません。 ストリーミングからRDMAモードまでの変換の前にMPA Request/回答Framesの交換に続いて、以下のセクションは結果について説明します。
Culley, et al. Standards Track [Page 62] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[62ページ]。
C.1. Negotiated Parameters
C.1。 交渉されたパラメタ
Three types of RNICs are considered:
RNICsの3つのタイプが考えられます:
Upgraded RDMAC RNIC - an RNIC implementing the RDMAC protocols that has a ULP or other supporting entity that exchanges the MPA Request/Reply Frames in streaming mode before the conversion to RDMA mode.
アップグレードしたRDMAC RNIC--それが変換の前にストリーミングのモードでMPA Request/回答FramesをRDMAモードと交換する実体を支持しながら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 RNICsと共に共同利用できるだけです。
Permissive IETF RNIC - an RNIC implementing the IETF protocols that is capable of implementing the RDMAC protocols on a per-connection basis.
寛大なIETF RNIC--1接続あたり1個のベースでRDMACプロトコルを実行だったことできる状態でIETFプロトコルを実行するRNIC。
The Permissive IETF RNIC is recommended for those implementers that want maximum interoperability with other RNIC implementations.
Permissive IETF RNICは他のRNIC実現がある最大限のインターオペラビリティが欲しいそれらのimplementersのために推薦されます。
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 MarkersとCRCと同様にMPA、DDP、およびRDMAPバージョンにこれらの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 || | | | |
+----------------++-----------+-----------+-----------+-----------+
+----------------++-----------+-----------+-----------+-----------+ | RNICはタイプします。|| DDP/RDMAP| MPA| MPA| MPA| | || バージョン| 改正| マーカー| CRC| +----------------++-----------+-----------+-----------+-----------+ +----------------++-----------+-----------+-----------+-----------+ | RDMAC|| 0 | 0 | 1 | 1 | | || | | | | +----------------++-----------+-----------+-----------+-----------+ | IETF|| 1 | 1 | 0か1| 0か1| | 非寛大です。|| | | | | +----------------++-----------+-----------+-----------+-----------+ | IETF|| 1か0| 1か0| 0か1| 0か1| | 寛大|| | | | | +----------------++-----------+-----------+-----------+-----------+
Figure 14: Connection Parameters for the RNIC Types
for MPA Markers and MPA CRC, enabled=1, disabled=0.
図14: MPA MarkersとMPA CRCのためのRNIC Typesのための接続Parameters(可能にされた=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プロトコルを使用します(バージョンは1です)。
Culley, et al. Standards Track [Page 63] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[63ページ]。
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 Request/回答Framesの交換の間、各同輩はMPA Revision、Marker好み(M: =が無効にした0、=が可能にした1)、およびCRC好みを提供します。 MPA Request FrameとMPA Reply Frameに提供されたMPA Revisionは異なるかもしれません。
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 Request/回答Framesにおける情報から、それぞれの側はそれぞれの半分接続にMarkersの州と同様にDDP/RDMAPプロトコルのバージョン分野(V: 0=RDMAC、1=IETF)を設定します。 DDPとRDMAPの間では、バージョンの混合は許されていません。 そのうえ、DDPとRDMAPバージョンは2つの方向と同じであるに違いありません。 RNICはワイヤ(バージョンはゼロである)の上にRDMACプロトコルを発生させるか、またはIETFプロトコルを使用します(バージョンは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.
以下のセクションで、CRCsのための相互運用性問題が全くないので、数字はCRC交渉について議論しません。 次に、RDMAC RNICがIETF MPA仕様通りにいつもCRC使用を要求するので、両方の同輩は、CRCsを発生して、チェックしなければなりません。
C.2. RDMAC RNIC and Non-Permissive IETF RNIC
C.2。 RDMAC RNICと非寛大なIETF RNIC
Figure 15 shows that a Non-permissive IETF RNIC cannot interoperate with an RDMAC RNIC, despite the fact that both peers exchange MPA Request/Reply Frames. For a Non-permissive IETF RNIC, the MPA negotiation has no effect on the DDP/RDMAP version and it is unable to interoperate with the RDMAC RNIC.
図15は、Non寛大なIETF RNICがRDMAC RNICと共に共同利用できないのを示します、両方の同輩がMPA Request/回答Framesを交換するという事実にもかかわらず。 Non寛大な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 Request FrameのMarker分野の状態がMPA Initiatorで発信したのを示します。 コラムは、MPA Reply FrameのMarker分野の状態がMPA Responderで発信したのを示します。 RNICの各タイプはInitiatorとResponderとして見せられます。 接続結果はV=0がRDMAC DDP/RDMAPバージョンであり、V=1がIETF DDP/RDMACバージョンであり、M=0が、MPA Markersは障害があることを意味して、Mが1つの手段と等しい異なったRNICタイプの交差点の右下隅にMPA Markersが有効にされるのが示されます。 交渉されたMarker状態がX/Yとして見せられる、Initiator/応答者の指示を受け取ってください。
Culley, et al. Standards Track [Page 64] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[64ページ]。
+---------------------------++-----------------------+
| 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 |
+---------+----------+------++-------+-------+-------+
+---------------------------++-----------------------+ | MPA|| MPA| | 接続してください。|| 応答者| | モード+-----------------++-------+---------------+ | | RNIC|| RDMAC| IETF| | | タイプ|| | 非寛大です。| | | +------++-------+-------+-------+ | | |マーカー|| M=1| M=0| M=1| +---------+----------+------++-------+-------+-------+ +---------+----------+------++-------+-------+-------+ | | RDMAC| M=1|| V=0| 閉鎖| 閉鎖| | | | || Mは1/1と等しいです。| | | | +----------+------++-------+-------+-------+ | MPA| | M=0|| 閉鎖| V=1| V=1| |創始者| IETF| || | Mは0/0と等しいです。| Mは0/1と等しいです。| | |非パーマ+------++-------+-------+-------+ | | | M=1|| 閉鎖| V=1| V=1| | | | || | Mは1/0と等しいです。| Mは1/1と等しいです。| +---------+----------+------++-------+-------+-------+
Figure 15: MPA Negotiation between an RDMAC RNIC and
a Non-Permissive IETF RNIC
図15: RDMAC RNICと非寛大なIETF RNICとのMPA交渉
C.2.1. RDMAC RNIC Initiator
C.2.1。 RDMAC RNIC創始者
If the RDMAC RNIC is the MPA Initiator, its ULP sends an MPA Request Frame with Rev field set to zero and the M and C bits set to one. Because the Non-permissive IETF RNIC cannot dynamically downgrade the version number it uses for DDP and RDMAP, it would send an MPA Reply Frame with the Rev field equal to one and then gracefully close the connection.
RDMAC RNICがMPA Initiatorであるなら、ULPはビットが1つに設定するゼロに設定されたRev分野があるMPA Request Frame、M、およびCを送ります。 Non寛大なIETF RNICがダイナミックにそれがDDPとRDMAPに使用するバージョン番号を格下げできないので、それは、1つと等しいRev分野があるMPA Reply Frameを送って、次に、優雅に接続を終えるでしょう。
C.2.2. Non-Permissive IETF RNIC Initiator
C.2.2。 非寛大なIETF RNIC創始者
If the Non-permissive IETF RNIC is the MPA Initiator, it sends an MPA Request Frame with Rev field equal to one. The ULP or supporting entity for the RDMAC RNIC responds with an MPA Reply Frame that has the Rev field equal to zero and the M bit set to one. The Non- permissive IETF RNIC will gracefully close the connection after it reads the incompatible Rev field in the MPA Reply Frame.
Non寛大なIETF RNICがMPA Initiatorであるなら、それは1つと等しいRev分野があるMPA Request Frameを送ります。 ULPかRDMAC RNICのための実体を支持するのがRev分野をゼロに合わせるために等しくするMPA Reply Frameと1つに設定されて、噛み付かれたMで応じます。 MPA Reply Frameの両立しないRev分野を読んだ後にNonの寛大なIETF RNICは優雅に接続を終えるでしょう。
C.2.3. RDMAC RNIC and Permissive IETF RNIC
C.2.3。 RDMAC RNICと寛大なIETF RNIC
Figure 16 shows that a Permissive IETF RNIC can interoperate with an RDMAC RNIC regardless of its Marker preference. The figure uses the same format as shown with the Non-permissive IETF RNIC.
図16は、Permissive IETF RNICがMarker好みにかかわらずRDMAC RNICと共に共同利用できるのを示します。 図はNon寛大なIETF RNICがある示されるのと同じ形式を使用します。
Culley, et al. Standards Track [Page 65] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[65ページ]。
+---------------------------++-----------------------+
| 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 |
+---------+----------+------++-------+-------+-------+
+---------------------------++-----------------------+ | MPA|| MPA| | 接続してください。|| 応答者| | モード+-----------------++-------+---------------+ | | RNIC|| RDMAC| IETF| | | タイプ|| | 寛大| | | +------++-------+-------+-------+ | | |マーカー|| M=1| M=0| M=1| +---------+----------+------++-------+-------+-------+ +---------+----------+------++-------+-------+-------+ | | RDMAC| M=1|| V=0| なし| V=0| | | | || Mは1/1と等しいです。| | Mは1/1と等しいです。| | +----------+------++-------+-------+-------+ | MPA| | M=0|| V=0| V=1| V=1| |創始者| IETF| || Mは1/1と等しいです。| Mは0/0と等しいです。| Mは0/1と等しいです。| | |寛大な+------++-------+-------+-------+ | | | 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.
本当に、Permissive IETF RNICがMPA Req/レップFramesのRev分野からRDMAC RNICを認識して、次に、適応する、それ、Marker状態とDDP/RDMAPバージョンを受けて、RDMAC RNICを収容してください。 Permissive IETF RNICがMPA Responderとして決して返さない結果として、MがあるMPA Reply Frameはセットにゼロまで噛み付きました。 本件はaとして適切でなく見せられます。(図16のN/a)。
C.2.4. RDMAC RNIC Initiator
C.2.4。 RDMAC RNIC創始者
When the RDMAC RNIC is the MPA Initiator, its ULP or other supporting entity prepares an MPA Request message and sets the revision to zero and the M bit and C bit to one.
RDMAC RNICがMPA Initiator、ULPであるか他のサポート実体は、いつMPA Requestメッセージを準備して、ゼロに改正を設定しますか、そして、1まで噛み付かれたMビットとC。
The Permissive IETF Responder receives the MPA Request message and checks the revision field. Since it is capable of generating RDMAC DDP/RDMAP headers, it sends an MPA Reply message with revision set to zero and the M and C bits set to one. The Responder must inform its ULP that it is generating version zero DDP/RDMAP messages.
Permissive IETF ResponderはMPA Requestメッセージを受け取って、改正分野をチェックします。 RDMAC DDP/RDMAPヘッダーを発生させることができるので、それはゼロに設定された改正と共にMPA Replyメッセージを送ります、そして、MとCビットは1つにセットしました。 Responderは、バージョンゼロ DDP/RDMAPメッセージを発生させていることをULPに知らせなければなりません。
Culley, et al. Standards Track [Page 66] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[66ページ]。
C.2.5 Permissive IETF RNIC Initiator
C.2.5の寛大なIETF RNIC創始者
If the Permissive IETF RNIC is the MPA Initiator, it prepares the MPA Request Frame setting the Rev field to one. Regardless of the value of the M bit in the MPA Request Frame, the ULP or other supporting entity for the RDMAC RNIC will create an MPA Reply Frame with Rev equal to zero and the M bit set to one.
Permissive IETF RNICがMPA Initiatorであるなら、それはRev分野を1つに設定するMPA Request Frameを準備します。 MPA Request Frameで噛み付かれたMの値にかかわらず、RDMAC RNICがゼロに合わせるために等しいRevとMでMPA Reply Frameを作成するので、何らかの実体を支持するULPはセットに1まで噛み付きました。
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.
Initiatorが、MPA Reply FrameのRev分野を読んで、同輩がRDMAC RNICであることがわかるとき、それはバージョンゼロ DDP/RDMAPメッセージを発生させて、MPA MarkersとCRCを有効にするべきであることをULPに知らせなければなりません。
C.3. Non-Permissive IETF RNIC and Permissive IETF RNIC
C.3。 非寛大なIETF RNICと寛大なIETF RNIC
For completeness, Figure 17 below shows the results of MPA negotiation between a Non-permissive IETF RNIC and a Permissive IETF RNIC. The important point from this figure is that an IETF RNIC cannot detect whether its peer is a Permissive or Non-permissive RNIC.
完全性のために、以下の図17はNon寛大なIETF RNICとPermissive IETF RNICとのMPA交渉の結果を示しています。 この図からの重要なポイントはIETF RNICが、同輩がPermissiveかそれともNon寛大な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 |
+---------+----------+------++-------+-------+-------+-------+
+---------------------------++-------------------------------+ | MPA|| MPA| | 接続してください。|| 応答者| | モード+-----------------++---------------+---------------+ | | RNIC|| IETF| IETF| | | タイプ|| 非寛大です。| 寛大| | | +------++-------+-------+-------+-------+ | | |マーカー|| 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と等しいです。| | |非パーマ+------++-------+-------+-------+-------+ | | | M=1|| V=1| V=1| V=1| V=1| | | | || Mは1/0と等しいです。| Mは1/1と等しいです。| Mは1/0と等しいです。| Mは1/1と等しいです。| | MPA+----------+------++-------+-------+-------+-------+ |創始者| | M=0|| V=1| V=1| V=1| V=1| | | IETF| || Mは0/0と等しいです。| Mは0/1と等しいです。| Mは0/0と等しいです。| Mは0/1と等しいです。| | |寛大な+------++-------+-------+-------+-------+ | | | 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: Non寛大なIETF RNICとPermissive IETF RNICとのMPA交渉。
Culley, et al. Standards Track [Page 67] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[67ページ]。
Normative References
引用規格
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
and E. Zeidner, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004.
[iSCSI] Satran、J.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、2004年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October
1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「ブロック格納プロトコルをIPの上に保証します」、RFC3723(2004年4月)。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RDMASEC] Pinkerton, J. and E. Deleganes, "Direct Data Placement
Protocol (DDP) / Remote Direct Memory Access Protocol
(RDMAP) Security", RFC 5042, October 2007.
[RDMASEC] ピンカートン、J.、およびE.Deleganesは「データプレースメントプロトコル(DDP)/リモートなダイレクトメモリアクセスプロトコル(RDMAP)セキュリティを指示します」、RFC5042、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)の適用性」RFC5045(2007年10月)。
[CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum
disagree", ACM Sigcomm, Sept. 2000.
[CRCTCP] C. ストーンJ.、Partridge、ACM Sigcomm、「CRCとTCPチェックサムは意見を異にする」ときの2000年9月。
[DAT-API] DAT Collaborative, "kDAPL (Kernel Direct Access
Programming Library) and uDAPL (User Direct Access
Programming Library)", Http://www.datcollaborative.org.
[DAT API] DAT協力的である、「kDAPL(カーネル直接アクセスプログラミング図書館)とuDAPL(ユーザ直接アクセスプログラミング図書館)」、Http://www.datcollaborative.org。
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley,
"Direct Data Placement over Reliable Transports", RFC
5041, October 2007.
[DDP] 2007年10月のシャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
Culley, et al. Standards Track [Page 68] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[68ページ]。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah,
H., and P. Thaler, "Internet Small Computer System
Interface (iSCSI) Extensions for Remote Direct Memory
Access (RDMA)" RFC 5046, October 2007.
[iSER]コー、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」RFC5046(2007年10月)。
[IT-API] The Open Group, "Interconnect Transport API (IT-API)"
Version 2.1, http://www.opengroup.org.
[IT API]TheOpenGroup、「内部連絡輸送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 Consortium、2002年10月、草稿iwarp- ddp-v1.0.pdf<http://>www.rdmaconsortium.org/家/王。
[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のために、仕様(バージョン1.0)を縁どりながら並べられたマーカーPDU」、RDMA Consortium、2002年10月、<草稿http://www.rdmaconsortium.org/家/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 Consortium、2002年10月、<草稿http://www.rdmaconsortium.org/家/recio-iwarp- rdmac-v1.0.pdf>。
[RDMAP] Recio, R., Culley, P., Garcia, D., Hilland, J., and B.
Metzler, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, October 2007.
[RDMAP]RecioとR.とCulleyとP.とガルシアとD.とHilland、J.とB.メツラー、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(2007年10月)。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC896] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「流れの制御伝動プロトコル」、RFC4960、9月2007日
[RFC4296] Bailey, S. and T. Talpey, "The Architecture of Direct
Data Placement (DDP) and Remote Direct Memory Access
(RDMA) on Internet Protocols", RFC 4296, December 2005.
[RFC4296] べイリーとS.とT.Talpey、「インターネットプロトコルのダイレクトデータプレースメント(DDP)とリモートダイレクトメモリアクセス(RDMA)の構造」、RFC4296、2005年12月。
Culley, et al. Standards Track [Page 69] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[69ページ]。
[RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey,
"Remote Direct Memory Access (RDMA) over IP Problem
Statement", RFC 4297, December 2005.
[RFC4297] Romanow、A.、ムガール人、J.、Talpey、T.、およびS.べイリー、「IP問題声明の上のリモートダイレクトメモリアクセス(RDMA)」、RFC4297(2005年12月)。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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 Consortium規格、2003年4月、<草稿-hilland-iwarp動詞http://www.rdmaconsortium.org/家/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のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 281-514-2769 メールしてください: dwight.barron@hp.com
Jeff Chase Department of Computer Science Duke University Durham, NC 27708-0129 USA Phone: +1 919 660 6559 EMail: chase@cs.duke.edu
デューク大学NC27708-0129ダラム(米国)が電話をするジェフチェイスコンピュータサイエンス学部: +1 6559年の919 660メール: chase@cs.duke.edu
Ted Compton EMC Corporation Research Triangle Park, NC 27709 USA Phone: 919-248-6075 EMail: compton_ted@emc.com
テッドコンプトンEMC社のリサーチトライアングル公園、NC27709米国電話: 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
デーヴガルシア24100Hutchinson通り ロスガトス、カリフォルニア 95033は以下に電話をします。 4464年の831 247メール: Dave.Garcia@StanfordAlumni.org
Hari Ghadia Gen10 Technology, Inc. 1501 W Shady Grove Road Grand Prairie, TX 75050 Phone: (972) 301 3630 EMail: hghadia@gen10technology.com
ハーリGhadia Gen10技術Inc.1501のW陰になっている木立道路壮大な大草原、テキサス75050電話: (972) 301 3630はメールされます: hghadia@gen10technology.com
Culley, et al. Standards Track [Page 70] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[70ページ]。
Howard C. Herbert Intel Corporation MS CH7-404 5000 West Chandler Blvd. Chandler, AZ 85226 Phone: 480-554-3116 EMail: howard.c.herbert@intel.com
ハワードC.ハーバートインテル社MS CH7-404 5000の西ろうそく屋Blvd. ろうそく屋、アリゾナ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
ジェフHillandヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 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
マイクコーIBM650ハリー通り サンノゼ、カリフォルニア 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
マイククラウジーヒューレット・パッカード社、43LN19410はRoadカルパチーノ(カリフォルニア)95014米国電話に入植します: +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
ヒルズバロ、オレゴン 97124が電話をするデーヴMinturnインテル社MS JF1-210 5200東北イーラムヤング公園道路: 503-712-4106 メールしてください: dave.b.minturn@intel.com
Jim Pinkerton Microsoft, Inc. One Microsoft Way Redmond, WA 98052 USA EMail: jpink@microsoft.com
ワシントン98052レッドモンド(米国)がメールされるジムピンカートンマイクロソフトInc.1マイクロソフト方法: jpink@microsoft.com
Culley, et al. Standards Track [Page 71] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[71ページ]。
Hemal Shah Broadcom Corporation 5300 California Avenue Irvine, CA 92617 USA Phone: +1 (949) 926-6941 EMail: hemal@broadcom.com
血液のシャーBroadcom社5300のカリフォルニアAvenueカリフォルニア92617アーバイン(米国)は以下に電話をします。 +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
カリフォルニア95134サンノゼ(米国)が電話をするアリンRomanowシスコシステムズの170Wタスマンのドライブ: +1 8836年の408 525メール: allyn@cisco.com
Tom Talpey Network Appliance 1601 Trapelo Road #16 Waltham, MA 02451 USA Phone: +1 (781) 768-5329 EMail: thomas.talpey@netapp.com
トムTalpeyはTrapelo道路#16MA02451ウォルサム(米国)が電話をする器具1601をネットワークでつなぎます: +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
Parkwayアーバイン、パトリシアターレルBroadcom16215オールトンカリフォルニア 92618は以下に電話をします。 2707年の916 570メール: 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
5668年のジムウェントヒューレットパッカード社8000のフットヒルズ並木街MSローズビル、カリフォルニア95747-5668米国電話: +1 5198年の916 785メール: jim_wendt@hp.com
Jim Williams Emulex Corporation 580 Main Street Bolton, MA 01740 USA Phone: +1 978 779 7224 EMail: jim.williams@emulex.com
ジムウィリアムズEmulex社580のMain Street MA01740ボルトン(米国)は以下に電話をします。 +1 7224年の978 779メール: jim.williams@emulex.com
Culley, et al. Standards Track [Page 72] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[72ページ]。
Authors' Addresses
作者のアドレス
Paul R. Culley Hewlett-Packard Company 20555 SH 249 Houston, TX 77070-2698 USA Phone: 281-514-5543 EMail: paul.culley@hp.com
ポールR.Culleyヒューレット・パッカード社20555のSH249テキサス77070-2698ヒューストン(米国)は以下に電話をします。 281-514-5543 メールしてください: paul.culley@hp.com
Uri Elzur 5300 California Avenue Irvine, CA 92617, USA Phone: 949.926.6432 EMail: uri@broadcom.com
Avenueアーバイン、カリフォルニア 92617、ユリElzur5300カリフォルニア米国は以下に電話をします。 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
オースチン、テキサス 78759が電話をするレナートJ RecioのIBMの内部の郵便番号9043 11400バーネット道路: 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
スティーブンべイリーSandburst社600の連邦政府の通りMA01810アンドーバー(米国)は以下に電話をします。 +1 1614年の978 689メール: 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
ジョンキャリヤーザリガニ株式会社411のFirst Avenue S、Suite600シアトル、ワシントン98104-2860Phone: 206-701-2090 メールしてください: carrier@cray.com
Culley, et al. Standards Track [Page 73] RFC 5044 MPA Framing for TCP October 2007
Culley、他 規格は2007年10月にTCPのためにRFC5044MPA縁どりを追跡します[73ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Culley, et al. Standards Track [Page 74]
Culley、他 標準化過程[74ページ]
一覧
スポンサーリンク
