Network Working Group V. Kashyap
Request for Comments: 4392 IBM
Category: Informational April 2006
IP over InfiniBand (IPoIB) Architecture
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).
著作権（C）インターネット協会（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アーキテクチャの概要を説明します。さらに、インフィニバンドオーバーIPの伝送のための要件とガイドラインについて説明します。明示的に指定しない限り、このドキュメントの議論は、IPv4とIPv6の両方に適用されます。インフィニバンドオーバー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.
インフィニバンド貿易連合（IBTA）は、ベースのチャネルを提供するためにI / Oの仕様を開発するように形成された、ファブリック技術を切り替えます。インフィニバンド規格は、スケーラビリティ、信頼性、可用性、およびデータセンター内のサーバーのパフォーマンスの要件を満たすことを目的としています。
The InfiniBand Trade Association specification is available for download from http://www.infinibandta.org.
インフィニバンドの貿易協会の仕様はhttp://www.infinibandta.orgからダウンロードできます。
For a more complete overview, the reader is referred to chapter 3 of the InfiniBand specification.
より完全な概要については、読者は、インフィニバンド仕様の第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.
インフィニバンド・アーキテクチャ（IBA）は、複数の独立したプロセッサ・プラットフォームを接続する、I / Oプラットフォームのシステムエリアネットワーク（SAN）を定義し、I / Oデバイス。 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ユニットは、（例えばLANアダプタなどの）単一の特定用途向け集積回路（ASIC）IBA-接続デバイスから独立したディスクの大きなメモリが豊富な冗長アレイ（RAID）サブシステムに複雑さの範囲であり得ます。
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サブネットです。この文書では、それぞれ「IBルータ」と「IBサブネット」としてのInfiniBandルータやサブネットを参照します。 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）の方法によってリンクとインタフェースします。アーキテクチャは、ファブリックに接続する1つの以上のポートを提供する各CAの単位ごとに複数のCAをサポートします。各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.
ポートは、データが送信されたエンドポイントです。しかしながら、ポートの各々は、直接リモートピアから対処することができる複数のQP（キュー・ペア）を含むことができます。データ転送の観点から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つの例外があります。パケットがマルチキャストされたときにQPNsは使用されません。 QPNsも生データグラムモードでは使用しません。
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.
ポートは、データパケットに、ローカル識別子（LID）と必要に応じてグローバル識別子（GID）によって識別されます。 IBサブネット間で通信するとき、それは常に含むことができるが、パケット内のGIDは、のみ必要です。
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は、拡張された一意の識別子を表します）。 LIDは、ポートがアクティブになったときに割り当てられた16ビット値です。 GUIDは、ポートの唯一の永続的な識別子です。しかし、それは、パケット内のアドレスとして使用することはできません。接頭辞が変更された場合、GIDが変更されることがあります。サブネットマネージャは、再起動後も一定のLID値を維持しようとするかもしれないが、それは必須ではありません。
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とLIDの割り当ては、サブネットマネージャによって行われます。すべてのIBサブネットは、ファブリックを制御する少なくとも1つのサブネットマネージャのコンポーネントを持っています。それはのLIDと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ルータはIBサブネット間のルートパケットがGIDをに基づいて、構成要素です。このように、IBのサブネット内のパケットは、またはGIDを含んでも含まなくてもよいが、IBサブネット横切るときGIDが含まれている必要があります。サブネット内の宛先が、それによって決定されますので、LIDは、常にパケットで必要とされます。
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ポートは、独自のLIDかのLIDの範囲が割り当てられます。スイッチのポートは、換言すれば、他のエンドノードに対して透明である、のLID / 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が単一の物理リンク内の複数の仮想リンクを作成するためのメカニズムを提供します。すべてのポートは、サブネット管理データグラム専用に予約されているので、IPインフィニバンドオーバー（IPoIBの）議論には関係しませんVL15をサポートしている必要があります。パケットが使用する実際のVLは、スイッチ/チャネルアダプタ表にSMによって構成され、すべてのパケットで指定されたサービスレベル（SL）に基づいて決定されます。 16の可能SLSがあります。
In addition to the features described above viz. QPs, SLs, and addressing (GID/LID), IBA also defines the following:
すなわち上述した特徴に加えて。 QP、のSL、及びアドレッシング（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_Keyを持っをチェック。 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_Keyを持っの少なくとも一つが（すなわち、パケット内P_KEYまたはポートにP_KEY）は「完全メンバーシップ」P_Keyを持っている必要があります。
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はとホストチャネルアダプタ（HCA）（一般的なサービスインタフェース（GSI）Q_Key [IB_ARCH]など）の制御Q_Keysは、消費者が任意に制御Q_Keyを指定することはできませんと考えられています。 QPコンテキストでQ_Keyを使用して制御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によって識別されます。 IPv6は[IB_ARCH]アドレッシングにRFC 2373で定義されているGID形式があります。したがって、ビューのIPv6のオーバーのInfiniBandポイントから、データリンクマルチキャストアドレスは、ネットワークアドレスのように見えます。 IBポートを明示的にマルチキャストパケットを受信するためにSMにリクエストを送信することにより、マルチキャストグループに参加する必要があります。ポートがどのマルチキャストグループにパケットを送信することができます。両方の場合において、マルチキャストLIDがSMから受信されたパケットで使用されます。
There are six methods for data transfer in IB architecture:
IBアーキテクチャにおけるデータ転送のための6つの方法があります。
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よりも大きくすることはできません。
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
信頼できるデータグラム（RD）サービスは、エンド・ツー・エンドの各RD QPが確立EECとの任意のノード上の任意のRD QPと通信することを可能にするコンテキスト（EEC）と呼ばれるノード間の接続を介して多重化されます。複数のQPは、同じを使用することができます
EEC and a single QP can use multiple EECs (one for each remote node per reliable datagram domain).
EECと単一QPは、複数のEEC（信頼性のあるデータグラム・ドメインごとに各リモートノードに対して1つ）を使用することができます。
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でローカルQPを関連付けます。メッセージの長さは2 ^ 31オクテットとして多分として大きなサイズ。 CAの実装では、セグメンテーションとアセンブリの世話をします。
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）サービス関連付け唯一つのリモートQPとつのローカルQP。確認応答ので、紛失または破損したパケットの再送なしはありません。このようなパケットは、したがって、単に廃棄されます。これは、そうでない場合はRCに似ています。
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.
イーサタイプ生データグラムパケットは、CAによって解釈されない一般的なトランスポート・ヘッダを含んでいるが、それは、プロトコルタイプを指定します。イーサタイプのためのIANA（Internet Assigned Numbers Authority）に[IANA]によって定義されるイーサタイプの値は同じです。
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の生のデータグラムサービスを使用して、IBA CAは、（TCP / UDPなど）のIPv6の上の標準的なプロトコル層をサポートすることができます。したがって、ネイティブIPv6パケットは、IBA SANに架橋することができ、ポートに、そのIPv6の生データグラム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のトランスポートと呼ばれます。後者の二つは、生のデータグラムとして分類されます。生のデータグラムパケットにおける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アーキテクチャは、インフィニバンドサブネット構造とGIDの面でのIPv6アーキテクチャから重く借ります。
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.
インフィニバンド・アーキテクチャは、128ビットのユニキャストまたはマルチキャスト識別子としてポートに関連付けられたGIDを定義します。効率的な発見、通信、およびルーティングを容易にするために定義されたいくつかの追加の特性/制約が、RFC 2373 [IB_ARCH]で定義されるようIBAは、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は、明示的に廃止された[RFC3513]である、RFC 2373を指します。なお、IBAアーキテクチャをIPv6アドレスに導入される任意のさらなる変更によって、したがって影響を受けないことに留意しなければなりません。
IBA defines two types of GIDs: unicast and multicast.
ユニキャストおよびマルチキャスト：IBAは、GIDの二種類を定義しています。
The unicast GIDs are defined, as in IPv6, with three scopes. The IB specification states the following:
ユニキャストのGIDは、3つのスコープと、IPv6におけるように、定義されます。 IB仕様は、次のように述べています：
a. link local: FE80/10.
A。ローカルリンク：FE80 / 10。
The IB routers will not forward packets with a link-
local address in source or destination beyond the IB
subnet.
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.
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.
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>
FFxy：<112ビット>
Flag bits:
フラグビット：
The nibble, denoted by x above, are the 4 flag bits: 000T.
000T：上記Xで表さニブルは、4つのフラグビットです。
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
= 0 T：一過性基を表す：永続的に割り当てられ、それは、よく知られているGID T = 1で示し
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
0予約1未指定2リンクローカル3未使用4未割り当て5サイトローカル6未使用7未割り当て8組織ローカル9未割り当て0xAが未割り当て0xB未割り当てから0xC未割り当て0xDの未割り当てから0xEグローバル0xFの予約
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生のIPv6データグラムに適用されることを述べています。これは、マルチキャストグループが単一のマルチキャストグローバル識別子（MGID）に関連付けることができることにも留意しなければなりません。従って同じMGIDはUDモードと生データグラムモードに関連付けることができません。
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.
MGIDを表示によって識別されるIBマルチキャストグループは、SMによって管理されています。 IBは、パケットがパケットの受信を要求するマルチキャストグループのすべてのメンバーによって受信されることを保証するために、ファブリック内のスイッチSMは、明示的にプログラム。 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によって定義され、ローカルグループに関連する識別子（LID）など。これらの特性は、グループの作成時に定義されています。興味のある読者は、グループを定義する特性の完全なリストについては、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.
LIDは、マルチキャストグループの作成時にSMによってマルチキャストグループに関連付けられています。 SMは、すべてのグループメンバーやプログラム関連のスイッチに基づくマルチキャストツリーを決定します。マルチキャストLID（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.
SMは、IBサブネット境界にまたがるグループのために、他の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サブネット間で一致しなければならない別の特徴です。 P_Keyを持っは、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 - このマルチキャストグループQ_Keyに参加ポートの有効なGID - - このマルチキャストグループMTUのためのマルチキャストLID - - このマルチキャストグループMLIDによって使用されるQ_KeyこのマルチキャストグループP_KEYのMTU - このためパーティションキーこのマルチキャストグループPortGIDためのマルチキャストGIDマルチキャストグループのSL - このマルチキャストグループ範囲のサービスレベル - MGIDアドレス範囲JoinStateと同じ - ポートによって要求された/ままの状態に参加：ビット0：FullMemberは、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：グループ宛てのメッセージをポートにしてからルーティングされます。グループにはFullMembersがない場合グループは、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ビット[IB_ARCH]の任意の組み合わせでJoinStatesの各マルチキャストグループを去ることができます。
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ポートは、参加要求（SubnAdmSet（）メソッド）を送信することによりマルチキャストグループに参加し、SMに離脱メッセージ（SubnAdmDelete（）メソッド）を送信することによりマルチキャストグループを去ります。 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ビットは、マルチキャストグループを作成するために設定する必要があります。換言すれば、第1 FullMemberは、要求がグループに参加する要求の副作用として作成されます参加します。それ以降の参加または去る要求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、フローラベル、はTClass、およびスコープ値を指定します。作成者は、適切な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.
リクエスタがFullMemberビットを設定し、そのようなグループが既にサブネット内に存在しない場合したがって、グループは、指定された値を使用して作成されます。
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.
最後FullMemberがマルチキャストグループを離れたときSMは、グループに関連付けられた生地自体に存在するかもしれないものを含め、すべてのリソースを、解放するマルチキャストグループを削除することができます。
Note that a special 'delete' message does not exist. It is a side effect of the last FullMember 'leave' operation.
特別な「削除」のメッセージが存在しないことに注意してください。それは最後のFullMember「休暇」操作の副作用です。
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を要求することがあります。エンドノードは、削除の報告を受けた上で、安全グループに関連付けられているリソースを解放することができます。関連する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.
インフィニバンド・サブネットコンポーネントの監視および構成を支援するために、MIBモジュールのセットが定義される必要があります。 MIBモジュールは、チャネルアダプタ、インフィニバンド・インターフェース、インフィニバンド・サブネット管理、およびインフィニバンドサブネット管理エージェントと特定のデバイスプロパティの管理を可能にするために必要とされます。 IPoIBの文書で対処管理オブジェクトは、IBサブネットのすべてのコンポーネントのためのものであり、（IB以上）IPに限定されるものではないことに留意しなければなりません。関連する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で説明したように、インフィニバンド・アーキテクチャは、インフィニバンド・ネットワーク上で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:
インフィニバンド・アーキテクチャは、上述したように、2つのエンドポイント間のデータ交換の複数の方法を提供します。これらは、次のとおりです。
Reliable Connected (RC)
Reliable Datagram (RD)
Unreliable Connected (UC)
Unreliable Datagram (UD)
Raw Datagram : 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）モードをサポートするために必要とされるが、同じことは、ターゲットチャネルアダプタ（TCAは）には当てはまりません。 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モードです。これらの条件を考えると、それはインフィニ[RFC4391]の上にIPのための当然の選択です。
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.
インフィニバンド仕様は、オプションのスイッチでマルチキャストのサポートを行います。マルチキャストは、しかし、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マルチキャストグループに関連付けされる必要があります。プロセスは、固有IBマルチキャストアドレスにIPマルチキャストアドレスをマッピングするために[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.
セクション1.2で説明したようにIB仕様はフラグビットを記述する。 IB仕様では、いくつかのよく知られているIBのMGIDを表示を定義します。 MGIDを表示はIBの他のトランスポートと互換性がありませんIBの生のデータグラムモード用に予約されています。したがって、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:
IPoIBのサブネットは、IBサブネット上にオーバーレイされます。 IPoIBのサブネットは、以下の手順で育っています。
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.
注意：IPレベルでの参加/離脱動作がIP_join / IP_leaveと呼ぶことにすると、IBレベルで参加/離脱動作が本書でIB_joinと呼ぶことにします。
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のサブネットの成功のセットアップのために必要であることは明らかです。
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のリンクのメンバーを定義します。このリンクは、ブロードキャスト・グループIB_join IPoIBのノードとして構築されます。
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がFullMemberが参加していることに注意してください。ポートまたはブロードキャスト・グループに関連するパラメータ（例えば、パスMTU又はP_KEY）をサポートすることができないIPoIBのサブネットの残りの部分へのポートを連結スイッチのいずれかが、その後IB_join要求は失敗し、要求元のポートが一部にならない場合IPoIBのサブネットの。
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
上述したように、すべてのIPoIBの通信のために必要とされるようQ_KeyとパスMTUなどのパラメータは、「放送グループ」IB_joiningにIPoIBのノードに戻されます。 [RFC4391]にもあることが指摘します
the parameters used in the broadcast group are used when creating other multicast groups.
他のマルチキャストグループを作成する際にブロードキャスト・グループで使用されるパラメータが使用されます。
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]のマッピングに含まれています。別のパラメータ、ブロードキャスト・グループのスコープは、また、それは、ブロードキャストグループに参加することができます前に、エンドノードに知られている必要があります。それはP_KEYとIPoIBのサブネットに関連する範囲ビットが実装によって決定されている方法については、実装の選択です。これらは、管理者が何らかの手段で初期化設定パラメータである可能性があります。
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_Keyを持っている必要があります。このように、IBサブネット上のIPサブネットを設定する管理者は、すべてのメンバーが互換性のP_Keyを持っていることを確認する必要があります。 IPサブネットは、その中のすべてのIPノードがお互いに話すことができることを確実にするために、それに関連付けられている唯一のP_KEYを持つことができます。エンドポイントは、しかし、複数のP_Keyを持っを有することができます。
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が存在することができることを指定します。 P_KEYは、IPマルチキャストアドレス[RFC4391]からMGIDマッピングに含まれています。 P_KEYは、IBサブネット内で一意であることから、IB MGIDを表示中P_KEYを含めることは、ユニークなMGIDマッピングが作成されることが保証されます。このように形成されたすべてのユニークな放送グループ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.
インフィニバンド・サブネット上のIPマルチキャストは、他のメディアに同じ概念や規則に従います。しかし、ほとんどの他のメディアとは違ったInfiniBand経由のマルチキャストは別のエンティティ、IBサブネットマネージャとの対話が必要です。このセクションでは、プロセスの概要を説明し、いくつかのガイドラインを提案します。
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].
様々なヘッダの詳細についてはインフィニバンドアーキテクチャ仕様[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）は、ローカル識別子（LID）を含みます。 IBは、ファブリック経路LIDに基づいて、パケット内のスイッチ。
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のマルチキャスト適合[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アーキテクチャは、パケットが宛先に到達することを保証するものではありませんので、これは必要とされます。
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.
純粋な送信者がFullMemberとして、マルチキャストグループに参加することもできます。このような場合には、送信者は、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かもしれません。それによって送信されたパケットは、他のグループのメンバーに達することができるものの、このような場合には、パケットが送信者にルーティングされません。すべてFullMembersがグループを離れた時に加えて、グループを削除することができます。送信者は、さらに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.
送信者が存在してグループを見つけられない場合は、パケットはすべて、IPルータアドレスに対応するMGIDに送信すること[RFC4391]で推奨されています。送信者は、ブロードキャストグループにパケットを送信することができます。送信者も「創造」を要求することを選択するかもしれませんが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マルチキャストグループに参加する必要があります。これは、受信機は、関連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_leave必要があります。 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のルータは、したがって、ファブリック内IBグループのすべての作品を報告するSMを要求する必要があります。 IPoIBのルータは、報告されたグループIB_join、その後することができます。すべての受信機が去るとき、ルータのIB_joinは、グループの削除を禁止するべきではない - マルチキャストグループのルータのIB_joiningは、受信機から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モードは、IPルータで使用することができます。それがグループに関連付けられているすべてのリソースを解放できるように、ルータは、理想的には、あまりにも削除報告を求めなければなりません。削除MGIDに関連付けられたMLIDは、SMによって再割り当てすることができ、MLIDがキャッシュされている場合、したがって、誤送信の可能性があります。それが正しいMLIDを受信し、それが作成したレポートに応じて、IBグループを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グループに参加している場合にはFullMemberとしてIB_joinへのルータのための合理的です。 （それはグループのFullMemberあるため）このような場合、ルータは、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送信者（レベル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マルチキャスト受信機は、それがIPマルチキャストグループをIP_leaves対応IBマルチキャストグループをIB_leaves。 IPv4の実装の場合、受信機は、IB群IB_leaveが、上述したようにタイマーを開始しないことを選択する可能性がある場合には、送信者（レベル1コンプライアンス）、であり続けることを選択してもよいです。
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 / MLIDをキャッシュ非会員のポートは、この可能性を回避する必要があります。彼らはレポートを削除するには、グループを要求するための方法アウトがあります。すべてのグループのレポートを要求する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_leaveすることを好むかもしれないし、それは、そのようなパケットを転送する必要の明示的な知識を持っていません。
The encapsulation of IP packets in InfiniBand is described in [RFC4391].
インフィニバンドにおける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の通信パケットの「イーサタイプ」値[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.
複数のIB-のサブネットにまたがるためにIPoIBのサブネットを有効にするには、仕様は、リンク層アドレスの一部として、GIDを利用しています。 IB中のすべてのパケットがローカル識別子（LID）を使用する必要があるので、アドレス解決プロセスは、先のGIDを解決する追加のステップがあり、LIDに、解決プロトコル（ARP）/ネイバー発見（ND）の要求をアドレスに応答して返されました[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を含みます。これらのオプションを使用して実装（s）がインターフェイスに関連付けられQPNがリブート/ネットワークリセット[RFC4391]を横切って不変であることを確認できた場合したがって、静的なARPエントリまたはRARPサーバエントリのみ動作します。
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のは、IPアドレスを要求するときに「ブロードキャストフラグ」がクライアントによって使用されること[RFC4390]を指定します。
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で利用可能ですが、それは「正しい」値を選択するエンドノードのアプリケーション次第です。
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].
この文書では、IPoIBのに関連するものとしてIBのアーキテクチャについて説明します。さらに、他のドキュメントで指定された問題を修正再表示します。それ自体は任意の要件を指定していません。何のセキュリティ上の問題はありませんが、このドキュメントで紹介しています。 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]インフィニバンドアーキテクチャ仕様、第1巻は、1.2、2004年10月リリース。
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, April 2006.
[RFC4391]チュー、J.およびV.カシャップ、 "インフィニバンド（のIPoIB）を超えるIPの伝送"、RFC 4391、2006年4月。
[RFC4390] Kashyap, V., "Dynamic Host Configuration Protocol (DHCP) over InfiniBand", RFC 4390, April 2006.
[RFC4390]カシャップ、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.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、 "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]デアリング、S.、STD 5、RFC 1112、1989年8月 "IPマルチキャスティングのためのホスト拡大"。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
Author's Address
著者のアドレス
Vivek Kashyap IBM 15450, SW Koll Parkway Beaverton, OR 97006
ヴィヴェックカシャップIBM 15450、SW KOLLパークウェイビーバートン、OR 97006
Phone: +1 503 578 3422 EMail: vivk@us.ibm.com
電話：+1 503 578 3422 Eメール：vivk@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。