Independent Submission E. Rosen, Ed.
Request for Comments: 6037 Y. Cai, Ed.
Category: Historic I. Wijnands
ISSN: 2070-1721 Cisco Systems, Inc.
October 2010
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
Cisco Systems在BGP/MPLS IP VPN中的多播解决方案
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 VPN中的多播）解决方案。本文件中规定的程序主要是IETF最近标准化的通用MVPN框架的子集。然而，由于本文规定的程序的部署早于IETF标准的发布（在某些情况下超过五年），基于这些程序的实施在某些方面与完全符合标准的实施有所不同。文件中指出了这些差异。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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 VPN中的多播）解决方案。本文档将记录在案，并作为与已部署实现互操作的参考。本文件为技术规范，不应用于推断思科系统当前或未来的计划。
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 VPN的基本规范[RFC4364]未提供IP多播数据或控制流量从一个VPN站点传输到另一个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. 协议独立多播（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. PIM在IPv4上运行，是服务提供商（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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
[RFC4364]的BGP/MPLS IP VPN服务通过SP主干网提供具有“最佳”单播路由的VPN，其中数据包遵循主干网自身路由算法确定的“最短路径”。提供了这种最佳路由
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.
不需要“P路由器”（提供商主干网中的路由器，而不是“提供商边缘”或“PE”路由器）来维护特定于VPN的任何路由信息；实际上，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.
不幸的是，如果不要求P路由器维护一些特定于VPN的状态信息，就无法提供最佳多播路由。最佳多播路由需要在主干中为每个正在使用的多播组创建一个或多个多播分发树。如果VPN中的特定多播组使用基于源的分发树，则最佳路由要求该组的每个发射机都有一个分发树。如果正在使用共享树，则每个组仍需要一棵树。每个这样的树都需要P路由器的某些集合中的状态，状态量与多播发射机的数量成比例。每个多播组需要至少一个分发树的原因是每个组可能有一组不同的接收器；多播路由算法通常会花费大量时间来确保多播数据包不会发送到不在接收器路径上的节点。
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可能有多个多播组，并且每个多播组可能有多个发射机，因此对于每个多播组来说，具有一个或多个分发树是不可伸缩的。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
SP确定特定VPN是否启用了多播。如果是，则对应于“多播域”。连接到特定支持多播的VPN的PE被称为属于
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.
相应的多播域。对于每个多播域，有一个通过主干的默认多播分发树（“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是在域中的PE出现时自动构建的。默认MDT的构造不依赖于域中多播流量的存在；它将在看到任何此类多播流量之前存在。默认MDT对应于[MVPN]的多向包容性P多播服务接口（“MI PMSI”）。
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路由器接收。入口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仅将特定多播组的VPN数据流量传送到该多播组的接收器路径上的那些PE路由器。使用数据MDT有利于减少主干上的多播通信量，以及减少某些PE上的负载；它的缺点是增加了P路由器必须维护的状态量。SP完全可以控制这种权衡。数据MDT对应于[MVPN]的选择性PMSI（“S-PMSI”）。
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
此解决方案要求SP部署适当的协议和过程，但对SP的客户是透明的。在其网络中使用基于PIM的多播的企业可以从
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.
专用网络连接到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路由器运行许多PIM稀疏模式（PIM-SM）实例，每个VRF最多运行一个实例。在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实例”），在该实例中，它与每个IGP邻居（即，与P路由器）具有PIM邻接，但不与任何CE路由器，也不与其他PE路由器（除非它们恰好在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-instance处理的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分配给一个MD。每个MD配置有一个不同的多播P组地址，称为“默认MDT组地址”。此地址用于为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实例控制流量时，它会封装控制流量，将其自己的IPv4地址作为源IP地址，将默认MDT组地址作为目标IP地址。请注意，默认MDT是PIM P实例的一部分，而通过默认MDT进行通信的PE是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上发送。第6节介绍了数据MDT的使用。
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.
请注意，如果使用ASM（“任何源多播”）服务模型设置MDT（默认或数据），MDT（默认或数据）必须具有“全局唯一”（更准确地说，在承载相应MD的多播流量的SP网络集合上唯一）的P组地址。如果使用SSM（“源特定多播”）模型设置MDT，则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网络中，单个MT作为默认MDT与零个或多个数据MDT组合实现。
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.
入口PE是直接连接到VPN中的多播发送方或通过CE路由器的PE路由器。当多播发送方开始传输时，如果公共MD中的其他PE路由器后面有接收器（或PIM RP），则入口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路由器具有VPN特定PIM实例，其中它正在将特定C组的流量转发到其连接的站点之一，并且该特定C组已与该特定数据MDT相关联，则PE路由器也可以加入数据MDT组。当PE路由器加入用于封装VPN多播流量的任何P组时，PE路由器成为相应MT的端点之一。
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.
当从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是一种IP隧道，其目标地址为P组地址。然而，MT不限于仅使用一个P组地址进行封装。基于有效负载VPN多播通信量，它可以选择使用默认MDT组地址或数据MDT组地址之一（如本文档第6节所述），从而允许MT到达公共MD中的不同PE路由器组。
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源特定多播（PIM-SSM）[SSM]。除PIM-SSM外，PEs只需知道正确的P组地址即可开始设置默认MDT。然后，PEs将通过接收彼此来源（和封装）的PIM控制流量（例如PIM Hellos）来发现彼此的地址。
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组地址，一个IPv4多播地址，用作将通过MDT发送的多播数据包的IP目标地址字段。
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）。本规范还要求实现能够使用PIM-SSM设置默认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
在[MVPN]中，MDT-SAFI被包含自主系统的内部PMSI自动发现（“内部AS I-PMSI A-D”）路由所取代。后者是MDT-SAFI的通用版本，允许将“默认MDT”和“数据MDT”实现为MPLS P2MP LSP（“点对多点标签交换路径”）或MP2MP LSP
("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.
（“多点到多点标签交换路径”），以及由PIM创建的多播分发树。在后一种情况下，帧内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 A-D路由也承载路由目标，因此可以与单播路由相同的方式分布，包括作为内部AS分布。（尽管名称不同，但AS I-PMSI A-D路由的AS间分布有时在[MVPN]中是必要的。）
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的BGP消息是“MDT-SAFI”消息。
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地址，后跟MDT组地址，即此SAFI的MP_REACH属性将包含一个或多个以下形式的元组：
+-------------------------------+
| |
| RD:IPv4-address (12 octets) |
| |
+-------------------------------+
| Group Address (4 octets) |
+-------------------------------+
+-------------------------------+
| |
| 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双向树。但是，如果使用PIM-SSM，分配P组地址的操作过程可能会大大简化，特别是在多提供商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路由器位于不同的AS中，则P路由器可能没有到源的路由。例如，远程AS可以使用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下一跳”。这可以通过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地址系列中选择树的源，则可能需要沿MDT SAFI地址的路由而不是沿相应IPv4地址的路由构建树。这使得树的inter-AS部分能够遵循专门为多播选择的路径（即，它允许inter-AS多播拓扑与inter-AS单播拓扑“不一致”）。这也需要PIM扩展。
The necessary PIM extension is the PIM MVPN Join Attribute described in the following subsection.
必要的PIM扩展是以下小节中描述的PIM MVPN Join属性。
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连接/删除消息中包含的连接属性的格式。现在我们定义一个新的连接属性，我们称之为“MVPN连接属性”。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
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连接属性的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].
[PIM-ATTRIB]中给出了设置E位的规则。
Two information fields are carried in the MVPN Join Attribute:
MVPN连接属性中包含两个信息字段：
- 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地址。这将是IPv4或IPv6地址，具体取决于PIM加入/删除消息本身是IPv4还是IPv6。
- RD: An eight-byte RD. This immediately follows the proxy IP address.
- RD：一个八字节的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.
在内部AS MVPN的情况下，代理和上游PE是相同的。在内部AS MVPN的情况下，代理将是AS边界路由器（ASBR），它是从本地AS到上游PE路径上的出口点。
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 Join/Prune消息以将inter设置为默认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路由的PE的地址（从该路由的NLRI获得）。
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 Join/Prune消息时，它首先检查代理字段是否包含自己的地址之一。
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 Join属性必须向上游传递，保持不变。
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地址之一，则路由器在其BGP路由表中查找MDT-SAFI路由，该路由的NLRI由上游PE地址组成，该地址前面带有Join属性中的RD。如果不匹配，PIM消息将被丢弃。如果存在匹配，则使用匹配路由的BGP下一跳字段中的IP地址来确定RPF接口和邻居。当PIM加入/删减向上游转发时，代理字段将替换为BGP下一跳的地址，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
数据包在传输过程中接收的数据包通过出口PEs提供商网络在服务的入口PE转发的数据包
+---------------+
| P-IP Header |
+---------------+
| GRE |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
+---------------+
| 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.
不需要GRE Key字段，因为传递IP报头中的P组地址已经识别MD，并因此关联VRF上下文，以便进一步处理有效负载数据包。
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.
GRE序列号字段也不需要，因为原始应用程序的传输层服务将由C-IP报头提供。
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. 入口PE路由器（进行封装的路由器）不得在外部报头中设置DF（“不分段”）位，以及
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. 如果在C数据包的IP报头中清除了“DF”位，则在封装之前对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.
入口PE不应将生存时间（TTL）字段从从CE路由器接收的有效负载IP报头复制到传送IP报头。设置传送IP头的TTL由入口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多播服务的Internet多播，则必须确保与其MDs对应的P组地址不同于其支持的Internet多播的任何组地址。这最好通过使用管理作用域地址[ADMIN-ADDR]来实现。
The C-group addresses need not be distinct from either the P-group addresses or the Internet multicast addresses.
C组地址不需要与P组地址或Internet多播地址区分。
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中，则该VRF的VPN特定PIM实例将相应的MT视为LAN接口。因此，MT上相邻的PEs将生成并处理PIM控制数据包，如Hello、Join/Prune和Assert。指定的转发器选择就像在实际的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-Router（IPv4为224.0.0.13，IPv6为ff02:：d），但在提供商网络中传输时，它们使用为该MD配置的默认MDT组进行封装。这允许VPN特定PIM路由从站点扩展到站点，而不会出现在IP路由器中。
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实例控制数据包是IPv6数据包，则其源地址是与发送该数据包的PE路由器的IPv4地址相对应的IPv4映射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相关联的接口之一，则用于确定RPF接口的普通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地址的路由是VPN-IP路由，其输出接口不是与VRF相关联的接口之一，那么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之一。
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地址时，它应该随附一个连接器属性。Connector属性指定MDT地址系列，其值是PE路由器用作其源IP地址的IP地址，用于封装和通过MT发送的多播数据包。当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下一跳”是作为PIM邻接的PE之一，则该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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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路由器。虽然这限制了提供商网络必须维护的多播路由状态的数量，但它还要求PE路由器在相应站点中没有多播C数据包的接收器时丢弃这些数据包。在某些情况下，特别是当内容涉及高带宽但仅限于一组接收器时，期望某些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.
提出了一种简单的协议，用信号发送附加的P组地址来封装VPN流量。这些P组地址称为数据MDT组。入口PE路由器播发不同的P组地址（与始终使用默认MDT组相反），以封装VPN多播流量。只有到达最终接收者的路径上的PE路由器加入P组，从而在服务提供商网络中为VPN多播流量形成最优多播分布树。这些多播分发树称为数据MDT，因为它们不携带PE路由器交换的PIM控制数据包。
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.
- 当满足一个或多个预配置条件时，它开始以[MDT_interval]的间隔定期宣布MDT Join TLV。MDT Join 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 Join 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流，则使用IPv4上的UDP。在这种情况下，UDP数据报被发送到ALL-PIM-Router（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-Router（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.
- 收到MDT Join TLV后，连接到接收器的PE路由器将加入MDT Join TLV在全局表中宣布的数据MDT组。当数据MDT组处于PIM-SM或双向PIM模式时，PE路由器向RP构建共享树。当使用PIM-SSM设置数据MDT组时，PE路由器向正在宣传MDT加入TLV的PE路由器构建源树。PE路由器的IP地址从包含MDT Join 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 Join TLV的接收时间间隔超过[MDT_DATA_TIMEOUT]，则连接到接收器的PE路由器只需将数据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中的两个VRF不能配置为同一组地址。这需要预先分配更多的多播P地址，并且需要为每个VRF配置不同的集合，这大大复杂了操作和管理。因此，强烈建议将SSM用于数据MDT。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Join 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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源（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).
PE路由器将用于封装流的IPv4组地址（C源，C组）。
The MDT Join TLV for IPv6 streams has the following format.
IPv6流的MDT Join 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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源（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).
PE路由器将用于封装流的IPv4组地址（C源，C组）。
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 Join TLV，尽可能多的MDT Join TLV可以完全容纳在其中。如果UDP数据报中有多个MDT Join TLV，则它们必须是同一类型。最后一个MDT连接TLV的结尾（由MDT连接TLV长度字段确定）必须与UDP数据报的结尾（由UDP长度字段确定）一致。当处理接收到的包含一个或多个MDT Join TLV的UDP数据报时，路由器必须能够处理适合该数据报的所有MDT Join TLV。
[MDT_DATA_DELAY]:
[MDT_数据_延迟]：
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\u数据\u超时]：
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\U数据\U压下]：
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组封装数据包后切换回默认MDT的间隔。这用于避免在流量突发时出现振荡。默认值为1分钟。
[MDT_INTERVAL]:
[MDT_间隔]：
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.
连接器属性的代码点在IANA的BGP属性注册表中定义。参考文件已更新为参考本文件。在IANA网页上，代码点表示为“已弃用”。此文档不会更改该状态。但是，请注意，有大量使用此代码点的部署，而且这种情况可能会持续数年。
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的代码点在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]的安全注意事项适用于通过IP或GRE隧道传输VPN流量的情况。
Major contributions to this work have been made by Dan Tappan and Tony Speakman.
Dan Tappan和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]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Trana，“通用路由封装（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，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年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虚拟专用网络（VPN）”，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 50152007年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.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[GRE2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[GRE2890]Dommety，G.，“GRE的密钥和序列号扩展”，RFC 28902000年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 VPN中的多播”，正在进行的工作，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，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，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，“在BGP/MPLS IP虚拟专用网络中使用提供商边缘到提供商边缘（PE-PE）通用路由封装（GRE）或IP”，RFC 4797，2007年1月。
Authors' Addresses
作者地址
Eric C. Rosen (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
Eric C.Rosen（编辑）Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号邮编01719电子邮件：erosen@cisco.com
Yiqun Cai (editor) Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 EMail: ycai@cisco.com
蔡益群（编辑）思科系统有限公司，地址：加利福尼亚州圣何塞塔斯曼大道170号，邮编：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号，邮编95134电子邮件：ice@cisco.com