[要約] RFC 4755は、InfiniBand上でのIP通信をサポートするためのプロトコルであり、接続モードを提供します。このRFCの目的は、InfiniBandネットワーク上でのIP通信の効率と信頼性を向上させることです。
Network Working Group V. Kashyap
Request for Comments: 4755 IBM
Category: Standards Track December 2006
IP over InfiniBand: Connected Mode
IP over InfiniBand：接続モード
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（C）IETF Trust（2006）。
Abstract
概要
This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand.
このドキュメントでは、InfiniBandの接続モードでのIPv4 / IPv6パケットの送信とアドレス解決について説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. IPoIB-connected Mode ............................................3
2.1. Multicasting ...............................................3
2.2. Outline of Address Resolution ..............................4
2.3. Outline of Connection Setup ................................4
3. Address Resolution ..............................................4
3.1. Link-layer Address .........................................4
3.2. IB Connection Setup ........................................6
3.3. Simultaneous IB Connections ................................6
3.4. IPoIB-CM IB Connection Teardown ............................7
3.5. Service-ID .................................................7
4. Frame Format ....................................................8
5. Maximum Transmission Unit .......................................8
5.1. Per-Connection MTU .........................................9
6. Private-Data Format .............................................9
7. IPoIB-CM Considerations ........................................10
7.1. A Cautionary Note on IPoIB-RC .............................10
7.2. IPoIB-CM Per-Destination MTU ..............................10
8. Security Considerations ........................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. Normative References ..........................................11
12. Informative References ........................................11
The InfiniBand specification [IB_ARCH] can be found at www.infinibandta.org. The document [RFC4392] provides a short overview of InfiniBand architecture along with consideration for specifying IP over InfiniBand networks.
InfiniBand仕様[IB_ARCH]は、www.infinibandta.orgにあります。ドキュメント[RFC4392]は、InfiniBandアーキテクチャの簡単な概要と、IP over InfiniBandネットワークの指定に関する考慮事項を提供します。
The InfiniBand Architecture (IBA) defines multiple modes of transports. Of these the unreliable datagram (UD) transport method best matches the needs of IP. IP over InfiniBand (IPoIB) over UD is described in [RFC4391]. This document describes IP transmission over the connected modes of IBA.
InfiniBandアーキテクチャ（IBA）は、複数のトランスポートモードを定義します。これらのうち、信頼性の低いデータグラム（UD）トランスポート方式は、IPのニーズに最適です。 IP over InfiniBand（IPoIB）over UDは、[RFC4391]で説明されています。このドキュメントでは、IBAの接続モードでのIP送信について説明します。
IBA defines two connected modes:
IBAは2つの接続モードを定義します。
1. Reliable Connected (RC) 2. Unreliable Connected (UC)
1. 信頼できる接続（RC）2.信頼できない接続（UC）
As is evident from the nomenclature, the two modes differ mainly in providing reliability of data delivery across the connection. This document applies equally to both the connected modes. IPoIB over these two modes is referred to as IPoIB-CM (connected mode) in this document. For clarity, IPoIB over the unreliable datagram mode as described in [RFC4391] is referred to as IPoIB-UD.
命名法から明らかなように、2つのモードは主に、接続を介したデータ配信の信頼性を提供する点で異なります。このドキュメントは、両方の接続モードに等しく適用されます。この2つのモードでのIPoIBは、このドキュメントではIPoIB-CM（接続モード）と呼ばれます。明確にするために、[RFC4391]で説明されているような信頼性の低いデータグラムモードでのIPoIBは、IPoIB-UDと呼ばれます。
IBA requires that all Host Channel Adapters (HCAs) support the reliable and unreliable connected modes [IB_ARCH]. It is optional for Target Channel Adapters (TCAs) to support the connected modes.
IBAでは、すべてのホストチャネルアダプター（HCA）が信頼性の高い接続モードと信頼性の低い接続モードをサポートする必要があります[IB_ARCH]。ターゲット・チャネル・アダプター（TCA）が接続モードをサポートすることはオプションです。
The connected modes offer link MTUs of up to 2^31 octets in length. Thus, the use of connected modes can offer significant benefits by supporting reasonably large MTUs. The datagram modes of InfiniBand Architecture (IBA) are limited to 4096 octets.
接続モードは、長さが最大2 ^ 31オクテットのリンクMTUを提供します。したがって、接続モードの使用は、かなり大きなMTUをサポートすることにより、大きな利点を提供できます。 InfiniBandアーキテクチャ（IBA）のデータグラムモードは、4096オクテットに制限されています。
Reliability is also enhanced if the underlying feature of "automatic path migration" supported by the connected modes is utilized.
接続モードでサポートされる「自動パス移行」の基本機能を利用すると、信頼性も向上します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
IPoIB over connected mode is an OPTIONAL extension to IPoIB-UD. Every IPoIB implementation MUST support [RFC4391] and MAY support the extensions described in this document.
接続モードでのIPoIBは、IPoIB-UDのオプションの拡張機能です。すべてのIPoIB実装は[RFC4391]をサポートする必要があり、このドキュメントで説明されている拡張機能をサポートする場合があります（MAY）。
Therefore, IP encapsulation, default MTU, link-layer address format, and the IPv6 stateless autoconfiguration mechanism apply to IPoIB-CM exactly as described in [RFC4391].
したがって、[RFC4391]で説明されているとおり、IPカプセル化、デフォルトMTU、リンク層アドレス形式、およびIPv6ステートレス自動構成メカニズムがIPoIB-CMに正確に適用されます。
The connected modes of IBA define a non-broadcast, multiple-access network. The connected modes of IBA do not support multicasting though every node can communicate with every other node if desired.
IBAの接続モードは、非ブロードキャストのマルチアクセスネットワークを定義します。 IBAの接続モードはマルチキャストをサポートしていませんが、必要に応じてすべてのノードが他のすべてのノードと通信できます。
This requires that multicasting be emulated in some form by the network. However, in the case of an InfiniBand network, instead of an emulation, an unreliable datagram (UD) queue pair (QP) can be used to support multicasting while the connected mode QP is used for unicast traffic. Since every IPoIB implementation is required to support the UD mode, every implementation supporting IPoIB-CM will be able to utilize the pre-existing IPoIB-UD QP for all broadcast/multicast communications. Multicast mapping, transmission, and reception of multicast packets and multicast routing MUST use the UD QP associated with the IPoIB interface.
これには、マルチキャストが何らかの形でネットワークによってエミュレートされる必要があります。ただし、InfiniBandネットワークの場合は、エミュレーションの代わりに、信頼性のないデータグラム（UD）キューペア（QP）を使用してマルチキャストをサポートし、ユニキャストトラフィックに接続モードQPを使用できます。すべてのIPoIB実装はUDモードをサポートする必要があるため、IPoIB-CMをサポートするすべての実装は、すべてのブロードキャスト/マルチキャスト通信に既存のIPoIB-UD QPを利用できます。マルチキャストパケットのマルチキャストマッピング、送信、および受信とマルチキャストルーティングでは、IPoIBインターフェイスに関連付けられたUD QPを使用する必要があります。
Every IPoIB-CM interface MUST have two sets of QPs associated with it:
すべてのIPoIB-CMインターフェースには、2組のQPが関連付けられている必要があります。
1) One unreliable datagram QP 2) One or more connected mode QPs
1）1つの信頼できないデータグラムQP 2）1つ以上の接続モードQP
[RFC4391] describes the address resolution method to determine the link address of the peer. This response is received on the UD QP associated with the IPoIB interface.
[RFC4391]は、ピアのリンクアドレスを決定するためのアドレス解決方法について説明しています。この応答は、IPoIBインターフェイスに関連付けられたUD QPで受信されます。
Once the link address of the remote node is known, an IB connection must be set up between the nodes before any IP communication may occur.
リモートノードのリンクアドレスがわかったら、IP通信が発生する前にノード間にIB接続をセットアップする必要があります。
To make a connection, the sender must know the service-ID to use in the request to make a connection [IB_ARCH]. It must also supply the "connection mode" queue pair to the remote node. The peer replies with its queue pair. Each IB connection is peer to peer and uses one connected mode QP at each end.
接続を行うには、送信者は接続を確立するためのリクエストで使用するサービスIDを知っている必要があります[IB_ARCH]。また、リモートノードに「接続モード」キューペアを提供する必要があります。ピアはキューペアで応答します。各IB接続はピアツーピアであり、両端で1つの接続モードQPを使用します。
Though the address resolution occurs at an individual IP address level, the connection between the nodes is at the IB layer. Therefore, every individual address resolution does not imply a new connection between the peers.
アドレス解決は個々のIPアドレスレベルで行われますが、ノード間の接続はIB層で行われます。したがって、個々のアドレス解決はすべて、ピア間の新しい接続を意味するものではありません。
Address resolution queries are sent out on the "broadcast-GID" (Broadcast-Group Identifier) over the UD QP associated with the IPoIB interface [RFC4391]. A unicast reply is received on the UD QP.
アドレス解決クエリは、IPoIBインターフェイス[RFC4391]に関連付けられたUD QPを介して、「broadcast-GID（ブロードキャストグループID）」で送信されます。 UD QPでユニキャスト応答が受信されます。
IPoIB encapsulation [RFC4391] describes the link-layer address as follows:
IPoIBカプセル化[RFC4391]は、リンク層アドレスを次のように記述しています。
<1 octet reserved>:QP: GID
This document extends the link-layer address as follows:
このドキュメントでは、リンク層アドレスを次のように拡張しています。
<Flags>:QPN:GID
Flags:
フラグ：
This is a single-octet field. The bits indicate the connected modes supported by the interface.
これは単一オクテットのフィールドです。ビットは、インターフェースがサポートする接続モードを示します。
Bit 0 specifies the support for the "reliable connected" (RC) mode. Bit 1 indicates the support for the "unreliable connected" (UC) mode. All other bits in the octet are reserved and MUST be set to 0 on transmits and ignored on receives. The format of the flags is as follows:
ビット0は、「高信頼接続」（RC）モードのサポートを指定します。ビット1は、「信頼できない接続」（UC）モードのサポートを示します。オクテットの他のすべてのビットは予約されており、送信時に0に設定し、受信時に無視する必要があります。フラグの形式は次のとおりです。
+--+--+--+--+--+--+--+--+
|RC|UC| 0| 0| 0| 0| 0| 0|
+--+--+--+--+--+--+--+--+
Both the RC and UC MAY be set at the same time if the interface supports both the modes. Since the IPoIB-UD mode is always supported, there are no flags to indicate IPoIB-UD support.
インターフェースが両方のモードをサポートしている場合、RCとUCの両方を同時に設定できます。 IPoIB-UDモードは常にサポートされているため、IPoIB-UDサポートを示すフラグはありません。
If IPoIB-CM is not supported, i.e., if the implementation only supports IPoIB-UD, then the implementation MUST ignore the <Flags> on reception. It MUST set the <Flags> octet to all zeros on transmission as specified in [RFC4391].
IPoIB-CMがサポートされていない場合、つまり実装がIPoIB-UDのみをサポートしている場合、実装は受信時に<Flags>を無視する必要があります。 [RFC4391]で指定されているように、送信時に<Flags>オクテットをすべてゼロに設定する必要があります。
QPN:
QPN：
The queue-pair number (QPN) on which the unicast address resolution replies will be received [RFC4391]. An IPoIB interface has only one UD QP associated with it whether or not it supports this extension.
ユニキャストアドレス解決応答が受信されるキューペア番号（QPN）[RFC4391]。 IPoIBインターフェイスには、この拡張機能をサポートするかどうかに関係なく、UD QPが1つだけ関連付けられています。
The QPN also serves another purpose. It is used to form the Service-ID that is used to set up the IB connection.
QPNには別の目的もあります。 IB接続のセットアップに使用されるService-IDを形成するために使用されます。
On receiving the multicast/broadcast address resolution request, the receiver replies with its own link address, including the associated UD QPN and the appropriate flags.
マルチキャスト/ブロードキャストアドレス解決要求を受信すると、レシーバーは、関連付けられたUD QPNと適切なフラグを含む独自のリンクアドレスで応答します。
The receiver's reply is unicast back to the sender after the receiver has, as in the case of IPoIB-UD, resolved the GID to the Local Identifier (LID), and determined other required parameters [RFC4391]. Once the address resolution is completed, the underlying IB connection on the supported connection modes can be set up. An implementation is NOT REQUIRED to set up a connection merely because the peer indicates the capability. The decision to make such a connection is left to the implementation.
受信者の応答は、IPoIB-UDの場合のように、受信者がGIDをローカル識別子（LID）に解決し、他の必要なパラメーターを決定した後、送信者にユニキャストで返されます[RFC4391]。アドレス解決が完了すると、サポートされている接続モードの基になるIB接続をセットアップできます。ピアが機能を示すだけの理由で、接続をセットアップするための実装は必要ありません。このような接続を行うかどうかの決定は実装に任されています。
Once the address resolution is complete, the IB connection can be set up by either of the peers. To set up a connection, IB Management Datagrams (MADs) are directed to the peer's communication manager (CM). The connection request always contains a Service-ID for the peer to associate the request with the appropriate service. If the request is accepted, the peer returns the relevant connected mode QPN in the response MAD. The format of the CM connection messages and the IB connection setup process is described in [IB_ARCH]. The overall handshake is of the form:
アドレス解決が完了すると、どちらのピアからもIB接続をセットアップできます。接続をセットアップするために、IB管理データグラム（MAD）がピアの通信マネージャー（CM）に送信されます。接続要求には、ピアが要求を適切なサービスに関連付けるためのService-IDが常に含まれています。要求が受け入れられると、ピアは関連する接続モードQPNを応答MADで返します。 CM接続メッセージのフォーマットとIB接続セットアッププロセスは、[IB_ARCH]で説明されています。全体的なハンドシェイクの形式は次のとおりです。
REQ ---->
<---- REP [or REJ(reject)]
RTA ---->
[or REJ(reject)]
The CM messages include, among other parameters, the Service-ID, Local connection-mode QPN, and the payload size to use over the connection.
CMメッセージには、他のパラメーターの中でも、サービスID、ローカル接続モードQPN、および接続で使用するペイロードサイズが含まれます。
Note: The IB connection is set up using the Service-ID as defined in Section 3.5 below. The node MUST keep a record of IB connections it is participating in. The node MAY attempt another connection to the remote peer using the same Service-ID as used for an existing IB connection. Similarly, the receiver of such a connection MAY drop the request with a suitable error indication in the CM response. The decision to accept or initiate multiple connections from or to an IPoIB interface is left to the implementation.
注：IB接続は、以下のセクション3.5で定義されているサービスIDを使用して設定されます。ノードは、参加しているIB接続の記録を保持する必要があります。ノードは、既存のIB接続に使用されているものと同じService-IDを使用して、リモートピアへの別の接続を試行できます（MAY）。同様に、そのような接続の受信者は、CM応答に適切なエラー表示がある要求をドロップしてもよい（MAY）。 IPoIBインターフェイスとの間の複数の接続を受け入れるか開始するかの決定は、実装に委ねられます。
The node that initiated the connection is aware of the target node's IP address as described above. The node receiving the IB connection request, however, cannot determine the initiating node's link address. To enable this determination, every CM message exchanged in setting up the IB connection MUST include the sender's IPoIB-UD QPN in the "private data" [IB_ARCH] field. The IPoIB-UD QPN MUST be included in all "REJ" [IB_ARCH] messages too.
接続を開始したノードは、上記のようにターゲットノードのIPアドレスを認識しています。ただし、IB接続要求を受信するノードは、開始ノードのリンクアドレスを判別できません。この決定を可能にするために、IB接続のセットアップで交換されるすべてのCMメッセージは、「プライベートデータ」[IB_ARCH]フィールドに送信者のIPoIB-UD QPNを含める必要があります。 IPoIB-UD QPNは、すべての「REJ」[IB_ARCH]メッセージにも含める必要があります。
To ensure that two IB connections are not set up between the peers due to REQ crossing, the following rules MUST be followed:
REQの交差によりピア間に2つのIB接続がセットアップされないようにするには、次のルールに従う必要があります。
The receiver forms the remote node's link-layer address using the UD QPN received in the "private data" field of the "REQ" message and the GID of the sender included in the "REQ" message. The link-layer address is used to determine if there is already an outstanding connection request "REQ" sent by the local interface to the given received link-layer address. If such an outstanding request is determined, then the two link-layer addresses (local and remote) are numerically compared. If the local link-layer address is numerically smaller, then the connection is accepted, otherwise rejected. The error code in "REJ" MAD is set to "Consumer Reject" [IB_ARCH].
受信者は、「REQ」メッセージの「プライベートデータ」フィールドで受信したUD QPNと「REQ」メッセージに含まれる送信者のGIDを使用して、リモートノードのリンク層アドレスを形成します。リンク層アドレスは、ローカルインターフェイスによって、指定された受信リンク層アドレスに送信された未処理の接続要求 "REQ"がすでにあるかどうかを判断するために使用されます。そのような未解決の要求が決定されると、2つのリンク層アドレス（ローカルとリモート）が数値的に比較されます。ローカルリンク層アドレスが数値的に小さい場合、接続は受け入れられ、そうでない場合は拒否されます。 「REJ」MADのエラーコードは「コンシューマ拒否」[IB_ARCH]に設定されています。
Note: The link-layer addresses formed for comparison zero out the connection mode flags specified in Section 3.1. The comparison is performed from the most significant octet to the least significant octet of the link-layer address.
注：比較のために形成されたリンク層アドレスは、セクション3.1で指定された接続モードフラグをゼロにします。比較は、リンク層アドレスの最上位オクテットから最下位オクテットまで実行されます。
The above holds even if the receiver supports multiple IB connections from the same peer. This is to ensure that only one more connection is set up when the "REQ" messages cross.
上記は、レシーバーが同じピアからの複数のIB接続をサポートする場合でも当てはまります。これは、「REQ」メッセージが通過したときに1つだけ接続がセットアップされることを保証するためです。
IB connections created through IPoIB-CM are considered part of an IPoIB interface. As such, they SHOULD be torn down when the IPoIB interfaces they are associated with are torn down.
IPoIB-CMを介して作成されたIB接続は、IPoIBインターフェイスの一部と見なされます。そのため、関連付けられているIPoIBインターフェイスが破棄されると、それらは破棄されるべきです（SHOULD）。
Furthermore, the IB connection between two peers MAY be torn down by either peer whenever the address resolution entry expires. An implementation is free to implement alternative policies for tearing down of IB connections between peers.
さらに、2つのピア間のIB接続は、アドレス解決エントリが期限切れになるたびに、いずれかのピアによって切断される場合があります。実装は、ピア間のIB接続を破棄するための代替ポリシーを自由に実装できます。
The InfiniBand specification defines a block of Service-IDs for IETF use. The InfiniBand specification has left the definition and management of this block to the IETF [IB_ARCH]. The 64-bit block is as follows:
InfiniBand仕様では、IETFが使用するService-IDのブロックを定義しています。 InfiniBand仕様では、このブロックの定義と管理をIETF [IB_ARCH]に任せています。 64ビットブロックは次のとおりです。
+--------+--------+--------+--------+-------+--------+--------+------+
|00000001|<-------------------IETF use------------------------------>|
+--------+--------+--------+--------+-------+--------+--------+------+
The Service-IDs used by IPoIB will be in the following format:
IPoIBで使用されるサービスIDは次の形式になります。
+--------+--------+--------+--------+-------+-------+--------+-------+
|00000001| Type | Reserved | QPN |
+--------+--------+--------+--------+-------+-------+--------+-------+
The "Type" field MUST be set to 0.
「タイプ」フィールドは0に設定する必要があります。
The "Reserved" field MUST be set to zeros.
「予約済み」フィールドはゼロに設定する必要があります。
The QPN MUST be the UD QP exchanged during address resolution.
QPNは、アドレス解決中に交換されるUD QPである必要があります。
All IP datagrams transported over InfiniBand are prefixed by a 4-octet encapsulation header as described in [RFC4391].
[RFC4391]で説明されているように、InfiniBandを介して転送されるすべてのIPデータグラムには、4オクテットのカプセル化ヘッダーがプレフィックスとして付加されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Type | Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field SHALL indicate the encapsulated protocol as per the following table.
タイプフィールドは、次の表のようにカプセル化されたプロトコルを示す必要があります（SHALL）。
+----------+-------------+
| Type | Protocol |
|------------------------|
| 0x800 | IPv4 |
|------------------------|
| 0x86DD | IPv6 |
+------------------------+
These values are taken from the "ETHER TYPE" numbers assigned by Internet Assigned Numbers Authority (IANA). Other network protocols, identified by different values of "ETHER TYPE", may use the encapsulation format defined herein, but such use is outside of the scope of this document.
これらの値は、Internet Assigned Numbers Authority（IANA）によって割り当てられた「ETHER TYPE」番号から取得されます。 「ETHER TYPE」の異なる値で識別される他のネットワークプロトコルは、ここで定義されたカプセル化形式を使用できますが、そのような使用はこのドキュメントの範囲外です。
The IB connection setup might be used for both IPv4 and IPv6 or it could be used for only one of them while a different connection is used for the other. The link MTU MUST be able to support the minimum MTU required by the protocols.
IB接続設定は、IPv4とIPv6の両方に使用できます。または、一方にのみ使用して、もう一方に別の接続を使用することもできます。リンクMTUは、プロトコルが必要とする最小MTUをサポートできなければなりません（MUST）。
The default MTU of the IPoIB-CM interface is 2044 octets, i.e., 2048-octet IPoIB-link MTU minus the 4-octet encapsulation header.
IPoIB-CMインターフェイスのデフォルトのMTUは2044オクテットです。つまり、2048オクテットのIPoIBリンクMTUから4オクテットのカプセル化ヘッダーを差し引いたものです。
However, connected modes of InfiniBand allow message sizes up to 2^31 octets. Therefore, IPoIB-CM can use a much larger MTU for unicast communication between any two endpoints. The maximum and/or optimal payload that can be received or sent over an InfiniBand connection is dependent on the implementation, IB Channel Adapter, and the resources configured.
ただし、InfiniBandの接続モードでは、最大2 ^ 31オクテットのメッセージサイズが許可されます。したがって、IPoIB-CMは、任意の2つのエンドポイント間のユニキャスト通信にはるかに大きなMTUを使用できます。 InfiniBand接続を介して送受信できる最大および/または最適なペイロードは、実装、IBチャネルアダプター、および構成されたリソースによって異なります。
An implementation MAY utilize the following mechanism to exchange the optimal message size across the IB connection.
実装は、IB接続を介して最適なメッセージサイズを交換するために、次のメカニズムを利用できます。
Every IB connection setup message includes a "private data" field [IB_ARCH]. The "private data" field in the connection setup message (CM REQ) MUST include the "Receive MTU". This indicates the maximum packet size the requester can accept. The requester MUST be able to accept smaller MTU sizes as well.
すべてのIB接続セットアップメッセージには、「プライベートデータ」フィールド[IB_ARCH]が含まれています。接続セットアップメッセージ（CM REQ）の「プライベートデータ」フィールドには、「受信MTU」を含める必要があります。これは、リクエスターが受け入れることができる最大パケットサイズを示します。リクエスタは、より小さいMTUサイズも受け入れる必要があります。
It is up to the implementation to utilize this mechanism for setting the per-IB connection MTU. To calculate the resultant IPoIB MTU over the connection the smaller of the two IB "Receive MTU" values is used by both the peers. The IPoIB interface must also account for the 4- octet encapsulation header and so the IPoIB MTU over the connection will be further reduced by that amount.
このメカニズムを利用してIB接続ごとのMTUを設定するのは、実装次第です。接続を介して結果のIPoIB MTUを計算するには、2つのIB "Receive MTU"値の小さい方が両方のピアで使用されます。 IPoIBインターフェイスは4オクテットのカプセル化ヘッダーも考慮する必要があるため、接続を介したIPoIB MTUはその分だけさらに削減されます。
The "private data" field in every CM message for connection establishment must include the following values:
接続確立用のすべてのCMメッセージの「プライベートデータ」フィールドには、次の値を含める必要があります。
1. UD QPN of the sender 2. Receive MTU supported by the sender
1. 送信者のUD QPN 2.送信者がサポートする受信MTU
The format of the "private data" field MUST be as follows:
「プライベートデータ」フィールドの形式は、次のようにする必要があります。
0 7 15 23 31
+--------+--------+--------+--------+
|Reserved| UD QPN |
+--------+--------+--------+--------+
| Receive MTU |
+--------+--------+--------+--------+
The Reserved value MUST be set to zero on transmit and ignored on receive.
予約値は送信時にゼロに設定され、受信時に無視されなければなりません。
Every IPoIB interface supports IPoIB-UD. It may additionally support one or both of the IPoIB-CM modes. Therefore, there can be multiple methods of communicating between any two peers. This implies that an interface MAY transmit/receive a packet over any of the RC, UC, or UD modes depending on the modes supported between it and the peer. It further follows that every IPoIB implementation compliant with this document MUST accept all IP unicast transmissions over any of the IPoIB modes it supports. Multicast and broadcast packets by their nature will always be transmitted and received over the IPoIB-UD QP. Additionally, all address resolution responses (ARP or Neighbor Discovery) MUST always be encapsulated in a UD mode packet.
すべてのIPoIBインターフェイスはIPoIB-UDをサポートしています。さらに、IPoIB-CMモードの一方または両方をサポートする場合があります。したがって、2つのピア間で通信する方法は複数存在する可能性があります。これは、インターフェイスがピアとの間でサポートされているモードに応じて、RC、UC、またはUDモードのいずれかでパケットを送受信できることを意味します。さらに、このドキュメントに準拠するすべてのIPoIB実装は、サポートするすべてのIPoIBモードですべてのIPユニキャスト送信を受け入れなければならない（MUST）。マルチキャストおよびブロードキャストパケットは、その性質上、常にIPoIB-UD QPを介して送受信されます。さらに、すべてのアドレス解決応答（ARPまたは近隣探索）は、常にUDモードパケットにカプセル化する必要があります。
The RC mode of InfiniBand guarantees in-order delivery of packets. Every message transmitted over the RC connection is broken into physical MTU-sized packets by the RC connection. If any packet is lost, it is retransmitted until the complete message is exchanged. Therefore, there is a possibility of an upper transport layer experiencing a timeout, while the RC layer is still in the process of transferring the complete message. TCP will view the timeout as an indicator of congestion and enter slow-start thereby affecting throughput drastically [RFC2581]. Other upper-layer protocols might insert retransmissions into the fabric, adding to the already existing congestion.
InfiniBandのRCモードは、パケットの順序どおりの配信を保証します。 RC接続を介して送信されるすべてのメッセージは、RC接続によって物理MTUサイズのパケットに分割されます。パケットが失われた場合、完全なメッセージが交換されるまで再送信されます。したがって、RC層がまだ完全なメッセージを転送している最中に、上位のトランスポート層でタイムアウトが発生する可能性があります。 TCPは、タイムアウトを輻輳のインジケータと見なし、スロースタートに入り、スループットに大きな影響を与えます[RFC2581]。他の上位層プロトコルは、再送信をファブリックに挿入し、既存の輻輳を追加する場合があります。
The applicability of Infiniband reliability is on a fabric with short latencies (not wide area). Therefore, the RC timer values should be short compared with the starting minimum time values used by the upper end-to-end transports. In addition, because the RC mode does not have measurement-based reliable transmission, its use over fabrics with long latency or very dynamic latency may be a concern for congestion-aware traffic traversing those fabrics.
Infinibandの信頼性の適用性は、レイテンシが短い（広域ではない）ファブリックにあります。したがって、RCタイマー値は、上位エンドツーエンドトランスポートで使用される開始最小時間値と比較して短くする必要があります。さらに、RCモードには測定ベースの信頼性の高い伝送がないため、レイテンシが長いまたは非常に動的なレイテンシのあるファブリックでの使用は、それらのファブリックを通過する輻輳認識トラフィックの懸念事項になる可能性があります。
As described above, interfaces on the same subnet may support different link MTUs based on the negotiated value or due to the link type (UD or connected mode). Therefore, an implementation might choose to define a large IP MTU, which is reduced based on the MTU to the destination. The relevant MTU may be stored in a suitable per-destination object, such as a route cache or a neighbor cache. The per-destination MTU is known to the IPoIB-CM interface as described in Section 5.
上記のように、同じサブネット上のインターフェイスは、ネゴシエートされた値に基づいて、またはリンクタイプ（UDまたは接続モード）により、異なるリンクMTUをサポートする場合があります。したがって、実装は、宛先へのMTUに基づいて削減される大きなIP MTUを定義することを選択する場合があります。関連するMTUは、ルートキャッシュやネイバーキャッシュなど、宛先ごとの適切なオブジェクトに格納できます。セクション5で説明されているように、宛先ごとのMTUはIPoIB-CMインターフェイスに認識されています。
Implementations might choose not to support differing MTU values and always support an MTU equal to the IPoIB-UD MTU determined from the broadcast GID.
実装では、異なるMTU値をサポートしないことを選択し、ブロードキャストGIDから決定されたIPoIB-UD MTUと等しいMTUを常にサポートする場合があります。
An impostor may return a false set of flags to an IPOIB interface. This may cause unnecessary attempts and some delay/disruption in IPoIB communication. The same is the case if wrong/spurious QPN values are provided during address resolution broadcast/multicast.
詐欺師は、IPOIBインターフェイスに誤ったフラグのセットを返す場合があります。これにより、IPoIB通信で不必要な試行と遅延/中断が発生する可能性があります。アドレス解決ブロードキャスト/マルチキャスト中に誤った/偽のQPN値が提供された場合も同様です。
Future uses of the reserved bits and octets in the link-layer address (Section 3.1), Service-ID (Section 3.5), and "Private-Data Format" (Section 6) MUST be published as RFCs. This document requires that the reserved bits be set to zero on sends.
リンク層アドレス（セクション3.1）、サービスID（セクション3.5）、および「プライベートデータ形式」（セクション6）での予約ビットおよびオクテットの将来の使用は、RFCとして公開する必要があります。このドキュメントでは、送信時に予約ビットをゼロに設定する必要があります。
The author thanks the IPoIB Working Group for the various comments and suggestions. A special thanks to Bernie King-Smith and Dror Goldenberg for the detailed review and suggestions.
著者は、さまざまなコメントや提案をしてくれたIPoIBワーキンググループに感謝します。詳細なレビューと提案をしてくれたBernie King-SmithとDror Goldenbergに特に感謝します。
[IB_ARCH] InfiniBand Architecture Specification, version 1.2 www.infinibandta.org
[IB_ARCH] InfiniBandアーキテクチャ仕様、バージョン1.2 www.infinibandta.org
[RFC4392] Kashyap, V., "IP over InfiniBand (IPoIB) Architecture", RFC 4392, April 2006.
[RFC4392] Kashyap、V。、「IP over InfiniBand（IPoIB）Architecture」、RFC 4392、2006年4月。
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, April 2006.
[RFC4391] Chu、J。およびV. Kashyap、「IP over InfiniBand（IPoIB）の伝送」、RFC 4391、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control ", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP Congestion Control」、RFC 2581、1999年4月。
Author's Address
著者のアドレス
Vivek Kashyap 15350, SW Koll Parkway Beaverton OR 97006
Vivek Kashyap 15350、SW Koll Parkway Beaverton OR 97006
Phone: +1 503 578 3422
EMail: vivk@us.ibm.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（C）IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状のまま」で提供され、寄稿者、彼/彼女の代理人または組織は（もしあれば）、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースの免責事項明示または黙示を問わず、ここに記載されている情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証を侵害するものではないことを含むすべての保証。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。