[要約] RFC 4391は、IPoIB（InfiniBand上のIPの伝送）に関する標準化されたプロトコル仕様です。このRFCの目的は、InfiniBandネットワーク上でIPトラフィックを効率的に伝送するためのガイドラインを提供することです。
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)
infinibandを介したIPの送信（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).
Copyright（c）The Internet Society（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.
このドキュメントは、IPv4/IPv6をカプセル化および送信する方法を指定し、Infiniband（IB）を介して解像度プロトコル（ARP）パケットをアドレスします。IPアドレスをIPのIPアドレス（IPOIB）サブネット上のIPアドレスを解決するときに使用するリンク層アドレスについて説明します。このドキュメントでは、IPマルチキャストアドレスからInfinibandマルチキャストアドレスへのマッピングについても説明しています。さらに、このドキュメントでは、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.
Infiniband仕様[IBTA]は、http：//www.infinibandta.orgにあります。ドキュメント[RFC4392]は、Infiniband Networksを介してIPを指定するための考慮事項とともに、Infiniband Architecture（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）トランスポートモードは、[RFC4392]に記載されているように、IPのニーズと普遍性の必要性に最適です。
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アドレス解像度と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 32-bit Cyclic Redundancy Check (CRC) [IBTA]. Though multicasting support is optional in IB fabrics, IPoIB architecture requires the participating components to support it.
信頼できないデータグラム通信モードは、IBルーター、ホストチャネルアダプター（HCA）、またはターゲットチャネルアダプター（TCA）など、すべてのIB要素によってサポートされています。唯一のユニバーサル伝送方法であることに加えて、マルチキャスト、パーティション化、および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ルーターを介して互いに直接通信することができます。このIBネットワーク上で複数のIPサブネットがオーバーレイされる場合があります。
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、Link 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つのポートは、同じパーティションにある場合にのみ通信できます（つまり、同じP_KEYと同じQ_KEYを持っています）[RFC4392]。リンクMTUは、使用できるペイロードのサイズに制限を提供します。IBファブリック内のパケット送信とルーティングは、トラフィッククラス（TCLASS）、ホップリミット（HOPLIMIT）、サービスレベル（SL）、フローラベル（FlowLabel）[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マルチキャストアドレスと同じルールに従うマルチキャストグローバル識別子（MGIDS）によってマルチキャストグループを識別します。したがって、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マルチキャストマッピングを図1に示します。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は、T-FLAGを1 [IBTA]に設定する必要があります。
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マルチキャストアドレスは、特定のIPOIBリンクP_KEYと一緒に使用され、IBマルチキャストグループのMGIDを形成します。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を持つ単一のIBサブネット内に完全に含まれるIPOIBリンクで、グループID 2 [AARCH、IGMP3]を持つオールルーターマルチキャストグループのMGIDSは次のとおりです。
FF12:401B:8000::2, for IPv4 in compressed format, and FF12:601B:8000::2, for IPv6 in compressed format.
FF12：401B：8000 :: 2、IPv4の圧縮形式で、FF12：601b：8000 :: 2、IPv6の圧縮形式。
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」[ホスト]に特別なケースが存在します。アドレスは、次のように定義されている「ブロードキャストギッド」にマッピングされなければなりません。
| 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は、次の属性を使用してセットアップされます。
1. P_Key
1. p_key
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に設定されます）を使用する必要があります。
2. Q_Key
2. Q_KEY
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データグラムを製造して送信するのを防ぐためです。
3. IB MTU
3. IB MTU
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サブネットをカバーしている場合、マルチキャストトランスミッションおよびユニキャストトランスミッションでは、次の属性が必要です。
4. Other parameters
4. その他のパラメーター
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、FlowLabel、および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もブロードキャストギッドに割り当てる必要があります。この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.
IPOIBリンクがIBサブネット内に限定されているのか、IPOIBリンクが複数のIBサブネットに及ぶかどうかに基づいて、ブロードキャストGIDのスコープビットを設定する必要があります。ローカルサブネットスコープ（つまり、0x2）のデフォルトが推奨されます。ノードは、最初にローカルスコープから始まることにより、より大きなスコープのブロードキャストギッドをインタラクティブに検索することにより、使用するスコープビットを決定する場合があります。または、実装には、構成パラメーターとしてスコープビットを含める場合があります。
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.
前のセクションで定義されている放送具は、IPOIBサブネットを形成するために設定する必要があります。すべてのIPOIBインターフェイスは、「FullMember」に「FullMember」に参加する必要があります。このマルチキャストグループは今後、放送グループと呼ばれます。結合操作は、放送グループに関連付けられたMTU、Q_Key、およびその他のパラメーターを返します。次に、ノードは、IPOIBインターフェイスで結合操作の結果として受信したパラメーターを関連付けます。ブロードキャストグループは、IBネットワークを介してIPv4でARP、ネット指向、サブネット指向、および全面的に向けられた放送などのプロトコルにリンク層ブロードキャストサービスを提供することも役立ちます。
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を形成する前に知っておく必要がある構成パラメーターです。ノードがパーティションに参加するには、そのポートの1つに、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マルチキャストグループの作成、結合、および離脱を含むInfinibandマルチキャスト管理は、[RFC4392]に記載されています。
All IP and ARP datagrams transported over InfiniBand are prefixed by a 4-octet encapsulation header as illustrated below.
Infinibandを介して輸送されるすべての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 | 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.
これらの値は、インターネットに割り当てられた数字の権限（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フレームを示しています。Infinibandの仕様では、マルチキャスト時または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リンク、スイッチ、チャネルアダプター（CA）、および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-Link MTU：IPOIB-Link MTUは、放送グループに関連付けられたMTU値です。IPOIB-Link 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.
断片化とPath-MTU発見の問題を軽減するために、このドキュメントでは、すべてのIPOIB実装が2044オクテットのMTUをサポートする必要があります。他の既存のMTU要件[IPv6]の対象となる大小のMTUがサポートされる場合がありますが、デフォルトの構成は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 Architectureは、Global Inited Identifier（GUID）[RFC4392、IBTA]と呼ばれるEUI-64識別子を各ポートに関連付けています。ローカル識別子（蓋）は、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.
ポートの蓋の値は、IBノードの再起動/パワーサイクルの後に変更される場合があります。したがって、永続的な値が必要な場合、蓋を使用してインターフェイス識別子を形成しないことは賢明です。
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.
一方、蓋は、蓋がグローバルに一意ではなく、時間とともに変化する可能性があるため、より匿名の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:
=> Determine if the GUID is a modified EUI-64 identifier ("u" bit is toggled) as defined by [AARCH]
=> [AARCH]で定義されているように、GUIDが修正されたEUI-64識別子（ "u"ビットが切り替えられます）であるかどうかを判断します
=> If the GUID is a modified EUI-64 identifier, then the "u" bit MUST NOT be toggled when creating the interface identifier
=> GUIDが修正されたEUI-64識別子の場合、インターフェイス識別子を作成するときに「u」ビットを切り替えてはなりません
=> 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.
IPOIBインターフェイスのIPv6リンクローカルアドレスは、前のセクションで説明されているようにインターフェイス識別子を使用して[AARCH]で説明されているように形成されます。
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.
UDモード上のインフィニバンドパケットには、図4に描かれ、図4に示され、指定されているように、LRH（ローカルルートヘッダー）、GRH（グローバルルートヘッダー）、BTH（ベーストランスポートヘッダー）、DETH（データグラム拡張輸送ヘッダー）などの複数のヘッダーが含まれます。Infiniband Architecture [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) 蓋
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.
蓋は常に必要です。パケットには、リモートノードの蓋をターゲットにするLRH、または別のIBサブネットのリモートノードに到達するためのIBルーターの蓋が常に含まれます。
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.
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_keysがある場合にのみ発生する可能性があります。これは、同じパーティション[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のパスは、3タプル（ソースリッド、宛先蓋、SL）によって定義されます。SLは、パケット[RFC4392]を送信/転送するすべてのCA、スイッチのすべてのCAで仮想レーン（VL）にマッピングされます。2つのエンドポイント間で複数のSLを使用して、負荷分散を提供することができます。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は複数のリンク速度を定義します。より高速送信機は、スイッチとCASを沼地にすることができます。このような輻輳を回避するために、データを送信する前に「パスレート」を決定するために、1倍以上の速度で送信するすべてのソースが必要です[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のソース/ターゲットリンクレイヤーアドレスオプションで使用されている20オクタートIPOIBリンクレイヤーアドレスとIPv4/ARPの「ハードウェアアドレス」は同じ形式です。
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) gid
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の1つです。IBは、複数のGIDをポートに関連付けます。IBサブネットプレフィックスとポートの「ポートGUID」[IBTA]の組み合わせによって形成されたGIDを、リンクレイヤー/ハードウェアアドレスに含めることをお勧めします。
The rest of the parameters are determined as follows:
残りのパラメーターは次のように決定されます。
a) LID
a) 蓋
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).
ピアの蓋を決定する方法は、このドキュメントでは定義されていません。IBAが承認した方法のいずれかを使用して、宛先の蓋を決定するのは実装次第です。そのような方法の1つは、アドレス解像度中に決定されたGIDを使用して、IBルーティングインフラストラクチャまたはサブネット管理者（SA）から関連する蓋を取得することです。
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ノード間でユニキャスト接続を確実にすることは、管理者の責任です。マルチキャストメッセージ（ARP/ND）で2つのエンドポイント間で交換されたGIDは、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.
エンドポイント間に複数の蓋、したがってパスがある場合があります。蓋の選択の基準は、このドキュメントの範囲を超えています。
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（小数）に設定されています。残りのフィールドは[arp]に従って使用されます。
16 bits: hardware type 16 bits: protocol 8 bits: length of hardware address 8 bits: length of protocol address 16 bits: ARP operation
16ビット：ハードウェアタイプ16ビット：プロトコル8ビット：ハードウェアアドレスの長さ8ビット：プロトコルアドレスの長さ16ビット：ARP操作
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.
ARPパケットに含まれるハードウェアアドレスは、セクション9.1.1で指定されており、図5に示されています。
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.
ソース/ターゲットリンクレイヤーアドレスオプションは、Router Salict、Router Advertisements、Redirect、Neighbor Salititation、およびNeighbor Advertisementメッセージで使用されます。
The source/target address option is specified as follows:
ソース/ターゲットアドレスオプションは、次のように指定されています。
Type: Source Link-layer address 1 Target Link-layer address 2
タイプ：ソースリンク層アドレス1ターゲットリンク層アドレス2
Length: 3
長さ：3
Link-layer address:
リンク層アドレス：
The link-layer address is as specified in section 9.1.1 and depicted in figure 5.
リンク層アドレスは、セクション9.1.1で指定されており、図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.
[disc]上記の「3」の長さで示されるように、8オクテットの数でソース/ターゲットオプションの長さを指定します。IPOIBリンク層アドレスは長さ20オクテットしかないため、ゼロの2オクテットを準備する必要があります。
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が含まれています。これは、再起動全体やネットワークインターフェイスリセット全体で一定ではない場合があります。静的ARPエントリやリバースアドレス解像度プロトコル（RARP）サーバーなどのキャッシュされたQPNエントリは、これらのオプションを使用して実装がインターフェイスに関連付けられている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マルチキャストグループの範囲がLink-Localを超えている場合、All-Router Multicastグループまたはブロードキャストグループを使用して、パケットをオンリンクルーターに送信する必要があります。これは、ローカルルーターがリモートネットワーク上のマルチキャストリスナーにパケットを転送できるようにするためです。全ルーターマルチキャストグループは、より良い効率を得るためにブロードキャストグループよりも好まれます。全ルーターマルチキャストグループが存在しない場合、送信者はローカルリンクにルーターがないと想定できます。したがって、パケットを安全にドロップできます。
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」結合は、通常の「フルメンバー」とは異なります。まず、両方のタイプの結合により、マルチキャストパケットをローカルポートからルーティングできますが、「フルメンバー」結合のみがマルチキャストパケットをポートにルーティングします。第二に、「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
ターゲットマルチキャストグループが存在する場合=> do "sendonlynonmember" join =>パケットを送信する
else if scope > link-local AND the all-router multicast group exists => send the packet to all routers
scope> link-localとall-routerマルチキャストグループが存在する場合=>すべてのルーターにパケットを送信する
else => drop the packet
else =>パケットをドロップします
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が計算されると、ノードはアウトバウンドリンクのSAを呼び出して、MGIDに対応するIBマルチキャストグループの「フルメンバー」結合を試みる必要があります。IBマルチキャストグループがまだ存在しない場合、最初にIPOIBリンクMTUで作成する必要があります。MGIDは、ブロードキャストギッドで使用されているものと同じ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.
結合要求により、ローカルポートがマルチキャストグループに追加されます。また、SMが新しいマルチキャスト情報を使用してIBスイッチとルーターをプログラムして、グループのマルチキャストパケットの正しい転送を確保することができます。
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マルチキャストグループを離れると、「FullMember」をSAにリクエストを残す必要があります。これにより、SMは関連する転送情報を更新し、ローカルポートが最後のフルメンバーである場合にIBマルチキャストグループを削除し、そのために割り当てられたMLIDを解放する機会を与えます。特定のアルゴリズムは実装依存であり、このドキュメントの範囲外です。
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のいずれかのものと一致する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）ワイルドカードMGIDを使用してIBマルチキャストグループ作成イベントを購読して、ルーターが「非メンバー」がIPv4またはIPv6用に作成されたすべての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.
「非メンバー」結合は、グループの作成または削除の目的でマルチキャストグループのメンバーとしてカウントされないことを除いて、「フルメンバー」の結合と同じ効果を持っています。つまり、最後の「フルメンバー」がマルチキャストグループを離れると、グループは「非メンバー」ルーターについては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への添付ファイル、および蓋、サービスレベルなどのさまざまなリンクパラメーターの正しい決定に依存します。、およびパスレート。これらの操作は、その多くが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].
Infiniband上の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）の将来の使用は、RFCSとして公開する必要があります。このドキュメントでは、予約されたビットを送信時にゼロに設定し、受信時に無視する必要があります。
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.
著者は、ブルース・ベウケマ、デビッド・ブレアン、ダン・カシデイ、アディティア・デューブ、ヤロン・ハヴィヴ、マイケル・クラウス、トーマス・ナルテン、エリック・ノードマーク、グレッグ・フィスター、ジム・ピンカートン、レナート・レシオ、ケビン・ライリー、カノジ・サルカー、サティア・シャルマに感謝したい、およびDavid L. Stevensの提案とIBA仕様に関する多くの説明について。
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[Aarch] Hinden、R。and S. Deering、「インターネットプロトコルバージョン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] Plummer、David C.、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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. Simpson、「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] Infiniband Architecture Specification、url http://www.infinibandta.org/specs
[RFC4392] Kashyap, V., "IP over InfiniBand (IPoIB) Architecture", RFC 4392, April 2006.
[RFC4392] Kashyap、V。、「IP Over Infiniband（IPOIB）Architecture」、RFC 4392、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月。
[HOSTS] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[ホスト] Braden、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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.
[IP6MLD] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[IPMULT] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[IPMult] Deering、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] Deering、S。and 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.Jerry Chu 17 Network Circle、UMPK17-201 MENLO PARK、CA 94025 USA
Phone: +1 650 786 5146
EMail: jerry.chu@sun.com
Vivek Kashyap 15350, SW Koll Parkway Beaverton, OR 97006 USA
Vivek Kashyap 15350、SW Koll Parkway Beaverton、または97006 USA
Phone: +1 503 578 3422
EMail: vivk@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。