Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 6420 H. Ou
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 November 2011
PIM Multi-Topology ID (MT-ID) Join Attribute
Abstract
抽象
This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree.
この文書では、PIMの新しいタイプは、特定のマルチキャスト配信ツリーを構築する際に使用すべきであるトポロジを識別するために、PIMシグナリングを拡張属性に参加ご紹介します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc6420.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6420で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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 ....................................................2
2. Terminology .....................................................3
3. Functional Overview .............................................4
3.1. PIM RPF Topology ...........................................4
3.2. PIM MT-ID ..................................................6
3.3. Applicability ..............................................7
4. Protocol Specification of PIM MT-ID .............................7
4.1. PIM MT-ID Hello Option .....................................7
4.2. PIM MT-ID Join Attribute ...................................7
4.2.1. Sending PIM MT-ID Join Attribute ....................7
4.2.2. Receiving PIM MT-ID Join Attribute ..................8
4.2.3. Validating PIM MT-ID Join Attribute .................8
4.2.4. Conflict Resolution .................................9
4.2.4.1. Conflict Resolution Rules for
Upstream Routers ..........................10
4.2.4.2. Conflict Resolution Rules for
Downstream Routers ........................10
5. Packet Format ..................................................10
5.1. PIM MT-ID Hello Option ....................................11
5.2. PIM MT-ID Join Attribute TLV Format .......................11
6. IANA Considerations ............................................11
6.1. PIM MT-ID Hello Option ....................................11
6.2. PIM MT-ID Join Attribute Type .............................12
7. Security Considerations ........................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
Some unicast protocols, such as OSPF and IS-IS, allow a single network to be viewed as multiple topologies [RFC4915] [RFC5120]. Deploying multi-topology (MT) routing allows different paths through the network to be selected to support different traffic or to offer protection paths in the event of failures.
例えばOSPFやIS-ISのようないくつかのユニキャストプロトコルは、単一のネットワークが複数のトポロジ[RFC4915]、[RFC5120]として見ることを可能にします。マルチトポロジを展開する（MT）ルーティングは、ネットワークを介して異なるパスは、異なるトラフィックをサポートするため、または障害が発生した場合に保護パスを提供するように選択されることを可能にします。
PIM [RFC4601] employs a technique known as Reverse Path Forwarding (RPF) to construct forwarding trees between multicast sources and receivers. The procedure of RPF uses topology information provided by routing protocols, such as OSPF and IS-IS. Using the PIM MT-ID Join Attribute specified in this document enables PIM to access the multiple topologies created by the routing protocols and construct multicast forwarding trees using separate network paths even when the roots of the trees are the same.
PIMは、[RFC4601]はマルチキャスト送信元と受信機との間で転送木を構築するためのリバースパス転送（RPF）として知られている技術を採用しています。 RPFの手順は、OSPFなどのルーティングプロトコルによって提供されるトポロジー情報を使用して、IS-IS。 PIM MT-IDは、この文書で指定された属性の結合を使用すると、ルーティングプロトコルによって作成された複数のトポロジにアクセスし、樹木の根が同じであっても別のネットワークパスを使用して、マルチキャスト転送ツリーを構築するPIMを可能にします。
This capability would allow for an improvement to the resilience of multicast applications. For instance, a multicast stream can be duplicated and transported using two source trees, (S1, G1) and (S1, G2), simultaneously. By using MT-capable unicast routing protocols and procedures described in this document, it is possible to construct two source trees for (S1, G1) and (S1, G2) in such a way that they do not share any transit network segment. As a result, a single network failure will not cause any loss to the stream.
この機能は、マルチキャストアプリケーションの回復力の改善を可能にするであろう。例えば、マルチキャストストリームが複製され、同時に、二つのソースツリー、（S1、G1）と（S1、G2）を用いて搬送することができます。 MT-可能なユニキャストルーティングプロトコルと、この文書に記載されている手順を使用して、任意のトランジットネットワークセグメントを共有しないように（S1、G1）と（S1、G2）のための2つのソースツリーを構築することが可能です。その結果、単一のネットワーク障害がストリームに損失が発生することはありません。
This document introduces a new type of PIM Join Attribute [RFC5384], named "MT-ID Join Attribute". It is used to encode the numerical identity of the topology PIM uses when performing RPF for the forwarding tree that is being joined. This document also specifies procedures and rules to process the attribute and resolve conflicts arising from mismatches in capabilities to support the attribute or the value of the attribute.
この文書は、「MT-ID属性を結合」という名前の、PIMの新しいタイプの属性[RFC5384]を入会を紹介します。接合されている転送ツリーのためのRPFを行う場合PIMが使用するトポロジーの数値IDを符号化するために使用されます。また、このドキュメントでは、属性を処理し、属性または属性の値をサポートするために、能力の不一致から生じる紛争を解決するための手順やルールを指定します。
This document does not introduce any change to the RPF check procedure used to verify the incoming interface when a packet is forwarded as defined in [RFC4601]. For example, to use the capability described by this document, an application can choose to use group addresses, and/or source addresses, to identify a unique multicast stream. It might further need to perform the functions of splitting and merging. However, the detailed processing is beyond the scope of the document.
このドキュメントは[RFC4601]で定義されるようにパケットが転送されるときに着信インターフェイスを検証するために使用RPFチェック手順に変更を導入しません。例えば、本文書によって記述機能を使用するために、アプリケーションは、グループアドレスを使用するように選択することができ、及び/又は送信元アドレスは、一意のマルチキャストストリームを識別します。さらに、分割およびマージの機能を実行する必要がある場合があります。しかし、詳細な処理は、文書の範囲を超えています。
In the rest of the document, the MT-ID Join Attribute will be referred to as "MT-ID".
文書の残りの部分では、MT-IDは、属性が「MT-ID」と呼ぶことにする参加します。
The following acronyms are frequently used in the document.
以下の頭字語は頻繁に文書で使用されています。
- RPF: RPF stands for "Reverse Path Forwarding". A PIM router performs RPF for two purposes. When building a forwarding tree, a PIM router identifies an interface (the RPF interface) and an upstream PIM neighbor (the RPF neighbor) to which to send PIM Joins. Upon receiving a data packet, a PIM router verifies if the packet arrives from the expected incoming interface (aka RPF check) before deciding whether or not to replicate the packets.
- RPF：RPFは、「リバースパス転送」の略です。 PIMルータは2つの目的のためにRPFを実行します。転送ツリーを構築するとき、PIMルータはPIMジョイン送信するためのインタフェース（RPFインターフェイス）と上流PIMネイバー（RPFネイバー）を識別する。パケットがパケットを複製するかどうかを決定する前に予測される着信インターフェイス（別名RPFチェック）から到着した場合、データパケットを受信すると、PIMルータが検証します。
- RPF Topology: An RPF topology is a collection of routes that a PIM router uses for RPF. One or more RPF topologies may be created on a PIM router.
- RPFトポロジ：RPFトポロジは、PIMルータがRPFのために使用するルートのコレクションです。一つ以上のRPFトポロジでは、PIMルータ上で作成することができます。
- MT: MT stands for "Multi-Topology" in this document. Sometimes it is also referred to as "multi-topology routing". In the context of PIM, MT refers to the capability of building and maintaining multiple RPF topologies.
- MT：MTは、このドキュメントの「マルチトポロジ」の略です。時にはそれは、また、「マルチトポロジルーティング」と呼ばれています。 PIMの文脈では、MTは、複数のRPFトポロジを構築し、維持する能力を指します。
- PIM MT-ID: An MT-ID is a numerical identifier associated with an RPF topology.
- PIM MT-ID：MT-IDは、RPFトポロジーに関連付けられた数値識別子です。
- PIM MT-ID Join Attribute: This is a new type of Join Attribute that is introduced by this document in order to specify RPF topology in the PIM Join messages.
- PIM MT-ID属性を参加：これは、PIM加入メッセージにRPFトポロジを指定するために、本書で紹介された参加属性の新しいタイプです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
PIM relies on routes learned from routing protocols for the purpose of RPF. These routes form one or more topologies. This section describes the function of multi-topology routing for PIM and its applicability.
PIMはRPFの目的のために、ルーティングプロトコルから学習したルートに依存しています。これらのルートは、一の以上のトポロジを形成します。このセクションでは、PIMおよびその適用のためのマルチトポロジルーティングの機能について説明します。
PIM RPF topology is a collection of routes used by PIM to perform the RPF operation when building shared or source trees. The routes in the topology may be contributed by different protocols. In the rest of the document, PIM RPF topology may be simply referred to as "topology" when there is no ambiguity.
PIMのRPFトポロジは、共有またはソースツリーを構築するときRPF操作を実行するためにPIMによって使用される経路の集合です。トポロジ内のルートは異なるプロトコルによって寄与されてもよいです。あいまいがない場合、ドキュメントの残りの部分では、PIMのRPFトポロジは、単に「トポロジー」と呼ぶことができます。
In a multi-topology environment, multiple RPF topologies can be created in the same network. A particular source may be reachable in only one of the topologies or in several of them via different paths.
マルチトポロジ環境では、複数のRPFトポロジは、同じネットワーク内に作成することができます。特定のソースは、異なる経路を介してトポロジの一方のみに到達又はそれらのいくつかにあってもよいです。
To help explain the relationship between an MT-capable unicast routing protocol and MT-capable RPF topologies, consider the following example described by Figure 1.
MT-可能なユニキャストルーティングプロトコルとMT-可能なRPFトポロジとの関係を説明するために、図1で説明されている次の例を考えます。
+++ A +++ B +++
+ +
S -- R1 R2 -- receivers
* *
*** C *** D ***
Figure 1. A simple topology for multicast
マルチキャストのためのシンプルなトポロジ1.図
- The traffic source is S. S is announced by R1 using Multiprotocol BGP (MBGP) to every router. This route is installed in every topology.
- トラフィックのソースは、S Sは、すべてのルータにマルチプロトコルBGP（MBGP）を使用して、R1が発表されています。このルートは、すべてのトポロジにインストールされています。
- Two topologies are created in the unicast IGP, let us call them OSPF 1000 and OSPF 2000. OSPF 1000 includes A, B, and interfaces in R1 and R2 that are configured to be part of OSPF 1000. OSPF 2000 includes C, D, and interfaces on R1 and R2 that are configured to be part of OSPF 2000.
- 2つのトポロジがユニキャストIGPで作成され、私たちはOSPF 1000およびOSPF 2000 OSPF 1000が含まれ、それらを呼ぼう、B、及び2000がC、Dを含むOSPF 1000 OSPFの一部であるように構成されているR1及びR2のインターフェイス、 R1およびR2上のインターフェイスはOSPF 2000の一部であるように構成されています。
- Two PIM RPF topologies are created, let us call them PIM 500 and PIM 600.
- 二つのPIM RPFトポロジが作成され、私たちはPIM 500とPIM 600それらを呼びましょう。
PIM 500 comprises the following routes: S announced by MBGP and those learned via OSPF 1000.
PIM 500は、以下のルートを含む：MBGPで発表し、OSPF 1000年を経て学んだものをS。
PIM 600 comprises the following routes: S announced by MBGP and those learned via OSPF 2000
PIM 600は、以下のルートを含む：MBGPで発表し、OSPF 2000を介して学習それらのS
The above example illustrates that the naming spaces of MT-ID are not required to be the same between PIM and IGPs. Furthermore, a unicast IGP topology and the PIM RPF topology to which the IGP topology contributes routes are not required to have the same set of routes. In the above example, the prefix covering S does not exist in either OSPF 1000 or OSPF 2000, but since it exists in PIM 500 and PIM 600, R2 is able to join to it via either path.
上記の例では、MT-IDのネームスペースは、PIMとのIGPの間で同じである必要はないことを示しています。また、ユニキャストIGPトポロジとIGPトポロジがルートに寄与するたPIM RPFトポロジは、ルートの同じセットを有することが必要とされません。上記の例では、Sを覆う接頭辞のいずれかOSPF 1000 OSPF 2000年には存在しないが、それはPIM 500およびPIM 600に存在するので、R2は、いずれかの経路を介してそれに参加することが可能です。
There are two methods to select the RPF topology for a particular multicast distribution tree, via configuration or via PIM.
コンフィギュレーションを介して、またはPIMを経由して、特定のマルチキャスト配信ツリーのためのRPFトポロジを選択するための2つの方法があります。
When it is done via configuration, a network administrator configures a policy that maps a group range to a topology and/or maps a source prefix range to a topology. Using the same example, the policy can say that to build a forwarding tree for G1 only routes in PIM 500 are to be used, and to build a forward tree for G2 only routes in PIM 600 are used. The result is that packets for (S, G1) will follow the path of S-R1-A-B-R2 and packets for (S, G2) will follow the path of S-R1-C-D-R2.
それはコンフィギュレーションを介して行われている場合は、ネットワーク管理者は、トポロジにグループ範囲をマッピングおよび/またはトポロジにソースプレフィックス範囲をマップするポリシーを設定します。同じ例を使用して、ポリシーがG1の転送ツリーを構築することを言うことができるPIM 500の唯一の経路が使用される、およびPIM 600でのみルートが使用されているG2のための順方向ツリーを構築します。結果のためのパケット（S、G1）はS-R1-A-B-R2とのためのパケット（S、G2）の経路をたどることであるS-R1-C-D-R2の経路をたどります。
An alternative to static configuration is to include the RPF topology information as a new PIM Join Attribute in the PIM Join packets sent by downstream routers.
新しいPIMは、PIM内の属性が下流のルータによって送信されたパケットを参加しようと静的構成の代替は、RPFトポロジ情報を含めることです。
Both methods can be used at the same time. The details of the first method are implementation specific and are not discussed in this document. The specification to support the second method is included in this document.
両方の方法を同時に使用することができます。第一の方法の詳細は実装固有のものであり、本書では説明しません。第二の方法をサポートするための仕様は、この文書に含まれています。
For each PIM RPF topology created, a unique numerical ID is assigned per PIM domain. This ID is called the PIM MT-ID. The PIM MT-ID has the following properties.
作成した各PIMのRPFトポロジの場合は、一意の数値IDは、PIMドメインごとに割り当てられます。このIDは、PIM MT-IDと呼ばれています。 PIM MT-IDは、次の特性を持っています。
- It is the path identifier that is used by the PIM control plane, but it does not function in the forwarding state for a specific topology. The differentiation for topologies on the forwarding plane is made by different group addresses and/or source addresses instead.
- それは、PIM制御プレーンによって使用されるパスの識別子であり、それは、特定のトポロジにフォワーディング状態では機能しません。転送プレーン上のトポロジの分化は、代わりに、異なるグループのアドレス及び/又は送信元アドレスによって行われます。
- As shown earlier, this value is not required to be the same as the MT-ID used by the unicast routing protocols that contribute routes to the topology. In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is used, the PIM MT-ID is RECOMMENDED to be assigned using the same value as the IGP topology identifier. Using the same example presented earlier, if every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to name this RPF topology as PIM 1000 instead of PIM 500. This is for the purpose of reducing management overhead and simplifying troubleshooting.
- 以前に示されているように、この値は、トポロジへのルートを寄与するユニキャストルーティングプロトコルによって使用されるMT-IDと同じである必要はありません。 （例えば、OSPFまたはIS-ISなど）のみ、ユニキャストルーティングプロトコルが使用されて実際に、PIM MT-IDは、IGPトポロジ識別子と同じ値を使用して割り当てることが推奨されます。 PIM 500内のすべてのルートがOSPF 1000が寄与された場合、以前に提示同じ例を使用し、管理オーバーヘッドを低減し、トラブルシューティングを簡素化するためである代わりにPIM 500のPIM 1000このRPFトポロジに名前を付けることが推奨されます。
- This value MUST be unique and consistent within the network for the same topology. For example, PIM 500 MUST refer to the same topology on routers R1, C, D, and R2. For actual deployment, one should have a means to detect inconsistency of the PIM MT-ID configuration, but the detail of such mechanism is beyond the scope of this document.
- この値は、同じトポロジのネットワーク内で一意と一致していなければなりません。例えば、PIM 500は、ルータR1、C、D、およびR2上の同じトポロジーを参照しなければなりません。実際の展開では、1は、PIM MT-IDの設定の矛盾を検出する手段を持たなければならないが、そのようなメカニズムの詳細は、このドキュメントの範囲を超えています。
- 0 is reserved as the default, and it MUST NOT be included in the Join Attribute encoding.
- 0がデフォルトとして予約されており、それが参加属性エンコーディングに含まれてはいけません。
- How to assign a PIM MT-ID to a topology is decided by the network administrator and is outside the scope of this document.
- どのようにトポロジにPIM MT-IDを割り当てるには、ネットワーク管理者が決定し、この文書の範囲外です。
The PIM MT-ID Join Attribute described in this document applies to PIM Join/Assert packets used by PIM SM/SSM/Bidir (Sparse Mode/Source-Specific Mode/Bidirectional). It is not used in any other PIM packets. As such, it can only be used to build shared or source trees for PIM SM/SSM and PIM-Bidir downstream.
PIM MT-IDは、この文書で説明する属性/参加PIM PIM SM / SSM /双方向（希薄モード/ソース固有モード/双方向）で使用されるパケットをアサートするために適用されるに参加しましょう。これは、他のPIMパケットで使用されていません。そのようなものとして、それだけ下流PIM SM / SSMおよびPIM-双方向の共有やソースツリーを構築するために使用することができます。
When this attribute is used in combination with RPF vectors defined in [RFC5496] and [MVPN], the vectors are processed against the topology identified by the PIM MT-ID attribute.
この属性は[RFC5496]と[MVPN]で定義されたRPFベクターと組み合わせて使用される場合、ベクターは、PIM MT-ID属性によって識別トポロジーに対して処理されます。
The change to the PIM protocol includes two pieces: the PIM MT-ID Hello Option and the PIM MT-ID Join Attribute.
PIMプロトコルへの変更は、2枚が含まれています。PIM MT-IDこんにちはオプションとPIM MT-IDは、属性に参加します。
The PIM MT-ID Hello Option is used by a router to indicate if it supports the functionality described by this document. If it does, it MUST include the PIM Hello Option in its PIM Hello packets and MUST include both the Join Attribute Option [RFC5384] and the new PIM MT-ID Option (see Section 5.1 of this document for packet format).
PIM MT-IDこんにちはオプションは、この文書で説明した機能をサポートしているかどうかを示すためにルータが使用されます。それがない場合は、そのPIM HelloパケットでPIMハローオプションを指定する必要がありますし、参加属性オプション[RFC5384]と新しいPIM MT-IDオプション（パケットフォーマットは、このドキュメントのセクション5.1を参照）の両方を含まなければなりません。
When a PIM router originates a PIM Join/Assert packet, it may choose to encode the PIM MT-ID of the topology in which RPF lookup is to take place for the corresponding (*,G) or (S,G) entry. The PIM MT-ID identifies the topology chosen by local policy/configuration or is the value received from downstream routers after MT-ID conflict resolution procedures have been applied (See Section 4.2.4 for further detail).
PIMルータがPIMに参加/アサートパケットを発信するとき、それはRPFルックアップが該当する（*、G）または（S、G）エントリのための場所を取ることであるトポロジーのPIM MT-IDをエンコードすることもできます。 PIM MT-IDは、ローカルポリシー/構成によって選択されたトポロジを識別またはMT-IDの競合解決手順が適用された後に（さらなる詳細については、セクション4.2.4を参照）、下流のルータから受信した値です。
The following are the exceptions:
以下は例外です。
- A router SHOULD NOT include the attribute if PIM MT-ID is 0. The value of 0 is ignored on reception.
- PIM MT-IDが0の値は、レセプションで無視された0の場合、ルータは、属性を含めるべきではありません。
- A router SHOULD NOT include the PIM MT-ID in its Join/Assert packets if the upstream router, or any of the routers on the LAN, does not include the "PIM Join Attribute" or "PIM MT-ID" option in its Hello packets.
- 上流のルータ、またはLAN上のルータのいずれかが、またはその中に「PIM MT-ID」オプション「PIMは属性に参加」が含まれていない場合、ルータは、その参加/アサートパケットでPIM MT-IDを含めるべきではありませんパケットこんにちは。
- A router SHOULD NOT attach PIM MT-ID for pruned sources. PIM MT-ID MUST be ignored for a pruned source by a router processing the Prune message.
- ルータは剪定されたソースのPIM MT-IDを添付すべきではありません。 PIM MT-IDは、プルーンメッセージを処理するルータによって剪定ソースでは無視されなければなりません。
When a PIM router receives a PIM MT-ID Join Attribute in a Join/Assert packet, it MUST perform the following:
PIMルータがPIM MT-IDが参加/アサートパケット内の属性をJoinを受信すると、それは次のことを実行する必要があります。
- Validate the attribute encoding. The detail is described in the next section.
- 属性のエンコーディングを検証します。詳細は次のセクションで説明されています。
- If the Join Attribute is valid, use the rules described in the section "Conflict Resolution" to determine a PIM MT-ID to use.
- 参加属性が有効な場合、使用するPIM MT-IDを決定するためには、「紛争解決」で説明したルールを使用しています。
- Use the topology identified by the selected PIM MT-ID to perform RPF lookup for the (*,G)/(S,G) entry unless a different topology is specified by a local configuration. The local configuration always takes precedence.
- 異なるトポロジーはローカル設定で指定されない限り、（*、G）/（S、G）エントリのRPFルックアップを実行するために選択されたPIM MT-IDによって識別されるトポロジーを使用。ローカル設定は常に優先されます。
While it is an exception case, it is worthwhile to describe what will happen if a router receives PIM MT-ID Join Attribute but doesn't support the functionality described in [RFC5384] or this document. If the router supports [RFC5384] but not this document, it is able to skip the PIM MT-ID Join Attribute and move on to the next Join Attribute, if one is present. The RPF decision will not be altered because the router doesn't understand the meaning of the PIM MT-ID Join Attribute. The router will use the procedures described by [RFC5384] to perform conflict resolution.
それは例外ケースであるが、ルータがPIM MT-ID属性を参加受信するが、[RFC5384]や、この文書で説明した機能をサポートしていない場合はどうなるのかを説明する価値があります。ルータのサポート[RFC5384]ではなく、この文書場合は、属性に参加して、1が存在する場合、属性に参加し次に進むPIM MT-IDを省略することができます。ルータがPIM MT-IDの意味を理解属性に参加していないため、RPFの決定は変更されません。ルータは、競合解決を実行するために[RFC5384]で説明した手順を使用します。
If a router doesn't support [RFC5384], it will ignore the Join/Assert message because it is not able to parse the encoded sources.
ルータは[RFC5384]をサポートしていない場合は、エンコードされたソースを解析することができないので、それがアサート/ Joinメッセージを無視します。
If a router does support both [RFC5384] and this document, but chooses not to send either the PIM MT-ID or the PIM Join Attribute Option in its Hello packets (likely due to administrative reasons), it SHOULD ignore the Join/Assert message when it receives a PIM Join/Assert packet with the PIM MT-ID Join Attribute.
ルータは、[RFC5384]とこのドキュメントの両方をサポートしていますが、PIM MT-IDやPIMのいずれかを送信しないことを選択した場合は（による管理上の理由の可能性が高い）そのHelloパケットで属性オプションに参加し、それが参加/アサートメッセージを無視すべきですそれが受信したときPIMは、PIM MT-ID属性に参加して/アサートパケットに参加します。
An upstream router MUST be known to support this document in order for a downstream router to include the PIM MT-ID attribute in its Join packets. However, an upstream router doesn't need to know whether or not a downstream router supports this document when deciding whether to accept the attribute. Hence, if the Join packet sender doesn't include the "PIM Join Attribute" or "PIM MT-ID" options in its Hello packets, the PIM MT-ID attribute in the Join may still be considered valid. This is also in accordance with the "Robustness Principle" outlined in [RFC793].
上流のルータは、その参加パケットにおけるPIM MT-ID属性を含むように、下流ルータのためにこの文書をサポートすることを知らなければなりません。しかし、上流のルータは、属性を受け入れるかどうかを決定する際、下流ルータがこの文書をサポートしているかどうかを知る必要はありません。参加パケット送信者が含まれていない場合したがって、またはそのHelloパケットで「PIM MT-ID」オプション「PIM属性への参加」、参加中のPIM MT-ID属性は依然として有効とみなすことができます。これは、[RFC793]に概説「ロバスト性の原則」に従ってもあります。
The following text specifies the detail of the validity check.
次のテキストは、妥当性チェックの詳細を指定します。
- There is at most 1 PIM MT-ID attribute encoded. If there are multiple PIM MT-ID Join Attributes included (possibly due to an error in the implementation), only the last one is accepted for this particular source. Processing of the rest of the Join message continues.
- エンコードされた高々1 PIM MT-ID属性があります。複数PIM MT-IDは、（おそらく実装におけるエラーのために）含まれている属性に参加がある場合、最後のものだけが、この特定のソースに受け入れられています。 Joinメッセージの残りの処理は続行されます。
- The Length field must be 2. If the Length field is not 2, the rest of the Join message, including the current (S,G) or (*,G) entry, MUST be ignored. The group, source, and Rendezvous Point (RP) in the Join message that have already been processed SHOULD still be considered valid.
- 長さフィールドが2ではない場合は、長さフィールドは2である必要があり、現在の（S、G）または（*、G）エントリを含む参加メッセージの残りの部分は、無視されなければなりません。すでに処理されたJoinメッセージのグループ、ソース、およびランデブーポイント（RP）がまだ有効であると見なされるべきです。
- The value MUST NOT be 0. If it is 0, the PIM MT-ID attribute is ignored. Processing of the rest of the Join message, including the current (S,G) or (*,G) entry, continues as if the particular PIM MT-ID attribute weren't present in the packet.
- それはPIM MT-ID属性は無視され、0であれば値は0であってはなりません。特にPIM MT-ID属性がパケットに存在しなかったかのように現在の（S、G）または（*、G）エントリを含む参加メッセージの残りの処理は、継続します。
The definition of "PIM MT-ID conflict" varies depending on whether it is on an upstream or a downstream router.
「PIM MT-IDの競合」の定義は、それが上流または下流のルータ上にあるかどうかに依存して変化します。
PIM MT-ID conflicts arises on an upstream router when the router doesn't have a local topology selection policy and receives Join packets from downstream routers and/or Assert packets from other forwarding routers on the LAN and those packets contain different PIM MT-IDs.
ルータはローカルトポロジー選択ポリシーを持っているし、下流のルータからのパケットを結合および/またはLAN上の他の転送ルータからのパケットをアサート受けていないときPIM MT-IDの競合が上流のルータ上で発生し、これらのパケットは異なるPIM MT-IDを含めます。
However, if an upstream router has a local configuration that specifies PIM MT-IDs to identify RPF topologies, and those MT-IDs do not match the MT-ID on a received Join or Assert packet, this is not considered to be a conflict and the resolution procedures are not applied. This includes the case where there are local PIM MT-IDs, but there is no PIM MT-ID encoded in the incoming packet.
上流のルータはRPFトポロジを識別するために、PIM MT-IDを指定するローカル構成を有しており、これらのMT-IDを受け取った参加またはアサートパケットにMT-IDと一致しない場合は、これは、競合と見なされず、解決手順は適用されません。これは、ローカルPIM MT-IDが存在する場合を含むが、着信パケットに符号化されないPIM MT-IDは存在しません。
On the other hand, when a downstream router sees a different PIM MT-ID attribute from other routers on the LAN, it applies rules to resolve the conflicts regardless of whether or not the router has local topology selection policy.
下流のルータはLAN上の他のルータと異なるPIM MT-ID属性を見ている一方、それは関係なく、ルータはローカルトポロジー選択ポリシーを持っているかどうかの競合を解決するためのルールを適用します。
When two PIM MT-IDs are compared, only the 12-bit Value field (see Section 5.2) is compared. Other fields of the PIM MT-ID Join Attribute TLV Format (including the four reserved bits) MUST NOT be used in the comparison.
2 PIM MT-IDが比較され、わずか12ビットの値フィールド（セクション5.2を参照）と比較されます。 PIM MT-IDの他のフィールドは、（4つの予約ビットを含む）TLVフォーマット属性参加比較に使用してはいけません。
- If an upstream router receives different PIM MT-ID attributes from PIM Join packets, it MUST follow the rules specified in [RFC5384] to select one. The PIM MT-ID chosen will be the one encoded for its upstream neighbor.
- 上流のルータは異なるPIM MT-IDがパケットを参加PIMから属性を受信した場合、それはいずれかを選択し、[RFC5384]で指定されたルールに従わなければなりません。選択したPIM MT-IDは、その上流の隣人のためにエンコードされたいずれかになります。
In order to minimize the chances of potential transient forwarding loops, an upstream router MAY choose to ignore the incoming PIM Join packets altogether if it sees a conflict in PIM MT-ID attributes. This action may also be taken by an upstream router that has locally configured topology selection policy, as an exception to the rules described above.
潜在的な過渡転送ループの可能性を最小限にするためには、上流のルータはPIM MT-ID属性で紛争を見れば、受信PIMは完全にパケットを参加無視することを選択するかもしれません。この作用はまた、局所的に、上述の規則の例外として、トポロジー選択ポリシーを設定したアップストリームルータによって取られてもよいです。
- If an upstream router receives a different PIM MT-ID attribute in an Assert packet, it MUST use the tiebreaker rules as specified in [RFC4601] to determine an Assert winner. PIM MT-ID is not considered in deciding a winner from Assert process.
- アップストリームルータがアサートパケットに異なるPIM MT-ID属性を受信した場合[RFC4601]で指定されるように、それがアサート勝者を決定するために、タイブレークのルールを使用しなければなりません。 PIM MT-IDは、アサートプロセスからの勝者を決定する際に考慮されていません。
- If a downstream router sees different PIM MT-ID attributes from PIM Join packets, it MUST follow the specification of [RFC4601] as if the attribute did not exist. For example, the router suppresses its own Join packet if a Join for the same (S,G) is seen.
- 下流のルータが見れば異なるPIM MT-IDがパケットを参加PIMから属性属性が存在していなかったかのように、それは[RFC4601]の仕様に従わなければなりません。見られる同一の（S、G）のために参加した場合、例えば、ルータは、自身の参加パケットを抑制することができます。
The router MUST NOT use the rules specified in [RFC5384] to select a PIM MT-ID from Join packets sent by other downstream routers.
ルータは、他の下流のルータによって送信されたパケットを参加からPIM MT-IDを選択するには、[RFC5384]で指定されたルールを使用してはなりません。
- If a downstream router sees its preferred upstream router loses in the Assert process, and the Assert winner uses a different PIM MT-ID, the downstream router SHOULD still choose the Assert winner as the RPF neighbour, but it MUST NOT encode PIM MT-ID when sending Join packets to it.
- 下流のルータが見ればその好適上流のルータがアサートプロセスで失い、アサート勝者が異なるPIM MT-IDを使用して、下流のルータがまだRPF隣人としてアサート勝者を選択する必要がありますが、それはPIM MT-をエンコードしてはなりませんID、それにパケットを送信するときに参加。
This section describes the format of new PIM messages introduced by this document. The messages follow the same transmission order as the messages defined in [RFC4601].
このセクションでは、この文書によって導入された新しいPIMメッセージの形式について説明します。メッセージは、[RFC4601]で定義されたメッセージと同じ送信順序に従います。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType = 30 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- OptionType: 30.
- でoptionType：30。
- OptionLength: 0.
- オプションの長さ：0。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr Type | Length |R R R R| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- F bit: 0 Non-transitive Attribute.
- Fビット：0非推移属性。
- E bit: As specified by [RFC5384].
- Eビット：[RFC5384]で指定されるように。
- Attr Type: 2
- Attrのタイプ：2
- Length: 2.
- 長さ：2。
- R: Reserved bits, 4 in total. Set to zero on transmission. Ignored upon receipt.
- R：予約ビット、合計4。送信時にゼロに設定してください。受信時に無視されます。
- Value: PIM MT-ID, 1 to 4095.
- 値：PIM MT-ID、4095から1。
IANA maintains a registry of "Protocol Independent Multicast (PIM) Parameters" with a sub-registry called "PIM-Hello Options".
IANAは、「PIM-こんにちはオプション」と呼ばれるサブレジストリで「プロトコル独立マルチキャスト（PIM）パラメータ」のレジストリを維持します。
The IANA has assigned the PIM Hello Option type value 30 for the PIM MT-ID Hello Option according to the First Come First Served allocation policy.
IANAは、まず最初に役立った割り当てポリシーを、是非によるPIM MT-IDのHelloオプションのためのPIMこんにちはオプションタイプ値30を割り当てています。
The IANA has assigned a Length value of 0.
IANAは、0の長さの値が割り当てられています。
The IANA maintains a registry of "Protocol Independent Multicast (PIM) Parameters" with a sub-registry called "PIM Join Attribute Types".
IANAは、「PIM参加属性タイプ」と呼ばれるサブレジストリでのレジストリの「プロトコル独立マルチキャスト（PIM）パラメータ」を維持しています。
The IANA has assigned a value of 2 for the PIM MT-ID Join Attribute defined in Section 5.2 of this document.
IANAはこのドキュメントのセクション5.2で定義された属性に参加PIM MT-IDのために2の値を割り当てています。
As described in [RFC5384], the security of the Join Attribute is only guaranteed by the security of the PIM packet that carries it. Similarly, the security of the Hello Option is only guaranteed by securing the whole Hello Packet.
[RFC5384]で説明したように、参加属性のセキュリティは唯一それを運ぶPIMパケットのセキュリティによって保証されています。同様に、こんにちはオプションのセキュリティは全体のみのHelloパケットを確保することにより保証されています。
In view of the fact that malicious alteration of the PIM MT-ID Hello Option or the PIM MT-ID carried in a packet might cause the PIM resiliency goals to be violated, the security considerations of [RFC4601] apply to the extensions described in this document.
パケットで運ばれたPIM MT-IDこんにちはオプションまたはPIM MT-IDの悪質な改ざんは、PIMの弾力性の目標に違反することが原因かもしれないという事実を考慮すると、[RFC4601]のセキュリティ上の考慮事項は、この中で説明した拡張子に適用されます資料。
As a type of PIM Join Attribute, the security considerations described in [RFC5384] apply here. Specifically, malicious alteration of PIM MT-ID may cause the resiliency goals to be violated.
属性に参加PIMの種類として、[RFC5384]で説明されたセキュリティ上の考慮事項が適用されます。具体的には、PIM MT-IDの悪意のある改ざんに違反する弾力性の目標を引き起こす可能性があります。
The authors would like to thank Eric Rosen, Ice Wijnands, Dino Farinacci, Colby Barth, Les Ginsberg, Dimitri Papadimitriou, Thomas Morin, and Hui Liu for their input.
作者は彼らの入力のためにエリック・ローゼン、アイスWijnands、ディノファリナッチ、コルビーバース、レ・ギンズバーグ、ディミトリPapadimitriou、トーマス・モリン、およびホイ劉に感謝したいと思います。
The authors would also like to thank Adrian Farrel for his detailed and constructive comments during the AD review.
著者らはまた、ADの審査の間に彼の詳細かつ建設的なコメントのためのエードリアンファレルに感謝したいと思います。
[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月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384]ボーア人は、A.、Wijnands、I.、およびE.ローゼンは、RFC 5384、2008年11月 "プロトコル独立マルチキャスト（PIM）は、属性のフォーマットに参加します"。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、ロイ、A.、グエン、L.、およびP. Pillay-Esnault、 "OSPFにおけるマルチトポロジー（MT）ルーティング"、RFC 4915、2007年6月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、シェン、N。、およびN. Shethは、 "M-ISIS：中間システムへの中間システムにおけるマルチトポロジー（MT）ルーティング（IS-ISS）"、RFC 5120、2008年2月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496] Wijnands、IJ。、ボーア人、A.、およびE.ローゼン、 "リバースパス転送（RPF）のベクトルTLV"、RFC 5496、2009年3月。
[MVPN] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[MVPN]ローゼン、E.およびR.アガルワル、 "MPLS / BGP VPNのIPマルチキャストで"、進歩、2010年1月の作業。
Authors' Addresses
著者のアドレス
Yiqun Cai Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Yiqunカイシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: ycai@cisco.com
メールアドレス：ycai@cisco.com
Heidi Ou Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ハイジ王シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: hou@cisco.com
メールアドレス：hou@cisco.com