[要約] RFC 6420は、PIM Multi-Topology ID（MT-ID）Join属性に関する仕様です。このRFCの目的は、PIMルータが異なるトポロジーを持つ複数のPIMドメインに参加できるようにするための方法を提供することです。
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
PIM Multi-Topology ID（MT-ID）属性
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
この機能により、マルチキャストアプリケーションの回復力を改善できます。たとえば、マルチキャストストリームは、2つのソースツリー（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 Join Attribute」という名前の新しいタイプのPIM Join属性[RFC5384]を紹介します。結合されている転送ツリーのRPFを実行するときにPIMが使用するトポロジーの数値的アイデンティティをエンコードするために使用されます。また、このドキュメントは、属性を処理し、機能の不一致から生じる競合を解決する手順とルールを指定して、属性または属性の値をサポートします。
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ルーターは、インターフェイス（RPFインターフェイス）と上流のPIM隣接（RPF隣接）を識別し、PIM結合を送信します。データパケットを受信すると、パケットを複製するかどうかを決定する前に、パケットが予想されるインターフェイス（別名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に使用するルートのコレクションです。PIMルーターに1つ以上のRPFトポロジを作成できます。
- 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 JOIN属性：これは、PIM JoinメッセージにRPFトポロジを指定するために、このドキュメントによって導入される新しいタイプのJoin属性です。
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" 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を目的としてルーティングプロトコルから学習したルートに依存しています。これらのルートは、1つ以上のトポロジーを形成します。このセクションでは、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トポロジを作成できます。特定のソースは、トポロジの1つのみで、または異なるパスを介してそれらのいくつかで到達可能になる場合があります。
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です。SSは、すべてのルーターにマルチプロトコル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.
- ユニキャストIGPで2つのトポロジが作成され、OSPF 1000とOSPF 2000と呼びましょう。OSPF1000には、OSPF 1000の一部として構成されているR1およびR2のA、B、およびR2のインターフェイスが含まれます。OSPF 2000の一部として構成されているR1およびR2のインターフェイス。
- Two PIM RPF topologies are created, let us call them PIM 500 and PIM 600.
- 2つのPIM RPFトポロジが作成されています。PIM500とPIM 600と呼びましょう。
PIM 500 comprises the following routes: S announced by MBGP and those learned via OSPF 1000.
PIM 500は、次のルートで構成されています。Sは、MBGPによって発表され、OSPF 1000を介して学んだルートです。
PIM 600 comprises the following routes: S announced by MBGP and those learned via OSPF 2000
PIM 600は次のルートで構成されています。SはMBGPによって発表され、OSPF 2000で学んだルート
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とIGPSの間で同じである必要がないことを示しています。さらに、Unicast IGPトポロジーとIGPトポロジが貢献するPIM RPFトポロジは、ルートを同じルートにする必要はありません。上記の例では、SはOSPF 1000またはOSPF 2000のいずれにも存在しませんが、PIM 500とPIM 600に存在するため、R2はいずれかのPATHを介して結合できます。
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.
構成を介して実行されると、ネットワーク管理者は、グループ範囲をトポロジーにマッピングするポリシーを構成し、ソースプレフィックス範囲をトポロジーにマッピングします。同じ例を使用して、ポリシーは、PIM 500のG1のみルート用の転送ツリーを構築するために使用され、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.
静的構成の代わりに、RPFトポロジ情報を、下流ルーターから送信したPIM結合パケットの新しいPIM結合属性として含めることです。
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.
どちらの方法も同時に使用できます。最初の方法の詳細は実装固有であり、このドキュメントでは説明されていません。2番目の方法をサポートする仕様は、このドキュメントに含まれています。
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トポロジごとに、PIMドメインごとに一意の数値IDが割り当てられます。この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と同じである必要はありません。実際には、1つのユニキャストルーティングプロトコル（OSPFやIS-ISなど）のみを使用する場合、PIM MT-IDはIGPトポロジ識別子と同じ値を使用して割り当てることをお勧めします。前述の同じ例を使用して、PIM 500のすべてのルートがOSPF 1000によって寄稿されている場合、このRPFトポロジーをPIM 500ではなくPIM 1000と呼ぶことをお勧めします。これは、管理オーバーヘッドを削減し、トラブルシューティングを簡素化する目的です。
- 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の同じトポロジーを参照する必要があります。実際の展開については、PIM MT-ID構成の矛盾を検出する手段が必要ですが、そのようなメカニズムの詳細はこのドキュメントの範囲を超えています。
- 0 is reserved as the default, and it MUST NOT be included in the Join Attribute encoding.
- 0はデフォルトとして予約されており、Join属性エンコードに含めてはなりません。
- 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 SM/SSM/Bidir（スパースモード/ソース固有モード/双方向）で使用されるPIM結合/アサートパケットに適用されます。他のPIMパケットでは使用されていません。そのため、PIM SM/SSMおよびPIM-BIDIRの下流の共有またはソースツリーを構築するためにのみ使用できます。
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プロトコルの変更には、PIM MT-ID Hello OptionとPIM MT-ID Join属性の2つのピースが含まれています。
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 Helloオプションは、このドキュメントで説明されている機能をサポートするかどうかを示すためにルーターによって使用されます。そうである場合は、PIM Hello PacketsにPIM Helloオプションを含める必要があり、Join Attributeオプション[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.
- ルーターには、Pimp My-IDの属性を含めるべきではありません。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結合属性」または「PIM MT-ID」オプションがHelloに含まれていない場合、ルーターには結合/アサートパケットに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ルーターがJoin/AssertパケットでPIM MT-ID結合属性を受信した場合、次のことを実行する必要があります。
- 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.
- Join属性が有効な場合は、セクション「競合解決」で説明されているルールを使用して、使用する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.
- 選択したPIM MT-IDで識別されたトポロジを使用して、ローカル構成によって異なるトポロジが指定されていない限り、（*、g）/（s、g）エントリのRPFルックアップを実行します。ローカル構成は常に優先されます。
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]をサポートしているが、このドキュメントではない場合、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]をサポートしていない場合、エンコードされたソースを解析できないため、結合/アサートメッセージが無視されます。
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]とこのドキュメントの両方をサポートしているが、Hello PacketsにPIM MT-IDまたはPIM JOIN属性オプションのいずれかを送信しない場合（おそらく管理上の理由により）、結合メッセージを無視する必要がありますPIM MT-ID JOIN属性を使用してPIM結合/アサートパケットを受信したとき。
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"
下流のルーターが結合パケットにPIM MT-ID属性を含めるために、このドキュメントをサポートするためにアップストリームルーターを把握する必要があります。ただし、上流のルーターは、属性を受け入れるかどうかを決定する際に、下流のルーターがこのドキュメントをサポートするかどうかを知る必要はありません。したがって、Join Packet Senderに「PIM Join属性」または「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].
HelloパケットのオプションであるJoinの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結合属性が含まれている場合（おそらく実装のエラーによる）、この特定のソースでは最後の属性のみが受け入れられます。結合メッセージの残りの部分の処理は継続されます。
- 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）エントリを含む結合メッセージの残りの部分は無視する必要があります。すでに処理されている結合メッセージのグループ、ソース、およびランデブーポイント（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.
- 値は0であってはなりません。0の場合、PIM MT-ID属性は無視されます。現在（s、g）または（*、g）エントリを含む結合メッセージの残りの部分の処理は、特定のpim mt-id属性がパケットに存在しないかのように継続します。
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結合属性TLV形式（4つの予約済みビットを含む）の他のフィールドは、比較で使用してはなりません。
- 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結合パケットから異なるPIM MT-ID属性を受信する場合、[RFC5384]で指定されたルールに従って1つを選択する必要があります。選択された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結合パケットから異なるPIM MT-ID属性を確認する場合、属性が存在しないかのように[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.
ルーターは、[RFC5384]で指定されたルールを使用して、他のダウンストリームルーターから送信された結合パケットからPIM MT-IDを選択してはなりません。
- 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.
- Option -Length：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
- アットタイプ：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、1〜4095。
IANA maintains a registry of "Protocol Independent Multicast (PIM) Parameters" with a sub-registry called "PIM-Hello Options".
IANAは、「PIM-Hello Options」と呼ばれるサブレジストリを備えた「プロトコル独立マルチキャスト（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は、最初のCome First Service Allocationポリシーに従って、PIM MT-ID Hello OptionにPIM Hello Option Type Value 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 Join Attribute Types」と呼ばれるサブレジストリを使用して、「プロトコル独立マルチキャスト（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オプションのセキュリティは、Hello Packet全体を確保することによってのみ保証されます。
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 Hello Optionまたは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.
著者は、Eric Rosen、Ice Wijnands、Dino Farinacci、Colby Barth、Les Ginsberg、Dimitri Papadimitriou、Thomas Morin、Hui Liuに意見を述べてくれたことに感謝します。
The authors would also like to thank Adrian Farrel for his detailed and constructive comments during the AD review.
著者はまた、広告のレビュー中に彼の詳細かつ建設的なコメントについてエイドリアン・ファレルに感謝したいと思います。
[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月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384] Boers、A.、Wijnands、I。、およびE. Rosen、「プロトコル独立マルチキャスト（PIM）結合属性形式」、RFC 5384、2008年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「Multi-Topology（MT）Routing in OSPF」、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.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）中間システムのルーティング（MT）中間システム（IS-IS）、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。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、2009年3月。
[MVPN] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[MVPN] Rosen、E。およびR. Aggarwal、「MPLS/BGP IP VPNSのマルチキャスト」、2010年1月、進行中の作業。
Authors' Addresses
著者のアドレス
Yiqun Cai Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Yiqun Cai Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: ycai@cisco.com
Heidi Ou Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Heidi Ou Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: hou@cisco.com