[要約] RFC 6037は、Cisco Systemsが提案するBGP/MPLS IP VPNsにおけるマルチキャストのソリューションに関するものです。このRFCの目的は、BGP/MPLS IP VPNs環境でのマルチキャストの実装方法と、その利点を説明することです。
Independent Submission E. Rosen, Ed.
Request for Comments: 6037 Y. Cai, Ed.
Category: Historic I. Wijnands
ISSN: 2070-1721 Cisco Systems, Inc.
October 2010
Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
BGP/MPLS IP VPNSのマルチキャストのためのCisco Systemsのソリューション
Abstract
概要
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document.
このドキュメントでは、Cisco Systemsによって設計および展開されたMVPN（BGP/MPLS IP VPNSのマルチキャスト）ソリューションについて説明します。このドキュメントで指定された手順は、主にIETFによって標準化された一般化されたMVPNフレームワークのサブセットです。ただし、本明細書で指定された手順の展開は、IETF標準の公開（場合によっては5年以上）より前にあるため、これらの手順に基づく実装は、完全に標準に準拠した実装とは異なります。これらの違いはドキュメントで指摘されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc6037.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6037で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
1.2. Scaling Multicast State Information in the Network Core ....3
1.3. Overview ...................................................4
2. Multicast VRFs ..................................................6
3. Multicast Domains ...............................................7
3.1. Model of Operation .........................................7
4. Multicast Tunnels ...............................................7
4.1. Ingress PEs ................................................8
4.2. Egress PEs .................................................8
4.3. Tunnel Destination Address(es) .............................8
4.4. Auto-Discovery .............................................8
4.4.1. MDT-SAFI ...........................................10
4.5. Which PIM Variant to Use ..................................10
4.6. Inter-AS MDT Construction .................................11
4.6.1. The PIM MVPN Join Attribute ........................11
4.6.1.1. Definition ................................11
4.6.1.2. Usage .....................................12
4.7. Encapsulation in GRE ......................................13
4.8. MTU .......................................................14
4.9. TTL .......................................................14
4.10. Differentiated Services ..................................14
4.11. Avoiding Conflict with Internet Multicast ................14
5. The PIM C-Instance and the MT ..................................15
5.1. PIM C-Instance Control Packets ............................15
5.2. PIM C-Instance RPF Determination ..........................15
5.2.1. Connector Attribute ................................16
6. Data MDT: Optimizing Flooding ..................................17
6.1. Limitation of Multicast Domain ............................17
6.2. Signaling Data MDTs .......................................17
6.3. Use of SSM for Data MDTs ..................................19
7. Packet Formats and Constants ...................................20
7.1. MDT TLV ...................................................20
7.2. MDT Join TLV for IPv4 Streams .............................20
7.3. MDT Join TLV for IPv6 Streams .............................21
7.4. Multiple MDT Join TLVs per Datagram .......................22
7.5. Constants .................................................22
8. IANA Considerations ............................................23
9. Security Considerations ........................................23
10. Acknowledgments ...............................................23
11. References ....................................................24
11.1. Normative References .....................................24
11.2. Informative References ...................................24
This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. This document is being made available for the record and as a reference for interoperating with deployed implementations. This document is a technical specification and should not be used to infer the current or future plans of Cisco Systems.
このドキュメントでは、Cisco Systemsによって設計および展開されたMVPN（BGP/MPLS IP VPNSのマルチキャスト）ソリューションについて説明します。このドキュメントは、展開された実装との相互運用のリファレンスとして、記録のために利用可能になっています。このドキュメントは技術的な仕様であり、Cisco Systemsの現在または将来の計画を推測するために使用しないでください。
The procedures specified in this document are largely a subset of the generalized MVPN framework defined in [MVPN]. However, as this document specifies an implementation that precedes the standardization of [MVPN] by several years, it does differ in a few respects from a fully standards-compliant implementation. These differences are pointed out where they occur.
このドキュメントで指定された手順は、主に[MVPN]で定義された一般化されたMVPNフレームワークのサブセットです。ただし、このドキュメントは数年ごとに[MVPN]の標準化に先行する実装を指定しているため、完全に標準に準拠した実装とはいくつかの点で異なります。これらの違いは、それらが発生する場所を指摘しています。
The base specification for BGP/MPLS IP VPNs [RFC4364] does not provide a way for IP multicast data or control traffic to travel from one VPN site to another. This document extends that specification by specifying the necessary protocols and procedures for support of IP multicast.
BGP/MPLS IP VPNS [RFC4364]のベース仕様は、IPマルチキャストデータまたは制御トラフィックがあるVPNサイトから別のサイトへの移動の方法を提供しません。このドキュメントは、IPマルチキャストをサポートするために必要なプロトコルと手順を指定することにより、その仕様を拡張します。
This specification presupposes that:
この仕様はそれを前提としています：
1. Protocol Independent Multicast (PIM) [PIM-SM], running over either IPv4 or IPv6, is the multicast routing protocol used within the VPN,
1. Protocol Independent Multicast（PIM）[PIM-SM]は、IPv4またはIPv6のいずれかを介して実行され、VPN内で使用されるマルチキャストルーティングプロトコルです。
2. PIM, running over IPv4, is the multicast routing protocol used within the service-provider (SP) network, and
2. IPv4を介して実行されているPIMは、Service-Provider（SP）ネットワーク内で使用されるマルチキャストルーティングプロトコルです。
3. the SP network supports native IPv4 multicast forwarding.
3. SPネットワークは、ネイティブIPv4マルチキャスト転送をサポートしています。
Familiarity with the terminology and procedures of [RFC4364] is presupposed. Familiarity with [PIM-SM] is also presupposed.
[RFC4364]の用語と手順に精通しています。[PIM-SM]に精通していることも前提です。
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]に記載されているように解釈される。
The BGP/MPLS IP VPN service of [RFC4364] provides a VPN with "optimal" unicast routing through the SP backbone, in that a packet follows the "shortest path" across the backbone, as determined by the backbone's own routing algorithm. This optimal routing is provided without requiring the "P routers" (routers in the provider backbone, other than the "provider edge" or "PE" routers) to maintain any routing information that is specific to a VPN; indeed, the P routers do not maintain any per-VPN state at all.
[RFC4364]のBGP/MPLS IP VPNサービスは、バックボーン自身のルーティングアルゴリズムによって決定されるように、パケットがバックボーンを横切る「最短パス」に従うという点で、SPバックボーンを介して「最適な」ユニキャストルーティングを備えたVPNを提供します。この最適なルーティングは、VPNに固有のルーティング情報を維持するために、「Pルーター」（プロバイダーエッジ」または「PE」ルーター以外のプロバイダーバックボーンのルーター）を必要とせずに提供されます。実際、PルーターはVPNごとの状態をまったく維持していません。
Unfortunately, optimal multicast routing cannot be provided without requiring the P routers to maintain some VPN-specific state information. Optimal multicast routing would require that one or more multicast distribution trees be created in the backbone for each multicast group that is in use. If a particular multicast group from within a VPN is using source-based distribution trees, optimal routing requires that there be one distribution tree for each transmitter of that group. If shared trees are being used, one tree for each group is still required. Each such tree requires state in some set of the P routers, with the amount of state being proportional to the number of multicast transmitters. The reason there needs to be at least one distribution tree per multicast group is that each group may have a different set of receivers; multicast routing algorithms generally go to great lengths to ensure that a multicast packet will not be sent to a node that is not on the path to a receiver.
残念ながら、VPN固有の状態情報を維持するためにPルーターを必要とせずに、最適なマルチキャストルーティングを提供することはできません。最適なマルチキャストルーティングでは、使用中のマルチキャストグループごとにバックボーンに1つ以上のマルチキャスト配布ツリーを作成する必要があります。VPN内からの特定のマルチキャストグループがソースベースの配布ツリーを使用している場合、最適なルーティングでは、そのグループの各送信機に1つの分布ツリーがあることが必要です。共有ツリーが使用されている場合、各グループに1つのツリーが必要です。そのような各ツリーは、Pルーターの一部のセットで状態を必要とし、状態の量はマルチキャスト送信機の数に比例します。マルチキャストグループごとに少なくとも1つの分布ツリーが必要な理由は、各グループに異なるレシーバーセットがある可能性があるためです。マルチキャストルーティングアルゴリズムは通常、マルチキャストパケットがレシーバーへのパスにないノードに送信されないようにするために非常に長く進みます。
Given that an SP generally supports many VPNs, where each VPN may have many multicast groups, and each multicast group may have many transmitters, it is not scalable to have one or more distribution trees for each multicast group. The SP has no control whatsoever over the number of multicast groups and transmitters that exist in the VPNs, and it is difficult to place any bound on these numbers.
SPが一般に多くのVPNをサポートしていることを考えると、各VPNには多くのマルチキャストグループがあり、各マルチキャストグループには多くの送信機がある可能性があります。各マルチキャストグループに1つ以上の分布ツリーを持つことはスケーラブルではありません。SPには、VPNに存在するマルチキャストグループと送信機の数を制御できないため、これらの数値にバインドすることは困難です。
In order to have a scalable multicast solution for BGP/MPLS IP VPNs, the amount of state maintained by the P routers needs to be proportional to something that IS under the control of the SP. This specification describes such a solution. In this solution, the amount of state maintained in the P routers is proportional only to the number of VPNs that run over the backbone; the amount of state in the P routers is NOT sensitive to the number of multicast groups or to the number of multicast transmitters within the VPNs. To achieve this scalability, the optimality of the multicast routes is reduced. A PE that is not on the path to any receiver of a particular multicast group may still receive multicast packets for that group, and if so, will have to discard them. The SP does, however, have control over the tradeoff between optimal routing and scalability.
BGP/MPLS IP VPNのスケーラブルなマルチキャストソリューションを持つためには、Pルーターによって維持される状態の量は、SPの制御下にあるものに比例する必要があります。この仕様では、そのような解決策が説明されています。このソリューションでは、Pルーターで維持される状態の量は、バックボーン上で実行されるVPNの数にのみ比例します。Pルーターの状態の量は、マルチキャストグループの数またはVPN内のマルチキャスト送信機の数に敏感ではありません。このスケーラビリティを実現するために、マルチキャストルートの最適性が低下します。特定のマルチキャストグループの受信者へのパスにないPEは、そのグループのマルチキャストパケットを依然として受け取る場合があり、もしそうなら、それらを破棄する必要があります。ただし、SPは、最適なルーティングとスケーラビリティの間のトレードオフを制御しています。
An SP determines whether a particular VPN is multicast-enabled. If it is, it corresponds to a "Multicast Domain". A PE that attaches to a particular multicast-enabled VPN is said to belong to the corresponding Multicast Domain. For each Multicast Domain, there is a default multicast distribution tree ("MDT") through the backbone, connecting ALL of the PEs that belong to that Multicast Domain. A given PE may be in as many Multicast Domains as there are VPNs attached to that PE. However, each Multicast Domain has its own MDT. The MDTs are created by running PIM in the backbone, and in general an MDT also includes P routers on the paths between the PE routers.
SPは、特定のVPNがマルチキャスト対応であるかどうかを判断します。もしそうなら、それは「マルチキャストドメイン」に対応します。特定のマルチキャスト対応VPNに付着するPEは、対応するマルチキャストドメインに属すると言われています。各マルチキャストドメインには、バックボーンを介してデフォルトのマルチキャスト分布ツリー（「MDT」）があり、そのマルチキャストドメインに属するすべてのPEを接続します。与えられたPEは、そのPEに付加されているVPNと同じくらい多くのマルチキャストドメインにある場合があります。ただし、各マルチキャストドメインには独自のMDTがあります。MDTは、バックボーンでPIMを実行することによって作成され、一般にMDTにはPEルーター間のパスにPルーターも含まれます。
In a departure from the usual multicast tree distribution procedures, the Default MDT for a Multicast Domain is constructed automatically as the PEs in the domain come up. Construction of the Default MDT does not depend on the existence of multicast traffic in the domain; it will exist before any such multicast traffic is seen. Default MDTs correspond to the Multidirectional Inclusive P-Multicast Service Interfaces ("MI-PMSIs") of [MVPN].
通常のマルチキャストツリー分布手順から離れると、マルチキャストドメインのデフォルトのMDTは、ドメイン内のPESが表示されると自動的に構築されます。デフォルトのMDTの構築は、ドメイン内のマルチキャストトラフィックの存在に依存しません。このようなマルチキャストトラフィックが見られる前に存在します。デフォルトのMDTは、[MVPN]の多方向包括的P-マルチカストサービスインターフェイス（「Mi-PMSIS」）に対応しています。
In BGP/MPLS IP VPNs, each CE ("Customer Edge", see [RFC4364]) router is a unicast routing adjacency of a PE router, but CE routers at different sites do NOT become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing -- a CE router becomes a PIM adjacency of a PE router, but CE routers at different sites do NOT become PIM adjacencies of each other. Multicast packets from within a VPN are received from a CE router by an ingress PE router. The ingress PE encapsulates the multicast packets and (initially) forwards them along the Default MDT to all the PE routers connected to sites of the given VPN. Every PE router attached to a site of the given VPN thus receives all multicast packets from within that VPN. If a particular PE router is not on the path to any receiver of that multicast group, the PE simply discards that packet.
BGP/MPLS IP VPNでは、各CE（「顧客エッジ」、[RFC4364]を参照）ルーターは、PEルーターのユニキャストルーティング隣接ですが、さまざまなサイトのCEルーターは互いにユニキャストルーティングに隣接していません。この重要な特性は、マルチキャストルーティングのために保持されます。CEルーターはPEルーターのPIM隣接になりますが、さまざまなサイトのCEルーターは互いのPIM隣接になりません。VPN内からのマルチキャストパケットは、侵入PEルーターによってCEルーターから受信されます。Ingress PEは、マルチキャストパケットをカプセル化し、（最初に）デフォルトのMDTに沿って、指定されたVPNのサイトに接続されたすべてのPEルーターに転送します。したがって、指定されたVPNのサイトに接続されたすべてのPEルーターは、そのVPN内からすべてのマルチキャストパケットを受信します。特定のPEルーターがそのマルチキャストグループの任意のレシーバーへのパス上にない場合、PEは単にそのパケットを破棄します。
If a large amount of traffic is being sent to a particular multicast group, but that group does not have receivers at all the VPN sites, it can be wasteful to forward that group's traffic along the Default MDT. Therefore, we also specify a method for establishing individual MDTs for specific multicast groups. We call these "Data MDTs". A Data MDT delivers VPN data traffic for a particular multicast group only to those PE routers that are on the path to receivers of that multicast group. Using a Data MDT has the benefit of reducing the amount of multicast traffic on the backbone, as well as reducing the load on some of the PEs; it has the disadvantage of increasing the amount of state that must be maintained by the P routers. The SP has complete control over this tradeoff. Data MDTs correspond to the Selective PMSI ("S-PMSIs") of [MVPN].
大量のトラフィックが特定のマルチキャストグループに送信されているが、そのグループにすべてのVPNサイトにレシーバーがない場合、デフォルトのMDTに沿ってそのグループのトラフィックを転送することは無駄になる可能性があります。したがって、特定のマルチキャストグループに個々のMDTを確立する方法も指定します。これらを「データMDT」と呼びます。データMDTは、そのマルチキャストグループの受信機へのパス上にあるPEルーターにのみ、特定のマルチキャストグループにVPNデータトラフィックを提供します。データを使用すると、MDTはバックボーン上のマルチキャストトラフィックの量を減らし、一部のPEの負荷を削減する利点があります。Pルーターによって維持されなければならない状態の量を増やすという欠点があります。SPは、このトレードオフを完全に制御しています。データMDTは、[MVPN]の選択的PMSI（ "S-PMSIS"）に対応しています。
This solution requires the SP to deploy appropriate protocols and procedures, but is transparent to the SP's customers. An enterprise that uses PIM-based multicasting in its network can migrate from a private network to a BGP/MPLS IP VPN service, while continuing to use whatever multicast router configurations it was previously using; no changes need be made to CE routers or to other routers at customer sites. For instance, any dynamic Rendezvous Point ("RP")-discovery procedures that are already in use may be left in place.
このソリューションでは、SPが適切なプロトコルと手順を展開する必要がありますが、SPの顧客には透明です。ネットワークでPIMベースのマルチキャストを使用するエンタープライズは、プライベートネットワークからBGP/MPLS IP VPNサービスに移行でき、以前に使用していたマルチキャストルーター構成を継続し続けます。CEルーターや顧客サイトの他のルーターに変更を加える必要はありません。たとえば、すでに使用されている動的なランデブーポイント（ "RP"） - 発見手順は、所定の位置に残されている場合があります。
The notion of a VPN Routing and Forwarding table ("VRF"), defined in [RFC4364], is extended to include multicast routing entries as well as unicast routing entries.
[RFC4364]で定義されているVPNルーティングおよび転送テーブル（「VRF」）の概念は、マルチキャストルーティングエントリとユニキャストルーティングエントリを含むように拡張されています。
Each VRF has its own multicast routing table. When a multicast data or control packet is received from a particular CE device, multicast routing is done in the associated VRF.
各VRFには、独自のマルチキャストルーティングテーブルがあります。特定のCEデバイスからマルチキャストデータまたはコントロールパケットが受信されると、関連するVRFでマルチキャストルーティングが行われます。
Each PE router runs a number of instances of PIM - Sparse Mode (PIM-SM), as many as one per VRF. In each instance of PIM-SM, the PE maintains a PIM adjacency with each of the PIM-capable CE routers associated with that VRF. The multicast routing table created by each instance is specific to the corresponding VRF. We will refer to these PIM instances as "VPN-specific PIM instances", or "PIM C-instances".
各PEルーターは、VRFごとに1つも、PIM -SPARSEモード（PIM -SM）のインスタンスをいくつか実行します。PIM-SMの各インスタンスでは、PEはそのVRFに関連付けられた各PIMで利用可能なCEルーターのPIM隣接を維持しています。各インスタンスによって作成されたマルチキャストルーティングテーブルは、対応するVRFに固有です。これらのPIMインスタンスを「VPN固有のPIMインスタンス」または「PIM Cインスタンス」と呼びます。
Each PE router also runs a "provider-wide" instance of PIM-SM (a "PIM P-instance"), in which it has a PIM adjacency with each of its IGP neighbors (i.e., with P routers), but NOT with any CE routers, and not with other PE routers (unless they happen to be adjacent in the SP's network). The P routers also run the P-instance of PIM, but do NOT run a C-instance.
各PEルーターは、PIM-SM（「PIM P-instance」）の「プロバイダー全体の」インスタンスを実行します。このインスタンスでは、各IGPネイバー（つまり、Pルーターを使用）のPIM隣接がありますが、他のPEルーターではなく、CEルーターはすべて（SPのネットワークで隣接していない限り）。PルーターはPIMのpインスタンスも実行しますが、Cインスタンスを実行しません。
In order to help clarify when we are speaking of the PIM P-instance and when we are speaking of a PIM C-instance, we will also apply the prefixes "P-" and "C-" respectively to control messages, addresses, etc. Thus, a P-Join would be a PIM Join that is processed by the PIM P-instance, and a C-Join would be a PIM Join that is processed by a C-instance. A P-group address would be a group address in the SP's address space, and a C-group address would be a group address in a VPN's address space.
PIM Pインスタンスについて話しているときとPIM Cインスタンスについて話しているときに明確にするために、それぞれのプレフィックス「P-」と「C-」もそれぞれ適用して、メッセージ、アドレスなどを制御します。したがって、P結合は、PIM Pインスタンスによって処理されるPIM結合であり、C-JOINはCインスタンスによって処理されるPIM結合です。Pグループアドレスは、SPのアドレス空間のグループアドレスであり、CグループアドレスはVPNのアドレススペースのグループアドレスです。
A Multicast Domain ("MD") is essentially a set of VRFs associated with interfaces that can send multicast traffic to each other. From the standpoint of a PIM C-instance, a Multicast Domain is equivalent to a multi-access interface. The PE routers in a given MD become PIM adjacencies of each other in the PIM C-instance.
マルチキャストドメイン（「MD」）は、基本的に、マルチキャストトラフィックを相互に送信できるインターフェイスに関連付けられたVRFのセットです。PIM Cインスタンスの観点から、マルチキャストドメインはマルチアクセスインターフェイスと同等です。特定のMDのPEルーターは、PIM Cインスタンスの互いにPIM隣接するものになります。
Each multicast VRF is assigned to one MD. Each MD is configured with a distinct, multicast P-group address, called the "Default MDT group address". This address is used to build the Default MDT for the MD.
各マルチキャストVRFは1つのMDに割り当てられます。各MDは、「デフォルトのMDTグループアドレス」と呼ばれる個別のマルチキャストPグループアドレスで構成されています。このアドレスは、MDのデフォルトのMDTを構築するために使用されます。
When a PE router needs to send PIM C-instance control traffic to the other PE routers in the MD, it encapsulates the control traffic, with its own IPv4 address as the source IP address and the Default MDT group address as the destination IP address. Note that the Default MDT is part of the PIM P-instance, whereas the PEs that communicate over the Default MDT are PIM adjacencies in a C-instance. Within the C-instance, the Default MDT appears to be a multi-access network to which all the PEs are attached. This is discussed in more detail in Section 4.
PEルーターがMDの他のPEルーターにPIM Cインスタンス制御トラフィックを送信する必要がある場合、ソースIPアドレスとして独自のIPv4アドレスとデフォルトのMDTグループアドレスを宛先IPアドレスとしてコントロールトラフィックをカプセル化します。デフォルトのMDTはPIM Pインスタンスの一部であり、デフォルトのMDTを介して通信するPESはCインスタンスのPIM隣接であることに注意してください。Cインスタンス内では、デフォルトのMDTは、すべてのPEが接続されているマルチアクセスネットワークのように見えます。これについては、セクション4で詳しく説明します。
The Default MDT does not only carry the PIM control traffic of the MD's PIM C-instance. It also, by default, carries the multicast data traffic of the C-instance. In some cases, though, multicast data traffic in a particular MD will be sent on a Data MDT rather than on the Default MDT. The use of Data MDTs is described in Section 6.
デフォルトのMDTは、MDのPIM CインスタンスのPIM制御トラフィックを運ぶだけではありません。また、デフォルトでは、Cインスタンスのマルチキャストデータトラフィックが搭載されています。ただし、場合によっては、特定のMDのマルチキャストデータトラフィックは、デフォルトのMDTではなくデータMDTに送信されます。データMDTの使用については、セクション6で説明します。
Note that, if an MDT (Default or Data) is set up using the ASM ("Any-Source Multicast") Service Model, the MDT (Default or Data) must have a P-group address that is "globally unique" (more precisely, unique over the set of SP networks carrying the multicast traffic of the corresponding MD). If the MDT is set up using the SSM ("Source-Specific Multicast") model, the P-group address of an MDT only needs to be unique relative to the source of the MDT (however, see Section 4.4). Nevertheless, some implementations require the same SSM group address to be assigned to all the PEs. Interoperability with those implementations requires conformance to this restriction.
MDT（デフォルトまたはデータ）がASM（ "Any-Source Multicast"）サービスモデルを使用してセットアップされている場合、MDT（デフォルトまたはデータ）には「グローバルに一意」のPグループアドレスが必要であることに注意してください（詳細」（詳細」正確には、対応するMDのマルチキャストトラフィックを運ぶSPネットワークのセットで一意です）。MDTがSSM（「ソース固有のマルチキャスト」）モデルを使用してセットアップされている場合、MDTのPグループアドレスは、MDTのソースに対して一意である必要があります（ただし、セクション4.4を参照）。それにもかかわらず、一部の実装では、同じSSMグループアドレスをすべてのPEに割り当てる必要があります。これらの実装との相互運用性には、この制限に適合する必要があります。
An MD can be thought of as a set of PE routers connected by a multicast tunnel ("MT"). From the perspective of a VPN-specific PIM instance, an MT is a single multi-access interface. In the SP network, a single MT is realized as a Default MDT combined with zero or more Data MDTs.
MDは、マルチキャストトンネル（「MT」）で接続された一連のPEルーターと考えることができます。VPN固有のPIMインスタンスの観点から見ると、MTは単一のマルチアクセスインターフェイスです。SPネットワークでは、ゼロ以上のデータMDTと組み合わせたデフォルトのMDTとして単一のMTが実現されます。
An ingress PE is a PE router that is either directly connected to the multicast sender in the VPN, or via a CE router. When the multicast sender starts transmitting, and if there are receivers (or a PIM RP) behind other PE routers in the common MD, the ingress PE becomes the transmitter of either the Default MDT group or a Data MDT group in the SP network.
Ingress PEは、VPNのマルチキャスト送信者に直接接続されているか、CEルーターを介してPEルーターです。マルチキャスト送信者が送信を開始し、共通MDの他のPEルーターの背後に受信機（またはPIM RP）がある場合、Ingress PEは、SPネットワークのデフォルトMDTグループまたはデータMDTグループの送信機になります。
A PE router with a VRF configured in an MD becomes a receiver of the Default MDT group for that MD. A PE router may also join a Data MDT group if it has a VPN-specific PIM instance in which it is forwarding to one of its attached sites traffic for a particular C-group, and that particular C-group has been associated with that particular Data MDT. When a PE router joins any P-group used for encapsulating VPN multicast traffic, the PE router becomes one of the endpoints of the corresponding MT.
MDで構成されたVRFを備えたPEルーターは、そのMDのデフォルトMDTグループの受信機になります。PEルーターは、特定のCグループの添付サイトトラフィックの1つに転送され、その特定のCグループがその特定のC-Groupに関連付けられている場合、VPN固有のPIMインスタンスがある場合、データMDTグループに参加することもできます。データMDT。PEルーターがVPNマルチキャストトラフィックのカプセル化に使用されるPグループに結合すると、PEルーターは対応するMTのエンドポイントの1つになります。
When a packet is received from an MT, the receiving PE derives the MD from the destination address, which is a P-group address, of the received packet. The packet is then passed to the corresponding multicast VRF and VPN-specific PIM instance for further processing.
PACKETがMTから受信されると、受信PEは、受信したパケットのPグループアドレスである宛先アドレスからMDを導き出します。次に、パケットを対応するマルチキャストVRFおよびVPN固有のPIMインスタンスに渡され、さらに処理します。
An MT is an IP tunnel for which the destination address is a P-group address. However, an MT is not limited to using only one P-group address for encapsulation. Based on the payload VPN multicast traffic, it can choose to use the Default MDT group address, or one of the Data MDT group addresses (as described in Section 6 of this document), allowing the MT to reach a different set of PE routers in the common MD.
MTは、宛先アドレスがPグループアドレスであるIPトンネルです。ただし、MTは、カプセル化に1つのPグループアドレスのみを使用することに限定されません。ペイロードVPNマルチキャストトラフィックに基づいて、デフォルトのMDTグループアドレス、またはデータMDTグループアドレスのいずれかを使用することを選択できます（このドキュメントのセクション6で説明されているように）。一般的なMD。
Any of the variants of PIM may be used to set up the Default MDT: PIM-SM, Bidirectional PIM [BIDIR], or PIM-Source-Specific Multicast (PIM-SSM) [SSM]. Except in the case of PIM-SSM, the PEs need only know the proper P-group address in order to begin setting up the Default MDTs. The PEs will then discover each others' addresses by virtue of receiving PIM control traffic, e.g., PIM Hellos, sourced (and encapsulated) by each other.
PIMのバリアントのいずれかを使用して、デフォルトのMDT：PIM-SM、双方向PIM [Bidir]、またはPIM-Source固有のマルチキャスト（PIM-SSM）[SSM]を設定することができます。PIM-SSMの場合を除き、PESは、デフォルトのMDTのセットアップを開始するために、適切なPグループアドレスを知る必要があります。PESは、PIMコントロールトラフィックを受け取ることにより、お互いの住所を発見します。
However, in the case of PIM-SSM, the necessary MDTs for an MD cannot be set up until each PE in the MD knows the source address of each of the other PEs in that same MD. This information needs to be auto-discovered.
ただし、PIM-SSMの場合、MDの各PEが同じMDの他の各PEのソースアドレスを知るまで、MDに必要なMDTを設定することはできません。この情報は自動発見する必要があります。
A new BGP address family, the MDT-Subsequent Address Family Identifier ("MDT-SAFI"), is defined. The Network Layer Reachability Information (NLRI) for this address family consists of a Route Distinguisher (RD), an IPv4 unicast address, and a multicast group address. A given PE router in a given MD constructs an NLRI in this family from:
新しいBGPアドレスファミリー、MDTサブ後のアドレスファミリー識別子（「MDT-Safi」）が定義されています。このアドレスファミリのネットワークレイヤーリーチ可能性情報（NLRI）は、ルート違い（RD）、IPv4ユニキャストアドレス、マルチキャストグループアドレスで構成されています。特定のMDの与えられたPEルーターは、次のファミリにNLRIを構築します。
- Its own IPv4 address. If it has several, it uses the one that it will be placing in the IP Source Address field of multicast packets that it will be sending over the MDT.
- 独自のIPv4アドレス。いくつかの場合、MDTを介して送信するマルチキャストパケットのIPソースアドレスフィールドに配置されるものを使用します。
- An RD that has been assigned to the MD.
- MDに割り当てられたRD。
- The P-group address, an IPv4 multicast address that is to be used as the IP Destination Address field of multicast packets that will be sent over the MDT.
- P-Groupアドレス、MDTを介して送信されるマルチキャストパケットのIP宛先アドレスフィールドとして使用されるIPv4マルチキャストアドレス。
When a PE distributes this NLRI via BGP, it may include a Route Target (RT) Extended Communities attribute. This RT must be an "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP distribution procedures used by [RFC4364] will then ensure that each PE learns the MDT-SAFI "address" of each of the other PEs in the MD, and that the learned MDT-SAFI addresses get associated with the right VRFs.
PEがBGPを介してこのNLRIを配布すると、ルートターゲット（RT）拡張コミュニティ属性が含まれる場合があります。このRTは、MDの各VRFの「インポートRT」[RFC4364]でなければなりません。[RFC4364]で使用される通常のBGP分布手順により、各PEがMDの他の各PEのMDT-SAFIの「アドレス」を学習し、学習したMDT-SAFIアドレスが適切なVRFに関連付けられていることを保証します。
If a PE receives an MDT-SAFI NLRI that does not have an RT attribute, the P-group address from the NLRI has to be used to associate the NLRI with a particular VRF. In this case, each Multicast Domain must be associated with a unique P-address, even if PIM-SSM is used. However, finding a unique P-address for a multi-provider multicast group may be difficult.
PEがRT属性を持たないMDT-SAFI NLRIを受信する場合、NLRIのPグループアドレスを使用してNLRIを特定のVRFに関連付ける必要があります。この場合、PIM-SSMが使用されていても、各マルチキャストドメインは一意のPアドレスに関連付けられている必要があります。ただし、マルチプロバイダーマルチキャストグループのユニークなPアドレスを見つけるのは難しい場合があります。
In order to facilitate the deployment of multi-provider Multicast Domains, this specification REQUIRES the use of the MDT-SAFI NLRI (even if PIM-SSM is not used to set up the Default MDT). This specification also REQUIRES that an implementation be capable of using PIM-SSM to set up the Default MDT.
マルチプロバイダーマルチキャストドメインの展開を促進するために、この仕様にはMDT-Safi NLRIの使用が必要です（PIM-SSMがデフォルトのMDTのセットアップに使用されていない場合でも）。また、この仕様では、実装を使用してデフォルトのMDTを設定するために実装を可能にする必要があります。
In [MVPN], the MDT-SAFI is replaced by the Intra-Autonomous-System Inclusive-PMSI auto-discovery ("Intra-AS I-PMSI A-D") route. The latter is a generalized version of the MDT-SAFI, which allows the "Default MDTs" and "Data MDTs" to be implemented as MPLS P2MP LSPs ("Point-to-Multipoint Label Switched Paths") or MP2MP LSPs ("Multipoint-to-Multipoint Label Switched Paths"), as well as by PIM-created multicast distribution trees. In the latter case, the Intra-AS A-D routes carry the same information that the MDT-SAFI does, though with a different encoding.
[MVPN]では、MDT-SAFIは、自律型システム内の包括的PMSIオートディスコービリ（「INTRA-AS I-PMSI A-D」）ルートに置き換えられます。後者は、MDT-SAFIの一般化バージョンであり、「デフォルトMDT」および「データMDT」をMPLS P2MP LSP（「ポイントツーマルチポイントラベルスイッチングパス」）またはMP2MP LSP（ "To-Multipointラベルの切り替えパス "）、およびPIM作成マルチキャスト分布ツリーによる。後者の場合、AS Intra-A-Dルートは、MDT-Safiと同じ情報と同じ情報を掲載していますが、異なるエンコードがあります。
The Intra-AS A-D routes also carry Route Targets, and so may be distributed in the same manner as unicast routes, including being distributed inter-AS. (Despite their name, the inter-AS distribution of Intra-AS I-PMSI A-D routes is sometimes necessary in [MVPN].)
AS Intra-Dルートにはルートターゲットも搭載されているため、AS間分布を含むユニキャストルートと同じ方法で配布される場合があります。（その名前にもかかわらず、[MVPN]では、IPMSI A-DルートとしてのIntra-Intraの分布が必要になることがあります。）
The encoding of the MDT-SAFI is specified in the following subsection.
MDT-SAFIのエンコードは、次のサブセクションで指定されています。
BGP messages in which AFI=1 and SAFI=66 are "MDT-SAFI" messages.
AFI = 1およびSAFI = 66が「MDT-Safi」メッセージであるBGPメッセージ。
The NLRI format is the 8-byte-RD:IPv4-address followed by the MDT group address, i.e., the MP_REACH attribute for this SAFI will contain one or more tuples of the following form:
NLRI形式は8バイトRD：IPv4-Addressに続くMDTグループアドレスが続きます。つまり、このSAFIのMP_Reach属性には、次の形式の1つ以上のタプルが含まれます。
+-------------------------------+
| |
| RD:IPv4-address (12 octets) |
| |
+-------------------------------+
| Group Address (4 octets) |
+-------------------------------+
The IPv4 address identifies the PE that originated this route, and the RD identifies a VRF in that PE. The group address MUST be an IPv4 multicast group address and is used to build the P-tunnels. All PEs attached to a given MVPN MUST specify the same group address, even if the group is an SSM group. MDT-SAFI routes do not carry RTs, and the group address is used to associate a received MDT-SAFI route with a VRF.
IPv4アドレスは、このルートを発信したPEを識別し、RDはそのPEのVRFを識別します。グループアドレスは、IPv4マルチキャストグループアドレスである必要があり、Pタンネルの構築に使用されます。特定のMVPNに接続されたすべてのPEは、グループがSSMグループであっても、同じグループアドレスを指定する必要があります。MDT-SAFIルートはRTSを運ばず、グループアドレスは、受信したMDT-SAFIルートをVRFに関連付けるために使用されます。
To minimize the amount of multicast routing state maintained by the P routers, the Default MDTs should be realized as shared trees, such as PIM bidirectional trees. However, the operational procedures for assigning P-group addresses may be greatly simplified, especially in the case of multi-provider MDs, if PIM-SSM is used.
Pルーターによって維持されるマルチキャストルーティング状態の量を最小化するには、デフォルトのMDTをPIM双方向木などの共有ツリーとして実現する必要があります。ただし、P-Groupアドレスを割り当てるための運用手順は、特にPIM-SSMが使用されている場合、マルチプロバイダーMDSの場合に大幅に簡素化される場合があります。
Data MDTs are best realized as source trees, constructed via PIM-SSM.
データMDTは、PIM-SSMを介して構築されたソースツリーとして最もよく実現されます。
Standard PIM techniques for the construction of source trees presuppose that every router has a route to the source of the tree. However, if the source of the tree is in a different AS than a particular P router, it is possible that the P router will not have a route to the source. For example, the remote AS may be using BGP to distribute a route to the source, but a particular P router may be part of a "BGP-free core", in which the P routers are not aware of BGP-distributed routes.
ソースツリーを構築するための標準的なPIM技術は、すべてのルーターにツリーのソースへのルートがあることを前提としています。ただし、ツリーのソースが特定のPルーターと同様に異なる場合、Pルーターにソースへのルートがない可能性があります。たとえば、BGPを使用してソースへのルートを配布しているリモートですが、特定のPルーターは「BGPフリーコア」の一部である可能性があります。この場合、PルーターはBGP分散型ルートを認識していません。
What is needed in this case is a way for a PE to tell PIM to construct the tree through a particular BGP speaker, the "BGP Next Hop" for the tree source. This can be accomplished with a PIM extension.
この場合に必要なのは、PEがPIMに特定のBGPスピーカーを介してツリーを構築するよう指示する方法であり、ツリーソースの「BGP Next Hop」です。これは、PIM拡張機能で実現できます。
If the PE has selected the source of the tree from the MDT SAFI address family, then it may be desirable to build the tree along the route to the MDT SAFI address, rather than along the route to the corresponding IPv4 address. This enables the inter-AS portion of the tree to follow a path that is specifically chosen for multicast (i.e., it allows the inter-AS multicast topology to be "non-congruent" to the inter-AS unicast topology). This too requires a PIM extension.
PEがMDT SAFIアドレスファミリからツリーのソースを選択した場合、対応するIPv4アドレスへのルートに沿ってではなく、MDT SAFIアドレスへのルートに沿ってツリーを構築することが望ましい場合があります。これにより、ツリーの部分である部分がマルチキャストに特別に選択されるパスに従うことができます（つまり、マルチキャスト間トポロジーは、ユニキャスト間トポロジー間で「非次第」になることができます）。これにもPIM拡張機能が必要です。
The necessary PIM extension is the PIM MVPN Join Attribute described in the following subsection.
必要なPIM拡張は、以下のサブセクションで説明されているPIM MVPN結合属性です。
In [PIM-ATTRIB], the notion of a "Join Attribute" is defined, and a format for included Join Attributes in PIM Join/Prune messages is specified. We now define a new Join Attribute, which we call the "MVPN Join Attribute".
[Pim-Attrib]では、「結合属性」の概念が定義されており、PIM Join/Pruneメッセージに含まれる結合属性の形式が指定されています。次に、「MVPN Join Attribute」と呼ばれる新しいJoin属性を定義します。
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| Type | Length | Proxy IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
The 6-bit Type field of the MVPN Join Attribute is set to 1.
MVPN JOIN属性の6ビット型フィールドは1に設定されています。
The F-bit is set to 0, indicating that the attribute is non-transitive.
Fビットは0に設定されており、属性が非転写であることを示します。
Rules for setting the E-bit are given in [PIM-ATTRIB].
eビットを設定するためのルールは、[pim-attrib]に記載されています。
Two information fields are carried in the MVPN Join Attribute:
MVPN結合属性に2つの情報フィールドが携帯されています。
- Proxy IP address: The IP address of the node towards which the PIM Join/Prune message is to be forwarded. This will either be an IPv4 or an IPv6 address, depending on whether the PIM Join/Prune message itself is IPv4 or IPv6.
- プロキシIPアドレス：PIMが結合/プルーンメッセージを転送するノードのIPアドレスを転送します。これは、PIM結合/プルーンメッセージ自体がIPv4またはIPv6であるかどうかに応じて、IPv4またはIPv6アドレスのいずれかです。
- RD: An eight-byte RD. This immediately follows the proxy IP address.
- RD：8バイトRD。これは、プロキシIPアドレスのすぐ後になります。
The PIM message also carries the address of the upstream PE.
PIMメッセージには、上流のPEのアドレスも搭載されています。
In the case of an intra-AS MVPN, the proxy and the upstream PE are the same. In the case of an inter-AS MVPN, the proxy will be the AS Border Router (ASBR) that is the exit point from the local AS on the path to the upstream PE.
MVPN内の場合、プロキシと上流のPEは同じです。MVPN間の場合、プロキシは、上流のPEへのパスのようにローカルからの出口ポイントであるAS Border Router（ASBR）になります。
When a PE router creates a PIM Join/Prune message in order to set up an inter-AS Default MDT, it does so as a result of having received a particular MDT-SAFI route. It includes an MVPN Join Attribute whose fields are set as follows:
PEルーターがPIM結合/プルーンメッセージを作成してデフォルトのMDTを設定する場合、特定のMDT-SAFIルートを受け取った結果としてそうします。これには、フィールドが次のように設定されているMVPN結合属性が含まれます。
- If the upstream PE is in the same AS as the local PE, then the Proxy field contains the address of the upstream PE. Otherwise, it contains the address of the BGP Next Hop on the route to the upstream PE.
- 上流のPEがローカルPEと同じである場合、プロキシフィールドには上流のPEのアドレスが含まれます。それ以外の場合は、上流のPEへのルートにBGPの次のホップのアドレスが含まれています。
- The RD field contains the RD from the NLRI of the MDT-SAFI route.
- RDフィールドには、MDT-SafiルートのNLRIからのRDが含まれています。
- The Upstream PE field contains the address of the PE that originated the MDT-SAFI route (obtained from the NLRI of that route).
- 上流のPEフィールドには、MDT-Safiルート（そのルートのNLRIから取得）を発信したPEのアドレスが含まれています。
When a PIM router processes a PIM Join/Prune message with an MVPN Join Attribute, it first checks to see if the Proxy field contains one of its own addresses.
PIMルーターがMVPN Join属性を使用してPIM結合/プルーンメッセージを処理する場合、最初にプロキシフィールドに独自のアドレスの1つが含まれているかどうかを確認します。
If not, the router uses the proxy IP address in order to determine the Reverse Path Forwarding (RPF) interface and neighbor. The MVPN Join Attribute MUST be passed upstream, unchanged.
そうでない場合、ルーターはプロキシIPアドレスを使用して、逆パス転送（RPF）インターフェイスと隣接を決定します。MVPN結合属性は、変更されていない上流で渡す必要があります。
If the proxy address is one of the router's own IP addresses, then the router looks in its BGP routing table for an MDT-SAFI route whose NLRI consists of the upstream PE address prepended with the RD from the Join Attribute. If there is no match, the PIM message is discarded. If there is a match, the IP address from the BGP Next Hop field of the matching route is used in order to determine the RPF interface and neighbor. When the PIM Join/Prune is forwarded upstream, the Proxy field is replaced with the address of the BGP Next Hop, and the RD and Upstream PE fields are left unchanged.
プロキシアドレスがルーター自身のIPアドレスの1つである場合、ルーターは、NLRIがJoin属性からRDで準備された上流のPEアドレスで構成されているMDT-SAFIルートのBGPルーティングテーブルを調べます。一致しない場合、PIMメッセージは破棄されます。一致がある場合、RPFインターフェイスと隣接を決定するために、一致ルートのBGP次のホップフィールドからのIPアドレスが使用されます。PIM結合/プルーンが上流に転送されると、プロキシフィールドはBGP Next Hopのアドレスに置き換えられ、RDおよび上流のPEフィールドは変更されません。
Generic Routing Encapsulation (GRE) [GRE1701] is used when sending multicast traffic through an MDT. The following diagram shows the progression of the packet as it enters and leaves the service-provider network.
ジェネリックルーティングカプセル化（GRE）[GRE1701]は、MDTを介してマルチキャストトラフィックを送信する際に使用されます。次の図は、パケットが入力してサービスプロバイダーネットワークを去るときのパケットの進行を示しています。
Packets received Packets in transit Packets forwarded at ingress PE in the service- by egress PEs provider network
Packetsは、Engress PESプロバイダーネットワークによってサービスのIngress PEで転送されたトランジットパケットでパケットを受け取りました
+---------------+
| P-IP Header |
+---------------+
| GRE |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The IPv4 Protocol Number field in the P-IP Header MUST be set to 47. The Protocol Type field of the GRE Header MUST be set to 0x0800 if the C-IP header is an IPv4 header; it MUST be set to 0x86dd if the C-IP header is an IPv6 header.
P-IPヘッダーのIPv4プロトコル番号フィールドは47に設定する必要があります。C-IPヘッダーがIPv4ヘッダーである場合、GREヘッダーのプロトコルタイプフィールドは0x0800に設定する必要があります。C-IPヘッダーがIPv6ヘッダーである場合、0x86DDに設定する必要があります。
[GRE2784] specifies an optional GRE checksum, and [GRE2890] specifies optional GRE Key and Sequence Number fields.
[GRE2784]はオプションのGREチェックサムを指定し、[GRE2890]はオプションのGREキーとシーケンス番号フィールドを指定します。
The GRE Key field is not needed because the P-group address in the delivery IP header already identifies the MD, and thus associates the VRF context, for the payload packet to be further processed.
配信IPヘッダーのPグループアドレスはすでにMDを識別しているため、ペイロードパケットがさらに処理されるためにVRFコンテキストを関連付けているため、GREキーフィールドは必要ありません。
The GRE Sequence Number field is also not needed because the transport layer services for the original application will be provided by the C-IP Header.
元のアプリケーションの輸送層サービスがC-IPヘッダーによって提供されるため、GREシーケンス番号フィールドも必要ありません。
The use of the GRE Checksum field MUST follow [GRE2784].
GREチェックサムフィールドの使用は、[GRE2784]に従う必要があります。
To facilitate high-speed implementation, this document recommends that the ingress PE routers encapsulate VPN packets without setting the Checksum, Key, or Sequence Number field.
高速実装を容易にするために、このドキュメントでは、チェックサム、キー、またはシーケンス番号フィールドを設定せずに、イングレスPEルーターがVPNパケットをカプセル化することを推奨しています。
Because multicast group addresses are used as tunnel destination addresses, existing Path MTU discovery mechanisms cannot be used. This requires that:
マルチキャストグループアドレスはトンネルの宛先アドレスとして使用されるため、既存のパスMTU発見メカニズムは使用できません。これには次のことが必要です。
1. The ingress PE router (one that does the encapsulation) MUST NOT set the DF ("Don't Fragment") bit in the outer header, and
1. Ingress PEルーター（カプセル化を行うもの）は、外側ヘッダーにdf（ "fragment" bit）ビットを設定してはなりません。
2. If the "DF" bit is cleared in the IP header of the C-Packet, fragment the C-Packet before encapsulation if appropriate. This is very important in practice due to the fact that the performance of the reassembly function is significantly lower than that of decapsulating and forwarding packets on today's router implementations.
2. 「DF」ビットがCパケットのIPヘッダーでクリアされている場合、必要に応じてカプセル化前にCパケットを断片化します。これは、再組み立て関数のパフォーマンスが今日のルーターの実装でパケットを脱カプセル化および転送するものよりも大幅に低いため、実際には非常に重要です。
The ingress PE should not copy the Time to Live (TTL) field from the payload IP header received from a CE router to the delivery IP header. Setting the TTL of the delivery IP header is determined by the local policy of the ingress PE router.
Ingress PEは、CEルーターから受信したペイロードIPヘッダーからのライブ（TTL）フィールドを配信IPヘッダーにコピーしてはなりません。配信IPヘッダーのTTLの設定は、Ingress PEルーターのローカルポリシーによって決定されます。
By default, setting of the DS ("Differentiated Services") field in the delivery IP header should follow the guidelines outlined in [DIFF2983]. An SP may also choose to deploy any of the additional mechanisms the PE routers support.
デフォルトでは、配信IPヘッダーのDS（「差別化されたサービス」）フィールドの設定は、[diff2983]で概説されているガイドラインに従う必要があります。SPは、PEルーターがサポートする追加のメカニズムのいずれかを展開することもできます。
If the SP is providing Internet multicast, distinct from its VPN multicast services, it must ensure that the P-group addresses that correspond to its MDs are distinct from any of the group addresses of the Internet multicasts it supports. This is best done by using administratively scoped addresses [ADMIN-ADDR].
SPがVPNマルチキャストサービスとは異なるインターネットマルチキャストを提供している場合、MDに対応するPグループアドレスが、サポートするインターネットマルチキャストのグループアドレスのいずれかとは異なることを確認する必要があります。これは、管理上スコープアドレス[Admin-ADDR]を使用して行うのが最適です。
The C-group addresses need not be distinct from either the P-group addresses or the Internet multicast addresses.
Cグループアドレスは、Pグループアドレスまたはインターネットマルチキャストアドレスのいずれかと区別する必要はありません。
If a particular VRF is in a particular MD, the corresponding MT is treated by that VRF's VPN-specific PIM instances as a LAN interface. As a result, the PEs that are adjacent on the MT will generate and process PIM control packets, such as Hello, Join/Prune, and Assert. Designated Forwarder election occurs just as it would on an actual LAN interface.
特定のVRFが特定のMDにある場合、対応するMTは、そのVRFのVPN固有のPIMインスタンスによってLANインターフェイスとして扱われます。その結果、MTに隣接するPESは、Hello、Join/Prune、AssertなどのPIM制御パケットを生成および処理します。指定されたフォワーダー選挙は、実際のLANインターフェイスと同じように発生します。
The PIM protocol packets are sent to ALL-PIM-ROUTERS (224.0.0.13 for IPv4 or ff02::d for IPv6) in the context of that VRF, but when in transit in the provider network, they are encapsulated using the Default MDT group configured for that MD. This allows VPN-specific PIM routes to be extended from site to site without appearing in the P routers.
PIMプロトコルパケットは、そのVRFのコンテキストでAll-PIM-Routers（IPv4またはFF02 :: Dの場合は224.0.0.13またはIPv6の場合は224.0.0.0.13）に送信されますが、プロバイダーネットワークでトランジットしている場合、デフォルトのMDTグループを使用してカプセル化されています。そのMD用に構成されています。これにより、VPN固有のPIMルートをPルーターに表示せずにサイトからサイトに拡張できます。
If a PIM C-Instance control packet is an IPv6 packet, its source address is the IPv4-mapped IPv6 address corresponding to the IPv4 address of the PE router sending the packet.
PIM C-InstanceコントロールパケットがIPv6パケットである場合、そのソースアドレスは、パケットを送信するPEルーターのIPv4アドレスに対応するIPv4-Mapped IPv6アドレスです。
Although the MT is treated as a PIM-enabled interface, unicast routing is NOT run over it, and there are no unicast routing adjacencies over it. It is therefore necessary to specify special procedures for determining when the MT is to be regarded as the "RPF Interface" for a particular C-address.
MTはPIM対応インターフェイスとして扱われますが、ユニキャストルーティングは実行されず、ユニキャストルーティングの隣接はありません。したがって、MTが特定のCアドレスの「RPFインターフェイス」と見なされる時期を決定するための特別な手順を指定する必要があります。
When a PE needs to determine the RPF interface of a particular C-address, it looks up the C-address in the VRF. If the route matching it is not a VPN-IP route learned from MP-BGP as described in [RFC4364], or if that route's outgoing interface is one of the interfaces associated with the VRF, then ordinary PIM procedures for determining the RPF interface apply.
PEが特定のCアドレスのRPFインターフェイスを決定する必要がある場合、VRFのCアドレスを調べます。一致するルートが[RFC4364]で説明されているようにMP-BGPから学習したVPN-IPルートではない場合、またはそのルートの発信インターフェイスがVRFに関連付けられたインターフェイスの1つである場合、RPFインターフェイスを決定するための通常のPIM手順を適用するための通常のPIM手順が適用されます。。
However, if the route matching the C-address is a VPN-IP route whose outgoing interface is not one of the interfaces associated with the VRF, then PIM will consider the outgoing interface to be the MT associated with the VPN-specific PIM instance.
ただし、Cアドレスを一致させるルートが、発信インターフェイスがVRFに関連付けられたインターフェイスの1つではないVPN-IPルートである場合、PIMは発信インターフェイスがVPN固有のPIMインスタンスに関連付けられたMTと見なされます。
Once PIM has determined that the RPF interface for a particular C-address is the MT, it is necessary for PIM to determine the RPF neighbor for that C-address. This will be one of the other PEs that is a PIM adjacency over the MT.
PIMが特定のCアドレスのRPFインターフェイスがMTであると判断すると、PIMがそのCアドレスのRPF隣接を決定する必要があります。これは、MTのPIM隣接である他のPESの1つになります。
The BGP "Connector" Attribute is defined. Whenever a PE router distributes a VPN-IP address from a VRF that is part of an MD, it SHOULD distribute a Connector Attribute along with it. The Connector Attribute specifies the MDT address family, and its value is the IP address that the PE router is using as its source IP address for the multicast packets that are encapsulated and sent over the MT. When a PE has determined that the RPF interface for a particular C-address is the MT, it looks up the Connector Attribute that was distributed along with the VPN-IP address corresponding to that C-address. The value of this Connector Attribute is considered to be the RPF adjacency for the C-address.
BGP「コネクタ」属性が定義されています。PEルーターがMDの一部であるVRFからVPN-IPアドレスを配布するときはいつでも、コネクタ属性をそれと一緒に配布する必要があります。コネクタ属性はMDTアドレスファミリを指定し、その値は、PEルーターがカプセル化され、MTを介して送信されるマルチキャストパケットのソースIPアドレスとして使用しているIPアドレスです。PEが特定のCアドレスのRPFインターフェイスがMTであると判断した場合、そのCアドレスに対応するVPN-IPアドレスとともに分布したコネクタ属性を調べます。このコネクタ属性の値は、CアドレスのRPF隣接と見なされます。
There are older implementations in which the Connector Attribute is not present. In this case, as long as the "BGP Next Hop" for the C-address is one of the PEs that is a PIM adjacency, then that PE is treated as the RPF adjacency for that C-address.
コネクタ属性が存在しない古い実装があります。この場合、Cアドレスの「BGP Next Hop」がPIMの隣接性であるPESの1つである限り、そのPEはそのCアドレスのRPF隣接として扱われます。
However, if the MD spans multiple Autonomous Systems, and an "option b" interconnect ([RFC4364], Section 10) is used, the BGP Next Hop might not be a PIM adjacency, and the RPF check will not succeed unless the Connector Attribute is used.
ただし、MDが複数の自律システムにまたがり、「オプションB」の相互接続（[RFC4364]、セクション10）が使用されている場合、BGP次のホップはPIM隣接ではなく、コネクタ属性属性がない限りRPFチェックが成功しない可能性があります。使用されている。
In [MVPN], the Connector Attribute is replaced by the "VRF Route Import Extended Community" attribute. The latter is a generalized version, but carries the same information as the Connector Attribute does; the encoding, however, is different.
[MVPN]では、コネクタ属性は「VRFルートインポート拡張コミュニティ」属性に置き換えられます。後者は一般化されたバージョンですが、コネクタ属性と同じ情報が含まれています。ただし、エンコードは異なります。
The Connector Attribute is defined in the following subsection.
コネクタ属性は、次のサブセクションで定義されています。
The Connector Attribute is an optional transitive attribute. Its value field is formatted as follows:
コネクタ属性は、オプションの推移的属性です。その値フィールドは次のようにフォーマットされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv4 Address of PE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While the procedure specified in the previous section requires the P routers to maintain multicast state, the amount of state is bounded by the number of supported VPNs. The P routers do NOT run any VPN-specific PIM instances.
前のセクションで指定された手順では、マルチキャスト状態を維持するためにPルーターが必要ですが、状態の量はサポートされているVPNの数によって制限されます。Pルーターは、VPN固有のPIMインスタンスを実行しません。
In particular, the use of a single bidirectional tree per VPN scales well as the number of transmitters and receivers increases, but not so well as the amount of multicast traffic per VPN increases.
特に、VPNあたりの単一の双方向ツリーの使用は、送信機と受信機の数が増加しますが、VPNあたりのマルチキャストトラフィックの量は増加しません。
The multicast routing provided by this scheme is not optimal, in that a packet of a particular multicast group may be forwarded to PE routers that have no downstream receivers for that group, and which hence may need to discard the packet.
このスキームで提供されるマルチキャストルーティングは最適ではありません。特定のマルチキャストグループのパケットは、そのグループの下流レシーバーがないため、パケットを廃棄する必要があるPEルーターに転送される可能性があるためです。
In the simplest configuration model, only the Default MDT group is configured for each MD. The result of the configuration is that all VPN multicast traffic, whether control or data, will be encapsulated and forwarded to all PE routers that are part of the MD. While this limits the number of multicast routing states the provider network has to maintain, it also requires PE routers to discard multicast C-packets if there are no receivers for those packets in the corresponding sites. In some cases, especially when the content involves high bandwidth but only a limited set of receivers, it is desirable that certain C-packets only travel to PE routers that do have receivers in the VPN to save bandwidth in the network and reduce load on the PE routers.
最も単純な構成モデルでは、各MDに対してデフォルトのMDTグループのみが構成されます。構成の結果、すべてのVPNマルチキャストトラフィックは、コントロールであろうとデータであろうと、MDの一部であるすべてのPEルーターにカプセル化され、転送されます。これにより、プロバイダーネットワークが維持する必要があるマルチキャストルーティング状態の数が制限されますが、対応するサイトにそれらのパケットの受信機がない場合、マルチキャストCパケットを破棄するためのPEルーターも必要です。場合によっては、特にコンテンツが高い帯域幅を伴うが、レシーバーの限られたセットのみを伴う場合、特定のCパケットは、ネットワーク内の帯域幅を節約し、負荷を減らすためにVPNにレシーバーを持つPEルーターにのみ移動することが望ましいですPEルーター。
A simple protocol is proposed to signal additional P-group addresses to encapsulate VPN traffic. These P-group addresses are called Data MDT groups. The ingress PE router advertises a different P-group address (as opposed to always using the Default MDT group) to encapsulate VPN multicast traffic. Only the PE routers on the path to eventual receivers join the P-group, and therefore form an optimal multicast distribution tree in the service-provider network for the VPN multicast traffic. These multicast distribution trees are called Data MDTs because they do not carry PIM control packets exchanged by PE routers.
簡単なプロトコルが提案されており、VPNトラフィックをカプセル化するために追加のPグループアドレスを信号します。これらのPグループアドレスは、データMDTグループと呼ばれます。Ingress PEルーターは、VPNマルチキャストトラフィックをカプセル化するために、常にデフォルトのMDTグループを使用するのではなく）別のPグループアドレスを宣伝します。最終的な受信機へのパス上のPEルーターのみがPグループに結合するため、VPNマルチキャストトラフィックのサービスプロバイダーネットワークに最適なマルチキャスト分布ツリーを形成します。これらのマルチキャスト分布ツリーは、PEルーターによって交換されたPIM制御パケットを運ばないため、データMDTと呼ばれます。
The following text documents the procedures of the initiation and teardown of the Data MDTs. The definition of the constants and timers can be found in Section 7.
次のテキストには、データMDTの開始と分解の手順を文書化します。定数とタイマーの定義は、セクション7にあります。
- The PE router connected to the source of the content initially uses the Default MDT group when forwarding the content to the MD.
- コンテンツのソースに接続されたPEルーターは、最初にコンテンツをMDに転送するときにデフォルトのMDTグループを使用します。
- When one or more pre-configured conditions are met, it starts to periodically announce the MDT Join TLV at the interval of [MDT_INTERVAL]. The MDT Join TLV is forwarded to all the PE routers in the MD.
- 1つ以上の事前に構成された条件が満たされると、[MDT_INTERVAL]の間隔でMDT参加TLVを定期的に発表し始めます。MDT結合TLVは、MDのすべてのPEルーターに転送されます。
A commonly used condition is the bandwidth. When the VPN traffic exceeds a certain threshold, it is more desirable to deliver the flow to the PE routers connected to receivers in order to optimize the performance of PE routers and the resources of the provider network. However, other conditions can also be devised, and they are purely implementation specific.
一般的に使用される条件は帯域幅です。VPNトラフィックが特定のしきい値を超える場合、PEルーターのパフォーマンスとプロバイダーネットワークのリソースを最適化するために、受信機に接続されたPEルーターにフローを配信することがより望ましいです。ただし、他の条件も考案することができ、それらは純粋に実装固有です。
- The MDT Join TLV is encapsulated in UDP.
- MDT結合TLVはUDPにカプセル化されています。
UDP over IPv4 is used if the multicast stream being assigned to a Data MDT is an IPv4 stream. In this case, the UDP datagram is addressed to ALL-PIM-ROUTERS (224.0.0.13).
MDTに割り当てられているマルチキャストストリームがIPv4ストリームである場合、UDP Over IPv4が使用されます。この場合、UDPデータグラムはAll-PIM-Routers（224.0.0.13）にアドレス指定されます。
UDP over IPv6 is used if the multicast stream being assigned to a Data MDT is an IPv6 stream. In this case, the UDP datagram is addressed to ALL-PIM-ROUTERS (ff02::d).
MDTに割り当てられているマルチキャストストリームがIPv6ストリームである場合、IPv6を超えるUDPが使用されます。この場合、UDPデータグラムはAll-PIM-Routers（FF02 :: D）にアドレス指定されます。
The destination UDP port is 3232.
宛先UDPポートは3232です。
The UDP datagram is sent on the Default MDT. This allows all PE routers to receive the information. Any MDT Join that is not received over a Default MDT MUST be dropped.
UDPデータグラムは、デフォルトのMDTで送信されます。これにより、すべてのPEルーターが情報を受信できます。デフォルトのMDTで受信されないMDT結合は、ドロップする必要があります。
- Upon receiving an MDT Join TLV, PE routers connected to receivers will join the Data MDT group announced by the MDT Join TLV in the global table. When the Data MDT group is in PIM-SM or bidirectional PIM mode, the PE routers build a shared tree toward the RP. When the Data MDT group is set up using PIM-SSM, the PE routers build a source tree toward the PE router that is advertising the MDT Join TLV. The IP address of that PE router is learned from the IP Source Address field of the UDP packet that contains the MDT Join TLV.
- TLVに結合したMDTを受信すると、受信機に接続されたPEルーターは、GlobalテーブルでMDT Join TLVによって発表されたデータMDTグループに参加します。データMDTグループがPIM-SMまたは双方向PIMモードである場合、PEルーターはRPに向かって共有ツリーを構築します。データMDTグループがPIM-SSMを使用してセットアップされると、PEルーターはMDT Join TLVを宣伝しているPEルーターに向かってソースツリーを構築します。そのPEルーターのIPアドレスは、MDT結合TLVを含むUDPパケットのIPソースアドレスフィールドから学習されます。
PE routers that are not connected to receivers may wish to cache the states in order to reduce the delay when a receiver comes up in the future.
受信機に接続されていないPEルーターは、レシーバーが将来登場したときに遅延を減らすために状態をキャッシュすることを希望する場合があります。
- After [MDT_DATA_DELAY], the PE router connected to the source starts encapsulating traffic using the Data MDT group.
- [MDT_DATA_DELAY]の後、ソースに接続されたPEルーターは、データMDTグループを使用してトラフィックのカプセル化を開始します。
- When the pre-configured conditions are no longer met, e.g., the traffic stops, the PE router connected to the source stops announcing the MDT Join TLV.
- 事前に構成された条件が満たされなくなった場合、たとえばトラフィックが停止すると、ソースに接続されているPEルーターがMDT Join TLVを発表します。
- If the MDT Join TLV is not received for an interval longer than [MDT_DATA_TIMEOUT], PE routers connected to the receivers just leave the Data MDT group in the global instance.
- MDT結合TLVが[MDT_DATA_TIMEOUT]よりも長い間間隔で受信されない場合、受信機に接続されたPEルーターは、GlobalインスタンスでデータMDTグループを離れるだけです。
The use of Data MDTs requires that a set of multicast P-addresses be pre-allocated and dedicated for use as the destination addresses for the Data MDTs.
データMDTを使用するには、一連のマルチキャストPアドレスを事前に割り当て、データMDTの宛先アドレスとして使用するために専用する必要があります。
If SSM is used to set up the Data MDTs, then each MD needs to be assigned a set of these multicast P-addresses. Each VRF in the MD needs to be configured with this same set of multicast P-addresses. If there are n addresses in this set, then each PE in the MD can be the source of n Data MDTs in that MD.
SSMを使用してデータMDTをセットアップする場合、各MDにこれらのマルチキャストPアドレスのセットを割り当てる必要があります。MDの各VRFは、この同じ一連のマルチキャストPアドレスで構成する必要があります。このセットにnアドレスがある場合、MDの各PEは、そのMDのNデータMDTのソースになります。
If SSM is not used for setting up Data MDTs, then each VRF needs to be configured with a unique set of multicast P-addresses; two VRFs in the same MD cannot be configured with the same set of addresses. This requires the pre-allocation of many more multicast P-addresses, and the need to configure a different set for each VRF greatly complicates the operations and management. Therefore, the use of SSM for Data MDTs is very strongly recommended.
SSMがデータMDTのセットアップに使用されていない場合、各VRFはマルチキャストPアドレスの一意のセットで構成する必要があります。同じMDの2つのVRFは、同じアドレスのセットで構成できません。これには、より多くのマルチキャストPアドレスの事前配分が必要であり、VRFごとに異なるセットを構成する必要があると、運用と管理が大幅に複雑になります。したがって、データMDTSのSSMの使用を非常に強くお勧めします。
The MDT TLV has the following format.
MDT TLVには次の形式があります。
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 | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
タイプ（8ビット）：
the type of the MDT TLV. In this specification, types 1 and 4 are defined.
MDT TLVのタイプ。この仕様では、タイプ1と4が定義されています。
Length (16 bits):
長さ（16ビット）：
the total number of octets in the TLV for this type, including both the Type and Length fields.
タイプと長さの両方のフィールドを含む、このタイプのTLVのオクテットの総数。
Value (variable length):
値（変数長）：
the content of the TLV.
TLVの内容。
The MDT Join TLV for IPv4 streams has the following format.
IPv4ストリームのMDT結合TLVには、次の形式があります。
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
タイプ（8ビット）：
Must be set to 1.
1に設定する必要があります。
Length (16 bits):
長さ（16ビット）：
Must be set to 16.
16に設定する必要があります。
Reserved (8 bits):
予約済み（8ビット）：
for future use.
将来の使用のために。
C-source (32 bits):
c-source（32ビット）：
the IPv4 address of the traffic source in the VPN.
VPNのトラフィックソースのIPv4アドレス。
C-group (32 bits):
Cグループ（32ビット）：
the IPv4 address of the multicast traffic destination address in the VPN.
VPNのマルチキャストトラフィックデスティネーションアドレスのIPv4アドレス。
P-group (32 bits):
Pグループ（32ビット）：
the IPv4 group address that the PE router is going to use to encapsulate the flow (C-source, C-group).
IPv4グループは、PEルーターがフローをカプセル化するために使用することを扱っています（C-Source、C-Group）。
The MDT Join TLV for IPv6 streams has the following format.
IPv6ストリームのMDT結合TLVには、次の形式があります。
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| C-source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| C-group |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
タイプ（8ビット）：
Must be set to 4.
4に設定する必要があります。
Length (16 bits):
長さ（16ビット）：
Must be set to 40.
40に設定する必要があります。
Reserved (8 bits):
予約済み（8ビット）：
for future use.
将来の使用のために。
C-source (128 bits):
c-source（128ビット）：
the IPv6 address of the traffic source in the VPN.
VPNのトラフィックソースのIPv6アドレス。
C-group (128 bits):
Cグループ（128ビット）：
the IPv6 address of the multicast traffic destination address in the VPN.
VPNのマルチキャストトラフィックデスティネーションアドレスのIPv6アドレス。
P-group (32 bits):
Pグループ（32ビット）：
the IPv4 group address that the PE router is going to use to encapsulate the flow (C-source, C-group).
IPv4グループは、PEルーターがフローをカプセル化するために使用することを扱っています（C-Source、C-Group）。
A single UDP datagram MAY carry multiple MDT Join TLVs, as many as can fit entirely within it. If there are multiple MDT Join TLVs in a UDP datagram, they MUST be of the same type. The end of the last MDT Join TLV (as determined by the MDT Join TLV Length field) MUST coincide with the end of the UDP datagram, as determined by the UDP Length field. When processing a received UDP datagram that contains one or more MDT Join TLVs, a router MUST be able to process all the MDT Join TLVs that fit into the datagram.
単一のUDPデータグラムは、複数のMDT結合TLVを運ぶ場合があります。UDPデータグラムに複数のMDTに結合されている場合、それらは同じタイプでなければなりません。最後のMDT結合TLVの終了（MDT Join TLV長さフィールドによって決定される）は、UDP長さフィールドで決定されるUDPデータグラムの終わりと一致する必要があります。1つ以上のMDT結合TLVを含む受信したUDPデータグラムを処理する場合、ルーターはデータグラムに適合するすべてのMDT結合TLVを処理できる必要があります。
[MDT_DATA_DELAY]:
[MDT_DATA_DELAY]：
the interval before the PE router connected to the source will switch to the Data MDT group. The default value is 3 seconds.
ソースに接続されたPEルーターの前の間隔は、データMDTグループに切り替わります。デフォルト値は3秒です。
[MDT_DATA_TIMEOUT]:
[MDT_DATA_TIMEOUT]：
the interval before which the PE router connected to the receivers will time out and leave the Data MDT group if no MDT_JOIN_TLV message has been received. The default value is 3 minutes. This value must be consistent among PE routers.
MDT_JOIN_TLVメッセージが受信されていない場合、PEルーターが受信機に接続されている間隔はタイムアウトし、データMDTグループを離れます。デフォルト値は3分です。この値は、PEルーター間で一貫している必要があります。
[MDT_DATA_HOLDDOWN]:
[MDT_DATA_HOLDDOWN]：
the interval before which the PE router will switch back to the Default MDT after it started encapsulating packets using the Data MDT group. This is used to avoid oscillation when traffic is bursty. The default value is 1 minute.
PEルーターがデータMDTグループを使用してパケットのカプセル化を開始した後、PEルーターがデフォルトのMDTに切り替える間隔。これは、トラフィックが破裂したときの振動を回避するために使用されます。デフォルト値は1分です。
[MDT_INTERVAL]:
[MDT_INTERVAL]：
the interval the source PE router uses to periodically send MDT_JOIN_TLV messages. The default value is 60 seconds.
ソースPEルーターが使用する間隔MDT_JOIN_TLVメッセージを定期的に送信します。デフォルト値は60秒です。
The codepoint for the Connector Attribute is defined in IANA's registry of BGP attributes. The reference has been updated to refer to this document. On the IANA web page, the codepoint is denoted as "deprecated". This document does not change that status. However, note that there are a large number of deployments using this codepoint, and this is likely to be the case for a number of years.
コネクタ属性のCodePointは、IANAのBGP属性のレジストリで定義されています。参照は、このドキュメントを参照するために更新されました。IANAのWebページでは、CodePointは「非推奨」として示されています。このドキュメントはそのステータスを変更しません。ただし、このCodePointを使用して多数の展開があることに注意してください。これは何年もの間当てはまる可能性が高いことに注意してください。
The codepoint for MDT-SAFI is defined in IANA's registry of BGP SAFI assignments. The reference has been updated to refer to this document.
MDT-SafiのCodePointは、IANAのBGP Safi割り当てのレジストリで定義されています。参照は、このドキュメントを参照するために更新されました。
[RFC4364] discusses in general the security considerations that pertain to when the RFC 4364 type of VPN is deployed.
[RFC4364]は、一般に、RFC 4364タイプのVPNが展開される時期に関連するセキュリティ上の考慮事項について説明します。
[PIM-SM] discusses the security considerations that pertain to the use of PIM.
[PIM-SM]は、PIMの使用に関連するセキュリティ上の考慮事項について説明します。
The security considerations of [RFC4023] and [RFC4797] apply whenever VPN traffic is carried through IP or GRE tunnels.
[RFC4023]および[RFC4797]のセキュリティ上の考慮事項は、VPNトラフィックがIPまたはGREトンネルを介して運ばれるたびに適用されます。
Major contributions to this work have been made by Dan Tappan and Tony Speakman.
この作品への主要な貢献は、ダン・タッパンとトニー・スピークマンによってなされました。
The authors also wish to thank Arjen Boers, Robert Raszuk, Toerless Eckert, and Ted Qian for their help and their ideas.
著者はまた、Arjen Boers、Robert Raszuk、Toerless Eckert、Ted Qianの助けとアイデアに感謝したいと考えています。
[GRE2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[GRE2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、 "Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）、RFC 4601、2006年8月。
[PIM-ATTRIB] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[Pim-Attrib] Boers、A.、Wijnands、I。、およびE. Rosen、「プロトコル独立マルチキャスト（PIM）結合属性形式」、RFC 5384、2008年11月。
[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月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[ADMIN-ADDR] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Admin-Addr] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[BIDIR] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[Bidir] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[DIFF2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[diff2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[GRE1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[GRE1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 1701、1994年10月。
[GRE2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[GRE2890] Dommety、G。、「Key and Sequence Number GREへの拡張」、RFC 2890、2000年9月。
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[MVPN] Rosen、E.、ed。、およびR. Aggarwal、ed。、「MPLS/BGP IP VPNSのマルチキャスト」、2010年1月の作業。
[SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[SSM] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC 4797, January 2007.
[RFC4797] Rekhter、Y.、Bonica、R。、およびE. Rosen、「プロバイダーエッジのエッジエッジ（PE-PE）ジェネリックルーティングカプセル化（GRE）またはBGP/MPLS IP仮想ネットワークでのIPの使用」、RFC4797、2007年1月。
Authors' Addresses
著者のアドレス
Eric C. Rosen (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
エリックC.ローゼン（編集者）Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 Email：erosen@cisco.com
Yiqun Cai (editor) Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 EMail: ycai@cisco.com
Yiqun Cai（編集者）Cisco Systems、Inc。170 Tasman Drive San Jose、CA 95134メール：Ycai@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 EMail: ice@cisco.com
IJSBRAND Wijnands Cisco Systems、Inc。170 Tasman Drive San Jose、CA 95134メール：ice@cisco.com