[要約] RFC 4392は、IPoIBアーキテクチャに関する仕様であり、InfiniBandネットワーク上でのIP通信を可能にする。目的は、高性能なInfiniBandネットワークを利用して、IPベースのアプリケーションやサービスを実現すること。
Network Working Group V. Kashyap
Request for Comments: 4392 IBM
Category: Informational April 2006
IP over InfiniBand (IPoIB) Architecture
IP over Infiniband（IPOIB）アーキテクチャ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
InfiniBand is a high-speed, channel-based interconnect between systems and devices.
Infinibandは、システムとデバイスの間の高速でチャネルベースの相互接続です。
This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents.
このドキュメントでは、Infiniband Architectureの概要を示します。さらに、IPのインフィニバンドを介して送信するための要件とガイドラインについて説明します。このドキュメントでの議論は、明示的に指定されていない限り、IPv4とIPv6の両方に適用されます。IPのIPのカプセル化とIBファブリックのIPアドレス解像度のメカニズムは、他のドキュメントで説明されています。
Table of Contents
目次
1. Introduction to InfiniBand ......................................2
1.1. InfiniBand Architecture Specification ......................2
1.2. Overview of InfiniBand Architecture ........................2
1.2.1. InfiniBand Addresses ................................6
1.2.1.1. Unicast GIDs ...............................7
1.2.1.2. Multicast GIDs .............................7
1.3. InfiniBand Multicast Group Management ......................9
1.3.1. Multicast Member Record ............................10
1.3.1.1. JoinState .................................10
1.3.2. Join and Leave Operations ..........................11
1.3.2.1. Creating a Multicast Group ................11
1.3.2.2. Deleting a Multicast Group ................11
1.3.2.3. Multicast Group Create/Delete Traps .......12
2. Management of InfiniBand Subnet ................................12
3. IP over IB .....................................................12
3.1. InfiniBand as Datalink ....................................13
3.2. Multicast Support .........................................13
3.2.1. Mapping IP Multicast to IB Multicast ...............14
3.2.2. Transient Flag in IB MGIDs .........................14
3.3. IP Subnets Across IB Subnets ..............................14
4. IP Subnets in InfiniBand Fabrics ...............................14
4.1. IPoIB VLANs ...............................................16
4.2. Multicast in IPoIB subnets ................................16
4.2.1. Sending IP Multicast Datagrams .....................17
4.2.2. Receiving Multicast Packets ........................18
4.2.3. Router Considerations for IPoIB ....................18
4.2.4. Impact of InfiniBand Architecture Limits ...........19
4.2.5. Leaving/Deleting a Multicast Group .................19
4.3. Transmission of IPoIB Packets .............................20
4.4. Reverse Address Resolution Protocol (RARP) and
Static ARP Entries ........................................20
4.5. DHCPv4 and IPoIB ..........................................21
5. QoS and Related Issues .........................................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................22
The InfiniBand Trade Association (IBTA) was formed to develop an I/O specification to deliver a channel based, switched fabric technology. The InfiniBand standard is aimed at meeting the requirements of scalability, reliability, availability, and performance of servers in data centers.
Infiniband Trade Association（IBTA）は、チャネルベースのスイッチングファブリックテクノロジーを提供するI/O仕様を開発するために設立されました。Infiniband標準は、データセンターのサーバーのスケーラビリティ、信頼性、可用性、およびパフォーマンスの要件を満たすことを目的としています。
The InfiniBand Trade Association specification is available for download from http://www.infinibandta.org.
Infiniband貿易協会の仕様は、http：//www.infinibandta.orgからダウンロードできます。
For a more complete overview, the reader is referred to chapter 3 of the InfiniBand specification.
より完全な概要については、読者はInfiniband仕様の第3章を参照します。
InfiniBand Architecture (IBA) defines a System Area Network (SAN) for connecting multiple independent processor platforms, I/O platforms, and I/O devices. The IBA SAN is a communications and management infrastructure supporting both I/O and inter-processor communications for one or more computer systems.
Infiniband Architecture（IBA）は、複数の独立したプロセッサプラットフォーム、I/Oプラットフォーム、およびI/Oデバイスを接続するためのシステムエリアネットワーク（SAN）を定義しています。IBA SANは、1つ以上のコンピューターシステムのI/Oとプロセッサ間通信の両方をサポートする通信および管理インフラストラクチャです。
An IBA SAN consists of processor nodes and I/O units connected through an IBA fabric made up of cascaded switches and IB routers (connecting IB subnets). I/O units can range in complexity from a single Application-specific Integrated Circuit (ASIC) IBA-attached device (such as a LAN adapter) to a large, memory-rich Redundant Array of Independent Disks (RAID) subsystem.
IBA SANは、カスケードスイッチとIBルーター（IBサブネットを接続する）で構成されたIBAファブリックを介して接続されたプロセッサノードとI/Oユニットで構成されています。I/Oユニットは、単一のアプリケーション固有の統合回路（ASIC）IBAアタッチドデバイス（LANアダプターなど）から、メモリが豊富な独立したディスク（RAID）サブシステムの大規模でメモリが豊富な冗長なアレイ（LANアダプターなど）から複雑になります。
An IBA network may be subdivided into subnets interconnected by routers. These are IB routers and IB subnets and not IP routers or IP subnets. This document will refer to InfiniBand routers and subnets as 'IB routers' and 'IB subnets' respectively. The IP routers and IP subnets will be referred to as 'routers' and 'subnets', respectively.
IBAネットワークは、ルーターによって相互接続されたサブネットに細分化される場合があります。これらは、IBルーターとIBサブネットであり、IPルーターまたはIPサブネットではありません。このドキュメントでは、それぞれInfinibandルーターとサブネットを「IBルーター」と「IBサブネット」と呼びます。IPルーターとIPサブネットは、それぞれ「ルーター」と「サブネット」と呼ばれます。
Each IB node or switch may attach to a single or multiple switches or directly with each other. Each IB unit interfaces with the link by way of channel adapters (CAs). The architecture supports multiple CAs per unit with each CA providing one or more ports that connect to the fabric. Each CA appears as a node to the fabric.
各IBノードまたはスイッチは、単一または複数のスイッチに接続するか、互いに直接接続できます。各IBユニットは、チャネルアダプター（CA）を使用してリンクをインターフェースします。アーキテクチャはユニットあたりの複数のCAをサポートし、各CAはファブリックに接続する1つ以上のポートを提供します。各CAは、ファブリックのノードとして表示されます。
The ports are the endpoints to which the data is sent. However, each of the ports may include multiple QPs (Queue Pairs) that may be directly addressed from a remote peer. From the point of view of data transfer the QP number (QPN) is part of the address.
ポートは、データが送信されるエンドポイントです。ただし、各ポートには、リモートピアから直接対処できる複数のQPS（キューペア）が含まれる場合があります。データ転送の観点から、QP番号（QPN）はアドレスの一部です。
IBA supports both connection-oriented and datagram service between the ports. The peers are identified by QPN and the port identifier. There are a two exceptions. QPNs are not used when packets are multicast. QPNs are also not used in the Raw Datagram mode.
IBAは、ポート間の接続指向とデータグラムの両方のサービスをサポートしています。ピアはQPNとポート識別子によって識別されます。2つの例外があります。パケットがマルチキャストの場合、QPNは使用されません。QPNは、生データグラムモードでも使用されません。
A port, in a data packet, is identified by a Local Identifier (LID) and optionally a Global Identifier (GID). The GID in the packet is needed only when communicating across an IB subnet, though it may always be included.
データパケット内のポートは、ローカル識別子（蓋）およびオプションでグローバル識別子（GID）によって識別されます。パケットのGIDは、IBサブネットを横切って通信する場合にのみ必要ですが、常に含まれている場合があります。
The GID is 128 bits long and is formed by the concatenation of a 64- bit IB subnet prefix and a 64-bit EUI-64-compliant portion. The EUI-64 portion of a GID is referred to as the Global Unique Identifier (GUID; EUI stands for Extended Unique Identifier). The LID is a 16-bit value that is assigned when the port becomes active. The GUID is the only persistent identifier of a port. However, it cannot be used as an address in a packet. If the prefix is modified, then the GID may change. The subnet manager may attempt to keep the LID values constant across reboots, but that is not a requirement.
GIDの長さは128ビットで、64ビットIBサブネットプレフィックスと64ビットEUI-64準拠の部分の連結によって形成されます。GIDのEUI-64部分は、グローバルな一意の識別子と呼ばれます（GUID; EUIは拡張ユニークな識別子の略）。蓋は、ポートがアクティブになったときに割り当てられる16ビット値です。GUIDは、ポートの唯一の永続的な識別子です。ただし、パケット内のアドレスとして使用することはできません。プレフィックスが変更されている場合、GIDが変更される場合があります。サブネットマネージャーは、再起動全体で蓋の値を一定に保つことを試みることができますが、それは要件ではありません。
The assignment of the GID and the LID is done by the subnet manager. Every IB subnet has at least one subnet manager component that controls the fabric. It assigns the LIDs and GIDs. The subnet manager also programs the switches so that they route packets between destinations. The subnet manager (SM) and a related component, the subnet administrator (SA), are the central repository of all information that is required to set-up and bring up the fabric.
GIDと蓋の割り当ては、サブネットマネージャーによって行われます。すべてのIBサブネットには、ファブリックを制御する少なくとも1つのサブネットマネージャーコンポーネントがあります。蓋とGIDを割り当てます。サブネットマネージャーはまた、スイッチをプログラムして、パケットを宛先間でルーティングするようにします。サブネットマネージャー（SM）と関連コンポーネントであるサブネット管理者（SA）は、ファブリックをセットアップして持ち上げるのに必要なすべての情報の中央リポジトリです。
IB routers are components that route packets between IB subnets based on the GIDs. Thus, within an IB subnet a packet may or may not include a GID but when going across an IB subnet the GID must be included. A LID is always needed in a packet since the destination within a subnet is determined by it.
IBルーターは、GIDに基づいてIBサブネット間でパケットをルーティングするコンポーネントです。したがって、IBサブネット内では、パケットがGIDを含める場合と含まない場合がありますが、IBサブネットを横切る場合はGIDを含める必要があります。サブネット内の宛先はそれによって決定されるため、パケットには常に蓋が必要です。
A CA and a switch may have multiple ports. Each CA port is assigned its own LID or a range of LIDs. The ports of a switch are not addressable by LIDs/GIDs or, in other words, are transparent to other end nodes. Each port has its own set of buffers. The buffering is channeled through virtual lanes (VL) where each VL has its own flow control. There may be up to 16 VLs.
CAおよびスイッチには複数のポートがある場合があります。各CAポートには、独自のふたまたは蓋の範囲が割り当てられています。スイッチのポートは、蓋/GIDによってアドレス指定できないか、言い換えれば、他のエンドノードに対して透明です。各ポートには、独自のバッファーセットがあります。バッファリングは、各VLに独自のフロー制御がある仮想レーン（VL）を介してチャネリングされます。最大16のVLがある場合があります。
VLs provide a mechanism for creating multiple virtual links within a single physical link. All ports must support VL15 which is reserved exclusively for subnet management datagrams and hence does not concern the IP over Infiniband (IPoIB) discussions. The actual VL that a packet uses is configured by the SM in the switch/channel adapter tables and is determined based on the Service Level (SL) specified in every packet. There are 16 possible SLs.
VLSは、単一の物理リンク内で複数の仮想リンクを作成するメカニズムを提供します。すべてのポートは、サブネット管理データグラム専用に予約されているVL15をサポートする必要があるため、IPのIPに関するIP（IPOIB）の議論には関係ありません。パケットが使用する実際のVLは、スイッチ/チャネルアダプターテーブルのSMによって構成され、すべてのパケットで指定されたサービスレベル（SL）に基づいて決定されます。16個のSLSがあります。
In addition to the features described above viz. QPs, SLs, and addressing (GID/LID), IBA also defines the following:
上記の機能に加えて。QPS、SLS、およびアドレス指定（GID/LID）、IBAは以下も定義します。
Partitioning:
分割：
Every packet, but for the raw datagrams, carries the partition key (P_Key). These values are used for isolation in the fabric. A switch (this is an optional feature) may be programmed by the SM to drop packets not having a certain key. The CA ports always check for the P_Keys. A CA port may belong to multiple partitions. P_Key checking is optional at IB routers.
すべてのパケットは、生のデータグラムの場合、パーティションキー（P_KEY）が搭載されています。これらの値は、ファブリックの分離に使用されます。スイッチ（これはオプションの機能です）は、特定のキーがないパケットをドロップするためにSMによってプログラムされます。CAポートは常にP_Keysをチェックします。CAポートは複数のパーティションに属する場合があります。P_KEYチェックは、IBルーターでオプションです。
A P_Key may be described as having 'limited membership' or 'full membership'. For a packet to be accepted, at least one of the P_Keys (i.e., the P_Key in the packet or the P_Key in the port) must be 'full membership' P_Keys.
P_KEYは、「メンバーシップが限られている」または「完全なメンバーシップ」を持っていると説明される場合があります。パケットを受け入れるには、P_Keysの少なくとも1つ（つまり、パケットのP_KEYまたはポートのP_KEY）は「完全なメンバーシップ」P_Keysでなければなりません。
Q_Keys:
Q_Keys：
Q_Keys are used to enforce access rights for reliable and unreliable IB datagram services. Raw datagram services do not use Q_Keys. At communication establishment, the endpoints exchange the Q_Keys and must always use the relevant Q_Keys when communicating with one another. Multicast packets use the Q_Key associated with the multicast group.
Q_Keysは、信頼できる信頼できないIBデータグラムサービスのアクセス権を強制するために使用されます。生データグラムサービスはQ_Keysを使用しません。通信施設では、エンドポイントはQ_Keysを交換し、互いに通信するときは常に関連するQ_Keysを使用する必要があります。マルチキャストパケットは、マルチキャストグループに関連付けられているQ_Keyを使用します。
Q_Keys with the most significant bit set are considered controlled Q_Keys (such as the General Service Interface (GSI) Q_Key [IB_ARCH]) and a Host Channel Adapter (HCA) does not allow a consumer to arbitrarily specify a controlled Q_Key. An attempt to send a controlled Q_Key results in using the Q_Key in the QP context. Thus, the Operating System maintains control since it can configure the QP context for the controlled Q_Key for privileged consumers. It must be noted that though the notion of a 'controlled Q_Key' is suggested by IB specification, it does not require its use or implementation.
最も重要なビットセットを持つQ_Keysは、制御されたQ_Keys（一般サービスインターフェイス（GSI）Q_KEY [IB_ARCH]など）と見なされ、ホストチャンネルアダプター（HCA）は、消費者が制御されたQ_KEYを任意に指定することを許可しません。制御されたQ_KEYを送信する試みは、QPコンテキストでQ_Keyを使用します。したがって、オペレーティングシステムは、特権消費者向けの制御されたQ_KeyのQPコンテキストを構成できるため、制御を維持します。「制御されたQ_KEY」の概念はIB仕様によって示唆されているが、その使用または実装は必要ないことに注意する必要があります。
Multicast support:
マルチキャストサポート：
A switch may support multicasting, that is, replication of packets across multiple output ports. This is an optional feature. Similarly, support for sending/receiving multicast packets is optional in CAs. A multicast group is identified by a GID. The GID format is as defined in RFC 2373 on IPv6 addressing [IB_ARCH]. Thus, from an IPv6-over-InfiniBand point of view, the data link multicast address looks like the network address. An IB port must explicitly join a multicast group by sending a request to the SM to receive multicast packets. A port may send packets to any multicast group. In both cases, the multicast LID to be used in the packets is received from the SM.
スイッチは、マルチキャスト、つまり複数の出力ポートにわたるパケットの複製をサポートする場合があります。これはオプションの機能です。同様に、CASでは、マルチキャストパケットの送信/受信のサポートがオプションです。マルチキャストグループはGIDによって識別されます。GID形式は、IPv6アドレス指定[IB_ARCH]のRFC 2373で定義されています。したがって、IPv6-over-infinibandの観点から、データリンクマルチキャストアドレスはネットワークアドレスのように見えます。IBポートは、SMにリクエストを送信してマルチキャストパケットを受信することにより、マルチキャストグループに明示的に参加する必要があります。ポートは、マルチキャストグループにパケットを送信する場合があります。どちらの場合も、パケットで使用するマルチキャスト蓋がSMから受信されます。
There are six methods for data transfer in IB architecture:
IBアーキテクチャには、データ転送には6つの方法があります。
1. Unreliable Datagram (unacknowledged - connectionless)
1. 信頼できないデータグラム（ックノウレッジ - コネクションレス）
The Unreliable Datagram (UD) service is connectionless and unacknowledged. It allows the QP to communicate with any unreliable datagram QP on any node.
信頼性の低いデータグラム（UD）サービスは、コネクションレスで承認されていません。これにより、QPは、任意のノード上の信頼性の低いデータグラムQPと通信できます。
The switches and hence each link can support only a certain MTU. The MTU ranges are 256 octets, 512 octets, 1024 octets, 2048 octets, and 4096 octets. A UD packet cannot be larger than the link MTU between the two peers.
スイッチとしたがって、各リンクは特定のMTUのみをサポートできます。MTU範囲は、256オクテット、512オクテット、1024オクテット、2048オクテット、4096オクテットです。UDパケットは、2つのピア間のリンクMTUよりも大きくすることはできません。
2. Reliable Datagram (acknowledged - multiplexed)
2. 信頼できるデータグラム（確認済み - 多重化）
The Reliable Datagram (RD) service is multiplexed over connections between nodes called End-to-End Contexts (EEC), which allows each RD QP to communicate with any RD QP on any node with an established EEC. Multiple QPs can use the same EEC and a single QP can use multiple EECs (one for each remote node per reliable datagram domain).
信頼できるデータグラム（RD）サービスは、エンドツーエンドコンテキスト（EEC）と呼ばれるノード間の接続に対して多重化されているため、各RD QPは、確立されたEECを使用して任意のノード上の任意のRD QPと通信できます。複数のQPは同じEECを使用でき、単一のQPは複数のEEC（信頼できるデータグラムドメインごとに1つのリモートノードに1つ）を使用できます。
3. Reliable Connected (acknowledged - connection oriented)
3. 信頼できる接続（確認済み - 接続指向）
The Reliable Connected (RC) service associates a local QP with one and only one remote QP. The message sizes maybe as large as 2^31 octets in length. The CA implementation takes care of segmentation and assembly.
信頼性の高い接続（RC）サービスは、ローカルQPを1つのリモートQPに関連付けます。メッセージサイズは、長さ2^31オクテットほど大きいかもしれません。CAの実装は、セグメンテーションとアセンブリを処理します。
4. Unreliable Connected (unacknowledged - connection oriented)
4. 信頼できない接続（承認なし - 接続指向）
The Unreliable Connected (UC) service associates one local QP with one and only one remote QP. There is no acknowledgement and hence no resend of lost or corrupted packets. Such packets are therefore simply dropped. It is similar to RC otherwise.
信頼性の低い接続（UC）サービスは、1つのローカルQPを1つのリモートQPに関連付けます。承認はなく、したがって、紛失または破損したパケットの再送信はありません。したがって、このようなパケットは単純に削除されます。それ以外の場合はRCに似ています。
5. Raw Ethertype (unacknowledged - connectionless)
5. RAW ETHERTYPE（UNACKNOWLEDGED-コネクションレス）
The Ethertype raw datagram packet contains a generic transport header that is not interpreted by the CA but it specifies the protocol type. The values for ethertype are the same as defined by Internet Assigned Numbers Authority (IANA) [IANA] for ethertype.
EtherType Raw Datagramパケットには、CAで解釈されない一般的なトランスポートヘッダーが含まれていますが、プロトコルタイプを指定します。EtherTypeの値は、EtherTypeのインターネット割り当てされた数字authority（IANA）[IANA] [IANA]で定義されているのと同じです。
6. Raw IPv6 (unacknowledged - connectionless)
6. RAW IPv6（Unacknowledged -Connectionless）
Using IPv6 raw datagram service, the IBA CA can support standard protocol layers atop IPv6 (such as TCP/UDP). Thus, native IPv6 packets can be bridged into the IBA SAN and delivered directly to a port and to its IPv6 raw datagram QP.
IPv6 Raw Datagramサービスを使用して、IBA CAはIPv6（TCP/UDPなど）の上の標準プロトコルレイヤーをサポートできます。したがって、ネイティブIPv6パケットはIBA SANにブリッジし、ポートとそのIPv6 RAWデータグラムQPに直接配信できます。
The first four types are referred to as IB transports. The latter two are classified as raw datagrams. There is no indication of the QP number in the raw datagram packets. The raw datagram packets are limited by the link MTU in size.
最初の4つのタイプは、IBトランスポートと呼ばれます。後者の2つは、生データグラムとして分類されます。生データグラムパケットにQP番号の兆候はありません。生のデータグラムパケットは、リンクMTUによって制限されています。
The two connected modes and the Reliable Datagram mode may also support Automatic Path Migration (APM). This is an optional facility that provides for a hardware based path fail over. An alternate path is associated with the QP when the connection/EE context is first created. If unrecoverable errors are encountered, the connection switches to using the alternative path.
2つの接続モードと信頼性の高いデータグラムモードは、自動パス移行（APM）をサポートする場合があります。これは、ハードウェアベースのパスが失敗するためのオプションの機能です。接続/EEコンテキストが最初に作成された場合、代替パスはQPに関連付けられます。回復不可能なエラーが発生した場合、接続は代替パスの使用に切り替わります。
The InfiniBand architecture borrows heavily from the IPv6 architecture in terms of the InfiniBand subnet structure and GIDs.
Infiniband Architectureは、IPV6アーキテクチャからIPV6アーキテクチャから、インフィニバンドのサブネット構造とGIDの観点から大きく借用しています。
The InfiniBand architecture defines the GID associated with a port as a 128-bit unicast or multicast identifier. IBA derives the GID address format, as defined in RFC 2373 [IB_ARCH], with some additional properties/restrictions defined to facilitate efficient discovery, communication, and routing.
Infinibandアーキテクチャは、ポートに関連付けられたGIDを128ビットユニキャストまたはマルチキャスト識別子として定義しています。IBAは、RFC 2373 [IB_ARCH]で定義されているGIDアドレス形式を導き出し、効率的な発見、コミュニケーション、およびルーティングを容易にするために定義された追加のプロパティ/制限があります。
Note: The IBA explicitly refers to RFC 2373, which is obsolete [RFC3513]. It must be noted that IBA is therefore unaffected by any further changes that are introduced in IPv6 addressing architecture.
注：IBAは、廃止されたRFC 2373を明示的に指します[RFC3513]。したがって、IBAは、IPv6アドレス指定アーキテクチャで導入されたさらなる変更の影響を受けないことに注意する必要があります。
IBA defines two types of GIDs: unicast and multicast.
IBAは、ユニキャストとマルチキャストの2種類のGIDを定義しています。
The unicast GIDs are defined, as in IPv6, with three scopes. The IB specification states the following:
ユニキャストGIDは、IPv6のように3つのスコープを備えた定義です。IB仕様には、次のように記載されています。
a. link local: FE80/10.
a. LINK LOCAL：FE80/10。
The IB routers will not forward packets with a link-local address in source or destination beyond the IB subnet.
IBルーターは、IBサブネットを越えたソースまたは宛先のリンクローカルアドレスでパケットを転送しません。
b. site local: FEC0/10
b. サイトローカル：FEC0/10
A unicast GID used within a collection of subnets that is unique within that collection (e.g., a data center or campus) but is not necessarily globally unique. IB routers must not forward any packets with either a site-local Source GID or a site-local Destination GID outside of the site.
そのコレクション内でユニークなサブネットのコレクション内で使用されるユニキャストGID（たとえば、データセンターやキャンパス）は必ずしもグローバルにユニークではありません。IBルーターは、サイトのローカルソースGIDまたはサイトの外側のサイトローカル宛先GIDを使用して、パケットを転送してはなりません。
c. global:
c. グローバル：
A unicast GID with a global prefix; an IB router may use this GID to route packets throughout an enterprise or internet.
グローバルプレフィックスを備えたユニキャストGID。IBルーターは、このGIDを使用して、企業またはインターネット全体でパケットをルーティングできます。
The multicast GIDs also parallel the IPv6 multicast addresses. The IB specification defines the multicast GIDs as follows:
マルチキャストGIDは、IPv6マルチキャストアドレスにも並行しています。IB仕様は、次のようにマルチキャストGIDを定義します。
FFxy:<112 bits>
Flag bits:
フラグビット：
The nibble, denoted by x above, are the 4 flag bits: 000T.
上記のXで示されるニブルは、4つのフラグビット：000tです。
The first 3 bits are reserved and are set to zero. The last bit is defined as follows:
最初の3ビットは予約されており、ゼロに設定されています。最後のビットは次のように定義されています。
T=0: denotes a permanently assigned, that is, well-known GID
T=1: denotes a transient group
Scope bits:
スコープビット：
The 4 bits, denoted by y in the GID above, are the scope bits. These scope values are described in Table 1.
上記のGIDでyで示される4ビットは、スコープビットです。これらのスコープ値を表1に示します。
scope value Address value
スコープ値アドレス値
0 Reserved
1 Unassigned
2 Link-local
3 Unassigned
4 Unassigned
5 Site-local
6 Unassigned
7 Unassigned
8 Organization-local
9 Unassigned
0xA Unassigned
0xB Unassigned
0xC Unassigned
0xD Unassigned
0xE Global
0xF Reserved
Table 1
表1
The IB specification further refers to RFC 2373 and RFC 2375 while defining the well-known multicast addresses. However, it then states that the well-known addresses apply to IB raw IPv6 datagrams only. It must be noted though that a multicast group can be associated with only a single Multicast Global Identifier (MGID). Thus the same MGID cannot be associated with the UD mode and the Raw Datagram mode.
IB仕様は、よく知られているマルチキャストアドレスを定義しながら、RFC 2373およびRFC 2375をさらに参照しています。ただし、よく知られているアドレスがIB RAW IPv6データグラムのみに適用されると述べています。ただし、マルチキャストグループは単一のマルチキャストグローバル識別子（MGID）のみに関連付けられることに注意する必要があります。したがって、同じMGIDをUDモードとRAW Datagramモードに関連付けることはできません。
IB multicast groups, identified by MGIDs, are managed by the SM. The SM explicitly programs the IB switches in the fabric to ensure that the packets are received by all the members of the multicast group that request the reception of packets. The SM also needs to program the switches such that packets transmitted to the group by any group member reach all receivers in the multicast group.
MGIDSによって識別されるIBマルチキャストグループは、SMによって管理されています。SMは、IBをファブリック内のスイッチを明示的にプログラムして、パケットの受信を要求するマルチキャストグループのすべてのメンバーがパケットを受信するようにします。また、SMは、グループメンバーによってグループに送信されたパケットがマルチキャストグループのすべてのレシーバーに到達するように、スイッチをプログラムする必要があります。
IBA distinguishes between multicast senders and receivers. Though all members of a multicast group can transmit to the group (and expect their packets to be correctly forwarded), not all members of the group are receivers. A port needs to explicitly request that multicast packets addressed to the group be forwarded to it.
IBAは、マルチキャスト送信者とレシーバーを区別します。マルチキャストグループのすべてのメンバーはグループに送信できますが（パケットが正しく転送されることを期待しています）、グループのすべてのメンバーが受信機であるわけではありません。ポートは、グループにアドレス指定されたマルチキャストパケットを転送することを明示的に要求する必要があります。
A multicast group is created by sending a join request to the SM. As will be explained later, IBA defines multiple modes for joining a multicast group. The subnet manager records the group's multicast GID and the associated characteristics. The group characteristics are defined by the group path MTU, whether the group will be used for raw datagrams or unreliable datagrams, the service level, the partition key associated with the group, the Local Identifier (LID) associated with the group, and so on. These characteristics are defined at the time of the group creation. The interested reader may look up the 'MCMemberRecord' attribute in the IB architecture specification [IB_ARCH] for the complete list of characteristics that define a group.
マルチキャストグループは、SMに参加要求を送信することにより作成されます。後で説明するように、IBAはマルチキャストグループに参加するための複数のモードを定義します。サブネットマネージャーは、グループのマルチキャストGIDと関連する特性を記録します。グループの特性は、グループパスMTUによって定義されます。これは、グループが生データグラムまたは信頼できないデータグラム、サービスレベル、グループに関連付けられたパーティションキー、グループに関連付けられたローカル識別子（蓋）などに使用されるかどうかにかかわらず定義されます。。これらの特性は、グループの作成時に定義されます。興味のある読者は、グループを定義する特性の完全なリストについて、IBアーキテクチャ仕様[IB_ARCH]の「MCMEMBERRECORD」属性を調べることができます。
A LID is associated with the multicast group by the SM at the time of the multicast group creation. The SM determines the multicast tree based on all the group members and programs the relevant switches. The Multicast LID (MLID) is used by the switches to route the packets.
蓋は、マルチキャストグループの作成時にSMによってマルチキャストグループに関連付けられています。SMは、すべてのグループメンバーに基づいてマルチキャストツリーを決定し、関連するスイッチをプログラムします。マルチキャスト蓋（MLID）は、スイッチによってパケットをルーティングするために使用されます。
Any member IB port wanting to participate in the multicast group must join the group. As part of the join operation, the node receives the group characteristics from the SM. At the same time, the subnet manager ensures that the requester can indeed participate in the group by verifying that it can support the group MTU and its accessibility to the rest of the group members. Other group characteristics may need verification too.
マルチキャストグループに参加したいメンバーIBポートは、グループに参加する必要があります。結合操作の一部として、ノードはSMからグループ特性を受信します。同時に、サブネットマネージャーは、グループMTUと他のグループメンバーへのアクセシビリティをサポートできることを確認することにより、リクエスターが実際にグループに参加できることを保証します。他のグループの特性も検証が必要になる場合があります。
The SM, for groups that span IB subnet boundaries, must interact with IB routers to determine the presence of this group in other IB subnets. If present, the MTU must match across the IB subnets.
IBサブネット境界にまたがるグループのSMは、IBルーターと相互作用して、他のIBサブネットにおけるこのグループの存在を決定する必要があります。存在する場合、MTUはIBサブネット全体で一致する必要があります。
P_Key is another characteristic that must match across IB subnets since the P_Key inserted into a packet is not modified by the IB switches or IB routers. Thus, if the P_Keys did not match the IB router(s) itself might drop the packets or destinations on other subnets might drop the packets.
P_KEYは、パケットに挿入されたP_KEYがIBスイッチまたはIBルーターによって変更されないため、IBサブネット間で一致する必要があるもう1つの特性です。したがって、p_keysがIBルーター自体と一致しなかった場合、他のサブネットのパケットまたは宛先がパケットをドロップする可能性があります。
A join operation may cause the SM to reprogram the fabric so that the new member can participate in the multicast group. By the same token, a leave may cause the SM to reprogram the fabric to stop forwarding the packets to the requester.
結合操作により、SMがファブリックを再プログラムして、新しいメンバーがマルチキャストグループに参加できるようにする場合があります。同様に、休暇をとると、SMが生地を再プログラムすると、パケットの転送を要求者に停止させる可能性があります。
The multicast group is maintained by the SM with each of the group members represented by an MCMemberRecord [IB_ARCH]. Some of its components are the following:
マルチキャストグループは、MCMemberRecord [IB_ARCH]で表される各グループメンバーとともにSMによって維持されます。そのコンポーネントの一部は次のとおりです。
MGID - Multicast GID for this multicast group PortGID - Valid GID of the port joining this multicast group Q_Key - Q_Key to be used by this multicast group MLID - Multicast LID for this multicast group MTU - MTU for this multicast group P_Key - Partition key for this multicast group SL - Service level for this multicast group Scope - Same as MGID address scope JoinState - Join/Leave status requested by the port: bit 0: FullMember bit 1: NonMember bit 2: SendOnlyNonMember
MGID-このマルチキャストグループPortgidのマルチキャストGID-このマルチキャストグループQ_Keyに参加するポートの有効なGID -Q_KeyこのマルチキャストグループMTUのマルチキャスト蓋 - このマルチキャストグループP_KEY -KEY -Partition KeyマルチキャストグループSL-このマルチキャストグループスコープのサービスレベル-MGIDアドレススコープJOINSTATE -JOIN/LEAVEステータス要求：ビット0：フルメンバービット1：ノンメンバービット2：SendOnlyNonMember
The JoinState indicates the membership qualities a port wishes to add while joining/creating a group or delete when leaving a group. The meaning of the JoinState bits are as follows:
JoinStateは、グループに参加/作成する際にポートが追加したいメンバーシップの品質を示します。JoinStateビットの意味は次のとおりです。
FullMember: Messages destined for the group are routed to and from the port. A group may be deleted by the SM if there are no FullMembers in the group.
FullMember：グループ向けのメッセージは、ポートとの間でルーティングされます。グループにフルメンバーがいない場合、グループはSMによって削除される場合があります。
NonMember: Messages destined for the group are routed to and from the port. The port is not considered a member for purposes of group creation/deletion.
非会員：グループ向けのメッセージは、ポートとの間でルーティングされます。ポートは、グループの作成/削除の目的でメンバーとは見なされません。
SendOnlyNonMember: Group messages are only routed from the port but not to the port. The port is not considered a member for purposes of group creation/deletion.
sendonlynonmember：グループメッセージは、ポートからのみルーティングされますが、ポートにはルーティングされません。ポートは、グループの作成/削除の目的でメンバーとは見なされません。
A port may have multiple bits set in its record. In such a case, the membership qualities are a union of the JoinStates. A port may leave the multicast group for each of the JoinStates individually or in any combination of JoinState bits [IB_ARCH].
ポートには、記録に複数のビットが設定される場合があります。そのような場合、メンバーシップの品質はJoinStatesの連合です。ポートは、各JoinStateのマルチキャストグループを個別に、またはJoinStateビット[IB_ARCH]の任意の組み合わせで残す場合があります。
An IB port joins a multicast group by sending a join request (SubnAdmSet() method) and leaves a multicast group by sending a leave message (SubnAdmDelete() method) to the SM. The IBA specification [IB_ARCH] describes the methods and attributes to be used when sending these messages.
IBポートは、Join Request（subnadmset（）メソッド）を送信することによりマルチキャストグループに参加し、leaveメッセージ（subnadmdelete（）メソッド）をSMに送信してマルチキャストグループを残します。IBA仕様[IB_ARCH]は、これらのメッセージを送信するときに使用するメソッドと属性について説明します。
There is no 'create' command to form a new multicast group. The FullMember bit in the JoinState must be set to create a multicast group. In other words, the first FullMember join request will cause the group to be created as a side effect of the join request. Subsequent join or leave requests may contain any combination of the JoinState bits.
新しいマルチキャストグループを形成する「作成」コマンドはありません。JoinStateのフルメンバービットは、マルチキャストグループを作成するために設定する必要があります。言い換えれば、最初のFullMember Joinリクエストにより、グループは参加リクエストの副作用として作成されます。後続の結合または休暇リクエストには、JoinStateビットの任意の組み合わせが含まれる場合があります。
The creator of the group specifies the Q_Key, MTU, P_Key, SL, FlowLabel, TClass, and the Scope value. A creator may request that a suitable MGID be created for it. Alternatively, the request can specify the desired MGID. In both cases, the MLID is assigned by the SM.
グループの作成者は、Q_Key、MTU、P_KEY、SL、FlowLabel、TClass、およびScope値を指定します。作成者は、適切なMGIDを作成するように要求する場合があります。または、リクエストは目的のMGIDを指定できます。どちらの場合も、MLIDはSMによって割り当てられます。
Thus, a group will be created with the specified values when the requester sets the FullMember bit and no such group already exists in the subnet.
したがって、要求者がフルメンバービットを設定すると、指定された値でグループが作成され、そのようなグループはすでにサブネットに存在しません。
When the last FullMember leaves the multicast group the SM may delete the multicast group releasing all resources, including those that might exist in the fabric itself, associated with the group.
最後のフルメンバーがマルチキャストグループを離れると、SMは、グループに関連付けられているファブリック自体に存在する可能性のあるリソースを含むすべてのリソースをリリースするマルチキャストグループを削除できます。
Note that a special 'delete' message does not exist. It is a side effect of the last FullMember 'leave' operation.
特別な「削除」メッセージは存在しないことに注意してください。これは、最後のフルメンバー「leave」操作の副作用です。
The SA may be requested by the ports to generate a report whenever a multicast group is created or deleted. The port can specify the multicast group(s) it is interested in by using its MGID or by submitting a wild card request. The SA will report these events using traps 66 (for creates) and 67 (for deletes)[IB_ARCH].
SAは、マルチキャストグループが作成または削除されるたびにレポートを生成するようにポートから要求される場合があります。ポートは、MGIDを使用するか、ワイルドカードリクエストを送信することで、関心のあるマルチキャストグループを指定できます。SAは、トラップ66（作成用）と67（削除用）[IB_ARCH]を使用してこれらのイベントを報告します。
Therefore, a port wishing to join a group but not create it by itself may request a create notification or a port might even request a notification for all groups that are created (a wild card request). The SA will diligently inform them of the creation utilizing the aforementioned traps. The requester can then join the multicast group indicated. Similarly, a SendOnlyNonMember or a NonMember might request the SA to inform it of group deletions. The endnode, on receiving a delete report, can safely release the resources associated with the group. The associated MLID is no longer valid for the group and may be reassigned to a new multicast group by the SM.
したがって、グループに参加したいが、それを作成しないポートは、作成通知を作成するか、ポートが作成されたすべてのグループの通知を要求する場合があります（ワイルドカードリクエスト）。SAは、前述のトラップを利用して作成を熱心に通知します。リクエスターは、示されているマルチキャストグループに参加できます。同様に、SendonlynonMemberまたは非会員は、SAにグループの削除を通知するように要求する場合があります。Endnodeは、削除レポートを受信すると、グループに関連付けられたリソースを安全にリリースできます。関連するMLIDは、グループに対して有効でなく、SMによって新しいマルチキャストグループに再割り当てされる場合があります。
To aid in the monitoring and configuration of InfiniBand subnet components, a set of MIB modules needs to be defined. MIB modules are needed for the channel adapters, InfiniBand interfaces, InfiniBand subnet manager, and InfiniBand subnet management agents and to allow the management of specific device properties. It must be noted that the management objects addressed in the IPoIB documents are for all of the IB subnet components and are not limited to IP (over IB). The relevant MIB modules are described in separate documents and are not covered here.
Infiniband SubNetコンポーネントの監視と構成を支援するには、MIBモジュールのセットを定義する必要があります。MIBモジュールは、チャネルアダプター、Infiniband Interfaces、Infiniband Subnet Manager、およびInfiniband Subnet管理エージェントに必要であり、特定のデバイスプロパティの管理を可能にします。IPOIBドキュメントでアドレス指定された管理オブジェクトは、すべてのIBサブネットコンポーネントのものであり、IP（IBを超える）に限定されないことに注意する必要があります。関連するMIBモジュールは、個別のドキュメントで説明されており、ここではカバーされていません。
As described in section 1.0, the InfiniBand architecture provides a broad set of capabilities to choose from when implementing IP over InfiniBand networks.
セクション1.0で説明されているように、Infinibandアーキテクチャは、IPを介してIPを実装するときに選択できる幅広い機能を提供します。
The IPoIB specification must not, and does not, require changes in IP and higher-layer protocols. Nor does it mandate requirements on IP stacks to implement special user-level programs. It is an aim of IPoIB specification that the IPoIB changes be amenable to modularization and incorporation into existing implementations at the same level as other media types.
IPOIB仕様は、IPおよび高層プロトコルの変更を必要としないはずです。また、特別なユーザーレベルプログラムを実装するために、IPスタックの要件を義務付けていません。IPOIBの変更は、他のメディアタイプと同じレベルで既存の実装へのモジュール化と組み込みに適していることをIPOIB仕様の目的です。
InfiniBand architecture provides multiple methods of data exchange between two endpoints as was noted above. These are the following:
Infinibandアーキテクチャは、上記の2つのエンドポイント間のデータ交換の複数の方法を提供します。これらは次のとおりです。
Reliable Connected (RC) Reliable Datagram (RD) Unreliable Connected (UC) Unreliable Datagram (UD) Raw Datagram : Raw IPv6 (R6) : Raw Ethertype (RE)
信頼できる接続（RC）信頼性のあるデータグラム（RD）信頼性のない接続（UC）信頼性のないデータグラム（UD）RAWデータグラム：RAW IPv6（R6）：RAW ETHERTYPE（RE）
IPoIB can be implemented over any, multiple, or all of these services. A case can be made for support on any of the transport methods depending on the desired features.
IPOIBは、これらのサービスのすべて、複数、またはすべてにわたって実装できます。目的の機能に応じて、輸送方法のいずれかをサポートするためにケースを作成できます。
The IB specification requires Unreliable Datagram mode to be supported by all the IB nodes. The host channel adapters (HCAs) are specifically required to support Reliable connected (RC) and Unreliable connected (UC) modes but the same is not the case with target channel adapters (TCAs). Support for the two Raw Datagram modes is entirely optional. The Raw Datagram mode supports a 16-bit Cyclic Redundancy Check (CRC) as compared to the better protection provided by the use of a 32-bit CRC in other modes.
IB仕様では、すべてのIBノードによってサポートされるために信頼性の低いデータグラムモードが必要です。ホストチャネルアダプター（HCA）は、信頼性の高い接続（RC）および信頼性のない接続（UC）モードをサポートするために特に必要ですが、ターゲットチャネルアダプター（TCAS）でも同じことはそうではありません。2つの生データグラムモードのサポートは完全にオプションです。生データグラムモードは、他のモードで32ビットCRCを使用することで提供されるより良い保護と比較して、16ビット環状冗長チェック（CRC）をサポートします。
For the sake of simplicity, ease of implementation and integration with existing stacks, it is desirable that the fabric support multicasting. This is possible only in Unreliable datagram (UD) and IB's Raw datagram modes.
簡単にするために、既存のスタックとの実装の容易さ、統合のために、ファブリックがマルチキャストをサポートすることが望ましいです。これは、信頼性の低いデータグラム（UD）およびIBの生データグラムモードでのみ可能です。
Thus, it is only the UD mode that is universal, supports multicast, and supports a robust CRC. Given these conditions it is the obvious choice for IP over InfiniBand [RFC4391].
したがって、普遍的で、マルチキャストをサポートし、堅牢なCRCをサポートするのはUDモードのみです。これらの条件を考えると、それはインフィニバンドよりもIPの明らかな選択です[RFC4391]。
Future documents might consider the connected modes. In contrast to the limited link MTU offered by UD mode, the connected modes can offer significant benefit in terms of performance by utilizing a larger MTU. Reliability is also enhanced if the underlying feature of automatic path migration of connected modes is utilized.
将来のドキュメントは、接続されたモードを考慮するかもしれません。UDモードで提供される限られたリンクMTUとは対照的に、接続されたモードは、より大きなMTUを利用することにより、パフォーマンスの面で大きな利点を提供できます。接続されたモードの自動パス移行の基本的な特徴が利用されると、信頼性が向上します。
InfiniBand specification makes support of multicasting in the switches optional. Multicast however, is a basic requirement in IP networks. Therefore, IPoIB requires that multicast-capable InfiniBand fabrics be used to implement IPoIB subnets.
Infiniband仕様により、スイッチのマルチリキャストがオプションでサポートされます。ただし、マルチキャストは、IPネットワークの基本的な要件です。したがって、IPOIBでは、マルチキャスト対応のインフィニバンドファブリックを使用してIPOIBサブネットを実装する必要があります。
Well-known IP multicast groups are defined for both IPv4 and IPv6 [IANA, RFC3513]. Multicast groups may also be dynamically created at any time. To avoid creating unnecessary duplicates of multicast packets in the fabric, and to avoid unnecessary handling of such packets at the hosts, each of the IP multicast groups needs to be associated with a different IB multicast group as far as possible. A process is defined in [RFC4391] for mapping the IP multicast addresses to unique IB multicast addresses.
よく知られているIPマルチキャストグループは、IPv4とIPv6の両方で定義されています[IANA、RFC3513]。マルチキャストグループは、いつでも動的に作成できます。ファブリックにマルチキャストパケットの不必要な重複を作成しないようにし、ホストでのそのようなパケットの不必要な処理を避けるために、各IPマルチキャストグループは、可能な限り異なるIBマルチキャストグループに関連付ける必要があります。IPマルチキャストアドレスを一意のIBマルチキャストアドレスにマッピングするために、プロセスは[RFC4391]で定義されています。
The IB specification describes the flag bits as discussed in section 1.2. The IB specification also defines some well-known IB MGIDs. The MGIDs are reserved for the IB's Raw Datagram mode which is incompatible with the other transports of IB. Any mapping that is defined from IP multicast addresses therefore must not fall into IB's definition of a well-known address.
IB仕様では、セクション1.2で説明したフラグビットについて説明します。IB仕様は、いくつかのよく知られているIB MGIDも定義します。MGIDSは、IBの他のトランスポートと互換性のあるIBのRAWデータグラムモードに予約されています。したがって、IPマルチキャストアドレスから定義されているマッピングは、よく知られているアドレスのIBの定義に該当してはなりません。
Therefore all IPoIB related multicast GIDs always set the transient bit.
したがって、すべてのIPOIB関連のマルチキャストGIDは、常に過渡ビットを設定します。
Some implementations may wish to support multiple clusters of machines in their own IB subnets but otherwise be part of a common IP subnet. For such a solution, the IB specification needs multiple upgrades. Some of the required enhancements are as follows:
いくつかの実装では、独自のIBサブネットで複数のマシンのクラスターをサポートしたい場合がありますが、それ以外の場合は共通のIPサブネットの一部になります。このようなソリューションでは、IB仕様には複数のアップグレードが必要です。必要な拡張機能の一部は次のとおりです。
1) A method for creating IB multicast GIDs that span multiple IB subnets. The partition keys and other parameters need to be consistent across IB subnets.
1) 複数のIBサブネットにまたがるIBマルチキャストGIDを作成する方法。パーティションキーやその他のパラメーターは、IBサブネット間で一貫性を保つ必要があります。
2) Develop IB routing protocol to determine the IB topology across IB subnets.
2) IBルーティングプロトコルを開発して、IBサブネット全体のIBトポロジを決定します。
3) Define the process and protocols needed between IB nodes and IB routers.
3) IBノードとIBルーターの間で必要なプロセスとプロトコルを定義します。
Until the above conditions are met, it is not possible to implement IPoIB subnets that span IB subnets. The IPoIB standards have however, been defined with this possibility in mind.
上記の条件が満たされるまで、IBサブネットにまたがるIPOIBサブネットを実装することはできません。ただし、IPOIB規格は、この可能性を念頭に置いて定義されています。
The IPoIB subnet is overlaid over the IB subnet. The IPoIB subnet is brought up in the following steps: Note: the join/leave operation at the IP level will be referred to as IP_join/IP_leave and the join/leave operations at the IB level will be referred to as IB_join in this document.
IPOIBサブネットは、IBサブネット上でオーバーレイされます。IPOIBサブネットは次の手順で育てられます。注：IPレベルでの結合/休暇操作はIP_JOIN/IP_LEAVEと呼ばれ、IBレベルでのJOIN/LEAVE操作はこのドキュメントでIB_JOINと呼ばれます。
1. The all-IPoIB nodes IB multicast group is created
1. All-IpoibノードIBマルチキャストグループが作成されます
The fabric administrator creates an IB multicast group (henceforth called 'broadcast group') when the IP subnet is set up. The 'broadcast group' is defined in [RFC4391]. The method by which the broadcast group is setup is not defined by IPoIB. The group may be setup at the SM by the administrator or by the first IB_join.
ファブリック管理者は、IPサブネットが設定されているときにIBマルチキャストグループ（以降「ブロードキャストグループ」と呼ばれる）を作成します。「放送グループ」は[RFC4391]で定義されています。ブロードキャストグループが設定される方法は、IPOIBによって定義されていません。グループは、管理者または最初のIB_JOINによってSMでセットアップされる場合があります。
As noted earlier, at the time of creating an IB multicast group, multiple values such as the P_Key, Q_Key, Service Level, Hop Limit, Flow ID, TClass, MTU, etc. have to be specified. These values should be such that all potential members of the IB multicast group are able to communicate with one another when using them. In the future, as the IB specification associates more meaning with the various parameters and defines IB Quality of Service (QoS), different values for IP multicast traffic may be possible. All unicast packets also need to use the P_Key and Q_Key specified in the broadcast group [RFC4391]. It is obvious that a thought out configuration is required for a successful setup of the IPoIB subnet.
前述のように、IBマルチキャストグループの作成時には、P_KEY、Q_KEY、サービスレベル、ホップ制限、フローID、TCLASS、MTUなどの複数の値を指定する必要があります。これらの値は、IBマルチキャストグループのすべての潜在的なメンバーが、それらを使用するときに互いに通信できるようにする必要があります。将来的には、IB仕様がさまざまなパラメーターとより多くの意味を関連付け、IBの品質（QOS）を定義するため、IPマルチキャストトラフィックの異なる値が可能になる場合があります。すべてのユニキャストパケットは、ブロードキャストグループ[RFC4391]で指定されたP_KEYとQ_KEYを使用する必要があります。IPOIBサブネットのセットアップを成功させるには、検討された構成が必要であることは明らかです。
2. All IPoIB interfaces IB_join the broadcast group
2. すべてのIPOIBインターフェイスIB_JOINブロードキャストグループ
The broadcast group defines the span and the members of the IPoIB link. This link gets built up as IPoIB nodes IB_join the broadcast group.
ブロードキャストグループは、IPOIBリンクのスパンとメンバーを定義します。このリンクは、IPOIBノードIB_JOINとしてブロードキャストグループのJOINとして構築されます。
The IB_join to the broadcast group has the additional benefit of distributing the above mentioned multicast group parameters to all the members of the subnet.
放送グループへのIB_JOINには、上記のマルチキャストグループパラメーターをサブネットのすべてのメンバーに配布するという追加の利点があります。
Note that this IB_join to the broadcast group is a FullMember join. If any of the ports or the switches linking the port to the rest of the IPoIB subnet cannot support the parameters (e.g., path MTU or P_Key) associated with the broadcast group, then the IB_join request will fail and the requesting port will not become part of the IPoIB subnet.
このIB_JOINへのこのIB_JOINは、フルメンバーの結合であることに注意してください。ポートをIPOIBサブネットの残りの部分にリンクするポートまたはスイッチのいずれかが、ブロードキャストグループに関連付けられたパラメーター（PATH MTUまたはP_KEYなど）をサポートできない場合、IB_JOINリクエストは失敗し、リクエストポートは一部になりません。IPOIBサブネットの。
3. Configuration Parameters
3. 構成パラメーター
As noted above, parameters such as Q_Key and Path MTU, which are needed for all IPoIB communication, are returned to the IPoIB node on IB_joining the 'broadcast group'. [RFC4391] also notes that the parameters used in the broadcast group are used when creating other multicast groups.
上記のように、すべてのIPOIB通信に必要なQ_KeyやPATH MTUなどのパラメーターは、「ブロードキャストグループ」をJOININGINGINGINGINGINGINGINGINGingでIB_に戻すことができます。[RFC4391]は、他のマルチキャストグループを作成する際に放送グループで使用されるパラメーターが使用されることも指摘しています。
However, the P_Key must still be known to the IPoIB endnode before it can join the broadcast group. The P_Key is included in the mapping of the broadcast group [RFC4391]. Another parameter, the scope of the broadcast group, also needs to be known to the endnode before it can join the broadcast group. It is an implementation choice on how the P_Key and the scope bits related to the IPoIB subnet are determined by the implementation. These could be configuration parameters initialized by some means by the administrator.
ただし、P_KEYは、ブロードキャストグループに参加する前に、IPOIBエンドノードにまだ知られている必要があります。P_KEYは、ブロードキャストグループ[RFC4391]のマッピングに含まれています。別のパラメーターであるブロードキャストグループの範囲は、ブロードキャストグループに参加する前に、エンドノードにも既知の必要があります。これは、IPOIBサブネットに関連するP_KEYおよびスコープビットが実装によってどのように決定されるかについての実装の選択肢です。これらは、管理者によって何らかの手段によって初期化された構成パラメーターである可能性があります。
The methods employed by an implementation to determine the P_Key and scope bits are not specified by IPoIB.
P_KEYおよびスコープビットを決定するために実装によって採用されている方法は、IPOIBで指定されていません。
The endpoints in an IB subnet must have compatible P_Keys to communicate with one another. Thus, the administrator when setting up an IP subnet over an IB subnet must ensure that all the members have compatible P_Keys. An IP subnet can have only one P_Key associated with it to ensure that all IP nodes in it can talk to one another. An endpoint may, however, have multiple P_Keys.
IBサブネットのエンドポイントには、相互に通信するための互換性のあるp_keysが必要です。したがって、IBサブネットを介してIPサブネットを設定するときの管理者は、すべてのメンバーが互換性のあるP_Keysを持っていることを確認する必要があります。IPサブネットは、それに関連付けられた1つのp_keyのみを持つことができ、その中のすべてのIPノードが互いに通信できるようにします。ただし、エンドポイントには複数のp_keysがあります。
The IB architecture specifies that there can be only one MGID associated with a multicast group in the IB subnet. The P_Key is included in the MGID mappings from the IP multicast addresses [RFC4391]. Since the P_Key is unique in the IB subnet, the inclusion of the P_Key in the IB MGIDs ensures that unique MGID mappings are created. Every unique broadcast group MGID so formed creates a separate abstract IPoIB link and hence an IPoIB VLAN.
IBアーキテクチャは、IBサブネットのマルチキャストグループに関連付けられたMGIDは1つだけであることを指定しています。P_KEYは、IPマルチキャストアドレス[RFC4391]のMGIDマッピングに含まれています。P_KeyはIBサブネットでユニークであるため、IB MGIDにP_KEYを含めると、一意のMGIDマッピングが作成されます。So Formedが形成されたすべてのユニークな放送グループMGIDは、個別の抽象IPOIBリンクを作成し、IPOIB VLANを作成します。
IP multicast on InfiniBand subnets follows the same concepts and rules as on any other media. However, unlike most other media multicast over InfiniBand requires interaction with another entity, the IB subnet manager. This section describes the outline of the process and suggests some guidelines.
InfinibandサブネットのIPマルチキャストは、他のメディアと同じ概念とルールに従います。ただし、他のほとんどのメディアマルチキャストとは異なり、Infinibandには別のエンティティであるIB Subnet Managerとのやり取りが必要です。このセクションでは、プロセスの概要について説明し、いくつかのガイドラインを提案します。
IB architecture specifies the following format for IB multicast packets when used over Unreliable Datagram (UD) mode:
IBアーキテクチャは、信頼性の低いデータグラム（UD）モードで使用される場合、IBマルチキャストパケットの次の形式を指定します。
+--------+-------+---------+---------+-------+---------+---------+
|Local |Global |Base |Datagram |Packet |Invariant| Variant |
|Routing |Routing|Transport|Extended |Payload| CRC | CRC |
|Header |Header |Header |Transport| (IP) | | |
| | | |Header | | | |
+--------+-------+---------+---------+-------+---------+---------+
For details about the various headers please refer to InfiniBand Architecture Specification [IB_ARCH].
さまざまなヘッダーの詳細については、infinibandアーキテクチャの仕様[IB_ARCH]を参照してください。
The Global Routing Header (GRH) includes the IB multicast group GID. The Local Routing Header (LRH) includes the Local Identifier (LID). The IB switches in the fabric route the packet based on the LID.
グローバルルーティングヘッダー（GRH）には、IBマルチキャストグループGIDが含まれています。ローカルルーティングヘッダー（LRH）には、ローカル識別子（蓋）が含まれます。IBは、蓋に基づいてパケットを布地ルートに切り替えます。
The GID is made available to the receiving IB user (the IPoIB interface driver for example). The driver can therefore determine the IB group the packet belongs to.
GIDは、受信IBユーザー（たとえばIPOIBインターフェイスドライバー）が利用できるようになります。したがって、ドライバーは、パケットが属するIBグループを決定できます。
IPv4 defines three levels of multicast conformance [RFC1112].
IPv4は、3つのレベルのマルチキャスト適合性を定義します[RFC1112]。
Level 0: No support for IP multicasting
レベル0：IPマルチキャストのサポートはありません
Level 1: Support for sending but not receiving multicasts
レベル1：送信のサポートがマルチキャストを受け取っていない
Level 2: Full support for IP multicasting
レベル2：IPマルチキャストの完全なサポート
In IPv6, there is no such distinction. Full multicast support is mandatory. In addition, all IPv4 subnets support broadcast (255.255.255.255). IPv4 broadcast can always be sent/received by all IPv4 interfaces.
IPv6では、そのような区別はありません。完全なマルチキャストサポートが必須です。さらに、すべてのIPv4サブネットはブロードキャスト（255.255.255.255）をサポートしています。IPv4ブロードキャストは、すべてのIPv4インターフェイスによっていつでも送信/受信できます。
Every IPoIB subnet requires the broadcast GID to be defined. Thus, a packet can always be broadcast.
すべてのIPOIBサブネットでは、ブロードキャストGIDを定義する必要があります。したがって、パケットはいつでもブロードキャストできます。
An IP host may send a multicast packet at any time to any multicast address.
IPホストは、マルチキャストアドレスにいつでもマルチキャストパケットを送信できます。
The IP layer conveys the multicast packet to the IPoIB interface driver/module. This module attempts to IB_join the relevant IB multicast group. This is required since otherwise InfiniBand architecture does not guarantee that the packet will reach its destinations.
IPレイヤーは、マルチキャストパケットをIPOIBインターフェイスドライバー/モジュールに伝えます。このモジュールは、関連するIBマルチキャストグループをIB_JOINしようとします。それ以外の場合は、Infiniband Architectureがパケットが目的地に到達することを保証しないため、これが必要です。
A pure sender may choose to join the multicast group as a FullMember. In such a case, the sender will receive all the multicast packets transmitted to the IB group. In addition, the IB group will not be deleted until the sender leaves the group.
純粋な送信者は、マルチキャストグループにフルメンバーとして参加することを選択できます。そのような場合、送信者はIBグループに送信されるすべてのマルチキャストパケットを受け取ります。さらに、送信者がグループを離れるまでIBグループは削除されません。
Alternatively, a sender might IB_join as a SendOnlyNonMember. In such a case, the packets are not routed to the sender though packets transmitted by it can reach the other group members. In addition, the group can be deleted when all FullMembers have left the group. The sender can further request delete updates from the SM.
あるいは、送信者はsendonlynonmemberとしてIB_JOINを使用する場合があります。そのような場合、パケットは送信者にルーティングされませんが、それによって送信されたパケットは他のグループメンバーに届く可能性があります。さらに、すべてのフルメンバーがグループを去ったときに、グループを削除できます。送信者は、SMからの削除更新をさらに要求できます。
If the sender does not find the group in existence, it is recommended in [RFC4391] that the packets be sent to the MGID corresponding to the all-IP routers address. A sender could also send the packets to the broadcast group. The sender might also choose to request 'creation' reports from the SM.
送信者が存在しているグループを見つけられない場合、[RFC4391]では、パケットをAll-IPルーターアドレスに対応するMGIDに送信することをお勧めします。送信者は、パケットをブロードキャストグループに送信することもできます。送信者は、SMから「作成」レポートを要求することも選択できます。
The IP host must join the IB multicast group corresponding to the IP address. This follows from the IBA requirement that the receiver must join the relevant IB multicast group. The group is automatically created if it does not exist [IB_ARCH].
IPホストは、IPアドレスに対応するIBマルチキャストグループに参加する必要があります。これは、Receiverが関連するIBマルチキャストグループに参加する必要があるというIBA要件から続きます。グループが存在しない場合、グループは自動的に作成されます[IB_ARCH]。
The IP receivers must IB_leave the IB group when the IP layer stops listening of the corresponding IP address. The SM can then choose to delete the group.
IPレイヤーが対応するIPアドレスのリスニングを停止したとき、IPレシーバーはIBグループをIBグループにリーブする必要があります。SMは、グループを削除することを選択できます。
IP routers know of the new IP groups created in the subnet by the use of protocols such as Internet Group Management Protocol (IGMPv3) / Multicast Listener Discovery (MLD) [RFC3376, RFC2710]. However, this is not enough for IPoIB since the router needs to IB_join the relevant IB groups to be able to receive and transmit the packets. There is no promiscuous mode for listening to all packets.
IPルーターは、インターネットグループ管理プロトコル（IGMPV3） /マルチキャストリスナーディスカバリー（MLD）[RFC3376、RFC2710]などのプロトコルを使用することにより、サブネットで作成された新しいIPグループを知っています。ただし、パケットを受け取って送信できるように、関連するIBグループをIB_JOINする必要があるため、IPOIBにとってこれは十分ではありません。すべてのパケットを聞くための無差別モードはありません。
The IPoIB routers therefore need to request the SM to report all creations of IB groups in the fabric. The IPoIB router can then IB_join the reported group. It is not desirable that the router's IB_joining of a multicast group be considered the same as the IB_join from a receiver -- the router's IB_join should not disallow the group's deletion when all receivers leave. To overcome just this type of situation, IBA provides the NonMember IB_join mode.
したがって、IPOIBルーターは、SMにIBグループのすべての作品を生地内のすべての作成者に報告するように要求する必要があります。IPOIBルーターは、報告されたグループをib_joinできます。マルチキャストグループのルーターのIB_JOINGINGがレシーバーからのIB_JOINと同じと見なされることは望ましくありません。ルーターのIB_JOINは、すべての受信機が出発するときにグループの削除を許可してはなりません。このタイプの状況を克服するために、IBAは非会員IB_JOINモードを提供します。
The NonMember IB_join mode can be used by IP routers when they join in response to the create reports. A router should ideally request the delete reports too so that it can release all the resources associated with the group. The MLID associated with a deleted MGID can be reassigned by the SM, and therefore there is a possibility of erroneous transmissions if the MLID is cached. A router that does not request delete reports will still work correctly since it will receive the correct MLID , and purge any old cached value, when it IB_joins the IB group in response to a create report.
非会員IB_JOINモードは、CREATEレポートに応じて結合するときにIPルーターで使用できます。ルーターは、グループに関連付けられたすべてのリソースをリリースできるように、削除レポートを理想的にリクエストする必要があります。削除されたMGIDに関連付けられたMLIDは、SMによって再割り当てされる可能性があるため、MLIDがキャッシュされている場合、誤った送信の可能性があります。削除レポートを要求しないルーターは、正しいMLIDを受信し、作成するレポートに応じてIBグループをJoinsにすると、古いキャッシュ値をパージするため、正しく機能します。
It is reasonable for a router to IB_join as a FullMember if it is joining the IB group in response to an application/routing daemon request. In such a case, the router might end up controlling the existence of the IB group (since it is a FullMember of the group).
アプリケーション/ルーティングデーモンリクエストに応じてIBグループに参加している場合、IB_JOINのルーターがフルメンバーとして合理的です。そのような場合、ルーターはIBグループの存在を制御する可能性があります（グループのフルメンバーであるため）。
An HCA or TCA may have a limit on the number of MGIDs it can support. Thus, even though the groups may not be limited at the subnet manager and in the subnet as such, they may be limited at a particular interface. It is advisable to choose an adequately provisioned HCA/TCA when setting up an IPoIB subnet.
HCAまたはTCAは、サポートできるMGIDの数に制限がある場合があります。したがって、グループはサブネットマネージャーやサブネットで制限されていない場合でも、特定のインターフェイスで制限される場合があります。IPOIBサブネットをセットアップするときに、適切にプロビジョニングされたHCA/TCAを選択することをお勧めします。
An IPv4 sender (level 1 compliance) IB_joins the IB multicast group only because that is the only way to guarantee reception of the packets by all the group recipients. The sender must, however, IB_leave the group at some time. A sender could, when not a receiver on the group, start a timer per multicast group sent to. The sender leaves the IB group when the timer goes off. It restarts the timer if another message is sent.
IPv4 Sender（レベル1コンプライアンス）IB_は、IBマルチキャストグループをjoinsにします。これは、すべてのグループ受信者によるパケットの受信を保証する唯一の方法であるためです。ただし、送信者は、ある時点でIB_Leaveグループを使用する必要があります。送信者は、グループのレシーバーではない場合、送信されるマルチキャストグループごとにタイマーを開始できます。送信者は、タイマーがオフになったときにIBグループを離れます。別のメッセージが送信された場合、タイマーを再起動します。
This suggestion does not apply to the IB broadcast group. It also does not apply to the IB group corresponding to the all-hosts multicast group. An IPv4 host must always remain a member of the broadcast group.
この提案は、IBブロードキャストグループには適用されません。また、全ホストマルチキャストグループに対応するIBグループにも適用されません。IPv4ホストは、常にブロードキャストグループのメンバーである必要があります。
An IP multicast receiver IB_leaves the corresponding IB multicast group when it IP_leaves the IP multicast group. In the case of IPv4 implementation, the receiver may choose to continue to be a sender (level 1 compliance), in which case it may choose not to IB_leave the IB group but start a timer as explained above.
IP_Leased IT_Leaves IP Multicast Groupを使用するとき、IPマルチキャストレシーバーIB_Lease対応するIBマルチキャストグループを使用します。IPv4の実装の場合、受信者は送信者（レベル1コンプライアンス）であり続けることを選択できます。この場合、IB_Leaveではなく、上記のようにタイマーを開始することを選択できます。
As noted elsewhere, the SM can choose to free up the resources (e.g., routing entries in the switches) associated with the IB group when the last FullMember IB_leaves the group. The MLID therefore becomes invalid for the group. The MLID can be reassigned when a new group is created.
他の場所で述べたように、SMは、IBグループに関連付けられたリソース（たとえば、スイッチのルーティングエントリ）を最後のFullMember IB_Leavesを解放することを選択できます。したがって、MLIDはグループにとって無効になります。MLIDは、新しいグループが作成されたときに再割り当てすることができます。
SendOnlyNonMember/NonMember ports caching the MLID need to avoid this possibility. The way out is for them to request group delete reports. An IP router requesting reports for all groups need not request the delete report since an IB_join in response to a create report will return the new MLID association to it.
sendonlynonmember/非会員ポートは、この可能性を回避するために必要です。外出方法は、彼らがグループ削除レポートを要求することです。すべてのグループのレポートを要求するIPルーターは、作成レポートに応じてIB_JOINが新しいMLIDアソシエーションを返すため、削除レポートを要求する必要はありません。
A router might prefer to IB_leave the IB multicast group when there are no members of the IP multicast address in the subnet and it has no explicit knowledge of any need to forward such packets.
ルーターは、サブネットにIPマルチキャストアドレスのメンバーがいない場合、IBマルチキャストグループをIBを使用することを好む場合があり、そのようなパケットを転送する必要性について明示的な知識がありません。
The encapsulation of IP packets in InfiniBand is described in [RFC4391].
InfinibandのIPパケットのカプセル化は、[RFC4391]で説明されています。
It specifies the use of an 'Ethertype' value [IANA] in all IPoIB communication packets. The link-layer address is comprised of the GID and the Queue Pair Number (QPN) [RFC4391].
すべてのIPOIB通信パケットで「EtherType」値[IANA]の使用を指定します。リンク層アドレスは、GIDおよびキューペア番号（QPN）[RFC4391]で構成されています。
To enable IPoIB subnets to span across multiple IB-subnets, the specification utilizes the GID as part of the link-layer address. Since all packets in IB have to use the Local Identifier (LID), the address resolution process has the additional step of resolving the destination GID, returned in response to Address Resolution Protocol (ARP) / Neighbor Discover (ND) request, to the LID [RFC4391]. This phase of address resolution might also be used to determine other essential parameters (e.g., the SL, path rate, etc.) for successful IB communication between two peers.
IPOIBサブネットが複数のIBサブネットにまたがることを有効にするために、仕様はGIDをリンク層アドレスの一部として使用します。IBのすべてのパケットはローカル識別子（LID）を使用する必要があるため、アドレス解像度GIDを解決するアドレス解像度GIDを解決する追加のステップがあります。[RFC4391]。アドレス解像度のこのフェーズは、2つのピア間のIB通信を成功させるために、他の重要なパラメーター（例：SL、パスレートなど）を決定するためにも使用できます。
As noted earlier, all communication in the IPoIB subnet derives the Q_Key to use from the Q_Key specified in the broadcast group.
前述のように、IPOIBサブネットのすべての通信は、ブロードキャストグループで指定されたQ_Keyから使用するQ_Keyを導き出します。
RARP entries or static ARP entries are based on invariant link addresses. In the case of IPoIB, the link address includes the QPN, which might not be constant across reboots or even across network interface resets. Therefore, static ARP entries or RARP server entries will only work if the implementation(s) using these options can ensure that the QPN associated with an interface is invariant across reboots/network resets [RFC4391].
RARPエントリまたは静的ARPエントリは、不変のリンクアドレスに基づいています。IPOIBの場合、リンクアドレスにはQPNが含まれています。これは、再起動全体やネットワークインターフェイスリセット全体で一定ではない場合があります。したがって、静的ARPエントリまたはRARPサーバーエントリは、これらのオプションを使用する実装がインターフェイスに関連付けられているQPNが再起動/ネットワークリセット[RFC4391]全体で不変であることを保証できる場合にのみ機能します。
DHCPv4 [RFC2131] utilizes a 'client identifier' field (expected to hold the link-layer address) of 16 octets. The address in the case of IPoIB is 20 octets. To get around this problem, IPoIB specifies [RFC4390] that the 'broadcast flag' be used by the client when requesting an IP address.
DHCPV4 [RFC2131]は、16オクテットの「クライアント識別子」フィールド（リンク層アドレスを保持する予定）を使用します。IPOIBの場合のアドレスは20オクテットです。この問題を回避するために、IPOIBは[RFC4390]を指定します[RFC4390]は、「ブロードキャストフラグ」をIPアドレスを要求するときにクライアントが使用することを指定します。
The IB specification suggests the use of service levels for load balancing, QoS, and deadlock avoidance within an IB subnet. But the IB specification leaves the usage and mode of determination of the SL for the application to decide. The SL and list of SLs are available in the SA, but it is up to the endnode's application to choose the 'right' value.
IB仕様は、IBサブネット内での負荷分散、QoS、およびデッドロック回避にサービスレベルを使用することを示唆しています。しかし、IB仕様は、アプリケーションが決定するためのSLの使用法と決定モードを残します。SLとSLSのリストはSAで利用できますが、「正しい」値を選択するのはEndNodeのアプリケーション次第です。
Every IPoIB implementation will determine the relevant SL value based on its own policy. No method or process for choosing the SL has been defined by the IPoIB standards.
すべてのIPOIB実装は、独自のポリシーに基づいて関連するSL値を決定します。SLを選択する方法やプロセスは、IPOIB標準で定義されていません。
This document describes the IB architecture as relevant to IPoIB. It further restates issues specified in other documents. It does not itself specify any requirements. There are no security issues introduces by this document. IPoIB-related security issues are described in [RFC4391] and [RFC4390].
このドキュメントでは、IBアーキテクチャについてIPOIBに関連するものとして説明しています。さらに、他のドキュメントで指定された問題を修正します。それ自体は要件を指定していません。このドキュメントによって導入されるセキュリティの問題はありません。IPOIB関連のセキュリティの問題は、[RFC4391]および[RFC4390]で説明されています。
This document has benefited from the comments and suggestions of the members of the IPoIB working group and the members of the InfiniBand(SM) Trade Association.
この文書は、IPOIBワーキンググループのメンバーとInfiniband（SM）貿易協会のメンバーのコメントと提案の恩恵を受けています。
[IB_ARCH] InfiniBand Architecture Specification, Volume 1, Release 1.2, October, 2004.
[IB_ARCH] Infiniband Architecture Specification、Volume 1、Release 1.2、2004年10月。
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, April 2006.
[RFC4391] Chu、J。およびV. Kashyap、「IPのIPの伝送（IPOIB）」、RFC 4391、2006年4月。
[RFC4390] Kashyap, V., "Dynamic Host Configuration Protocol (DHCP) over InfiniBand", RFC 4390, April 2006.
[RFC4390] Kashyap、V。、「Infiniband上の動的ホスト構成プロトコル（DHCP）」、RFC 4390、2006年4月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1998年7月。
[IANA] Internet Assigned Numbers Authority, URL http://www.iana.org
[IANA]インターネットが割り当てられた番号局、url http://www.iana.org
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
Author's Address
著者の連絡先
Vivek Kashyap IBM 15450, SW Koll Parkway Beaverton, OR 97006
Vivek Kashyap IBM 15450、SW Koll Parkway Beaverton、または97006
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）によって提供されます。