Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 7899 S. Litkowski
Updates: 6514 Orange
Category: Standards Track K. Patel
ISSN: 2070-1721 Cisco Systems
Z. Zhang
R. Kebler
J. Haas
Juniper Networks
June 2016
Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 7899 S. Litkowski
Updates: 6514 Orange
Category: Standards Track K. Patel
ISSN: 2070-1721 Cisco Systems
Z. Zhang
R. Kebler
J. Haas
Juniper Networks
June 2016
Multicast VPN State Damping
多播VPN状态阻尼
Abstract
摘要
This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.
本文档描述了抑制多播VPN（MVPN）路由状态更改和控制客户站点中多播动态性引起的搅动影响的过程。本文档中描述的过程适用于基于BGP的多播VPN，并有助于避免核心路由基础设施中控制平面负载的失控增加。所提出的新程序受到了BGP单播路由阻尼原理的启发，该原理已适用于多播。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7899.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7899.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4.1. Rate-Limiting Multicast Control Traffic . . . . . . . . . 5
4.2. Existing PIM, IGMP, and MLD Timers . . . . . . . . . . . 6
4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for Multicast State Damping . . . . . . . . . . . 7
5.1. PIM Procedures . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures for Multicast VPN State Damping . . . . . . . 10
6. Procedures for P-Tunnel State Damping . . . . . . . . . . . . 12
6.1. Damping MVPN P-Tunnel Change Events . . . . . . . . . . . 12
6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 13
7.1. Enabling Multicast Damping . . . . . . . . . . . . . . . 13
7.2. Troubleshooting and Monitoring . . . . . . . . . . . . . 13
7.3. Default and Maximum Values . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4.1. Rate-Limiting Multicast Control Traffic . . . . . . . . . 5
4.2. Existing PIM, IGMP, and MLD Timers . . . . . . . . . . . 6
4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for Multicast State Damping . . . . . . . . . . . 7
5.1. PIM Procedures . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures for Multicast VPN State Damping . . . . . . . 10
6. Procedures for P-Tunnel State Damping . . . . . . . . . . . . 12
6.1. Damping MVPN P-Tunnel Change Events . . . . . . . . . . . 12
6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 13
7.1. Enabling Multicast Damping . . . . . . . . . . . . . . . 13
7.2. Troubleshooting and Monitoring . . . . . . . . . . . . . 13
7.3. Default and Maximum Values . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
In a multicast VPN [RFC6513] deployed with BGP-based procedures [RFC6514], when receivers in VPN sites join and leave a given multicast group or channel through multicast membership control protocols (Internet Group Management Protocol (IGMP) [RFC3376] and Multicast Listener Discovery (MLD) [RFC3810]), multicast routing protocols accordingly adjust multicast routing states and P-multicast tree states to forward or prune multicast traffic to these receivers. Similar challenges arise in the context of the multicast specification for Virtual Private LAN Service (VPLS) [RFC7117].
在使用基于BGP的过程[RFC6514]部署的多播VPN[RFC6513]中，当VPN站点中的接收器通过多播成员控制协议（Internet组管理协议（IGMP）[RFC3376]和多播侦听器发现（MLD）[RFC3810]）加入并离开给定的多播组或信道时，多播路由协议相应地调整多播路由状态和P-多播树状态，以将多播流量转发或修剪到这些接收器。在虚拟专用LAN服务（VPLS）[RFC7117]的多播规范的上下文中也出现了类似的挑战。
In VPN contexts, providing isolation between customers of a shared infrastructure is a core requirement resulting in stringent expectations with regard to risks of denial-of-service attacks.
在VPN环境中，在共享基础设施的客户之间提供隔离是一项核心要求，这导致了对拒绝服务攻击风险的严格期望。
By nature, multicast memberships change based on the behavior of multicast applications running on end hosts. Hence, the frequency of membership changes can legitimately be much higher than the typical churn of unicast routing states.
本质上，多播成员身份会根据在终端主机上运行的多播应用程序的行为而变化。因此，成员资格更改的频率可以合法地远高于单播路由状态的典型搅动。
Therefore, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast membership changes are made by end hosts.
因此，需要建立机制，以确保施加在BGP控制平面和P-tunnel设置控制平面上的负载保持在控制之下，而不管终端主机进行多播成员身份更改的频率如何。
This document describes procedures inspired by existing BGP route damping [RFC2439] that are aimed at offering means to set an upper bound to the amount of processing for the MVPN control-plane protocols: more precisely, the BGP control plane in [RFC6514], the P-tunnel control-plane protocol in the contexts of [RFC6514], and the multicast specification for VPLS [RFC7117]. The goal of setting this upper bound is pursued simultaneous with the goal of preserving the service provided (delivering the multicast stream as requested by Customer Edge devices), although at the expense of a minimal increase of average bandwidth use in the provider network). The upper bound to the control-plane load due to the processing of a given multicast state is controlled indirectly via configurable parameters.
本文件描述了受现有BGP路由阻尼[RFC2439]启发的程序，旨在提供设置MVPN控制平面协议处理量上限的方法：更准确地说，[RFC6514]中的BGP控制平面，[RFC6514]中的P隧道控制平面协议，以及VPLS的多播规范[RFC7117]。设置该上限的目标与保持所提供的服务（根据客户边缘设备的请求交付多播流）的目标同时追求，尽管代价是提供商网络中平均带宽使用的最小增加）。由于处理给定的多播状态，控制平面负载的上限通过可配置参数间接控制。
Section 16 of [RFC6514] specifically spells out the need for damping the activity of C-multicast and Leaf Auto-discovery routes and outlines how to do it by "delaying the advertisement of withdrawals of C-multicast routes". This specification provides appropriate detail on how to implement this approach and how to provide control to the operator; for this reason, it is an update to [RFC6514].
[RFC6514]第16节明确说明了抑制C-多播和叶子自动发现路由活动的必要性，并概述了如何通过“延迟C-多播路由退出的公告”来实现这一点。本规范提供了有关如何实施该方法以及如何向操作员提供控制的适当细节；因此，它是对[RFC6514]的更新。
The base principle of this specification is described in Section 3. Existing mechanisms that could be relied upon are discussed in Section 4. Section 5 details the procedures introduced by this specification.
本规范的基本原理见第3节。第4节讨论了可依赖的现有机制。第5节详细说明了本规范介绍的程序。
Section 6 provides specific details related to the damping of multicast VPNs P-tunnel state.
第6节提供了有关多播VPN P隧道状态阻尼的具体细节。
Finally, Section 7 discusses operational considerations related to the proposed mechanism.
最后，第7节讨论了与拟议机制相关的操作考虑。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document reuses terminology from [RFC7761] and [RFC6514].
本文档重用了[RFC7761]和[RFC6514]中的术语。
In this specification, damping of a multicast state will be said to be "active" or "inactive". Note that in [RFC2439], the term used for a unicast route that is dampened is "suppressed", but we will avoid this term in this specification given that the proposed solution consists in holding active a damped multicast state.
在本规范中，多播状态的阻尼将被称为“活动”或“非活动”。请注意，在[RFC2439]中，用于阻尼的单播路由的术语是“抑制的”，但鉴于建议的解决方案包括保持阻尼的多播状态，我们将在本规范中避免使用该术语。
The procedures described in this document allow the network operator to configure multicast VPN PEs (Provider Edge routers) so that they can delay the propagation of multicast state prune messages between PEs when faced with a rate of multicast state dynamicity exceeding a certain configurable threshold. Assuming that the number of multicast states that can be created by a receiver is bounded, delaying the propagation of multicast state pruning results in setting up an upper bound to the average frequency at which the router will send state updates to an upstream router.
本文档中描述的过程允许网络运营商配置多播VPN PEs（提供商边缘路由器），以便当多播状态动态率超过某个可配置阈值时，他们可以延迟多播状态修剪消息在PEs之间的传播。假设可以由接收器创建的多播状态的数量是有界的，延迟多播状态修剪的传播将导致设置路由器将向上游路由器发送状态更新的平均频率的上限。
From the point of view of a downstream router, such as a CE (Customer Edge router), this approach has no impact: the multicast routing state changes that it solicits to its PE will be honored without any additional delay. Indeed, the propagation of Joins is not impacted by the procedures specified here, and having the upstream router delay state prune propagation to its own upstream router does not affect what traffic is sent to the downstream router. In particular, the amount of bandwidth used on the PE-CE link downstream to a PE applying this damping technique is not increased.
从下游路由器（如CE（客户边缘路由器））的角度来看，这种方法没有影响：它向其PE请求的多播路由状态更改将在没有任何额外延迟的情况下得到遵守。实际上，连接的传播不受此处指定的过程的影响，并且使上游路由器延迟状态修剪传播到其自己的上游路由器不会影响发送到下游路由器的流量。特别地，在应用该阻尼技术的PE下游的PE-CE链路上使用的带宽量没有增加。
This approach increases the average bandwidth utilization on a link upstream to a PE applying this technique, such as a PE-PE link: indeed, a given multicast flow will be forwarded for a longer time than if no damping was applied. That said, it is expected that this technique will meet the goals of protecting the multicast routing infrastructure control plane without a significant average increase of bandwidth; for instance, damping events happening at a frequency higher than one event per X seconds can be done without increasing by more than X seconds the time during which a multicast flow is present on a link.
这种方法提高了应用这种技术的PE（例如PE-PE链路）上游链路上的平均带宽利用率：实际上，与未应用阻尼相比，给定的多播流将被转发更长的时间。这就是说，预计该技术将在不显著增加平均带宽的情况下实现保护多播路由基础设施控制平面的目标；例如，以高于每X秒一个事件的频率发生的阻尼事件可以在不增加链路上存在多播流的时间超过X秒的情况下完成。
That said, simulation of the exponential decay algorithm shows that the multicast state churn can be drastically reduced without significantly increasing the duration for which multicast traffic is forwarded. Hence, using this technique will efficiently protect the multicast routing infrastructure control plane against the issues described here without a significant average increase of bandwidth. The exception will be a scenario with strict constraints on multicast bandwidth, where extending the time a multicast flow is forwarded would result in congestion.
也就是说，对指数衰减算法的模拟表明，在不显著增加多播流量转发持续时间的情况下，可以大幅减少多播状态搅动。因此，使用该技术将有效地保护多播路由基础设施控制平面，使其免受此处所述问题的影响，而不会显著增加平均带宽。例外情况是对多播带宽有严格限制的情况，延长多播流的转发时间将导致拥塞。
To be practical, such a mechanism requires configurability. In particular, means are required to control when damping is triggered and to allow delaying the pruning of a multicast state for a time increasing with the churn of this multicast state. This will let the operator control the trade-off made between minimizing the dynamicity and reducing bandwidth consumption.
为了实用，这种机制需要可配置性。特别地，需要控制何时触发阻尼的方法，并允许随着该多播状态的搅动而将多播状态的修剪延迟一段时间。这将使运营商能够控制最小化动态性和减少带宽消耗之间的权衡。
This section describes mechanisms that could be considered to address the issue but that end up appearing as not suitable or not efficient enough.
本节描述了可以考虑解决该问题的机制，但最终看起来不合适或效率不够。
The Protocol Independent Multicast - Sparse Mode (PIM-SM) specification [RFC7761] examines multicast security threats and, among other things, the risk of denial-of-service attacks described in Section 1. A mechanism relying on rate-limiting PIM messages is proposed in Section 5.3.3 of [RFC4609] but has the identified drawbacks of impacting the service delivered and having side-effects on legitimate users.
协议独立多播稀疏模式（PIM-SM）规范[RFC7761]检查多播安全威胁，以及第1节中描述的拒绝服务攻击风险。[RFC4609]第5.3.3节中提出了一种依赖速率限制PIM消息的机制，但该机制存在影响所提供服务和对合法用户产生副作用的缺陷。
In the context of PIM multicast routing protocols [RFC7761], a mechanism exists that may offer a form of de facto damping of multicast states, under some conditions. Indeed, when active, the prune override mechanism consists in having a PIM upstream router introduce a delay ("prune override interval") before taking into account a PIM Prune message sent by a downstream neighbor.
在PIM多播路由协议[RFC7761]的上下文中，存在一种机制，可在某些条件下提供事实上的多播状态阻尼形式。实际上，当处于活动状态时，修剪覆盖机制包括让PIM上游路由器在考虑下游邻居发送的PIM修剪消息之前引入延迟（“修剪覆盖间隔”）。
This mechanism has not been designed specifically for the purpose of damping multicast state, but as a means to allow PIM to operate on multi-access networks. See Section 4.3.3 of [RFC7761]. However, when active, this mechanism will prevent a downstream router from producing multicast routing protocol messages that would cause, for a given multicast state, the upstream router to send to its own upstream router multicast routing protocol messages at a rate higher than 1/[JP_Override_Interval]. This provides a form of de facto damping.
这种机制并不是专门为抑制多播状态而设计的，而是允许PIM在多址网络上运行的一种手段。见[RFC7761]第4.3.3节。然而，当激活时，该机制将防止下游路由器产生多播路由协议消息，该消息将导致对于给定的多播状态，上游路由器以高于1/[JP_Override_Interval]的速率向其自己的上游路由器发送多播路由协议消息。这提供了一种事实上的阻尼形式。
Similarly, the IGMP and MLD multicast membership control protocols can provide a similar behavior under the right conditions.
类似地，IGMP和MLD多播成员控制协议可以在适当的条件下提供类似的行为。
These mechanisms are not considered suitable to meet the goals spelled out in Section 1, the main reasons being that:
这些机制被认为不适合实现第1节规定的目标，主要原因是：
o when enabled, these mechanisms require additional bandwidth on the local link on which the effect of a prune is delayed (in our case, the PE-CE link);
o 启用时，这些机制需要本地链路上的额外带宽，在本地链路上剪枝的效果会延迟（在我们的例子中，PE-CE链路）；
o when enabled, these mechanisms require disabling explicit tracking (see Section 4.3.3 of [RFC7761]), even though enabling this feature may otherwise be desired;
o 启用时，这些机制需要禁用显式跟踪（见[RFC7761]第4.3.3节），即使可能需要启用此功能；
o on certain implementations, these mechanisms are incompatible with behaviors that cannot be turned off (e.g., implementation applying a fast-leave behavior on interfaces with only two neighbors);
o 在某些实现中，这些机制与无法关闭的行为不兼容（例如，在只有两个邻居的接口上应用快速离开行为的实现）；
o they do not provide a suitable level of configurability; and
o 它们没有提供适当级别的可配置性；和
o they do not provide a way to discriminate between multicast flows based on estimation of their dynamicity.
o 它们没有提供一种基于对多播流动态性的估计来区分多播流的方法。
The procedures defined in [RFC2439] and [RFC7196] for BGP route flap damping are useful for operators who want to control the impact of unicast route churn on the routing infrastructure and offer a standardized set of parameters to control damping.
[RFC2439]和[RFC7196]中定义的BGP路由抖动阻尼程序对于希望控制单播路由抖动对路由基础设施的影响并提供一组标准化参数以控制阻尼的运营商非常有用。
These procedures are not directly relevant in a multicast context for the following reasons:
由于以下原因，这些过程在多播上下文中不直接相关：
o they are not specified for multicast routing protocol in general, and
o 通常，它们不是为多播路由协议指定的，并且
o even in contexts where BGP routes are used to carry multicast routing states (e.g., [RFC6514]), these procedures do not allow the implementation of the principle described in this document; the main reason being that a damped route becomes suppressed while the target behavior would be to keep advertising when damping is triggered on a multicast route.
o 即使在BGP路由用于承载多播路由状态的情况下（例如，[RFC6514]），这些程序也不允许实现本文件中描述的原则；主要原因是阻尼路由被抑制，而目标行为是在多播路由上触发阻尼时保持广告。
However, the set of parameters standardized to control the thresholds of the exponential decay mechanism can be relevantly reused. This is the approach proposed for the procedures described in this document (Section 5). Motivations for doing so are to help the network operator deploy this feature based on consistent configuration parameters and to obtain predictable results without the drawbacks of relying on rate-limiting multicast control protocol exchanges (as is exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as is exposed in Section 4.2).
然而，用于控制指数衰减机制阈值的标准化参数集可以相应地重用。这是针对本文件（第5节）所述程序提出的方法。这样做的动机是帮助网络运营商基于一致的配置参数部署此功能，并获得可预测的结果，而不存在依赖速率限制多播控制协议交换（如第4.1节所示）或使用现有PIM/IGMP定时器（如第4.2节所示）的缺点。
This section describes procedures for multicast state damping satisfying the goals spelled out in Section 1. This section describes procedures for (S,G) states in the PIM-SM protocol [RFC7761]; they apply unchanged for such states created based on multicast group management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream interfaces. The same procedures are applied to (*,G) states in the context of PIM-SM Any-Source Multicast (ASM) groups (damping is not applied to (S,G,Rpt) Prune state).
本节描述了满足第1节所述目标的多播状态阻尼过程。本节描述了PIM-SM协议[RFC7761]中（S，G）状态的程序；对于基于下游接口上的多播组管理协议（IGMP[RFC3376]，MLD[RFC3810]）创建的此类状态，它们的应用不变。相同的过程适用于PIM-SM任何源多播（ASM）组上下文中的（*，G）状态（阻尼不适用于（S，G，Rpt）修剪状态）。
The following notions of [RFC2439] are reused in these procedures:
[RFC2439]的以下概念在这些程序中重复使用：
figure-of-merit: A number reflecting the current estimation of recent past activity of an (S,G) multicast routing state, which increases based on routing events related to this state and decreases between these events following an exponential decay function (see below); the activation or inactivation of damping on the state is based on this number. This number is associated with the upstream state machine for (S,G) and is initialized to a value of zero on state creation.
优值：反映（S，G）多播路由状态最近过去活动的当前估计值的数字，该值根据与该状态相关的路由事件增加，并在指数衰减函数之后在这些事件之间减少（见下文）；状态上阻尼的激活或失活基于此数字。该数字与（S，G）的上游状态机关联，并在状态创建时初始化为零。
exponential decay function: A mathematical function as defined in Section 2.3 of [RFC2439] (ignoring the first paragraph of the section, as it does not apply here).
指数衰减函数：在[RFC2439]第2.3节中定义的数学函数（忽略本节第一段，因为它不适用于此处）。
decay-half-life: The duration used to control how fast the exponential decay of the *figure-of-merit* is; this parameter of the exponential decay function is the time duration during which the *figure-of-merit* will be reduced by half when in the absence of a routing event (configurable parameter).
衰变半衰期：用于控制*优值*指数衰变速度的持续时间；指数衰减函数的此参数是在没有路由事件（可配置参数）的情况下，*优值*将减少一半的持续时间。
cutoff-threshold: The value of the *figure-of-merit* over which damping is applied (configurable parameter).
截止阈值：应用阻尼的*优值*的值（可配置参数）。
reuse-threshold: The value of the *figure-of-merit* under which damping stops being applied (configurable parameter).
重用阈值：停止应用阻尼的*价值系数*的值（可配置参数）。
In addition to these values, a configurable *increment-factor* parameter is introduced that controls by how much the *figure-of-merit* is incremented on multicast state update events.
除了这些值之外，还引入了一个可配置的*increment factor*参数，用于控制在多播状态更新事件中*figure of merit*的增量。
Section 7.3 proposes default and maximum values for the configurable parameters.
第7.3节提出了可配置参数的默认值和最大值。
On reception of updated multicast membership or routing information on a downstream interface I for a given (S,G) state, which results in a change of the state of the PIM downstream state machine (see Section 4.5.3 of [RFC7761]), a router implementing these procedures MUST:
在下游接口I接收到给定（S，G）状态的更新多播成员资格或路由信息时，导致PIM下游状态机的状态发生变化（参见[RFC7761]第4.5.3节），执行这些过程的路由器必须：
o apply procedures of [RFC7761] unchanged, for everything relating to what multicast traffic ends up being sent on downstream interfaces, including interface I
o 将[RFC7761]的过程应用于所有与最终在下游接口（包括接口I）上发送的多播通信有关的内容
o update the *figure-of-merit* following the exponential decay algorithm
o 按照指数衰减算法更新*优值*
o increase the *figure-of-merit* for the (S,G) by the *increment-factor*
o 将（S，G）的*价值系数*增加*增量因子*
o update the damping state for the (S,G) state: damping becomes active on the state if the recomputed *figure-of-merit* is strictly above the configured *cutoff-threshold*:
o 更新（S，G）状态的阻尼状态：如果重新计算的*优值*严格高于配置的*截止阈值*，则该状态的阻尼变为激活状态：
* if damping remains inactive on (S,G) state, update the upstream state machine as usual (as per Section 4.5.7 of [RFC7761]).
* 如果阻尼在（S，G）状态下保持不活动状态，则应像往常一样更新上游状态机（根据[RFC7761]第4.5.7节）。
* if damping becomes active for the (S,G) state:
* 如果阻尼在（S，G）状态下变为激活状态：
+ if the received message has caused the upstream state machine to transition to Joined state, update the upstream state machine for (S,G) applying usual PIM procedures in Section 4.5.7 of [RFC7761] and including sending a PIM Join to the upstream neighbor
+ 如果收到的消息已导致上游状态机转换为联接状态，则应用[RFC7761]第4.5.7节中的常规PIM程序更新（S，G）的上游状态机，包括向上游邻居发送PIM联接
+ if the received message has caused the upstream state machine to transition to NotJoined state, do not update the upstream state machine for (S,G)
+ 如果收到的消息已导致上游状态机转换为NotJoined状态，则不要更新（S，G）的上游状态机
+ hold the upstream state machine in Joined state until the reuse threshold is reached: for the purpose of updating this state machine, events that may result in updating the state based on [RFC7761] SHOULD be ignored until the *reuse-threshold* is reached. The effect is that in the meantime, while PIM Join messages may be sent as refreshes to the upstream neighbor, no PIM Prune message will be sent.
+ 保持上游状态机处于联接状态，直到达到重用阈值：为了更新此状态机，应忽略可能导致基于[RFC7761]更新状态的事件，直到达到*重用阈值*。其效果是，同时，虽然PIM Join消息可以作为刷新发送给上游邻居，但不会发送PIM Prune消息。
* if damping was already active, do not update the upstream state machine for (S,G); the upstream state machine was frozen after processing the previous message.
* 如果阻尼已激活，则不要更新（S，G）的上游状态机；上游状态机在处理上一条消息后被冻结。
Once the *figure-of-merit* for (S,G) damping state decays to a value strictly below the configured *reuse-threshold*, the upstream state machine for (S,G) is recomputed based on states of downstream state machines, eventually leading to a PIM Join or Prune message to be sent to the upstream neighbor.
一旦（S，G）阻尼状态的*优值*衰减到严格低于配置的*重用阈值*的值，则基于下游状态机的状态重新计算（S，G）的上游状态机，最终导致发送到上游邻居的PIM加入或删减消息。
Given the specificity of multicast applications, it is REQUIRED for the implementation to let the operator configure the *decay-half-life* in seconds, rather than in minutes.
鉴于多播应用程序的特殊性，实现需要让操作员在几秒钟内而不是几分钟内配置“衰减半衰期”。
This specification does not impose the use of a particular technique to update the *figure-of-merit* following the exponential decay controlled by the configured *decay-half-life*. For instance, the same techniques as the ones described in [RFC2439] can be applied. The only requirement is that the *figure-of-merit* has to be updated prior to increasing it and that its decay below the *reuse-threshold* has to be reacted upon in a timely manner: in particular, if the recomputation is done with a fixed time granularity, this granularity should be low enough to not significantly delay the inactivation of damping on a multicast state beyond what the operator wanted to configure (e.g., for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state remaining damped for a much longer time than specified).
本规范不强制使用特定技术在配置的*衰变半衰期*控制的指数衰变之后更新*优值*。例如，可以应用与[RFC2439]中描述的技术相同的技术。唯一的要求是，必须在增加*优值*之前对其进行更新，并且必须及时对其在*重用阈值*以下的衰减作出反应：特别是，如果以固定的时间粒度进行重新计算，该粒度应足够低，以使多播状态的阻尼失活不会显著延迟超过操作员想要配置的时间（例如，对于10秒的*衰减半衰期*，每分钟重新计算*优值*将导致多播状态保持阻尼的时间比规定的时间长得多）。
PIM implementations typically follow the suggestion from Section 4.1 of [RFC7761] that:
PIM实施通常遵循[RFC7761]第4.1节的建议：
implementations will only maintain state when it is relevant to forwarding operations - for example, the 'NoInfo' state might be assumed from the lack of other state information, rather than being held explicitly.
实现只会在与转发操作相关时维护状态—例如，“NoInfo”状态可能是由于缺少其他状态信息而假定的，而不是显式保持的。
To properly implement damping procedures, an implementation MUST keep an explicit (S,G) state as long as damping is active on an (S,G). Once an (S,G) state expires, and damping becomes inactive on this state, its associated *figure-of-merit* and damping state are removed as well.
为了正确实施阻尼程序，只要（S，G）上的阻尼处于活动状态，实现就必须保持显式（S，G）状态。一旦（S，G）状态过期，阻尼在此状态下变为非活动状态，其关联的*优值*和阻尼状态也将被删除。
Note that these procedures:
请注意，这些程序：
o do not impact PIM procedures related to refreshes or expiration of multicast routing states: PIM Prune messages triggered by the expiration of the (S,G) keep-alive timer are not suppressed or delayed, and the reception of Join messages not causing transition of state on the downstream interface does not lead to incrementing the *figure-of-merit*;
o 不要影响与多播路由状态刷新或过期相关的PIM过程：由（S，G）保持活动计时器过期触发的PIM Prune消息不会被抑制或延迟，并且不会导致下游接口上状态转换的连接消息的接收不会导致*优值*增加；
o do not impact the PIM Assert mechanism: in particular, PIM Prune messages triggered by a change of the PIM Assert winner on the upstream interface are not suppressed or delayed;
o 不要影响PIM断言机制：特别是，上游接口上的PIM断言赢家更改触发的PIM Prune消息不会被抑制或延迟；
o do not impact PIM Prune messages that are sent when the RPF neighbor is updated for a given multicast flow; and
o 不影响在为给定多播流更新RPF邻居时发送的PIM修剪消息；和
o do not impact PIM Prune messages that are sent in the context of switching between a Rendezvous Point Tree and a Shortest Path Tree.
o 不要影响在集合点树和最短路径树之间切换的上下文中发送的PIM修剪消息。
Note also that no action is triggered based on the reception of PIM Prune messages (or corresponding IGMP/MLD messages) that relate to non-existing (S,G) state: in particular, no *figure-of-merit* or damping state is created in this case.
还请注意，没有基于接收到与不存在（S，G）状态相关的PIM删减消息（或相应的IGMP/MLD消息）而触发任何动作：特别是，在这种情况下，没有创建*优值*或阻尼状态。
The procedures described in Section 5.1 can be applied in the Virtual Routing and Forwarding (VRF) PIM-SM implementation (in the "C-PIM instance"), with the corresponding action to suppressing the emission of a Prune(S,G) message being to not withdraw the C-multicast Source Tree Join (C-S,C-G) BGP route. An implementation of [RFC6513] relying on the use of PIM to carry C-multicast routing information MUST support this technique to be compliant with this specification.
第5.1节中描述的程序可应用于虚拟路由和转发（VRF）PIM-SM实现（在“C-PIM实例”中），抑制剪枝（S，G）消息发射的相应措施是不撤回C-多播源树连接（C-S，C-G）BGP路由。[RFC6513]的实现依赖于PIM的使用来携带C-多播路由信息，必须支持该技术才能符合本规范。
In the context of [RFC6514], where BGP is used to distribute C-multicast routing information, the following procedure is proposed as an alternative to the procedures in Section 5.1 and consists in applying damping in the BGP implementation based on existing BGP damping mechanisms applied to C-multicast Source Tree Join routes and Shared Tree Join routes (and as well to Leaf A-D routes - see Section 6) and modified to implement the behavior described in Section 3 along the following guidelines:
在[RFC6514]的上下文中，其中BGP用于分发C多播路由信息，以下程序作为第5.1节中程序的替代方案，包括基于应用于C-多播源树连接路由和共享树连接路由（以及叶A-D路由-见第6节）的现有BGP阻尼机制，在BGP实现中应用阻尼并根据以下准则进行修改，以实现第3节中描述的行为：
o not withdrawing (instead of not advertising) damped routes;
o 不撤回（而不是不公布）受影响的路线；
o providing means to configure the *decay-half-life* in seconds if that option is not already available; and
o 如果该选项不可用，则提供以秒为单位配置“衰变半衰期”的方法；和
o using parameters for the exponential decay that are specific to multicast based on default values and multicast-specific configuration.
o 基于默认值和多播特定配置，使用多播特定的指数衰减参数。
While these procedures would typically be implemented on PE routers, in a context where BGP Route Reflectors (RRs) [RFC4456] are used it can be considered useful to also be able to apply damping on RRs as well to provide additional protection against activity created behind multiple PEs. Additionally, for MVPN Inter-AS deployments, it can be needed to protect one Autonomous System (AS) from the dynamicity of multicast VPN routing events from other ASes.
虽然这些程序通常会在PE路由器上实施，但在使用BGP路由反射器（RRs）[RFC4456]的情况下，也可以认为能够对RRs施加阻尼以及针对多个PE后面产生的活动提供额外保护是有用的。此外，对于MVPN AS间部署，可能需要保护一个自治系统（AS）免受来自其他AS的多播VPN路由事件的动态影响。
The choice to implement damping based on BGP routes or the procedures described in Section 5.1 is up to the implementor, but at least one of the two MUST be implemented. In the perspective of allowing damping to be done on RRs and Autonomous System Border Routers (ASBRs), implementing the BGP approach is recommended.
根据BGP路由或第5.1节所述程序实施阻尼的选择取决于实施者，但必须至少实施其中一种。从允许在RRs和自治系统边界路由器（ASBR）上进行阻尼的角度来看，建议实施BGP方法。
When not all routers in a deployment have the capability to drop traffic coming from the wrong PE (as spelled out in Section 9.1.1 of [RFC6513]), then the withdrawal of a C-multicast route resulting from a change in the Upstream Multicast Hop or Upstream Multicast PE SHOULD NOT be damped. An implementation of this specification MUST do at least one of the two following things:
当并非部署中的所有路由器都能够丢弃来自错误PE的流量时（如[RFC6513]第9.1.1节所述），则不应抑制由于上游多播跃点或上游多播PE的变化而导致的C多播路由的撤回。本规范的实施必须至少完成以下两项工作之一：
o not damp these withdrawals by default, and/or
o 默认情况下，不会阻止这些提款，和/或
o provide a tuning knob to disable the damping of these withdrawals.
o 提供一个调谐旋钮，以禁用这些抽出的阻尼。
Additionally, in such a deployment context, it is RECOMMENDED not to enable any multicast VPN route damping on RRs and ASBRs since these types of equipment cannot distinguish the event having caused a C-multicast to be withdrawn.
此外，在这种部署环境中，建议不要在RRs和ASBR上启用任何多播VPN路由阻尼，因为这些类型的设备无法区分导致撤销C多播的事件。
Note well that it is out of scope of this section to consider the application of these damping techniques on MVPN BGP routes other than C-multicast routes.
请注意，考虑到这些阻尼技术在除了C组播路由之外的MVPN BGP路由上的应用，超出了本节的范围。
When selective P-tunnels are used (see Section 7 of [RFC6513]), the effect of updating the upstream state machine for a given (C-S,C-G) state on a PE connected to multicast receivers is not only to generate activity to propagate C-multicast routing information to the source connected PE, but also to possibly trigger changes related to the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider network from an excessive amount of change in the state of P-tunnels is required, and this section details how this can be done.
当使用选择性P隧道（参见[RFC6513]第7节）时，在连接到多播接收器的PE上更新给定（C-S，C-G）状态的上游状态机的效果不仅是生成将C-多播路由信息传播到源连接PE的活动，但也可能引发与P隧道承载（C-S，C-G）交通有关的变化。需要保护提供商网络免受P-隧道状态的过度变化，本节详细介绍了如何做到这一点。
A PE implementing these procedures for MVPN MUST damp Leaf A-D routes in the same manner as it would for C-multicast routes (see Section 5.2).
为MVPN实施这些程序的PE必须以与C多播路由相同的方式阻尼叶A-D路由（见第5.2节）。
A PE implementing these procedures for MVPN MUST damp the activity related to removing itself from a P-tunnel. Possible ways to do so depend on the type of P-tunnel, and local implementation details are left up to the implementor.
执行这些MVPN程序的PE必须抑制与从P通道中移除自身相关的活动。可能的方法取决于P-tunnel的类型，本地实现细节由实现者决定。
The following is proposed as an example of how the above can be achieved:
以下是如何实现上述目标的示例：
o For P-tunnels implemented with the PIM protocol, this consists in applying multicast state damping techniques described in Section 5.1 to the P-PIM instance, at least for (S,G) states corresponding to P-tunnels.
o 对于使用PIM协议实现的P-隧道，这包括将第5.1节中描述的多播状态阻尼技术应用于P-PIM实例，至少适用于对应于P-隧道的（S，G）状态。
o For P-tunnels implemented with multipoint LDP (mLDP), this consists in applying damping techniques completely similar to the one described in Section 5 but generalized to apply to mLDP states.
o 对于采用多点LDP（mLDP）实施的P隧道，这包括应用阻尼技术，该技术与第5节中描述的完全相似，但一般适用于mLDP状态。
o For root-initiated P-tunnels (P-tunnels implemented with the Point-to-Multipoint (P2MP) RSVP-TE, or relying on ingress replication), no particular action needs to be implemented to damp P-tunnels membership, if the activity of Leaf A-D route themselves is damped.
o 对于根启动的P-隧道（使用点对多点（P2MP）RSVP-TE实现的P-隧道，或依赖入口复制），如果叶A-D路由本身的活动受到抑制，则无需执行任何特定操作来抑制P-隧道成员资格。
o Another possibility is to base the decision to join or not join the P-tunnel to which a given (C-S,C-G) is bound and to advertise or not advertise a Leaf A-D route related to (C-S,C-G) based on whether or not a C-multicast Source Tree Join route is being advertised for (C-S,C-G) rather than by relying on the state of the C-PIM Upstream state machine for (C-S,C-G).
o 另一种可能性是基于是否正在为（C-S，C-G）播发C-多播源树加入路由来决定加入或不加入与给定（C-S，C-G）绑定的P-隧道，以及播发或不播发与（C-S，C-G）相关的叶a-D路由而不是依赖于（C-S，C-G）的C-PIM上游状态机的状态。
Specifications exist to support or optimize multicast and broadcast in the context of Ethernet VPNs [RFC7117] relying on the use of Selective P-Multicast Service Interface (S-PMSI) and P-tunnels. For the same reasons as for IP multicast VPNs, an implementation of [RFC7117] MUST follow the procedures described in Section 6.1 to be compliant with this specification.
现有规范支持或优化以太网VPN[RFC7117]上下文中的多播和广播，这些规范依赖于选择性P多播服务接口（S-PMSI）和P隧道的使用。出于与IP多播VPN相同的原因，[RFC7117]的实现必须遵循第6.1节中描述的程序，以符合本规范。
In the context of multicast VPNs, these procedures would be enabled on PE routers. Additionally, in the case of C-multicast routing based on BGP extensions ([RFC6514]), these procedures can be enabled on ASBRs and RRs.
在多播VPN的上下文中，这些过程将在PE路由器上启用。此外，在基于BGP扩展（[RFC6514]）的C多播路由的情况下，可以在ASBR和RRs上启用这些过程。
Implementing the damping mechanisms described in this document should be complemented by appropriate tools to observe and troubleshoot damping activity.
实施本文件中所述的阻尼机制应辅以适当的工具，以观察和排除阻尼活动。
Complementing the existing interface providing information on multicast states with information on eventual damping of corresponding states (e.g., Multicast Routing Information Base (MRIB) states) is RECOMMENDED for C-multicast routing states and P-tunnel states.
对于C-多播路由状态和P-隧道状态，建议使用相应状态（例如，多播路由信息库（MRIB）状态）的最终阻尼信息来补充提供多播状态信息的现有接口。
Considering that, by design, multicast streams will be delivered unchanged to the end user independent of the value chosen for the configurable parameters, and that the only trade-off being made is an increase of bandwidth use, the default and maximum values do not have to be perfectly tuned.
考虑到，通过设计，多播流将不受为可配置参数选择的值的影响而发送给最终用户，并且唯一的折衷是增加带宽使用，因此不必对默认值和最大值进行完美调整。
This section proposes default and maximum values that are conservative, so as to not significantly impact network dimensioning but still prevent multicast state churn going beyond what can be
本节提出了保守的默认值和最大值，以便不显著影响网络尺寸，但仍然防止多播状态波动超出可能的范围
considered a reasonably low churn for a multicast state (see below for illustrations in order of magnitude of the effect of these values).
被认为是多播状态的一个合理的低搅动（请参见下面这些值的影响大小顺序的说明）。
The following values are RECOMMENDED to be adopted as default values:
建议采用以下值作为默认值：
o *increment-factor*: 1000
o *increment-factor*: 1000
o *cutoff-threshold*: 3000
o *cutoff-threshold*: 3000
o *decay-half-life*: 10s
o *decay-half-life*: 10s
o *reuse-threshold*: 1500
o *reuse-threshold*: 1500
For unicast damping, it is common to set an upper bound to the time during which a route is suppressed. In the case of multicast state damping, which relies on not withdrawing a damped route, it may be desirable to avoid a situation where a multicast flow would keep flowing in a portion of the network for a very long time in the absence of receivers.
对于单播阻尼，通常为抑制路由的时间设置上限。在依赖于不撤回阻尼路由的多播状态阻尼的情况下，可能希望避免在没有接收机的情况下多播流将在网络的一部分中保持流动很长时间的情况。
The proposed default maximum value for the *figure-of-merit* is 20x*increment-factor*, i.e., 20000 with the proposed default *increment-factor* of 1000.
*价值系数*的建议默认最大值为20倍*增量系数*，即20000，建议默认*增量系数*为1000。
As illustrations, with these values:
如图所示，使用以下值：
o a multicast state updated less frequently than once every 6 s will not be damped at all;
o 如果多播状态更新频率低于每6秒一次，则不会受到任何影响；
o a multicast state changing once per second for 3 s, and then not changing, will not be damped;
o 多播状态每秒改变一次，持续3秒，然后不改变，将不会被抑制；
o a multicast state changing once per second for 4 s, and then not changing, will be damped after the fourth change for approximately 13 s;
o 多播状态每秒改变一次，持续4秒，然后不改变，将在第四次改变后衰减约13秒；
o a multicast state changing twice per second for 15 s, and then not changing, will be damped after the fourth change for approximately 50 s; and
o 多播状态每秒改变两次，持续15秒，然后不改变，将在第四次改变后衰减约50秒；和
o a multicast state changing at a fast pace for a long time will reach the maximum of *figure-of-merit*; once the activity on this state stops, corresponding traffic may still flow in the network for approximately 37 s before dampening stops being active.
o 长时间快速变化的多播状态将达到*优值*的最大值；一旦此状态下的活动停止，相应的流量可能仍会在网络中流动约37秒，然后阻尼停止活动。
The following values are proposed as maximums:
建议将以下值作为最大值：
o *decay-half-life*: 60 s
o *decay-half-life*: 60 s
o *cutoff-threshold*: 50000
o *cutoff-threshold*: 50000
More aggressive protection against the risk of denial of service can be achieved by increasing the *increment-factor* or the *decay-half-life*, or by reducing the *cutoff-threshold* and/or *reuse-threshold*.
通过增加*增量系数*或*衰减半衰期*，或降低*截止阈值*和/或*重用阈值*，可以实现针对拒绝服务风险的更积极的保护。
The procedures defined in this document do not introduce additional security issues not already present in the contexts addressed and actually aim at addressing some of the identified risks without introducing as much denial-of-service risk as some of the mechanisms already defined.
本文档中定义的程序不会引入在所述上下文中尚未出现的其他安全问题，实际上旨在解决一些已识别的风险，而不会引入与已定义的某些机制一样多的拒绝服务风险。
The protection provided relates to the control plane of the multicast routing protocols, including the components implementing the routing protocols and the components responsible for updating the multicast forwarding plane.
所提供的保护涉及多播路由协议的控制平面，包括实现路由协议的组件和负责更新多播转发平面的组件。
The procedures described are meant to provide some level of protection for the router on which they are enabled by reducing the amount of routing state updates that it needs to send to its upstream neighbor or peers but do not provide any reduction of the control-plane load related to processing routing information from downstream neighbors. Protecting routers from an increase in control-plane load due to activity on downstream interfaces toward core routers (or in the context of BGP-based MVPN C-multicast routing, BGP peers) relies on the activation of damping on corresponding downstream neighbors (or BGP peers) and/or at the edge of the network. Protecting routers from an increase in control-plane load due to activity on customer-facing downstream interfaces or downstream interfaces to routers in another administrative domain is out of the scope of this document and should use already defined mechanisms (see [RFC4609]).
所描述的过程旨在通过减少路由器需要发送给其上游邻居或对等方的路由状态更新量，为其启用的路由器提供某种程度的保护，但不提供与处理来自下游邻居的路由信息相关的控制平面负载的任何减少。保护路由器免受由于核心路由器（或在基于BGP的MVPN C多播路由的背景下，BGP对等点）下游接口上的活动而导致的控制平面负载增加，这取决于在相应的下游邻居（或BGP对等点）和/或网络边缘激活阻尼。保护路由器免受因面向客户的下游接口或另一管理域中路由器的下游接口上的活动而增加的控制平面负载的影响不在本文件的范围内，应使用已定义的机制（参见[RFC4609]）。
To be effective, the procedures described here must be complemented by configuration limiting the number of multicast states that can be created on a multicast router through protocol interactions with multicast receivers, neighbor routers in adjacent ASes, or in multicast VPN contexts with multicast CEs. Note well that the two mechanisms may interact: the state for which Prune has been requested may still remain taken into account for some time if damping has been triggered and hence result in an otherwise acceptable new state from being successfully created.
为了有效，必须通过配置来补充此处描述的过程，该配置限制通过与多播接收器、相邻ASE中的邻居路由器或具有多播CE的多播VPN上下文中的协议交互在多播路由器上创建的多播状态的数量。请注意，这两种机制可能相互作用：如果已触发阻尼，则请求修剪的状态可能在一段时间内仍会被考虑，从而导致无法成功创建其他可接受的新状态。
Additionally, it is worth noting that these procedures are not meant to protect against peaks of control-plane load but only address averaged load. For instance, assuming a set of multicast states are submitted to the same Join/Prune events, damping can prevent more than a certain number of Join/Prune messages to be sent upstream in the period of time that elapses between the reception of Join/Prune messages triggering the activation of damping on these states and when damping becomes inactive after decay.
此外，值得注意的是，这些程序不是为了防止控制面载荷峰值，而是仅针对平均载荷。例如，假设一组多播状态提交给相同的加入/删除事件，阻尼可以防止在接收连接/修剪消息触发这些状态上的阻尼激活和阻尼在衰减后变为非活动状态之间的时间段内，向上游发送超过一定数量的连接/修剪消息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 1998, <http://www.rfc-editor.org/info/rfc2439>.
[RFC2439]Villamizar，C.，Chandra，R.和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，DOI 10.17487/RFC2439，1998年11月<http://www.rfc-editor.org/info/rfc2439>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，版本3”，RFC 3376，DOI 10.17487/RFC3376，2002年10月<http://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.，Ed.和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，DOI 10.17487/RFC3810，2004年6月<http://www.rfc-editor.org/info/rfc3810>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<http://www.rfc-editor.org/info/rfc6514>.
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.
[RFC7117]Aggarwal，R.，Ed.，Kamite，Y.，Fang，L.，Rekhter，Y.，和C.Kodeboniya，“虚拟专用局域网服务（VPLS）中的多播”，RFC 7117，DOI 10.17487/RFC71172014年2月<http://www.rfc-editor.org/info/rfc7117>.
[RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, DOI 10.17487/RFC7196, May 2014, <http://www.rfc-editor.org/info/rfc7196>.
[RFC7196]Pelsser，C.，Bush，R.，Patel，K.，Mohapatra，P.，和O.Maennel，“使路线襟翼阻尼可用”，RFC 7196，DOI 10.17487/RFC71962014年5月<http://www.rfc-editor.org/info/rfc7196>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<http://www.rfc-editor.org/info/rfc7761>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.
[RFC4456]Bates，T.，Chen，E.和R.Chandra，“BGP路由反射：全网格内部BGP（IBGP）的替代方案”，RFC 4456，DOI 10.17487/RFC4456，2006年4月<http://www.rfc-editor.org/info/rfc4456>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <http://www.rfc-editor.org/info/rfc4609>.
[RFC4609]Savola，P.，Lehtonen，R.，和D.Meyer，“协议独立多播-稀疏模式（PIM-SM）多播路由安全问题和增强”，RFC 4609，DOI 10.17487/RFC4609，2006年10月<http://www.rfc-editor.org/info/rfc4609>.
Acknowledgements
致谢
We would like to thank Bruno Decraene and Lenny Giuliano for discussions that helped shape this proposal. We would also like to thank Yakov Rekhter and Eric Rosen for their reviews and helpful comments. Thanks to Wim Henderickx for his comments and support of this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde, and Alvaro Retana provided useful comments to finalize the document.
我们要感谢布鲁诺·德雷恩和莱尼·朱利亚诺的讨论，这些讨论帮助形成了这项提案。我们还要感谢亚科夫·雷克特和埃里克·罗森的评论和有益的评论。感谢Wim Henderickx对本提案的评论和支持。此外，Martin Vigoureux、Gunter Van De Velde和Alvaro Retana为文件定稿提供了有用的意见。
Authors' Addresses
作者地址
Thomas Morin (editor) Orange 2, avenue Pierre Marzin Lannion 22307 France
托马斯·莫林（编辑）法国皮埃尔·马津·拉尼翁大街橙色2号22307
Email: thomas.morin@orange.com
Email: thomas.morin@orange.com
Stephane Litkowski Orange France
斯特凡利特科夫斯基橙法国
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞市塔斯曼大道西170号，邮编95134
Email: keyupate@cisco.com
Email: keyupate@cisco.com
Zhaohui Zhang Juniper Networks Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号张昭辉Juniper Networks Inc.01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net
Robert Kebler Juniper Networks Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Robert Kebler Juniper Networks Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: rkebler@juniper.net
Email: rkebler@juniper.net
Jeffrey Haas Juniper Networks
Jeffrey Haas Juniper网络
Email: jhaas@juniper.net
Email: jhaas@juniper.net