Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6559 IJ. Wijnands
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
M. Napierala
AT&T Labs
March 2012
A Reliable Transport Mechanism for PIM
Abstract
抽象
This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol.
この文書では、参加/プルーンのメッセージを送信するためのPIMプロトコルのための信頼性の高いトランスポート・メカニズムを定義します。これは、定期的な参加/プルーンのメッセージの送信および処理する必要がなくなります。信頼性の高いトランスポート・メカニズムは、トランスポートプロトコルとしてTCPまたはSCTPのいずれかを使用することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6559.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6559で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 6
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 6
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 7
3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 8
4. Establishing Transport Connections . . . . . . . . . . . . . . 9
4.1. Connection Security . . . . . . . . . . . . . . . . . . . 11
4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 11
4.3. Actions When a Connection Goes Down . . . . . . . . . . . 13
4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 14
4.5. On-Demand versus Pre-Configured Connections . . . . . . . 14
4.6. Possible Hello Suppression Considerations . . . . . . . . 15
4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 15
5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 16
5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 18
5.2. PORT Keep-Alive Message . . . . . . . . . . . . . . . . . 19
5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 21
5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 21
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 22
7. Support of Multiple Address Families . . . . . . . . . . . . . 23
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Transport Considerations . . . . . . . . . . . . . . . . . . . 23
10. Manageability Considerations . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 25
12.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 25
12.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 26
12.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . . 28
The goals of this specification are:
この仕様の目的は次のとおりです。
o To create a simple incremental mechanism to provide reliable PIM Join/Prune message delivery in PIM version 2 for use with PIM Sparse-Mode (PIM-SM) [RFC4601], including PIM Source-Specific Multicast (PIM-SSM), and Bidirectional PIM [RFC5015].
PIMソース固有マルチキャスト（PIM-SSM）、および双方向など信頼PIMは、PIMスパースモード（PIM-SM）で使用[RFC4601]のためのPIMバージョン2の/プルーンメッセージ配信に参加し提供するための簡単な増分機構を作成するには、O、 PIM [RFC5015]。
o When a router supports this specification, it need not use the reliable transport mechanism with every neighbor. It can be negotiated on a per-neighbor basis.
ルータはこの仕様をサポートしている場合は、O、それはすべてのネイバーと信頼性の高いトランスポートメカニズムを使用する必要はありません。これは、ネイバーごとに交渉することができます。
The explicit non-goals of this specification are:
この仕様の明示的な非目的は次のとおりです。
o Making changes to the PIM message formats as defined in [RFC4601].
[RFC4601]で定義されるようにPIMメッセージフォーマットに変更を加えるO。
o Providing support for automatic switching between the reliable transport mechanism and the regular PIM mechanism defined in [RFC4601]. Two routers that are PIM neighbors on a link will always use the reliable transport mechanism if and only if both have enabled support for the reliable transport mechanism.
信頼性の高いトランスポート機構と[RFC4601]で定義された定期的なPIM機構との間の自動切り替えのためのサポートを提供O。リンク上のPIMネイバーある2台のルータが常に両方が信頼できるトランスポート・メカニズムのサポートを有効にしている場合に限り、信頼性の高いトランスポート機構を使用します。
This document will specify how periodic Join/Prune message transmission can be eliminated by using TCP [RFC0793] or SCTP [RFC4960] as the reliable transport mechanism for Join/Prune messages. The destination port number is 8471 for both TCP and SCTP.
この文書では、/プルーンメッセージに参加するための信頼できるトランスポートメカニズムとしてTCP [RFC0793]またはSCTP [RFC4960]を使用することによって解消することができる方法を定期的に参加/プルーンメッセージ送信を指定します。宛先ポート番号はTCPとSCTPの両方のための8471です。
This specification enables greater scalability in terms of control-traffic overhead. However, for routers connected to multi-access links, scalability comes at the price of increased PIM state and the overhead required to maintain this state.
この仕様は、制御トラフィックのオーバーヘッドの面でスケーラビリティを可能にします。しかし、マルチアクセスリンクに接続されたルータのため、スケーラビリティが増加PIM状態と、この状態を維持するために必要なオーバーヘッドの代償します。
In many existing and emerging networks, particularly wireless and mobile satellite systems, link degradation due to weather, interference, and other impairments can result in temporary spikes in the packet loss rate. In these environments, periodic PIM joining can cause join latency when messages are lost, causing a retransmission only 60 seconds later. By applying a reliable transport, a lost Join is retransmitted rapidly. Furthermore, when the last user leaves a multicast group, any lost Prune is similarly repaired, and the multicast stream is quickly removed from the wireless/satellite link. Without a reliable transport, the multicast transmission could otherwise continue until it timed out, roughly 3 minutes later. As network resources are at a premium in many of these environments, rapid termination of the multicast stream is critical for maintaining efficient use of bandwidth.
天候、干渉、および他の障害には多くの既存および新興のネットワーク、特に無線およびモバイル衛星システム、リンク劣化でパケット損失率が一時的に急増につながることができます。これらの環境では、参加する定期的なPIMは、わずか60秒後に再送を引き起こし、メッセージが失われたときに、待ち時間に参加引き起こす可能性があります。信頼性の高いトランスポートを適用することにより、失われた急速に再送されている参加します。最後に、ユーザは、マルチキャストグループを離れるときさらに、任意の失われたプルーンも同様に修復され、およびマルチキャストストリームはすぐに無線/衛星リンクから削除されます。それはおよそ3分後、タイムアウトしたまで信頼性の高い輸送がなければ、マルチキャスト伝送は、それ以外の場合は続けることができます。ネットワークリソースは、これらの環境の多くに貴重であるとして、マルチキャストストリームの迅速な終端は、帯域幅の効率的な利用を維持するために重要です。
This is an experimental extension to PIM. It makes some fundamental changes to how PIM works in that Join/Prune state does not require periodic updates, and it partly turns PIM into a hard-state protocol. Also, using reliable delivery for PIM messages is a new concept, and it is likely that experiences from early implementations and deployments will lead to at least minor changes in the protocol. Once there is some deployment experience, making this a Standards Track protocol should be considered. Experiments using this protocol only require support by pairs of PIM neighbors, and need not be constrained to isolated networks.
これは、PIMに実験的な拡張機能です。これは、PIMは、その参加/プルーンの状態は、定期的な更新を必要としない、そしてそれは、部分的にハードステートプロトコルにPIMをオンにどのように機能するかにいくつかの基本的な変更を加えます。また、PIMメッセージのための信頼性の高い配信を使用すると、新しい概念であり、初期の実装と展開の経験がプロトコルで少なくともマイナーな変更につながる可能性があります。一度、いくつかの展開の経験は、この標準化過程プロトコルを考慮すべきで作り、そこにあります。このプロトコルを用いた実験では唯一のPIMネイバーのペアによる支援を必要とし、分離されたネットワークに拘束される必要はありません。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
PORT: Stands for PIM Over Reliable Transport, which is the short form for describing the mechanism in this specification where PIM can use the TCP or SCTP transport protocol.
PORTは：PIMはTCP又はSCTPトランスポートプロトコルを使用することができ、本明細書に機構を説明するための短縮形で信頼性の高いトランスポートを介しPIMを表します。
Periodic Join/Prune message: A Join/Prune message sent periodically to refresh state.
定期的な参加/プルーンのメッセージ：状態をリフレッシュするために定期的に送信参加/プルーンのメッセージ。
Incremental Join/Prune message: A Join/Prune message sent as a result of state creation or deletion events. Also known as a triggered message.
状態の作成や削除の事象の結果として送ら参加/プルーンのメッセージ：インクリメンタルには、/プルーンのメッセージに参加します。また、トリガーメッセージとして知られています。
Native Join/Prune message: A Join/Prune message that is carried with an IP protocol type of PIM.
PIMのIPプロトコルタイプで行われる参加/プルーンのメッセージ：ネイティブ/プルーンのメッセージに参加します。
PORT Join/Prune message: A Join/Prune message using TCP or SCTP for transport.
輸送のためのTCPまたはSCTPを使用して参加/プルーンのメッセージ：PORTは/プルーンのメッセージに参加します。
Datagram Mode: The procedures whereby PIM encapsulates triggered or periodic Join/Prune messages in IP packets.
データグラムモード：PIMはIPパケットに/プルーンのメッセージを参加トリガーまたは定期的にカプセル化することにより手続き。
PORT Mode: The procedures used by PIM and defined in this specification for sending Join/Prune messages over the TCP or SCTP transport layer.
PORTモード：手順PIMによって使用され、TCPまたはSCTPトランスポート層の上に参加/プルーンのメッセージを送信するために、この仕様で定義されています。
PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for refresh reduction of PIM Join/Prune messages. It involves sending incremental rather than periodic Join/Prune messages over a TCP/SCTP connection between PIM neighbors.
信頼性の高いトランスポート（PORT）以上のPIMは、参加PIMのリフレッシュ削減/プルーンのメッセージのためのPIMv2への単純な拡張です。これは、PIMネイバー間のTCP / SCTP接続上で、増分ではなく、定期的に参加/プルーンのメッセージを送信するよりも必要とします。
PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM [RFC5015] Join/Prune messages.
PORTは、唯一のPIMスパースモード[RFC4601]に適用され、双方向PIM [RFC5015]は/プルーンのメッセージに参加します。
This document does not restrict PORT to any specific link types. However, the use of PORT on, e.g., multi-access LANs with many PIM neighbors should be carefully evaluated. This is due to the facts that there may be a full mesh of PORT connections and that explicit tracking of all PIM neighbors is required.
このドキュメントは、任意の特定のリンクタイプにPORTを制限するものではありません。しかし、上のポートの使用は、例えば、多くのPIMネイバーとのマルチアクセスLANは慎重に評価する必要があります。これは、PORT接続のフルメッシュとすべてのPIMネイバーの明示的なトラッキングが必要とされるがあるかもしれないことを事実によるものです。
PORT can be incrementally used on a link between PORT-capable neighbors. Routers that are not PORT-capable can continue to use PIM in Datagram mode. PORT capability is detected using new PORT-Capable PIM Hello Options.
PORTは、インクリメンタルPORT対応ネイバー間のリンク上で使用することができます。 PORTに対応していないルータはデータグラムモードでPIMを使用し続けることができます。 PORTの機能は、新しいPORT対応のPIMこんにちはオプションを使用して検出されます。
Once PORT is enabled on an interface and a PIM neighbor also announces that it is PORT enabled, only PORT Join/Prune messages will be used. That is, only PORT Join/Prune messages are accepted from, and sent to, that particular neighbor. Native Join/Prune messages are still used for PIM neighbors that are not PORT enabled.
PORTは、インターフェイスとPIMネイバー上で有効にされた後も、それはPORTだけポートが使用されます/プルーンのメッセージに参加し、有効であることを発表しました。それは、唯一のPORT参加/プルーンのメッセージがから受け入れ、そしてその特定の隣人に送られています。プルーン/参加ネイティブのメッセージはまだPORTが有効になっていないPIMネイバーのために使用されています。
PORT Join/Prune messages are sent using a TCP/SCTP connection. When two PIM neighbors are PORT enabled, both for TCP or both for SCTP, they will immediately, or on demand, establish a connection. If the connection goes down, they will again immediately, or on demand, try to reestablish the connection. No Join/Prune messages (neither Native nor PORT) are sent while there is no connection. Also, any received native Join/Prune messages from that neighbor are discarded, even when the connection is down.
PORTは/参加プルーンのメッセージは、TCP / SCTP接続を使用して送信されます。 2つのPIMネイバーがポートがTCPまたは両方SCTPの両方に対応しているとき、彼らはすぐに、またはオンデマンドで、接続を確立します。接続がダウンした場合、彼らは再びすぐに、またはオンデマンドで、接続を再確立しようとします。いいえ接続がないながら/プルーンのメッセージ（ネイティブもPORTでもないが）送信され参加しません。また、任意のは、その隣人からネイティブの参加/プルーンのメッセージは、接続がダウンした場合でも、破棄されました。
When PORT is used, only incremental Join/Prune messages are sent from downstream routers to upstream routers. As such, downstream routers do not generate periodic Join/Prune messages for state for which the Reverse Path Forwarding (RPF) neighbor is PORT-capable.
PORTを使用する場合は、増分のみ参加/プルーンのメッセージは、上流のルータにダウンストリームルータから送信されます。こうした、下流のルータはリバースパス転送（RPF）隣人のために国家のために定期的に参加/プルーンのメッセージを生成しないようPORT対応です。
For Joins and Prunes that are received over a TCP/SCTP connection, the upstream router does not start or maintain timers on the outgoing interface entry. Instead, it keeps track of which downstream routers have expressed interest. An interface is deleted from the outgoing interface list only when all downstream routers on the interface no longer wish to receive traffic. If there also are native Joins/ Prunes from a non-PORT neighbor, then a router can maintain timers on the outgoing interface entry as usual, while at the same time keep track of each of the downstream PORT Joins/Prunes.
参加およびTCP / SCTP接続を介して受信されたプルーンの場合は、上流のルータは、発信インターフェイスエントリのタイマーを起動したり、維持しません。その代わりに、下流のルータが関心を表明しているのを追跡します。インターフェイスは、インターフェイス上のすべてのダウンストリームルータは、もはやトラフィックを受信したい場合にのみ、発信インターフェイスリストから削除されません。また、/非PORTの隣人からプルーンをネイティブが参加している場合は、同時にダウンストリームポートのそれぞれを追跡しながら、ルータは、いつものように発信インターフェイスエントリにタイマーを維持することができます/プルーンを結合します。
This document does not update the PIM Join/Prune packet format. In the procedures described in this document, each PIM Join/Prune message is included in the payload of a PORT message carried over TCP/SCTP. See Section 5 for details on the PORT message.
この文書では、PIM参加/プルーンのパケットフォーマットを更新しません。この文書に記載されている手順では、各PIM参加/プルーンメッセージは、TCP / SCTP上で搬送PORTメッセージのペイロードに含まれています。 PORTメッセージの詳細については、第5章を参照してください。
Option Type: PIM-over-TCP-Capable
オプションタイプ：PIM-over-TCPの対応
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 = 27 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Hello Type values can be found in [HELLO-OPT].
割り当てられたこんにちはタイプ値は、[ハロー-OPT]で見つけることができます。
When a router is configured to use PIM over TCP on a given interface, it MUST include the PIM-over-TCP-Capable Hello Option in its Hello messages for that interface. If a router is explicitly disabled from using PIM over TCP, it MUST NOT include the PIM-over-TCP-Capable Hello Option in its Hello messages.
ルータが特定のインターフェイス上でTCP上でPIMを使用するように設定されている場合、そのインターフェイスのためのhelloメッセージでPIM-over-TCPの対応こんにちはオプションを含まなければなりません。ルータが明示的にTCP上でPIMを使用してから無効になっている場合、それはそのhelloメッセージでPIM-over-TCPの対応こんにちはオプションを含んではいけません。
All Hello messages containing the PIM-over-TCP-Capable Hello Option MUST also contain the Interface ID Hello Option, see Section 3.3.
PIM-over-TCPの対応こんにちはオプションを含むすべてのHelloメッセージはまた、3.3節を参照してください、インタフェースIDこんにちはオプションを含まなければなりません。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
実装はPORTの機能を有効または無効にする設定オプションを提供してもよいです。この機能はデフォルトで無効にすることをお勧めします。
Length: Length in bytes for the value part of the Type/Length/Value encoding, where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 when AFI of value 0 is used.
長さ：タイプ/長さ/値の符号の値部分のバイト単位の長さ、Xは、接続IDフィールドを構成するバイトの数です。 Xは、値1のAFI（IPv4の）は[AFI]、値2のAFI（IPv6）の[AFI]が使用されている16、および値0のAFIを使用する0使用される4です。
TCP Connection ID AFI: The AFI value to describe the address family of the address of the TCP Connection ID field. Note that this value does not need to match the address family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection.
TCPコネクションID AFI：AFI値は、TCPコネクションIDフィールドのアドレスのアドレスファミリを記述します。この値は、それを運ぶPIM Helloメッセージのアドレスファミリに一致する必要はないことに注意してください。このフィールドが0である場合には、この文書の範囲外のメカニズムは、TCP接続を確立するために使用されるアドレスを取得するために使用されます。
Reserved: Set to zero on transmission and ignored on receipt.
予約：送信時にゼロに設定して、領収書の上で無視。
Exp: For experimental use [RFC3692]. One expected use of these bits would be to signal experimental capabilities. For example, if a router supports an experimental feature, it may set a bit to indicate this. The default behavior, unless a router supports a particular experiment, is to ignore the bits on receipt.
EXP：実験用[RFC3692]。これらのビットの1つの予想される使用は、実験的な機能を知らせることであろう。ルータは実験的な機能をサポートしている場合、それはこのことを示すためにビットを設定することができます。ルータが特定の実験をサポートしていない限り、デフォルトの動作は、レシート上のビットを無視することです。
TCP Connection ID: An IPv4 or IPv6 address used to establish the TCP connection. This field is omitted (length 0) for the Connection ID AFI 0.
TCPコネクションID：TCPコネクションを確立するために使用されるIPv4またはIPv6アドレス。このフィールドは、接続ID AFI 0（長さ0）は省略されています。
Option Type: PIM-over-SCTP-Capable
オプションタイプ：PIM-オーバーSCTP対応
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 = 28 | Length = 4 + X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | Exp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assigned Hello Type values can be found in [HELLO-OPT].
割り当てられたこんにちはタイプ値は、[ハロー-OPT]で見つけることができます。
When a router is configured to use PIM over SCTP on a given interface, it MUST include the PIM-over-SCTP-Capable Hello Option in its Hello messages for that interface. If a router is explicitly disabled from using PIM over SCTP, it MUST NOT include the PIM-over-SCTP-Capable Hello Option in its Hello messages.
ルータが特定のインターフェイス上でSCTP上でPIMを使用するように設定されている場合、そのインターフェイスのためのhelloメッセージでPIM-オーバーSCTP対応こんにちはオプションを含まなければなりません。ルータが明示的にSCTP上でPIMを使用してから無効になっている場合、それはそのhelloメッセージでPIM-オーバーSCTP対応こんにちはオプションを含んではいけません。
All Hello messages containing the PIM-over-SCTP-Capable Hello Option MUST also contain the Interface ID Hello Option; see Section 3.3.
PIM-オーバーSCTP対応こんにちはオプションを含むすべてのHelloメッセージは、インタフェースIDこんにちはオプションを含まなければなりません。 3.3節を参照してください。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
実装はPORTの機能を有効または無効にする設定オプションを提供してもよいです。この機能はデフォルトで無効にすることをお勧めします。
Length: Length in bytes for the value part of the Type/Length/Value encoding, where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 when AFI of value 0 is used.
長さ：タイプ/長さ/値の符号の値部分のバイト単位の長さ、Xは、接続IDフィールドを構成するバイトの数です。 Xは、値1のAFI（IPv4の）は[AFI]、値2のAFI（IPv6）の[AFI]が使用されている16、および値0のAFIを使用する0使用される4です。
SCTP Connection ID AFI: The AFI value to describe the address family of the address of the SCTP Connection ID field. Note that this value does not need to match the address family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection.
SCTPコネクションID AFI：AFI値は、SCTPコネクションIDフィールドのアドレスのアドレスファミリを記述します。この値は、それを運ぶPIM Helloメッセージのアドレスファミリに一致する必要はないことに注意してください。このフィールドが0である場合、本文書の範囲外の機構は、SCTPコネクションを確立するために使用されるアドレスを取得するために使用されます。
Reserved: Set to zero on transmission and ignored on receipt.
予約：送信時にゼロに設定して、領収書の上で無視。
Exp: For experimental use [RFC3692]. One expected use of these bits would be to signal experimental capabilities. For example, if a router supports an experimental feature, it may set a bit to indicate this. The default behavior, unless a router supports a particular experiment, is to ignore the bits on receipt.
EXP：実験用[RFC3692]。これらのビットの1つの予想される使用は、実験的な機能を知らせることであろう。ルータは実験的な機能をサポートしている場合、それはこのことを示すためにビットを設定することができます。ルータが特定の実験をサポートしていない限り、デフォルトの動作は、レシート上のビットを無視することです。
SCTP Connection ID: An IPv4 or IPv6 address used to establish the SCTP connection. This field is omitted (length 0) for the Connection ID AFI 0.
SCTPコネクションID：SCTPコネクションを確立するために使用されるIPv4またはIPv6アドレス。このフィールドは、接続ID AFI 0（長さ0）は省略されています。
All Hello messages containing PIM-over-TCP-Capable or PIM-over-SCTP-Capable Hello Options MUST also contain the Interface ID Hello Option [RFC6395].
PIM-over-TCPの対応やPIM-オーバーSCTP対応含むすべてのHelloメッセージこんにちはオプションもインターフェイスIDこんにちはオプション[RFC6395]を含まなければなりません。
The Interface ID is used to associate a PORT Join/Prune message with the PIM neighbor from which it is coming. When unnumbered interfaces are used or when a single transport connection is used for sending and receiving Join/Prune messages over multiple interfaces, the Interface ID is used to convey the interface from Join/Prune message sender to Join/Prune message receiver. The value of the Interface ID Hello Option in Hellos sent on an interface MUST be the same as the Interface ID value in all PORT Join/Prune messages sent to a PIM neighbor on that interface.
インターフェイスIDは、それが来て、そこからのPIMネイバーとPORT参加/プルーンのメッセージを関連付けるために使用されます。単一のトランスポート接続を送信し、複数のインターフェイス上/プルーンメッセージに参加し受信するために使用される場合、インタフェースIDを/参加プルーンメッセージ送信者からインタフェースを伝えるために使用されたときに無数のインタフェースが使用されるか、または/プルーンメッセージ受信に参加します。インターフェイス上で送信されたハローズのインタフェースIDこんにちはオプションの値は、そのインターフェイス上のPIMネイバーに送信される/プルーンのメッセージに参加し、すべてのポートにインターフェイスIDの値と同じでなければなりません。
The Interface ID need only uniquely identify an interface of a router; it does not need to identify to which router the interface belongs. This means that the Router ID part of the Interface ID MAY be 0. For details on the Router ID and the value 0, see [RFC6395].
インタフェースIDは、一意のルータのインタフェースを識別する必要があります。それは、インターフェイスが属するルータこれに特定する必要はありません。これは、インタフェースIDのルータID部分は[RFC6395]を参照して、ルータIDと値0については0とすることができることを意味します。
While a router interface is PORT enabled, a PIM-over-TCP-Capable or a PIM-over-SCTP-Capable Option MUST be included in the PIM Hello messages sent on that interface. When a router on a PORT-enabled interface receives a Hello message containing a PIM-over-TCP-Capable/ PIM-over-SCTP-Capable Option from a new neighbor, or an existing neighbor that did not previously include the option, it switches to PORT mode for that particular neighbor.
ルータインターフェイスはポートが有効になっている間、PIM-over-TCPの対応やPIM-オーバーSCTP対応のオプションは、そのインターフェイス上で送信されたPIM Helloメッセージに含まれなければなりません。 PORT対応のインターフェイス上のルータが新しい隣人、または以前にオプションが含まれていない既存の隣人からPIM-over-TCPの対応/ PIM-オーバーSCTP可能なオプションを含むHelloメッセージを受信すると、スイッチその特定の隣人のためのPORTモードに。
When a router switches to PORT mode for a neighbor, it stops sending and accepting Native Join/Prune messages for that neighbor. Any state from previous Native Join/Prune messages is left to expire as normal. It will also attempt to establish a transport connection (TCP or SCTP) with the neighbor. If both the router and its neighbor have announced both PIM-over-TCP-Capable and PIM-over-SCTP-Capable Options, SCTP MUST be used. This resolves the issue where two transports are both offered. The method prefers SCTP over TCP, because SCTP has benefits such as handling of call collisions and support for multiple streams, as discussed later in this document.
ルータが隣人のためにPORTモードに切り替わると、それは、送信側とネイティブはその隣人のために/プルーンのメッセージを参加受け入れを停止します。以前のネイティブからの任意の状態に参加/プルーンのメッセージは通常通りに期限切れに残されています。また、隣人とのトランスポート接続（TCPまたはSCTP）を確立しようとします。ルータとその隣の両方が、PIM-over-TCPの対応とPIM-オーバーSCTP可能なオプションの両方を発表している場合は、SCTPを使用しなければなりません。これは、2つのトランスポートの両方が提供されている問題を解決します。 SCTPは、複数のストリームのためのコール衝突の取り扱いやサポートなどの利点があるため、このドキュメントで後述するような方法は、TCP上でSCTPを好みます。
When the router is using TCP, it will compare the TCP Connection ID it announced in the PIM-over-TCP-Capable Option with the TCP Connection ID in the Hello received from the neighbor. Unless connections are opened on demand (see below), the router with the lower Connection ID MUST do an active transport open to the neighbor Connection ID. The router with the higher Connection ID MUST do a passive transport open. An implementation MAY open connections only on demand; in that case, it may be that the neighbor with the higher Connection ID does the active open (see Section 4.5). If the router with the lower Connection ID chooses to only do an active open on demand, it MUST do a passive open, allowing for the neighbor to initiate the connection. Note that the source address of the active open MUST be the announced Connection ID.
ルータはTCPを使用している場合は、それが隣人から受け取っこんにちはにおけるTCPコネクションIDを持つPIM-over-TCPの対応のオプションに発表されたTCPコネクションIDを比較します。接続が（下記参照）、オンデマンドで開かれている場合を除き、下部接続IDを持つルータがネイバー接続IDにオープン能動輸送を行う必要があります。高いコネクションIDを持つルータが受動輸送が開いて行う必要があります。実装は、オンデマンドでのみ接続を開くことができ、その場合には、より高い接続IDを持つネイバーがアクティブオープンを（4.5節を参照）している可能性があります。下部接続IDを持つルータはオンデマンドでのみアクティブオープンを行うことを選択した場合、それは接続を開始するために隣人を可能にし、パッシブオープンを行う必要があります。アクティブなオープンソースのアドレスが発表された接続IDでなければならないことに注意してください。
When the router is using SCTP, the IP address comparison need not be done since the SCTP protocol can handle call collision.
ルータがSCTPを使用している場合はSCTPプロトコルは、コールの衝突を扱うことができるため、IPアドレスの比較が行われる必要がありません。
The decisions whether to use PORT, which transport to use, and which Connection IDs to use are made independently for IPv4 and IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello messages MUST be sent, both containing PORT Hello Options. If two neighbors announce the same transport (TCP or SCTP) and the same Connection IDs in the IPv4 and IPv6 Hello messages, then only one connection is established and is shared. Otherwise, two connections are established and are used separately.
トランスポートが使用するポートを使用するかどうかの決定、およびその接続IDを使用するには、IPv4とIPv6のために独立して作られています。 PORTは、IPv4とIPv6の両方のために使用されている場合このように、IPv4およびIPv6 PIM Helloメッセージの両方が両方ともPORTこんにちはオプションを含む、送らなければなりません。 2つのネイバーは、IPv4とIPv6のHelloメッセージに同じトランスポート（TCPまたはSCTP）と同じ接続IDをアナウンスした場合、1つだけの接続が確立され、共有されています。それ以外の場合は、2つの接続が確立され、別々に使用されています。
The PIM router that performs the active open initiates the connection with a locally generated source transport port number and a well-known destination transport port number. The PIM router that performs the passive open listens on the well-known local transport port number and does not qualify the remote transport port number. See Section 5 for the well-known port number assignment for PORT.
アクティブオープンを行うPIMルータは、ローカルに生成されたソーストランスポートポート番号と周知の宛先トランスポートポート番号との接続を開始します。パッシブオープンを行い、PIMルータは、よく知られている地元の交通機関のポート番号をリッスンし、リモートトランスポートのポート番号を資格はありません。 PORTのためのよく知られたポート番号の割り当てについては、セクション5を参照してください。
When a transport connection is established (or reestablished), the two routers MUST both send a full set of Join/Prune messages for state for which the other router is the upstream neighbor. This is needed to ensure that the upstream neighbor has the correct state. When moving from Datagram mode, or when the connection has gone down, the router cannot be sure that all the previous Join/Prune state was received by the neighbor. Any state that was created before the connection was established (or reestablished) and that is not refreshed MUST be left to expire and be deleted. When the non-refreshed state has expired and been deleted, the two neighbors will be in sync.
トランスポート接続が確立（または再確立）されると、2つのルータが他のルータが上流隣接されている状態のための参加/プルーンメッセージのフルセットを送信しなければなりません両方。これは、上流の隣人が正しい状態であることを確認するために必要とされます。データグラムモードから移動した場合、接続がダウンしたとき、または、ルータは以前のすべての参加/プルーンの状態は隣人によって受信されたことを確認することはできません。接続が確立（または再確立）して前に作成された、それがリフレッシュされない任意の状態を期限切れにして削除することが残されなければなりません。非リフレッシュ状態の有効期限が切れていると削除されたとき、2人の隣人は同期になります。
When not running PORT, a full update is only needed when a router restarts; with PORT, it must be done every time a connection is established. This can be costly, although it is expected that a PORT connection will go up and down rarely. There may be a need for extensions to better handle this.
PORTを実行していない場合は、完全な更新をする場合にのみ、ルータの再起動を必要とされています。 PORTと、それは、接続が確立されるたびに行われなければなりません。 PORT接続が上下まれて行くことが期待されるが、これは、コストがかかります。拡張子が良いこれを処理するために必要があるかもしれません。
It is possible that a router starts sending Hello messages with a new Connection ID, e.g., due to configuration changes. A router MUST always use the last announced and last seen Connection IDs. A connection is identified by the local Connection ID (the one we are announcing on a particular interface), and the remote Connection ID (the one we are receiving from a neighbor on the same interface). When either the local or remote ID changes, the Connection ID pair we need a connection for changes. There may be an existing connection with the same pair, in which case the router will share that connection. Or, a new connection may need to be established. Note that for link-local addresses, the interface should be regarded as part of the ID, so that connection sharing is not attempted when the same link-local addresses are seen on different interfaces.
ルータが原因構成の変更に、例えば、新しい接続IDでのHelloメッセージの送信を開始することが可能です。ルータは常に最後に発表し、最後に見た接続IDを使用しなければなりません。接続は、ローカル接続ID（私たちは、特定のインターフェイス上で発表されているもの）、およびリモート接続ID（私たちは、同じインターフェイス上でネイバーから受信しているもの）によって識別されます。ローカルまたはリモートIDの変更、接続IDのペアのどちらかは、我々は、変更のための接続を必要とするとき。ルータはその接続を共有します。その場合には同じペア、との既存の接続があるかもしれません。それとも、新しい接続を確立する必要があるかもしれません。同じリンクローカルアドレスが異なるインタフェース上で見られるときに、接続の共有を試行しないようにリンクローカルアドレスに、インターフェースは、IDの一部として見なされるべきであることに留意されたいです。
When a Connection ID changes, if the previously used connection is not needed (i.e., there are no other PIM neighborships using the same Connection ID pair), both peers MUST attempt to reset the transport connection. Next (even if the old connection is still needed), they MUST, unless a connection already exists with the new Connection ID pair, immediately or on demand attempt to establish a new connection with the new Connection ID pair.
以前に使用された接続が必要とされない場合、接続IDの変更は、（すなわち、同じ接続IDのペアを使用して、他のPIM neighborshipsは存在しない）、両方のピアは、トランスポート接続をリセットしようとしなければならない場合。次の接続はすでに、すぐに、または新しい接続IDのペアとの新しい接続を確立するために、オンデマンドの試みで、新しい接続IDのペアで存在しない限り、彼らはMUST、（古い接続がまだ必要とされている場合でも）。
Normally, the Interface ID would not change while a connection is up. However, if it does, the change does not affect the connection. It just means that when subsequent PORT Join/Prune messages are received, they should be matched against the last seen Interface ID.
接続がアップしている間、通常、インタフェースIDは変更されません。それがない場合は、変更が接続に影響を与えません。それはちょうど、後続のPORT参加/プルーンのメッセージを受信したとき、彼らは最後に見たインタフェースIDと照合しなければならないことを意味しています。
Note that a Join sent over a transport connection will only be seen by the upstream router; thus, it will not cause non-PORT routers on the link with the upstream router to delay the refresh of Join state for the same state. Similarly, a Prune sent over a transport connection will only be seen by the upstream router; thus, it will never cause non-PORT routers on the link with the upstream router to send a Join to override this Prune.
だけ上流のルータによって見られるトランスポート接続を介して送信される入会ことに注意してください。したがって、それは同じ状態の状態を参加のリフレッシュを遅らせるために上流のルータとのリンク上の非PORTルータが発生することはありません。同様に、トランスポート接続を介して送信されるプルーンは、上流のルータによって理解されるであろう。したがって、それはこのプルーンを上書きするために参加送信するアップストリームルータとのリンク上の非PORTルータを引き起こすことはありません。
Note also that a datagram PIM Join/Prune message for a said (S,G) or (*,G) sent by some router on a link will not cause routers on the same link that use a transport connection with the upstream router for that state to suppress the refresh of that state to the upstream router (because they don't need to periodically refresh this state) or to send a Join to override a Prune. The latter will not occur because the upstream router will only stop forwarding the traffic when all joined routers that use a transport connection have explicitly sent a Prune for this state, as explained in Section 6.
注また、リンクの上にいくつかのルータによって送信された（S、G）または（*、G）のためのデータグラムPIM参加/プルーンのメッセージは、そのためのアップストリームルータとのトランスポート接続を使用するのと同じリンク上のルータを起こさないことを（彼らは定期的にこの状態をリフレッシュする必要がないため）、またはプルーンをオーバーライドするために参加を送信するために上流のルータにその状態のリフレッシュを抑制する状態。セクション6で説明したように、トランスポート接続を使用するすべての参加ルータが明示的に、この状態のためのプルーンを送信したときに、上流ルータにのみトラフィックの転送を停止するので、後者は発生しないであろう。
TCP/SCTP packets used for PORT MUST be sent with a TTL/Hop Limit of 255 to facilitate the enabling of the Generalized TTL Security Mechanism (GTSM) [RFC5082]. Implementations SHOULD provide a configuration option to enable the GTSM check at the receiver. This means checking that inbound packets from directly connected neighbors have a TTL/Hop Limit of 255, but implementations MAY also allow for a different TTL/Hop Limit threshold to check that the sender is within a certain number of router hops. The GTSM check SHOULD be disabled by default.
ポートの使用TCP / SCTPパケットは一般TTLセキュリティメカニズム（GTSM）[RFC5082]の有効化を容易にするために、255のTTL /ホップリミットで送らなければなりません。実装は、受信機でGTSMチェックを有効にする設定オプションを提供する必要があります。これは、直接接続されたネイバーからインバウンドパケットは、255のTTL /ホップリミットを持っていることを確認する意味はなく、別のTTL /ホップ制限スレッショルドは、送信者がルータのホップの一定数の範囲内であることを確認するための実装も可能。 GTSMチェックは、デフォルトでは無効にする必要があります。
Implementations SHOULD support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP Authenticated Chunks [RFC4895].
実装は、TCP認証オプション（TCP-AO）[RFC5925]及びSCTP認証チャンク[RFC4895]をサポートすべきです。
TCP is designed to keep connections up indefinitely during a period of network disconnection. If a PIM-over-TCP router fails, the TCP connection may stay up until the neighbor actually reboots, and even then it may continue to stay up until PORT tries to send the neighbor some information. This is particularly relevant to PIM since the flow of Join/Prune messages might be in only one direction and the downstream neighbor might never get any indication via TCP that the other end of the connection is not really there.
TCPは、ネットワーク切断の期間中に無期限の接続を維持するように設計されています。 PIM-over-TCPのルータに障害が発生した場合は、隣人が実際に再起動するまでTCP接続が起きても、さらには、それはPORTが隣人にいくつかの情報を送信しようとまで滞在し続けることができます。これは、一方向のみであるかもしれない/参加プルーンのメッセージの流れからPIMに特に関連があると下流の隣人は、接続のもう一方の端は実際に存在しないTCP経由で任意の表示を取得することはありませんかもしれません。
SCTP has a heartbeat mechanism that can be used to detect that a connection is not working, even when no data is sent. Many TCP implementations also support sending keep-alives for this purpose. Implementations MAY make use of TCP keep-alives, but the PORT keep-alive mechanism defined below allows for more control and flexibility.
SCTPは、データが送信されていない場合でも、接続が機能していないことを検出するために用いることができるハートビート機構を備えています。多くのTCP実装はまた、この目的のためにキープアライブの送信をサポート。実装は、TCPの使用がキープアライブを行うことができますが、以下に定義PORTキープアライブメカニズムは、より多くの制御と柔軟性を可能にします。
One can detect that a PORT connection is not working by regularly sending PORT messages. This applies to both TCP and SCTP. For example, in the case of TCP, the connection will be reset if no TCP ACKs are received after several retries. PORT in itself does not require any periodic signaling. PORT Join/Prune messages are only sent when there is a state change. If the state changes are not frequent enough, a PORT Keep-Alive message (defined in Section 5.2) can be sent instead. For example, if an implementation wants to send a PORT message, to check that the connection is working, at least every 60 seconds, then whenever 60 seconds have passed since the previous message, a Keep-Alive message could be sent. If there were less than 60 seconds between each Join/Prune, no Keep-Alive messages would be needed. Implementations SHOULD support the use of PORT Keep-Alive messages. It is RECOMMENDED that a configuration option be available to network administrators to enable it when needed. Note that Keep-Alives can be used by a peer, independently of whether the other peer supports it.
一つは、PORT接続が定期的にPORTメッセージを送信することにより動作していないことを検出することができます。これは、TCPとSCTPの両方に適用されます。何のTCPのACKが、いくつかの再試行後に受信されていない場合たとえば、TCPの場合は、接続がリセットされます。自身のポートは、任意の周期のシグナリングを必要としません。 PORTは、状態変化があった場合にプルーンのメッセージのみが送信されます/参加します。状態変化が十分に頻繁でない場合、（セクション5.2で定義された）ポートキープ・アライブ・メッセージは、代わりに送信することができます。実装は、接続が機能していることを確認するために、少なくとも60秒ごとにPORTメッセージを送信したい場合は60秒前のメッセージ経過したときはいつでも、例えば、その後、キープアライブメッセージを送ることができます。それぞれの間に60秒未満は/プルーンに参加があった場合は、キープアライブメッセージは必要ないであろう。実装はPORTキープアライブメッセージの使用をサポートする必要があります。コンフィギュレーションオプションが必要なときにそれを有効にするには、ネットワーク管理者が使用できることが推奨されます。そのキープアライブは、独立して、他のピアがそれをサポートしているかどうかを、ピアで使用できます。
An implementation that supports Keep-Alive messages acts as follows when processing a received PORT message. When processing a Keep-Alive message with a non-zero Holdtime value, it MUST set a timer to the value. We call this timer Connection Expiry Timer (CET). If the CET is already running, it MUST be reset to the new value. When processing a Keep-Alive message with a zero Holdtime value, the CET (if running) MUST be stopped. When processing a PORT message other than a Keep-Alive, the CET MUST be reset to the last received Holdtime value if running. If the CET is not running, no action is taken. If the CET expires, the connection SHOULD be shut down. This specification does not mandate a specific default Holdtime value. However, the dynamic congestion and flow control in TCP and SCTP can result in variable transit delay between the endpoints. When capacity varies, there may be loss in the network or variable link performance. Consistent behavior therefore requires a sufficiently large Holdtime value, e.g., 60 seconds to prevent premature termination.
キープアライブメッセージの行為を受けPORTメッセージを処理するときに、次のようにサポートする実装。ゼロ以外のholdtime値とキープアライブメッセージを処理するとき、それは値にタイマーを設定しなければなりません。私たちは、このタイマー接続有効期限タイマー（CET）を呼び出します。 CETがすでに実行されている場合は、新しい値にリセットされなければなりません。ゼロホールドタイム値のキープ・アライブ・メッセージを処理するとき、CET（走行する場合）は停止しなければなりません。キープアライブ以外のポートメッセージを処理するときに実行している場合は、CETは、最後に受信したホールドタイムの値にリセットする必要があります。 CETが実行されていない場合、アクションは実行されません。 CETの有効期限が切れた場合は、接続がシャットダウンされるべきです。この仕様は、特定のデフォルトholdtime値は必須ではありません。しかし、TCPとSCTPにおける動的輻輳フロー制御は、エンドポイントとの間の可変伝送遅延をもたらすことができます。容量が変化した場合、ネットワークまたは可変リンク性能の損失があってもよいです。一貫性のある行動はそのため、早期終了を防ぐために、例えば、60秒を十分大きなホールドタイム値が必要です。
It is possible that a router receives Join/Prune messages for an interface/link that is down. As long as the neighbor has not expired, it is RECOMMENDED to process those messages as usual. If they are ignored, then the router SHOULD ensure it gets a full update for that interface when it comes back up. This can be done by changing the GenID (Generation Identifier; see [RFC4601]) or by terminating and reestablishing the connection.
ルータがダウンしているインタフェース/リンク用/プルーンJoinメッセージを受け取ることも可能です。限り隣人が満了していないとして、いつものようにそれらのメッセージを処理することをお勧めします。それらが無視されている場合、ルータはバックアップ来るとき、それはそのインターフェイスの完全更新を確実に受けるようにすべきです。または接続を終了し、再構築することによって、これはられたGenIDを変化させることにより（[RFC4601]を参照世代識別子）行うことができます。
If a PORT neighbor changes its GenID and a connection is established or is in the process of being established, the local side should generally tear down the connection and do as described in Section 4.3. However, if the connection is shared by multiple interfaces and the GenID changes for only one of them, the local side SHOULD simply send a full update, similar to other cases when a GenID changes for an upstream neighbor.
PORTの隣人がそのられたGenIDを変更し、接続が確立されるか確立の過程にある場合は、ローカル側は、一般的に接続を切断すべきであり、4.3節で説明したように行います。接続は、それらの一方のみのための複数のインタフェース及びられたGenID変化によって共有されている場合られたGenIDが上流隣接のために変更した場合しかし、ローカル側は、単に他の場合と同様、完全な更新を送信すべきです。
A connection may go down for a variety of reasons. It may be due to an error condition or a configuration change. A connection SHOULD be shut down as soon as there are no more PIM neighbors using it. That is, for the connection in question (and its associated local and remote Connection IDs), when there is no PIM neighbor with that particular remote Connection ID on any interface where we announce the local Connection ID, the connection SHOULD be shut down. This may happen when a new Connection ID is configured, PORT is disabled, or a PIM neighbor expires.
接続は、さまざまな理由で下がってもよいです。これは、エラー状態または構成の変更に起因する可能性があります。接続は、すぐにそれを使用してこれ以上のPIMネイバーが存在しないようにシャットダウンするべきです。それは我々がローカルコネクションIDを発表任意のインターフェイス上の特定のリモート接続IDとはPIMネイバーが存在しない場合、接続がシャットダウンされるべきで、当該の接続（およびそれに関連するローカルおよびリモート接続ID）のために、です。これは、新しい接続IDが設定されている場合、ポートが無効になっている、またはPIMネイバーの有効期限が切れる起こるかもしれません。
If a PIM neighbor expires, one should free connection state and downstream outgoing interface list (oif-list) state for that neighbor. A downstream router, when an upstream neighboring router has expired, will simply update the RPF neighbor for the corresponding state to a new neighbor where it would trigger Join/ Prune messages. This behavior is according to [RFC4601], which defines the term "RPF neighbor". It is required of a PIM router to clear its neighbor table for a neighbor who has timed out due to neighbor Holdtime expiration.
PIMネイバーが期限切れになった場合、人はその隣人のために接続状態と下流の発信インターフェイスリスト（OIFリスト）状態を解放する必要があります。下流のルータは、上流の隣接ルータの有効期限が切れているとき、単にそれは/プルーンJoinメッセージをトリガーする新しい隣人に対応する状態のためのRPF隣人を更新します。この現象は、用語「RPF隣人」を定義[RFC4601]に記載のものです。原因隣人ホールドタイムの有効期限にタイムアウトになった隣人のためにそのネイバーテーブルをクリアするには、PIMルータに要求されます。
When a connection is no longer available between two PORT-enabled PIM neighbors, they MUST immediately, or on demand, try to reestablish the connection following the normal rules for connection establishment. The neighbors MUST also start expiry timers so that all oif-list state for the neighbor using the connection gets expired after J/P_Holdtime, unless it later gets refreshed by receiving new Join/Prunes.
接続はもはや2 PORT対応のPIMネイバーの間で利用可能な場合、彼らはすぐにしなければならず、またはオンデマンドで、接続確立のための通常の規則次の接続を再確立しようとします。それは、後に新加入/プルーンを受信することでリフレッシュしますしない限り、接続を使用している隣人のために、すべてのOIFリスト状態は、J / P_Holdtime後に期限が切れますように、隣人にも有効期限のタイマーを起動する必要があります。
The value of J/P_Holdtime is 210 seconds. This value is based on Section 4.11 of [RFC4601], which says that J/P_HoldTime should be 3.5 * t_periodic where the default for t_periodic is 60 seconds.
J / P_Holdtimeの値は210秒です。この値は、J / P_HoldTimeがt_periodicのデフォルト値は60秒です3.5 * t_periodicなければならないことを言っている、[RFC4601]のセクション4.11に基づいています。
There may be situations where an administrator decides to stop using PORT. If PORT is disabled on a router interface, or a previously PORT-enabled neighbor no longer announces any of the PORT Hello Options, the router follows the rules in Section 4.3 for taking down connections and starting timers. Next, the router SHOULD trigger a full state update similar to what would be done if the GenID changed in Datagram mode. The router SHOULD send Join/Prune messages for any state where the router switched from PORT to Datagram mode for the upstream neighbor.
管理者がPORTの使用を停止することを決定した状況があるかもしれません。 PORTは、ルータインターフェイスで無効にされていない、または以前にPORT対応の隣人は、もはやPORTこんにちはオプションのいずれかを発表した場合、ルータは接続を降ろすとタイマーを起動するために、4.3節の規則に従います。次に、ルータはられたGenIDがデータグラムモードに変更された場合に行われるものと類似の完全な状態更新をトリガする必要があります。ルータは、ルータが上流の隣人のためのデータグラムモードにポートからスイッチングどんな状態で登録しよう/プルーンのメッセージを送るべきです。
Transport connections could be established when they are needed or when a router interface to other PIM neighbors has come up. The advantage of on-demand transport connection establishment is the reduction of router resources, especially in the case where there is no need for a full mesh of connections on a network interface. The disadvantage is additional delay and queueing when a Join/Prune message needs to be sent and a transport connection is not established yet.
それらが必要なときにトランスポート接続が確立することができたり、他のPIMネイバーへのルータインターフェイスが来ているとき。オンデマンドのトランスポート接続の確立の利点は、特に、ネットワークインタフェース上の接続のフルメッシュの必要がない場合には、ルータ資源の減少です。欠点は、追加の遅延および参加/プルーンのメッセージを送信する必要があるとトランスポート接続がまだ確立されていないときのキューイングです。
If a router interface has become operational and PIM neighbors are learned from Hello messages, at that time, transport connections may be established. The advantage is that a connection is ready to transport data by the time a Join/Prune message needs to be sent. The disadvantage is there can be more connections established than needed. This can occur when there is a small set of RPF neighbors for the active distribution trees compared to the total number of neighbors. Even when transport connections are pre-established before they are needed, a connection can go down and an implementation will have to deal with an on-demand situation.
ルータインターフェイスが動作可能になりましたし、PIMネイバーは、Helloメッセージから学習された場合は、その時点で、交通機関の接続が確立されてもよいです。利点は、接続が参加/プルーンのメッセージを送信する必要がある時間でデータを転送する準備ができているということです。欠点は、必要以上に設立され、より多くの接続が可能です。近隣の総数と比較して、活性配信ツリーのためのRPF隣人の小さなセットがある場合に発生する可能性があります。それらが必要になる前に、交通機関の接続が事前に確立されている場合でも、接続がダウンして行くことができ、実装はオンデマンドの状況に対処する必要があります。
Note that for TCP, it is the router with the lower Connection ID that decides whether to open a connection immediately or on demand. The router with the higher Connection ID SHOULD only initiate a connection on demand, that is, if it needs to send a Join/Prune message and there is no currently established connection.
TCPのために、それはすぐにまたはオンデマンドでの接続を開くかどうかを決定する下部接続IDを持つルータであることに注意してください。それは参加/プルーンのメッセージを送信する必要があるとなし、現在確立された接続がある場合、高い接続IDを持つルータが唯一のオンデマンド接続を開始すべきで、それが、あります。
Therefore, this specification RECOMMENDS but does not mandate the use of on-demand transport connection establishment.
したがって、この仕様は、オンデマンドトランスポートコネクション確立の使用を強制しませんが、お勧めします。
Based on this specification, a transport connection cannot be established until a Hello message is received. Reasons for this are to determine if the PIM neighbor supports this specification and to determine the remote address to use for establishing the transport connection.
Helloメッセージが受信されるまで、この仕様に基づいて、トランスポート接続を確立することはできません。この理由は、PIMネイバーがこの仕様をサポートしているかどうかを判断するために、輸送接続を確立するために使用するリモートアドレスを決定することです。
There are cases where it is desirable to suppress entirely the transmission of Hello messages. In this case, how to determine if the PIM neighbor supports this specification and how to determine out-of-band (i.e., outside of the PIM protocol) the remote address for establishing the transport connection are outside the scope of this document. In this case, the following is outside the scope of this document: how to determine if the PIM neighbor supports this specification as well as an out-of-band (outside of the PIM protocol) method to determine the remote address to establish the transport connection.
完全にHelloメッセージの送信を抑制することが望ましい場合があります。 PIMネイバーは、本明細書とどのようにこの文書の範囲外であるアウトオブバンド（すなわち、PIMプロトコルの外側）トランスポート接続を確立するためのリモートアドレスを決定するためにサポートしている場合この場合には、どのように決定します。この場合、以下はこの文書の範囲外である：PIMネイバーは、本明細書ならびに輸送を確立するために、リモートアドレスを決定するために、アウトオブバンド（PIMプロトコルの外側）メソッドをサポートしているかどうかを決定する方法接続。
To ensure that there is only one TCP connection between a pair of PIM neighbors, the following set of rules MUST be followed. Note that this section applies only to TCP; for SCTP, this is not an issue. Let nodes A and B be two PIM neighbors where A's Connection ID is numerically smaller than B's Connection ID, and each is known to the other as having a potential PIM adjacency relationship.
PIMネイバーのペアの間に1つのTCP接続だけがあることを確実にするために、以下のルールのセットに従わなければなりません。このセクションでは、TCPにのみ適用されることに注意してください。 SCTPのために、これは問題ではありません。ノードA及びBは、Aの接続IDがBの接続IDよりも数値的に小さい、そして各々が電位PIM隣接関係を有するように他に知られている2つのPIMネイバーとします。
At node A:
ノードAで：
o If there is already an established TCP connection to B, on the PIM-over-TCP port, then A MUST NOT attempt to establish a new connection to B. Rather, it uses the established connection to send Join/Prune messages to B. (This is independent of which node initiated the connection.)
O Bに確立されたTCP接続がすでに存在する場合は、PIM-over-TCPのポート上で、それはBに参加/プルーンのメッセージを送信するために確立された接続を使用して、B.むしろへの新しい接続を確立することを試みてはいけません（これは、接続を開始したノードとは無関係です。）
o If A has initiated a connection to B, but the connection is still in the process of being established, then A MUST refuse any connection on the PIM-over-TCP port from B.
AがBへの接続を開始したが、接続が確立されたプロセス中である場合、O、次いでB.からPIMオーバーTCPポート上の任意の接続を拒否しなければなりません
o At any time when A does not have a connection to B (which is either established or in the process of being established), A MUST accept connections from B.
O Aが（確立または確立中であるいずれか）Bへの接続を持たないとき、AはBからの接続を受け入れなければなりません
At node B:
ノードBで：
o If there is already an established TCP connection to A on the PIM-over-TCP port, then B MUST NOT attempt to establish a new connection to A. Rather, it uses the established connection to send Join/Prune messages to A. (This is independent of which node initiated the connection.)
PIM-over-TCPのポート上に確立されたTCP接続がすでに存在する場合は、O、そしてBは、（それがAに参加/プルーンのメッセージを送信するために確立された接続を使用して、A.むしろへの新しい接続を確立することを試みてはいけませんこれは、接続を開始したノードとは無関係です。）
o If B has initiated a connection to A, but the connection is still in the process of being established, then if A initiates a connection too, B MUST accept the connection initiated by A and release the connection that it (B) initiated.
Aがあまりにも接続を開始する場合、O BはAへの接続を開始したが、接続が確立されたプロセス中である場合、次いで、Bは、Aによって開始された接続を受け入れて、それは（B）で開始した接続を解放しなければなりません。
For scaling purposes, it may be desirable to allow Join/Prune messages from different PIM protocol families to be sent over the same transport connection. Also, it may be desirable to have a set of Join/Prune messages for one address family sent over a transport connection that is established over a different address-family network layer.
目的をスケーリングするために、別のPIMプロトコルファミリからの参加/プルーンのメッセージは、同じトランスポート接続を介して送信することができるようにすることが望ましいことがあります。また、別のアドレスファミリのネットワーク層の上に確立されたトランスポート接続を介して送信される一つのアドレスファミリのために参加/プルーンのメッセージのセットを有することが望ましいです。
To be able to do this, we need a common PORT message format. This will provide both record boundary and demux points when sending over a stream protocol like TCP/SCTP.
これを実行することができるように、我々は共通PORTメッセージ・フォーマットを必要としています。 TCP / SCTPのようなストリームプロトコルを介して送信するとき、これはレコード境界とデマルチプレクサのポイントの両方を提供します。
A PORT message may contain PORT Options; see Section 5.3. We will define two PORT Options for carrying PIM Join/Prune messages -- one for IPv4 and one for IPv6. For each PIM Join/Prune message to be sent over the transport connection, we send a PORT Join/Prune message containing exactly one such option.
PORTメッセージは、PORTオプションを含んでいてもよいです。 5.3節を参照してください。 IPv4のための1およびIPv6のための1 - 私たちは/参加PIMプルーンメッセージを運ぶための2つのPORTオプションを定義します。各PIMは、トランスポート接続を介して送信される/プルーンのメッセージに参加するために、我々は、PORTは正確に一つのそのようなオプションを含む/プルーンJoinメッセージを送信します。
Each PORT message will have the Type/Length/Value format. Multiple different TLV types can be sent over the same transport connection.
各ポートのメッセージは、タイプ/長さ/値の形式を持っています。複数の異なるTLVタイプは、同じトランスポート接続を介して送信することができます。
To make sure PIM Join/Prune messages are delivered as soon as the TCP transport layer receives the Join/Prune buffer, the TCP Push flag will be set in all outgoing Join/Prune messages sent over a TCP transport connection.
作るために必ずPIM参加/プルーンのメッセージは、すぐにTCPトランスポート層が参加/プルーンのバッファを受信として配信され、TCPプッシュフラグは、TCPトランスポート接続を介して送信されるすべての送信参加/プルーンのメッセージに設定されます。
PORT messages will be sent using destination TCP port number 8471. When using SCTP as the reliable transport, destination port number 8471 will be used. See Section 12 for IANA considerations.
PORTメッセージは、信頼性の高いトランスポートとしてSCTPを使用する場合は、宛先ポート番号8471が使用される宛先TCPポート番号8471.を使用して送信されます。 IANAの考慮事項については、セクション12を参照してください。
PORT messages are error checked. This includes unknown/illegal type fields or a truncated message. If the PORT message contains a PIM Join/Prune Message, then that is subject to the normal PIM error checks, including checksum verification. If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages.
PORTメッセージは、エラーがチェックされます。これは、未知/違法なタイプのフィールドや切り詰められたメッセージを含んでいます。 PORTメッセージはPIMは/プルーンのメッセージを参加含まれている場合は、そのチェックサム検証を含む通常のPIMエラーチェックの対象です。任意の構文解析エラーがPORTメッセージに発生した場合、それはスキップされ、我々は任意の次PORTメッセージに進みます。
When an unknown type field is encountered, that message MUST be ignored. As specified above, one then proceeds as usual when processing further PORT messages. This is important in order to allow new message types to be specified in the future, without breaking existing implementations. However, if only unknown or invalid messages are received for a longer period of time, an implementation MAY alert the operator. For example, if a message is sent with a wrong length, the receiver is likely to see only unknown/ invalid messages thereafter.
未知のタイプフィールドが検出された場合、そのメッセージは無視しなければなりません。上記指定されたようにさらにPORTメッセージを処理するとき、人はその後通常通り進みます。これは、新しいメッセージタイプは、既存の実装を壊すことなく、将来的に指定できるようにするために重要です。唯一不明または無効なメッセージは、時間の長い期間のために受信されている場合は、実装は、オペレータに警告することができます。メッセージが間違った長さで送信された場合、受信機は、その後のみ不明/無効なメッセージを表示する可能性があります。
The checksum of the PIM Join/Prune message MUST be calculated exactly as specified in Section 4.9 of [RFC4601]. For IPv6, [RFC4601] specifies the use of a pseudo-header. For PORT, the exact same pseudo-header MUST be used, but its source and destination address fields MUST be set to 0 when calculating the checksum.
PIMのチェックサムは、[RFC4601]のセクション4.9で指定されるように/プルーンメッセージが正確に計算しなければならない参加します。 IPv6の場合、[RFC4601]は、疑似ヘッダの使用を指定します。ポートに対して、まったく同じ疑似ヘッダが使用されなければならないが、チェックサムを計算する際に、その送信元および宛先アドレスフィールドを0に設定しなければなりません。
The TLV type field is 16 bits. The range 65532 - 65535 is for experimental use [RFC3692].
TLVタイプフィールドは16ビットです。範囲65532から65535は、実験的使用[RFC3692]のためのものです。
This document defines two message types.
この文書では、2つのメッセージタイプを定義します。
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 = 1 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface |
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PORT Join/Prune Message
PORTはjoin / pruneメッセージを
The PORT Join/Prune Message is used for sending a PIM Join/Prune.
PORT参加/プルーンのメッセージは、PIM参加/プルーンを送信するために使用されます。
Message Length: Length in bytes for the value part of the Type/ Length/Value encoding. If no PORT Options are included, the length is 12. If n PORT Options with Option Value lengths L1, L2, ..., Ln are included, the message length is 12 + 4*n + L1 + L2 + ... + Ln.
メッセージ長：タイプ/長さ/値の符号の値部分のバイト単位の長さ。何PORTオプションが含まれていない場合、長さ値はL1、L2を、長オプションと12の場合、N PORTオプションである...、Lnの含まれている、メッセージの長さは+ ... + 12 + 4 *はN + L1 + L2 LN。
Reserved: Set to zero on transmission and ignored on receipt.
予約：送信時にゼロに設定して、領収書の上で無視。
Interface ID: This MUST be the Interface ID of the Interface ID Hello Option contained in the PIM Hello messages that the PIM router is sending to the PIM neighbor. It indicates to the PIM neighbor what interface to associate the Join/Prune with. The Interface ID allows us to do connection sharing.
インタフェースID：これは、PIMルータがPIMネイバに送信されたPIM Helloメッセージに含まれているインタフェースIDこんにちはオプションのインタフェースIDでなければなりません。これは、とプルーン/参加を関連付けるためにどのようなインターフェイスのPIMネイバーに示します。インタフェースIDは、私たちは、接続の共有を行うことができます。
PORT Options: The message MUST contain exactly one PIM Join/Prune PORT Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ Prune. It MUST NOT contain both. It MAY contain additional options not defined in this document. The behavior when receiving a message containing unknown options depends on the option type. See Section 5.3 for option definitions.
PORTオプション：メッセージは正確に一つのPIM参加/プルーンPORTオプションを含まなければならない、どちらか1 PIMのIPv4参加/プルーンまたは1 PIM IPv6は/プルーンに参加します。これは、両方を含めることはできません。それは、この文書で定義されていない追加のオプションを含むかもしれません。未知のオプションを含むメッセージを受信する動作は、オプションの種類によって異なります。オプションの定義については、5.3節を参照してください。
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 = 2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | PORT Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PORT Keep-Alive Message
PORTキープアライブメッセージ
The PORT Keep-alive Message is used to regularly send PORT messages to verify that a connection is alive. They are used when other PORT messages are not sent at the desired frequency.
PORTキープアライブメッセージを定期的に接続が生きていることを確認するために、PORTメッセージを送信するために使用されます。他のPORTメッセージが所望の周波数で送信されていないとき、彼らが使用されています。
Message Length: Length in bytes for the value part of the Type/ Length/Value encoding. If no PORT Options are included, the length is 6. If n PORT Options with Option Value lengths L1, L2, ..., Ln are included, the message length is 6 + 4*n + L1 + L2 + ... + Ln.
メッセージ長：タイプ/長さ/値の符号の値部分のバイト単位の長さ。何PORTオプションが含まれていない場合、長さ値はL1、L2を、長オプションと6の場合、N PORTオプションである...、Lnの含まれている、メッセージの長さは6 + 4 *はN + L1 + L2 + ... + LN。
Reserved: Set to zero on transmission and ignored on receipt.
予約：送信時にゼロに設定して、領収書の上で無視。
Holdtime: This specifies a Holdtime in seconds for the connection. A non-zero value means that the connection SHOULD be gracefully shut down if no further PORT messages are received within the specified time. This is measured on the receiving side by measuring the time from when one PORT message has been processed until the next has been processed. Note that this MUST be done for any PORT message, not just keep-alive messages. A Holdtime of 0 disables the keep-alive mechanism.
ホールドタイム：これは、接続のための秒単位でホールドタイムを指定します。非ゼロ値は、さらなるPORTメッセージが指定された時間内に受信されない場合、接続が正常にシャットダウンされるべきであることを意味します。これは次が処理されるまで、1件のポートメッセージが処理されたときからの時間を測定することにより、受信側で測定されます。これは任意のPORTメッセージのために行わなければならないことに注意してくださいだけでなく、キープアライブメッセージ。 0のホールドタイムは、キープアライブメカニズムを無効にします。
PORT Options: A keep-alive message MUST NOT contain any of the options defined in this document. It MAY contain other options not defined in this document. The behavior when receiving a message containing unknown options depends on the option type. See Section 5.3 for option definitions.
PORTオプション：キープアライブメッセージがこの文書で定義されたオプションのいずれかを含めることはできません。それは、この文書で定義されていない他のオプションを含むかもしれません。未知のオプションを含むメッセージを受信する動作は、オプションの種類によって異なります。オプションの定義については、5.3節を参照してください。
Each PORT Option is a TLV. The type is 16 bits. The PORT Option type space is split in two ranges. The types in the range 0 - 32767 (the most significant bit is not set) are for Critical Options. The types in the range 32768 - 65535 (the most significant bit is set) are for Non-Critical Options.
各ポートのオプションTLVです。型は16ビットです。 PORTオプションタイプスペースは二つの範囲に分割されます。範囲0におけるタイプ - （最上位ビットがセットされていない）32767クリティカルオプションのためのものです。範囲32768内の型 - 65535（最上位ビットがセットされている）非クリティカル・オプションのためのものです。
The behavior of a router receiving a message with an unknown PORT Option is determined by whether the option is a Critical Option. If the message contains an unknown Critical Option, the entire message must be ignored. If the option is Non-Critical, only that particular option is ignored, and the message is processed as if the option was not present.
未知のPORTオプションでメッセージを受信したルータの動作はオプションは重要なオプションであるかどうかによって決定されます。メッセージが未知の重要なオプションが含まれている場合は、メッセージ全体を無視しなければなりません。オプションは、非クリティカルである場合は、その特定のオプションは無視され、オプションが存在していなかったかのようにメッセージが処理されます。
PORT Option types are assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535, which are for experimental use [RFC3692]. The length specifies the length of the value in bytes. Below are the two options defined in this document.
実験的使用[RFC3692]のためのものである65535 - 32767と65532 - ポートオプションタイプは、範囲32764を除いて、IANAによって割り当てられます。長さはバイト単位の値の長さを指定します。以下は、この文書で定義された2つのオプションがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 1 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM IPv4 Join/Prune Option Format
PIMはIPv4 /プルーンオプションフォーマットに参加します
The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune message that has all IPv4-encoded addresses in the PIM payload.
IPv4がプルーンオプションはPIMペイロードにすべてのIPv4エンコードアドレスを有するPIMv2の参加/プルーンメッセージを搬送するために使用される/参加します。
Option Value Length: The number of bytes that make up the PIMv2 Join/Prune message.
オプション値の長さ：PIMv2の参加/プルーンのメッセージを構成するバイト数。
PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with no IP header in front of it.
PIMv2のは/プルーンメッセージに参加：PIMv2のそれの前にないIPヘッダで/プルーンメッセージ及びペイロードに参加します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 2 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM IPv6 Join/Prune Option Format
PIM IPv6は/プルーンオプションフォーマットに参加します
The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune message that has all IPv6-encoded addresses in the PIM payload.
IPv6はプルーンオプションはPIMペイロード内のすべてのIPv6エンコードアドレスを有するPIMv2の参加/プルーンメッセージを搬送するために使用される/参加します。
Option Value Length: The number of bytes that make up the PIMv2 Join/Prune message.
オプション値の長さ：PIMv2の参加/プルーンのメッセージを構成するバイト数。
PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with no IP header in front of it.
PIMv2のは/プルーンメッセージに参加：PIMv2のそれの前にないIPヘッダで/プルーンメッセージ及びペイロードに参加します。
When explicit tracking is used, a router keeps track of Join state for individual downstream neighbors on a given interface. This MUST be done for all PORT Joins and Prunes. Note that it may also be done for native Join/Prune messages, if all neighbors on the LAN have set the T bit of the LAN Prune Delay Option (see definition in Section 4.9.2 of [RFC4601]). The discussion below covers ET (explicit tracking) neighbors and non-ET neighbors. The set of ET neighbors MUST include the PORT neighbors. The set of non-ET neighbors consists of all the non-PORT neighbors, unless all neighbors have set the LAN Prune Delay T bit -- in which case, the ET neighbors set contains all neighbors.
明示的なトラッキングが使用されている場合、ルータは、特定のインターフェイス上の個々のダウンストリームネイバーの状態を参加を追跡します。すべてのポートが参加し、プルーンのために行われなければなりません。 LAN上のすべてのネイバーが（[RFC4601]のセクション4.9.2で定義を参照）LANプルーン遅延オプションのTビットを設定している場合、それは、ネイティブの参加/プルーンのメッセージに対してもを行うことができることに注意してください。以下の議論は、ET（明示的な追跡）隣人や非ETネイバーをカバーしています。 ETの隣人のセットは、PORTネイバーを含まなければなりません。その場合には、ETの隣人セットは、すべてのネイバーが含まれている - すべてのネイバーがLANプルーン遅延Tビットを設定していない限り、非ETの隣人のセットは、すべての非PORTの隣人から構成されています。
For some link-types, e.g., point-to-point, tracking neighbors is no different than tracking interfaces. It may also be possible for an implementation to treat different downstream neighbors as being on different logical interfaces, even if they are on the same physical link. Exactly how this is implemented, and for which link types, is left to the implementer.
いくつかのリンクタイプの場合、例えば、ポイントツーポイント、ネイバーを追跡するインターフェイスを追跡するよりも違いはありません。実装は、彼らが同じ物理リンク上にある場合でも、異なる論理インターフェイス上にあるものとして異なる下流の隣人を治療することも可能です。これが実装されている方法を正確に、そしてどのリンクタイプのため、実装者に任されています。
For (*,G) and (S,G) state, the router starts forwarding traffic on an interface when a Join is received from a neighbor on such an interface. When a non-ET neighbor sends a Prune, as specified in [RFC4601], if no Join is sent to override this Prune before the expiration of the Override Timer, the upstream router concludes that no non-ET neighbor is interested. If no ET neighbors are interested, the interface can be removed from the oif-list. When an ET neighbor sends a Prune, one removes the Join state for that neighbor. If no other ET or non-ET neighbors are interested, the interface can be removed from the oif-list. When a PORT neighbor sends a Prune, there can be no Prune Override, since the Prune is not visible to other neighbors.
（*、G）および（S、G）状態のために、ルータは、インターフェイス上でネイバーから受信したとき参加インターフェイス上のトラフィックの転送を開始します。非ETネイバーがプルーンを送信すると何の参加をオーバーライドタイマーの満了前にこのプルーンを上書きするために送信されない場合は、[RFC4601]で指定されるように、上流のルータには非ETネイバーが興味を持っていないと結論します。何のETの隣人が興味を持っていない場合、インターフェイスはOIF-リストから削除することができます。 ETの隣人がプルーンを送信するとき、人はその隣人のための参加状態を削除します。他のETまたは非ET隣人が興味を持っていない場合、インターフェイスはOIF-リストから削除することができます。 PORTネイバーがプルーンを送信するとプルーンは、他の隣人には見えないので、何のプルーンの上書きはあり得ません。
For (S,G,rpt) state, the router needs to track Prune state on the shared tree. It needs to know which ET neighbors have sent Prunes, and whether any non-ET neighbors have sent Prunes. Normally, one would forward a packet from a source S to a group G out on an interface if a (*,G) Join is received, but no (S,G,rpt) Prune. With ET, one needs to do this check per ET neighbor. That is, the packet should be forwarded except in two cases: all ET neighbors that have sent (*,G) Joins have also sent (S,G,rpt) Prunes, and if a non-ET neighbor has sent a (*,G) Join, whether there also is non-ET (S,G,rpt) Prune state.
（S、G、RPT）状態のために、ルータは共有ツリー上のプルーン状態を追跡する必要があります。これは、ETの隣人が送られたプルーンを持っているかを知る必要があり、任意の非ETの隣人はプルーンを送っているかどうか。通常、プルーンを（*、G）参加を受信した場合、一つのインタフェースにグループG OUTにソースSからのパケットを転送しないだろうが、何の（S、G、RPT）。 ETでは、一つはETネイバごとにこのチェックを行う必要があります。送信されたすべてのETの隣人（*、G）は、送られた（S、G、RPT）プルーンを持って参加し、あれば非ETの隣には、*（送信された、：それは、パケットが2例を除いて転送する必要がありますされますG）非ET（S、G、RPT）プルーン状態が存在するかどうか、参加。
To allow for efficient use of router resources, one can mux Join/ Prune messages of different address families on the same transport connection. There are two ways this can be accomplished -- using a common message format over a TCP connection or using multiple streams over a single SCTP connection.
ルータリソースの効率的な利用を可能にするためには、同じトランスポート接続上の異なるアドレスファミリの参加/プルーンのメッセージをマルチプレクサ・することができます。 TCP接続を介して、共通のメッセージ形式を使用したり、単一のSCTP接続を介して複数のストリームを使用して - これを達成することができる2つの方法があります。
Using the common message format described in this specification, and using different PORT Options, both IPv4- and IPv6-based Join/Prune messages can be encoded within the same transport connection.
本明細書に記載の一般的なメッセージフォーマットを使用し、そして別のポートオプションを使用して、IPv4-両方のIPv6ベースの参加/プルーンメッセージは、同じトランスポート接続内で符号化することができます。
When using SCTP multi-streaming, the common message format is still used to convey address-family information, but an SCTP association is used, on a per-family basis, to send data concurrently for multiple families. When data is sent concurrently, head-of-line blocking (which can occur when using TCP) is avoided.
SCTPのマルチストリーミングを使用する場合は、共通のメッセージ・フォーマットは、まだアドレスファミリの情報を伝えるために使用されますが、SCTP協会は、複数の家族のために同時にデータを送信するために、あたりの家族ベースで、使用されています。データが同時に送信されると、ヘッドオブラインブロッキング（TCPを使用するときに発生する可能性がある）が回避されます。
There are no changes to processing of other PIM messages like PIM Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This goes for Bootstrap Router (BSR) and Auto-RP type messages as well.
そこPIMアサート、移植片、移植片Acksを、レジスタのような他のPIMメッセージの処理に変更はありません、とストップを登録します。これは、同様にブートストラップルータ（BSR）とAuto-RPのタイプのメッセージのために行きます。
This extension is applicable only to PIM-SM, PIM-SSM, and Bidirectional PIM. It does not take requirements for PIM Dense Mode (PIM-DM) into consideration.
この拡張は、唯一のPIM-SM、PIM-SSM、および双方向PIMに適用されます。それを考慮にPIM稠密モード（PIM-DM）の要件を取ることはありません。
As noted in the introduction, this is an experimental extension to PIM, and using reliable delivery for PIM messages is a new concept. There are several potential transport-related concerns. Hopefully, experiences from early implementations and deployments will reveal what concerns are relevant and how to resolve them.
冒頭で述べたように、これは、PIMに実験的な拡張機能であり、かつPIMメッセージの信頼性の高い配信を使用すると、新しい概念です。いくつかの潜在的な輸送関連の懸念があります。うまくいけば、初期の実装および展開の経験が関連しているとどのようにそれらを解決するにはどのような懸念明らかになります。
One consideration is keep-alive mechanisms. We have defined an optional keep-alive mechanism for PORT; see Section 4.2. Also, SCTP and many TCP implementations provide keep-alive mechanisms that could be used. When to use keep-alive messages and which mechanism to use are unclear; however, we believe the PORT Keep-alive allows for better application control. It is unclear what Holdtimes are preferred for the PORT Keep-alives. For now, it is RECOMMENDED that administrators be able to configure whether to use keep-alives, what Holdtimes to use, etc.
一つの考慮事項は、キープアライブメカニズムです。私たちは、PORT用のオプションのキープアライブメカニズムを定義しています。 4.2節を参照してください。また、SCTPおよび多くのTCP実装を使用することができるキープアライブメカニズムを提供します。キープアライブメッセージを使用すると、どのメカニズムが使用する場合は不明です。しかし、私たちは、PORTは、キープアライブより良いアプリケーション制御を可能と信じています。 HoldtimesはPORTキープアライブのために好まれているものは不明です。今のところ、管理者がキープアライブを使用するかどうかを設定することができることをお勧めしますが、何等、使用することをHoldtimes
In a stable state, it is expected that only occasional small messages are sent over a PORT connection. This depends on how often PIM Join/ Prune state changes. Thus, over a long period of time, there may be only small messages that never use the entire TCP congestion window, and the window may become very large. This would then be an issue if there is a state change that makes PORT send a very large message. It may be good if the TCP stack provides some rate-limiting or burst-limiting. The congestion control mechanism defined in [RFC3465] may be of help.
安定した状態では、時折、小さなメッセージがPORT接続を介して送信されることが期待されます。これは、多くの場合、PIM /プルーンの状態の変更を参加方法によって異なります。したがって、長期間にわたって、そこに全体のTCP輻輳ウィンドウを使用しない唯一の小さなメッセージであってもよく、窓が非常に大きくなる可能性があります。 PORTは、非常に大きなメッセージを送信可能な状態の変更があった場合、これは、問題になります。 TCPスタックは、いくつかの律速またはバースト制限を提供する場合それは良いかもしれません。 [RFC3465]で定義された輻輳制御メカニズムが助けになることができます。
With PORT, it is possible that only occasional small messages are sent (as discussed in the previous paragraph). This may cause problems for the TCP retransmit mechanism. In particular, the TCP Fast Retransmit algorithm may never get triggered. For further discussion of this and a possible solution, see [RFC3042].
PORTと、（前の段落で説明したように）だけ時折小さなメッセージが送信されている可能性があります。これは、TCPの再送メカニズムのための問題を引き起こす可能性があります。特に、TCP高速再送アルゴリズムがトリガされることはありません飽きないことがあります。こののさらなる議論と可能な解決策については、[RFC3042]を参照してください。
There may be SCTP issues similar to the TCP issues discussed in the above two paragraphs.
上記の二つの段落で述べたTCPの問題に似てSCTPの問題があるかもしれません。
This document defines using TCP or SCTP transports between pairs of PIM neighbors. It is recommended that this mechanism be disabled by default. An administrator can then enable PORT TCP and/or SCTP on PIM-enabled interfaces. If two neighbors both have PORT SCTP (or both have PORT TCP), they will only use SCTP (or alternatively, TCP) for PIM Join/Prune messages. This is the case even when the connection is down (there is no fallback to native Join/Prune messages).
このドキュメントでは、TCPを使用して定義するか、SCTPは、PIMネイバーのペアの間で転送します。このメカニズムはデフォルトで無効にすることをお勧めします。管理者は、PIM対応インターフェイス上PORT TCPおよび/またはSCTPを有効にすることができます。 2つのネイバーの両方がPORT SCTP（またはその両方がPORT TCPを持っている）している場合、彼らは唯一の/プルーンのメッセージを参加PIM用のSCTP（あるいは、TCP）を使用します。これは、接続がダウンしている場合でもです（プルーン/参加ネイティブメッセージへのフォールバックはありません）。
When PORT support is enabled, a router sends PIM Hello messages announcing support for TCP and/or SCTP and also Connection IDs. It should be possible to configure a local Connection ID, and also to see what PORT capabilities and Connection IDs PIM neighbors are announcing. Based on these advertisements, pairs of PIM neighbors will decide whether to try to establish a PORT connection. There should be a way for an operator to check the current connection state. Statistics on the number of PORT messages sent and received (including number of invalid messages) may also be helpful.
PORTのサポートが有効になっている場合、ルータは、TCPおよび/またはSCTPとも接続IDのサポートを発表PIM Helloメッセージを送信します。ローカルコネクションIDを設定するには、とも発表しているものPORT機能と接続IDのPIMネイバー見ることが可能であるべきです。これらの広告に基づいて、PIMネイバーのペアは、PORT接続を確立しようとするかどうかを決定します。現在の接続状態をチェックするオペレータのための方法があるはずです。 PORTメッセージの数に関する統計は、送受信された（無効なメッセージの数を含む）にも有用であろう。
For connection security (see Section 4.1), it should be possible to enable a GTSM check to only accept connections (TCP/SCTP packets) when the sender is within a certain number of router hops. Also, one should be able to configure the use of TCP-AO.
接続セキュリティ（セクション4.1を参照）の場合は、送信者がルータのホップ一定数の範囲内にあるときにのみ接続（TCP / SCTPパケット）を受け入れるようにGTSMチェックを有効にすることが可能なはずです。また、1はTCP-AOの使用を設定することができるはずです。
For connection maintenance (see Section 4.2), it is recommended to support Keep-Alive messages. It should be configurable whether to send Keep-Alives -- and if doing so, whether to use a Holdtime and what Holdtime to use.
接続の維持（4.2節を参照）のためには、キープアライブメッセージをサポートすることをお勧めします。ホールドタイムを使用するかどうかとホールドタイムを使用するか、そしてそうならば - キープアライブを送信するかどうかを設定可能でなければなりません。
There should be some way to alert an operator when PORT connections are going down or when there is a failure in establishing a PORT connection. Also, information like the number of connection failures, and how long the connection has been up or down, is useful.
PORT接続がダウンまたはPORT接続を確立する際に、障害がある場合にされているオペレータに警告するためにいくつかの方法があるはずです。また、接続エラーの数で、どのくらいの接続がアップまたはダウンしているような情報は、便利です。
There are several security issues related to the use of TCP or SCTP transports. By sending packets with a spoofed source address, off-path attackers might establish a connection or inject packets into an existing connection. This might allow an attacker to send spoofed Join/Prune messages and/or reset a connection. Mechanisms that help protect against this are discussed in Section 4.1.
TCPまたはSCTPトランスポートの使用に関連するいくつかのセキュリティ問題があります。偽装された送信元アドレスを持つパケットを送信することにより、オフパス攻撃者は、接続を確立したり、既存の接続にパケットを注入します。これにより、攻撃者は/プルーンJoinメッセージを偽装された送信することができ、および/または接続がリセットされる場合があります。このに対する保護の手助けメカニズムはセクション4.1で説明されています。
For authentication, TCP-AO [RFC5925] may be used with TCP, Authenticated Chunks [RFC4895] may be used with SCTP. Also, GTSM [RFC5082] can be used to help prevent spoofing.
認証のために、TCP-AO [RFC5925]はTCPで使用することができる、認証チャンク[RFC4895]はSCTPと共に使用することができます。また、GTSM [RFC5082]は、なりすましを防ぐために使用することができます。
This specification makes use of a TCP port number and an SCTP port number for the use of the pim-port service that has been assigned by IANA. It also makes use of IANA PIM Hello Options assignments that have been made permanent.
この仕様は、TCPポート番号とIANAによって割り当てられているPIM-ポートサービスの利用のためのSCTPポート番号を使用しています。また、永久行われているIANA PIMこんにちはオプションの割り当てを使用しています。
IANA previously had assigned a port number that is used as a destination port for pim-port TCP and SCTP transports. The assigned number is 8471. References to this document have been added to the Service Name and Transport Protocol Port Number Registry for pim-port.
IANAは以前、PIM-ポートTCPとSCTPのトランスポートの宛先ポートとして使用されているポート番号が割り当てられていました。割り当てられた番号は、この文書に8471.参照は、PIM-ポートのためのサービス名とトランスポートプロトコルポート番号のレジストリに追加されましたです。
In the "PIM-Hello Options" registry, the following options have been added for PORT.
「PIM-こんにちはオプション」のレジストリで、次のオプションは、PORTのために追加されました。
Value Length Name Reference
------- ---------- ----------------------- ---------------
27 Variable PIM-over-TCP-Capable this document
28 Variable PIM-over-SCTP-Capable this document
A registry for PORT message types has been created. The message type is a 16-bit integer, with values from 0 to 65535. An RFC is required for assignments in the range 0 - 65531. This document defines two PORT message types: Type 1 (Join/Prune) and Type 2 (Keep-alive). The type range 65532 - 65535 is for experimental use [RFC3692].
PORTメッセージタイプのためのレジストリが作成されています。タイプ1（/プルーンに参加）とタイプ2（キープ：このドキュメントでは、2つのポートのメッセージ・タイプを定義65531. - 0から65535までの値は、RFCは範囲0に割り当てに必要とされると、メッセージ・タイプは、16ビットの整数であります-alive）。タイプの範囲65532から65535は、実験的使用[RFC3692]のためのものです。
The initial content of the registry is as follows:
次のようにレジストリの初期の内容は次のとおりです。
Type Name Reference
------------- ------------------------------- ---------------
0 Reserved this document
1 Join/Prune this document
2 Keep-alive this document
3-65531 Unassigned
65532-65535 Experimental this document
A registry for PORT Option types. The option type is a 16-bit integer, with values from 0 to 65535. The type space is split in two ranges, 0 - 32767 for Critical Options and 32768 - 65535 for Non-Critical Options. Option types are assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535 that are for experimental use [RFC3692]. An RFC is required for the IANA assignments. An RFC defining a new option type must specify whether the option is Critical or Non-Critical in order for IANA to assign a type. This document defines two Critical PORT Option types: Type 1 (PIM IPv4 Join/Prune) and Type 2 (PIM IPv6 Join/Prune).
PORTのオプションの種類のレジストリ。非クリティカル・オプションのための65535 - クリティカル・オプションのための32767と32768 - オプションタイプは、タイプ空間が二つの範囲、0で分割され、0から65535までの値を持つ16ビットの整数です。実験的使用[RFC3692]のためのものである65535から32767と65532 - オプションタイプは、範囲32764を除いて、IANAによって割り当てられます。 RFCは、IANAの割り当てのために必要とされます。新しいオプションタイプを定義するRFCは、オプションはIANAはタイプを割り当てるようにするためにクリティカルまたは非クリティカルであるかどうかを指定する必要があります。タイプ1（PIM IPv4アドレス/プルーンに参加）およびタイプ2（PIM IPv6は/プルーンに参加）：この文書では、2つの重要なポートオプションタイプを定義します。
The initial content of the registry is as follows:
次のようにレジストリの初期の内容は次のとおりです。
Type Name Reference
------------- ---------------------------------- ---------------
0 Reserved this document
1 PIM IPv4 Join/Prune this document
2 PIM IPv6 Join/Prune this document
3-32763 Unassigned Critical Options
32764-32767 Experimental this document
32768-65531 Unassigned Non-Critical Options
65532-65535 Experimental this document
In addition to the persons listed as authors, significant contributions were provided by Apoorva Karan and Arjen Boers.
著者として掲げる者のほかに、重要な貢献をApoorvaカランとアリエン・ボーア人によって提供されました。
The authors would like to give a special thank you and appreciation to Nidhi Bhaskar for her initial design and early prototype of this idea.
著者は、特別に彼女の初期の設計とこのアイデアの初期の試作品のためNidhi Bhaskarにあなたと感謝に感謝したいと思い。
Appreciation goes to Randall Stewart for his authoritative review and recommendation for using SCTP.
感謝は、SCTPを使用するための彼の権威レビューと勧告のためのランドール・スチュワートに行きます。
Thanks also goes to the following for their ideas and review of this specification: Mike McBride, Toerless Eckert, Yiqun Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh Parekh, Manav Bhatia, Pekka Savola, Tom Petch, and Joe Touch.
おかげでも、自分の考えとこの仕様の見直しについては、次に行く：マイク・マクブライド、Toerlessエッカート、Yiqunカイ、アルバート・ティエン、スレシュBoddapati、ナタラジBatchu、ダニエル・ヴォーチェ、ジョンZwiebel、ヤコフ・レックター、レニージュリアーノ、Gorry Fairhurst、サミールGulrajani 、トーマス・モラン、ディミトリPapadimitriou、バーラト・ジョシ、Rishabh Parekhの、Manav Bhatiaは、ペッカSavola、トム・ペッチ、そしてジョー・タッチ。
A special thank you goes to Eric Rosen for his very detailed review and commentary. Many of his comments are reflected as text in this specification.
特別なあなたは彼の非常に詳細なレビューと解説のためにエリック・ローゼンに行く感謝します。彼のコメントの多くは、この仕様書のテキストとして反映されています。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895] Tuexen、M.、スチュワート、R.、レイ、P.、およびE.レスコラ、 "ストリーム制御伝送プロトコル（SCTP）に対して認証チャンク"、RFC 4895、2007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、RFC 5015、2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、およびC. Pignataro、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 5082、2007年10月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、RFC 5925、2010年6月。
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, October 2011.
[RFC6395] Gulrajani、S.、およびS. Venaas、 "アンインタフェース識別子（ID）ハローPIM用オプション"、RFC 6395、2011年10月。
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/ address-family-numbers>.
[AFI] IANA、 "アドレスファミリ番号"、<http://www.iana.org/assignments/アドレスファミリ-番号>。
[HELLO-OPT] IANA, "PIM-Hello Options", <http://www.iana.org/assignments/pim-parameters>.
[ハロー-OPT] IANA、 "PIM-こんにちはオプション"、<http://www.iana.org/assignments/pim-parameters>。
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.、およびS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]オールマン、M.、RFC 3465、2003年2月 "適切なバイトカウント（ABC）とTCP輻輳制御"。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
ディノファリナッチシスコシステムズタスマン・ドライブサンノゼ、CA 95134 USA
EMail: dino@cisco.com
メールアドレス：dino@cisco.com
IJsbrand Wijnands Cisco Systems Tasman Drive San Jose, CA 95134 USA
IJsbrand Wijnandsシスコシステムズタスマン・ドライブサンノゼ、CA 95134 USA
EMail: ice@cisco.com
メールアドレス：ice@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
スティグVenaasシスコシステムズタスマン・ドライブサンノゼ、CA 95134 USA
EMail: stig@cisco.com
メールアドレス：stig@cisco.com
Maria Napierala AT&T Labs 200 Laurel Drive Middletown, New Jersey 07748 USA
マリアNapierala AT＆T Labsの200ローレルドライブミドルタウン、ニュージャージー州07748米国
EMail: mnapierala@att.com
メールアドレス：mnapierala@att.com