[要約] RFC 4834は、レイヤー3のプロバイダ提供仮想プライベートネットワーク（PPVPN）におけるマルチキャストの要件を定義しています。このRFCの目的は、PPVPN環境でのマルチキャストのサポートに関するガイドラインを提供することです。
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）The IETF Trust（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
o 新しいVPNメンバーを追加するには、制限された構成努力のみが必要なため
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マルチキャストベースのサービスをサポートする必要性が高まっています。特に、プロトコル独立マルチキャスト（PIM）およびインターネットグループ管理プロトコル（IGMP）の定義につながった標準化団体で、効率的なIPマルチキャストルーティングプロトコルとマルチキャストグループ管理を提供する努力が行われました。
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マルチキャストに基づくサービスのPPVPN内での展開に固有の追加要件を指定することにより、一般的な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.
読者は、[RFC4031]、[RFC4364]、[RFC4601]、および[RFC4607]で定義されている用語に精通していると想定されていますが、次の用語の用語は価値があるかもしれません。
We also propose here generic terms for concepts that naturally appear when multicast in VPNs is discussed.
また、VPNSのマルチキャストが議論されているときに自然に表示される概念の一般的な用語をここで提案します。
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：IPマルチキャスト機能をサポートするVPN、つまり、一部のPEデバイス（すべてではないにしても）がマルチキャスト対応であり、コアアーキテクチャがマルチキャスト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ルーティングと転送テーブル」、および[VRS]用語で定義されている「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にトラフィックを指定します。
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：Rendezvous Point（Protocol Independent Multicast -Sparse Mode（PIM -SM）[RFC4601]）。
P2MP, MP2MP: Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees.
P2MP、MP2MP：「Point-to-Multipoint」および「Multipoint-to-Multipoint」レプリケーションツリーを指定します。
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.
VPNの側面に特に関連する用語の詳細については、マルチキャストパフォーマンスまたはサービス品質（QOS）関連の用語については[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
マルチキャストトラフィックをサポートするソリューションは、プロバイダーネットワーク全体のポイントツーポイントトンネルで構成され、トラフィックを複製するためにPES（プロバイダーエッジルーター）が必要です。これは明らかに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]や[VRS]など）への拡張として自分自身を定義し、それらとの一貫性を保持することも理にかなっていますが、これはコア要件ではありません。
The requirements in this document are equally applicable to IPv4 and IPv6, for both customer- and provider-related matters.
このドキュメントの要件は、顧客とプロバイダー関連の問題の両方について、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
o 多くのレシーバーへの1つまたは少数のソース
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/s（たとえば、オーディオまたは低品質のビデオメディア）と数十のMB/s（高品質のビデオ）の間で異なる場合があります。数百のMB/s。
o QoS requirements include, in many cases, a low multicast group join delay
o QoS要件には、多くの場合、マルチキャストグループの結合遅延が低いことが含まれます
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 遅延感度はアプリケーションに依存します。一部のアプリケーションはそれほど遅延感度（放送テレビなど）ではありませんが、他のアプリケーションは非常に低い遅延を必要とする場合があります（プロのスタジオアプリケーション）
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).
このシナリオのサブケースは、VPNSのサイトの数（たとえば、ビデオ会議や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).
このISPシナリオは、すべてのVPNに対してIP-Multicast接続が提案される展開シナリオです。顧客がVPNを要求する場合、このVPNはデフォルトでIPマルチキャストをサポートします。この場合、マルチキャストVPNの数はVPNの数に等しくなります。これは、非常に重要なスケーラビリティ要件を意味します（たとえば、数百のPE、PEあたり数百のVPN、将来1桁増加する可能性があります）。
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).
調査結果から、幅広い期待が見られます。極端な答えがあります：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〜1,000の範囲の多数のマルチキャスト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.
調査回答の大部分は、約10個のPEあたりの多数のマルチキャストVPNを表しています（5〜50の8回の応答）。それらのかなりの数（4）は、PEあたり数百または数千（1つの応答）のマルチキャストVPNを備えた展開を期待しています。
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).
調査回答は、PEあたりマルチキャストVPNあたり1〜2000 CESに及びます。ほとんどの典型的な応答は、10（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).
ソリューションは、PEごとに数百のマルチキャストVPNあたりの多数のCEをサポートする必要があります（数千の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).
調査に回答した人は、通常、数百のPES（6回の応答）または数十PE（4回の応答）の範囲のマルチキャストVPNあたりのPES数の展開を期待しています。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ごとに数百のPESをサポートする必要があり、数千人まで有用にスケールアップする場合があります。
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).
ソースに接続されるPES（VPNごと）の数は、VPNあたりのPESの数よりも大幅に低いようです。これは明らかに、多くの回答者がコンテンツブロードキャストアプリケーションに関連する展開に言及したという事実に関連しています（1人から多く）。
Typical numbers are tens (6 responses) or hundreds (4 responses) of source-connected PEs. One respondent expected a higher number of several thousands.
典型的な数値は、10個（6回の応答）または数百（4回の応答）のソース接続PESです。ある回答者は、数千人の数が多いと予想していました。
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ごとに数百のソース接続PESをサポートする必要があります。多くのアプリケーションを含むいくつかの展開シナリオでは、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.
調査では、受信機のPESの数は、マルチキャストVPNのPES数と同じ桁であると予想されています。これは、ソースのみの参加者がほとんどいないほとんどのマルチキャストアプリケーションの本質的な性質と一致しています。
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 PPVPN内の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を使用している顧客）とサービスプロバイダーの2つの異なる重要なエンティティの象徴を取りました。
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.
その結果、セクション5.1.1には、CEとその直接接続された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-DENSEモード（DM）[RFC3973]、およびIgMPv3 [RFC3376]が含まれます（このバージョンは、IgMPV1 [RFC112]またはIgMPV1 [RFC112]または実装のみを暗黙的にサポートします。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.
これらのプロトコルの中で、PIM-SM（SSMモデルを含む）およびIGMPV3（IPv4ソリューション用）および/またはマルチキャストリスナーディスカバリーバージョン2（MLDV2）[RFC3810]（IPv6ソリューションの場合）のいずれかのサポートが必要です。PE-CEインターフェイスでのBidir-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.
IPv6ユニキャストをサポートするVPNソリューションにマルチキャスト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.
まず、[RFC4031]のセクション5.5で表されたL3VPNのQOに関する一般的な考慮事項もこのセクションに関連しています。
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]メカニズムの恩恵を受けるものとします。したがって、そのような機能は、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.
マルチキャストはTV放送などの高品質のサービスを提供するためによく使用されるため、マルチキャストVPNソリューションは、帯域幅の予約や入場制御などの高いQOをサポートするための追加機能を提供する場合があります。
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.
また、マルチキャスト受信が受信機トリガーであることを考慮すると、グループ結合遅延（[RFC2432]で定義されている）も1つの重要なQoSパラメーターと見なされます。したがって、この点でマルチキャスト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.
グループの休暇（[RFC2432]で定義されているように）は、いくつかの使用シナリオのCE-PEリンクでも重要な場合があります。マルチキャストストリームの典型的な帯域幅がPE-CEリンクの帯域幅に近い場合、2つの異なるハイスループットマルチキャストストリーム間を高速に切り替えることができるように、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]で定義されているL3VPNの運用と管理（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]）が含まれる場合があります。そのような情報には、一方向パケット遅延、パケット間遅延の変動などが含まれます。
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ソリューションにより、顧客は現在のリソース使用（マルチキャストルーティング状態とスループット）を見つけ、使用が合意された範囲を超えた場合に何らかのフィードバックを受け取ることができます。この問題がPE-CEインターフェイスのプロトコルレベルまたはサービス管理レベルインターフェイス[RFC4176]でより適切に処理されるかどうかは、さらなる議論のために残されています。
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
o VRF / vrあたり
o per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR)
o PER CEインターフェイス（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 添付のCESの背後にあるレシーバーは、構成されたエクストラネットVPNSのセットで調達したマルチキャストトラフィックを受信できます
o sources behind attached CEs can reach multicast traffic receivers located in the configured set of extranet VPNs
o 添付のCESの背後にあるソースは、構成されたエクストラネットVPNSのセットにあるマルチキャストトラフィックレシーバーに到達できます
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
o 他のVPNへのユニキャスト接続を有効にすることは、その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
o 別のVPNとのマルチキャスト接続を有効にすることは、厳密な最小限のユニキャストルーティングを超えてはならないはずです。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
o 別のVPNからのユニキャストルートがVR/VRFにインポートされている場合、マルチキャストリバースパス転送（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]や[VRS]などの多くのL3 PPVPNソリューションは、「キャリアのキャリア」モデルを定義します。ここでは、「キャリアのキャリア」サービスプロバイダーが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 VPNS [RFC4364]などのMPLSベースのL3VPN展開のコンテキストでは、MPLSラベル分布がPE-CEレベルで発生することを意味し、サブキャリアにマルチポイントLSPをトンネリングとして使用する能力を与えます。機構。
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（またはBidir-PIM）がVPNカスタマー側のASMモードで使用される場合、RP関数（またはBidir-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が外部委託されている場合（たとえば、PES）ケースを考慮する必要があることを意味します。その結果、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]).
PIM-SM（ASMモード）とBidir-PIMの適切な動作には、RP関数（またはアドレス）の可用性が必要です。レシーバーまたはソースからRPへの接続の損失は、マルチキャストサービスに影響を与えます。このため、BSR [PIM-BSR]またはAnycast-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を介して透過的に動作する必要があり、関連する場合は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）A）MVPN内のすべてのサイト間でASMマルチキャストサービスを維持する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.
PIM-SMの場合、ソースがグループに向かってトラフィックを発し始めたとき（ASMモード）、ソースとレシーバーがRPとは異なるVPNサイトに配置されている場合、トラフィックは一時的に2回流れる場合があります。RPのSPネットワークと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内でのみ使用されるサービスのために、マルチキャストの管理的にスコープ範囲（[RFC2365]で定義されている239/8）の使用と、SSM-rangeアドレス（232/8が定義された232/8）の使用を意味します。[RFC4607]またはグローバルに割り当てられたグループアドレス（例：GLOP [RFC3180]、233/8）によって、VPNの外側にトラフィックが送信される可能性があるサービスのために。
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ソリューションを設計する必要があります。実際には：oマルチキャストVPNソリューションのカプセル化オーバーヘッドを最小限に抑える必要があります。そうすれば、顧客デバイスには可能な限り断片化や再組み立てアクティビティがないようにする必要があります。
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ソリューションは、パスMTU発見メカニズムと互換性がある必要があり（[RFC1191]および[RFC4459]を参照）、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顧客マルチキャストパケット用の最低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]および仮想ルーター[VRS]モデルでは、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ルーターのコントロールプレーンでリソースを使用します（メモリおよび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
o PESの数
o the number of customer VPNs (total and per PE)
o 顧客VPNの数（合計およびPEあたり）
o the number of PEs and sites in any VPN
o 任意のVPNのPEとサイトの数
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)
o 顧客サイト（またはマルチキャストセッションから顧客）を追加または削除するためにPEおよびPルーターで必要なコントロールプレーン処理の量
o the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
o 使用されるマルチキャストIPアドレスの数（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.
ユニキャストの代わりにマルチキャストの使用の目的の1つは、ネットワークでのリソース最適化です。
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つの明らかな準最適な動作は、不必要な複製です（同じデータがリンクで2倍以上移動する場合、たとえば、PEレプリケーションをイングレスするとき）と不必要な受信（たとえば、トラフィックを受信する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.).
さらに、「1つのサイズがすべてに適合する」トレードオフもおそらく存在しないようです。したがって、マルチキャスト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.
状態最適化：複数の顧客マルチキャストストリームを集約するMDTUNNELS（すべてまたは一部、異なるVPNにまたがるかどうか）を設定します。これはより良いスケーラビリティプロパティを備えていますが、一部のMDTunnelの葉は必要ないトラフィックを受け取る可能性が非常に高いため、帯域幅を犠牲にします。また、制約の増加は最適なMdtunnelを見つけるのが難しくなるためです。
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サービスが、VPNサービスのユニキャストトラフィックにPES間で使用される接続にトラフィックエンジニアリング（TE）機能を提供する場合、ソリューションはマルチキャストトラフィックに同等の機能を提供する必要があります。
A solution SHOULD offer means to support key TE objectives as defined in [RFC3272], for the multicast service.
ソリューションは、マルチキャストサービスのために[RFC3272]で定義されている主要な目標をサポートする手段を提供する必要があります。
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 一般的なルーティングカプセル化（GRE）[RFC2784]（マルチキャストIPツリーのGREを含む）、
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]),
o -LDP]）、
o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast [RFC4045]),
o レイヤー-2トンネルプロトコル（L2TP）（マルチキャストのL2TPを含む[RFC4045]）、
o IPsec [RFC4031]
o ipsec [rfc4031]
o IP-in-IP [RFC2003], etc.
o IP-in-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
o MDTunnelに大きすぎるパケットが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ルーターであろうとグローバルであろうと、マルチキャストトラフィックのために、コアネットワーク内のVPNが使用する状態の量に何らかのバウンドを課すことができることが望ましい場合があります。動機は、リソース外の状況を避けるために必要になる可能性があるということです（たとえば、マルチキャストVPNトラフィックのコアでIPマルチキャストが使用されている場合、またはMPLS P2MPの場合はRSVP状態を維持するためにメモリを維持するために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をサポートする必要があります。Unicast Inter-AS VPNオプションA、B、およびC（[RFC4364]のセクション10で説明）との共存に関する考慮事項は、強く奨励されています。
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 各サービスプロバイダー内で、サービスプロバイダーは、PES間で（マルチキャスト）トラフィックを運ぶための最も適切なトンネリングメカニズムを選択できるようにする必要があります（ユニキャストのために今日行われているように）
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
o ソリューションが複数のASSでPルーターをスパンするために単一のトンネルを必要とする場合、ソリューションは、そのようなトンネルをセットアップするための間のプロバイダーの調整が最小化されることを保証するメカニズムを提供する必要があります
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サービスプロバイダーに、さまざまな顧客に差別化されたレベルのQOを提供、保証、および実施する機能を提供する必要があります。
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.
ソリューションは、ユニキャストVPNに現在存在するものと同じレベルのセキュリティを提供する必要があります（たとえば、[RFC4364]および[VRS]のセキュリティセクションで開発されたように）。たとえば、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.
さらに、マルチキャストトラフィックとルーティングは本質的に動的であるため（受信機が開始）、クライアントトラフィックの運ばれる方法の変化の頻度を境界線に制限し、マルチキャストトラフィックの動的な変化にしっかりと結合しないように、いくつかのメカニズムを提案する必要があります。カスタマーネットワークで。たとえば、マルチキャストルートの減衰機能は、可能なメカニズムの1つです。
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].
イラストとして、PIM-SMをMDTunnelsをセットアップする手段として使用するソリューションの場合を考慮することができます。そのような場合、PIM RPは単一の障害ポイントである可能性があります。このようなソリューションは、AnyCast-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]で定義されたMIBSのマルチキャスト拡張機能を提案する必要があります。。
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.
提案されたOAMメカニズムとマルチキャストVPNの手順は、セクション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の適切なセットアップと操作を確認する手段をオペレーターに提供することも提供される場合があります（たとえば、MDTunnelsにP2MP MPLSが使用される場合、トラブルシューティング機能は、LSP Ping [RFC4379] [LSP-Ping-Pingなどの[RFC4687]に準拠したメカニズムを統合する必要があります。]）。実装に応じて、そのような検証は、Source-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 PPVPNの設計と展開を検討する際に対処する必要がある一連のセキュリティ問題が特定されています。このような問題は、セクション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 クリスチャンジャックエネットフランステレコム3、アベニューフランソワシャトーCS 36901 35069レンヌセデックス、フランスメール：churtian.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 Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku、Shinjuku-Ku Tokyo 163-1421、日本メール：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 Jean-Louis Le Roux France Telecom R＆D 2、Avenue Pierre-Marzin 22307 Lannion Cedex、France Email：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 ニコライレイマンドイツテレコムエンジニアリングネットワーク、製品＆サービスGoslarer Ufer 3510589ベルリン、ドイツメール：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 Renaud Moignard France Telecom R＆D 2、Avenue Pierre-Marzin 22307 Lannion Cedex、France Email：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、アベニューピエールマルツィン22307ラニオンセデックス、フランスメール：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 Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, valuable input, and feedback.
著者は、大まかな年代順に、ヴィンセントパフェ、ズバイアアフマド、エロディーヘモン - ラーラー、セバスチャンロイ、ラーフルアグーワル、富士、ルユアンファン、エイドリアンファーレル、ダニエルキング、イクンカイSatoru Matsushima、Netzahualcoyotl Ornelas、Yakov Rekhter、Marshall Eubanks、Pekka Savola、Benjamin Niven-Jenkins、およびThomas Nadeauは、レビュー、貴重な入力、フィードバックを。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。and 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] Andersson、L。およびT. Madsen、「プロバイダーがプロビジョニングした仮想プライベートネットワーク（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] Fenner、B.、Handley、M.、Holbrook、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] Holbrook、H。およびB. Cain、「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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、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] El Mghazli、Y.、Nadeau、T.、Boucadair、M.、Chan、K。、およびA. Gonguet、「レイヤー3仮想プライベートネットワーク（L3VPN）運用と管理のフレームワーク」、RFC 4176、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] Adams、A.、Nicholas、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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[VRs] Ould-Brahim, H., "Network based IP VPN Architecture Using Virtual Routers", Work in Progress, March 2006.
[VRS] Oould-Brahim、H。、「仮想ルーターを使用したネットワークベースのIP VPNアーキテクチャ」、2006年3月、進行中の作業。
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[RFC2432] Dubray、K。、「IPマルチキャストベンチマークの用語」、RFC 2432、1998年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、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] Aggarwal、R。、「ポイントツーマルチポイントTE LSPのRSVP-TEへの拡張」、2006年8月、進行中の作業。
[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] Farinacci、D。およびY. Cai、「プロトコル独立マルチキャスト（PIM）を使用したAnycast-RP」、RFC 4610、2006年8月。
[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] Kim、D.、Meyer、D.、Kilmer、H。、およびD. Farinacci、「Anycast Rendevous Point（RP）メカニズムプロトコル独立マルチキャスト（PIM）およびマルチキャストソースディスカバリープロトコル（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] MIGIEI、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] Roux、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] Yasukawa、S.、Farrel、A.、King、D。、およびT. Nadeau、「ポイントツーマルチポイントMPLSネットワークの運用および管理（OAM）要件」、RFC 4687、2006年9月。
[BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.
[Bidir-Pim] Handley、M。、「Bi-Directional Protocol Independent Multicast（Bidir-PIM）」、2005年10月の作業。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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.、Sales、B.、Livens、W.、Acharya、A.、Griffoul、F.、およびF. Ansari、「マルチプロトコルラベルスイッチング（MPLS）環境におけるIPマルチキャストの概要」、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.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（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] Bourdon、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] Nadeau、T。およびJ. Cucchiara、「マルチプロトコルラベルスイッチング（MPLS）管理のテキストコンベンション（TCS）の定義」、RFC 3811、2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Nadeau、T.、Srinivasan、C。、およびA. Viswanathan、「マルチプロトコルラベルスイッチング（MPLS）転送等価クラスへの次のホップラベル転送エントリ（FEC-to-NHLFE）管理情報ベース（MIB）」、RFC3814、2004年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、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] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for spatial and multicast", Work in Progress, October 2006.
[Multimetrics] Stephan、E。、「Spatial and MulticastのIPパフォーマンスメトリック（IPPM）」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180] Meyer、D。およびP. Lothberg、「233/8での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] Harrington、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.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Nadeau、T。およびH. van der Linde、「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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol", Work in Progress, September 2006.
[LSP-Ping] Farrel、A。およびS. Yasukawa、「ポイントツーマルチポイントマルチプロトコルでのデータプレーンの障害の検出」、2006年9月、進行中の作業。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459] Savola、P。、「ネットワーク内トンネルに関するMTUおよび断片化の問題」、RFC 4459、2006年4月。
Author's Address
著者の連絡先
Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France
トーマス・モリン（編集者）フランステレコムR＆D 2、アベニューピエールマルジンラニオン22307フランス
EMail: thomas.morin@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。