[要約] RFC 6559は、PIM（Protocol Independent Multicast）のための信頼性のある輸送メカニズムを提供することを目的としています。このRFCは、PIMの信頼性を向上させるための具体的な手法とプロトコルを提案しています。
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
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
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.
セクション4.Eで説明されている法的規定のセクション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].
o PIM SPARSE-MODE（PIM-SM）[RFC4601]で使用するPIMバージョン2で信頼できるPIM結合/プルーンメッセージ配信を提供する簡単な増分メカニズムを作成し、PIMソース固有のマルチキャスト（PIM-SSM）、双方向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].
o [RFC4601]で定義されているPIMメッセージ形式を変更します。
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.
o [RFC4601]で定義されている信頼できる輸送メカニズムと通常のPIMメカニズムとの間の自動スイッチングのサポートを提供します。リンク上の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の実験的拡張です。これは、Join/Prune Stateが定期的な更新を必要とせず、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
ポート：PIMは、PIMがTCPまたはSCTP輸送プロトコルを使用できるこの仕様のメカニズムを説明するための短い形式です。
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.
Incremental Join/Pruneメッセージ：州の作成または削除イベントの結果として送信されたJoin/Pruneメッセージ。トリガーされたメッセージとしても知られています。
Native Join/Prune message: A Join/Prune message that is carried with an IP protocol type of PIM.
ネイティブの結合/プルーンメッセージ：IPプロトコルタイプのPIMで携帯される結合/プルーンメッセージ。
PORT Join/Prune message: A Join/Prune message using TCP or SCTP for transport.
ポートJOIN/PRUNEメッセージ：TCPまたはSCTPを使用した輸送用の結合/プルーンメッセージ。
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.
ポートモード：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.
PIM Over Reliable Transport（PORT）は、PIM結合/プルーンメッセージを更新するためのPIMV2の簡単な拡張です。これには、PIMネイバー間のTCP/SCTP接続を介して、周期的な結合/プルーンメッセージではなく増分/プルーンメッセージを送信することが含まれます。
PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM [RFC5015] Join/Prune messages.
ポートは、PIM Sparse-Mode [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.
このドキュメントは、ポートを特定のリンクタイプに制限しません。ただし、多くのPIMネイバーを使用したマルチアクセスLANなどのポートを使用することを慎重に評価する必要があります。これは、ポート接続の完全なメッシュがある可能性があり、すべての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.
ポートは、ポート対応の隣人間のリンクで徐々に使用できます。ポート対応ではないルーターは、データグラムモードでPIMを引き続き使用できます。ポート機能は、新しいポート対応のPIM Hello Optionsを使用して検出されます。
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.
インターフェイスでポートが有効になり、PIM Neighborがポートが有効になっていることも発表すると、ポート結合/プルーンメッセージのみが使用されます。つまり、特定の隣人からポート結合/プルーンメッセージのみが受け入れられ、送信されます。ネイティブの結合/プルーンメッセージは、ポートが有効になっていない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.
ポート結合/プルーンメッセージは、TCP/SCTP接続を使用して送信されます。TCPまたは両方のSCTPの両方で2つのPIMネイバーがポートを有効にすると、すぐに、またはオンデマンドで接続を確立します。接続がダウンした場合、すぐに、またはオンデマンドで再び、接続を再確立しようとします。接続がない間、結合/プルーンメッセージ（ネイティブもポートもポート）は送信されません。また、接続がダウンしている場合でも、その隣人からのネイティブの結合/プルーンメッセージは廃棄されます。
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.
ポートを使用すると、下流ルーターから上流ルーターにインクリメンタル接合/プルーンメッセージのみが送信されます。そのため、下流のルーターは、リバースパス転送（RPF）隣接がポート対応である状態の周期的な結合/プルーンメッセージを生成しません。
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
TCP/SCTP接続を介して受信される結合とプルーンの場合、上流のルーターは、発信インターフェイスエントリでタイマーを起動または維持しません。代わりに、どの下流ルーターが関心を表明しているかを追跡します。インターフェイスは、インターフェイス上のすべてのダウンストリームルーターがトラフィックを受信したくない場合にのみ、送信インターフェイスリストから削除されます。ポート以外の隣人からネイティブの結合/プルーンもある場合、ルーターはタイマーを維持できます
the outgoing interface entry as usual, while at the same time keep track of each of the downstream PORT Joins/Prunes.
通常どおりの発信インターフェイスエントリは、同時に、下流のポートが結合/プルーンする各ポートを追跡します。
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 Join/Pruneパケット形式を更新しません。このドキュメントで説明されている手順では、各PIM結合/プルーンメッセージは、TCP/SCTPに掲載されたポートメッセージのペイロードに含まれています。ポートメッセージの詳細については、セクション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].
割り当てられたハロータイプの値は、[hello-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-TCP利用可能なHelloオプションを含める必要があります。ルーターがTCPを介してPIMを使用することを明示的に無効にしている場合、HelloメッセージにPIM-TCP利用可能なHelloオプションを含めてはなりません。
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 Optionを含むすべてのHelloメッセージは、インターフェイスID Hello Optionも含める必要があります。セクション3.3を参照してください。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
実装は、ポート機能を有効または無効にする構成オプションを提供する場合があります。この機能をデフォルトで無効にすることをお勧めします。
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（IPv4）[AFI]のAFIが使用される場合4、値2（IPv6）[AFI]のAFIが使用される場合は16、値0のAFIが使用される場合は0です。
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：TCP接続IDフィールドのアドレスのアドレスファミリを記述するAFI値。この値は、それを伝える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-over-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].
割り当てられたハロータイプの値は、[hello-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-overSCTP利用可能なHelloオプションを含める必要があります。ルーターがSCTPを介してPIMを使用することを明示的に無効にしている場合、HelloメッセージにPIM-overSCTP利用可能なHelloオプションを含めてはなりません。
All Hello messages containing the PIM-over-SCTP-Capable Hello Option MUST also contain the Interface ID Hello Option; see Section 3.3.
pim-over-sctp対応のhello helloオプションを含むすべてのハローメッセージには、インターフェイスID Hello Optionも含まれている必要があります。セクション3.3を参照してください。
Implementations MAY provide a configuration option to enable or disable PORT functionality. It is RECOMMENDED that this capability be disabled by default.
実装は、ポート機能を有効または無効にする構成オプションを提供する場合があります。この機能をデフォルトで無効にすることをお勧めします。
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（IPv4）[AFI]のAFIが使用される場合4、値2（IPv6）[AFI]のAFIが使用される場合は16、値0のAFIが使用される場合は0です。
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：SCTP接続IDフィールドのアドレスのアドレスファミリを記述するAFI値。この値は、それを伝える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-over-over-sctp対応のハローオプションを含むすべてのハローメッセージには、インターフェイスID Hello Option [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 Neighborが来るPIM隣接に関連付けます。非仮定されたインターフェイスが使用されている場合、または複数のインターフェイス上で参加/プルーンメッセージの送信と受信に単一のトランスポート接続を使用する場合、インターフェイスIDを使用して、Join/Pruneメッセージ送信者からJoin/Pruneメッセージ受信機にインターフェイスを伝達します。インターフェイスで送信されたHellosのインターフェイスID Hello Optionの値は、そのインターフェイスのPIM Neighborに送信されたすべてのポートJoin/Pruneメッセージのインターフェイス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部分が0になる可能性があることを意味します。ルーターIDと値0の詳細については、[RFC6395]を参照してください。
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-over-over-sctp対応オプションを、そのインターフェイスに送信したpim helloメッセージに含める必要があります。ポート対応インターフェイスのルーターが、新しい隣人または以前にオプションを含めなかった既存の隣人からPIM-TCP利用可能/ PIM-Over-SCTP対応オプションを含むハローメッセージを受信すると、切り替えますその特定の隣人のポートモードへ。
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.
隣人のルーターがポートモードに切り替わると、その隣人のネイティブの結合/プルーンメッセージの送信と受け入れが停止します。以前のネイティブの結合/プルーンメッセージからの状態は、通常どおりに期限切れになります。また、隣人との輸送接続（TCPまたはSCTP）を確立しようとします。ルーターとその隣人の両方がPim-over-TCP対応とPim-over-over-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を使用している場合、PIM-Over-TCP対応オプションで発表されたTCP接続IDを、隣人から受信したHelloのTCP接続IDと比較します。接続がオンデマンドで開かれていない限り（以下を参照）、下部接続IDを持つルーターは、近隣接続IDにアクティブなトランスポートを開く必要があります。より高い接続IDを備えたルーターは、パッシブトランスポートを開く必要があります。実装は、オンデマンドでのみ接続を開く場合があります。その場合、より高い接続IDを持つ隣人がアクティブオープンを行う可能性があります（セクション4.5を参照）。下部接続IDを備えたルーターがアクティブなオープンオンデマンドのみを実行することを選択した場合、パッシブオープンを行う必要があり、隣人が接続を開始できるようにします。Active Openのソースアドレスは、発表された接続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に対して独立して作成されます。したがって、ポートがIPv4とIPv6の両方に使用される場合、IPv4とIPv6 PIM Helloメッセージの両方を送信する必要があります。2人の近隣が同じトランスポート（TCPまたはSCTP）とIPv4およびIPv6 Helloメッセージの同じ接続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ルーターは、よく知られているローカルトランスポートポート番号に耳を傾け、リモート輸送ポート番号を適格にしません。ポートの有名なポート番号割り当てについては、セクション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つのルーターは両方とも、他のルーターが上流の隣接である状態に結合/プルーンメッセージの完全なセットを送信する必要があります。これは、上流の隣人が正しい状態を持っていることを確認するために必要です。Datagramモードから移動するとき、または接続がダウンしたときに、ルーターは以前のすべての結合/プルーン状態が隣人によって受信されたことを確認できません。接続が確立される前に作成された（または再確立）、更新されていない状態は、期限切れにして削除するために残されている必要があります。非新鮮な状態が期限切れになり、削除された場合、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.
ポートを実行していない場合、ルーターが再起動するときにのみ完全な更新が必要です。ポートを使用すると、接続が確立されるたびに実行する必要があります。これはコストがかかる場合がありますが、ポート接続がめったに上下することは予想されます。これをよりよく処理するために拡張機能が必要になる場合があります。
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ペアには変更に接続が必要です。同じペアに既存の接続がある場合があります。その場合、ルーターはその接続を共有します。または、新しい接続を確立する必要がある場合があります。Link-Localアドレスの場合、インターフェイスは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ネイバーシップはありません）、両方のピアはトランスポート接続のリセットを試みる必要があります。次に（古い接続がまだ必要であっても）、新しい接続IDペアとの接続が既に存在しない限り、すぐにまたはオンデマンドで、新しい接続IDペアとの新しい接続を確立しようとする必要があります。
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が変更されません。ただし、もしそうなら、変更は接続に影響しません。これは、後続のポート結合/プルーンメッセージが受信された場合、最後に見たインターフェイス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.
輸送接続を介して送信される結合は、上流のルーターによってのみ表示されることに注意してください。したがって、上流のルーターとのリンク上に非ポートルーターが、同じ状態の結合状態の更新を遅らせることはありません。同様に、輸送接続に送られたプルーンは、上流のルーターによってのみ表示されます。したがって、上流のルーターとのリンク上に非ポートルーターを引き起こすことはありません。このプルーンをオーバーライドするために結合を送信します。
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パケットは、255のTTL/ホップ制限で送信する必要があります。実装は、受信機でGTSMチェックを有効にするための構成オプションを提供する必要があります。これは、直接接続された近隣からのインバウンドパケットのTTL/ホップ制限は255であることを確認することを意味しますが、実装により、異なる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接続は隣人が実際に再起動するまで起き続ける可能性があり、それでもポートが隣人に情報を送信しようとするまで留まることがあります。結合/プルーンメッセージのフローは一方向にのみであり、下流の隣人がTCPを介して接続のもう一方の端が実際にはないことを示すことができないため、これは特にPIMに関連しています。
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実装は、この目的のためにKeep-Alivesの送信もサポートしています。実装ではTCP Keep-Alivesを使用する場合がありますが、以下に定義されているポートKEEPアリブメカニズムにより、より制御と柔軟性が高まります。
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.
ポートメッセージを定期的に送信してポート接続が機能していないことを検出できます。これは、TCPとSCTPの両方に適用されます。たとえば、TCPの場合、いくつかの再試行後にTCP ACKが受信されない場合、接続はリセットされます。ポート自体は、定期的なシグナル伝達を必要としません。ポート結合/プルーンメッセージは、状態の変更がある場合にのみ送信されます。状態の変更が十分に頻繁でない場合、代わりにポートキープアライブメッセージ（セクション5.2で定義）を送信できます。たとえば、実装がポートメッセージを送信したい場合は、少なくとも60秒ごとに接続が機能していることを確認し、前のメッセージ以来60秒が通過したときはいつでも、キープアライブメッセージを送信できます。各結合/プルーンの間に60秒未満の場合、キープアライブメッセージは必要ありません。実装は、ポートキープアライブメッセージの使用をサポートする必要があります。ネットワーク管理者は、必要なときにそれを有効にするために、ネットワーク管理者が構成オプションを利用できるようにすることをお勧めします。 Keep-Alivesは、他のピアがそれをサポートするかどうかとは無関係に、ピアによって使用できることに注意してください。
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.
Keep-Aliveメッセージをサポートする実装は、受信したポートメッセージを処理する際に次のように機能します。ゼロ以外の保留タイム値でキープアライブメッセージを処理する場合、タイマーを値に設定する必要があります。このタイマー接続有効期限タイマー（CET）と呼びます。 CETがすでに実行されている場合、新しい値にリセットする必要があります。ゼロホールドタイム値でキープアライブメッセージを処理する場合、CET（実行中の場合）を停止する必要があります。 Keep-Alive以外のポートメッセージを処理する場合、CETを実行する場合は最後に受信した保留タイム値にリセットする必要があります。 CETが実行されていない場合、アクションは実行されません。 CETの有効期限が切れた場合、接続をシャットダウンする必要があります。この仕様は、特定のデフォルトの保留タイム値を義務付けません。ただし、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.
そのインターフェイスが戻ってくるとき。これは、遺伝子（生成識別子; [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.
ポートネイバーがその遺伝子を変更し、接続が確立されているか、確立されているプロセスにある場合、地元の側は一般に接続を取り壊し、セクション4.3で説明するように行う必要があります。ただし、接続が複数のインターフェイスによって共有され、そのうちの1つだけの遺伝子が変化する場合、地元の側は、上流の隣人の遺伝子が変化する場合の他のケースと同様に、完全な更新を単に送信する必要があります。
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を発表するインターフェイスに特定のリモート接続IDを持つPIM隣接がない場合、接続をシャットダウンする必要があります。これは、新しい接続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リスト）状態を解放する必要があります。下流のルーターは、上流の隣接するルーターの有効期限が切れたときに、対応する状態の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つのポート対応の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秒です。この値は[RFC4601]のセクション4.11に基づいています。これは、J/P_holdtimeが3.5 * t_periodicである必要があると述べています。ここで、T_PerioDicのデフォルトは60秒です。
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.
管理者がポートの使用を停止することを決定する状況がある場合があります。ルーターインターフェイスでポートが無効になっている場合、または以前にポート対応の近隣がポートハローオプションのいずれかを発表しなくなった場合、ルーターは、接続を削除してタイマーを開始するためにセクション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を持つルーターは、オンデマンドの接続を開始するだけです。つまり、Join/Pruneメッセージを送信する必要があり、現在確立されている接続がない場合です。
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.
この仕様に基づいて、ハローメッセージが受信されるまでトランスポート接続を確立することはできません。この理由は、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ネイバーのペア間にTCP接続が1つしかないことを確認するには、次のルールセットに従う必要があります。このセクションはTCPにのみ適用されることに注意してください。SCTPの場合、これは問題ではありません。ノードAとBを2つのPIMネイバーとし、Aの接続IDがBの接続IDよりも数値的に小さく、それぞれが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 PIM-Over-TCPポートでBへのBへの確立されたTCP接続が既にある場合、Aは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.
o AがBへの接続を開始したが、接続がまだ確立されているプロセスにある場合、AはBからPIM-Over-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（確立されるか、確立されているプロセスのいずれか）との接続がない場合はいつでも、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.)
o Pim-over-TCPポート上のAへのAへの確立されたTCP接続がすでにある場合、Bは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.
o BがAへの接続を開始したが、接続がまだ確立されている場合、Aが接続を開始する場合、BはAによって開始された接続を受け入れ、それが開始した接続を解放する必要があります。
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プロトコルファミリからの結合/プルーンメッセージを同じ輸送接続で送信できるようにすることが望ましい場合があります。また、別のアドレスファミリーネットワークレイヤーに確立された輸送接続を介して送信される1つのアドレスファミリに対して、一連の結合/プルーンメッセージを持つことが望ましい場合があります。
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.
これを行うには、共通のポートメッセージ形式が必要です。これにより、TCP/SCTPのようなストリームプロトコルを送信する際の記録境界ポイントとDEMUXポイントの両方が提供されます。
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.
ポートメッセージにはポートオプションが含まれる場合があります。セクション5.3を参照してください。PIM結合/プルーンメッセージをCORMideするための2つのポートオプションを定義します。1つはIPv4用、もう1つはIPv6用です。PIM結合/プルーンメッセージが送信される各トランスポート接続を介して送信されると、そのような1つのオプションが1つだけ含まれたポート結合/プルーンメッセージを送信します。
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.
TCPトランスポートレイヤーがJoin/Pruneバッファーを受信するとすぐにPIM結合/プルーンメッセージが配信されるようにするために、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.
ポートメッセージは、宛先TCPポート番号8471を使用して送信されます。SCTPを信頼できる輸送として使用する場合、宛先ポート番号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
ポートメッセージはエラーチェックされています。これには、不明/違法タイプのフィールドまたは切り捨てられたメッセージが含まれます。ポートメッセージにPIM結合/プルーンメッセージが含まれている場合、それは通常のPIMエラーの対象となります
checks, including checksum verification. If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages.
チェックサムの検証を含むチェック。ポートメッセージで解析エラーが発生した場合、スキップされ、次のポートメッセージに進みます。
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.
不明なタイプフィールドに遭遇した場合、そのメッセージは無視する必要があります。上記で指定したように、ポートメッセージをさらに処理すると、通常どおりに進行します。これは、既存の実装を破ることなく、将来、新しいメッセージタイプを将来指定できるようにするために重要です。ただし、未知のメッセージまたは無効なメッセージのみが長期間受信された場合、実装がオペレーターに警告する場合があります。たとえば、メッセージが間違った長さで送信される場合、受信者はその後未知/無効なメッセージのみが表示される可能性があります。
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
ポート結合/プルーンメッセージ
The PORT Join/Prune Message is used for sending a PIM Join/Prune.
PORT Join/Pruneメッセージは、PIM Join/Pruneの送信に使用されます。
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.
メッセージの長さ：タイプ/長さ/値エンコーディングの値部分のバイトの長さ。ポートオプションが含まれていない場合、長さは12です。オプション値の長さl1、l2、...、lnが含まれるnポートオプションが含まれている場合、メッセージの長さは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 Hello OptionのインターフェイスIDでなければなりません。これは、PIM Neighborに、Join/Pruneを関連付けるためのインターフェイスを示します。インターフェイス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.
ポートオプション：メッセージには、1つのPIM IPv4 Join/Pruneまたは1つのPIM IPv6 Join/PruneのいずれかのPIM Join/Pruneポートオプションが正確に含まれている必要があります。両方を含めてはなりません。このドキュメントでは定義されていない追加のオプションが含まれる場合があります。未知のオプションを含むメッセージを受信するときの動作は、オプションタイプに依存します。オプション定義については、セクション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
ポートキープアライブメッセージ
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.
ポートキープアライブメッセージは、ポートメッセージを定期的に送信して、接続が生きていることを確認するために使用されます。他のポートメッセージが目的の周波数で送信されない場合に使用されます。
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.
メッセージの長さ：タイプ/長さ/値エンコーディングの値部分のバイトの長さ。ポートオプションが含まれていない場合、長さは6です。オプション値の長さl1、l2、...、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.
ホールドタイム：これは、接続の数秒でホールドタイムを指定します。ゼロ以外の値とは、指定された時間内にそれ以上のポートメッセージが受信されない場合、接続を優雅にシャットダウンする必要があることを意味します。これは、1つのポートメッセージが処理されてから次のポートメッセージが処理されるまでの時間を測定することにより、受信側で測定されます。これは、単にアライブメッセージを保持するだけでなく、ポートメッセージに対して行う必要があることに注意してください。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.
ポートオプション：キープアライブメッセージには、このドキュメントで定義されているオプションを含めてはなりません。このドキュメントでは定義されていない他のオプションが含まれる場合があります。未知のオプションを含むメッセージを受信するときの動作は、オプションタイプに依存します。オプション定義については、セクション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ビットです。ポートオプションタイプスペースは2つの範囲で分割されます。範囲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 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.
ポートオプションタイプは、実験用の範囲32764-32767および65532-65535を除き、IANAによって割り当てられます[RFC3692]。長さは、バイトの値の長さを指定します。以下は、このドキュメントで定義されている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 Join/Pruneオプション形式
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 Join/Pruneオプションは、PIMペイロードにすべてのIPv4エンコードアドレスを持つPIMV2 Join/PruneメッセージをCARMANingに送信するために使用されます。
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ヘッダーの前に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 Join/Pruneオプション形式
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 Join/Pruneオプションは、PIMペイロードにすべてのIPv6エンコードアドレスを持つPIMV2結合/プルーンメッセージをCARMANingに送信するために使用されます。
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ヘッダーの前に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上のすべての隣人がLAN Prune遅延オプションのtビットを設定した場合、ネイティブの結合/プルーンメッセージに対しても実行される可能性があることに注意してください（[RFC4601]のセクション4.9.2の定義を参照）。以下の議論は、ET（明示的な追跡）隣人と非ET隣人を取り上げています。ET隣人のセットには、港湾隣人を含める必要があります。すべての隣人がLAN Pruneの遅延tビットを設定していない限り、非隣の隣人のセットはすべての非ポート隣人で構成されています。
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）状態の場合、ルーターは、そのようなインターフェイス上の隣人から結合が受信されると、インターフェイス上のトラフィックの転送を開始します。[RFC4601]で指定されているように、非ET隣人がプルーンを送信すると、オーバーライドタイマーの有効期限の前にこのプルーンをオーバーライドするために結合が送信されない場合、上流のルーターは、非ET隣人が関心がないと結論付けます。ET Neighborsが興味がない場合、INTERFACEはOIFリストから削除できます。ET隣人がプルーンを送ると、その隣人の結合状態を削除します。他のETまたは非ETの隣人が興味を持っていない場合、インターフェイスをOIFリストから削除することができます。ポートネイバーがプルーンを送信すると、プルーンが他の隣人には見えないため、プルーンオーバーライドはありません。
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隣人がプルーンを送ったか、そして非隣人がプルーンを送ったかどうかを知る必要があります。通常、（*、g）結合が受信されたが、no（s、g、rpt）プルーンを受信した場合、ソースSからインターフェイス上でグループGにパケットを転送します。ETを使用すると、ET Neighborごとにこのチェックを行う必要があります。つまり、パケットは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.
ルーターリソースを効率的に使用できるようにするために、同じ輸送接続で異なるアドレスファミリのメッセージを結合/プルンすることができます。これを達成できる2つの方法があります。TCP接続を介した一般的なメッセージ形式を使用するか、単一のSCTP接続で複数のストリームを使用しています。
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ベースのJoin/Pruneメッセージの両方を同じトランスポート接続内でエンコードできます。
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アサート、グラフト、接ぎ木、登録、レジスタストップなど、他の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.
考慮事項の1つは、キープアライブメカニズムです。ポートのオプションのキープアライブメカニズムを定義しました。セクション4.2を参照してください。また、SCTPおよび多くのTCP実装は、使用できるキープアライブメカニズムを提供します。キープアライブメッセージと使用するメカニズムをいつ使用するかは不明です。ただし、ポートキープアライブにより、アプリケーション制御が改善される可能性があると考えています。ポートキープアリブよりもどのホールドタイムが好ましいのかは不明です。今のところ、管理者は、キープアリブを使用するかどうか、使用するものを保持するものなどを構成できることをお勧めします。
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.
安定した状態では、ポート接続を介して時折小さなメッセージのみが送信されることが予想されます。これは、PIMが接合/プルン状態の変化の頻度に依存します。したがって、長期間にわたって、TCPの混雑ウィンドウ全体を使用しない小さなメッセージのみが存在する場合があり、ウィンドウが非常に大きくなる可能性があります。これは、ポートが非常に大きなメッセージを送信する状態の変更がある場合、問題になります。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].
ポートでは、時折小さなメッセージのみが送信される可能性があります（前の段落で説明したように）。これにより、TCPの再送信メカニズムの問題が発生する可能性があります。特に、TCP高速再送信アルゴリズムはトリガーされない場合があります。これと可能な解決策の詳細については、[RFC3042]を参照してください。
There may be SCTP issues similar to the TCP issues discussed in the above two paragraphs.
上記の2つの段落で説明した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).
このドキュメントでは、PIM近隣のペア間でTCPまたはSCTPトランスポートを使用して定義されています。このメカニズムをデフォルトで無効にすることをお勧めします。管理者は、PIM対応インターフェイスでポートTCPおよび/またはSCTPを有効にすることができます。2人の隣人が両方ともポートSCTP（または両方がポートTCPを持っている）を持っている場合、PIM Join/Pruneメッセージには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.
ポートサポートが有効になっている場合、ルーターはTCPおよび/またはSCTPおよび接続IDのサポートを発表するPIM Helloメッセージを送信します。ローカル接続IDを構成し、ポート機能と接続IDS PIM Neighborsが発表していることを確認することも可能です。これらの広告に基づいて、PIM Neighborsのペアは、ポート接続を確立しようとするかどうかを決定します。オペレーターが現在の接続状態を確認する方法があるはずです。送信および受信したポートメッセージの数（無効なメッセージの数を含む）に関する統計も役立つ場合があります。
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チェックを有効にすることができるはずです。また、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を参照）については、キープアライブメッセージをサポートすることをお勧めします。Keep-Alivesを送信するかどうか、およびその場合は、保留タイムを使用するかどうか、使用する保留タイムを使用するかどうかを構成できる必要があります。
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.
ポート接続が下がっている場合、またはポート接続の確立に障害がある場合、オペレーターに警告する方法があるはずです。また、接続障害の数や、接続が上下する期間などの情報は有用です。
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トランスポートの使用に関連するいくつかのセキュリティ問題があります。スプーフィングされたソースアドレスでパケットを送信することにより、オフパス攻撃者は接続を確立するか、既存の接続にパケットを挿入する場合があります。これにより、攻撃者はスプーフィングされた結合/プルーンメッセージを送信したり、接続をリセットできる場合があります。これから保護するのに役立つメカニズムについては、セクション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で使用でき、SCTPで認証されたチャンク[RFC4895]を使用できます。また、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.
この仕様では、IANAによって割り当てられたPIMポートサービスを使用するために、TCPポート番号とSCTPポート番号を使用します。また、永続的になったIANA PIM Hello Optionsの割り当ても使用しています。
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-Portのサービス名と輸送プロトコルポート番号レジストリに追加されました。
In the "PIM-Hello Options" registry, the following options have been added for PORT.
「PIM-Helloオプション」レジストリでは、ポート用に次のオプションが追加されています。
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].
ポートメッセージタイプのレジストリが作成されました。メッセージタイプは16ビット整数で、0から65535の値があります。RFCは0〜65531の範囲の割り当てに必要です。このドキュメントは、タイプ1（結合/プルーン）とタイプ2（キープ2つのポートメッセージタイプを定義します。-生きている）。型範囲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).
ポートオプションタイプのレジストリ。オプションタイプは16ビット整数で、値は0から65535です。タイプスペースは2つの範囲で分割され、重要なオプションの場合は0〜32767、非クリティカルなオプションでは32768-65535です。オプションタイプは、実験用の32764-32767および65532-65535の範囲を除き、IANAによって割り当てられます[RFC3692]。IANAの割り当てにはRFCが必要です。新しいオプションタイプを定義するRFCは、IANAがタイプを割り当てるために、オプションが重要であるか非クリティカルであるかを指定する必要があります。このドキュメントでは、2つの重要なポートオプションタイプを定義します。タイプ1（PIM IPv4 Join/Prune）とType 2（PIM IPv6 Join/Prune）です。
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 KaranとArjen Boersによって多大な貢献が提供されました。
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.
Randall Stewartは、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.
また、この仕様のアイデアとレビューについて以下に感謝します：マイクマクブライド、トアーレスエッカート、Yiqun Cai、Albert Tian、Suresh Boddapati、Nataraj Batchu、Daniel Voce、John Zwiebel、Yakov Rekhter、Lenny Giuliano、Gorry Fairhurst、Sameer Gulrajani、トーマス・モリン、ディミトリ・パパジミトリウ、バラト・ジョシ、リシャブ・パレフ、マナヴ・バティア、ペッカ・サヴォラ、トム・ペッチ、ジョー・タッチ。
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] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Fenner、B.、Handley、M.、Holbrook、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.、Stewart、R.、Lei、P。、およびE. Rescorla、「ストリーム制御伝送プロトコル（SCTP）の認証チャンク」、RFC 4895、2007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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] Handley、M.、Kouvelas、I.、Speakman、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] Gill、V.、Heasley、J.、Meyer、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] Touch、J.、Mankin、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、「Interface Identifier（ID）Hello Option for 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/ drastfore-family-numbers>。
[HELLO-OPT] IANA, "PIM-Hello Options", <http://www.iana.org/assignments/pim-parameters>.
[hello-opt] iana、 "pim-hello options"、<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] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465] Allman、M。、「適切なバイトカウント（ABC）によるTCP混雑制御」、RFC 3465、2003年2月。
[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
Dino Farinacci Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: dino@cisco.com
IJsbrand Wijnands Cisco Systems Tasman Drive San Jose, CA 95134 USA
IJSBRAND Wijnands Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: ice@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: stig@cisco.com
Maria Napierala AT&T Labs 200 Laurel Drive Middletown, New Jersey 07748 USA
Maria Napierala AT＆T Labs 200 Laurel Drive Middletown、ニュージャージー07748 USA
EMail: mnapierala@att.com