Network Working Group J. Chu
Request for Comments: 4391 Sun Microsystems
Category: Standards Track V. Kashyap
IBM
April 2006
Transmission of IP over InfiniBand (IPoIB)
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 Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links.
この文書では、カプセル化したInfiniBand（IB）上でのIPv4 / IPv6およびアドレス解決プロトコル（ARP）パケットを送信するための方法を指定します。これは、（IPoIBの）サブネットインフィニバンド上でIPでIPアドレスを解決する際に使用するリンク層アドレスを記述しています。文書はまた、InfiniBandのマルチキャストアドレスにIPマルチキャストアドレスからのマッピングを説明しています。また、この文書は、IPoIBのリンクのセットアップと構成を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. IP over UD Mode .................................................2
3. InfiniBand Datalink .............................................3
4. Multicast Mapping ...............................................3
4.1. Broadcast-GID Parameters ...................................5
5. Setting Up an IPoIB Link ........................................6
6. Frame Format ....................................................6
7. Maximum Transmission Unit .......................................8
8. IPv6 Stateless Autoconfiguration ................................8
8.1. IPv6 Link-Local Address ....................................9
9. Address Mapping - Unicast .......................................9
9.1. Link Information ...........................................9
9.1.1. Link-Layer Address/Hardware Address ................11
9.1.2. Auxiliary Link Information .........................12
9.2. Address Resolution in IPv4 Subnets ........................13
9.3. Address Resolution in IPv6 Subnets ........................14
9.4. Cautionary Note on QPN Caching ............................14
10. Sending and Receiving IP Multicast Packets ....................14
11. IP Multicast Routing ..........................................16
12. New Types of Vulnerability in IB Multicast ....................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................18
15. Acknowledgements ..............................................18
16. References ....................................................18
16.1. Normative References .....................................18
16.2. Informative References ...................................19
The InfiniBand specification [IBTA] can be found at http://www.infinibandta.org. The document [RFC4392] provides a short overview of InfiniBand architecture (IBA) along with considerations for specifying IP over InfiniBand networks.
インフィニバンド仕様は[IBTA] http://www.infinibandta.orgで見つけることができます。文書[RFC4392]はインフィニバンド・ネットワーク上でIPを指定するための考慮事項とともに、インフィニバンド・アーキテクチャ（IBA）の簡単な概要を提供します。
IBA defines multiple modes of transport over which IP may be implemented. The Unreliable Datagram (UD) transport mode best matches the needs of IP and the need for universality as described in [RFC4392].
IBAは、IPを実装することができる上輸送の複数のモードを定義します。信頼性の低いデータグラム（UD）トランスポートモードでは最高のIPのニーズと[RFC4392]で説明したように普遍性の必要性に合致します。
This document specifies IPoIB over IB's UD mode. The implementation of IP subnets over IB's other transport mechanisms is out of scope of this document.
この文書では、IBのUDモード上でIPoIBのを指定します。 IBの他のトランスポートメカニズムを介したIPサブネットの実装は、この文書の範囲外です。
This document describes the necessary steps required in order to lay out an IP network on top of an IB network. It describes all the elements of an IPoIB link, how to configure its associated attributes, and how to set up basic broadcast and multicast services for it.
この文書では、IBネットワークの上にIPネットワークをレイアウトするために必要な必要な手順を説明しています。それは、それに関連する属性を設定する方法、IPoIBのリンクのすべての要素を説明し、そのための基本的なブロードキャストおよびマルチキャスト・サービスを設定する方法。
It further describes IP address resolution and the encapsulation of IP and Address Resolution Protocol (ARP) packets in InfiniBand frame.
さらに、IPアドレスの解決とのInfiniBandフレームでIPとアドレス解決プロトコル（ARP）パケットのカプセル化について説明します。
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]に記載されているように解釈されます。
The unreliable datagram mode of communication is supported by all IB elements be they IB routers, Host Channel Adapters (HCAs), or Target Channel Adapters (TCAs). In addition to being the only universal transmission method, it supports multicasting, partitioning, and a
通信の信頼性のないデータグラムモードは、すべてのIB要素がIBルータ、ホストチャネルアダプタ（HCAは）、またはターゲットチャネルアダプタ（TCAの）彼らことによってサポートされています。のみユニバーサル送信方法であることに加えて、それはマルチキャスト、パーティショニング、及びAをサポート
32-bit Cyclic Redundancy Check (CRC) [IBTA]. Though multicasting support is optional in IB fabrics, IPoIB architecture requires the participating components to support it.
32ビット巡回冗長検査（CRC）IBTA]。マルチキャストサポートがIBファブリックではオプションですが、IPoIBのアーキテクチャは、それをサポートするために、参加コンポーネントが必要です。
All IPoIB implementations MUST support IP over the UD transport mode of IBA.
すべてのIPoIBの実装は、IBAのUDトランスポートモード上でIPをサポートしなければなりません。
An IB subnet is formed by a network of IB nodes interconnected either directly or via IB switches. IB subnets may be connected using IB routers to form a fabric made of multiple IB subnets. Nodes residing in different IB subnets can communicate directly with one another through IB routers at the IB network layer. Multiple IP subnets may be overlaid over this IB network.
IBサブネットは、直接またはIBスイッチを介して相互接続IBノードのネットワークによって形成されます。 IBのサブネットは複数IBサブネットからなる織物を形成するためにIBルータを使用して接続することができます。異なるIBサブネットに存在するノードはIBネットワーク層でのIBルータを介して互いに直接通信することができます。複数のIPサブネットが、このIBネットワーク上にオーバーレイすることができます。
An IP subnet is configured over a communication facility or medium over which nodes can communicate at the "link" layer [IPV6]. For example, an ethernet segment is a link formed by interconnected switches/hubs/bridges. The segment is therefore defined by the physical topology of the network. This is not the case with IPoIB. IPoIB subnets are built over an abstract "link". The link is defined by its members and common characteristics such as the P_Key, link MTU, and the Q_Key.
IPサブネットは、ノードが「リンク」レイヤ[IPV6]で通信を行う通信設備または媒体上で構成されています。例えば、イーサネット・セグメントが相互接続されたスイッチ/ハブ/ブリッジによって形成されたリンクです。セグメントは、従って、ネットワークの物理トポロジによって定義されます。これは、IPoIBの場合ではありません。 IPoIBのサブネットは、抽象「リンク」上に構築されています。リンクは、そのメンバーとそのようなP_KEY、リンクMTUおよびQ_Keyなどの一般的な特性によって定義されます。
Any two ports using UD communication mode in an IB fabric can communicate only if they are in the same partition (i.e., have the same P_Key and the same Q_Key) [RFC4392]. The link MTU provides a limit to the size of the payload that may be used. The packet transmission and routing within the IB fabric are also affected by additional parameters such as the traffic class (TClass), hop limit (HopLimit), service level (SL), and the flow label (FlowLabel) [RFC4392]. The determination and use of these values for IPoIB communication are described in the following sections.
それらが同じパーティション内にある場合にのみ通信可能IBファブリックにUD通信モードを使用して、任意の2つのポートが[RFC4392]（すなわち、同じP_KEYと同じQ_Keyを有します）。リンクMTUを使用することができるペイロードのサイズに制限を提供します。 IBファブリック内のパケット送信およびルーティングはまた、トラフィッククラス（はTClass）、ホップリミット（HopLimit）、サービスレベル（SL）、およびフローラベル（フローラベル）[RFC4392]などの追加のパラメータによって影響されます。 IPoIBの通信のためのこれらの値の決意および使用は、以下のセクションに記載されています。
IB identifies multicast groups by the Multicast Global Identifiers (MGIDs), which follow the same rules as IPv6 multicast addresses. Hence the MGIDs follow the same rules regarding the transient addresses and scope bits albeit in the context of the IB fabric. The resultant address therefore resembles IPv6 multicast addresses. The documents [IBTA, RFC4392] give a detailed description of IB multicast.
IBは、IPv6マルチキャストアドレスと同じ規則に従うマルチキャストグローバル識別子（MGIDを表示）によってマルチキャストグループを識別する。したがってMGIDを表示は、IBファブリックの文脈でいえ一過アドレスおよび範囲ビットについて同じ規則に従います。結果として得られるアドレスは、したがって、IPv6マルチキャストアドレスに似ています。文書[IBTA、RFC4392]はIBマルチキャストの詳細な説明を与えます。
The IPoIB multicast mapping is depicted in figure 1. The same mapping function is used for both IPv4 and IPv6 except for the IPoIB signature field.
IPoIBのマルチキャストマッピングは、IPoIBの署名フィールドを除く、IPv4とIPv6の両方のために使用される同じマッピング関数同図に示されています。
Unless explicitly stated, all addresses and fields in the protocol headers in this document are stored in the network byte order.
明示的に述べられない限り、このドキュメントのプロトコルヘッダ内のすべてのアドレスとフィールドは、ネットワークバイト順に格納されています。
| 8 | 4 | 4 | 16 bits | 16 bits | 80 bits |
+------ -+----+----+-----------------+---------+-------------------+
|11111111|0001|scop|<IPoIB signature>|< P_Key >| group ID |
+--------+----+----+-----------------+---------+-------------------+
Figure 1
図1
Since an MGID allocated for transporting IP multicast datagrams is considered only a transient link-layer multicast address [RFC4392], all IB MGIDs allocated for IPoIB purpose MUST set T-flag to 1 [IBTA].
IPマルチキャストデータグラムを搬送するために割り当てられたMGIDのみ一過リンク層マルチキャストアドレス[RFC4392]であると考えられるので、IPoIBの目的のために割り当てられたすべてのIBのMGIDを表示する[IBTA】1にT-フラグを設定しなければなりません。
A special signature is embedded to identify the MGID for IPoIB use only. For IPv4 over IB, the signature MUST be "0x401B". For IPv6 over IB, the signature MUST be "0x601B".
特別な署名のみ使用IPoIBのためMGIDを識別するために埋め込まれています。 IB上IPv4の場合、署名は「0x401B」でなければなりません。 IBを超えるIPv6の場合、署名は「0x601B」でなければなりません。
The IP multicast address is used together with a given IPoIB link P_Key to form the MGID of the IB multicast group. For IPv6 the lower 80-bit of the group ID is used directly in the lower 80-bit of the MGID. For IPv4, the group ID is only 28-bit long, and is placed directly in the lower 28 bits of the MGID. The rest of the group ID bits in the MGID are filled with 0.
IPマルチキャストアドレスはIBマルチキャストグループのMGIDを形成するために、所定のIPoIBのリンクP_KEYと一緒に使用されます。 IPv6のためのグループIDの下位80ビットは、MGIDの下位80ビットに直接使用されます。 IPv4の場合、グループIDは、28ビット長であり、そしてMGIDの下位28ビットに直接配置されています。 MGIDのグループIDビットの残りは0で満たされています。
E.g., on an IPoIB link that is fully contained within a single IB subnet with a P_Key of 0x8000, the MGIDs for the all-router multicast group with group ID 2 [AARCH, IGMP3] are:
例えば、完全には0x8000のP_KEY、グループIDを持つすべてのルータのマルチキャストグループのためのMGIDを表示有する単一IBサブネット内に含まれるIPoIBのリンク上の2 [AARCH、IGMP3]です。
FF12:401B:8000::2, for IPv4 in compressed format, and
FF12:601B:8000::2, for IPv6 in compressed format.
A special case exists for the IPv4 limited broadcast address "255.255.255.255" [HOSTS]. The address SHALL be mapped to the "broadcast-GID", which is defined as follows:
特殊なケースは、IPv4ブロードキャストアドレス「255.255.255.255」[ホストを】限定のために存在します。アドレスは以下のように定義される「放送GID」にマッピングされなければなりません。
| 8 | 4 | 4 | 16 bits | 16 bits | 48 bits | 32 bits |
+--------+----+----+----------------+---------+----------+---------+
|11111111|0001|scop|0100000000011011|< P_Key >|00.......0|<all 1's>|
+--------+----+----+----------------+---------+----------+---------+
Figure 2
図2
All MGIDs used in the IPoIB subnet MUST use the same scop bits as in the corresponding broadcast-GID.
IPoIBのサブネットで使用されるすべてのMGIDを表示し、対応する放送GIDと同じSCOPビットを使用しなければなりません。
The broadcast-GID is set up with the following attributes:
放送-GIDを次の属性で設定されています。
A "Full Membership" P_Key (high-order bit is set to 1) MUST be used so that all members may communicate with one another.
すべてのメンバーが相互に通信できるように「フルメンバー」P_KEYは（上位ビットが1にセットされている）を使用しなければなりません。
It is RECOMMENDED that a controlled Q_Key be used with the high-order bit set. This is to prevent non-privileged software from fabricating and sending out bogus IP datagrams.
なお、制御Q_Keyが上位ビットセットで使用することを推奨されています。これは、製造および偽のIPデータグラムを送信するから、非特権ソフトウェアを防ぐためです。
The value assigned to the broadcast-GID must not be greater than any physical link MTU spanned by the IPoIB subnet.
放送-GIDに割り当てられた値は、IPoIBのサブネットが及ぶ任意の物理リンクMTUを超えてはなりません。
The following attributes are required in multicast transmissions and also in unicast transmissions if an IPoIB link covers more than a single IB subnet.
IPoIBのリンクは、単一のIBサブネット以上をカバーしていた場合、次の属性がマルチキャスト伝送にも、ユニキャスト送信に必要とされています。
The selection of TClass, FlowLabel, and HopLimit values is implementation dependent. But it must take into account the topology of IB subnets comprising the IPoIB link in order to allow successful communication between any two nodes in the same IPoIB link.
TClass、フローラベル、およびHopLimit値の選択は実装依存です。しかし、それは同じIPoIBのリンク内の任意の2つのノード間の正常な通信を可能にするために考慮にIPoIBのリンクを含んIBサブネットのトポロジーを取る必要があります。
An SL also needs to be assigned to the broadcast-GID. This SL is used in all multicast communication in the subnet.
SLも放送GIDに割り当てる必要があります。このSLは、サブネット内のすべてのマルチキャスト通信に使用されています。
The broadcast-GID's scope bits need to be set based on whether the IPoIB link is confined within an IB subnet or the IPoIB link spans multiple IB subnets. A default of local-subnet scope (i.e., 0x2) is RECOMMENDED. A node might determine the scope bits to use by interactively searching for a broadcast-GID of ever greater scope by first starting with the local-scope. Or, an implementation might include the scope bits as a configuration parameter.
放送GIDの範囲ビットはIPoIBのリンクがIBサブネット内に制限されるか、またはIPoIBのリンクが複数IBサブネットをまたがるかどうかに基づいて設定する必要があります。ローカルサブネットの範囲（すなわち、0x2の）のデフォルトが推奨されます。ノードは、対話的に第一のローカルスコープで開始することにより、これまでより大きな範囲の放送GIDを検索することにより、使用するスコープのビットを決定するかもしれません。または、実装は、設定パラメータとして、範囲ビットを含むかもしれません。
The broadcast-GID, as defined in the previous section, MUST be set up for an IPoIB subnet to be formed. Every IPoIB interface MUST "FullMember" join the IB multicast group defined by the broadcast-GID. This multicast group will henceforth be referred to as the broadcast group. The join operation returns the MTU, the Q_Key, and other parameters associated with the broadcast group. The node then associates the parameters received as a result of the join operation with its IPoIB interface. The broadcast group also serves to provide a link-layer broadcast service for protocols like ARP, net-directed, subnet-directed, and all-subnets-directed broadcasts in IPv4 over IB networks.
放送GIDは、前のセクションで定義されるように、形成されるIPoIBのサブネット用に設定されなければなりません。すべてのIPoIBのインタフェースは、「FullMemberは」放送GIDによって定義されたIBマルチキャストグループに参加する必要があります。このマルチキャストグループは、今後の放送グループと呼ぶことにします。結合操作は、MTU、Q_Key、ブロードキャストグループに関連付けられた他のパラメータを返します。ノードは、そのIPoIBのインタフェースと結合操作の結果として受信されたパラメータを関連付けます。ブロードキャスト・グループはまた、ARP、IBネットワーク上でIPv4のネット向け、サブネット向け、および全サブネット直接ブロードキャストなどのプロトコルにリンク層ブロードキャストサービスを提供するのに役立ちます。
The join operation is successful only if the Subnet Manager (SM) determines that the joining node can support the MTU registered with the broadcast group [RFC4392] ensuring support for a common link MTU. The SM also ensures that all the nodes joining the broadcast-GID have paths to one another and can therefore send and receive unicast packets. It further ensures that all the nodes do indeed form a multicast tree that allows packets sent from any member to be replicated to every other member. Thus, the IPoIB link is formed by the IPoIB nodes joining the broadcast group. There is no physical demarcation of the IPoIB link other than that determined by the broadcast group membership.
結合演算は、サブネットマネージャ（SM）は、参加するノードは、共通のリンクMTUのサポートを確保するブロードキャストグループ[RFC4392]に登録されたMTUをサポートできると判断した場合にのみ成功します。 SMはまた、放送GIDを接合するすべてのノードが相互にパスを有し、従って、ユニキャストパケットを送信および受信することができることを確実にします。さらに、すべてのノードが実際に任意のメンバーから送信されたパケットが他のすべてのメンバーに複製することを可能にするマルチキャストツリーを形成しないことを保証します。したがって、IPoIBのリンクは、ブロードキャストグループに参加IPoIBのノードによって形成されます。ブロードキャスト・グループ・メンバーシップによって決定されたもの以外のIPoIBリンクの物理的な境界はありません。
The P_Key is a configuration parameter that must be known before the broadcast-GID can be formed. For a node to join a partition, one of its ports must be assigned the relevant P_Key by the SM [RFC4392].
P_KEYは放送-GIDを形成することができる前に知っていなければならない設定パラメータです。パーティションに参加するノードの場合、そのポートの一つがSM [RFC4392]によって関連P_KEYを割り当てなければなりません。
The method of creation of the broadcast group and the assignment/choice of its parameters are up to the implementation and/or the administrator of the IPoIB subnet. The broadcast group may be created by the first IPoIB node to be initialized, or it can be created administratively before the IPoIB subnet is set up. It is RECOMMENDED that the creation and deletion of the broadcast group be under administrative control.
ブロードキャスト・グループの作成方法とそのパラメータの割り当て/選択は、実装および/またはIPoIBのサブネットの管理者までいます。ブロードキャスト・グループが初期化された最初のIPoIBのノードによって作成することができる、またはIPoIBのサブネットが設定される前に、それは管理上作成することができます。ブロードキャスト・グループの作成と削除を管理下することをお勧めします。
InfiniBand multicast management, which includes the creation, joining, and leaving of IB multicast groups by IB nodes, is described in [RFC4392].
接合、及びIBノードによってIBマルチキャストグループの離脱、作成を含むインフィニバンドマルチキャスト管理、[RFC4392]に記載されています。
All IP and ARP datagrams transported over InfiniBand are prefixed by a 4-octet encapsulation header as illustrated below.
以下に示すように、インフィニバンド上で輸送すべてのIPとARPデータグラムは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 |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
図3
The "Reserved" field MUST be set to zero on send and ignored on receive unless specified differently in a future document.
「予約」フィールドは、送信時にゼロに設定し、将来の文書で特に指定しない限り、受信時に無視しなければなりません。
The "Type" field SHALL indicate the encapsulated protocol as per the following table.
「Type」フィールドには、次の表のとおりにカプセル化されたプロトコルを表示しなければなりません。
+----------+-------------+
| Type | Protocol |
|------------------------|
| 0x800 | IPv4 |
|------------------------|
| 0x806 | ARP |
|------------------------|
| 0x8035 | RARP |
|------------------------|
| 0x86DD | IPv6 |
+------------------------+
Table 1
表1
These values are taken from the "ETHER TYPE" numbers assigned by Internet Assigned Numbers Authority (IANA) [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）[IANA]によって割り当てられた "エーテル系" の数字から取られます。 「エーテル型」の異なる値によって識別される他のネットワークプロトコルは、本明細書で定義されるカプセル化フォーマットを使用してもよいが、そのような使用は、この文書の範囲外です。
|<------ IB Frame headers -------->|<- Payload ->|<- IB trailers ->|
+-------+------+---------+---------+-------------+---------+-------+
|Local | |Base |Datagram | 4-octet | | |
|Routing| GRH* |Transport|Extended | header |Invariant|Variant|
|Header |Header|Header |Transport| + | CRC | CRC |
| | | |Header | IP/ARP | | |
+-------+------+---------+---------+-------------+---------+-------+
Figure 4
図4
Figure 4 depicts the IB frame encapsulating an IP/ARP datagram. The InfiniBand specification requires the use of Global Routing Header (GRH) [RFC4392] when multicasting or when an InfiniBand packet traverses from one IB subnet to another through an IB router. Its use is optional when used for unicast transmission between nodes within an IB subnet. The IPoIB implementation MUST be able to handle packets received with or without the use of GRH.
図4は、IP / ARPデータグラムをカプセル化IBフレームを示します。インフィニバンド・パケットは、IBルータを介して別のIBサブネットから横断するときにマルチキャストする場合、またはインフィニバンド仕様は、グローバルルーティングヘッダ（GRH）の使用[RFC4392]を必要とします。 IBのサブネット内のノード間のユニキャスト伝送のために使用される場合、その使用は任意です。 IPoIBの実装は、またはGRHを使用せずに受信したパケットを扱うことができなければなりません。
IB MTU: The IB components, that is, IB links, switches, Channel Adapters (CAs), and IB routers, may support maximum payloads of 256, 512, 1024, 2048, or 4096 octets. The maximum IB payload supported by the IB components in any IB path is the IB MTU for the path.
IB MTU：IB成分は、つまり、IBリンク、スイッチ、チャネルアダプタ（CAS）、及びIBルータは、256、512、1024、2048、または4096オクテットの最大ペイロードをサポートすることができます。任意IB経路におけるIBコンポーネントによってサポートされる最大IBペイロードは、パスのIB MTUです。
IPoIB-Link MTU: The IPoIB-link MTU is the MTU value associated with the broadcast group. The IPoIB-link MTU can be set to any value up to the smallest IB MTU supported by the IB components comprising the IPoIB link.
IPoIBのリンクMTU：IPoIBのリンクMTUは、ブロードキャスト・グループに関連付けられたMTU値です。 IPoIBのリンクMTUは、IPoIBのリンクを含むIBコンポーネントによってサポートされる最小のIB MTUまでの任意の値に設定することができます。
In order to reduce problems with fragmentation and path-MTU discovery, this document requires that all IPoIB implementations support an MTU of 2044 octets, that is, a 2048-octet IPoIB-link MTU minus the 4-octet encapsulation overhead. Larger and smaller MTUs MAY be supported subject to other existing MTU requirements [IPV6], but the default configuration must support an MTU of 2044 octets.
フラグメンテーションおよびパスMTU探索の問題を低減するために、この文書は、すべてのIPoIBの実装は、2044オクテットのMTUをサポートすること、すなわち、2048オクテットIPoIBのリンクMTUマイナス4オクテットのカプセル化オーバーヘッドである必要があります。大きい方と小さい方のMTUは、他の既存のMTU要件[IPV6]の対象にサポートすることもできるが、デフォルトの設定では2044オクテットのMTUをサポートしている必要があります。
IB architecture associates an EUI-64 identifier termed the Globally Unique Identifier (GUID) [RFC4392, IBTA] with each port. The Local Identifier (LID) is unique within an IB subnet only.
IBアーキテクチャは、EUI-64識別子は、各ポートにグローバル一意識別子（GUID）[RFC4392、IBTA]を呼ば関連付けます。ローカル識別子（LID）が唯一のIBサブネット内で一意です。
The interface identifier may be chosen from the following:
インタフェース識別子は、以下から選択することができます。
1) The EUI-64-compliant GUID assigned by the manufacturer.
製造者によって割り当てられた1）EUI-64準拠のGUID。
2) If the IPoIB subnet is fully contained within an IB subnet, any of the unique 16-bit LIDs of the port associated with the IPoIB interface.
2）IPoIBのサブネットが完全IBサブネット内に含まれている場合、IPoIBのインターフェイスに関連付けられたポートのユニークな16ビットの蓋のいずれか。
The LID values of a port may change after a reboot/power-cycle of the IB node. Therefore, if a persistent value is desired, it would be prudent not to use the LID to form the interface identifier.
ポートのLID値は、IBノードのリブート/パワーサイクルの後に変更することができます。永続値が所望される場合、したがって、それはインタフェース識別子を形成するために、LIDを使用しないことが賢明であろう。
On the other hand, the LID provides an identifier that can be used to create a more anonymous IPv6 address since the LID is not globally unique and is subject to change over time.
一方、LIDはLIDがグローバルに一意ではなく、時間をかけて変更されることがありますので、より多くの匿名のIPv6アドレスを作成するために使用することができる識別子を提供します。
It is RECOMMENDED that the link-local address be constructed from the port's EUI-64 identifier as given below.
下記のようなリンクローカルアドレスがポートのEUI-64識別子から構成されることが推奨されます。
[AARCH] requires that the interface identifier be created in the "Modified EUI-64" format when derived from an EUI-64 identifier. [IBTA] is unclear if the GUID should use IEEE EUI-64 format or the "Modified EUI-64" format. Therefore, when creating an interface identifier from the GUID, an implementation MUST do the following:
【AARCH] EUI-64識別子に由来する場合、インタフェース識別子は「修飾EUI-64」形式で作成されることを必要とします。 GUIDは、IEEE EUI-64フォーマットまたは "修飾EUI-64" 形式を使用する必要がある場合[IBTA]不明です。 GUIDからインタフェース識別子を作成する場合したがって、実装は、以下を行う必要があります。
=> Determine if the GUID is a modified EUI-64 identifier ("u" bit is toggled) as defined by [AARCH]
=> GUIDは、によって定義されるように修飾されたEUI-64識別子（「U」のビットがトグルされる）であるかどうかを判断[AARCH]
=> If the GUID is a modified EUI-64 identifier, then the "u" bit MUST NOT be toggled when creating the interface identifier
=> GUIDはインタフェース識別子を作成するときに「U」ビットがトグルしてはいけません、改変EUI-64識別子である場合
=> If the GUID is an unmodified EUI-64 identifier, then the "u" bit MUST be toggled in compliance with [AARCH]
GUIDは、未修飾のEUI-64識別子の場合=>は、「U」はビット[AARCH]に準拠してトグルされなければなりません
The IPv6 link-local address for an IPoIB interface is formed as described in [AARCH] using the interface identifier as described in the previous section.
【AARCH]に記載されているように、前のセクションで説明したようにIPoIBのインタフェースのIPv6リンクローカルアドレスは、インタフェース識別子を使用して形成されています。
Address resolution in IPv4 subnets is accomplished through Address Resolution Protocol (ARP) [ARP]. It is accomplished in IPv6 subnets using the Neighbor Discovery protocol [DISC].
IPv4のサブネット内のアドレス解決は、アドレス解決プロトコル（ARP）[ARP]を介して達成されます。これは、近隣探索プロトコル[DISC]を用いたIPv6サブネットで達成されます。
An InfiniBand packet over the UD mode includes multiple headers such as the LRH (local route header), GRH (global route header), BTH (base transport header), DETH (datagram extended transport header) as depicted in figure 4 and specified in the InfiniBand architecture [IBTA]. All these headers comprise the link-layer in an IPoIB link.
図4に示されているとで指定されるようにUDモード上インフィニバンド・パケットは、LRH（ローカルルートヘッダ）、GRH（グローバルルートヘッダ）、BTH（ベーストランスポートヘッダ）、DETH（データグラム拡張トランスポート・ヘッダ）のような複数のヘッダを含みますInfiniBandアーキテクチャ[IBTA]。すべてのこれらのヘッダは、IPoIBのリンクでリンク層を含みます。
The parameters needed in these IBA headers constitute the link-layer information that needs to be determined before an IP packet may be transmitted across the IPoIB link.
これらIBAヘッダーに必要なパラメータは、IPパケットがIPoIBのリンクを介して送信することができる前に決定する必要がリンク層情報を構成します。
The parameters that need to be determined are as follows:
以下のように決定する必要があるパラメータは次のとおりです。
a) LID
A）LID
The LID is always needed. A packet always includes the LRH that is targeted at the remote node's LID, or an IB router's LID to get to the remote node in another IB subnet.
LIDは常に必要とされています。パケットは、常に他のIBのサブネット内のリモートノードに到達するために、リモート・ノードのLID、またはIBルータのLIDを対象としてLRHが含まれています。
b) Global Identifier (GID)
B）グローバル識別子（GID）
The GID is not needed when exchanging information within an IB subnet though it may be included in any packet. It is an absolute necessity when transmitting across the IB subnet since the IB routers use the GID to correctly forward the packets. The source and destination GIDs are fields included in the GRH.
IBサブネット内の情報を交換するときに任意のパケットに含まれてもよいがGIDが必要とされません。 IBルータが正しくパケットを転送するGIDを使用するのでIBサブネットを横切って送信する場合には、絶対に必要です。送信元と送信先GIDはGRHに含まフィールドです。
The GID, if formed using the GUID, can be used to unambiguously identify an endpoint.
GODは、形成されたGUIDを使用する、明確エンドポイントを識別するために使用することができます。
c) Queue Pair Number (QPN)
C）キューペア番号（QPN）
Every unicast UD communication is always directed to a particular queue pair (QP) at the peer.
すべてのユニキャストUDの通信は、常に、ピアに特定のキュー・ペア（QP）に向けられています。
d) Q_Key
D）Q_Key
A Q_Key is associated with each Unreliable Datagram QPN. The received packets must contain a Q_Key that matches the QP's Q_Key to be accepted.
Q_Keyは、各信頼性の低いデータグラムQPNに関連付けられています。受信したパケットが受け入れられるためにQPのQ_Keyに一致するQ_Keyが含まれている必要があります。
e) P_Key
E）P_KEY
A successful communication between two IB nodes using UD mode can occur only if the two nodes have compatible P_Keys. This is referred to as being in the same partition [IBTA].
UDモードを使用して2つのIBノードとの間の正常な通信は、2つのノードが互換性P_Keyを持っを持っている場合にのみ起こり得ます。これは、同じパーティション[IBTA]であると呼ばれます。
f) SL
f）はSL
Every IBA packet contains an SL value. A path in IBA is defined by the three-tuple (source LID, destination LID, SL). The SL in turns is mapped to a virtual lane (VL) at every CA, switch that sends/forwards the packet [RFC4392]. Multiple SLs may be used between two endpoints to provide for load balancing. SLs may be used for providing a Quality of Service (QoS) infrastructure, or may be used to avoid deadlocks in the IBA fabric.
すべてのIBAパケットは、SLの値が含まれています。 IBA中のパスは、三組（ソースLID、宛先LID、SL）で定義されます。ターンでSLは/転送パケット[RFC4392]を送信するすべてのCAの仮想レーン（VL）、スイッチにマッピングされます。複数のSLは、負荷分散のために提供するために、2つのエンドポイント間で使用されてもよいです。 SLSが、インフラストラクチャサービスの品質（QoS）を提供するために使用することができる、またはIBAファブリックでデッドロックを回避するために使用することができます。
Another auxiliary piece of information, not included in the IBA headers, is the following:
IBAヘッダに含まれていない情報の他の補助部品は、以下の通りであります：
g) Path rate
g）のパス率
IBA defines multiple link speeds. A higher-speed transmitter can swamp switches and the CAs. To avoid such congestion, every source transmitting at greater than 1x speeds is required to determine the "path rate" before the data may be transmitted [IBTA].
IBAは、複数のリンク速度を定義します。より高速な送信機は、スイッチとCAを圧倒することができます。このような輻輳を回避するために、より大きい1X速度で送信毎にソースデータが[IBTA】送信されることができる前に、「パス・レート」を決定する必要があります。
Though the list of information required for a successful transmittal of an IPoIB packet is large, not all the information need be determined during the IP address resolution process.
IPoIBのパケットの成功伝送のために必要な情報の一覧が大きいですが、必ずしもすべての情報は、IPアドレス解決プロセス中に決定される必要があります。
The 20-octet IPoIB link-layer address used in the source/target link-layer address option in IPv6 and the "hardware address" in IPv4/ARP has the same format.
IPv6におけるソース/ターゲットリンク層アドレス・オプションとIPv4 / ARPの「ハードウェアアドレス」で使用される20オクテットIPoIBのリンク層アドレスは、同じフォーマットを有します。
The format is as described below:
以下に記載するようなフォーマットです。
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 | Queue Pair Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ GID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
a) Reserved Flags
a）は予約済みのフラグ
These 8 bits are reserved for future use. These bits MUST be set to zero on send and ignored on receive unless specified differently in a future document.
これらの8ビットは将来の使用のために予約されています。これらのビットは、送信時にゼロに設定し、将来の文書で特に指定しない限り、受信時に無視しなければなりません。
b) QPN
B）QPN
Every unicast communication in IB architecture is directed to a specific QP [IBTA]. This QP number is included in the link description. All IP communication to the relevant IPoIB interface MUST be directed to this QPN. In the case of IPv4 subnets, the Address Resolution Protocol (ARP) reply packets are also directed to the same QPN.
IBアーキテクチャのすべてのユニキャスト通信は、特定のQP [IBTA]を対象とします。このQP番号は、リンクの記述に含まれています。関連するIPoIBのインターフェイスへのすべてのIP通信は、このQPNに向けなければなりません。 IPv4のサブネットの場合には、アドレス解決プロトコル（ARP）応答パケットは、同じQPNに向けられています。
The choice of the QPN for IP/ARP communication is up to the implementation.
IP / ARP通信用QPNの選択は実装に任されています。
c) GID
C）GUIDE
This is one of the GIDs of the port associated with the IPoIB interface [IBTA]. IB associates multiple GIDs with a port. It is RECOMMENDED that the GID formed by the combination of the IB subnet prefix and the port's "Port GUID" [IBTA] be included in the link-layer/hardware address.
これは、IPoIBのインタフェース[IBTA]に関連付けられたポートのGIDの一つです。 IBは、ポートで複数のGIDを関連付けます。 IBサブネットプレフィックスとポートの「ポートGUID」[IBTA]の組み合わせによって形成されたGIDが、リンク層/ハードウェア・アドレスに含まれることが推奨されます。
The rest of the parameters are determined as follows:
次のように残りのパラメータが決定されます。
a) LID
A）LID
The method of determining the peer's LID is not defined in this document. It is up to the implementation to use any of the IBA-approved methods to determine the destination LID. One such method is to use the GID determined during the address resolution, to retrieve the associated LID from the IB routing infrastructure or the Subnet Administrator (SA).
ピアのLIDを決定する方法は、このドキュメントで定義されていません。これは、宛先LIDを決定するためにIBA-承認された方法のいずれかを使用して実装次第です。そのような方法の一つは、IBルーティングインフラストラクチャまたはサブネット管理者（SA）から関連したLIDを取得するために、アドレス解決中に決定GIDを使用することです。
It is the responsibility of the administrator to ensure that the IB subnet(s) have unicast connectivity between the IPoIB nodes. The GID exchanged between two endpoints in a multicast message (ARP/ND) does not guarantee the existence of a unicast path between the two.
IBサブネット（複数可）のIPoIBノード間のユニキャストの接続性を持っていることを確認するには、管理者の責任です。 GIDは、二つの間のユニキャスト経路の存在を保証するものではないマルチキャスト・メッセージ（ARP / ND）に2つのエンドポイント間で交換されます。
There may be multiple LIDs, and hence paths, between the endpoints. The criteria for selection of the LIDs are beyond the scope of this document.
エンドポイント間の複数の蓋、ひいてはパスがあってもよいです。 LIDの選択の基準は、このドキュメントの範囲を超えています。
b) Q_Key
B）Q_Key
The Q_Key received on joining the broadcast group MUST be used for all IPoIB communication over the particular IPoIB link.
Q_Key特定IPoIBのリンクを介してすべてのIPoIBの通信に使用しなければならない放送グループに参加する上で受信されました。
c) P_Key
C）P_KEY
The P_Key to be used in the IP subnet is not discovered but is a configuration parameter.
IPサブネットで使用するP_KEYが発見されたが、設定パラメータではありません。
d) SL
D）SL
The method of determining the SL is not defined in this document. The SL is determined by any of the IBA-approved methods.
SLの決定方法は、このドキュメントで定義されていません。 SLは、IBA-承認された方法のいずれかによって決定されます。
e) Path rate
e）のパス率
The implementation must leverage IB methods to determine the path rate as required.
実装は、必要に応じて、パスの速度を決定するためにIB法を活用しなければなりません。
The ARP packet header is as defined in [ARP]. The hardware type is set to 32 (decimal) as specified by IANA [IANA]. The rest of the fields are used as per [ARP].
[ARP]で定義されるようにARPパケットヘッダがあります。 IANA [IANA]で指定されたハードウェアタイプは32（10進数）に設定されています。残りのフィールドは、[ARP]あたりとして使用されています。
16 bits: hardware type
16 bits: protocol
8 bits: length of hardware address
8 bits: length of protocol address
16 bits: ARP operation
The remaining fields in the packet hold the sender/target hardware and protocol addresses.
パケット内の残りのフィールドは、送信者/ターゲットハードウェアおよびプロトコルアドレスを保持します。
[ sender hardware address ]
[ sender protocol address ]
[ target hardware address ]
[ target protocol address ]
The hardware address included in the ARP packet will be as specified in section 9.1.1 and depicted in figure 5.
セクション9.1.1で指定され、図5に示すようにARPパケットに含まれるハードウェアアドレスがあろう。
The length of the hardware address used in ARP packet header therefore is 20.
したがって、ARPパケットのヘッダに用いられるハードウェアアドレスの長さは20です。
The Source/Target Link-layer address option is used in Router Solicit, Router advertisements, Redirect, Neighbor Solicitation, and Neighbor Advertisement messages when such messages are transmitted on InfiniBand networks.
このようなメッセージは、インフィニバンド・ネットワーク上で送信される場合、ソース/ターゲットリンク層アドレスオプションは、ルーター要請、ルーター通知、リダイレクト、近隣要請、及び近隣広告メッセージで使用されています。
The source/target address option is specified as follows:
次のようにソース/ターゲット・アドレス・オプションが指定されています。
Type:
Source Link-layer address 1
Target Link-layer address 2
Length: 3
長さ：3
Link-layer address:
リンク層アドレス：
The link-layer address is as specified in section 9.1.1 and
depicted in figure 5.
[DISC] specifies the length of source/target option in number of 8-octets as indicated by a length of '3' above. Since the IPoIB link-layer address is only 20 octets long, two octets of zero MUST be prepended to fill the total option length of 24 octets.
上記「3」の長さによって示されるように[DISC]は8オクテットの数にソース/ターゲットオプションの長さを指定します。 IPoIBのリンク層アドレスのみが20オクテットの長さであるので、ゼロの2つのオクテットは、24オクテットの総数オプションの長さを埋めるために付加されなければなりません。
The link-layer address for IPoIB includes the QPN, which might not be constant across reboots or even across network interface resets. Cached QPN entries, such as in static ARP entries or in Reverse Address Resolution Protocol (RARP) servers, will only work if the implementation(s) using these options ensure that the QPN associated with an interface is invariant across reboots/network resets.
IPoIBのためのリンク層アドレスは、リブートあるいはネットワークインターフェースリセットにわたって一定ではないかもしれないQPNを含みます。これらのオプションを使用して実装（s）がインターフェイスに関連付けられQPNは、再起動/ネットワークのリセット全体で不変であることを確認する場合は、このような静的ARPエントリまたは逆アドレス解決プロトコル（RARP）サーバのようにキャッシュされたQPNエントリは、のみ動作します。
It is RECOMMENDED that implementations revalidate ARP caches periodically due to the aforementioned QPN-induced volatility of IPoIB link-layer addresses.
実装が原因のIPoIBリンク層アドレスの前述のQPN誘発性のボラティリティに定期的にARPキャッシュを再検証することを推奨されます。
Multicast in InfiniBand differs in a number of ways from multicast in ethernet. This adds some complexity to an IPoIB implementation when supporting IP multicast over IB.
インフィニバンドでのマルチキャストは、イーサネットにおけるマルチキャストからいくつかの方法が異なります。 IBオーバーIPマルチキャストをサポートしているとき、これはIPoIBの実装にいくつかの複雑さを追加します。
A) An IB multicast group must be explicitly created through the SA before it can be used.
それは使用することができます前に、A）IBマルチキャストグループは、明示的にSAを介して作成する必要があります。
This implies that in order to send a packet destined for an IP multicast address, the IPoIB implementation must check with the SA on the outbound link first for a "MCMemberRecord" that matches the MGID. If one does exist, the Multicast Local Identifier (MLID) associated with the multicast group is used as the Destination Local Identifier (DLID) for the packet. Otherwise, it implies no member exists on the local link. If the scope of the IP multicast group is beyond link-local, the packet must be sent to the on-link routers through the use of the all-router multicast group or the broadcast group. This is to allow local routers to forward the packet to multicast listeners on remote networks. The all-router multicast group is preferred over the broadcast group for better efficiency. If the all-router multicast group does not exist, the sender can assume that there are no routers on the local link; hence the packet can be safely dropped.
これは、IPマルチキャストアドレス宛のパケットを送信するために、IPoIBの実装はMGIDと一致した「MCMemberRecord」のための最初のアウトバウンドリンクをSAに確認しなければならないことを意味します。が存在しない場合、マルチキャストグループに関連付けられているマルチキャストローカル識別子（MLID）は、パケットの宛先ローカル識別子（DLID）として使用されます。そうでなければ、それはメンバーがローカルリンク上に存在しない意味します。 IPマルチキャストグループのスコープはリンクローカルを超えている場合、パケットはすべて、ルータのマルチキャストグループまたはブロードキャストグループを使用して、リンク上のルータに送信する必要があります。これは、ローカルルータはリモートネットワーク上のマルチキャストリスナーにパケットを転送できるようにすることです。すべてのルータのマルチキャストグループは、より良い効率のためにブロードキャスト・グループよりも好ましいです。すべてのルータのマルチキャストグループが存在しない場合、送信者は、ローカルリンク上の一切のルータが存在しないと仮定することができます。したがって、パケットが安全に削除できます。
B) A multicast sender must join the target multicast group before outgoing multicast messages from it can be successfully routed. The "SendOnlyNonMember" join is different from the regular "FullMember" join in two aspects. First, both types of joins enable multicast packets to be routed FROM the local port, but only the "FullMember" join causes multicast packets to be routed TO the port. Second, the sender port of a "SendOnlyNonMember" join will not be counted as a member of the multicast group for purposes of group creation and deletion.
それからの発信マルチキャストメッセージを正常にルーティングすることができます前に、B）は、マルチキャスト送信者がターゲットマルチキャストグループに参加する必要があります。 「SendOnlyNonMember」参加は、通常の「FullMember」二つの側面に参加異なっています。まず、両方のタイプは、ローカルポートからルーティングするためのマルチキャストパケットを有効に合流するが、唯一「FullMemberは、」ポートにルーティングされるようにするマルチキャストパケットを結合します。第二に、「SendOnlyNonMember」の送信元ポートは、グループの作成と削除の目的のためにマルチキャストグループのメンバーとしてカウントされることはありません参加します。
The following code snippet demonstrates the steps in a typical implementation when processing an egress multicast packet.
出力マルチキャストパケットを処理する際に次のコードスニペットは、典型的な実施のステップを示しています。
if the egress port is already a "SendOnlyNonMember", or a "FullMember" => send the packet
出力ポートがすでに「SendOnlyNonMember」、または「FullMember」であれば=>パケットを送ります
else if the target multicast group exists => do "SendOnlyNonMember" join => send the packet
ターゲットマルチキャストグループが存在する他の場合=>「SendOnlyNonMemberは」パケットを送信=>参加ください
else if scope > link-local AND the all-router multicast group exists => send the packet to all routers
スコープ>リンクローカルと全ルータのマルチキャストグループが存在する他の場合=>すべてのルータにパケットを送信します
else => drop the packet
他に=>パケットをドロップします
Implementations should cache the information about the existence of an IB multicast group, its MLID and other attributes. This is to avoid expensive SA calls on every outgoing multicast packet. Senders MUST subscribe to the multicast group create and delete traps in order to monitor the status of specific IB multicast groups. For example, multicast packets directed to the all-router multicast group due to a lack of listener on the local subnet must be forwarded to the right multicast group if the group is created later. This happens when a listener shows up on the local subnet.
実装はIBマルチキャストグループの存在、そのMLIDおよびその他の属性に関する情報をキャッシュする必要があります。これは、高価なSAは、すべての発信マルチキャストパケットに対して呼び出しを避けることです。送信者は、特定のIBマルチキャストグループのステータスを監視するために、トラップを作成し、削除し、マルチキャストグループに加入する必要があります。グループは後で作成されている場合たとえば、原因ローカルサブネット上のリスナーがないため、すべてのルーターマルチキャストグループに向けたマルチキャストパケットは、右のマルチキャストグループに転送する必要があります。リスナーがローカルサブネット上に現れたときに発生します。
A node joining an IP multicast group must first construct an MGID according to the rule described in section 4 above. Once the correct MGID is calculated, the node must call the SA of the outbound link to attempt a "FullMember" join of the IB multicast group corresponding to the MGID. If the IB multicast group does not already exist, one must be created first with the IPoIB link MTU. The MGID MUST use the same P_Key, Q_Key, SL, MTU, and HopLimit as those used in the broadcast-GID. The rest of attributes SHOULD follow the values used in the broadcast-GID as well.
IPマルチキャストグループに参加するノードは、最初に上記のセクション4で説明したルールに従ってMGIDを構築しなければなりません。正しいMGIDが計算されると、ノードは「FullMemberは」MGIDに対応するIBマルチキャストグループの参加を試みるためにアウトバウンドリンクのSAを呼び出す必要があります。 IBマルチキャストグループが存在しない場合、1はIPoIBのリンクMTUを最初に作成する必要があります。 MGIDは放送GIDに使用されるものと同じP_KEY、Q_Key、SL、MTU、およびHopLimitを使用しなければなりません。属性の残りの部分は、同様に放送GIDで使用される値に従ってください。
The join request will cause the local port to be added to the multicast group. It also enables the SM to program IB switches and routers with the new multicast information to ensure the correct forwarding of multicast packets for the group.
参加要求は、ローカルポートがマルチキャストグループに追加されることになります。それはまた、グループのためのマルチキャスト・パケットの正しい転送を保証するために、新たなマルチキャスト情報とIBスイッチおよびルータをプログラムするためにSMを可能にします。
When a node leaves an IP multicast group, it SHOULD make a "FullMember" leave request to the SA. This gives the SM an opportunity to update relevant forwarding information, to delete an IB multicast group if the local port is the last FullMember to leave, and to free up the MLID allocated for it. The specific algorithm is implementation-dependent and is out of the scope of this document.
ノードがIPマルチキャストグループを離れたとき、それはSAに「FullMember」休暇申請を行う必要があります。これは、SMにローカルポートが残して、それに割り当てられたMLIDを解放するために、最後のFullMemberであればIBマルチキャストグループを削除するには、関連するフォワーディング情報を更新する機会を与えてくれます。特定のアルゴリズムは実装依存であり、この文書の範囲外です。
Note that for an IPoIB link that spans more than one IB subnet connected by IB routers, an adequate multicast forwarding support at the IB level is required for multicast packets to reach listeners on a remote IB subnet. The specific mechanism for this is beyond the scope of IPoIB.
IBルータによって接続された複数のIBサブネットにまたがるIPoIBのリンクのためなお、IBレベルで十分なマルチキャスト転送のサポートは、リモートIBサブネット上リスナーに到達するマルチキャストパケットのために必要とされます。このため具体的なメカニズムは、IPoIBのの範囲を超えています。
IP multicast routing requires each interface over which the router is operating to be configured to listen to all link-layer multicast addresses generated by IP [IPMULT, IP6MLD]. For an Ethernet interface, this is often achieved by turning on the promiscuous multicast mode on the interface.
IPマルチキャストルーティングは、ルータがIP [IPMULT、IP6MLD]によって生成されたすべてのリンク層マルチキャストアドレスをリッスンするように構成することが動作している上に、各インターフェイスを必要とします。イーサネットインターフェイスの場合、これは多くの場合、インターフェイス上の無差別マルチキャストモードをオンにすることによって達成されます。
IBA does not provide any hardware support for promiscuous multicast mode. Fortunately, a promiscuous multicast mode can be emulated in the software running on a router through the following steps:
IBAは無差別マルチキャストモードのための任意のハードウェアサポートを提供していません。幸いなことに、無差別マルチキャストモードでは、次の手順を介してルータ上で動作するソフトウェアでエミュレートすることができます。
A) Obtain a list of all active IB multicast groups from the local SA.
A）ローカルSAからのすべてのアクティブIBマルチキャストグループのリストを取得します。
B) Make a "NonMember" join request to the SA for every group that has a signature in its MGID matching the one for either IPv4 or IPv6.
B）「非会員」はIPv4またはIPv6のいずれかのための1つに一致するそのMGIDで署名を有するグループ毎にSAに参加要求を作ります。
C) Subscribe to the IB multicast group creation events using a wildcarded MGID so that the router can "NonMember" join all IB multicast groups created subsequently for IPv4 or IPv6.
C）ルータは「非会員」とは、すべてのIBマルチキャストグループがIPv4またはIPv6用に作成した後に参加できるようにワイルドカードを使ったMGIDを使用してIBマルチキャストグループの作成イベントを購読します。
The "NonMember" join has the same effect as a "FullMember" join except that the former will not be counted as a member of the multicast group for purposes of group creation or deletion. That is, when the last "FullMember" leaves a multicast group, the group can be safely deleted by the SA without concerning any "NonMember" routers.
「非会員」は、「FullMember」前者はグループの作成または削除の目的のためのマルチキャストグループのメンバーとしてカウントされないことを除いて参加するのと同じ効果を有する参加します。それは、最後の「FullMember」は、マルチキャストグループを離れると、グループは安全に任意の「非会員」ルータに関するずにSAによって削除することが可能です。
Many IB multicast functions are subject to failures due to a number of possible resource constraints. These include the creation of IB multicast groups, the join calls ("SendOnlyNonMember", "FullMember", and "NonMember"), and the attaching of a QP to a multicast group.
多くのIBマルチキャスト機能は、可能な資源制約の数による故障の対象となっています。これらはIBマルチキャストグループの作成を含め、参加コール（「SendOnlyNonMember」、「FullMember」、および「非会員」）、およびマルチキャストグループへのQPの取付。
In general, the occurrence of these failure conditions is highly implementation-dependent, and is believed to be rare. Usually, a failed multicast operation at the IB level can be propagated back to the IP level, causing the original operation to fail and the initiator of the operation to be notified. But some IB multicast functions are not tied to any foreground operation, making their failures hard to detect. For example, if an IP multicast router attempts to "NonMember" join a newly created multicast group in the local subnet, but the join call fails, packet forwarding for that particular multicast group will likely fail silently, that is, without the attention of local multicast senders. This type of problem can add more vulnerability to the already unreliable IP multicast operations.
一般に、これらの障害状態の発生を高度に実装依存であり、稀であると考えられています。通常、IBレベルで失敗したマルチキャストの操作は、元の操作が失敗し、バックIPレベルに伝播することができ、操作のイニシエータが通知されます。しかし、いくつかのIBマルチキャスト機能を検出するのは自分の失敗はハード作り、任意のフォアグラウンド操作に縛られていません。例えば、IPマルチキャストルータは、「非会員」はローカルサブネットに新しく作成されたマルチキャストグループに参加しようとしたが、参加の呼び出しは、その特定のマルチキャストグループのために、パケット転送は可能性の高い地元の注目せずに、つまり、黙って失敗します失敗した場合マルチキャスト送信者。この種の問題は、既に信頼できないIPマルチキャスト操作に多くの脆弱性を追加することができます。
Implementations SHOULD log error messages upon any failure from an IB multicast operation. Network administrators should be aware of this vulnerability, and preserve enough multicast resources at the points where IP multicast will be used heavily. For example, HCAs with ample multicast resources should be used at any IP multicast router.
実装はIBマルチキャスト操作から任意の失敗したときにエラーメッセージがログインする必要があります。ネットワーク管理者は、この脆弱性を認識して、およびIPマルチキャストが頻繁に使用されるポイントで十分なマルチキャストリソースを保持する必要があります。例えば、十分なマルチキャストリソースとのHCAは、任意のIPマルチキャストルータで使用されるべきです。
This document specifies IP transmission over a multicast network. Any network of this kind is vulnerable to a sender claiming another's identity and forging traffic or eavesdropping. It is the responsibility of the higher layers or applications to implement suitable countermeasures if this is a problem.
この文書では、マルチキャストネットワーク上でIP伝送を指定します。この種の任意のネットワークが別のアイデンティティを主張し、トラフィックや盗聴を鍛造送信者に対して脆弱です。問題である場合、適切な対策を実施するための上位層またはアプリケーションの責任です。
Successful transmission of IP packets depends on the correct setup of the IPoIB link, creation of the broadcast-GID, creation of the QP and its attachment to the broadcast-GID, and the correct determination of various link parameters such as the LID, service level, and path rate. These operations, many of which involve interactions with the SM/SA, MUST be protected by the underlying operating system. This is to prevent malicious, non-privileged software from hijacking important resources and configurations.
IPパケットの送信成功、正しいIPoIBのリンクの設定、放送GIDの作成、QPの作成とその放送GIDへの結合、およびそのようなLIDのような様々なリンクパラメータの正しい決定は、サービスレベルに依存します、およびパス・レート。 SM / SAとの相互作用を伴うそれらの多くはこれらの操作は、基礎となるオペレーティング・システムによって保護されなければなりません。これは重要な資源と構成をハイジャックから悪質な、非特権ソフトウェアを防ぐためです。
Controlled Q_Keys SHOULD be used in all transmissions. This is to prevent non-privileged software from fabricating IP datagrams.
制御Q_Keysは、すべての送信で使用されるべきです。これは、IPデータグラムを製造から非特権ソフトウェアを防ぐためです。
To support ARP over InfiniBand, a value for the Address Resolution Parameter "Number Hardware Type (hrd)" is required. IANA has assigned the number "32" to indicate InfiniBand [IANA_ARP].
インフィニバンド上でARPをサポートするために、アドレス解決パラメータ「番号ハードウェアタイプ（HRD）」の値が必要です。 IANAは、インフィニ[IANA_ARP]を示すために、数字「32」が割り当てられています。
Future uses of the reserved bits in the frame format (Figure 3) and link-layer address (Figure 5) MUST be published as RFCs. This document requires that the reserved bits be set to zero on send and ignored on receive.
フレームフォーマット（図3）とリンク層アドレス（図5）内の予約ビット将来の用途はRFCとして公開されなければなりません。この文書では、予約ビットは、送信時にゼロに設定し、受信時に無視されている必要があります。
The authors would like to thank Bruce Beukema, David Brean, Dan Cassiday, Aditya Dube, Yaron Haviv, Michael Krause, Thomas Narten, Erik Nordmark, Greg Pfister, Jim Pinkerton, Renato Recio, Kevin Reilly, Kanoj Sarcar, Satya Sharma, Madhu Talluri, and David L. Stevens for their suggestions and many clarifications on the IBA specification.
著者はブルースBeukema、デビッドBrean、ダンCassiday、アーディティヤデュベ、ヤロンHaviv、マイケル・クラウス、トーマスNarten氏、エリックNordmarkと、グレッグ・フィスター、ジム・ピンカートン、レナートRecio、ケビン・ライリー、Kanoj Sarcar、サティヤ・シャルマ、マドゥTalluriに感謝したいと思います、とDavid L.スティーブンスIBA仕様上の彼らの提案や、多くの明確化のため。
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[AARCH] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[ARP] Plummer, David C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware ", STD 37, RFC 826, November 1982.
[ARP]プラマー、デビッド・C.、 "イーサネットアドレス解決プロトコル：またはEthernetハードウェア上での伝送のためのイーサネットアドレスを48ビットするネットワーク・プロトコル・アドレスを変換"、STD 37、RFC 826、1982年11月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[IANA] Internet Assigned Numbers Authority, URL http://www.iana.org
[IANA]インターネット割り当て番号機関、URL http://www.iana.org
[IANA_ARP] URL http://www.iana.org/assignments/arp-parameters
[IANA_ARP] URL http://www.iana.org/assignments/arp-parameters
[IBTA] InfiniBand Architecture Specification, URL http://www.infinibandta.org/specs
[IBTA]インフィニバンドアーキテクチャ仕様、URL http://www.infinibandta.org/specs
[RFC4392] Kashyap, V., "IP over InfiniBand (IPoIB) Architecture", RFC 4392, April 2006.
[RFC4392]カシャップ、V.、 "IP経由のInfiniBand（IPoIBの）アーキテクチャ"、RFC 4392、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[HOSTS] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[HOSTS]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[IGMP3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[IGMP3]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[IP6MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
"IPv6のためのマルチキャストリスナー発見（MLD）" [IP6MLD]デアリング、S.、フェナー、W.、およびB.ハーバーマン、RFC 2710、1999年10月。
[IPMULT] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[IPMULT]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
Authors' Addresses
著者のアドレス
H.K. Jerry Chu 17 Network Circle, UMPK17-201 Menlo Park, CA 94025 USA
H.K.ジェリー・チュー17ネットワークサークル、UMPK17-201メンロパーク、CA 94025 USA
Phone: +1 650 786 5146 EMail: jerry.chu@sun.com
電話：+1 650 786 5146 Eメール：jerry.chu@sun.com
Vivek Kashyap 15350, SW Koll Parkway Beaverton, OR 97006 USA
ヴィヴェックカシャップ15350、SW KOLLパークウェイビーバートン、OR 97006 USA
Phone: +1 503 578 3422 EMail: vivk@us.ibm.com
電話：+1 503 578 3422 Eメール：vivk@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。