Network Working Group T. Morin, Ed.
Request for Comments: 4834 France Telecom R&D
Category: Informational April 2007
Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
レイヤでのマルチキャストのための要件3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.
この文書では、レイヤ3（L3）プロバイダ、プロビジョニングされた仮想プライベートネットワーク（PPVPNs）内のIPマルチキャストの展開を許可するネットワークソリューションのための機能要件のセットを提示します。これは、エンドユーザとサービス提供者の立場からの両方の要件を指定します。このようなVPNの内のIPマルチキャストのサポートを指定する潜在的な解決策は、ガイドラインとしてこれらの要件を使用することが意図されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7
3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9
4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10
4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10
4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11
4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11
4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11
4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12
4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12
4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12
4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13
4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13
5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13
5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13
5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13
5.1.2. CE-PE Multicast Routing and Group Management
Protocols . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14
5.1.4. Operations and Management . . . . . . . . . . . . . . 15
5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16
5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18
5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18
5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19
5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20
5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21
5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21
5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23
5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24
5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26
5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26
5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27
5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27
5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28
5.2.10. Operation, Administration, and Maintenance . . . . . . 28
5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Virtual Private Network (VPN) services satisfying the requirements defined in [RFC4031] are now being offered by many service providers throughout the world. VPN services are popular because customers need not be aware of the VPN technologies deployed in the provider network. They scale well for the following reasons:
[RFC4031]で定義された要件を満たす仮想プライベートネットワーク（VPN）サービスは現在、世界中の多くのサービスプロバイダーによって提供されています。顧客は、プロバイダのネットワークに配備VPN技術を意識する必要はありませんので、VPNサービスが普及しています。彼らは、次の理由でうまくスケール：
o because P routers (Provider Routers) need not be aware of VPN service details
O Pルータ（プロバイダールータ）がVPNサービスの詳細を意識する必要がないので、
o because the addition of a new VPN member requires only limited configuration effort
新しいVPNメンバーの追加は、限られたコンフィギュレーションの労力を必要とするため、O
There is also a growing need for support of IP multicast-based services. Efforts to provide efficient IP multicast routing protocols and multicast group management have been made in standardization bodies which has led, in particular, to the definition of Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP).
IPマルチキャストベースのサービスをサポートするためのニーズの高まりもあります。効率的なIPマルチキャストルーティングプロトコルおよびマルチキャストグループ管理を提供するための努力は、Protocol Independent Multicast（PIM）とインターネットグループ管理プロトコル（IGMP）の定義に、特に、つながっている標準化機関で行われています。
However, multicast traffic is not natively supported within existing L3 PPVPN solutions. Deploying multicast over an L3VPN today, with only currently standardized solutions, requires designing customized solutions which will be inherently limited in terms of scalability, operational efficiency, and bandwidth usage.
しかし、マルチキャストトラフィックはネイティブに、既存のL3 PPVPNソリューション内でサポートされていません。唯一、現在標準化されたソリューションとL3VPNの上にマルチキャスト今日、展開、本質的に拡張性、運用効率、および帯域幅の使用に関して制限されるカスタマイズされたソリューションを設計する必要があり。
This document complements the generic L3VPN requirements [RFC4031] document, by specifying additional requirements specific to the deployment within PPVPNs of services based on IP multicast. It clarifies the needs of both VPN clients and providers and formulates the problems that should be addressed by technical solutions with the key objective being to remain solution agnostic. There is no intent in this document to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim at expressing multicast-related requirements that are not specific to L3 PPVPNs.
この文書では、IPマルチキャストに基づいてサービスのPPVPNs内の展開に特有の追加要件を指定することで、一般的なL3VPN要件[RFC4031]文書を補完します。これは、VPNクライアントとプロバイダーの両方のニーズを明確にし、主要な目的は、ソリューションにとらわれないままにすることで技術的な解決策で対処すべき問題を定式化します。ソリューション固有の詳細情報や、アプリケーション固有の要件のいずれかを指定するには、この文書の意図はありません。また、この文書は、L3 PPVPNsに固有のものではありませんマルチキャスト関連の要件を表現することを目指しません。
It is expected that solutions that specify procedures and protocol extensions for multicast in L3 PPVPNs SHOULD satisfy these requirements.
L3 PPVPNsにおけるマルチキャストのための手順やプロトコル拡張を指定するソリューションは、これらの要件を満たすべきであることが期待されます。
Although the reader is assumed to be familiar with the terminology defined in [RFC4031], [RFC4364], [RFC4601], and [RFC4607], the following glossary of terms may be worthwhile.
読者は、[RFC4364]、[RFC4601]及び[RFC4607]、[RFC4031]で定義された用語に精通していることを想定しているが、以下の用語の用語集は、価値があるかもしれ。
We also propose here generic terms for concepts that naturally appear when multicast in VPNs is discussed.
また、ここでのVPNにおけるマルチキャストが議論されたときに自然に現れる概念のための一般的な用語を提案します。
ASM: Any Source Multicast. One of the two multicast service models, in which a terminal subscribes to a multicast group to receive data sent to the group by any source.
ASM：任意のソースマルチキャスト。端末は、任意のソースによってグループに送信されたデータを受信するためにマルチキャストグループに加入している2つのマルチキャストサービスモデルの一つ、。
Multicast-enabled VPN, multicast VPN, or mVPN: A VPN that supports IP multicast capabilities, i.e., for which some PE devices (if not all) are multicast-enabled and whose core architecture supports multicast VPN routing and forwarding.
マルチキャスト対応VPN、マルチキャストVPN、またはMVPN：いくつかのPEデバイス（全てではない）がマルチキャスト対応であり、そのコアアーキテクチャマルチキャストVPNルーティングおよび転送をサポートするためのIPマルチキャスト機能、すなわち、サポートVPN。
PPVPN: Provider-Provisioned Virtual Private Network.
PPVPN：プロバイダ・プロビジョニングされた仮想プライベートネットワーク。
PE, CE: "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As suggested in [RFC4026], we will use these notations to refer to the equipments/routers/devices themselves. Thus, "PE" will refer to the router on the provider's edge, which faces the "CE", the router on the customer's edge.
PE、CE： "プロバイダエッジ"、 "顧客エッジ"（[RFC4026]で定義されるように）。 [RFC4026]で示唆したように、我々は機器/ルータ/デバイス自体を参照するためにこれらの表記を使用します。したがって、「PE」「CE」、顧客のエッジ上のルータと対向プロバイダのエッジ上のルータを参照します。
VRF or VR: By these terms, we refer to the entity defined in a PE dedicated to a specific VPN instance. "VRF" refers to "VPN Routing and Forwarding table" as defined in [RFC4364], and "VR" to "Virtual Router" as defined in [VRs] terminology.
VRFかVRは：これらの用語によって、我々は特定のVPNインスタンスに専用のPEに定義されたエンティティを参照してください。 「VRF」は、[仮想ルーター]用語で定義される「仮想ルータ」に[RFC4364]で定義されるように、「VPNルーティングおよび転送テーブル」を参照し、「VR」。
MDTunnel: Multicast Distribution Tunnel. The means by which the customer's multicast traffic will be transported across the SP network. This is meant in a generic way: such tunnels can be either point-to-point or point-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, the wording also encompasses bidirectional tunnels.
MDTunnel：マルチキャスト配信トンネル。顧客のマルチキャストトラフィックは、SPネットワークを横切って輸送されるための手段。そのようなトンネルは、ポイントツーポイントまたはポイントツーマルチポイントのいずれかになります。これは、一般的な方法で意味しています。この定義は配布トンネルが単方向であることを前提としているように見えるかもしれないが、言葉遣いも双方向のトンネルを含みます。
S: Denotes a multicast source.
Sは：マルチキャストソースを示します。
G: Denotes a multicast group.
G：マルチキャストグループを示します。
Multicast channel: In the multicast SSM model [RFC4607], a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(S,G)".
マルチキャストチャネル：マルチキャストSSMモデル[RFC4607]で、「マルチキャストチャネル」はまた、「（S、G）」と命名マルチキャストグループGに特定のソースSからのトラフィックを指定します。
SP: Service provider.
SP：サービスプロバイダ。
SSM: Source Specific Multicast. One of the two multicast service models, where a terminal subscribes to a multicast group to receive data sent to the group by a specific source.
SSM：ソース固有マルチキャスト。端末は、特定のソースによってグループに送信されたデータを受信するためにマルチキャストグループに加入する2つのマルチキャストサービスモデルの一つ。
RP: Rendezvous Point (Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]).
RP：ランデブーポイント（プロトコル独立マルチキャスト - スパースモード（PIM-SM）[RFC4601]）。
P2MP, MP2MP: Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees.
P2MP、MP2MP：指定「ポイントツーマルチポイント」と「多対多」のレプリケーションの木。
L3VPN, VPN: Throughout this document, "L3VPN" or even just "VPN" will refer to "Provider-Provisioned Layer 3 Virtual Private Network" (PP L3VPNs), and will be preferred for readability.
L3VPN、VPN：このドキュメントでは、「L3VPN」あるいは単に「VPN」は、「プロバイダ・プロビジョニングのレイヤ3仮想プライベートネットワーク」（PP L3VPNs）を参照し、読みやすくするために好ましいであろう。
Please refer to [RFC4026] for details about terminology specifically relevant to VPN aspects, and to [RFC2432] for multicast performance or quality of service (QoS)-related terms.
用語 - 関連マルチキャスト性能やサービス品質（QoS）のために特にVPNの側面に関連して、[RFC2432]への用語の詳細については、[RFC4026]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
More and more L3VPN customers use IP multicast services within their private infrastructures. Naturally, they want to extend these multicast services to remote sites that are connected via a VPN.
より多くのL3VPNのお客様は、プライベートインフラストラクチャ内のIPマルチキャストサービスを使用しています。当然のことながら、彼らは、VPNを介して接続されているリモートサイトにこれらのマルチキャストサービスを拡張したいです。
For instance, the customer could be a national TV channel with several geographical locations that wants to broadcast a TV program from a central point to several regional locations within its VPN.
例えば、顧客がそのVPN内のいくつかの地域の場所に中心点からテレビ番組を放送したいいくつかの地理的な位置での全国放送のテレビチャンネルである可能性があります。
A solution to support multicast traffic could consist of point-to-point tunnels across the provider network and requires the PEs (Provider Edge routers) to replicate traffic. This would obviously be sub-optimal as it would place the replication burden on the PE and hence would have very poor scaling characteristics. It would also probably waste bandwidth and control plane resources in the provider's network.
マルチキャストトラフィックをサポートするためのソリューションは、プロバイダのネットワークを介してポイントツーポイントトンネルで構成され、トラフィックを複製するためのPE（プロバイダーエッジルータ）が必要でした。それはPE上の複製負担をかけることになるので、非常に貧しいスケーリング特性を持つことになり、これは明らかに次善のだろう。また、おそらくプロバイダのネットワークで帯域幅および制御プレーン資源を浪費することになります。
Thus, to provide multicast services for L3VPN networks in an efficient manner (that is, with a scalable impact on signaling and protocol state as well as bandwidth usage), in a large-scale environment, new mechanisms are required to enhance existing L3VPN solutions for proper support of multicast-based services.
したがって、効率的な方法でL3VPNネットワーク（すなわち、シグナリング及びプロトコル状態にスケーラブルな影響並びに帯域幅の使用と、である）のマルチキャストサービスを提供するために、大規模な環境で、新たなメカニズムが用の既存のL3VPNソリューションを向上させるために必要とされますマルチキャストベースのサービスの適切なサポート。
This document sets out requirements for L3 provider-provisioned VPN solutions designed to carry customers' multicast traffic. The main requirement is that a solution SHOULD first satisfy the requirements documented in [RFC4031]: as far as possible, a multicast service should have the same characteristics as the unicast equivalent, including the same simplicity (technology unaware), the same quality of service (if any), the same management (e.g., performance monitoring), etc.
この文書では、顧客のマルチキャストトラフィックを運ぶために設計されたL3プロバイダープロビジョニングVPNソリューションのための要件を定めています。可能な限り、マルチキャストサービスは、同じ単純（技術気づかない）、同じサービス品質を含むユニキャスト等価と同じ特性を有するべきである：主な要件は、溶液が最初の[RFC4031]に記載の要件を満たさなければならないということです（もしあれば）、同じ管理（例えば、パフォーマンス監視）、など
Moreover, it also has to be clear that a multicast VPN solution MUST interoperate seamlessly with current unicast VPN solutions. It would also make sense that multicast VPN solutions define themselves as extensions to existing L3 provider-provisioned VPN solutions (such as for instance, [RFC4364] or [VRs]) and retain consistency with those, although this is not a core requirement.
さらに、それはまた、マルチキャストVPNソリューションは、現在のユニキャストVPNソリューションとシームレスに相互運用しなければならないことが明らかでなければなりません。それはまた、マルチキャストVPNソリューションは、既存のL3プロバイダプロビジョニングVPNソリューションへの拡張として自分自身を定義することは意味をなす（そのような場合については、[RFC4364]または[仮想ルーター]）、これは、コアの要件ではないが、それらとの整合性を保持するであろう。
The requirements in this document are equally applicable to IPv4 and IPv6, for both customer- and provider-related matters.
この文書の要件はcustomer-とプロバイダに関する事項の両方のために、IPv4とIPv6にも同様に適用可能です。
When transporting multicast VPN traffic over a service provider network, there intrinsically is tension between scalability and resource optimization, since the latter is likely to require the maintenance of control plane states related to replication trees in the core network [RFC3353].
サービス・プロバイダ・ネットワーク上のマルチキャストVPNトラフィックを輸送する場合、後者は、コアネットワーク[RFC3353]にツリーを複製に関連する制御プレーン状態の維持を必要とする可能性があるため、本質的に、スケーラビリティとリソース最適化の間に緊張があります。
Consequently, any deployment will require a trade-off to be made. This document will express some requirements related to this trade-off.
その結果、いずれの展開がなされるトレードオフが必要になります。この文書では、このトレードオフに関連するいくつかの要件を表現します。
The goal of this section is to highlight how different applications and network contexts may have a different impact on how a multicast VPN solution is designed, deployed, and tuned. For this purpose, we describe some typical use case scenarios and express expectations in terms of deployment orders of magnitude.
このセクションの目的は、マルチキャストVPNソリューションの設計、展開、およびチューニングされているどのように異なる影響を与える可能性がどのように異なるアプリケーションやネットワークのコンテキスト強調することです。この目的のために、我々は大きさの展開順序の面でいくつかの典型的なユースケースシナリオと急行の期待を述べます。
Most of the content of these sections originates from a survey done in summer 2005, among institutions and providers that expect to deploy such solutions. The full survey text and raw results (13 responses) were published separately, and we only present here the most relevant facts and expectations that the survey exposed.
これらのセクションの内容のほとんどは、このようなソリューションを展開することを期待機関やプロバイダ間、2005年夏に行わ調査に由来します。フル調査テキストと生の結果（13回答）は、別途公表され、私たちはここでしか調査が露出し、最も関連する事実と期待を提示しました。
For scalability figures, we considered that it was relevant to highlight the highest expectations, those that are expected to have the greatest impact on solution design. For balance, we do also mention cases where such high expectations were expressed in only a few answers.
スケーラビリティの数字のために、我々は最高の期待、ソリューション設計に大きな影響を持つことが期待されているものを強調するために、関連すると考えました。バランスのために、我々はまた、このような高い期待がわずか数の答えで発現させた例を言及します。
We don't provide here an exhaustive set of scenarios that a multicast VPN solution is expected to support -- no solution should restrict the scope of multicast applications and deployments that can be done over a multicast VPN.
何の解決策は、マルチキャストVPNを介して行うことができマルチキャストアプリケーションと展開の範囲を制限するべきではない - 私たちはここで、マルチキャストVPNソリューションをサポートすることが期待されているシナリオの網羅セットを提供していません。
Hence, we only give here a short list of scenarios that are expected to have a large impact on the design of a multicast VPN solution.
したがって、我々はここでしかマルチキャストVPNソリューションの設計に大きな影響を与えると予想されるシナリオの短いリストを与えます。
Under this label, we group all applications that distribute content (audio, video, or other content) with the property that this content is expected to be consulted at once ("live") by the receiver. Typical applications are broadcast TV, production studio connectivity, and distribution of market data feeds.
このラベルの下で、我々のグループ受信機によるこのコンテンツを一度に相談されることが期待される性質（「ライブ」）とコンテンツ（オーディオ、ビデオ、またはその他のコンテンツ）を配信するすべてのアプリケーション。代表的なアプリケーションには、テレビ、制作スタジオの接続性、および市場データフィードの配信を放送しています。
The characteristics of such applications are the following:
このようなアプリケーションの特性は以下のとおりです。
o one or few sources to many receivers
多くの受信機へ1つのまたは少数のソースO
o sources are often in known locations; receivers are in less predictable locations (this latter point may depend on applications)
O源は、既知の場所であることが多いです。受信機は、（この後者の点は、アプリケーションに依存してもよい）より少ない予測可能な場所にあります
o in some cases, it is expected that the regularity of audience patterns may help improve how the bandwidth/state trade-off is handled
Oいくつかのケースでは、観客パターンの規則性は、帯域幅/状態トレードオフの処理方法を改善に役立つことが期待されます
o the number of streams can be as high as hundreds, or even thousands, of streams
Oストリームの数は、ストリームの数百、あるいは数千、と高くすることができます
o bandwidth will depend on the application, but may vary between a few tens/hundreds of Kb/s (e.g., audio or low-quality video media) and tens of Mb/s (high-quality video), with some demanding professional applications requiring as much as hundreds of Mb/s.
O帯域幅は、アプリケーションに依存しますが、KB /秒の数十/数百（例えば、オーディオまたは低品質のビデオメディア）との間で数十メガビット/秒（高品質のビデオ）の異なる場合があり、いくつかの厳しいプロフェッショナルアプリケーションとMb /秒の何百もの限りを必要とします。
o QoS requirements include, in many cases, a low multicast group join delay
QoS要件には、O、多くの場合、低マルチキャストグループは、遅延に参加します
o QoS of these applications is likely to be impacted by packet loss (some applications may be robust to low packet loss) and to have low robustness against jitter
OこれらのアプリケーションのQoSは、パケットロスの影響を受けれる可能性がある（一部のアプリケーションでは、低パケット損失に対して頑強でもよい）とジッタに対する低堅牢性を持っています
o delay sensitivity will depend on the application: some applications are not so delay sensitive (e.g., broadcast TV), whereas others may require very low delay (professional studio applications)
O用途に依存する感度を遅らせる：他の人が非常に低遅延を必要とする場合がある一部のアプリケーションは、そう、遅延に敏感（例えば、放送TV）されていません（プロのスタジオ・アプリケーション）
o some of these applications may involve rapid changes in customer multicast memberships as seen by the PE, but this will depend on audience patterns and on the amount of provider equipments deployed close to VPN customers
O PEで見られるように、これらのアプリケーションのいくつかは、顧客のマルチキャストメンバーシップの急激な変化を伴うことが、これは観客のパターンに近いとVPNの顧客に展開され、プロバイダの機器の量に依存します
Some use cases exposed by the survey can be grouped under this label, and include many-to-many applications such as conferencing and server cluster monitoring.
調査によって公開されたいくつかのユースケースは、このラベルの下にグループ化、および多対多な会議や、サーバークラスタの監視などのアプリケーションを含めることができます。
They are characterized by the relatively high number of streams that they can produce, which has a direct impact on scalability expectations.
これらは、スケーラビリティの期待に直接影響を与え、彼らが生成することができるストリームの比較的高い数、によって特徴付けられます。
A sub-case of this scenario is the case of symmetric applications with small groups, when the number of receivers is low compared to the number of sites in the VPNs (e.g., video conferencing and e-learning applications).
受信機の数は、VPNの中の部位の数（例えば、ビデオ会議、eラーニング・アプリケーション）と比較して低い場合、このシナリオのサブケースは、小グループ対称アプリケーションの場合です。
This latter case is expected to be an important input to solution design, since it may significantly impact how the bandwidth/state is managed.
後者の場合は、それが大幅な帯域幅/状態の管理方法影響を与える可能性があるので、溶液の設計に重要な入力であると予想されます。
Optimizing bandwidth may require introducing dedicated states in the core network (typically as much as the number of groups) for the following reasons:
最適帯域幅は、次の理由のために（グループの数として典型的にはるかに）コアネットワーク内の専用状態を導入する必要があります。
o small groups, and low predictability of the location of participants ("sparse groups")
小グループ、および参加者の位置の低い予測O（「疎グループ」）
o possibly significantly high bandwidth (a few Mb/s per participant)
Oおそらく非常に高い帯域幅（数MB / sの参加者あたり）
Lastly, some of these applications may involve real-time interactions and will be highly sensitive to packet loss, jitter, and delay.
最後に、これらのアプリケーションのいくつかは、リアルタイムの相互作用を伴うことが、パケットロス、ジッタ、および遅延に非常に敏感になります。
Some applications that are expected to be deployed on multicast VPNs are non-real-time applications aimed at distributing data from few sources to many receivers.
マルチキャストVPNの上に展開されると予想されている一部のアプリケーションでは、多くの受信機にいくつかのソースからのデータを配布を目的とした非リアルタイムのアプリケーションです。
Such applications may be considered to have lower expectations than their counterparts proposed in this document, since they would not necessarily involve more data streams and are more likely to adapt to the available bandwidth and to be robust to packet loss, jitter, and delay.
このようなアプリケーションは、彼らが必ずしもより多くのデータ・ストリームを伴い、利用可能な帯域幅に適応すると、パケットロス、ジッタ、および遅延に対してロバストである可能性が高いではないでしょうので、彼らのカウンターパートは、この文書で提案されているよりも低い期待を持っていると考えてよいです。
One important property is that such applications may involve higher bandwidths (hundreds of Mb/s).
1つの重要な特性は、そのようなアプリケーションは、より高い帯域幅（数百MB / s）を伴うことです。
This ISP scenario is a deployment scenario where IP-multicast connectivity is proposed for every VPN: if a customer requests a VPN, then this VPN will support IP multicast by default. In this case, the number of multicast VPNs equals the number of VPNs. This implies a quite important scalability requirement (e.g., hundreds of PEs, hundreds of VPNs per PE, with a potential increase by one order of magnitude in the future).
顧客はVPNを要求した場合、その後、このVPNは、デフォルトでは、IPマルチキャストをサポートしています。このISPのシナリオでは、IPマルチキャスト接続は、すべてのVPNのために提案されている展開シナリオです。この場合、マルチキャストVPNの数は、VPNの数に等しいです。これは非常に重要なスケーラビリティ要件（例えば、PEの数百、PE当たりVPNの何百も、将来的に一桁による電位上昇を有する）を意味しています。
The per-mVPN traffic behavior is not predictable because how the service is used is completely up to the customer. This results in a traffic mix of the scenarios mentioned in Section 4.1. QoS requirements are similar to typical unicast scenarios, with the need for different classes. Also, in such a context, a reasonably large range of protocols should be made available to the customer for use at the PE-CE level.
サービスがどのように使われるか、完全にお客様次第ですのでごとのMVPNトラフィックの動作は予測できません。これは、4.1節で述べたシナリオのトラフィックミックスになります。 QoS要件は、異なるクラスの必要性と、典型的なユニキャストのシナリオに似ています。また、このような状況において、プロトコルの合理的に広い範囲は、PE-CEレベルでの使用のために顧客に利用可能にされるべきです。
Also, in such a scenario, customers may want to deploy multicast connectivity between two or more multicast VPNs as well as access to Internet Multicast.
また、このようなシナリオでは、顧客は、マルチキャスト2つの以上のマルチキャストVPN間の接続だけでなく、インターネットのマルチキャストへのアクセスを展開することをお勧めします。
This section proposes orders of magnitude for different scalability metrics relevant for multicast VPN issues. It should be noted that the scalability figures proposed here relate to scalability expectations of future deployments of multicast VPN solutions, as the authors chose to not restrict the scope to only currently known deployments.
このセクションでは、マルチキャストVPNの問題に関連するさまざまなスケーラビリティのメトリックの大きさのオーダーを提案しています。著者が唯一の現在知られている展開に範囲を制限しないことを選択したとして、ここで提案スケーラビリティの数字は、マルチキャストVPNソリューションの今後の展開のスケーラビリティの期待に関連することに留意すべきです。
From the survey results, we see a broad range of expectations. There are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), but more typical answers are split between the low range of tens of VPNs (7 answers) and the higher range of hundreds or thousands of VPNs (2 + 4 answers).
調査結果から、我々は期待の広い範囲を参照してください。 2（5つのVPNの（1答）から10KのVPN（1答）に、より多くの一般的な答えは、VPNの（7つの解答）の数十の低域の間で分割され、VPNの数百または数千の高い範囲：あり、極端な答えがあります+ 4件の回答）。
A solution SHOULD support a number of multicast VPNs ranging from one to several thousands.
溶液を1から数千に及ぶマルチキャストVPNの数をサポートする必要があります。
A solution SHOULD NOT limit the proportion of multicast VPNs among all (unicast) VPNs.
溶液は、すべての（ユニキャスト）のVPN間のマルチキャストVPNの割合を制限するものではありません。
The majority of survey answers express a number of multicast VPNs per PE of around tens (8 responses between 5 and 50); a significant number of them (4) expect deployments with hundreds or thousands (1 response) of multicast VPNs per PE.
調査回答の大部分は、約十（5と50の間の8つの応答）のPE当たりのマルチキャストVPNの数を表します。それらのかなりの数は、（4）PE当たりのマルチキャストVPNの数百または数千と展開（1応答）を期待します。
A solution SHOULD support a number of multicast VPNs per PE of several hundreds, and may have to scale up to thousands of VPNs per PE.
溶液は、数百のPEあたりのマルチキャストVPNの数をサポートする必要があり、PE当たりのVPNの数千にスケールアップする必要があります。
Survey responses span from 1 to 2000 CEs per multicast VPN per PE. Most typical responses are between tens (6 answers) and hundreds (4 responses).
アンケートの回答は、1からPEあたりのマルチキャストVPNあたり2000 CEにまたがります。最も典型的な応答は、十（6件の回答可）と数百人（4件の回答）の間にあります。
A solution SHOULD support a number of CEs per multicast VPN per PE going up to several hundreds (and may target the support of thousands of CEs).
溶液は、数百（およびCEの何千もの支持を標的とすることができる）まで行くPE当たりマルチキャストVPN当たりのCEの数をサポートしなければなりません。
People who answered the survey typically expect deployments with the number of PEs per multicast VPN in the range of hundreds of PEs (6 responses) or tens of PEs (4 responses). Two responses were in the range of thousands (one mentioned a 10k figure).
アンケートに答え人々は、通常のPE（6件の回答）または十PEの（4つの応答）の数百の範囲のマルチキャストVPNあたりのPEの数と展開を期待しています。 2つの応答は、（1が10Kの図を述べた）何千人もの範囲でした。
A multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands.
マルチキャストVPNソリューションは、マルチキャストVPNあたりのPEの数百をサポートする必要があり、有効に数千人にスケールアップするかもしれません。
The number of PEs (per VPN) that would be connected to sources seems to be significantly lower than the number of PEs per VPN. This is obviously related to the fact that many respondents mentioned deployments related to content broadcast applications (one to many).
ソースに接続されることになる（VPNあたり）PEの数は、VPN当たりのPEの数よりも有意に低いと思われます。これは明らかに多くの回答者が、コンテンツの放送アプリケーション（多くの1つ）に関連した展開を言及しているという事実に関連しています。
Typical numbers are tens (6 responses) or hundreds (4 responses) of source-connected PEs. One respondent expected a higher number of several thousands.
典型的な数値は、十（6つの応答）またはソースに接続されたPEの数百（4つの応答）です。ある回答者は、数千の高い数を予想しました。
A solution SHOULD support hundreds of source-connected PEs per VPN, and some deployment scenarios involving many-to-many applications may require supporting a number of source-connected PEs equal to the number of PEs (hundreds or thousands).
溶液は、VPN当たりソースに接続されたPEの数百、及びPES（数百または数千）の数に等しいソースに接続されたPEの数をサポートする必要な場合があり、多対多の用途を含むいくつかの展開シナリオをサポートしなければなりません。
The survey showed that the number of PEs with receivers is expected to be of the same order of magnitude as the number of PEs in a multicast VPN. This is consistent with the intrinsic nature of most multicast applications, which have few source-only participants.
調査では、受信機とPEの数はマルチキャストVPN内のPEの数と同じオーダーの大きさであると予想されることを示しました。これは、いくつかのソースのみの参加者があり、ほとんどのマルチキャストアプリケーションの固有な性質と一致しています。
A solution SHOULD scale up to thousands of PEs having multicast service enabled.
解決策は、マルチキャストサービスを有効にしたPEの数千人にスケールアップすべきです。
Survey responses led us to retain the following orders of magnitude for the number of streams that a solution SHOULD support:
アンケートの回答は、ソリューションがサポートするストリーム数の大きさは、次の命令を保持するために、私たちを導きました：
per VPN: hundreds or thousands of streams
VPNあたり：ストリームの数百または数千
per PE: hundreds of streams
PEあたり：ストリームの数百
Again, the aim of this document is not to specify solutions but to give requirements for supporting IP multicast within L3 PPVPNs.
ここでも、この文書の目的は、解決策を指定するのではなく、L3 PPVPNs内のIPマルチキャストをサポートするための要件を与えることはありません。
In order to list these requirements, we have taken the standpoint of two different important entities: the end user (the customer using the VPN) and the service provider.
エンドユーザー（VPNを使用して、顧客）とサービスプロバイダ：これらの要件をリストアップするために、我々は二つの異なる重要なエンティティの立場をとっています。
In the rest of the document, by "a solution" or "a multicast VPN solution", we mean a solution that allows multicast in an L3 provider-provisioned VPN, and which addresses the requirements listed in this document.
文書の残りの部分では、「ソリューション」または「マルチキャストVPNソリューション」によって、我々はL3プロバイダープロビジョニングVPNでマルチキャストを可能にし、この文書に記載されている要件に対応したソリューションを意味します。
As for unicast, the multicast service MUST be provider provisioned and SHALL NOT require customer devices (CEs) to support any extra features compared to those required for multicast in a non-VPN context. Enabling a VPN for multicast support SHOULD be possible with no impact (or very limited impact) on existing multicast protocols possibly already deployed on the CE devices.
ユニキャストについては、マルチキャストサービスプロバイダプロビジョニングする必要がありますし、非VPNコンテキストでマルチキャストのために必要なものに比べて余分な機能をサポートするために、顧客のデバイス（CES）が必要ないものとします。マルチキャストサポートのためにVPNを有効にする可能性がすでにCEデバイスに展開既存のマルチキャストプロトコルに影響を与えず（又は非常に限られた影響）とが可能であるべきです。
Consequently to Section 5.1.1, multicast-related protocol exchanges between a CE and its directly connected PE SHOULD happen via existing multicast protocols.
したがってCEとの間のセクション5.1.1、マルチキャスト関連プロトコル交換に直接接続されたPEは、既存のマルチキャストプロトコルを介して起こるべきです。
Such protocols include: PIM-SM [RFC4601], bidirectional-PIM [BIDIR-PIM], PIM - Dense Mode (DM) [RFC3973], and IGMPv3 [RFC3376] (this version implicitly supports hosts that only implement IGMPv1 [RFC1112] or IGMPv2 [RFC2236]).
そのようなプロトコルは：PIM-SM [RFC4601]、双方向PIM [BIDIR-PIM]、PIM - 稠密モード（DM）[RFC3973]、およびIGMPv3 [RFC3376]（このバージョンは暗黙のみのIGMPv1 [RFC1112]を実装するホストをサポートするかをIGMPv2の[RFC2236]）。
Among those protocols, the support of PIM-SM (which includes the SSM model) and either IGMPv3 (for IPv4 solutions) and/or Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions) is REQUIRED. Bidir-PIM support at the PE-CE interface is RECOMMENDED. And considering deployments, PIM-DM is considered OPTIONAL.
これらのプロトコルのうち、（SSMモデルを含む）PIM-SMおよび（IPv4のソリューションのため）のIGMPv3のいずれかおよび/またはマルチキャストリスナー発見バージョン2（のMLDv2）（IPv6のソリューションのため）[RFC3810]のサポートが必要です。 PE-CEインターフェイスで双方向-PIMサポートが推奨されます。そして、導入を検討し、PIM-DMは、オプションと考えられています。
When a multicast VPN solution is built on a VPN solution supporting IPv6 unicast, it MUST also support v6 variants of the above protocols, including MLDv2, and PIM-SM IPv6-specific procedures. For a multicast VPN solution built on a unicast VPN solution supporting only IPv4, it is RECOMMENDED that the design favors the definition of procedures and encodings that will provide an easy adaptation to IPv6.
マルチキャストVPNソリューションがIPv6ユニキャストをサポートするVPNソリューションに基づいて構築されている場合、それはまたのMLDv2、およびPIM-SM IPv6固有の手順を含む上記プロトコルのV6変異体をサポートしなければなりません。 IPv4のみをサポートしているユニキャストVPNソリューション上に構築されたマルチキャストVPNソリューションのためには、設計がIPv6への容易な適応を提供し、手続きとエンコーディングの定義を支持することが推奨されます。
Firstly, general considerations regarding QoS in L3VPNs expressed in Section 5.5 of [RFC4031] are also relevant to this section.
まず、L3VPNsにおけるQoSに関する一般的な考察は、このセクションに関連する[RFC4031]のセクション5.5で発現しました。
QoS is measured in terms of delay, jitter, packet loss, and availability. These metrics are already defined for the current unicast PPVPN services and are included in Service Level Agreements (SLAs). In some cases, the agreed SLA may be different between unicast and multicast, and that will require differentiation mechanisms in order to monitor both SLAs.
QoSは遅延、ジッタ、パケット損失、および可用性の観点で測定されます。これらのメトリックは、すでに現在のユニキャストPPVPNサービスのために定義され、サービスレベル契約（SLA）に含まれています。いくつかのケースでは、合意されたSLAは、ユニキャストとマルチキャストの間で異なっていてもよく、それは両方のSLAを監視するために分化機構を必要とするであろう。
The level of availability for the multicast service SHOULD be on par with what exists for unicast traffic. For instance, comparable traffic protection mechanisms SHOULD be available for customer multicast traffic when it is carried over the service provider's network.
マルチキャストサービスの可用性のレベルは、ユニキャストトラフィックのために存在するものと同等にする必要があります。それは、サービスプロバイダのネットワーク上で伝送されている場合たとえば、同等のトラフィック保護メカニズムは、顧客のマルチキャストトラフィックのために利用可能であるべきです。
A multicast VPN solution SHALL allow a service provider to define at least the same level of quality of service as exists for unicast, and as exists for multicast in a non-VPN context. From this perspective, the deployment of multicast-based services within an L3VPN environment SHALL benefit from Diffserv [RFC2475] mechanisms that include multicast traffic identification, classification, and marking capabilities, as well as multicast traffic policing, scheduling, and conditioning capabilities. Such capabilities MUST therefore be supported by any participating device in the establishment and the maintenance of the multicast distribution tunnel within the VPN.
マルチキャストVPNソリューションは、ユニキャストのために存在し、非VPNコンテキストにおけるマルチキャストのために存在する限り、サービスの品質の少なくとも同じレベルを定義するためにサービスプロバイダに許可しなければなりません。この観点から、L3VPN環境内のマルチキャストベースのサービスの展開は、マルチキャストトラフィックの識別、分類、およびマーキング機能、ならびにマルチキャストトラフィックポリシング、スケジューリング、および調整能力を含むDiffservの[RFC2475]メカニズムから恩恵を受けるSHALL。そのような能力は、したがって、確立中の任意の参加装置とVPN内のマルチキャスト配信トンネルの維持によってサポートされなければなりません。
As multicast is often used to deliver high-quality services such as TV broadcast, a multicast VPN solution MAY provide additional features to support high QoS such as bandwidth reservation and admission control.
マルチキャストは、多くの場合、テレビ放送などの高品質なサービスを提供するために使用されているように、マルチキャストVPNソリューションは、このような帯域予約とアドミッション制御など高いQoSをサポートするための追加機能を提供することができます。
Also, considering that multicast reception is receiver-triggered, group join delay (as defined in [RFC2432]) is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard.
また、マルチキャスト受信が受信トリガであることを考慮すると、グループも考えられる一つの重要なQoSパラメータ（[RFC2432]で定義されるように）遅延が加わります。このように、マルチキャストVPNソリューションは、この点で適切に設計することが推奨されます。
The group leave delay (as defined in [RFC2432]) may also be important on the CE-PE link for some usage scenarios: in cases where the typical bandwidth of multicast streams is close to the bandwidth of a PE-CE link, it will be important to have the ability to stop the emission of a stream on the PE-CE link as soon as it stops being requested by the CE, to allow for fast switching between two different high-throughput multicast streams. This implies that it SHOULD be possible to tune the multicast routing or group management protocols (e.g., IGMP/MLD or PIM) used on the PE-CE adjacency to reduce the group leave delay to the minimum.
ケースでマルチキャストストリームの典型的な帯域幅は、それが意志PE-CEリンクの帯域幅に近いです（[RFC2432]で定義されるように）グループ離脱遅延はまた、いくつかの使用シナリオ用のCE-PEリンク上で重要であるかもしれませんそれは二つの異なる高スループットマルチキャストストリーム間の高速切り替えを可能にするために、CEによって要求されている停止するとすぐに、PE-CEリンク上のストリームの発光を停止させる能力を有することが重要です。これは、最小のグループ離脱遅延を低減するために、PE-CE隣接上で使用されるマルチキャストルーティングまたはグループ管理プロトコル（例えば、IGMP / MLDまたはPIM）調整することが可能でなければならないことを意味します。
Lastly, a multicast VPN solution SHOULD as much as possible ensure that client multicast traffic packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network. Packet loss issues also have to be considered when a new source starts to send traffic to a group: any receiver interested in receiving such traffic SHOULD be serviced accordingly.
最後に、マルチキャストVPNソリューションは、可能な限り変更は、クライアントのマルチキャストデータストリームは、プロバイダのネットワーク上で行われる方法で発生した場合でも、そのクライアントマルチキャストトラフィックのパケットが失われたり重複もないようにする必要があります。このようなトラフィックの受信に関心の任意の受信機はそれに応じてサービスを提供する必要があります。パケット損失の問題は、新しいソースがグループにトラフィックを送信するために開始したときに考慮しなければなりません。
The requirements and definitions for operations and management (OAM) of L3VPNs that are defined in [RFC4176] equally apply to multicast, and are not extensively repeated in this document. This sub-section mentions the most important guidelines and details points of particular relevance in the context of multicast in L3VPNs.
[RFC4176]で定義されL3VPNsの操作および管理するための要件と定義（OAM）が等しくマルチキャストに適用され、そして広範本書では繰り返しません。このサブセクションでは、L3VPNsにおけるマルチキャストの文脈の中で最も重要なガイドラインと特に関連の詳細ポイントに言及しています。
A multicast VPN solution SHOULD allow a multicast VPN customer to manage the capabilities and characteristics of their multicast VPN services.
マルチキャストVPNソリューションは、マルチキャストVPNの顧客がマルチキャストVPNサービスの機能や特性を管理できるようにする必要があります。
A multicast VPN solution MUST support SLA monitoring capabilities, which SHOULD rely upon techniques similar to those used for the unicast service for the same monitoring purposes. Multicast SLA-related metrics SHOULD be available through means similar to the ones already used for unicast-related monitoring, such as Simple Network Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT].
マルチキャストVPNソリューションは、同一の監視目的のためにユニキャストサービスのために使用されるものと同様の技術に依存するべきであるSLA監視機能をサポートしなければなりません。マルチキャストSLA関連メトリックは、簡易ネットワーク管理プロトコル（SNMP）[RFC3411]またはIPFIX [IPFIX-PROT]として既にユニキャスト関連の監視のために使用されるものと同様の手段を介して利用可能であるべきです。
Multicast-specific characteristics that may be monitored include: multicast statistics per stream, end-to-end delay, and group join/ leave delay (time to start/stop receiving a multicast group's traffic across the VPN, as defined in [RFC2432], Section 3).
監視することができるマルチキャスト固有の特性が含まれる：ストリーム、エンドツーエンド遅延、及びグループ参加/離脱遅延（[RFC2432]で定義されるように、VPNを横切ってマルチキャストグループのトラフィックの受信を停止/開始する時間当たりマルチキャスト統計を第3節）。
The monitoring of multicast-specific parameters and statistics MUST include multicast traffic statistics: total/incoming/outgoing/dropped traffic, by period of time. It MAY include IP Performance Metrics related information (IPPM, [RFC2330]) that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. See [MULTIMETRICS].
マルチキャスト固有のパラメータと統計の監視は、マルチキャストトラフィックの統計情報を含める必要があります発信/合計/着信/時間の期間によって、トラフィックを落としました。これは、マルチキャストトラフィックの使用に関連しているIPパフォーマンス・メトリックに関する情報（IPPM、[RFC2330]）を含めることがあります。そのような情報は、一方向のパケット遅延、パケット間遅延変動など[MULTIMETRICS]を参照してくださいが含まれています。
A generic discussion of SLAs is provided in [RFC3809].
SLAの一般的な議論は[RFC3809]で提供されています。
Apart from statistics on multicast traffic, customers of a multicast VPN will need information concerning the status of their multicast resource usage (multicast routing states and bandwidth). Indeed, as mentioned in Section 5.2.5, for scalability purposes, a service provider may limit the number (and/or throughput) of multicast streams that are received/sent to/from a client site. In such a case, a multicast VPN solution SHOULD allow customers to find out their current resource usage (multicast routing states and throughput), and to receive some kind of feedback if their usage exceeds the agreed bounds. Whether this issue will be better handled at the protocol level at the PE-CE interface or at the Service Management Level interface [RFC4176] is left for further discussion.
別にマルチキャストトラフィックの統計から、マルチキャストVPNの顧客は、マルチキャストリソース使用量の状況（マルチキャストルーティングの状態と帯域幅）に関する情報が必要になります。スケーラビリティのために、セクション5.2.5で述べたように実際に、サービスプロバイダは、番号（及び/又はスループット）を制限することができるクライアントのサイトへ/から送信/受信されたマルチキャストストリームの。このような場合には、マルチキャストVPNソリューションは、顧客が現在のリソース使用量（マルチキャストルーティング状態及びスループット）を見つけるために可能にしなければならない、そしてそれらの使用は、合意された境界を超えた場合、フィードバックのいくつかの種類を受信します。この問題は、より良好な[RFC4176] PE-CEインターフェースにおけるプロトコルレベルまたはサービス管理レベルのインターフェイスで処理されるかどうかは、さらなる議論のために残されています。
It is RECOMMENDED that any OAM mechanism designed to trigger alarms in relation to performance or resource usage metrics integrate the ability to limit the rate at which such alarms are generated (e.g., some form of a hysteresis mechanism based on low/high thresholds defined for the metrics).
性能またはリソース使用メトリクスに関連してアラームをトリガするために設計された任意のOAMメカニズムは、アラームが生成される速度（例えば、用に定義された低/高閾値に基づいてヒステリシス機構のいくつかのフォームを制限する機能を統合することが推奨されますメトリクス）。
Security is a key point for a customer who uses a VPN service. For instance, the [RFC4364] model offers some guarantees concerning the security level of data transmission within the VPN.
セキュリティは、VPNサービスを利用する顧客のための重要なポイントです。例えば、[RFC4364]のモデルは、VPN内のデータ伝送のセキュリティレベルに関するいくつかの保証を提供しています。
A multicast VPN solution MUST provide an architecture with the same level of security for both unicast and multicast traffic.
マルチキャストVPNソリューションは、ユニキャストおよびマルチキャストトラフィックの両方のセキュリティの同じレベルのアーキテクチャを提供しなければなりません。
Moreover, the activation of multicast features SHOULD be possible:
また、マルチキャスト機能の活性化を可能にすべきです：
o per VRF / per VR
マイクロ足ワーフ/フットVAR
o per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR)
CEインターフェイスあたりO（VPNの複数のCEが共通のVRFに接続されている/ VR）
o per multicast group and/or per channel
マルチキャストグループごと及び/又はチャネルあたりO
o with a distinction between multicast reception and emission
マルチキャスト受信と発光との間の区別とO
A multicast VPN solution may choose to make the optimality/ scalability trade-off stated in Section 3.3 by sometimes distributing multicast traffic of a client group to a larger set of PE routers that may include PEs that are not part of the VPN. From a security standpoint, this may be a problem for some VPN customers; thus, a multicast VPN solution using such a scheme MAY offer ways to avoid this for specific customers (and/or specific customer multicast streams).
マルチキャストVPNソリューションは時々VPNの一部ではないのPEを含むことがPEルータのより大きいセットにクライアント・グループのマルチキャストトラフィックを分散させることによって、セクション3.3で述べた最適性/拡張性のトレードオフを行うことを選択してもよいです。セキュリティの観点から、これはいくつかのVPNの顧客のために問題がある可能性があります。したがって、このようなスキームを使用して、マルチキャストVPNソリューションは、特定の顧客（および/または特定の顧客のマルチキャストストリーム）のためにこれを回避するための方法を提供することがあります。
In current PP L3VPN models, a customer site may be set up to be part of multiple VPNs, and this should still be possible when a VPN is multicast-enabled. In practice, it means that a VRF or VR can be part of more than one VPN.
現在のPP L3VPNモデルでは、顧客サイトは複数のVPNの一部であるように設定することができる、およびVPNがマルチキャストに対応しているとき、これはまだ可能でなければなりません。実際には、VRFまたはVRが複数のVPNの一部であることを意味します。
A multicast VPN solution MUST support such deployments.
マルチキャストVPNソリューションは、このような展開をサポートしなければなりません。
For instance, it must be possible to configure a VRF so that an enterprise site participating in a BGP/MPLS multicast-enabled VPN and connected to that VRF can receive a multicast stream from (or originate a multicast stream towards) another VPN that would be associated to that VRF.
BGP / MPLSのマルチキャスト対応VPNに参加し、そのVRFに接続された企業のサイトからマルチキャストストリームを受信（又は向かってマルチキャストストリームを発信）であろう他のVPNができるように、例えば、VRFを設定することが可能でなければなりませんそのVRFに関連付けられています。
This means that a multicast VPN solution MUST offer means for a VRF to be configured so that multicast connectivity can be set up for a chosen set of extranet VPNs. More precisely, it MUST be possible to configure a VRF so that:
これは、マルチキャスト接続がエクストラネットVPNの選ばれたセット用に設定することができるように、マルチキャストVPNソリューションを設定するVRFのための手段を提供しなければならないことを意味します。より正確には、そのようVRFを設定することは可能でなければなりません。
o receivers behind attached CEs can receive multicast traffic sourced in the configured set of extranet VPNs
O添付のCEの背後にある受信機は、エクストラネットVPNの構成セットにソースマルチキャストトラフィックを受信することができます。
o sources behind attached CEs can reach multicast traffic receivers located in the configured set of extranet VPNs
添付のCE後ろO源は、エクストラネットVPNの構成セットに位置するマルチキャストトラフィックの受信機に到達することができ
o multicast reception and emission can be independently enabled for each of the extranet VPNs
Oマルチキャスト受信及び放出が独立エクストラネットVPNの各々に対して有効にすることができます
Moreover, a solution MUST allow service providers to control an extranet's multicast connectivity independently from the extranet's unicast connectivity. More specifically:
また、溶液は、サービスプロバイダは、エクストラネットのユニキャスト接続とは独立してエクストラネットのマルチキャスト接続性を制御することを可能にしなければなりません。すなわち：
o enabling unicast connectivity to another VPN MUST be possible without activating multicast connectivity with that VPN
別のVPNへのユニキャスト接続を可能oをそのVPNでマルチキャスト接続を活性化することなく可能でなければなりません
o enabling multicast connectivity with another VPN SHOULD NOT require more than the strict minimal unicast routing. Sending multicast to a VPN SHOULD NOT require having unicast routes to that VPN; receiving multicast from a VPN SHOULD be possible with nothing more than unicast routes to the relevant multicast sources of that VPN
別のVPNでマルチキャスト接続を可能oを厳密最小ユニキャストルーティングよりも多くを必要とすべきではありません。 VPNへのマルチキャストを送信すると、そのVPNへのユニキャストルートを持つ必要はありません。 VPNからのマルチキャストを受信すると、そのVPNの関連するマルチキャストソースへのユニキャストルートよりも何も可能であるべき
o when unicast routes from another VPN are imported into a VR/VRF, for multicast Reverse Path Forwarding (RPF) resolution, this SHOULD be possible without making those routes available for unicast routing
別のVPNからのユニキャストルートはVR / VRFにインポートされたときにO、マルチキャストリバースパス転送（RPF）解像度のため、これは、ユニキャストルーティングのためにそれらの経路を利用可能にすることなく可能であるべき
Proper support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link, whether it is a physical or logical link.
この機能のための適切なサポートは、それが物理的または論理的なリンクであるかどうか、PE-CEリンク上でマルチキャストトラフィックを複製する必要はありません。
Connectivity with Internet Multicast is a particular case of the previous section, where sites attached to a VR/VRF would need to receive/send multicast traffic from/to the Internet.
インターネットマルチキャストとの接続には、VR / VRFに添付のサイトが/からのインターネットへのマルチキャストトラフィックを送信/受信する必要があるだろう、前のセクションの特定のケースです。
This should be considered OPTIONAL given the additional considerations, such as security, needed to fulfill the requirements for providing Internet Multicast.
これは、インターネットマルチキャストを提供するための要件を満たすために必要なセキュリティなどの追加の考慮事項、与えられたオプションと見なされるべきです。
Many L3 PPVPN solutions, such as [RFC4364] and [VRs], define the "Carrier's Carrier" model, where a "carrier's carrier" service provider supports one or more customer ISPs, or "sub-carriers". A multicast VPN solution SHOULD support the carrier's carrier model in a scalable and efficient manner.
このような[RFC4364]などの多くのL3 PPVPNソリューション、および[のVR]、「キャリアのキャリア」サービス・プロバイダは、1つのまたは複数の顧客のISP、または「サブキャリアを」サポート「キャリアのキャリア」モデルを定義します。マルチキャストVPNソリューションは、スケーラブルかつ効率的にキャリアのキャリアモデルをサポートする必要があります。
Ideally, the range of tunneling protocols available for the sub-carrier ISP should be the same as those available for the carrier's carrier ISP. This implies that the protocols that may be used at the PE-CE level SHOULD NOT be restricted to protocols required as per Section 5.1.2 and SHOULD include some of the protocols listed in Section 5.2.4, such as for instance P2MP MPLS signaling protocols.
理想的には、サブキャリアのISPのために利用可能なトンネリングプロトコルの範囲は、キャリアのキャリアISPのために利用可能なものと同じであるべきです。これは、PE-CEレベルで使用することができるプロトコルはセクション5.1.2に従って必要なプロトコルに限定されるものではないことを意味し、そのようなインスタンスP2MP MPLSシグナリングプロトコルのような、セクション5.2.4に記載されているプロトコルの一部を含むべきです。
In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs [RFC4364], this means that MPLS label distribution SHOULD happen at the PE-CE level, giving the ability to the sub-carrier to use multipoint LSPs as a tunneling mechanism.
そのようなBGP / MPLS VPNの[RFC4364]としてMPLSベースL3VPN配備のコンテキストでは、これは、MPLSラベル配布トンネリングとして多LSPを使用するサブキャリアする能力を与え、PE-CEレベルで起こるべきであることを意味します機構。
A multicast VPN solution SHOULD be compatible with current solutions that aim at improving the service robustness for customers such as multi-homing, CE-PE link load balancing, and fail-over. A multicast VPN solution SHOULD also be able to offer those same features for multicast traffic.
マルチキャストVPNソリューションは、マルチホーミング、CE-PEリンクのロードバランシングなどの顧客向けサービスの堅牢性を向上させることを目指して、現在のソリューションとの互換性、およびフェイルオーバべきです。マルチキャストVPNソリューションは、マルチキャストトラフィック用のものと同じ機能を提供できるようにすべきです。
Any solution SHOULD support redundant topology of CE-PE links. It SHOULD minimize multicast traffic disruption and fail-over.
任意の溶液は、CE-PEリンクの冗長トポロジーをサポートしなければなりません。これは、マルチキャストトラフィックの中断を最小限に抑え、フェイル・オーバーすべきです。
When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer side, the RP function (or RP-address in the case of bidir-PIM) has to be associated to a node running PIM, and configured on this node.
PIM-SM（または双方向-PIM）がVPN顧客側のASMモードで使用される場合、RP機能（または双方向-PIMの場合にはRP-アドレス）PIMを実行するノードに関連付けられ、そして上に構成されなければなりませんこのノード。
In the case of PIM-SM in ASM mode, engineering of the RP function requires the deployment of specific protocols and associated configurations. A service provider may offer to manage customers' multicast protocol operation on their behalf. This implies that it is necessary to consider cases where a customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN solution MAY support the hosting of the RP function in a VR or VRF.
ASMモードでPIM-SMの場合は、RP機能のエンジニアリングは、特定のプロトコルと関連する構成を展開する必要があります。サービスプロバイダは、彼らに代わって顧客のマルチキャストプロトコルの動作を管理するために提供することがあります。顧客のRPが（例えば、PEの上）外部委託しているケースを考慮する必要があることを意味します。そのため、VPNソリューションは、VRまたはVRFにRP機能のホスティングをサポートするかもしれません。
Availability of the RP function (or address) is required for proper operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity to the RP from a receiver or source will impact the multicast service. For this reason, different mechanisms exist, such as BSR [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)- based [RFC3446] or PIM-based [RFC4610]).
RP機能（またはアドレス）の入手可能性は、PIM-SM（ASMモード）とのbidir-PIMの適切な動作のために必要とされます。受信機または送信元からRPへの接続の損失は、マルチキャストサービスに影響を与えます。この理由のために、異なるメカニズムが、このようなBSR [PIM-BSR]またはエニーキャスト-RPとして、存在する（マルチキャストソース発見プロトコル（MSDP） - ベースの[RFC3446]またはPIMベース[RFC4610]）。
These protocols and procedures SHOULD work transparently through a multicast VPN, and MAY if relevant, be implemented in a VRF/VR.
これらのプロトコルおよび手順は、マルチキャストVPNを透過的に動作するはずですし、MAYは関連がある場合は、VRF / VRで実装します。
Moreover, a multicast VPN solution MAY improve the robustness of the ASM multicast service regarding loss of connectivity to the RP, by providing specific features that help: a) maintain ASM multicast service among all the sites within an MVPN that maintain connectivity among themselves, even when the site(s) hosting the RP lose their connectivity to the MVPN
また、マルチキャストVPNソリューションを助ける特定の機能を提供することで、RPへの接続が失わに関するASMマルチキャストサービスの堅牢性を向上する可能性があります。a）自分たちの中での接続性を維持するMVPN内のすべてのサイトの中でASMマルチキャストサービスを維持し、でもRPをホストしているサイト（複数可）MVPNへの接続が失われたときに
b) maintain ASM multicast service within any site that loses connectivity to the service provider
b）は、サービスプロバイダへの接続を失った任意のサイト内のASMマルチキャストサービスを維持
In the case of PIM-SM, when a source starts to emit traffic toward a group (in ASM mode), if sources and receivers are located in VPN sites that are different than that of the RP, then traffic may transiently flow twice through the SP network and the CE-PE link of the RP (from source to RP, and then from RP to receivers). This traffic peak, even short, may not be convenient depending on the traffic and link bandwidth.
ソース及び受信機はRPとは異なるVPNのサイトに配置されている場合、ソースは（ASMモード）のグループに向けてトラフィックを放出し始めるPIM-SMの場合には、トラフィックは一過通っ倍流れることができますSPネットワークとRPのCE-PEリンク（RPソースから、次いでRPからレシーバまで）。このトラフィックのピークは、短くても、トラフィックやリンクの帯域幅に応じて、便利ではないかもしれません。
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue.
このように、VPNソリューションを解決する機能を提供したり、この潜在的な問題を軽減するかもしれません。
A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions on multicast group addresses used by VPN customers.
マルチキャストプロバイダプロビジョニングL3VPNは、VPNの顧客が使用するマルチキャストグループアドレスに制限を課すべきではありません。
In particular, like unicast traffic, an overlap of multicast group address sets used by different VPN customers MUST be supported.
具体的には、ユニキャストトラフィックのように、異なるVPN顧客によって使用されるマルチキャストグループアドレスセットの重複をサポートしなければなりません。
The use of globally unique means of multicast-based service identification at the scale of the domain where such services are provided SHOULD be recommended. For IPv4 multicast, this implies the use of the multicast administratively scoped range (239/8 as defined by [RFC2365]) for services that are to be used only inside the VPN, and of either SSM-range addresses (232/8 as defined by [RFC4607]) or globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for services for which traffic may be transmitted outside the VPN.
このようなサービスが提供されているドメインの規模でマルチキャストベースのサービス識別のグローバル一意手段の使用が推奨されるべきです。定義されるようなのIPv4マルチキャストのために、これは、VPN内で使用されるサービスのために、およびSSM範囲のアドレスのいずれかのマルチキャスト管理スコープ範囲（8分の239 [RFC2365]で定義されるように）（232/8の使用を意味します[RFC4607]）によって、またはグローバルトラフィックがVPNの外部に送信することができるため、サービスのためのグループアドレス（例えば、GLOP [RFC3180]、8分の233）を割り当て。
For customers, it is often a serious issue whether or not transmitted packets will be fragmented. In particular, some multicast applications might have different requirements than those that make use of unicast, and they may expect services that guarantee available packet length not to be fragmented.
顧客のために、多くの場合、送信されたパケットが断片化されるか否かの深刻な問題です。特に、いくつかのマルチキャストアプリケーションは、ユニキャストを利用しているものとは異なる要件があるかもしれない、と彼らはない断片化することが可能なパケット長を保証するサービスを期待することがあります。
Therefore, a multicast VPN solution SHOULD be designed with these considerations in mind. In practice: o the encapsulation overhead of a multicast VPN solution SHOULD be minimized, so that customer devices can be free of fragmentation and reassembly activity as much as possible
そのため、マルチキャストVPNソリューションは、これらを考慮して設計する必要があります。マルチキャストVPNソリューションのカプセル化オーバーヘッドO顧客のデバイスはできるだけ断片化と再構築活動の自由になるように、最小化されなければならない。実際には
o a multicast VPN solution SHOULD enable the service provider to commit to a minimum path MTU usable by multicast VPN customers
OマルチキャストVPNソリューションは、マルチキャストVPN顧客によって使用可能な最小のパスMTUにコミットするために、サービスプロバイダを有効にする必要があります
o a multicast VPN solution SHOULD be compatible with path MTU discovery mechanisms (see [RFC1191] and [RFC4459]), and particular care SHOULD be given to means to help troubleshoot MTU issues
OマルチキャストVPNソリューションは、（[RFC1191]参照[RFC4459]）パスMTUディスカバリメカニズムと互換性があり、特に注意がMTUの問題をトラブルシューティングするための手段に与えられるべきです
Moreover, since Ethernet LAN segments are often located at first and last hops, a multicast VPN solution SHOULD be designed to allow for a minimum 1500-byte IP MTU for VPN customers multicast packet, when the provider backbone design allows it.
イーサネットLANセグメントは、多くの場合、最初と最後のホップに位置しているので、マルチキャストVPNソリューションは、プロバイダのバックボーンデザインがそれを可能にする場合、VPNの顧客マルチキャストパケットの最小1500バイトのIP MTUを可能にするように設計する必要があります。
Note: To avoid repetition and confusion with terms used in solution specifications, we introduced in Section 2.1 the term MDTunnel (for Multicast Distribution Tunnel), which designates the data plane means used by the service provider to forward customer multicast traffic over the core network.
注意：ソリューションの仕様で使用される用語で反復し、混乱を避けるために、我々は2.1節で紹介し用語MDTunnelコアネットワークを介して顧客のマルチキャストトラフィックを転送するために、サービスプロバイダによって使用される手段データプレーンを指定し、（マルチキャスト配信トンネル用）。
The deployment of a multicast VPN solution SHOULD be possible with no (or very limited) impact on existing deployments of standardized multicast-related protocols on P and PE routers.
マルチキャストVPNソリューションの展開はない（又は非常に限られた）を有することが可能であるべきであるP及びPEルータ上の標準化されたマルチキャスト関連プロトコルの既存の配備に影響。
Some currently standardized and deployed L3VPN solutions have the major advantage of being scalable in the core regarding the number of customers and the number of customer routes. For instance, in the [RFC4364] and Virtual Router [VRs] models, a P router sees a number of MPLS tunnels that is only linked to the number of PEs and not to the number of VPNs, or customer sites.
いくつかの現在の標準化と展開L3VPNソリューションは、顧客数や顧客ルートの数に関するコアにスケーラブルであることの主な利点を持っています。例えば、[RFC4364]と仮想ルータ[のVR]モデルでは、PルータはVPNの数、または顧客サイトへのPEの数にリンクされていないMPLSトンネルの数を見ています。
As far as possible, this independence in the core, with respect to the number of customers and to customer activity, is recommended. Yet, it is recognized that in our context scalability and resource usage optimality are competing goals, so this requirement may be reduced to giving the possibility of bounding the quantity of states that the service provider needs to maintain in the core for MDTunnels, with a bound being independent of the multicast activity of VPN customers.
可能な限り、顧客の数に、顧客の活動に対するコアでこの独立性は、推奨されます。しかし、私たちのコンテキストの拡張性とリソース使用率の最適に目標を競合していることが認識されているので、この要件は、結合して、サービスプロバイダがMDTunnelsの中核に維持する必要がある状態の量を境界とする可能性を与えることに低減することができますVPN顧客のマルチキャスト活動から独立しています。
It is expected that multicast VPN solutions will use some kind of point-to-multipoint technology to efficiently carry multicast VPN traffic, and because such technologies require maintaining state information, this will use resources in the control plane of P and PE routers (memory and processing, and possibly address space).
マルチキャストVPNソリューションを効率的にマルチキャストVPNトラフィックを運ぶためにポイント・ツー・マルチポイント技術のいくつかの種類が使用され、そしてそのような技術は、状態情報を維持する必要があるため、これはPとPEルータの制御プレーンのリソースを使用する（メモリとすることが期待されます処理、そしておそらくアドレス空間）。
Scalability is a key requirement for multicast VPN solutions. Solutions MUST be designed to scale well with an increase in any of the following:
スケーラビリティは、マルチキャストVPNソリューションの重要な要件です。ソリューションは、次のいずれかの増加とよく拡張できるように設計されなければなりません。
o the number of PEs
PEの数O
o the number of customer VPNs (total and per PE)
OカスタマーVPNの数（合計およびPEあたり）
o the number of PEs and sites in any VPN
任意のVPN内のPEとサイトの数O
o the number of client multicast channels (groups or source-groups)
Oクライアントマルチキャストチャネル（グループまたはソースグループ）の数
Please consult Section 4.2 for typical orders of magnitude up to which a multicast VPN solution is expected to scale.
マルチキャストVPNソリューションを拡張することが期待されている大きさまでの典型的な注文については、セクション4.2を参照してください。
Scalability of both performance and operation MUST be considered.
性能と操作の両方のスケーラビリティを考えなければなりません。
Key considerations SHOULD include:
主な考慮事項は含まれている必要があります
o the processing resources required by the control plane (neighborhood or session maintenance messages, keep-alives, timers, etc.)
O制御プレーンによって必要とされる処理リソース（近隣又はセッション維持メッセージ、キープアライブ、タイマー、等）
o the memory resources needed for the control plane
コントロールプレーンのために必要なメモリリソースO
o the amount of protocol information transmitted to manage a multicast VPN (e.g., signaling throughput)
OマルチキャストVPNを管理するために送信プロトコル情報の量（例えば、シグナルスループット）
o the amount of control plane processing required on PE and P routers to add or remove a customer site (or a customer from a multicast session)
（マルチキャストセッションから、または顧客）顧客サイトを追加または削除するPEおよびPルータに必要な制御プレーン処理量O
o the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
使用されるマルチキャストIPアドレスの数O（ASMモードでIPマルチキャストをマルチキャスト配信トンネルとして提案されている場合）
o other particular elements inherent to each solution that impact scalability (e.g., if a solution uses some distribution tree inside the core, topology of the tree and number of leaf nodes may be some of them)
各溶液衝撃スケーラビリティに固有の他の特定の要素O（溶液はコア内部にいくつかのディストリビューションツリーを使用する場合、例えば、リーフノードのツリーと数のトポロジーは、それらの一部であってもよいです）
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
各ソリューションの適用は、前述のスケーラビリティ基準に関して評価されることが期待されます。
These considerations naturally lead us to believe that proposed solutions SHOULD offer the possibility of sharing such resources between different multicast streams (between different VPNs, between different multicast streams of the same or of different VPNs). This means, for instance, if MDTunnels are trees, being able to share an MDTunnel between several customers.
これらの考慮事項は、自然に提案されたソリューションは、（異なるVPN間で、同じの異なるマルチキャストストリーム間や異なるVPNの）異なるマルチキャストストリームの間で、このようなリソースを共有する可能性を提供すべきであると信じて私たちを導きます。 MDTunnelsは、複数の顧客の間でMDTunnelを共有することができるという、木々ある場合、これは、例えば、意味しています。
Those scalability issues are expected to be more significant on P routers, but a multicast VPN solution SHOULD address both P and PE routers as far as scalability is concerned.
これらのスケーラビリティの問題がPルータでより顕著であると予想されるが、マルチキャストVPNソリューションは限りスケーラビリティに関しては、両方のPおよびPEルータに対処すべきです。
One of the aims of the use of multicast instead of unicast is resource optimization in the network.
代わりに、ユニキャストのマルチキャストの使用の目的の一つは、ネットワーク内のリソースの最適化です。
The two obvious suboptimal behaviors that a multicast VPN solution would want to avoid are needless duplication (when the same data travels twice or more on a link, e.g., when doing ingress PE replication) and needless reception (e.g., a PE receiving traffic that it does not need because there are no downstream receivers).
マルチキャストVPNソリューションは避けたいと思う2つの明白な次善の行動が（入力PEのレプリケーションを行うときに同じデータが、例えば、リンクを2回以上移動する）不必要な重複や不必要な受信（例えば、PE受信トラフィックそれことです何の下流の受信機が存在しないため）必要はありません。
As previously stated in this document, designing a scalable solution that makes an optimal use of resources is considered difficult. Thus, what is expected from a multicast VPN solution is that it addresses the resource optimization issue while taking into account the fact that some trade-off has to be made.
以前にリソースの最適な使用が困難であると考えられている可能スケーラブルなソリューションを設計し、この文書に記載されています。このように、マルチキャストVPNソリューションから期待されているものを考慮にいくつかのトレードオフを行わなければならないという事実をしながら、それはリソースの最適化の問題に対処していることです。
Moreover, it seems that a "one size fits all" trade-off probably does not exist either. Thus, a multicast VPN solution SHOULD offer service providers appropriate configuration settings that let them tune the trade-off according to their particular constraints (network topology, platforms, customer applications, level of service offered etc.).
また、トレードオフはおそらくどちらかが存在しません「ワンサイズは、すべてが収まる」ということらしいです。このように、マルチキャストVPNソリューションは、その特定の制約（ネットワークトポロジ、プラットフォーム、顧客のアプリケーションなどが提供するサービスのレベル）に応じて、サービスプロバイダに、彼らに曲を聞かせて、適切な構成設定のトレードオフを提供する必要があります。
As an illustration, here are some example bounds of the trade-off space:
実例として、ここではトレードオフの空間のいくつかの例の範囲は以下のとおりです。
Bandwidth optimization: setting up optimized core MDTunnels whose topology (PIM or P2MP LSP trees, etc.) precisely follows a customer's multicast routing changes. This requires managing a large amount of state in the core, and also quick reactions of the core to customer multicast routing changes. This approach can be advantageous in terms of bandwidth, but it is poor in terms of state management.
帯域幅の最適化：トポロジ（PIMまたはP2MP LSP木、等）最適化されたコアMDTunnelsの設定を正確に顧客のマルチキャストルーティング変化に追従します。これは、顧客のマルチキャストルーティングの変更にコアの迅速な反応をコアに状態を大量に管理し、かつ必要があります。このアプローチは、帯域幅の面で有利であることができますが、それは国家管理の面で劣っています。
State optimization: setting up MDTunnels that aggregate multiple customer multicast streams (all or some of them, across different VPNs or not). This will have better scalability properties, but at the expense of bandwidth since some MDTunnel leaves will very likely receive traffic they don't need, and because increased constraints will make it harder to find optimal MDTunnels.
状態の最適化：複数の顧客のマルチキャスト・ストリーム（全てまたはそのうちのいくつか、異なるVPN間またはしない）を集計MDTunnelsを設定します。これは、より優れた拡張性の性質を持っていますが、一部のMDTunnelの葉は非常に可能性の高いトラフィックを受信しますので、帯域幅を犠牲にして彼らが必要としない、と増加した制約が行いますので、それは難しい最適MDTunnelsを見つけること。
If the VPN service provides traffic engineering (TE) features for the connection used between PEs for unicast traffic in the VPN service, the solution SHOULD provide equivalent features for multicast traffic.
VPNサービスは、トラフィックエンジニアリング（TE）がVPNサービスでユニキャストトラフィックのためにPE間で使用される接続のための機能を提供した場合、溶液は、マルチキャストトラフィックのために同等の機能を提供するべきです。
A solution SHOULD offer means to support key TE objectives as defined in [RFC3272], for the multicast service.
[RFC3272]で定義されているソリューションは、マルチキャストサービスのために、キーTEの目標をサポートするための手段を提供する必要があります。
A solution MAY also usefully support means to address multicast-specific traffic engineering issues: it is known that bandwidth resource optimization in the point-to-multipoint case is an NP-hard problem, and that techniques used for unicast TE may not be applicable to multicast traffic.
ソリューションはまた、有効マルチキャスト固有のトラフィックエンジニアリングの問題に対処するための手段をサポートする可能性があります。ポイント・ツー・マルチポイントの場合における帯域幅リソースの最適化はNP困難な問題があることが知られており、ユニキャストTEのために使用される技術は、には適用できない可能性があることマルチキャストトラフィック。
Also, it has been identified that managing the trade-off between resource usage and scalability may incur uselessly sending traffic to some PEs participating in a multicast VPN. For this reason, a multicast VPN solution MAY permit that the bandwidth/state tuning take into account the relative cost or availability of bandwidth toward each PE.
また、リソース使用率とスケーラビリティの間のトレードオフを管理することは無駄マルチキャストVPNに参加し、いくつかのPEにトラフィックを送信被ることが確認されています。このため、マルチキャストVPNソリューションは、帯域幅/状態がチューニングを考慮に入れ、各PEに向けて帯域幅の相対的なコストや可用性を取ることを許可することができます。
Following the principle of separation between the control plane and the forwarding plane, a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent: the control plane SHALL NOT depend on which forwarding plane is used (and vice versa), and the choice of forwarding plane SHOULD NOT be limited by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology.
制御プレーンと転送プレーンとの間の分離の原理次制御および転送プレーンが相互に依存しないように、マルチキャストVPNソリューションを設計しなければならない：制御プレーンは、プレーンが使用される転送れ依存（及びその逆）ないもの、及びフォワーディングプレーンの選択は、ソリューションの設計によって限定されるべきではありません。また、解決策は、特定のトンネリング技術に縛られるべきではありません。
In a multicast VPN solution extending a unicast L3 PPVPN solution, consistency in the tunneling technology has to be favored: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast. Deployment consistency, ease of operation, and potential migrations are the main motivations behind this requirement.
ユニキャストL3 PPVPNソリューションを拡張マルチキャストVPNソリューションでは、トンネリング技術の一貫性が好まれなければならない。そのような溶液は、ユニキャストの場合とマルチキャストのための同一のトンネリング技術を使用することを可能にすべきです。展開の一貫性、操作の容易さ、および潜在的な移行は、この要件の背後にある主な動機です。
For MDTunnels, a solution SHOULD be able to use a range of tunneling technologies, including point-to-point and point-to-multipoint, such as:
MDTunnelsために、溶液は、以下のようなポイントツーポイントおよびポイントツーマルチポイントなどのトンネリング技術の範囲を使用できるようにする必要があります。
o Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in multicast IP trees),
O（IPマルチキャストツリーにGREを含む）を総称ルーティングカプセル化（GRE）[RFC2784]、
o MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP extensions to the Resource Reservation Protocol (RSVP) [P2MP-RSVP-TE] or Label Distribution Protocol (LDP) [P2MP-LDP-REQS] [P2MP-LDP]),
MPLS O [RFC3031]（P2PまたはMP2Pトンネル、およびリソース予約プロトコル（RSVP）[P2MP-RSVP-TE]またはラベル配布プロトコル（LDP）P2MP-LDP-REQS] [に対してMPLS P2MP拡張とシグナリングマルチポイントトンネルを含みますP2MP-LDP]）、
o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast [RFC4045]),
Oレイヤー2トンネリングプロトコル（L2TP）（マルチキャスト[RFC4045]のためにL2TPを含みます）、
o IPsec [RFC4031]
OのIPsec [RFC4031]
o IP-in-IP [RFC2003], etc.
O IPインIP [RFC2003]など
Naturally, it is RECOMMENDED that a solution is built so that it can leverage the point-to-multipoint variants of these techniques. These variants allow for packet replications to happen along a tree in the provider core network, and they may help improve bandwidth efficiency in a multicast VPN context.
当然、これらの技術のポイント・ツー・マルチポイントのバリアントを活用できるように、ソリューションが構築されていることが推奨されます。これらの変異体は、パケットの複製は、プロバイダーのコアネットワークのツリーに沿って起こることを可能にし、彼らは、マルチキャストVPNコンテキストにおける帯域幅の効率を向上させることがあります。
A solution SHOULD support a method that provides the minimum MTU of the MDTunnel (e.g., to discover MTU, to communicate MTU via signaling, etc.) so that:
溶液はMDTunnelの最小MTUを提供するメソッドをサポートすべきである（例えば、シグナリング、等を介してMTUを通信するために、MTUを発見する）ように。
o fragmentation inside the MDTunnel does not happen, even when allowed by the underlying tunneling technology
O MDTunnel内部の断片化は、基本的なトンネリング技術によって許可された場合でも、発生しません
o proper troubleshooting can be performed if packets that are too big for the MDTunnel happen to be encapsulated in the MDTunnel
MDTunnelため大きすぎるパケットが起こる場合は、O、適切なトラブルシューティングがMDTunnelにカプセル化するために行うことができます
The solution MUST provide some mechanisms to control the sources within a VPN. This control includes the number of sources that are entitled to send traffic on the VPN, and/or the total bit rate of all the sources.
溶液は、VPN内のソースを制御するために、いくつかのメカニズムを提供しなければなりません。このコントロールは、VPN上のトラフィックを送信する権利を有しているソースの数、および/またはすべてのソースの総ビットレートが含まれます。
At the reception level, the solution MUST also provide mechanisms to control the number of multicast groups or channels VPN users are entitled to subscribe to and/or the total bit rate represented by the corresponding multicast traffic.
受信レベルでは、溶液は、VPNユーザがを購読及び/又は対応するマルチキャストトラフィックで表される総ビットレートする権利がマルチキャストグループまたはチャネルの数を制御するためのメカニズムを提供しなければなりません。
All these mechanisms MUST be configurable by the service provider in order to control the amount of multicast traffic and state within a VPN.
すべてのこれらのメカニズムは、VPN内のマルチキャストトラフィックと状態の量を制御するために、サービスプロバイダによって構成可能でなければなりません。
Moreover, it MAY be desirable to be able to impose some bound on the quantity of state used by a VPN in the core network for its multicast traffic, whether on each P or PE router, or globally. The motivation is that it may be needed to avoid out-of-resources situations (e.g., out of memory to maintain PIM state if IP multicast is used in the core for multicast VPN traffic, or out of memory to maintain RSVP state if MPLS P2MP is used, etc.).
また、各P又はPEルータ上か、またはグローバルに、そのマルチキャストトラフィックのコアネットワークにVPNによって使用される状態量にいくらかのバウンドを課すことができることが望ましいかもしれません。動機は、IPマルチキャストがMPLS P2MP場合RSVP状態を維持するために、マルチキャストVPNトラフィックのため、またはメモリのうち、コアで使用されている場合PIM状態を維持するために、メモリのうち外のリソース状況（例えば、回避するために必要ことができることです）など、使用されています。
A solution MUST support inter-AS (Autonomous System) multicast VPNs, and SHOULD support inter-provider multicast VPNs. Considerations about coexistence with unicast inter-AS VPN Options A, B, and C (as described in Section 10 of [RFC4364]) are strongly encouraged.
溶液は、インターAS（自律システム）マルチキャストVPNをサポートしなければならない、と相互プロバイダマルチキャストVPNをサポートすべきです。ユニキャストAS間VPNオプションA、B、及び（[RFC4364]のセクション10に記載されているように）Cとの共存についての考慮事項が強く奨励されます。
A multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers, and keep the need for detailed knowledge of providers' networks to a minimum -- all this being in comparison with corresponding unicast VPN options.
マルチキャストVPNソリューションは、プロバイダ間の最小限の調整を必要とAS間のメカニズムを提供し、最小限にプロバイダのネットワークの詳細な知識の必要性を保つべきである - これはすべてのユニキャストVPNオプションの対応と比較しています。
o Within each service provider, the service provider SHOULD be able on its own to pick the most appropriate tunneling mechanism to carry (multicast) traffic among PEs (just like what is done today for unicast)
各サービスプロバイダの中でO、サービスプロバイダは、（マルチキャスト）を運ぶために最も適切なトンネリングメカニズムを選ぶために自分自身でできるようにすべきである（ただユニキャストのために、今日行われているものなど）のPE間のトラフィック
o If a solution does require a single tunnel to span P routers in multiple ASs, the solution SHOULD provide mechanisms to ensure that the inter-provider coordination to set up such a tunnel is minimized
溶液は、複数のASにPルータにまたがる単一のトンネルを必要とする場合は、O、溶液は、このようなトンネルを設定する間、プロバイダ調整が最小化されることを確実にするためのメカニズムを提供すべきです
Moreover, such support SHOULD be possible without compromising other requirements expressed in this requirement document, and SHALL NOT incur penalties on scalability and bandwidth-related efficiency.
また、このような支持体は、この要件文書で発現される他の要件を損なうことなく、可能でなければならず、スケーラビリティおよび帯域幅に関連する効率にペナルティを被るないもの。
A multicast VPN solution SHOULD give a VPN service provider the ability to offer, guarantee and enforce differentiated levels of QoS for its different customers.
マルチキャストVPNソリューションは、VPNサービスプロバイダーに、提供する保証とそのさまざまな顧客のためのQoSの差別化のレベルを強制する能力を与える必要があります。
The solution SHOULD provide the same level of security for the service provider as what currently exists for unicast VPNs (for instance, as developed in the Security sections of [RFC4364] and [VRs]). For instance, traffic segregation and intrinsic protection against DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks of the BGP/MPLS VPN solution must be supported by the multicast solution.
（[RFC4364]と[仮想ルーター]のセキュリティセクションに開発され、例えば）溶液は、現在、ユニキャストのVPNのために存在するもののようなサービス・プロバイダのセキュリティの同じレベルを提供すべきです。例えば、BGP / MPLS VPNソリューションのDoS攻撃（サービス妨害）攻撃やDDoS（サービス拒否の分散）攻撃に対するトラフィックの分離や固有の保護は、マルチキャストソリューションによってサポートされなければなりません。
Moreover, since multicast traffic and routing are intrinsically dynamic (receiver-initiated), some mechanism SHOULD be proposed so that the frequency of changes in the way client traffic is carried over the core can be bounded and not tightly coupled to dynamic changes of multicast traffic in the customer network. For example, multicast route dampening functions would be one possible mechanism.
マルチキャストトラフィックとルーティングが（受信器で開始）本質的に動的であるため、クライアントトラフィックがコア上に担持されている方法の変化の周波数が境界としっかりマルチキャストトラフィックの動的な変更に結合されていないことができるように、また、いくつかの機構が提案されてください顧客ネットワークインチ例えば、マルチキャストルートダンプニング機能は、一つの可能なメカニズムであろう。
Network devices that participate in the deployment and the maintenance of a given L3VPN MAY represent a superset of the participating devices that are also involved in the establishment and maintenance of the multicast distribution tunnels. As such, the activation of IP multicast capabilities within a VPN SHOULD be device-specific, not only to make sure that only the relevant devices will be multicast-enabled, but also to make sure that multicast (routing) information will be disseminated to the multicast-enabled devices only, hence limiting the risk of multicast-inferred DOS attacks.
展開と与えられたL3VPNのメンテナンスに参加し、ネットワークデバイスは、マルチキャスト配信トンネルの確立と維持に関与している参加するデバイスのスーパーセットを表すことができます。そのため、VPN内のIPマルチキャスト機能の活性化は、唯一の関連デバイスがマルチキャスト対応になることを確認するだけでなく、デバイス固有であるべきであるが、また、マルチキャスト（ルーティング）情報はに配布されることを確認しますマルチキャスト対応デバイスのみ、それゆえマルチキャスト推論DOS攻撃のリスクを制限します。
Traffic of a multicast channel for which there are no members in a given multicast VPN MUST NOT be propagated within the multicast VPN, most particularly if the traffic comes from another VPN or from the Internet.
何のメンバーが所定のマルチキャストVPNではありませんれるマルチキャストチャネルのトラフィックは、トラフィックを別のVPNまたはインターネットから来ているほとんどの場合は特に、マルチキャストVPN内を伝搬してはなりません。
Security considerations are particularly important for inter-AS and inter-provider deployments. In such cases, it is RECOMMENDED that a multicast VPN solution support means to ensure the integrity and authenticity of multicast-related exchanges across inter-AS or inter-provider borders. It is RECOMMENDED that corresponding procedures require the least possible coordination between providers; more precisely, when specific configurations or cryptographic keys have to be deployed, this shall be limited to ASBRs (Autonomous System Border Routers) or a subset of them, and optionally BGP Route Reflectors (or a subset of them).
セキュリティの考慮事項は相互ASおよびインタープロバイダの展開のために特に重要です。このような場合には、マルチキャストVPNソリューションのサポートはインターASまたはインタープロバイダの国境を越えたマルチキャスト関連交流の完全性と真正性を保証することを意味することが推奨されます。対応する手順は、プロバイダ間の最小限の調整を必要とすることをお勧めします。より正確には、特定の構成または暗号鍵を展開しなければならない場合、これは、のASBR（自律システム境界ルータ）、またはそれらのサブセットに限定されるものとし、必要に応じてBGPルートリフレクタ（またはそれらのサブセット）。
Lastly, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view.
最後に、セクション5.2.5に記載の制御機構は、ビューのこのインフラストラクチャのセキュリティの点から考慮されるべきでもあります。
Resiliency is also crucial to infrastructure security; thus, a multicast VPN solution SHOULD either avoid single points of failures or propose some technical solution making it possible to implement a fail-over mechanism.
弾力性もインフラストラクチャのセキュリティに不可欠です。このように、マルチキャストVPNソリューションは、単一障害点を回避するか、またはそれが可能フェイルオーバーメカニズムを実装することいくつかの技術的な解決策を提案すべきであるのいずれか。
As an illustration, one can consider the case of a solution that would use PIM-SM as a means to set up MDTunnels. In such a case, the PIM RP might be a single point of failure. Such a solution SHOULD be compatible with a solution implementing RP resiliency, such as anycast-RP [RFC4610] or BSR [PIM-BSR].
例示として、一つはMDTunnelsを設定する手段として、PIM-SMを使用する溶液の場合を考慮することができます。そのような場合には、PIM RPは単一障害点であるかもしれません。そのような溶液は、エニーキャスト-RPの[用RFC4610]またはBSR [PIM-BSR]としてRPの弾力性を、実装溶液と相溶性であるべきです。
The operation of a multicast VPN solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be a priority when designing a multicast VPN solution. Particularly, the operational burden of setting up multicast on a PE or for a VR/ VRF SHOULD be as low as possible.
マルチキャストVPNソリューションの動作が可能なような光、およびマルチキャストVPNソリューションを設計する際の優先順位であるべきである自動構成および発見を提供するようにしなければなりません。特に、PE上またはVR / VRFのマルチキャストを設定するための作業負担は可能な限り低くすべきです。
Also, as far as possible, the design of a solution SHOULD carefully consider the number of protocols within the core network: if any additional protocols are introduced compared with the unicast VPN service, the balance between their advantage and operational burden SHOULD be examined thoroughly.
また、可能な限り、ソリューションの設計は慎重にコアネットワーク内のプロトコルの数を考慮する必要があります任意の追加のプロトコルは、ユニキャストVPNサービスと比較して導入されている場合は、その利点と運用負荷のバランスを徹底的に調べるべきです。
Moreover, monitoring of multicast-specific parameters and statistics SHOULD be offered to the service provider, following the requirements expressed in [RFC4176].
また、マルチキャスト固有のパラメータと統計の監視は、[RFC4176]で表さ要件以下、サービスプロバイダに提供されるべきです。
Most notably, the provider SHOULD have access to:
最も顕著なのは、プロバイダがへのアクセス権を持っている必要があります。
o Multicast traffic statistics (incoming/outgoing/dropped/total traffic conveyed, by period of time)
Oマルチキャストトラフィック統計（着信/発信/ドロップ/総トラフィックは、時間の期間によって、搬送）
o Information about client multicast resource usage (multicast routing state and bandwidth usage)
Oクライアントマルチキャストリソースの使用状況（マルチキャストルーティング状態と帯域幅の使用）に関する情報
o Alarms when limits are reached on such resources
アラームO制限は、そのようなリソースに達したとき
o The IPPM (IP Performance Metrics [RFC2330])-related information that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc.
O IPPM（IPパフォーマンス・メトリック[RFC2330]） - 関連情報マルチキャストトラフィックの使用に関連している：そのような情報は、一方向のパケット遅延、パケット間の遅延変動、等を含みます
o Statistics on decisions related to how client traffic is carried on distribution tunnels (e.g., "traffic switched onto a multicast tree dedicated to such groups or channels")
クライアントトラフィックが配布トンネル上に担持される方法に関連する意思決定に関する統計O（例えば、「トラフィックは、そのようなグループまたはチャネル専用のマルチキャストツリーへの切り替え」）
o Statistics on parameters that could help the provider to evaluate its optimality/state trade-off
その最適/状態のトレードオフを評価するために、プロバイダを助けることができるパラメータに関する統計O
This information SHOULD be made available through standardized SMIv2 [RFC2578] Management Information Base (MIB) modules to be used with SNMP [RFC3411], or through IPFIX [IPFIX-PROT]. For instance, in the context of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs defined in [RFC4382] SHOULD be proposed, with proper integration with [RFC3811], [RFC3812], [RFC3813], and [RFC3814] when applicable.
この情報は、SNMP [RFC3411]で使用される標準のSMIv2 [RFC2578]管理情報ベース（MIB）モジュールを介して、またはIPFIX [IPFIX-PROT]を介して利用できるようにすべきです。例えば、BGP / MPLS VPNの[RFC4364]、[RFC4382]で定義されたMIBにマルチキャスト拡張の文脈において、[RFC3811]、[RFC3812]、[RFC3813]及び[RFC3814]適用と適切に統合して、提案されてください。
Mechanisms similar to those described in Section 5.2.12 SHOULD also exist for proactive monitoring of the MDTunnels.
セクション5.2.12に記載されたものと同様のメカニズムもMDTunnelsの積極的な監視のために存在すべきです。
Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be scalable with respect to the parameters mentioned in Section 5.2.2. In particular, it is RECOMMENDED that particular attention is given to the impact of monitoring mechanisms on performances and QoS.
マルチキャストVPNの提案されたOAMメカニズムおよび手順は、セクション5.2.2で述べたパラメータに関してスケーラブルであるべきです。特に、特定の注意が性能およびQoSに対する監視機構の影響を与えていることが推奨されます。
Moreover, it is RECOMMENDED that any OAM mechanism designed to trigger alarms in relation to performance or resource usage metrics integrate the ability to limit the rate at which such alarms are generated (e.g., some form of a hysteresis mechanism based on low/ high thresholds defined for the metrics).
また、性能またはリソース使用メトリクスに関連してアラームをトリガするために設計された任意のOAMメカニズムが定義された低/高閾値に基づいて、ヒステリシス機構（例えば、何らかの形のようなアラームが生成されるレートを制限する機能を統合することが推奨されますメトリックのため）。
It is a requirement that unicast and multicast services MUST be able to coexist within the same VPN.
これは、ユニキャストとマルチキャストサービスが同じVPN内に共存することができなければならない要件です。
Likewise, a multicast VPN solution SHOULD be designed so that its activation in devices that participate in the deployment and maintenance of a multicast VPN SHOULD be as smooth as possible, i.e., without affecting the overall quality of the services that are already supported by the underlying infrastructure.
マルチキャストVPNの導入と保守に参加デバイスでの活性化は、できるだけスムーズになるよう同様に、マルチキャストVPNソリューションは、すでに基礎となるでサポートされているサービスの全体的な品質に影響を与えずに、すなわち、設計すべきですインフラ。
A multicast VPN solution SHOULD prevent compatibility and migration issues, for instance, by focusing on providing mechanisms facilitating forward compatibility. Most notably, a solution supporting only a subset of the requirements expressed in this document SHOULD be designed to allow compatibility to be introduced in further revisions.
マルチキャストVPNソリューションは、フォワード互換性を容易にする機構を提供することに着目し、例えば、互換性および移行の問題を防止するはずです。最も顕著なのは、この文書で表現要件のサブセットのみをサポートするソリューションは、互換性がさらに改正で導入できるように設計する必要があります。
It SHOULD be an aim of any multicast VPN solution to offer as much backward compatibility as possible. Ideally, a solution would have the ability to offer multicast VPN services across a network containing some legacy routers that do not support any multicast VPN-specific features.
これは、任意のマルチキャストVPNソリューションの目的は、できるだけ多くの下位互換性を提供することであるべき。理想的には、解決策は、マルチキャストVPN固有の機能をサポートしていない一部のレガシールータを含むネットワークを介してマルチキャストVPNサービスを提供する能力を持っているでしょう。
In any case, a solution SHOULD state a migration policy from possibly existing deployments.
いずれにしても、解決策は、おそらく既存の展開から移行ポリシーを必ず明記してください。
A multicast VPN solution that dynamically adapts the way some client multicast traffic is carried over the provider's network may incur the disadvantage of being hard to troubleshoot. In such a case, to help diagnose multicast network issues, a multicast VPN solution SHOULD provide monitoring information describing how client traffic is carried over the network (e.g., if a solution uses multicast-based MDTunnels, which provider multicast group is used for a given client multicast stream). A solution MAY also provide configuration options to avoid any dynamic changes, for multicast traffic of a particular VPN or a particular multicast stream.
動的にいくつかのクライアントのマルチキャストトラフィックは、トラブルシューティングするのは難しいという欠点が発生する可能性があり、プロバイダのネットワーク上で行われている方法を適応マルチキャストVPNソリューション。そのような場合には、マルチキャストネットワークの問題を診断するために、マルチキャストVPNソリューションは、ソリューションプロバイダのマルチキャストグループが指定するために使用されているマルチキャストベースMDTunnelsを、使用している場合、クライアントのトラフィックは、例えば（ネットワーク上で行われる方法を記述する情報を監視提供するべきですクライアントのマルチキャストストリーム）。解決策は、特定のVPNまたは特定のマルチキャストストリームのマルチキャストトラフィックのために、任意のダイナミックな変化を避けるために、設定オプションを提供することができます。
Moreover, a solution MAY provide mechanisms that allow network operators to check that all VPN sites that advertised interest in a particular customer multicast stream are properly associated with the corresponding MDTunnel. Providing operators with means to check the proper setup and operation of MDTunnels MAY also be provided (e.g., when P2MP MPLS is used for MDTunnels, troubleshooting functionalities SHOULD integrate mechanisms compliant with [RFC4687], such as LSP Ping [RFC4379][LSP-PING]). Depending on the implementation, such verification could be initiated by a source-PE or a receiver-PE.
また、解決策は、ネットワークオペレータは、特定の顧客マルチキャストストリームに関心をアドバタイズされたすべてのVPNサイトが適切に対応MDTunnelに関連付けられていることを確認することを可能にするメカニズムを提供することができます。 MDTunnelsの適切なセットアップや操作を確認する手段をオペレータに提供することもP2MP MPLSをMDTunnelsのために使用される場合（例えば、トラブルシューティング機能は、LSP Pingのように、[RFC4379]を[RFC4687]に準拠したメカニズムを統合する必要が提供されてもよい[LSP-PING ]）。実装に応じて、そのような検証は、ソース-PEまたは受信-PEによって開始することができます。
This document does not by itself raise any particular security issue.
このドキュメントは、それ自体で、特定のセキュリティ上の問題を提起しません。
A set of security issues has been identified that MUST be addressed when considering the design and deployment of multicast-enabled L3 PPVPNs. Such issues have been described in Section 5.1.5 and Section 5.2.8.
セキュリティ問題のセットは、マルチキャスト対応のL3 PPVPNsの設計と導入を検討する際に対処する必要があることを確認されています。このような問題は、5.1.5項および5.2.8項に記載されています。
The main contributors to this document are listed below, in alphabetical order:
このドキュメントの主な要因は、アルファベット順に、以下の通りです：
o Christian Jacquenet France Telecom 3, avenue Francois Chateau CS 36901 35069 RENNES Cedex, France Email: christian.jacquenet@orange-ftgroup.com
OクリスチャンJacquenetフランステレコム3、大通りフランソワ・シャトーCS 36901 35069のレンヌセデックス、フランスEメール：christian.jacquenet@orange-ftgroup.com
o Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan Email: y.kamite@ntt.com
お ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん ときょ おぺら しｔｙ とうぇｒ ３ー２０ー２ にし しんじゅく、 しんじゅくーく ときょ １６３ー１４２１、 じゃぱん えまいｌ： ｙ。かみて＠んっｔ。こｍ
o Jean-Louis Le Roux France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: jeanlouis.leroux@orange-ftgroup.com
Oジャン=ルイ・ルーフランステレコムR＆D 2、大通りピエールMarzin 22307ラニオンセデックス、フランスEメール：jeanlouis.leroux@orange-ftgroup.com
o Nicolai Leymann Deutsch Telecom Engineering Networks, Products & Services Goslarer Ufer 3510589 Berlin, Germany Email: nicolai.leymann@t-systems.com
OニコライLeymannドイツテレコムエンジニアリングネットワーク、製品＆サービスGoslarerウーファー3510589ベルリン、ドイツEメール：nicolai.leymann@t-systems.com
o Renaud Moignard France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: renaud.moignard@orange-ftgroup.com
OルノーMoignardフランステレコムR＆D 2、大通りピエールMarzin 22307ラニオンセデックス、フランスEメール：renaud.moignard@orange-ftgroup.com
o Thomas Morin France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: thomas.morin@orange-ftgroup.com
Oトーマス・モリンフランステレコムR＆D 2、大通りピエールMarzin 22307ラニオンセデックス、フランスEメール：thomas.morin@orange-ftgroup.com
The authors would like to thank, in rough chronological order, Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka
著者は、大まかな年代順に、ヴィンセントパフェ、ズバイルアフマド、エロディHemon-Larreur、セバスチャンLoye、ラウール・アガーウォール、仁福田、Luyuan牙、エードリアンファレル、ダニエル・キング、Yiqunカイ、ロナルドBonica、レンニーマンに感謝したいと思います悟松島、ネサワルコヨトルオルネラス、ヤコフ・レックター、マーシャルユーバンクス、ペッカ
Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, valuable input, and feedback.
Savola、ベンジャミン・ニーヴン・ジェンキンス、とトーマスナドー、そのレビュー、貴重な入力、およびフィードバックのために。
We also thank the people who kindly answered the survey, and Daniel King, who took care of gathering and anonymizing its results.
また、その結果を収集し、匿名の世話をした親切にアンケートに答えて、ダニエル・キング人々に、感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031] Carugi、M.とD. McDysan、 "レイヤ3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのサービスの要件"、RFC 4031、2005年4月。
[RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションとL.とT.マドセン、 "プロバイダ・プロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176]エルMghazli、Y.、ナドー、T.、Boucadair、M.、チャン、K.、およびA. Gonguet、RFC 4176、 "レイヤ3仮想プライベートネットワーク（L3VPN）運用と管理のための枠組み" 2005年10月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]アダムス、A.、ニコラス、J.、およびW. Siadak、 "プロトコル独立マルチキャスト - 稠密モード（PIM-DM）：プロトコル仕様（改訂）"、RFC 3973、2005年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[VRs] Ould-Brahim, H., "Network based IP VPN Architecture Using Virtual Routers", Work in Progress, March 2006.
、進歩、2006年3月に仕事[のVR]ウルド - Brahimの、H.、「仮想ルーターを使用してIP VPNアーキテクチャをベースとネットワーク」。
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[RFC2432] Dubray、K.、RFC 2432、1998年10月 "IPマルチキャストベンチマーキングのための用語"。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[P2MP-RSVP-TE] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", Work in Progress, August 2006.
[P2MP-RSVP-TE]アガルワル、R.は、進捗状況、2006年8月に、仕事を "拡張機能は、ポイント・ツー・マルチポイントTE LSPのための-TEをRSVPに"。
[PIM-BSR] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006.
[PIM-BSR] Bhaskar、N.、 "PIMのためのブートストラップルータ（BSR）メカニズム"、進歩、2006年6月に作業。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]ファリナッチ、D.およびY.カイ、RFC 4610、2006年8月 "Protocol Independent Multicast（PIM）を使用してエニーキャストRP-"。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3446]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "エニーキャストRendevousポイント（RP）プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を用いた機構" を、RFC 3446 、2003年1月。
[P2MP-LDP] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, October 2006.
[P2MP-LDP] Mineiは、I.は、進歩、2006年10月に、仕事を「のラベル配布プロトコルの拡張機能は、ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチラベルパスの交換しました」。
[P2MP-LDP-REQS] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", Work in Progress, June 2006.
[P2MP-LDP-REQS]ルー、J.、「ラベル配布プロトコルへのポイント・ツー・マルチポイント機能拡張のための要件」、進歩、2006年6月での作業。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687]安川、S.、ファレル、A.、キング、D.、およびT.ナドー、 "操作とポイントツーマルチポイントMPLSネットワークの管理（OAM）要件"、RFC 4687、2006年9月。
[BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.
[BIDIR-PIM]ハンドリー、M.、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、進歩、2005年10月に作業。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment", RFC 3353, August 2002.
[RFC3353] Ooms、D.、販売、B.、Livens、W.、アチャリヤ、A.、Griffoul、F.、およびF.アンサリ、 "マルチプロトコルラベルでのIPマルチキャストの概要（MPLS）環境の切り替え" 、RFC 3353、2002年8月。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[RFC3272] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.、およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272、2002年5月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[IPFIX-PROT] Claise, B., "Specification of the IPFIX Protocol for the Exchange", Work in Progress, November 2006.
[IPFIX-PROT] Claise、B.、 "ExchangeのIPFIXプロトコルの仕様"、進歩、2006年11月に作業。
[RFC4045] Bourdon, G., "Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)", RFC 4045, April 2005.
[RFC4045]ブルドン、G.、 "レイヤ2トンネリングプロトコル（L2TP）にマルチキャストトラフィックの効率的なキャリングをサポートする拡張機能"、RFC 4045、2005年4月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider-Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809] Nagarajan、A.、 "プロバイダ・プロビジョニングされた仮想プライベートネットワークのための一般的要件（PPVPN）"、RFC 3809、2004年6月。
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811]ナドー、T.、およびJ. Cucchiara、RFC 3811、2004年6月 "マルチプロトコルラベルスイッチング（MPLS）管理のためのテキストの表記法（TCS）の定義"。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]スリニバサン、C.、Viswanathanの、A.、およびT.ナドーは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルータ（LSR）管理情報ベース（MIB）"、RFC 3813、2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
[RFC3814]ナドー、T.、スリニヴァサン、C.、およびA. Viswanathanの、 "マルチプロトコルラベルスイッチング（MPLS）、転送等価クラスへのネクストホップラベル転送エントリ（FEC-TO-NHLFE）管理情報ベース（MIB）"、RFC 3814、2004年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for spatial and multicast", Work in Progress, October 2006.
[MULTIMETRICS] "空間とマルチキャストのためのIPパフォーマンス・メトリック（IPPM）" ステファン、E.、進歩、2006年10月に作業。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]マイヤー、D.およびP. Lothberg、 "8分の233にアドレッシングGLOP"、BCP 53、RFC 3180、2001年9月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", RFC 4382, February 2006.
[RFC4382]ナドー、T.とH.ファンデリンデ、 "MPLS / BGPレイヤ3仮想プライベートネットワーク（VPN）管理情報ベース"、RFC 4382、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol", Work in Progress, September 2006.
[LSP-PING]ファレル、A.とS.安川、「ポイント・ツー・マルチポイントマルチプロトコルで検出データプレーン障害」、進歩、2006年9月での作業。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]、RFC 4459 Savola、P.、 "イン・ネットワークのトンネリングを使用したMTUと断片化の問題"、2006年4月。
Author's Address
著者のアドレス
Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France
トーマス・モリン（編集者）フランステレコムR＆D 2、大通りピエールMarzin 22307ラニオンフランス
EMail: thomas.morin@orange-ftgroup.com
メールアドレス：thomas.morin@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。