RFC4392 日本語訳
4392 IP over InfiniBand (IPoIB) Architecture. V. Kashyap. April 2006. (Format: TXT=53506 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Kashyap Request for Comments: 4392 IBM Category: Informational April 2006
Kashyapがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4392年のIBMカテゴリ: 情報の2006年4月
IP over InfiniBand (IPoIB) Architecture
インフィニバンド(IPoIB)構造の上のIP
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)インターネット協会(2006)。
Abstract
要約
InfiniBand is a high-speed, channel-based interconnect between systems and devices.
インフィニバンドはシステムと装置の間の高速で、チャンネルベースの内部連絡です。
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.
このドキュメントはインフィニバンド構造の概観を提示します。 それはインフィニバンドの上でさらにIPのトランスミッションのための要件とガイドラインについて説明します。 明らかに指定されない場合、議論は本書ではIPv4とIPv6の両方に適切です。 インフィニバンドの上のIPのカプセル化とIPアドレス解決のためのIB織物の上のメカニズムは他のドキュメントで含まれています。
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
1. インフィニバンドへの序論…2 1.1. インフィニバンド構造仕様…2 1.2. インフィニバンド構造の概観…2 1.2.1. インフィニバンドアドレス…6 1.2.1.1. ユニキャストヒツジ暈倒病…7 1.2.1.2. マルチキャストヒツジ暈倒病…7 1.3. インフィニバンドマルチキャストは管理を分類します…9 1.3.1. マルチキャストメンバレコード…10 1.3.1.1. JoinState…10 1.3.2. 操作に参加して、残してください…11 1.3.2.1. マルチキャストを作成して、分類してください…11 1.3.2.2. マルチキャストを削除して、分類してください…11 1.3.2.3. マルチキャストグループは、罠を作成するか、または削除します…12 2. インフィニバンドサブネットの管理…12 3. IBの上のIP…12 3.1. データリンクとしてのインフィニバンド…13
Kashyap Informational [Page 1] RFC 4392 IPoIB Architecture April 2006
[1ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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
3.2. マルチキャストサポート…13 3.2.1. IPマルチキャストをIBマルチキャストに写像します…14 3.2.2. IB MGIDsの一時的な旗…14 3.3. IBサブネットの向こう側のIPサブネット…14 4. インフィニバンド織物のIPサブネット…14 4.1. IPoIB VLANs…16 4.2. IPoIBサブネットにおけるマルチキャスト…16 4.2.1. IPマルチキャストデータグラムを送ります…17 4.2.2. マルチキャストパケットを受けます…18 4.2.3. IPoIBのためのルータ問題…18 4.2.4. インフィニバンド構造限界の影響…19 4.2.5. マルチキャストを残すか、または削除して、分類してください…19 4.3. IPoIBパケットのトランスミッション…20 4.4. アドレス解決プロトコル(RARP)と静的なARPエントリーを逆にしてください…20 4.5. DHCPv4とIPoIB…21 5. QoSと関連問題…21 6. セキュリティ問題…21 7. 承認…21 8. 参照…21 8.1. 標準の参照…21 8.2. 有益な参照…22
1. Introduction to InfiniBand
1. インフィニバンドへの序論
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.
インフィニバンドTrade Association(IBTA)は、ベースの、そして、切り換えられた織物技術をチャンネルに渡すために入出力仕様を開発するために形成されました。 インフィニバンド規格はデータセンターのサーバのスケーラビリティに関する必要条件、信頼性、有用性、および性能を満たすのを目的とされます。
1.1. InfiniBand Architecture Specification
1.1. インフィニバンド構造仕様
The InfiniBand Trade Association specification is available for download from http://www.infinibandta.org.
http://www.infinibandta.org からインフィニバンドTrade Association仕様をダウンロードできます。
1.2. Overview of InfiniBand Architecture
1.2. インフィニバンド構造の概観
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.
インフィニバンドArchitecture(IBA)は、複数の独立しているプロセッサプラットホーム、入出力プラットホーム、および入出力装置をつなげるために、System Area Network(SAN)を定義します。 IBA SANは入出力と1個以上のコンピュータ・システムのためのプロセッサ間通信の両方を支持するコミュニケーションと管理インフラストラクチャです。
Kashyap Informational [Page 2] RFC 4392 IPoIB Architecture April 2006
[2ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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はどっと落しているスイッチで作られたIBA織物とIBルータ(接続IBサブネット)を通して接続されたプロセッサノードと入出力ユニットから成ります。 入出力ユニットは独身のApplication特有のIntegrated Circuit(ASIC)のIBAが付属している装置(LANアダプターなどの)から大きくて、メモリ豊富な無党派Disks(RAID)サブシステムのRedundant Arrayまで複雑さのねらいを定めることができます。
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ネットワークはルータによってインタコネクトされたサブネットに細分されるかもしれません。 これらは、IPルータかIPサブネットではなく、IBルータとIBサブネットです。 このドキュメントはそれぞれ'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ユニットはチャンネル・アダプタ(CAs)を通してリンクに連結します。 構造は、各カリフォルニアと共に織物に接続する1つ以上のポートを提供しながら、複数の1ユニットあたりのCAsを支持します。 各カリフォルニアはノードとして織物に現れます。
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つの例外があります。 パケットがマルチキャストであるときに、QPNsは使用されていません。 また、QPNsはRawデータグラムモードで使用されません。
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.
データ・パケットでは、ポートはLocal Identifier(LID)によって任意に特定されます。Global Identifier(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ビットによって形成される、EUI64対応する、部分。 GIDのEUI-64部分はGlobal Unique Identifier(GUID; Extended Unique Identifierのための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
サブネットマネージャはGIDとLIDの課題を完了しています。 あらゆるIBサブネットには、織物を制御する少なくとも1つのサブネットマネージャコンポーネントがあります。 それはLIDsとGIDsを割り当てます。 サブネット
Kashyap Informational [Page 3] RFC 4392 IPoIB Architecture April 2006
[3ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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.
また、マネージャは、目的地の間にパケットを発送するように、スイッチをプログラムします。 サブネットマネージャ(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サブネットの間のルートパケットがGIDsに基礎づけたコンポーネントです。 したがって、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.
カリフォルニアとスイッチには、複数のポートがあるかもしれません。 それ自身のLIDかさまざまなLIDsがそれぞれのカリフォルニア港に割り当てられます。 スイッチのポートは、LIDs/GIDsがアドレス可能でないか、または言い換えれば、他のエンドノードに透明です。 各ポートには、それ自身のバッファのセットがあります。 バッファリングは各VLがそれ自身のフロー制御を持っている仮想の車線(VL)を通ってチャネルを開設されます。 最大16VLsがあるかもしれません。
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は単一の物理的なリンクの中に複数の仮想のリンクを作成するのにメカニズムを提供します。 すべてのポートが排他的にサブネット管理データグラムのために予約されて、したがってInfiniband(IPoIB)議論に関してIPに心配させないVL15を支持しなければなりません。 パケットが使用する実際のVLはスイッチ/チャンネル・アダプタテーブルのSMによって構成されて、あらゆるパケットで指定されたService Level(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によってプログラムされるかもしれません。 カリフォルニア港はP_キーズがないかどうかいつもチェックします。 カリフォルニア港は複数のパーティションに属すかもしれません。 P_の主要な照合は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_キーズ(_パケットのすなわち、P Keyか_ポートのP Key)の1つは'正会員の資格'P_キーズでなければなりません。
Q_Keys:
Q_キー:
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
Q_キーは、信頼できて頼り無いIBデータグラムサービスのためにアクセス権を実施するのに使用されます。 生のデータグラムサービスはQ_キーズを使用しません。 コミュニケーション設立、終点交換のときに
Kashyap Informational [Page 4] RFC 4392 IPoIB Architecture April 2006
[4ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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_キーズと必須はいつも関連Q_キーズを使用します。 マルチキャストパケットはマルチキャストグループに関連している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_キーは制御Q_キーズ(ゼネラルサービスInterface(GSI)Q_Key[イブ_ARCH]などの)であると考えられます、そして、Host Channel Adapter(HCA)は消費者が任意に制御Q_Keyを指定するのを許容しません。 制御Q_Keyを送る試みはQP文脈でQ_Keyを使用するのに結果として生じます。 したがって、特権がある消費者のために制御Q_KeyのためのQP文脈を構成できるので、Operating Systemはコントロールを維持します。 '制御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形式が[イブ_ARCH]を記述するIPv6の上のRFC2373で定義されるようにあります。 したがって、IPv6過剰インフィニバンド観点から、データ・リンクマルチキャストアドレスはネットワーク・アドレスに似ています。 マルチキャストパケットを受けるために要求をSMに送ることによって、IBポートは明らかにマルチキャストグループに加わらなければなりません。 ポートはどんなマルチキャストグループにもパケットを送るかもしれません。 どちらの場合も、SMからパケットで使用されるべきマルチキャストLIDを受け取ります。
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.
Unreliableデータグラム(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
Endから終わりへの確立したEECと共にどんなノードの上のどんなRD QPとも各RD QPとコミュニケートさせるContexts(EEC)と呼ばれるノードの間の接続の上にReliableデータグラム(RD)サービスを多重送信します。 複数のQPsが同じくらい使用できます。
Kashyap Informational [Page 5] RFC 4392 IPoIB Architecture April 2006
[5ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
EEC and a single QP can use multiple EECs (one for each remote
node per reliable datagram domain).
EECと独身のQPは複数のEECs(各信頼できるデータグラムドメインあたりの遠隔ノードあたり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.
Reliable Connected(RC)サービスは1唯一無二のリモートQPに地方のQPを関連づけます。 長さにおける2^31の八重奏と多分同じくらい大きいメッセージサイズ。 カリフォルニアの実現は分割とアセンブリの世話をします。
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.
Unreliable Connected(UC)サービスは1唯一無二のリモートQPに1地方のQPを関連づけます。 いいえが無くなっているか崩壊したパケットについて承認といいえがしたがって、再送するあります。 したがって、そのようなパケットは単に落とされます。 そうでなければ、それはRCと同様です。
5. Raw Ethertype (unacknowledged - connectionless)
5. 生のEthertype(不承認--、コネクションレスである、)
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の生のデータグラムパケットはカリフォルニアによって解釈されない一般的な輸送ヘッダーを含んでいますが、それはプロトコルタイプを指定します。 ethertypeのための値はethertypeのためにインターネットAssigned民数記Authority(IANA)[IANA]によって定義されるのと同じです。
6. Raw IPv6 (unacknowledged - connectionless)
6. 生のIPv6(不承認--、コネクションレスである、)
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はIPv6(TCP/UDPなどの)の上で標準プロトコル層を支えることができます。 したがって、ネイティブの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輸送と呼ばれます。 後者の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はモードを接続しました、そして、また、ReliableデータグラムモードはAutomatic Path Migration(APM)を支持するかもしれません。 これはハードウェアに基づいている経路フェイルオーバーに備える任意の施設です。接続/EE文脈が最初に作成されるとき、代替パスはQPに関連しています。 回復不能エラーが遭遇するなら、接続は迂回経路を使用するのに切り替わります。
1.2.1. InfiniBand Addresses
1.2.1. インフィニバンドアドレス
The InfiniBand architecture borrows heavily from the IPv6 architecture in terms of the InfiniBand subnet structure and GIDs.
インフィニバンド構造はインフィニバンドサブネットの構造とGIDsに関してIPv6構造から大いに借ります。
Kashyap Informational [Page 6] RFC 4392 IPoIB Architecture April 2006
[6ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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を定義します。 IBAはGIDアドレス形式を引き出します、RFC2373[イブ_ARCH]で定義されるように、いくつかの追加特性/制限が効率的な発見、コミュニケーション、およびルーティングを容易にするために定義されている状態で。
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は明らかにRFC2373[RFC3513]について言及します。(RFCは時代遅れです)。 したがって、IBAがIPv6アドレッシング体系で導入されるどんな一層の変化でも影響を受けないことに注意しなければなりません。
IBA defines two types of GIDs: unicast and multicast.
IBAはGIDsの2つのタイプを定義します: ユニキャストとマルチキャスト。
1.2.1.1. Unicast GIDs
1.2.1.1. ユニキャストヒツジ暈倒病
The unicast GIDs are defined, as in IPv6, with three scopes. The IB specification states the following:
ユニキャストGIDsは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.
リンクローカルアドレスがソースか目的地にある状態で、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ルータはサイト地方のSource GIDかサイト地方のDestination 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を使用するかもしれません。
1.2.1.2. Multicast GIDs
1.2.1.2. マルチキャストヒツジ暈倒病
The multicast GIDs also parallel the IPv6 multicast addresses. The IB specification defines the multicast GIDs as follows:
また、マルチキャストGIDsはIPv6マルチキャストアドレスに沿います。 IB仕様は以下のマルチキャストGIDsを定義します:
FFxy:<112 bits>
FFxy: <の112ビットの>。
Flag bits:
ビットに旗を揚げさせてください:
Kashyap Informational [Page 7] RFC 4392 IPoIB Architecture April 2006
[7ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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
T=0: 永久に、割り当てられて、すなわち、周知の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ビットは範囲ビットです。 これらの範囲値はTable1で説明されます。
scope value Address value
範囲値のAddress価値
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はリンク地方の3が6が割り当てなかった割り当てられなかった5サイトローカル7が組織地方の9が予約された0xEのグローバルな0xFが割り当てられなかった0xDが割り当てられなかった0xCが割り当てられなかった0xBが割り当てられなかった0xAを割り当てなかった8を割り当てなかった4を割り当てなかった2を割り当てませんでした。
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仕様は周知のマルチキャストアドレスを定義している間、さらにRFC2373とRFC2375について言及します。 しかしながら、そして、それは、周知のアドレスがIBの生のIPv6データグラムだけに適用されると述べます。 もっとも、独身のMulticast Global Identifier(MGID)だけにマルチキャストグループを関連づけることができることに注意しなければなりません。 したがって、UDモードとRawデータグラムモードに同じMGIDを関連づけることができません。
Kashyap Informational [Page 8] RFC 4392 IPoIB Architecture April 2006
[8ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
1.3. InfiniBand Multicast Group Management
1.3. インフィニバンドマルチキャスト集団経営
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.
グループがaを送りながら創設されるマルチキャストはSMに要求に参加します。 後で説明されるように、IBAはマルチキャストグループに加わるための複数のモードを定義します。 サブネットマネージャはグループのマルチキャストGIDと関連特性を記録します。 グループの特性はグループ経路MTUによって定義されます、グループが生のデータグラムか頼り無いデータグラムに使用されるか否かに関係なく、サービスレベル、グループ、グループに関連しているLocal Identifier(LID)などに関連しているパーティションキー。 これらの特性はグループ創造時点で、定義されます。 興味のある読者はグループを定義する特性に関する全リストのための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は、マルチキャスト木が関連スイッチをすべてのグループのメンバーとプログラムに基礎づけたことを決定します。 Multicast 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.
IBサブネット境界にかかるグループのためのSMは、他のIBサブネットにおける、このグループの存在を決定するためにIBルータと対話しなければなりません。 存在しているなら、MTUはIBサブネットの向こう側に合わなければなりません。
Kashyap Informational [Page 9] RFC 4392 IPoIB Architecture April 2006
[9ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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_キーはパケットに挿入されたP_KeyがIBスイッチかIBルータによって変更されないのでIBサブネットの向こう側に合わなければならない別の特性です。 したがって、P_キーズが合っていないなら、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.
Aは操作に参加します。新しいメンバーがマルチキャストグループに参加できるように、SMが織物のプログラムを変えることを引き起こすかもしれません。 同様に、休暇で、SMは、パケットをリクエスタに送るのを止めるように織物にプログラムを変えるかもしれません。
1.3.1. Multicast Member Record
1.3.1. マルチキャストメンバレコード
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[イブ_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
このマルチキャストグループP_Key--このマルチキャストグループSLに、主要なパーティション--このマルチキャストグループScopeのためのサービスレベルにこのマルチキャストグループMLID--このマルチキャストグループMTUのためのマルチキャストLID--MTUによって使用されるようにこのマルチキャストのためのマルチキャストGIDがPortGID--このマルチキャストグループQ_Keyを接合するポートの有効なGID--Q_Keyを分類するというMGIDが範囲JoinStateを記述するのと同じMGID--ポートによって要求された接合するか、または状態をままにしてください: ビット0: FullMemberは1に噛み付きました: NonMemberは2に噛み付きました: SendOnlyNonMember
1.3.1.1. JoinState
1.3.1.1. JoinState
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.
非会員: グループのために運命づけられたメッセージはポートとポートから発送されます。 ポートはグループ創造/削除の目的のためのメンバーであると考えられません。
Kashyap Informational [Page 10] RFC 4392 IPoIB Architecture April 2006
[10ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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の組合です。 ポートはそれぞれのJoinStatesのための個別かJoinStateビットのどんな組み合わせでもマルチキャストグループを[イブ_ARCH]に出るかもしれません。
1.3.2. Join and Leave Operations
1.3.2. 操作に参加して、残してください。
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ポートは、SMへのメッセージ(SubnAdmDelete()方法)を休暇に送りながら、aが要求(SubnAdmSet()方法)に参加して、マルチキャストグループを出る発信するのによるマルチキャストグループに加わります。 IBA仕様[イブ_ARCH]は、これらのメッセージを送るとき、使用されるために方法と属性について説明します。
1.3.2.1. Creating a Multicast Group
1.3.2.1. マルチキャストグループを創設します。
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ビットを設定しなければなりません。 言い換えれば、最初の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、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.
リクエスタがFullMemberビットを設定するとき、したがって、グループは規定値で創設されるでしょう、そして、どんなそのようなグループもサブネットで既に存在しません。
1.3.2.2. Deleting a Multicast Group
1.3.2.2. マルチキャストグループを削除します。
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が操作を'残す'最終副作用です。
Kashyap Informational [Page 11] RFC 4392 IPoIB Architecture April 2006
[11ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
1.3.2.3. Multicast Group Create/Delete Traps
1.3.2.3. マルチキャストグループは、罠を作成するか、または削除します。
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、(削除、)、[イブ_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.
したがって、仲間に入りますが、それ自体でそれを作成しないaポート願望が、aが通知を作成するよう要求するかもしれませんか、またはポートは創設されるすべてのグループ(ワイルドカード要求)のための通知を要求さえするかもしれません。 創造が前述の罠を利用するのについてSAはまめにそれらを知らせるでしょう。 そして、リクエスタは示されたマルチキャストグループに加わることができます。 同様に、SendOnlyNonMemberかNonMemberが、グループ削除についてそれを知らせるようSAに要求するかもしれません。 aを受けるときendnodeに、レポートを削除してください、そして、安全にグループに関連しているリソースを発表できます。 関連MLIDはもうグループには有効でなく、SMによる新しいマルチキャストグループに再選任されるかもしれません。
2. Management of InfiniBand Subnet
2. インフィニバンドサブネットの管理
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.
インフィニバンドサブネットコンポーネントのモニターと構成で支援するために、1セットのMIBモジュールは、定義される必要があります。 MIBモジュールが、チャンネル・アダプタ、インフィニバンドインタフェース、インフィニバンドサブネットマネージャ、およびインフィニバンドサブネット管理エージェント、特定の装置性質の管理を許すのに必要です。 IPoIBドキュメントに記述された管理物がIBサブネットの部品のすべてのためにあって、IP(IBの上の)に制限されないことに注意しなければなりません。 関連MIBモジュールは、別々のドキュメントで説明されて、ここにカバーされていません。
3. IP over IB
3. IBの上のIP
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における変化と上位層プロトコルを必要としてください。 また、それは、特別なユーザレベルプログラムそれを実行するのが、IPoIBが変えるIPoIB仕様の目的であるというIPスタックに関する要件が他のメディアタイプと同じレベルで既存の実現への変調と編入に従順であることを強制しません。
Kashyap Informational [Page 12] RFC 4392 IPoIB Architecture April 2006
[12ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
3.1. InfiniBand as Datalink
3.1. データリンクとしてのインフィニバンド
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)
頼り無い信頼できる接続(RC)信頼できるデータグラム(RD)は(UC)頼り無いデータグラム(UD)の生のデータグラムを接続しました: 生のIPv6(R6): 生の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仕様は、UnreliableデータグラムモードがすべてのIBノードによって支持されるのを必要とします。 ホストチャンネル・アダプタ(HCAs)がReliableの接続(RC)を支持するのに明確に必要です、そして、Unreliableは(UC)モードを接続しましたが、同じくらいは目標チャンネル・アダプタ(TCAs)があるケースではありません。 2つのRawデータグラムモードのサポートは完全に任意です。 他のモードにおける32ビットのCRCの使用で提供されたより良い保護と比べて、Rawデータグラムモードは16ビットのCyclic Redundancy Check(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.
織物がマルチキャスティングを支持するのは、簡単にするために、存在するのがある実現と統合の容易さが積み重ねられるのが望ましいです。 これはUnreliableデータグラム(UD)とIBのRawデータグラムモードだけで可能です。
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を利用するのによる性能で重要な利益を提供できます。 また、関連モードの自動経路移動の基本的な特徴が利用されているなら、信頼性は高められます。
3.2. Multicast Support
3.2. マルチキャストサポート
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サブネットを実行するのに使用されるのを必要とします。
Kashyap Informational [Page 13] RFC 4392 IPoIB Architecture April 2006
[13ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
3.2.1. Mapping IP Multicast to IB Multicast
3.2.1. IPマルチキャストをIBマルチキャストに写像します。
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]で定義されます。
3.2.2. Transient Flag in IB MGIDs
3.2.2. IB MGIDsの一時的な旗
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 MGIDsを定義します。 MGIDsはIBのIBの他の輸送と両立しないRawデータグラムモードによって予約されます。 したがって、IPマルチキャストアドレスから定義されるどんなマッピングもIBの周知のアドレスの定義になってはいけません。
Therefore all IPoIB related multicast GIDs always set the transient bit.
したがって、すべてのIPoIBの関連するマルチキャストGIDsはいつも一時的なビットを設定します。
3.3. IP Subnets Across IB Subnets
3.3. IBサブネットの向こう側のIPサブネット
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マルチキャストGIDsを作成するための方法。 パーティションキーと他のパラメタは、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規格。
4. IP Subnets in InfiniBand Fabrics
4. インフィニバンド織物のIPサブネット
The IPoIB subnet is overlaid over the IB subnet. The IPoIB subnet is brought up in the following steps:
IPoIBサブネットはIBサブネットの上でかぶせられます。 IPoIBサブネットは以下のステップで持って来られます:
Kashyap Informational [Page 14] RFC 4392 IPoIB Architecture April 2006
[14ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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_が残す/を接合するとき、レベルが任せられるIPに操作を参加するか、または残してください、IBと呼ばれたレベル意志の_が本書では接合するIBに操作を参加するか、または残してください。
1. The all-IPoIB nodes IB multicast group is created
1. オール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によって定義されません。 グループは、管理者によるSMでのセットアップであるか最初のIB_で加わるかもしれません。
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、Service Level、Hop Limit、Flow ID、TClass、MTUなどの複数の値が指定されなければなりません。 これらの値がそのようなものであるべきであるので、彼らを使用するとき、IBマルチキャストグループのすべての会員になる可能性のある人がお互いにコミュニケートできます。 将来、IB仕様が、より多くの意味を様々なパラメタに関連づけて、Service(QoS)のIB Qualityを定義するとき、IPマルチキャスト交通への異価は可能であるかもしれません。 また、すべてのユニキャストパケットが、放送グループ[RFC4391]で指定されたP_KeyとQ_Keyを使用する必要があります。 考えアウト構成がIPoIBサブネットのうまくいっているセットアップに必要であるのは、明白です。
2. All IPoIB interfaces IB_join the broadcast group
2. すべてのIPoIBインタフェースIB_が放送グループに加わります。
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_が放送グループに加わるのに従って、このリンクは確立されます。
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は上記のマルチキャストグループパラメタをサブネットのすべてのメンバーに分配する追加利益を持っています。
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_が放送グループにつなぐというメモはFullMemberが接合するということです。 IPoIBサブネットの残りにポートをリンクするポートのどれかかスイッチが放送グループに関連しているパラメタ(_例えば、経路MTUかP Key)を支持できないなら、_が接合するIBは失敗して、要求ポートが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
上で述べたように、_QのKeyやPath MTUなどのパラメタ(すべてのIPoIBコミュニケーションに必要である)は'放送グループ'を接合するIB_の上のIPoIBノードに返されます。 また、[RFC4391]はそれに注意します。
Kashyap Informational [Page 15] RFC 4392 IPoIB Architecture April 2006
[15ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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.
しかしながら、放送グループに加わることができる前にIPoIB endnodeにおいてP_Keyをまだ知っていなければなりません。 P_Keyは放送グループ[RFC4391]に関するマッピングに含まれています。 また、別のパラメタ(放送グループの範囲)は、放送グループに加わることができる前にendnodeにおいて知られている必要があります。 それは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によって指定されません。
4.1. IPoIB VLANs
4.1. IPoIB VLANs
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_キーズがなければなりません。 IBサブネットの上にIPサブネットをセットアップするとき、したがって、管理者は、すべてのメンバーにはコンパチブルP_キーズがあるのを保証しなければなりません。 IPサブネットは_KeyがそれのすべてのIPノードがお互いに話すことができるのを保証するためにそれに関連づけた1つPしか持つことができません。 しかしながら、終点には、複数のP_キーズがあるかもしれません。
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サブネットにはマルチキャストグループに関連している1MGIDしかあることができないと指定します。 P_KeyはIPマルチキャストアドレス[RFC4391]からのMGIDマッピングに含まれています。 P_KeyがIBサブネットでユニークであるので、IB MGIDsでのP_Keyの包含は、ユニークなMGIDマッピングが作成されるのを確実にします。 そのように形成されたあらゆるユニークな放送グループMGIDが別々の抽象的なIPoIBリンクとしたがって、IPoIB VLANを作成します。
4.2. Multicast in IPoIB subnets
4.2. IPoIBサブネットにおけるマルチキャスト
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マルチキャストはいかなる他のメディアのようにも同じ概念と規則に従います。 しかしながら、他のほとんどのメディアと異なって、インフィニバンドの上のマルチキャストは別の実体、IBサブネットマネージャとの相互作用を必要とします。 このセクションは、過程のアウトラインについて説明して、いくつかのガイドラインを示します。
IB architecture specifies the following format for IB multicast packets when used over Unreliable Datagram (UD) mode:
Unreliableデータグラム(UD)モードの上で使用されると、IB構造はIBマルチキャストパケットに以下の形式を指定します:
Kashyap Informational [Page 16] RFC 4392 IPoIB Architecture April 2006
[16ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
+--------+-------+---------+---------+-------+---------+---------+ |Local |Global |Base |Datagram |Packet |Invariant| Variant | |Routing |Routing|Transport|Extended |Payload| CRC | CRC | |Header |Header |Header |Transport| (IP) | | | | | | |Header | | | | +--------+-------+---------+---------+-------+---------+---------+
+--------+-------+---------+---------+-------+---------+---------+ |ローカル|グローバル|基地|データグラム|パケット|不変式| 異形| |ルート設定|ルート設定|輸送|広がっています。|有効搭載量| CRC| CRC| |ヘッダー|ヘッダー|ヘッダー|輸送| (IP) | | | | | | |ヘッダー| | | | +--------+-------+---------+---------+-------+---------+---------+
For details about the various headers please refer to InfiniBand Architecture Specification [IB_ARCH].
様々なヘッダーに関する詳細について、インフィニバンドArchitecture Specification[イブ_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.
Globalルート設定Header(GRH)はIBマルチキャストグループGIDを含んでいます。 Localルート設定Header(LRH)はLocal Identifier(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は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が定義されるのを必要とします。 したがって、いつもパケットを放送できます。
4.2.1. Sending IP Multicast Datagrams
4.2.1. 送付IPマルチキャストデータグラム
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マルチキャストグループに加わります。 インフィニバンド構造が、パケットが目的地に到着するのをさもなければ、保証しないので、これが必要です。
Kashyap Informational [Page 17] RFC 4392 IPoIB Architecture April 2006
[17ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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がそうするかもしれません。 このような場合には、それによって伝えられたパケットは他のグループのメンバーに届くことができますが、パケットは送付者に発送されません。 すべての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.
送付者が、グループが現存しているのがわからないなら、[RFC4391]では、パケットがオールIPルータアドレスに対応するMGIDに送られることが勧められます。 また、送付者は放送グループにパケットを送ることができました。 また、送付者は、SMから'創造'レポートを要求するのを選ぶかもしれません。
4.2.2. Receiving Multicast Packets
4.2.2. マルチキャストパケットを受けます。
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要件から続きます。 存在していないなら[イブ_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層が、聴くのを止めるとIBが分類する対応するIPアドレスのIB_休暇がそうしなければなりません。 そして、SMは、グループを削除するのを選ぶことができます。
4.2.3. Router Considerations for IPoIB
4.2.3. IPoIBのためのルータ問題
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ルータはサブネットでインターネットGroup Managementプロトコル(IGMPv3)/マルチキャストListenerディスカバリー(MLD)[RFC3376、RFC2710]などのプロトコルの使用で創設された新しいIPグループを知っています。 しかしながら、IB_におけるルータの必要性がパケットを受けて、伝えることができるように関連IBグループに加わるので、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_は報告されたグループに加わります。 同じように考えられて、IB_としてマルチキャストグループに加わるルータのIB_が受信機から接合するのは、望ましくはありません--すべての受信機がいなくなるとき、_が接合するルータのIBはグループの削除を禁じるはずがありません。 まさしくこのタイプの状況に打ち勝つために、IBAは_が接合するNonMember IBにモードを供給します。
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
に対応してNonMember IB_が接合する、接合するとIPルータでモードを使用できる、レポートを作成してください。 ルータが理想的に要求するべきである、すべてのリソースを発表できるように、レポートも削除してください。
Kashyap Informational [Page 18] RFC 4392 IPoIB Architecture April 2006
[18ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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.
グループに関連しています。 SMは削除されたMGIDに関連しているMLIDを再選任できます、そして、したがって、MLIDがキャッシュされるなら、誤ったトランスミッションの可能性があります。 正しいMLIDを受けて、あらゆる古いキャッシュされた値を掃除してください、それであるときにIB_がIBグループに加わるのでスチール写真が正しく扱う意志がaに対応してレポートを作成するというレポートを削除するよう要求しないルータ。
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に妥当です。 このような場合には、ルータは結局、IBグループの存在を制御するかもしれません(それがグループのFullMemberであるので)。
4.2.4. Impact of InfiniBand Architecture Limits
4.2.4. インフィニバンド構造限界の影響
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がそれが支持できるMGIDsの数に限界を持っているかもしれません。 したがって、グループはサブネットマネージャにおいてそういうもののサブネットが制限されないかもしれませんが、それらは特定のインタフェースで制限されるかもしれません。 IPoIBサブネットをセットアップするとき、適切に食糧を供給されたHCA/TCAを選ぶのは賢明です。
4.2.5. Leaving/Deleting a Multicast Group
4.2.5. マルチキャストグループをいなくなるか、または削除します。
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マルチキャストグループに加わります。 送付者は仲間から抜けなければならなくて、しかしながら、IB_はいつか仲間から抜けます。 グループの受信機でないときに、送付者は発信するマルチキャストグループあたり1個のタイマを始動できました。 タイマが発射されるとき、送付者は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マルチキャスト受信機IB_はIPマルチキャストが分類するIP_葉にそれであるときにIBマルチキャストが分類する対応を残します。 IPv4実現の場合では、受信機が、ずっと送付者であることを(レベル1 承諾)選ぶかもしれなくて、その場合、それはIBが分類するIB_休暇に選ぶのではなく、上で説明されるようにタイマを始動するかもしれません。
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は、最後のFullMember IB_が仲間から抜けるとき、IBグループに関連しているリソース(例えば、スイッチのルーティングエントリー)を開けるのを選ぶことができます。 したがって、MLIDはグループに無効になります。 新しいグループが創設されるとき、MLIDを再選任できます。
Kashyap Informational [Page 19] RFC 4392 IPoIB Architecture April 2006
[19ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
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.
MLIDをキャッシュするSendOnlyNonMember/NonMemberポートは、この可能性を避ける必要があります。 彼らが、グループがレポートを削除するよう要求するように、出口はあります。 すべてのグループのためのレポートを要求すると要求される必要はないIPルータ、_がaに対応して接合するIBが意志が新しい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マルチキャストグループを好むかもしれません、そして、それには、そのようなパケットを進めるどんな必要性の形式知も全くありません。
4.3. Transmission of IPoIB Packets
4.3. IPoIBパケットのトランスミッション
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コミュニケーションパケットにおける'Ethertype'価値[IANA]の使用を指定します。 リンクレイヤアドレスはGIDとQueue Pair Number(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のすべてのパケットがLocal Identifier(LID)を使用しなければならないので、アドレス解決の過程に、(ARP)/隣人Discover(ノースダコタ)が要求するAddress Resolutionプロトコルに対応して返された目的地GIDをLID[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を引き出します。
4.4. Reverse Address Resolution Protocol (RARP) and Static ARP Entries
4.4. 逆アドレス解決プロトコル(RARP)と静的なARPエントリー
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を含んでいます。(QPNはリブートかネットワーク・インターフェースリセットの向こう側にさえ一定でないかもしれません)。 したがって、これらのオプションを使用する実現がインタフェースに関連しているQPNが確実にリブート/ネットワークリセット[RFC4391]の向こう側に不変になるようにすることができる場合にだけ、静的なARPエントリーかRARPサーバエントリーが働くでしょう。
Kashyap Informational [Page 20] RFC 4392 IPoIB Architecture April 2006
[20ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
4.5. DHCPv4 and IPoIB
4.5. DHCPv4とIPoIB
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]。
5. QoS and Related Issues
5. QoSと関連問題
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がアプリケーションについて決める決断の用法と方法を残します。 SLsのSLとリストは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規格によって定義されていません。
6. Security Considerations
6. セキュリティ問題
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]で説明されます。
7. Acknowledgements
7. 承認
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ワーキンググループのメンバーとインフィニバンド(SM)貿易Associationのメンバーのコメントと提案の利益を得ました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[IB_ARCH] InfiniBand Architecture Specification, Volume 1,
Release 1.2, October, 2004.
[イブ_アーチ]インフィニバンド構造仕様(第1巻)は1.2、2004年10月をリリースします。
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over
InfiniBand (IPoIB)", RFC 4391, April 2006.
[RFC4391] チュウ、J.、および「インフィニバンド(IPoIB)の上のIPのトランスミッション」、RFC4391、2006年4月対Kashyap
[RFC4390] Kashyap, V., "Dynamic Host Configuration Protocol
(DHCP) over InfiniBand", RFC 4390, April 2006.
[RFC4390]Kashyap、2006年4月のV.、「インフィニバンドの上のダイナミックなホスト構成プロトコル(DHCP)」RFC4390。
Kashyap Informational [Page 21] RFC 4392 IPoIB Architecture April 2006
[21ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
8.2. Informative References
8.2. 有益な参照
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、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.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、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] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、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"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
Author's Address
作者のアドレス
Vivek Kashyap IBM 15450, SW Koll Parkway Beaverton, OR 97006
Vivek Kashyap IBM15450、SW Koll Parkwayビーバートン、または97006
Phone: +1 503 578 3422 EMail: vivk@us.ibm.com
以下に電話をしてください。 +1 3422年の503 578メール: vivk@us.ibm.com
Kashyap Informational [Page 22] RFC 4392 IPoIB Architecture April 2006
[22ページ]RFC4392IPoIB構造2006年4月の情報のKashyap
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Kashyap Informational [Page 23]
Kashyap情報です。[23ページ]
一覧
スポンサーリンク
