RFC4755 日本語訳
4755 IP over InfiniBand: Connected Mode. V. Kashyap. December 2006. (Format: TXT=26314 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Kashyap Request for Comments: 4755 IBM Category: Standards Track December 2006
Kashyapがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4755年のIBMカテゴリ: 標準化過程2006年12月
IP over InfiniBand: Connected Mode
インフィニバンドの上のIP: 関連モード
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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand.
このドキュメントはインフィニバンドの関連モードの上のIPv4/IPv6パケットとアドレス解決の送信を指定します。
Kashyap Standards Track [Page 1] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[1ページ]RFC4755
Table of Contents
目次
1. Introduction ....................................................2
2. IPoIB-connected Mode ............................................3
2.1. Multicasting ...............................................3
2.2. Outline of Address Resolution ..............................4
2.3. Outline of Connection Setup ................................4
3. Address Resolution ..............................................4
3.1. Link-layer Address .........................................4
3.2. IB Connection Setup ........................................6
3.3. Simultaneous IB Connections ................................6
3.4. IPoIB-CM IB Connection Teardown ............................7
3.5. Service-ID .................................................7
4. Frame Format ....................................................8
5. Maximum Transmission Unit .......................................8
5.1. Per-Connection MTU .........................................9
6. Private-Data Format .............................................9
7. IPoIB-CM Considerations ........................................10
7.1. A Cautionary Note on IPoIB-RC .............................10
7.2. IPoIB-CM Per-Destination MTU ..............................10
8. Security Considerations ........................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. Normative References ..........................................11
12. Informative References ........................................11
1. 序論…2 2. IPoIBが関連しているモード…3 2.1. マルチキャスティング…3 2.2. アドレス解決のアウトライン…4 2.3. 接続設定のアウトライン…4 3. 解決を扱ってください…4 3.1. リンクレイヤアドレス…4 3.2. IB接続設定…6 3.3. 同時のIBコネクションズ…6 3.4. IPoIB-CM IB接続分解…7 3.5. サービスID…7 4. 形式を縁どってください…8 5. 最大のトランスミッション単位…8 5.1. 1接続あたりのMTU…9 6. 個人的なデータの形式…9 7. IPoIB-CM問題…10 7.1. IPoIB-RCに関する警告的な注…10 7.2. 1目的地あたりのIPoIB-CM MTU…10 8. セキュリティ問題…11 9. IANA問題…11 10. 承認…11 11. 標準の参照…11 12. 有益な参照…11
1. Introduction
1. 序論
The InfiniBand specification [IB_ARCH] can be found at www.infinibandta.org. The document [RFC4392] provides a short overview of InfiniBand architecture along with consideration for specifying IP over InfiniBand networks.
www.infinibandta.orgでインフィニバンド仕様[イブ_ARCH]を見つけることができます。 ドキュメント[RFC4392]はインフィニバンドネットワークの上でIPを指定するための考慮に伴うインフィニバンドアーキテクチャの短い概要を提供します。
The InfiniBand Architecture (IBA) defines multiple modes of transports. Of these the unreliable datagram (UD) transport method best matches the needs of IP. IP over InfiniBand (IPoIB) over UD is described in [RFC4391]. This document describes IP transmission over the connected modes of IBA.
インフィニバンドArchitecture(IBA)は輸送の複数の方法を定義します。 メソッドはIPの必要性に頼り無いデータグラム(UD)が輸送するこれらでは、最もよく合っています。 UDの上のインフィニバンド(IPoIB)の上のIPは[RFC4391]で説明されます。 このドキュメントはIBAの関連モードの上のIPトランスミッションについて説明します。
IBA defines two connected modes:
IBAは2つの関連モードを定義します:
1. Reliable Connected (RC)
2. Unreliable Connected (UC)
1. 信頼できる接続(RC。)2 頼り無さ、接続(UC)
As is evident from the nomenclature, the two modes differ mainly in providing reliability of data delivery across the connection. This document applies equally to both the connected modes. IPoIB over these two modes is referred to as IPoIB-CM (connected mode) in this
そのままで、用語体系から明白であることで、2つのモードが接続の向こう側に主にデータ配送の信頼性を提供するのにおいて異なります。 このドキュメントは等しく両方の関連モードに適用されます。 これらの2つのモードの上のIPoIBはこれにIPoIB-CM(モードを接続する)と呼ばれます。
Kashyap Standards Track [Page 2] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[2ページ]RFC4755
document. For clarity, IPoIB over the unreliable datagram mode as described in [RFC4391] is referred to as IPoIB-UD.
記録します。 明快において、[RFC4391]で説明される頼り無いデータグラムモードの上のIPoIBはIPoIB-UDと呼ばれます。
IBA requires that all Host Channel Adapters (HCAs) support the reliable and unreliable connected modes [IB_ARCH]. It is optional for Target Channel Adapters (TCAs) to support the connected modes.
IBAは、すべてのHost Channel Adapters(HCAs)が、信頼できて頼り無い関連モードが[イブ_ARCH]であるとサポートするのを必要とします。 Target Channel Adapters(TCAs)が関連モードをサポートするのは、任意です。
The connected modes offer link MTUs of up to 2^31 octets in length. Thus, the use of connected modes can offer significant benefits by supporting reasonably large MTUs. The datagram modes of InfiniBand Architecture (IBA) are limited to 4096 octets.
関連モードは長さにおける最大2^31の八重奏のリンクMTUsを提供します。 したがって、関連モードの使用は、合理的に大きいMTUsをサポートすることによって、重要な利益を提供できます。 インフィニバンドArchitecture(IBA)のデータグラムモードは4096の八重奏に制限されます。
Reliability is also enhanced if the underlying feature of "automatic path migration" supported by the connected modes is utilized.
また、関連モードでサポートされた「自動経路移行」の基本的な特徴が利用されているなら、信頼性は高められます。
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. IPoIB-connected Mode
2. IPoIBが関連しているモード
IPoIB over connected mode is an OPTIONAL extension to IPoIB-UD. Every IPoIB implementation MUST support [RFC4391] and MAY support the extensions described in this document.
関連モードの上のIPoIBはIPoIB-UDへのOPTIONAL拡張子です。 あらゆるIPoIB実装が、[RFC4391]をサポートしなければならなくて、本書では説明された拡大をサポートするかもしれません。
Therefore, IP encapsulation, default MTU, link-layer address format, and the IPv6 stateless autoconfiguration mechanism apply to IPoIB-CM exactly as described in [RFC4391].
したがって、IPカプセル化、デフォルトMTU、リンクレイヤアドレス形式、およびIPv6の状態がない自動構成メカニズムはちょうど[RFC4391]で説明されるようにIPoIB-CMに適用されます。
2.1. Multicasting
2.1. マルチキャスティング
The connected modes of IBA define a non-broadcast, multiple-access network. The connected modes of IBA do not support multicasting though every node can communicate with every other node if desired.
IBAの関連モードは非放送であって、複数のアクセスしているネットワークを定義します。 望まれているなら、あらゆるノードが他のあらゆるノードとコミュニケートできますが、IBAの関連モードはマルチキャスティングをサポートしません。
This requires that multicasting be emulated in some form by the network. However, in the case of an InfiniBand network, instead of an emulation, an unreliable datagram (UD) queue pair (QP) can be used to support multicasting while the connected mode QP is used for unicast traffic. Since every IPoIB implementation is required to support the UD mode, every implementation supporting IPoIB-CM will be able to utilize the pre-existing IPoIB-UD QP for all broadcast/multicast communications. Multicast mapping, transmission, and reception of multicast packets and multicast routing MUST use the UD QP associated with the IPoIB interface.
これは、マルチキャスティングが何らかのフォームでネットワークによって見習われるのを必要とします。 しかしながら、インフィニバンドネットワークの場合では、エミュレーションの代わりに、関連モードQPがユニキャストトラフィックに使用されている間、マルチキャスティングをサポートするのに、頼り無いデータグラム(UD)待ち行列組(QP)を使用できます。 あらゆるIPoIB実装がUDモードをサポートするのに必要であるので、IPoIB-CMをサポートするあらゆる実装がすべての放送/マルチキャストコミュニケーションに先在のIPoIB-UD QPを利用できるでしょう。 マルチキャストパケットとマルチキャストルーティングのマルチキャストマッピング、トランスミッション、およびレセプションはIPoIBインタフェースに関連しているUD QPを使用しなければなりません。
Kashyap Standards Track [Page 3] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[3ページ]RFC4755
2.2. Outline of Address Resolution
2.2. アドレス解決のアウトライン
Every IPoIB-CM interface MUST have two sets of QPs associated with it:
あらゆるIPoIB-CMインタフェースには、それに関連しているQPsの2セットがなければなりません:
1) One unreliable datagram QP
2) One or more connected mode QPs
1) 1個の頼り無いデータグラムQP2) ものか以上がモードQPsを接続しました。
[RFC4391] describes the address resolution method to determine the link address of the peer. This response is received on the UD QP associated with the IPoIB interface.
[RFC4391]は同輩のリンクアドレスを決定するアドレス解決メソッドを説明します。 IPoIBインタフェースに関連しているUD QPでこの応答を受けます。
2.3. Outline of Connection Setup
2.3. 接続設定のアウトライン
Once the link address of the remote node is known, an IB connection must be set up between the nodes before any IP communication may occur.
遠隔ノードのリンクアドレスがいったん知られていると、どんなIPコミュニケーションも現れるかもしれない前にIB接続のノードをセットアップしなければなりません。
To make a connection, the sender must know the service-ID to use in the request to make a connection [IB_ARCH]. It must also supply the "connection mode" queue pair to the remote node. The peer replies with its queue pair. Each IB connection is peer to peer and uses one connected mode QP at each end.
接続を作るために、送付者は[イブ_ARCH]に接続を作るという要求で使用へのサービスIDを知らなければなりません。 また、それは「接続モード」待ち行列組の遠隔ノードを供給しなければなりません。 同輩は待ち行列組と共に返答します。 それぞれのIB接続はピアツーピアです、そして、用途1はモードQPを各端に接続しました。
Though the address resolution occurs at an individual IP address level, the connection between the nodes is at the IB layer. Therefore, every individual address resolution does not imply a new connection between the peers.
アドレス解決は個々のIPアドレスレベルで起こりますが、ノードの間の接続がIB層にあります。 したがって、あらゆる個々のアドレス決議が同輩の間の新しい接続を含意するというわけではありません。
3. Address Resolution
3. アドレス解決
Address resolution queries are sent out on the "broadcast-GID" (Broadcast-Group Identifier) over the UD QP associated with the IPoIB interface [RFC4391]. A unicast reply is received on the UD QP.
IPoIBインタフェース[RFC4391]に関連しているUD QPの上の「放送ヒツジ暈倒病」(放送グループIdentifier)でアドレス解決質問を出します。 UD QPにユニキャスト回答を受け取ります。
3.1. Link-layer Address
3.1. リンクレイヤアドレス
IPoIB encapsulation [RFC4391] describes the link-layer address as follows:
IPoIBカプセル化[RFC4391]は以下のリンクレイヤアドレスについて説明します:
<1 octet reserved>:QP: GID
<1八重奏は>: QPを予約しました: ヒツジ暈倒病
This document extends the link-layer address as follows:
このドキュメントは以下のリンクレイヤアドレスを広げています:
<Flags>:QPN:GID
<は>:QPN:ヒツジ暈倒病に旗を揚げさせます。
Kashyap Standards Track [Page 4] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[4ページ]RFC4755
Flags:
旗:
This is a single-octet field. The bits indicate the connected
modes supported by the interface.
これはただ一つの八重奏分野です。 ビットはインタフェースによってサポートされた関連モードを示します。
Bit 0 specifies the support for the "reliable connected" (RC)
mode. Bit 1 indicates the support for the "unreliable connected"
(UC) mode. All other bits in the octet are reserved and MUST be
set to 0 on transmits and ignored on receives. The format of the
flags is as follows:
ビット0がサポートを指定する、「信頼できる、」 (RC)モードを接続しました。 ビット1がサポートを示す、「頼り無さ、」 (UC)モードを接続しました。 八重奏における他のビットが0にオンなセットが伝わるということでなければならなく、予約されて、無視されるすべてが受信されます。 旗の形式は以下の通りです:
+--+--+--+--+--+--+--+--+
|RC|UC| 0| 0| 0| 0| 0| 0|
+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+ |RC|UC| 0| 0| 0| 0| 0| 0| +--+--+--+--+--+--+--+--+
Both the RC and UC MAY be set at the same time if the interface
supports both the modes. Since the IPoIB-UD mode is always
supported, there are no flags to indicate IPoIB-UD support.
RCとUC MAYの両方、インタフェースが、両方がモードであるとサポートするなら、同時に、設定されてください。 IPoIB-UDモードがいつもサポートされるので、IPoIB-UDサポートを示すために、旗は全くありません。
If IPoIB-CM is not supported, i.e., if the implementation only
supports IPoIB-UD, then the implementation MUST ignore the <Flags>
on reception. It MUST set the <Flags> octet to all zeros on
transmission as specified in [RFC4391].
すなわち、実装がIPoIB-UDをサポートするだけであるならIPoIB-CMがサポートされないなら、実装はレセプションで<Flags>を無視しなければなりません。 それは[RFC4391]の指定されるとしてのトランスミッションのすべてのゼロに<Flags>八重奏を設定しなければなりません。
QPN:
QPN:
The queue-pair number (QPN) on which the unicast address
resolution replies will be received [RFC4391]. An IPoIB interface
has only one UD QP associated with it whether or not it supports
this extension.
ユニキャストアドレス解決が返答する待ち行列組番号(QPN)を受け取るでしょう[RFC4391]。 IPoIBインタフェースには、それがこの拡大をサポートするか否かに関係なく、それに関連している1UD QPしかありません。
The QPN also serves another purpose. It is used to form the
Service-ID that is used to set up the IB connection.
また、QPNは別の目的に役立ちます。 それは、IB接続をセットアップするのに使用されるService-IDを形成するのに使用されます。
On receiving the multicast/broadcast address resolution request, the receiver replies with its own link address, including the associated UD QPN and the appropriate flags.
マルチキャスト/放送演説解決要求を受け取ると、受信機はそれ自身のリンクアドレスで返答します、関連UD QPNと適切なフラグを含んでいて。
The receiver's reply is unicast back to the sender after the receiver has, as in the case of IPoIB-UD, resolved the GID to the Local Identifier (LID), and determined other required parameters [RFC4391]. Once the address resolution is completed, the underlying IB connection on the supported connection modes can be set up. An implementation is NOT REQUIRED to set up a connection merely because the peer indicates the capability. The decision to make such a connection is left to the implementation.
受信機の回答は受信機の後の送付者へのユニキャスト後部がIPoIB-UDに関するケースのようにLocal Identifier(LID)、および他の決定している必要なパラメタ[RFC4391]にGIDを決議したということです。 アドレス解決がいったん終了されていると、サポートしている接続モードにおける基本的なIB関係をセットアップできます。 実装は同輩が単に能力を示すので接続をセットアップするNOT REQUIREDです。 そのような接続を作るという決定は実装に任せます。
Kashyap Standards Track [Page 5] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[5ページ]RFC4755
3.2. IB Connection Setup
3.2. IB接続設定
Once the address resolution is complete, the IB connection can be set up by either of the peers. To set up a connection, IB Management Datagrams (MADs) are directed to the peer's communication manager (CM). The connection request always contains a Service-ID for the peer to associate the request with the appropriate service. If the request is accepted, the peer returns the relevant connected mode QPN in the response MAD. The format of the CM connection messages and the IB connection setup process is described in [IB_ARCH]. The overall handshake is of the form:
アドレス解決がいったん完全になると、同輩のどちらかはIB接続をセットアップできます。 接続をセットアップするために、IB Managementデータグラム(MADs)は同輩のコミュニケーションマネージャ(CM)に向けられます。 接続要求はいつも同輩が適切なサービスに要求を関連づけるService-IDを含んでいます。 要求を受け入れるなら、同輩は応答MADで関連関連モードQPNを返します。 CM接続メッセージとIB接続設定プロセスの形式は[イブ_ARCH]で説明されます。 総合的な握手はフォームのものです:
REQ ---->
<---- REP [or REJ(reject)]
RTA ---->
[or REJ(reject)]
REQ----><。---- レップ[または、REJ(拒絶する)]RTA---->。[または、REJ(拒絶します)]
The CM messages include, among other parameters, the Service-ID, Local connection-mode QPN, and the payload size to use over the connection.
CMメッセージは他のパラメタの中にService-ID、Local接続モードQPN、および接続の上で使用するペイロードサイズを含んでいます。
Note: The IB connection is set up using the Service-ID as defined in
Section 3.5 below. The node MUST keep a record of IB
connections it is participating in. The node MAY attempt
another connection to the remote peer using the same Service-ID
as used for an existing IB connection. Similarly, the receiver
of such a connection MAY drop the request with a suitable error
indication in the CM response. The decision to accept or
initiate multiple connections from or to an IPoIB interface is
left to the implementation.
以下に注意してください。 IB接続は以下のセクション3.5で定義されるようにService-IDを使用するのに用意ができています。 ノードはそれが参加しているIB接続に関する記録をつけなければなりません。 既存のIB接続に、同じくらい中古の同じService-IDを使用して、ノードはリモート同輩に別の接続を試みるかもしれません。 同様に、CM応答における適当な誤り表示に応じて、そのような接続の受信機は要求を下げるかもしれません。 インタフェースかIPoIBインタフェースに複数の接続を受け入れるか、または開始するという決定は実装に任せます。
The node that initiated the connection is aware of the target node's IP address as described above. The node receiving the IB connection request, however, cannot determine the initiating node's link address. To enable this determination, every CM message exchanged in setting up the IB connection MUST include the sender's IPoIB-UD QPN in the "private data" [IB_ARCH] field. The IPoIB-UD QPN MUST be included in all "REJ" [IB_ARCH] messages too.
接続を開始したノードは上で説明されるように目標ノードのIPアドレスを意識しています。 しかしながら、IB接続要求を受け取るノードは開始ノードのリンクアドレスを決定できません。 この決断を可能にするために、IB接続をセットアップする際に交換されたあらゆるCMメッセージが「個人的なデータ」[イブ_ARCH]分野に送付者のIPoIB-UD QPNを含まなければなりません。 すべての「レイ」[イブ_アーチ]メッセージにもIPoIB-UD QPNを含まなければなりません。
3.3. Simultaneous IB Connections
3.3. 同時のIBコネクションズ
To ensure that two IB connections are not set up between the peers due to REQ crossing, the following rules MUST be followed:
2つのIB接続がREQ交差点のため同輩の間でセットアップされないのを保証するために、以下の規則に従わなければなりません:
The receiver forms the remote node's link-layer address using the
UD QPN received in the "private data" field of the "REQ" message
and the GID of the sender included in the "REQ" message. The
link-layer address is used to determine if there is already an
受信機は、"REQ"メッセージの「個人的なデータ」分野に受け取られて、"REQ"メッセージに送付者のヒツジ暈倒病を含んでいて、UD QPNを使用することで遠隔ノードのリンクレイヤアドレスを形成します。 リンクレイヤアドレスは、既にあるかどうか決定するのに使用されます。
Kashyap Standards Track [Page 6] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[6ページ]RFC4755
outstanding connection request "REQ" sent by the local interface
to the given received link-layer address. If such an outstanding
request is determined, then the two link-layer addresses (local
and remote) are numerically compared. If the local link-layer
address is numerically smaller, then the connection is accepted,
otherwise rejected. The error code in "REJ" MAD is set to
"Consumer Reject" [IB_ARCH].
傑出している接続要求"REQ"は局所界面のそばで与えられた受け取られていているリンクレイヤアドレスに発信しました。 そのような傑出している要求が決定しているなら、2つのリンクレイヤアドレス(地方の、そして、リモートな)が数の上で比較されます。 ローカルのリンクレイヤアドレスが数の上でより小さいなら、別の方法で拒絶されていると接続を受け入れます。 「レイ」で気が狂ったエラーコードは「消費者廃棄物」[イブ_アーチ]に設定されます。
Note: The link-layer addresses formed for comparison zero out the
connection mode flags specified in Section 3.1. The
comparison is performed from the most significant octet to
the least significant octet of the link-layer address.
以下に注意してください。 比較のために形成されたリンクレイヤアドレスは外でセクション3.1で指定された接続モード旗のゼロに合っています。 比較は最も重要な八重奏から最も重要でないリンクレイヤアドレスの八重奏まで実行されます。
The above holds even if the receiver supports multiple IB
connections from the same peer. This is to ensure that only one
more connection is set up when the "REQ" messages cross.
受信機が同じくらいから複数のIB接続をサポートしても、上の船倉はじっと見ます。 これは、"REQ"メッセージが交差するとき、もうひとつの接続だけがセットアップされるのを保証するためのものです。
3.4. IPoIB-CM IB Connection Teardown
3.4. IPoIB-CM IB接続分解
IB connections created through IPoIB-CM are considered part of an IPoIB interface. As such, they SHOULD be torn down when the IPoIB interfaces they are associated with are torn down.
IPoIB-CMを通して創造されたIB接続はIPoIBインタフェースの一部であると考えられます。 そういうものとしてそれら、SHOULD、それらが関連しているIPoIBインタフェースを取りこわすときには、取りこわしてください。
Furthermore, the IB connection between two peers MAY be torn down by either peer whenever the address resolution entry expires. An implementation is free to implement alternative policies for tearing down of IB connections between peers.
その上、アドレス解決エントリーが期限が切れるときはいつも、2人の同輩の間のIB接続はどちらの同輩によっても取りこわされるかもしれません。 実装は自由にIB接続について下にを同輩に迷わされるための代替的政策を実装することができます。
3.5. Service-ID
3.5. サービスID
The InfiniBand specification defines a block of Service-IDs for IETF use. The InfiniBand specification has left the definition and management of this block to the IETF [IB_ARCH]. The 64-bit block is as follows:
インフィニバンド仕様はIETF使用のために1ブロックのService-IDを定義します。 インフィニバンド仕様はIETFへのこのブロックの定義と管理を[イブ_ARCH]に出ました。 64ビットのブロックは以下の通りです:
+--------+--------+--------+--------+-------+--------+--------+------+ |00000001|<-------------------IETF use------------------------------>| +--------+--------+--------+--------+-------+--------+--------+------+
+--------+--------+--------+--------+-------+--------+--------+------+ |00000001| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--IETF使用------------------------------>| +--------+--------+--------+--------+-------+--------+--------+------+
Kashyap Standards Track [Page 7] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[7ページ]RFC4755
The Service-IDs used by IPoIB will be in the following format:
以下の形式にはIPoIBによって使用されたService-IDがあるでしょう:
+--------+--------+--------+--------+-------+-------+--------+-------+ |00000001| Type | Reserved | QPN | +--------+--------+--------+--------+-------+-------+--------+-------+
+--------+--------+--------+--------+-------+-------+--------+-------+ |00000001| タイプ| 予約されます。| QPN| +--------+--------+--------+--------+-------+-------+--------+-------+
The "Type" field MUST be set to 0.
「タイプ」分野を0に設定しなければなりません。
The "Reserved" field MUST be set to zeros.
「予約された」分野をゼロに設定しなければなりません。
The QPN MUST be the UD QP exchanged during address resolution.
QPN MUST、アドレス解決の間に交換されたUD QPになってください。
4. Frame Format
4. フレーム形式
All IP datagrams transported over InfiniBand are prefixed by a 4-octet encapsulation header as described in [RFC4391].
インフィニバンドの上で輸送されたすべてのIPデータグラムが[RFC4391]で説明されるように4八重奏のカプセル化ヘッダーによって前に置かれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Type | Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | タイプ| 予約されます。| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field SHALL indicate the encapsulated protocol as per
the following table.
タイプ分野SHALLは以下のテーブルに従ってカプセル化されたプロトコルを示します。
+----------+-------------+
| Type | Protocol |
|------------------------|
| 0x800 | IPv4 |
|------------------------|
| 0x86DD | IPv6 |
+------------------------+
+----------+-------------+ | タイプ| プロトコル| |------------------------| | 0×800| IPv4| |------------------------| | 0x86DD| IPv6| +------------------------+
These values are taken from the "ETHER TYPE" numbers assigned by Internet Assigned Numbers Authority (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)によって割り当てられた「エーテル型」番号からこれらの値を取ります。 「エーテル型」の異価によって特定された他のネットワーク・プロトコルはここに定義されたカプセル化書式を使用するかもしれませんが、そのような使用はこのドキュメントの範囲の外にあります。
5. Maximum Transmission Unit
5. マキシマム・トランスミッション・ユニット
The IB connection setup might be used for both IPv4 and IPv6 or it could be used for only one of them while a different connection is used for the other. The link MTU MUST be able to support the minimum MTU required by the protocols.
IPv4とIPv6の両方にIB接続設定を使用したかもしれませんか、または異なった接続がもう片方に使用されている間、1だけにそれらについてそれを使用できました。 MTU MUSTをリンクしてください。プロトコルによって必要とされた最小のMTUはサポートすることができてください。
Kashyap Standards Track [Page 8] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[8ページ]RFC4755
The default MTU of the IPoIB-CM interface is 2044 octets, i.e., 2048-octet IPoIB-link MTU minus the 4-octet encapsulation header.
IPoIB-CMインタフェースのデフォルトMTUは2044の八重奏、すなわち、4八重奏のカプセル化ヘッダーを引いて2048八重奏のIPoIB-リンクMTUです。
However, connected modes of InfiniBand allow message sizes up to 2^31 octets. Therefore, IPoIB-CM can use a much larger MTU for unicast communication between any two endpoints. The maximum and/or optimal payload that can be received or sent over an InfiniBand connection is dependent on the implementation, IB Channel Adapter, and the resources configured.
しかしながら、インフィニバンドの関連モードは最大2^31の八重奏をメッセージサイズに許容します。 したがって、IPoIB-CMはどんな2つの終点のユニキャストコミュニケーションにもはるかに大きいMTUを使用できます。 インフィニバンド接続の上に受け取るか、または送ることができる最大の、そして/または、最適のペイロードは構成された実装、IB Channel Adapter、およびリソースに依存しています。
An implementation MAY utilize the following mechanism to exchange the optimal message size across the IB connection.
実装は、IB接続の向こう側に最適のメッセージサイズを交換するのに以下のメカニズムを利用するかもしれません。
5.1. Per-Connection MTU
5.1. 1接続あたりのMTU
Every IB connection setup message includes a "private data" field [IB_ARCH]. The "private data" field in the connection setup message (CM REQ) MUST include the "Receive MTU". This indicates the maximum packet size the requester can accept. The requester MUST be able to accept smaller MTU sizes as well.
あらゆるIB接続設定メッセージが「個人的なデータ」分野[イブ_ARCH]を含んでいます。 接続設定メッセージ(CM REQ)の「個人的なデータ」分野が含まなければならない、「MTUを受けてください。」 これはリクエスタが受け入れることができる最大のパケットサイズを示します。 リクエスタはまた、より小さいMTUサイズを受け入れることができなければなりません。
It is up to the implementation to utilize this mechanism for setting the per-IB connection MTU. To calculate the resultant IPoIB MTU over the connection the smaller of the two IB "Receive MTU" values is used by both the peers. The IPoIB interface must also account for the 4- octet encapsulation header and so the IPoIB MTU over the connection will be further reduced by that amount.
1IBあたりの接続MTUを設定するのにこのメカニズムを利用するのは実装まで達しています。 接続に関して結果のIPoIB MTUについて計算するために、「MTUを受けてください」が評価する2IBについて、より小さいのは両方の同輩によって使用されます。 また、IPoIBインタフェースが4八重奏カプセル化ヘッダーの原因にならなければならないので、接続の上のIPoIB MTUはその量によってさらに減少させられるでしょう。
6. Private-Data Format
6. 個人的なデータの形式
The "private data" field in every CM message for connection establishment must include the following values:
コネクション確立へのあらゆるCMメッセージの「個人的なデータ」分野は以下の値を含まなければなりません:
1. UD QPN of the sender
2. Receive MTU supported by the sender
1. 送付者2のUD QPN。 送付者によってサポートされたMTUを受けてください。
The format of the "private data" field MUST be as follows:
「個人的なデータ」分野の形式は以下の通りであるに違いありません:
0 7 15 23 31
+--------+--------+--------+--------+
|Reserved| UD QPN |
+--------+--------+--------+--------+
| Receive MTU |
+--------+--------+--------+--------+
0 7 15 23 31 +--------+--------+--------+--------+ |予約されます。| UD QPN| +--------+--------+--------+--------+ | MTUを受けてください。| +--------+--------+--------+--------+
The Reserved value MUST be set to zero on transmit and ignored on receive.
伝わって、無視されて、Reserved値がゼロにオンなセットでなければならない、オンである、受信してください。
Kashyap Standards Track [Page 9] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[9ページ]RFC4755
7. IPoIB-CM Considerations
7. IPoIB-CM問題
Every IPoIB interface supports IPoIB-UD. It may additionally support one or both of the IPoIB-CM modes. Therefore, there can be multiple methods of communicating between any two peers. This implies that an interface MAY transmit/receive a packet over any of the RC, UC, or UD modes depending on the modes supported between it and the peer. It further follows that every IPoIB implementation compliant with this document MUST accept all IP unicast transmissions over any of the IPoIB modes it supports. Multicast and broadcast packets by their nature will always be transmitted and received over the IPoIB-UD QP. Additionally, all address resolution responses (ARP or Neighbor Discovery) MUST always be encapsulated in a UD mode packet.
あらゆるIPoIBインタフェースがIPoIB-UDをサポートします。 それはさらに、IPoIB-CMモードの1か両方をサポートするかもしれません。 したがって、どんな2人の同輩の間でも交信する複数のメソッドがあることができます。 これは、インタフェースがそれと同輩の間でサポートされたモードに依存するRC、UC、またはUDモードのどれかの上にパケットを伝えるか、または受けるかもしれないのを含意します。 さらに、このドキュメントによる対応することのあらゆるIPoIB実装がそれがサポートするIPoIBモードのどれかの上にすべてのIPユニキャスト送信を受け入れなければならないということになります。 いつも本質的にマルチキャストと放送パケットをIPoIB-UD QPの上に送信して、受け取るでしょう。 さらに、UDモードパケットでいつもすべてのアドレス解決応答(ARPかNeighborディスカバリー)をカプセル化しなければなりません。
7.1. A Cautionary Note on IPoIB-RC
7.1. IPoIB-RCに関する警告的な注
The RC mode of InfiniBand guarantees in-order delivery of packets. Every message transmitted over the RC connection is broken into physical MTU-sized packets by the RC connection. If any packet is lost, it is retransmitted until the complete message is exchanged. Therefore, there is a possibility of an upper transport layer experiencing a timeout, while the RC layer is still in the process of transferring the complete message. TCP will view the timeout as an indicator of congestion and enter slow-start thereby affecting throughput drastically [RFC2581]. Other upper-layer protocols might insert retransmissions into the fabric, adding to the already existing congestion.
インフィニバンドのRCモードはオーダーにおけるパケットの配信を保証します。 RC接続による物理的なMTUサイズのパケットはRC接続の上に送られたあらゆるメッセージに細かく分けられます。 どれかパケットが無くなるなら、それは完全なメッセージを交換するまで再送されます。 したがって、上側のトランスポート層がタイムアウトになる可能性があります、まだ完全なメッセージを移すことの途中にRC層がありますが。 TCPは、スループットに抜本的[RFC2581]に影響しながら、混雑のインディケータであるとタイムアウトをみなして、その結果遅れた出発を入れるでしょう。 既に既存の混雑の一助となって、他の上側の層のプロトコルは「再-トランスミッション」を骨組みに挿入するかもしれません。
The applicability of Infiniband reliability is on a fabric with short latencies (not wide area). Therefore, the RC timer values should be short compared with the starting minimum time values used by the upper end-to-end transports. In addition, because the RC mode does not have measurement-based reliable transmission, its use over fabrics with long latency or very dynamic latency may be a concern for congestion-aware traffic traversing those fabrics.
骨組みの上にInfinibandの信頼性の適用性が短い潜在(広い領域でない)と共にあります。 したがって、終わりから終わりへの上側の輸送で使用される始めの最小の時間的価値と比べて、RCタイマ値は短いはずです。 さらに、長い潜在か非常にダイナミックな潜在がある骨組みの使用は、RCモードには測定ベースの信頼できるトランスミッションがないので、それらの骨組みを横断する混雑意識しているトラフィックに関する心配であるかもしれません。
7.2. IPoIB-CM Per-Destination MTU
7.2. 1目的地あたりのIPoIB-CM MTU
As described above, interfaces on the same subnet may support different link MTUs based on the negotiated value or due to the link type (UD or connected mode). Therefore, an implementation might choose to define a large IP MTU, which is reduced based on the MTU to the destination. The relevant MTU may be stored in a suitable per- destination object, such as a route cache or a neighbor cache. The per-destination MTU is known to the IPoIB-CM interface as described in Section 5.
上で説明されるように、同じサブネットのインタフェースは交渉された値に基づいたリンク型(UDか関連モード)のため異なったリンクMTUsをサポートするかもしれません。 したがって、実装は、大きいIP MTUを定義するのを選ぶかもしれません。(IP MTUは目的地へのMTUに基づいて減少します)。 関連MTUが適当なaに保存されるかもしれない、-、経路キャッシュか隣人キャッシュなどの目的地オブジェクト。 目的地MTUはセクション5で説明されるIPoIB-CMインタフェースに知られています。
Kashyap Standards Track [Page 10] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[10ページ]RFC4755
Implementations might choose not to support differing MTU values and always support an MTU equal to the IPoIB-UD MTU determined from the broadcast GID.
実装は、異なったMTU値をサポートして、いつも放送GIDによって断固としたIPoIB-UD MTUと等しいMTUはサポートするというわけではないのを選ぶかもしれません。
8. Security Considerations
8. セキュリティ問題
An impostor may return a false set of flags to an IPOIB interface. This may cause unnecessary attempts and some delay/disruption in IPoIB communication. The same is the case if wrong/spurious QPN values are provided during address resolution broadcast/multicast.
詐欺師は1つの偽凝結の旗をIPOIBインタフェースに返すかもしれません。 これはIPoIBコミュニケーションにおける不要な試みと何らかの遅れ/分裂を引き起こすかもしれません。 アドレス解決放送/マルチキャストの間、間違ったか偽りのQPN値を提供するなら、同じくらいはケースです。
9. IANA Considerations
9. IANA問題
Future uses of the reserved bits and octets in the link-layer address (Section 3.1), Service-ID (Section 3.5), and "Private-Data Format" (Section 6) MUST be published as RFCs. This document requires that the reserved bits be set to zero on sends.
RFCsとしてリンクレイヤアドレス(セクション3.1)、Service-ID(セクション3.5)、および「個人的なデータの形式」(セクション6)の予約されたビットと八重奏の将来の用途を発行しなければなりません。 このドキュメントは、予約されたビットがゼロにオンなセットが発信するということであることを必要とします。
10. Acknowledgements
10. 承認
The author thanks the IPoIB Working Group for the various comments and suggestions. A special thanks to Bernie King-Smith and Dror Goldenberg for the detailed review and suggestions.
作者は様々なコメントと提案についてIPoIB作業部会に感謝します。 詳細なレビューと提案のためのバーニー・キング-スミスとドロール・ゴールデンバーグのおかげで特別番組。
11. Normative References
11. 引用規格
[IB_ARCH] InfiniBand Architecture Specification, version 1.2
www.infinibandta.org
[イブ_ARCH] インフィニバンドArchitecture Specification、バージョン1.2www.infinibandta.org
[RFC4392] Kashyap, V., "IP over InfiniBand (IPoIB) Architecture",
RFC 4392, April 2006.
[RFC4392] 2006年4月のKashyap、V.、「インフィニバンド(IPoIB)アーキテクチャの上のIP」RFC4392。
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over
InfiniBand (IPoIB)", RFC 4391, April 2006.
[RFC4391] チュウ、J.、および「インフィニバンド(IPoIB)の上のIPのトランスミッション」、RFC4391、2006年4月対Kashyap
[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月。
12. Informative References
12. 有益な参照
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control ", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
Kashyap Standards Track [Page 11] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[11ページ]RFC4755
Author's Address
作者のアドレス
Vivek Kashyap 15350, SW Koll Parkway Beaverton OR 97006
Vivek Kashyap15350、SW Koll Parkwayビーバートンか97006
Phone: +1 503 578 3422 EMail: vivk@us.ibm.com
以下に電話をしてください。 +1 3422年の503 578メール: vivk@us.ibm.com
Kashyap Standards Track [Page 12] RFC 4755 Connected Mode IPoIB December 2006
モードIPoIB2006年12月に接続されたKashyap標準化過程[12ページ]RFC4755
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(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, THE IETF TRUST, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信用、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kashyap Standards Track [Page 13]
Kashyap標準化過程[13ページ]
一覧
スポンサーリンク
