[要約] RFC 7899は、マルチキャストVPNの状態のダンピングに関する規格です。その目的は、ネットワークの安定性を向上させ、リソースの効率的な利用を促進することです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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サイトの受信者が、マルチキャストメンバーシップ制御プロトコル（インターネットグループ管理プロトコル（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トンネルセットアップコントロールプレーンにかかる負荷が、エンドホストによってマルチキャストメンバーシップの変更が行われる頻度に関係なく制御されたままになるように、メカニズムを配置する必要があります。
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.
このドキュメントでは、MVPNコントロールプレーンプロトコルの処理量に上限を設定する手段を提供することを目的とした既存のBGPルートダンピング[RFC2439]に触発された手順について説明します。より正確には、[RFC6514]のBGPコントロールプレーン、 [RFC6514]のコンテキストでのPトンネルコントロールプレーンプロトコル、およびVPLSのマルチキャスト仕様[RFC7117]。この上限の設定の目標は、プロバイダーネットワークでの平均帯域幅の使用の増加を最小限に抑えながら、提供されたサービスを維持する（Customer Edgeデバイスの要求に応じてマルチキャストストリームを配信する）目標と同時に達成されます。特定のマルチキャスト状態の処理によるコントロールプレーンの負荷の上限は、構成可能なパラメーターを介して間接的に制御されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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 PE（プロバイダーエッジルーター）を構成できるため、特定の構成可能なしきい値を超えるマルチキャストステートダイナミックスの速度に直面した場合に、PE間のマルチキャストステートプルーンメッセージの伝播を遅延させることができます。レシーバーが作成できるマルチキャストステートの数が制限されていると仮定すると、マルチキャストステートプルーニングの伝播を遅らせると、ルーターが上流のルーターにステートアップデートを送信する平均頻度に上限が設定されます。
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に要求するマルチキャストルーティングステートの変更は、追加の遅延なしに適用されます。実際、Joinの伝播は、ここで指定された手順の影響を受けません。また、アップストリームルータに自身のアップストリームルータへの伝播状態をプルーニングしても、ダウンストリームルータに送信されるトラフィックには影響しません。特に、この減衰技術を適用する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秒あたり1つのイベントよりも高い頻度で発生するダンピングイベントは、マルチキャストフローがリンク上に存在する時間を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.
Protocol Independent Multicast-Sparse Mode（PIM-SM）仕様[RFC7761]は、マルチキャストセキュリティの脅威と、特にセクション1で説明されているサービス拒否攻撃のリスクを調べます。レート制限PIMメッセージに依存するメカニズムは、 [RFC4609]のセクション5.3.3で提案されていますが、提供されるサービスに影響を与え、正当なユーザーに副作用をもたらすという特定の欠点があります。
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 特定の実装では、これらのメカニズムはオフにできない動作と互換性がありません（たとえば、2つのネイバーしか持たないインターフェースに高速脱退動作を適用する実装）。
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 Any-Source Multicast（ASM）グループのコンテキストで（*、G）状態に適用されます（ダンピングは（S、G、Rpt）Prune状態には適用されません）。
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).
decay-half-life：* figure-of-merit *の指数関数的減衰の速度を制御するために使用される期間。指数関数的減衰関数のこのパラメーターは、ルーティングイベントがない場合（構成可能なパラメーター）、* figure-of-merit *が半分に削減される期間です。
cutoff-threshold: The value of the *figure-of-merit* over which damping is applied (configurable parameter).
cutoff-threshold：ダンピングが適用される* figure-of-merit *の値（構成可能なパラメーター）。
reuse-threshold: The value of the *figure-of-merit* under which damping stops being applied (configurable parameter).
再利用しきい値：ダンピングが適用されなくなる* figure-of-merit *の値（構成可能なパラメーター）。
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:
特定の（S、G）状態のダウンストリームインターフェイスIで更新されたマルチキャストメンバーシップまたはルーティング情報を受信すると、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 指数減衰アルゴリズムに従って* figure-of-merit *を更新する
o increase the *figure-of-merit* for the (S,G) by the *increment-factor*
o （S、G）の* figure-of-merit *を* increment-factor *だけ増やします
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）状態のダンピング状態を更新します。再計算された* figure-of-merit *が構成された*カットオフしきい値*を厳密に上回っている場合、ダンピング状態がアクティブになります。
* 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
+ 受信したメッセージによってアップストリームステートマシンがJoined状態に移行した場合は、[S、G）のアップストリームステートマシンを更新して、[RFC7761]のセクション4.5.7の通常のPIM手順を適用し、PIM Joinをアップストリームネイバーに送信する
+ 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]に基づいて状態を更新する可能性のあるイベントは、* reuse-threshold *に達するまで無視する必要があります。その間、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）減衰状態の* figure-of-merit *が構成された* reuse-threshold *を完全に下回る値に減衰すると、（S、G）の上流状態マシンが下流状態マシンの状態に基づいて再計算されます、最終的にはPIM JoinまたはPruneメッセージが上流のネイバーに送信されます。
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).
この仕様は、構成された* decay-half-life *によって制御される指数関数的減衰に続いて* figure-of-merit *を更新する特定の手法の使用を強制しません。たとえば、[RFC2439]で説明されている手法と同じ手法を適用できます。唯一の要件は、* figure-of-merit *を増加する前に更新する必要があり、* reuse-threshold *を下回る減衰にタイムリーに対応する必要があることです。特に、再計算が行われた場合固定時間の細分性では、この細分性は、オペレーターが構成したいものを超えてマルチキャスト状態での減衰の非アクティブ化を大幅に遅らせないように十分に低くする必要があります（たとえば、*減衰半減期が10秒の場合、*図を再計算します） -of-merit *の場合、毎分、マルチキャストの状態は、指定された時間よりもはるかに長い時間減衰したままになります。
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）状態が期限切れになり、ダンピングがこの状態で非アクティブになると、それに関連する* figure-of-merit *とダンピング状態も削除されます。
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メッセージは抑制または遅延されず、Joinメッセージの受信によって状態が遷移しないダウンストリームインターフェイスでは、* figure-of-merit *の増加にはつながりません。
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 Pruneメッセージには影響しません。そして
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 Pruneメッセージには影響しません。
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 Pruneメッセージ（または対応するIGMP / MLDメッセージ）の受信に基づいてアクションがトリガーされないことにも注意してください。特に、* figure-of-merit *またはダンピング状態はありません。この場合は作成されます。
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インスタンス」内）に適用でき、対応するアクションにより、Prune（S、G）メッセージの送信を抑制します。 Cマルチキャストソースツリー参加（CS、CG）BGPルートを撤回しないこと。 Cマルチキャストルーティング情報を伝送するためにPIMの使用に依存する[RFC6513]の実装は、この技術がこの仕様に準拠するようにサポートする必要があります。
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の手順の代替として提案され、適用される既存のBGPダンピングメカニズムに基づいてBGP実装にダンピングを適用します。 Cマルチキャストソースツリー結合ルートおよび共有ツリー結合ルート（およびリーフADルート-セクション6を参照）に変換され、セクション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 そのオプションがまだ利用できない場合、* decay-half-life *を秒単位で構成する手段を提供します。そして
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ルートリフレクター（RR）[RFC4456]が使用されているコンテキストでは、RRにダンピングを適用できることや、背後で作成されたアクティビティに対する追加の保護を提供できることも有用であると考えられます複数のPE。さらに、MVPN Inter-AS展開では、他のASからのマルチキャストVPNルーティングイベントの動的性から1つの自律システム（AS）を保護する必要がある場合があります。
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で説明されている手順に基づいてダンピングを実装する選択は、実装者次第ですが、2つのうち少なくとも1つを実装する必要があります。 RRおよび自律システムボーダールーター（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に記載）、アップストリームマルチキャストの変更に起因するCマルチキャストルートの撤回ホップまたはアップストリームマルチキャストPEを減衰させないでください。この仕様の実装は、次の2つのうち少なくとも1つを実行する必要があります。
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.
さらに、そのような配置コンテキストでは、RRと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で特定の（CS、CG）状態のアップストリームステートマシンを更新することの効果は、Cを伝播するアクティビティを生成するだけではありません-ソースに接続されたPEへのルーティング情報をマルチキャストするだけでなく、（CS、CG）トラフィックを運ぶPトンネルに関連する変更をトリガーする可能性もあります。 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トンネルのタイプによって異なり、ローカル実装の詳細は実装者に任されています。
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トンネルの場合、これは、少なくともPトンネルに対応する（S、G）状態に対して、セクション5.1で説明されているマルチキャスト状態減衰技術をP-PIMインスタンスに適用することです。
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トンネル、または入力レプリケーションに依存）の場合、アクティビティがPトンネルメンバーシップをダンプするために特定のアクションを実装する必要はありません。 Leaf ADルート自体の減衰。
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 別の可能性は、特定の（CS、CG）がバインドされているPトンネルに参加するかどうかに基づいて決定し、（CS、CG）に関連するリーフADルートをアドバタイズするかどうかに基づいて、 （CS、CG）のC-PIMアップストリームステートマシンの状態に依存するのではなく、（CS、CG）のCマルチキャストソースツリー結合ルートがアドバタイズされています。
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.
仕様は、選択的Pマルチキャストサービスインターフェイス（S-PMSI）およびPトンネルの使用に依存するイーサネットVPN [RFC7117]のコンテキストでマルチキャストおよびブロードキャストをサポートまたは最適化するために存在します。 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およびRRで有効にできます。
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.
マルチキャスト状態に関する情報を提供する既存のインターフェースを、対応する状態の最終的な減衰に関する情報（たとえば、マルチキャストルーティング情報ベース（MRIB）状態）で補完することは、Cマルチキャストルーティング状態とPトンネル状態に推奨されます。
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 *cutoff-threshold*: 3000
o *decay-half-life*: 10s
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.
* figure-of-merit *の提案されたデフォルトの最大値は20x * increment-factor *です。つまり、提案されたデフォルトの* increment-factor *が20000の20000です。
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秒に1回よりも少ない頻度で更新されるマルチキャスト状態は、まったく減衰されません。
o a multicast state changing once per second for 3 s, and then not changing, will not be damped;
o 1秒に1秒間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 毎秒1回4秒間変化し、その後変化しないマルチキャスト状態は、約13秒間4番目の変化後に減衰します。
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 1秒に2回15秒間変化し、その後変化しないマルチキャスト状態は、4番目の変化の後に約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 マルチキャストの状態が速いペースで長時間変化する場合、* figure-of-merit *の最大値に達します。この状態のアクティビティが停止すると、ダンプニングのアクティブが停止する前に、対応するトラフィックが約37秒間ネットワークに流れ続ける可能性があります。
The following values are proposed as maximums:
以下の値が最大値として提案されています。
o *decay-half-life*: 60 s
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*.
* increment-factor *または* decay-half-life *を増やすか、* cutoff-threshold *または* 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.
効果的にするには、ここで説明する手順は、マルチキャストレシーバー、隣接AS内のネイバールータ、またはマルチキャストCEを使用するマルチキャストVPNコンテキストとのプロトコル相互作用を通じてマルチキャストルータ上に作成できるマルチキャストステートの数を制限する構成によって補完する必要があります。 2つのメカニズムが相互に作用する可能性があることに注意してください。ダンピングがトリガーされた場合、プルーンが要求された状態がしばらく考慮されたままになり、それにより、受け入れられる新しい状態が正常に作成されなくなります。
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.
さらに、これらの手順はコントロールプレーンの負荷のピークに対する保護を意図したものではなく、平均化された負荷に対処することのみを目的としています。たとえば、一連のマルチキャスト状態が同じJoin / Pruneイベントに送信されると仮定すると、ダンピングにより、Join / Pruneの受信から次の受信までの間に、一定数以上のJoin / Pruneメッセージが上流に送信されるのを防ぐことができます。これらの状態で減衰のアクティブ化をトリガーするメッセージ、および減衰後に減衰が非アクティブになるときのメッセージ。
[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 Route Flap Damping」、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.コスタ編、「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]ローゼン、E、エド。およびR. Aggarwal編、「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、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、DOI 10.17487 / RFC7117 、2014年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、「Making Route Flap Damping Usable」、RFC 7196、DOI 10.17487 / RFC7196、2014年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、「Protocol Independent Multicast-Sparse Mode（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]ベイツ、T。、チェン、E。、およびR.チャンドラ、「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、「Protocol Independent Multicast-Sparse Mode（PIM-SM）Multicast Routing Security Issues and Enhancements」、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.
この提案を形作るのに役立つ議論をしてくれたBruno DecraeneとLenny Giulianoに感謝します。また、Yakov RekhterとEric Rosenのレビューと役立つコメントにも感謝します。この提案に対するコメントとサポートを提供してくれた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 Stephane Litkowski Orange France
メール：thomas.morin@orange.comステファンリトコウスキーオレンジフランス
Email: stephane.litkowski@orange.com
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: keyupate@cisco.com
Zhaohui Zhang Juniper Networks Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Zhaohui Zhang Juniper Networks Inc. 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
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 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: rkebler@juniper.net
Jeffrey Haas Juniper Networks
ジェフリー・ハース・ジュニパーネットワークス
Email: jhaas@juniper.net