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