RFC4834 日本語訳
4834 Requirements for Multicast in Layer 3 Provider-ProvisionedVirtual Private Networks (PPVPNs). T. Morin, Ed.. April 2007. (Format: TXT=80341 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Morin, Ed. Request for Comments: 4834 France Telecom R&D Category: Informational April 2007
ワーキンググループのT.モーリン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4834年のフランス電子通信研究開発カテゴリ: 情報の2007年4月
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).
IETFが信じる著作権(C)(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.
このドキュメントはLayer3(L3)のプロバイダーで食糧を供給されたVirtual兵士のNetworks(PPVPNs)の中でIPマルチキャストの展開を許すネットワークソリューションのための1セットの機能条件書を提示します。 それはエンドユーザとサービスプロバイダー見地からの要件を指定します。 そのようなVPNsの中でIPマルチキャストのサポートを指定する潜在的解決策がガイドラインとしてこれらの要件を使用することを意図します。
Morin Informational [Page 1] RFC 4834 L3VPN Mcast Reqs April 2007
[1ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 コンベンションは本書では.52.1を使用しました。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 2.2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . 6 3。 問題声明. . . . . . . . . . . . . . . . . . . . . . 7 3.1。 動機. . . . . . . . . . . . . . . . . . . . . . . 7 3.2。 一般要件. . . . . . . . . . . . . . . . . . . 7 3.3。 リソース利用. . . . . . . 8 4を最適化することに対して比例します。 ケース. . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1を使用してください。 シナリオ. . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1。 ライブ満足している放送. . . . . . . . . . . . . . . . 9 4.1.2。 左右対称のアプリケーション. . . . . . . . . . . . . . . . 10 4.1.3。 情報配給. . . . . . . . . . . . . . . . . . 10 4.1.4。 一般的なマルチキャストVPNは.114.2を提供します。 スケーラビリティ桁. . . . . . . . . . . . . 11 4.2の.1。 マルチキャストがあるVPNsの数は.2に.114.2を可能にしました。 PE. . . . . . . . . . . 12 4.2.3あたりのマルチキャストVPNsの数。 PE. . . . . . . . 12 4.2.4あたりのマルチキャストVPNあたりのCEsの数。 マルチキャストVPN. . . . . . . . . . . . . . . . 12 4.2.5あたりのPEs。 マルチキャストVRFs. . . . . . . . . . . . . . . 13 4.2.6があるPEs。 .135に出典を明示された流れの数。 L3 PPVPNs. . 13 5.1の中でIPマルチキャストを支持するための要件。 エンドユーザ/顧客見地. . . . . . . . . . . . . . . 13 5.1.1。 定義. . . . . . . . . . . . . . . . . . 13 5.1.2を修理してください。 Ce-PEマルチキャストルート設定とグループ管理プロトコル. . . . . . . . . . . . . . . . . . . . . . 14 5.1.3。 サービスの質(QoS). . . . . . . . . . . . . . . 14 5.1.4。 操作と管理. . . . . . . . . . . . . . 15 5.1.5。 セキュリティ要件. . . . . . . . . . . . . . . . 16 5.1.6。 エクストラネット. . . . . . . . . . . . . . . . . . . . . . . 17 5.1.7。 インターネットマルチキャスト. . . . . . . . . . . . . . . . . . 18 5.1.8。 キャリヤーのキャリヤー. . . . . . . . . . . . . . . . . . 18 5.1.9。 マルチホーミング、ロードバランシング、および弾性. . . . . 19 5.1.10。 RP工学. . . . . . . . . . . . . . . . . . . . 19 5.1.11。 アドレシング. . . . . . . . . . . . . . . . . . . . . . 20 5.1.12。 最小のMTU. . . . . . . . . . . . . . . . . . . . . 20 5.2。 サービスプロバイダー見地. . . . . . . . . . . . . . . 21 5.2.1。 一般要件. . . . . . . . . . . . . . . . . 21 5.2.2。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . 21 5.2.3。 リソース最適化. . . . . . . . . . . . . . . . 23 5.2.4。 要件. . . . . . . . . . . . . . . . 24 5.2.5にトンネルを堀ります。 メカニズム. . . . . . . . . . . . . . . . . . 26 5.2.6を制御してください。 サポート、相互、相互プロバイダー展開. . . 26 5.2.7 サービスの質分化. . . . . . . . . . 27 5.2.8。 インフラストラクチャセキュリティ. . . . . . . . . . . . . . . 27 5.2.9。 丈夫さ. . . . . . . . . . . . . . . . . . . . . . 28
Morin Informational [Page 2] RFC 4834 L3VPN Mcast Reqs April 2007
[2ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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
5.2.10. 操作、政権、および維持. . . . . . 28 5.2.11。 互換性と移動は.12に.295.2を発行します。 トラブルシューティング. . . . . . . . . . . . . . . . . . . 30 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 7。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 31 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 31 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 32 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 33
Morin Informational [Page 3] RFC 4834 L3VPN Mcast Reqs April 2007
[3ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
1. Introduction
1. 序論
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]で定義された要件を満たす仮想の兵士のNetwork(VPN)サービスが現在、世界中の多くのサービスプロバイダーによって提供されています。 顧客がプロバイダーネットワークで配備されたVPN技術を意識している必要はないので、VPNサービスはポピュラーです。 それらは以下の理由でよく比例します:
o because P routers (Provider Routers) need not be aware of VPN
service details
o Pルータ(プロバイダーRouters)が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のマルチキャストベースのサービスのサポートの増加している必要があります。 標準化本体で効率的なIPマルチキャストルーティング・プロトコルとマルチキャスト集団経営を提供するための努力をしました(プロトコルの無党派Multicast(PIM)とインターネットGroup Managementプロトコル(IGMP)の定義に特に導きました)。
However, multicast traffic is not natively supported within existing L3 PPVPN solutions. Deploying multicast over an L3VPN today, with only currently standardized solutions, requires designing customized solutions which will be inherently limited in terms of scalability, operational efficiency, and bandwidth usage.
しかしながら、マルチキャスト交通は既存のL3 PPVPN解決策の中でネイティブに支持されません。 今日L3VPNの上で現在だけの標準液でマルチキャストを配備するのは、本来スケーラビリティ、経営効率、および帯域幅用法で制限されるカスタム設計された解決策を設計するのを必要とします。
This document complements the generic L3VPN requirements [RFC4031] document, by specifying additional requirements specific to the deployment within PPVPNs of services based on IP multicast. It clarifies the needs of both VPN clients and providers and formulates the problems that should be addressed by technical solutions with the key objective being to remain solution agnostic. There is no intent in this document to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim at expressing multicast-related requirements that are not specific to L3 PPVPNs.
このドキュメントは一般的なL3VPN要件[RFC4031]ドキュメントの補足となります、IPマルチキャストに基づくサービスのPPVPNsの中の展開に特定の追加要件を指定することによって。 それは、解決策不可知論者のままで残るために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 SHOULDのマルチキャストのための手順を指定する解決策とプロトコル拡大がこれらの要件を満たすと予想されます。
Morin Informational [Page 4] RFC 4834 L3VPN Mcast Reqs April 2007
[4ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
2.1. Terminology
2.1. 用語
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マルチキャストサービスの1つ(端末はどんなソースによるグループにも送られたデータを受け取るためにマルチキャストグループに加入する)はモデル化されます。
Multicast-enabled VPN, multicast VPN, or mVPN:
A VPN that supports IP multicast capabilities, i.e., for which
some PE devices (if not all) are multicast-enabled and whose core
architecture supports multicast VPN routing and forwarding.
マルチキャストのマルチキャストで可能にされたVPN、VPN、またはmVPN: すなわちいくつかのPE装置(すべて)がどれであるかためにマルチキャストによって可能にされた状態でIPマルチキャスト能力を支持して、コア構造がマルチキャストVPNルーティングと推進を支持する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: 「プロバイダーEdge」、「顧客縁。」([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"は[VRs]用語で定義されるように[RFC4364]、および"VR"で定義される「VPNルート設定とForwardingテーブル」を「仮想のルータ」を示します。
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ネットワークの向こう側に輸送される手段。 これは一般的な方法で意味されます: そのようなトンネルは、ポイントからポイントかポイントツーマルチポイントのどちらかであるかもしれません。 この定義は分配トンネルが単方向であると仮定するように思えるかもしれませんが、また、言葉遣いは双方向のトンネルを取り囲みます。
Morin Informational [Page 5] RFC 4834 L3VPN Mcast Reqs April 2007
[5ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
S:
Denotes a multicast source.
S: マルチキャストソースを指示します。
G:
Denotes a multicast group.
G: マルチキャストグループを指示します。
Multicast channel:
In the multicast SSM model [RFC4607], a "multicast channel"
designates traffic from a specific source S to a multicast group
G. Also denominated as "(S,G)".
マルチキャストチャンネル: マルチキャストSSMモデル[RFC4607]では、「マルチキャストチャンネル」は「(S、G)」として命名されたグループG.Alsoに特定のソースSからマルチキャストまでの交通を指定します。
SP:
Service provider.
SP: サービスプロバイダー。
SSM:
Source Specific Multicast. One of the two multicast service
models, where a terminal subscribes to a multicast group to
receive data sent to the group by a specific source.
SSM: ソースの特定のマルチキャスト。 2マルチキャストサービスの1つ(端末は特定のソースによるグループに送られたデータを受け取るためにマルチキャストグループに加入する)はモデル化されます。
RP:
Rendezvous Point (Protocol Independent Multicast - Sparse Mode
(PIM-SM) [RFC4601]).
RP: ポイント(プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm)[RFC4601])を集合させてください。
P2MP, MP2MP:
Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint"
replication trees.
P2MP、MP2MP: 「ポイントツーマルチポイント」と「多点から多点」模写木を指定してください。
L3VPN, VPN:
Throughout this document, "L3VPN" or even just "VPN" will refer to
"Provider-Provisioned Layer 3 Virtual Private Network" (PP
L3VPNs), and will be preferred for readability.
L3VPN、VPN: このドキュメント中では、"L3VPN"かまさしく"VPN"さえ、「プロバイダーで食糧を供給された層3の仮想私設網」(pp L3VPNs)について言及して、読み易さのために好まれるでしょう。
Please refer to [RFC4026] for details about terminology specifically relevant to VPN aspects, and to [RFC2432] for multicast performance or quality of service (QoS)-related terms.
詳細についてマルチキャスト性能のための明確に[RFC2432]にVPN局面と、そして、関連している用語かサービスの質の(QoS)関連のおよそ用語で[RFC4026]を参照してください。
2.2. Conventions
2.2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Morin Informational [Page 6] RFC 4834 L3VPN Mcast Reqs April 2007
[6ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
3. Problem Statement
3. 問題声明
3.1. Motivations
3.1. 動機
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(プロバイダーEdgeルータ)が交通を模写するのを必要とします。 模写負担を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解決策を高めなければなりません。
3.2. General Requirements
3.2. 一般要件
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解決策が顧客のマルチキャスト交通を運ぶように設計した要件を出します。 主な要件は解決策SHOULD第1が[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に本書では等しく適切です。
Morin Informational [Page 7] RFC 4834 L3VPN Mcast Reqs April 2007
[7ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
3.3. Scaling vs. Optimizing Resource Utilization
3.3. リソース利用を最適化することに対して比例します。
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.
その結果、どんな展開も、トレードオフをするのを必要とするでしょう。 このドキュメントは要件がこの貿易に関係したいくつかを言い表すでしょう。
4. Use Cases
4. ケースを使用してください。
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.
スケーラビリティの数字のために、私たちは、最も高い期待を強調するのが関連していると考えました、最も大きい影響を解決策デザインに与えると予想されるもの。 また、バランスのために、私たちはそのような大きな期待がほんのいくつかの答えで表現されたケースについて言及します。
4.1. Scenarios
4.1. シナリオ
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解決策のデザインに大きい影響力を持っていると予想されるシナリオの短いリストをここに与えるだけです。
Morin Informational [Page 8] RFC 4834 L3VPN Mcast Reqs April 2007
[8ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
4.1.1. Live Content Broadcast
4.1.1. ライブ内容は放送されました。
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(例えば、オーディオか低品質ビデオメディア)と10Mb/s(高品質なビデオ)をアプリケーションによりますが、数10/数百の間で異ならせるかもしれません、いくつかの過酷なプロのアプリケーションが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顧客の近くで配備されたプロバイダー機器の量に依存するでしょう。
Morin Informational [Page 9] RFC 4834 L3VPN Mcast Reqs April 2007
[9ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
4.1.2. Symmetric Applications
4.1.2. 左右対称のアプリケーション
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(例えば、ビデオ会議とインターネット学習アプリケーション)のサイトの数と比べて、受信機の数が下位であるときに。
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 ことによるとかなり、高帯域(いくつかの1関係者あたりのMb/s)
Lastly, some of these applications may involve real-time interactions and will be highly sensitive to packet loss, jitter, and delay.
最後に、これらのアプリケーションのいくつかが、リアルタイムの相互作用にかかわるかもしれなくて、パケット損失、ジター、および遅れに非常に敏感になるでしょう。
4.1.3. Data Distribution
4.1.3. 情報配給
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.
マルチキャストVPNsで配備されると予想されるいくつかのアプリケーションが非リアルタイムのわずかなソースから多くの受信機までデータを分配するのが目的とされたアプリケーションです。
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の数百)にかかわるかもしれないということです。
Morin Informational [Page 10] RFC 4834 L3VPN Mcast Reqs April 2007
[10ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
4.1.4. Generic Multicast VPN Offer
4.1.4. 一般的なマルチキャストVPN申し出
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シナリオはIP-マルチキャストの接続性があらゆるVPNのために提案される展開シナリオです: 顧客がVPNを要求すると、このVPNはデフォルトでIPマルチキャストを支持するでしょう。 この場合、マルチキャストVPNsの数はVPNsの数と等しいです。 これはかなり重要なスケーラビリティ要件(例えば、何百PEs、未来の1桁の潜在的増加がある1PEあたり何百VPNs)を含意します。
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.
サービスがどう使用されているかが、完全な顧客次第であるので、1mVPNあたりの交通現象は予測できません。 これはセクション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.
また、そのようなシナリオでは、顧客はインターネットMulticastへのアクセスと同様に2以上マルチキャストVPNsの間のマルチキャストの接続性を配備したがっているかもしれません。
4.2. Scalability Orders of Magnitude
4.2. スケーラビリティ桁
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解決策の今後の展開へのスケーラビリティ期待に関連することに注意されるべきです、作者が、範囲を現在知られている展開だけに制限しないのを選んだとき。
4.2.1. Number of VPNs with Multicast Enabled
4.2.1. マルチキャストが可能にされているVPNsの数
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).
調査結果から、私たちは広範囲な期待を見ます。 極端な答えがあります: 5VPNs(1つの答え)から10k VPNs(1つの答え)まで、より典型的な答えだけが低い範囲の10VPNs(7つの答え)と、より高い範囲の数百か何千VPNs(2+4つの答え)の間で分けられます。
A solution SHOULD support a number of multicast VPNs ranging from one to several thousands.
解決策SHOULDは1〜数個の数千まで及ぶ多くのマルチキャストVPNsを支持します。
A solution SHOULD NOT limit the proportion of multicast VPNs among all (unicast) VPNs.
解決策SHOULD NOTはすべての(ユニキャスト)VPNsの中でマルチキャストVPNsの割合を制限します。
Morin Informational [Page 11] RFC 4834 L3VPN Mcast Reqs April 2007
[11ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
4.2.2. Number of Multicast VPNs per PE
4.2.2. 1PEあたりのマルチキャストVPNsの数
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(5と50の間の8つの応答)のPEあたりの多くのマルチキャストVPNsを急送します。 (4)がマルチキャストVPNsの数百か数千(1つの応答)がある1PEあたりの展開に予想する多くのそれら
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.
SHOULDが数個の数百のPEあたりの多くのマルチキャストVPNsに支持して、1PEあたり何千VPNsまで拡大させなければならないかもしれない解決策。
4.2.3. Number of CEs per Multicast VPN per PE
4.2.3. 1PEあたりのマルチキャストVPNあたりのCEsの数
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〜2000CEsまでわたります。 ほとんどの典型的反応が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).
SHOULDが数個の数百(そして、何千CEsのサポートを狙うかもしれない)に上がるPE単位で多くのマルチキャストVPNあたりのCEsに支持する解決策。
4.2.4. PEs per Multicast VPN
4.2.4. マルチキャストVPNあたりのPEs
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つの応答)か何十PEs(4つの応答)についてマルチキャストVPNあたりのPEsに数がある展開を通常予想します。 2つの応答が数千の範囲にありました(あるものは10k数値について言及しました)。
A multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands.
SHOULDがPEsの数個のマルチキャストVPNあたりの数百支持して、有効に数千まで拡大させるかもしれないマルチキャストVPN解決策。
4.2.4.1. ... with Sources
4.2.4.1. ソースがある…
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(1VPNあたりの)の数は1VPNあたりの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.
典型的な数は、ソースによって接続されたPEsの10(6つの応答)か数百(4つの応答)です。 1人の応答者が数個の数千の、より大きい数を予想しました。
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).
SHOULDが数百を支持する解決策は1VPNあたりのPEsをソースで接続しました、そして、多くへの多くアプリケーションにかかわるいくつかの展開シナリオがPEs(数百か数千)の数と等しい多くのソースによって接続されたPEsを支持するのを必要とするかもしれません。
Morin Informational [Page 12] RFC 4834 L3VPN Mcast Reqs April 2007
[12ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
4.2.4.2. ... with Receivers
4.2.4.2. 受信機がある…
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の数と同じ桁のものであると予想されるのを示しました。 これはほとんどのマルチキャストアプリケーションの本質的な本質と一致しています。(そこには、わずかなソースだけ関係者がいます)。
4.2.5. PEs with Multicast VRFs
4.2.5. マルチキャストVRFsとPEs
A solution SHOULD scale up to thousands of PEs having multicast service enabled.
マルチキャストサービスを可能にさせる何千PEsまでの解決策SHOULDスケール。
4.2.6. Number of Streams Sourced
4.2.6. 出典を明示された流れの数
Survey responses led us to retain the following orders of magnitude for the number of streams that a solution SHOULD support:
調査回答は、私たちがソリューションSHOULDがサポートするストリームの数のための以下の桁を保有するように導きました:
per VPN: hundreds or thousands of streams
VPN単位で: 数百か何千ものストリーム
per PE: hundreds of streams
PE単位で: 何百ものストリーム
5. Requirements for Supporting IP Multicast within L3 PPVPNs
5. L3 PPVPNsの中でIPマルチキャストをサポートするための要件
Again, the aim of this document is not to specify solutions but to give requirements for supporting IP multicast within L3 PPVPNs.
一方、このドキュメントの目的はソリューションを指定するのではなく、L3 PPVPNsの中でIPマルチキャストをサポートするための要件を与えることです。
In order to list these requirements, we have taken the standpoint of two different important entities: the end user (the customer using the VPN) and the service provider.
これらの要件をリストアップするために、私たちは2つの異なった重要な実体の見地を取りました: エンドユーザ(VPNを使用している顧客)とサービスプロバイダー。
In the rest of the document, by "a solution" or "a multicast VPN solution", we mean a solution that allows multicast in an L3 provider-provisioned VPN, and which addresses the requirements listed in this document.
ドキュメントの残りでは、「ソリューション」か「マルチキャストVPNソリューション」で、私たちはプロバイダーで食糧を供給されたVPNをL3のマルチキャストに許容して、本書ではリストアップされた要件をどのアドレスに許容するソリューションを言っています。
5.1. End User/Customer Standpoint
5.1. エンドユーザ/顧客見地
5.1.1. Service Definition
5.1.1. サービス定義
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文脈のマルチキャストに必要であるものと比べて、SHALL NOTは顧客デバイス(CEs)がどんな付加的特徴もサポートするのを必要とします。 マルチキャストサポートSHOULDのためにVPNを有効にして、ことによるとCEデバイスで既に配布された既存のマルチキャストプロトコルで影響(または、非常に限られた影響)なしで可能であってください。
Morin Informational [Page 13] RFC 4834 L3VPN Mcast Reqs April 2007
[13ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
5.1.2. CE-PE Multicast Routing and Group Management Protocols
5.1.2. Ce-PEマルチキャストルート設定とグループ管理プロトコル
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 SHOULDの間のマルチキャスト関連のプロトコル交換は既存のマルチキャストプロトコルで起こります。
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--濃いMode(DM)[RFC3973]、およびIGMPv3[RFC3376](このバージョンはそれとなくIGMPv1[RFC1112]かIGMPv2[RFC2236]を実装するだけであるホストをサポートします)。
Among those protocols, the support of PIM-SM (which includes the SSM model) and either IGMPv3 (for IPv4 solutions) and/or Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions) is REQUIRED. Bidir-PIM support at the PE-CE interface is RECOMMENDED. And considering deployments, PIM-DM is considered OPTIONAL.
それらのプロトコルの中では、PIM-SM(SSMモデルを含んでいる)とIGMPv3(IPv4ソリューションのための)、そして/または、Multicast Listenerディスカバリーバージョン2(MLDv2)[RFC3810](IPv6ソリューションのための)のサポートはREQUIREDです。 PE-CEインタフェースでのBidir-PIMサポートはRECOMMENDEDです。 そして、展開を考える場合、PIM-DMはOPTIONALであると考えられます。
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ソリューションで築き上げられるとき、上のプロトコルのv6異形をサポートしなければなりません、MLDv2、およびPIM-SM IPv6特有の手順を含んでいて。 IPv4だけをサポートしながらユニキャストVPNソリューションで築き上げられたマルチキャストVPNソリューションのために、デザインがIPv6への簡単な適合を提供する手順とencodingsの定義を支持するのは、RECOMMENDEDです。
5.1.3. Quality of Service (QoS)
5.1.3. サービスの質(QoS)
Firstly, general considerations regarding QoS in L3VPNs expressed in Section 5.5 of [RFC4031] are also relevant to this section.
また、まず第一に、[RFC4031]のセクション5.5で急送されたL3VPNsのQoSに関する一般的な問題もこのセクションに関連しています。
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.
マルチキャストサービスSHOULDのための有用性のレベルは平価に関するそうです。ユニキャストトラフィックのために存在するもので。 保護メカニズムSHOULDを取引してください。例えば、匹敵する、それがサービスプロバイダーのネットワークの上まで運ばれたら顧客マルチキャストトラフィックに利用可能にしてください。
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
ユニキャスト、非VPN文脈のマルチキャストのために存在するとき存在するときSHALLが少なくとも同じレベルのサービスの質をサービスプロバイダーを定義させるマルチキャストVPNソリューション。 この見解、L3VPNの中のマルチキャストベースのサービスの展開から
Morin Informational [Page 14] RFC 4834 L3VPN Mcast Reqs April 2007
[14ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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.
環境SHALLはマルチキャストトラフィック識別と、分類と、能力をマークするのを含んでいる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.
マルチキャストがテレビ放送などの質の高いサービスを提供するのにしばしば使用されるとき、マルチキャストVPNソリューションは、帯域幅の予約や入場コントロールなどの高いQoSをサポートするために付加的な機能を提供するかもしれません。
Also, considering that multicast reception is receiver-triggered, group join delay (as defined in [RFC2432]) is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard.
また、また、考える場合、マルチキャストレセプションが受信機によって引き起こされます、グループが遅れに合流するという([RFC2432]で定義されるように)ことであることは1つの重要なQoSパラメタであると考えられます。 その結果、マルチキャストVPNソリューションがこの点で適切に設計されているのは、RECOMMENDEDです。
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リンクにおけるストリームの放出を止める能力を持っているのは重要でしょう; SHOULDはマルチキャストルーティングを調整するのにおいて可能であるか、または分類します。これがそれを含意する、それ、グループを減少させるのに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.
最後に、SHOULDがそのクライアントマルチキャストトラフィックパケットをできるだけ確実にするマルチキャストVPNソリューションは、無くならないでまたコピーされていません、変化がクライアントマルチキャストデータ・ストリームがプロバイダーネットワークの上まで運ばれる方法で起こると。 また、新しいソースがトラフィックをグループに送り始めるとき、パケット損失問題は考えられなければなりません: どんな受信機もそのようなトラフィックを受けるのにSHOULDを関心がありました。それに従って、調整されます。
5.1.4. Operations and Management
5.1.4. 操作と管理
The requirements and definitions for operations and management (OAM) of L3VPNs that are defined in [RFC4176] equally apply to multicast, and are not extensively repeated in this document. This sub-section mentions the most important guidelines and details points of particular relevance in the context of multicast in L3VPNs.
[RFC4176]で等しく定義されるL3VPNsの操作と管理(OAM)のための要件と定義は、マルチキャストに適用して、手広く本書では繰り返されません。 この小区分は、L3VPNsでマルチキャストの文脈で最も重要なガイドラインについて言及して、ポイントの特定の関連性を詳しく述べます。
A multicast VPN solution SHOULD allow a multicast VPN customer to manage the capabilities and characteristics of their multicast VPN services.
SHOULDが彼らのマルチキャストVPNサービスの能力と特性をマルチキャストVPN顧客を管理させるマルチキャストVPNソリューション。
Morin Informational [Page 15] RFC 4834 L3VPN Mcast Reqs April 2007
[15ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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のモニターしている能力であるとサポートしなければならないマルチキャスト、どのSHOULDが同じモニターしている目的のためのユニキャストサービスに使用されるものと同様のテクニックを当てにしますか? マルチキャストSLAは測定基準SHOULDを関係づけました。ユニキャスト関連のモニターに既に使用されたものと同様の手段で利用可能であってください、Simple Network Managementプロトコル(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).
モニターされるかもしれないマルチキャスト特有の特性は: 1ストリームあたりのマルチキャスト統計、終わりから終わりへの遅れ、およびグループは、遅れ([RFC2432]、セクション3で定義されるようにVPNの向こう側にマルチキャストグループのトラフィックを受けるのを始めるか、または止める時間)を合流するか、または残します。
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パフォーマンスMetrics関連する情報(IPPM、[RFC2330])を含むかもしれません: そのような情報は一方向パケット遅れ、相互パケット遅れ変化などを含んでいます。 [MULTIMETRICS]を見てください。
A generic discussion of SLAs is provided in [RFC3809].
SLAのジェネリック議論を[RFC3809]に提供します。
Apart from statistics on multicast traffic, customers of a multicast VPN will need information concerning the status of their multicast resource usage (multicast routing states and bandwidth). Indeed, as mentioned in Section 5.2.5, for scalability purposes, a service provider may limit the number (and/or throughput) of multicast streams that are received/sent to/from a client site. In such a case, a multicast VPN solution SHOULD allow customers to find out their current resource usage (multicast routing states and throughput), and to receive some kind of feedback if their usage exceeds the agreed bounds. Whether this issue will be better handled at the protocol level at the PE-CE interface or at the Service Management Level interface [RFC4176] is left for further discussion.
マルチキャストトラフィックにおける統計は別として、VPNがそうするマルチキャストの顧客は彼らのマルチキャストリソース用法(マルチキャストルーティング州と帯域幅)の状態に関して情報を必要とします。 本当に、スケーラビリティ目的のためにセクション5.2.5で言及されるように、サービスプロバイダーはクライアントサイトからの/に受け取るか、または送るマルチキャストストリームの数(そして/または、スループット)を制限するかもしれません。 このような場合には、それらの用法が同意を超えているなら、SHOULDが彼らの現在のリソース用法(マルチキャストルーティング州とスループット)を見つけて、ある種のフィードバックを受ける顧客を許容するマルチキャストVPNソリューションはバウンドしています。 この問題をPE-CEインタフェースにおける、または、Service Management Levelインタフェース[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メカニズムかリソース用法測定基準もそのようなアラームが(測定基準のために定義された低いか高い敷居に基づくヒステリシスメカニズムの例えば何らかのフォーム)であると生成されるレートを制限する能力を統合するのは、RECOMMENDEDです。
5.1.5. Security Requirements
5.1.5. セキュリティ要件
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ソリューションはユニキャストとマルチキャストトラフィックの両方のために同じレベルのセキュリティをアーキテクチャに提供しなければなりません。
Morin Informational [Page 16] RFC 4834 L3VPN Mcast Reqs April 2007
[16ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
Moreover, the activation of multicast features SHOULD be possible:
そのうえ、マルチキャストの起動はSHOULDを特集します。可能であってください:
o per VRF / per VR
o 1VRあたりのVRF/単位で
o per CE interface (when multiple CEs of a VPN are connected to a
common VRF/VR)
o CEインタフェース単位で(VPNの複数のCEsが一般的な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ソリューションは、セクション3.3に時々VPNの一部でないPEsを含むかもしれないより大きいセットのPEルータにクライアントグループのマルチキャストトラフィックを分配することによって述べられた最適/スケーラビリティトレードオフをするのを選ぶかもしれません。 セキュリティ見地から、これは何人かのVPN顧客のための問題であるかもしれません。 したがって、そのような体系を使用するマルチキャストVPNソリューションは特定の顧客(そして/または、特定の顧客マルチキャストストリーム)のためにこれを避ける方法を提供するかもしれません。
5.1.6. Extranet
5.1.6. エクストラネット
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モデルでは、顧客サイトは複数のVPNsの一部になるようにセットアップされるかもしれません、そして、VPNがマルチキャストによって可能にされるとき、これはまだ可能であるべきです。 実際には、それは、VRFかVRが1VPNの一部であるかもしれないことを意味します。
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.
または、例えば、それがそのVRFにマルチキャストで可能にされたVPNの、そして、接続されたBGP/MPLSに参加する企業サイトがマルチキャストストリームを受けることができるようにVRFを構成するのにおいて可能であるに違いない、(マルチキャストストリームを溯源する、)、そのVRFに関連づけられる別のVPN。
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ソリューションがVRFがエクストラネットVPNsの選ばれたセットにそのマルチキャストの接続性を設定できるように構成される手段を提供しなければならないことを意味します。 より正確に、以下のことはしたがって、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 それぞれのエクストラネットVPNsのために独自にマルチキャストレセプションと放出を可能にすることができます。
Morin Informational [Page 17] RFC 4834 L3VPN Mcast Reqs April 2007
[17ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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 MUSTに可能にして、可能であってください。
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 SHOULD NOTと共にマルチキャストの接続性を可能にして、厳しい最小量のユニキャストルーティング以上を必要としてください。 マルチキャストをVPN SHOULD NOTに送って、そのVPNにユニキャストルートを持つのを必要であってください。 VPN SHOULDからマルチキャストを受けて、その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にインポートされます、マルチキャストReverse Path Forwarding(RPF)解決のために、このSHOULD、それらのルートをユニキャストルーティングに利用可能にしないで、可能であってください。
Proper support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link, whether it is a physical or logical link.
この特徴SHOULD NOTの適切なサポートは、PE-CEリンクにマルチキャストトラフィックを模写するのを必要とします、それが物理的であるか論理的なリンクであるか否かに関係なく。
5.1.7. Internet Multicast
5.1.7. インターネットマルチキャスト
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.
インターネットMulticastがある接続性は前項の特定のケースです。そこでは、VR/VRFに添付されたサイトが、マルチキャストトラフィックを/からインターネットに受けるか、または送る必要があるでしょう。
This should be considered OPTIONAL given the additional considerations, such as security, needed to fulfill the requirements for providing Internet Multicast.
追加問題を考えて、これはOPTIONALであると考えられるべきです、インターネットMulticastを提供するために要求にこたえるのに必要であるセキュリティなどのように。
5.1.8. Carrier's Carrier
5.1.8. キャリヤーのキャリヤー
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、または「サブキャリヤー」であるとサポートします。 SHOULDがスケーラブルで効率的な方法でキャリヤーのキャリヤーモデルをサポートするマルチキャスト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の平らなSHOULD NOTで使用されるかもしれないプロトコルがセクション5.1.2に従って必要であるプロトコルに制限されるのを含意します、そして、SHOULDはセクション5.2.4で記載されたプロトコルのいくつかを含んでいます、例えば、P2MP MPLSシグナリングプロトコルなどのように。
Morin Informational [Page 18] RFC 4834 L3VPN Mcast Reqs April 2007
[18ページ]RFC4834L3VPN Mcast Reqs2007年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などのMPLSベースのL3VPN展開[RFC4364]の文脈では、これは、MPLSラベル分配SHOULDがPE-CEレベルで起こることを意味します、トンネリングメカニズムとして多点LSPsを使用するためにサブキャリヤーに能力を与えて。
5.1.9. Multi-Homing, Load Balancing, and Resiliency
5.1.9. マルチホーミング、ロードバランシング、および弾性
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ソリューションSHOULD、フェイルオーバーマルチホーミングや、CE-PEリンクロードバランシングや、マルチキャストVPNソリューションSHOULDなどの顧客のためにサービス丈夫さを改良するのを目的とする現在のソリューションと互換性があってください、そして、また、マルチキャストトラフィックのためにそれらの同じ特徴を提供できてください。
Any solution SHOULD support redundant topology of CE-PE links. It SHOULD minimize multicast traffic disruption and fail-over.
どんなソリューションSHOULDもCE-PEリンクの余分なトポロジーをサポートします。 それ、SHOULDはマルチキャストトラフィック分裂とフェイルオーバーを最小にします。
5.1.10. RP Engineering
5.1.10. RP工学
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を実行するノードに関連づけられて、このノードの上で構成されなければなりません。
5.1.10.1. RP Outsourcing
5.1.10.1. RPアウトソーシング
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機能の工学は特定のプロトコルと関連構成の展開を必要とします。 サービスプロバイダーは、それらに代わって顧客のマルチキャストプロトコル操作を管理すると申し出るかもしれません。 これは、顧客のRPsが社外調達されている(例えば、PEsの)ケースを考えるのが必要であることを含意します。 その結果、VPNソリューションはVRかVRFでのRP機能の接待をサポートするかもしれません。
5.1.10.2. RP Availability
5.1.10.2. RPの有用性
Availability of the RP function (or address) is required for proper operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity to the RP from a receiver or source will impact the multicast service. For this reason, different mechanisms exist, such as BSR [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)- based [RFC3446] or PIM-based [RFC4610]).
RP機能(または、アドレス)の有用性がPIM-SM(ASMモード)とbidir-PIMの適切な操作に必要です。 受信機かソースからのRPへの接続性の損失はマルチキャストサービスに影響を与えるでしょう。 この理由で、異なったメカニズムは存在しています、BSR[PIM-BSR]やanycast-RP(マルチキャストSourceディスカバリープロトコル(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.
関連しているなら、これらのプロトコルと手順SHOULDは透過的にマルチキャストVPN、および5月を終えて、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:
そのうえ、マルチキャストVPNソリューションは接続性の損失に関してASMマルチキャストサービスの丈夫さをRPに改良するかもしれません、助ける特定の特徴を提供することによって:
Morin Informational [Page 19] RFC 4834 L3VPN Mcast Reqs April 2007
[19ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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
a) MVPNの中の自分たちの中で接続性を維持するすべてのサイトの中でASMマルチキャストサービスを維持してください、RPを接待するサイトがそれらの接続性をMVPNに失うと
b) maintain ASM multicast service within any site that loses
connectivity to the service provider
b) サービスプロバイダーに接続性を失うどんなサイトの中でもASMマルチキャストサービスを維持してください。
5.1.10.3. RP Location
5.1.10.3. RP位置
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.
ソースがグループ(ASMモードによる)に向かってトラフィックを放ち始めるときのPIM-SMの場合では、ソースと受信機がRPのものと異なったVPNサイトに位置しているなら、トラフィックははかなく、RP(ソースからRPまでそして、RPから受信機までの)のSPネットワークとCE-PEリンクを通して二度流れるかもしれません。 この短くさえあるトラフィックピークさえ、トラフィックによって、便利であり、帯域幅をリンクしないかもしれません。
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue.
したがって、VPNソリューションはそれが解決するか、または緩和するのを助ける特徴にこの潜在的問題を提供するかもしれません。
5.1.11. Addressing
5.1.11. アドレシング
A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions on multicast group addresses used by VPN customers.
マルチキャストのプロバイダーで食糧を供給されたL3VPN SHOULD NOTは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.
SHOULDがお勧めであるならそのようなサービスがそうであるマルチキャストベースのドメインのスケールでのサービス識別のグローバルにユニークな手段の使用。 IPv4マルチキャストのために、これは、マルチキャストの使用がVPNだけの中で利用されて、VPNの外でサービスのためのトラフィックがそうするかもしれないSSM-範囲アドレス([RFC4607]によって定義される232/8)かグローバルに割り当てられたグループアドレス(例えば、GLOP[RFC3180]、233/8)のどちらかについて送信されることになっているサービスに関して行政上、範囲([RFC2365]によって定義される239/8)を見たのを含意します。
5.1.12. Minimum MTU
5.1.12. 最小のMTU
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:
したがって、マルチキャストVPNソリューションSHOULD、これらの問題で、念頭に設計されてください。 実際には:
Morin Informational [Page 20] RFC 4834 L3VPN Mcast Reqs April 2007
[20ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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
o マルチキャストVPNソリューションSHOULDのカプセル化オーバーヘッドは、顧客デバイスが断片化を持つことができないように最小にされて、活動をできるだけ再アセンブリします。
o a multicast VPN solution SHOULD enable the service provider to
commit to a minimum path MTU usable by multicast VPN customers
o SHOULDが、サービスプロバイダーがマルチキャストVPN顧客によるMTU使用可能な最小の経路に遂行するのを可能にするマルチキャストVPNソリューション
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ソリューションSHOULD、経路MTU探索メカニズム([RFC1191]と[RFC4459]を見る)とのコンパチブル、そして、特定の注意がSHOULDであったなら、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ソリューションSHOULDがVPN顧客マルチキャストパケットのために最小の1500年のバイトのIP MTUを考慮するように設計されていて、デザインはそれを許容します。
5.2. Service Provider Standpoint
5.2. サービスプロバイダー見地
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(Multicast Distribution Tunnelのための)を導入しました。(MDTunnelはコアネットワークの上でサービスプロバイダーによって前進の顧客マルチキャストトラフィックに使用された飛行機手段にデータを指定します)。
5.2.1. General Requirement
5.2.1. 一般要件
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における標準化されたマルチキャスト関連のプロトコルの既存の展開のときにノー、と(非常に制限される)と共にルータに影響を与えますSHOULDが可能である。
5.2.2. Scalability
5.2.2. スケーラビリティ
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ソリューションであると配布された或るものはコアで顧客の数と顧客ルートの数に関してスケーラブルであることの主要な利点を持っています。 例えば、PルータはVPNsの数ではなく、PEsの数にリンクされるだけである多くのMPLSトンネル、または[RFC4364]とVirtual Router[VRs]モデルの、顧客サイトを見ます。
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顧客のマルチキャスト活動から独立していた状態で。
Morin Informational [Page 21] RFC 4834 L3VPN Mcast Reqs April 2007
[21ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
It is expected that multicast VPN solutions will use some kind of point-to-multipoint technology to efficiently carry multicast VPN traffic, and because such technologies require maintaining state information, this will use resources in the control plane of P and PE routers (memory and processing, and possibly address space).
マルチキャストVPNソリューションが効率的にマルチキャストVPNトラフィックを運ぶのにある種のポイントツーマルチポイント技術を使用すると予想されて、そのような技術が、州の情報を保守するのを必要とするので、これはPとPEルータ(メモリ、処理、およびことによるとアドレス空間)の制御飛行機でリソースを使用するでしょう。
Scalability is a key requirement for multicast VPN solutions. Solutions MUST be designed to scale well with an increase in any of the following:
スケーラビリティはマルチキャストVPNソリューションのための主要な要件です。 以下のどれかの増加でよく比例するようにソリューションを設計しなければなりません:
o the number of PEs
o PEsの数
o the number of customer VPNs (total and per PE)
o 顧客VPNsの数(総、PE、)
o the number of PEs and sites in any VPN
o どんなVPNのPEsとサイトの数
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.
セクション4.2にマルチキャストVPNソリューションが比例すると予想される典型的な桁相談してください。
Scalability of both performance and operation MUST be considered.
性能と操作の両方のスケーラビリティを考えなければなりません。
Key considerations SHOULD include:
主要な問題SHOULDは:
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.
それぞれのソリューションの適用性があいさつで前述のスケーラビリティ評価基準に評価されると予想されます。
Morin Informational [Page 22] RFC 4834 L3VPN Mcast Reqs April 2007
[22ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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.
これらの問題は、私たちが、提案されたソリューションSHOULDが異なったマルチキャストストリーム(異なったVPNs、同じくらいか異なったVPNsの異なったマルチキャストの流れの間の)の間にそのようなリソースを共有する可能性を提供すると信じているように自然に導きます。 例えば、これは、数人の顧客の間のMDTunnelを共有できて、MDTunnelsが木であるかどうかを意味します。
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ルータでは、それらのスケーラビリティ問題が、より重要であると予想されますが、SHOULDがスケーラビリティと同じくらい遠くにPとPEルータの両方を扱うマルチキャストVPNソリューションは関係があります。
5.2.3. Resource Optimization
5.2.3. リソース最適化
5.2.3.1. General Goals
5.2.3.1. 一般目標
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つの明白な準最適の振舞いが、不必要な複製(例えば、イングレスPE模写をするとき、同じデータが二度かさらにリンクの上に移動するとき)と不必要なレセプション(例えば、どんな川下の受信機もないので、それが必要としないトラフィックを受けるPE)です。
5.2.3.2. Trade-off and Tuning
5.2.3.2. トレードオフとチューニング
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.).
そのうえ、「フリーサイズ」トレードオフがたぶん存在しないように思えます。 したがって、SHOULDがサービスプロバイダーを提供するマルチキャストVPN解決策は彼らの特定の規制に従ってそれらがトレードオフを調整する構成設定を当てます(ネットワーク形態、プラットホーム、顧客アプリケーション、サービスのレベルはなどを提供しました)。
As an illustration, here are some example bounds of the trade-off space:
イラストとして、ここに、トレードオフスペースのいくつかの例の領域があります:
Morin Informational [Page 23] RFC 4834 L3VPN Mcast Reqs April 2007
[23ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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をセットアップするのが流れる、(彼らのすべてか何人か、直径、異なったVPNsである、) これは、より良いスケーラビリティの特性を持ちますが、たぶんいくらかのMDTunnelがいなくなって以来の帯域幅を犠牲にして彼らが必要としない交通を受けるでしょう、そして、増加するので、規制で最適のMDTunnelsを見つけるのは、より困難になるでしょう。
5.2.3.3. Traffic Engineering
5.2.3.3. 交通工学
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)に特徴を提供するなら、解決策SHOULDはマルチキャスト交通のための同等な特徴を提供します。
A solution SHOULD offer means to support key TE objectives as defined in [RFC3272], for the multicast service.
SHOULDが提供する解決策は、マルチキャストサービスのために[RFC3272]で定義されるように主要なTE目的を支持することを意味します。
A solution MAY also usefully support means to address multicast- specific traffic engineering issues: it is known that bandwidth resource optimization in the point-to-multipoint case is an NP-hard problem, and that techniques used for unicast TE may not be applicable to multicast traffic.
また、解決策は有効にマルチキャストの特定の交通工学問題を記述する手段を支持するかもしれません: ポイントツーマルチポイント場合における帯域幅リソース最適化がNP-難問であり、ユニキャストTEに使用されるテクニックがマルチキャスト交通に適切でないかもしれないことが知られています。
Also, it has been identified that managing the trade-off between resource usage and scalability may incur uselessly sending traffic to some PEs participating in a multicast VPN. For this reason, a multicast VPN solution MAY permit that the bandwidth/state tuning take into account the relative cost or availability of bandwidth toward each PE.
また、リソース用法とスケーラビリティの間のトレードオフを管理するとマルチキャストVPNに参加するいくつかのPEsへの送付交通が無益に被られるかもしれないのが特定されました。 この理由で、マルチキャストVPN解決策は、帯域幅/州の調律が各PEに向かって帯域幅の相対コストか有用性を考慮に入れるように許可するかもしれません。
5.2.4. Tunneling Requirements
5.2.4. トンネリング要件
5.2.4.1. Tunneling Technologies
5.2.4.1. トンネリング技術
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
原則に従って、制御飛行機と推進飛行機、マルチキャストVPN解決策SHOULDの間の分離では、コントロールと推進飛行機が互いに依存しないように、設計されてください: 制御飛行機SHALL NOTはどの推進飛行機が(逆もまた同様に)使用されるか、そして、制限されていて、飛行機SHOULD NOTを進めることの選択によります。
Morin Informational [Page 24] RFC 4834 L3VPN Mcast Reqs April 2007
[24ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology.
解決策のデザインで。 解決策もSHOULD NOT、特定のトンネリング技術に結ばれてください。
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解決策では、トンネリング技術による一貫性は支持されなければなりません: SHOULDがユニキャストのように同じトンネリング技術のマルチキャストの使用を許すそのような解決策。 展開の一貫性、操作の容易さ、および潜在的移動はこの要件の後ろの主な動機です。
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、解決策SHOULD、ポイントツーポイントとポイントツーマルチポイントを含む以下などのさまざまなトンネリング技術は使用できてください。
o Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in
multicast IP trees),
o 一般的なルート設定Encapsulation(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 MPLS[RFC3031](P2PかMP2Pトンネルと、MPLS P2MP拡張子でResource予約プロトコル(RSVP)[P2MP-RSVP-TE]かLabel Distributionプロトコル(自由民主党)[P2MP自由民主党REQS][P2MP-自由民主党]に合図された多点トンネルを含んでいます)
o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast
[RFC4045]),
o 層-2Tunnelingプロトコル(L2TP)(マルチキャスト[RFC4045]のためのL2TPを含んでいます)
o IPsec [RFC4031]
o IPsec[RFC4031]
o IP-in-IP [RFC2003], etc.
o IPにおけるIP[RFC2003]など
Naturally, it is RECOMMENDED that a solution is built so that it can leverage the point-to-multipoint variants of these techniques. These variants allow for packet replications to happen along a tree in the provider core network, and they may help improve bandwidth efficiency in a multicast VPN context.
当然、解決策がこれらのテクニックのポイントツーマルチポイント異形に投機できるように組立しているのは、RECOMMENDEDです。 これらの異形は、パケット模写が木に沿ってプロバイダーコアネットワークで起こるのを許容します、そして、それらはマルチキャストVPN文脈の帯域幅効率を高めるのを助けるかもしれません。
5.2.4.2. MTU and Fragmentation
5.2.4.2. MTUと断片化
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:
A解決策SHOULDがしたがって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でたまたま要約されるなら、適切なトラブルシューティングを実行できます。
Morin Informational [Page 25] RFC 4834 L3VPN Mcast Reqs April 2007
[25ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
5.2.5. Control Mechanisms
5.2.5. 制御機構
The solution MUST provide some mechanisms to control the sources within a VPN. This control includes the number of sources that are entitled to send traffic on the VPN, and/or the total bit rate of all the sources.
解決策は、VPNの中でソースを監督するためにいくつかのメカニズムを提供しなければなりません。 このコントロールはVPNにおける交通を送る権利を与えられるソースの数、そして/または、すべてのソースの総ビット伝送速度を含んでいます。
At the reception level, the solution MUST also provide mechanisms to control the number of multicast groups or channels VPN users are entitled to subscribe to and/or the total bit rate represented by the corresponding multicast traffic.
また、レセプションレベルでは、解決策は、加入するVPNユーザが権利を与えられるマルチキャストグループかチャンネルの数、そして/または、対応するマルチキャスト交通で表された総ビット伝送速度を制御するためにメカニズムを提供しなければなりません。
All these mechanisms MUST be configurable by the service provider in order to control the amount of multicast traffic and state within a VPN.
これらのすべてのメカニズムが、サービスプロバイダーは、VPNの中でマルチキャスト交通と状態の量を制御するために構成可能でなければなりません。
Moreover, it MAY be desirable to be able to impose some bound on the quantity of state used by a VPN in the core network for its multicast traffic, whether on each P or PE router, or globally. The motivation is that it may be needed to avoid out-of-resources situations (e.g., out of memory to maintain PIM state if IP multicast is used in the core for multicast VPN traffic, or out of memory to maintain RSVP state if MPLS P2MP is used, etc.).
そのうえ、それぞれのPかPEルータにかかわらずマルチキャスト交通にコアネットワークにおけるVPNによって使用された状態の量、またはグローバルに縛られたいくつかは課すことができるのが望ましいかもしれません。 動機はそれがリソースの外で状況を避けるのに必要であるかもしれないという(例えば維持するメモリから、PIM状態はIPマルチキャストであるならRSVP状態がMPLS P2MPであるなら使用されていると主張するのにコアでマルチキャストVPN交通、またはメモリから使用されますなど)ことです。
5.2.6. Support of Inter-AS, Inter-Provider Deployments
5.2.6. サポート、相互、相互プロバイダー展開
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(自治のSystem)マルチキャストVPNsを支持しなければなりません、そして、SHOULDは相互プロバイダーマルチキャストVPNsを支持します。 ユニキャスト相互AS VPN Options 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.
SHOULDが必要である中でコーディネート最も可能でない相互ASメカニズムをプロバイダーの間に提供して、必要性を保つマルチキャストVPN解決策はプロバイダーのネットワークに関する知識を最小限に詳しく述べました--対応するユニキャスト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 サービスプロバイダーSHOULDの各サービスプロバイダー、選ぶ中で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ルータにかかるために単一のトンネルを必要とするなら、解決策SHOULDは、そのようなトンネルに設定する相互プロバイダーコーディネートが最小にされるのを保証するためにメカニズムを提供します。
Morin Informational [Page 26] RFC 4834 L3VPN Mcast Reqs April 2007
[26ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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.
そのうえ、他の要件で妥協しないで、そのようなサポートは中でこの要件ドキュメントを急送しました、そして、SHOULDが可能であるSHALL NOTはスケーラビリティと帯域幅関連の効率で刑罰を被ります。
5.2.7. Quality-of-Service Differentiation
5.2.7. サービスの質分化
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解決策SHOULDは異なった顧客のためにQoSの微分されたレベルを提供して、保証して、実施する能力をVPNサービスプロバイダーに与えます。
5.2.8. Infrastructure security
5.2.8. インフラストラクチャセキュリティ
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.
解決策SHOULDは現在ユニキャストVPNs(例えばSecurityが区分する[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.
そのうえ、マルチキャスト以来、交通とルーティングは本質的にダイナミックです(受信機で開始している)、クライアント交通がコアの上まで運ばれる方法における変化の頻度は境界があるように提案された、しっかり結合していない動力が変える顧客ネットワークのマルチキャスト交通の何らかのメカニズムSHOULD。 例えば、機能を湿らせるマルチキャストルートは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 MAYの展開と維持に参加するネットワーク装置がまた、マルチキャスト分配トンネルの設立と維持にかかわる参加装置のスーパーセットを表します。 そういうものとして関連装置だけがマルチキャストによって可能にされるのを単に確実にするのではなく、マルチキャスト(ルーティング)情報がマルチキャストで可能にされた装置だけに広められるのを確実にもするために装置特有であり、したがって、マルチキャストで推論されたDOSの危険を制限すると攻撃されるVPN SHOULDの中のIPマルチキャスト能力の起動。
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 MUST NOTにはメンバーが全くいないマルチキャストチャンネルの交通がマルチキャスト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
相互ASと相互プロバイダー展開には、セキュリティ問題は特に重要です。 そのような場合、マルチキャストVPN解決策サポートが、相互ASか相互プロバイダー境界の向こう側にマルチキャスト関連の交換の保全と信憑性を確実にすることを意味するのは、RECOMMENDEDです。 それ、RECOMMENDEDはそんなに対応する手順です。
Morin Informational [Page 27] RFC 4834 L3VPN Mcast Reqs April 2007
[27ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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).
プロバイダーの間の最も可能でないコーディネートを必要としてください。 特定の構成か暗号化キーが配備されなければならないとき、より正確に、これは任意にASBRs(自治のSystem Border Routers)か彼らの部分集合に制限されるものとします。BGP Route Reflectors(彼らの部分集合)。
Lastly, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view.
最後に、セクション5.2.5で説明された制御機構はまた、このインフラストラクチャセキュリティ観点から考えられることです。
5.2.9. Robustness
5.2.9. 丈夫さ
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.
また、弾性もインフラストラクチャセキュリティに重要です。 したがって、SHOULDが単一のポイントの失敗を避けるか、またはそれを可能にする何らかの技術的解決法を提案するマルチキャストVPN解決策はフェイルオーバーメカニズムを実行します。
As an illustration, one can consider the case of a solution that would use PIM-SM as a means to set up MDTunnels. In such a case, the PIM RP might be a single point of failure. Such a solution SHOULD be compatible with a solution implementing RP resiliency, such as anycast-RP [RFC4610] or BSR [PIM-BSR].
イラストとして、人はMDTunnelsをセットアップする手段としてPIM-SMを使用する解決策に関するケースを考えることができます。 このような場合には、PIM RPは1ポイントの失敗であるかもしれません。 そのような解決策SHOULD、anycast-RP[RFC4610]かBSRなどのRPの弾性[PIM-BSR]を実行する解決策と互換性があってください。
5.2.10. Operation, Administration, and Maintenance
5.2.10. 操作、政権、および維持
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解決策SHALLの操作は、できるだけ軽く、優先がいつであったかときに、マルチキャストVPN解決策を設計しながら、自動構成と発見SHOULDを提供しています。 特に、設定の操作上の負担がPEでマルチキャストを上げるか、またはVR/ VRF SHOULDに関して、できるだけ低くいてください。
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.
また、そして、できるだけ、SHOULDがコアの中でプロトコルの数であると慎重に考える解決策のデザインは以下をネットワークでつなぎます。 ユニキャストVPNサービス、それらの利点と操作上の負担SHOULDの間のバランスと比べて、何か追加議定書が紹介されるなら、徹底的に調べられてください。
Moreover, monitoring of multicast-specific parameters and statistics SHOULD be offered to the service provider, following the requirements expressed in [RFC4176].
そのうえ、マルチキャスト特有のパラメタと統計SHOULDがモニターされて、[RFC4176]で言い表された要件に続いて、サービスプロバイダーに提供してください。
Most notably, the provider SHOULD have access to:
最も著しく、プロバイダーSHOULDは以下にアクセスを持っています。
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 クライアントマルチキャストリソース用法に関する情報(マルチキャストルーティング状態と帯域幅用法)
Morin Informational [Page 28] RFC 4834 L3VPN Mcast Reqs April 2007
[28ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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パフォーマンスMetrics[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.
この情報SHOULD、標準化されたSMIv2[RFC2578]管理Information基地(MIB)のモジュールで利用可能に作られていて、SNMP[RFC3411]か、IPFIX[IPFIX-PROT]を通して使用されてください。 例えば、適切であるときにはBGP/MPLS VPNs[RFC4364]、[RFC4382]SHOULDで定義されたMIBsへのマルチキャスト拡大の文脈では、[RFC3811]、[RFC3812]、[RFC3813]、および[RFC3814]との適切な統合で提案されてください。
Mechanisms similar to those described in Section 5.2.12 SHOULD also exist for proactive monitoring of the MDTunnels.
また、セクション5.2.12SHOULDで説明されたものと同様のメカニズムは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メカニズムと手順を提案する、マルチキャストVPNs SHOULDにおいて、セクション5.2で.2に言及されたパラメタに関してスケーラブルであってください。 性能とQoSで特別の注意を監視メカニズムの影響に与えるのは、特に、RECOMMENDEDです。
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メカニズムかリソース用法測定基準もそのようなアラームが発生する速度(測定基準のために定義された低いか高い敷居に基づくヒステリシスメカニズムの例えば何らかのフォーム)を制限する能力を統合するのは、RECOMMENDEDです。
5.2.11. Compatibility and Migration Issues
5.2.11. 互換性と移動問題
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解決策SHOULD、aマルチキャストVPN SHOULDの展開と維持に参加する装置での起動がすなわち、できるだけ滑らか、そして、総合的な基本的なインフラストラクチャで既に後押しされているサービスの品質に影響しないである設計されたそうになってください。
A multicast VPN solution SHOULD prevent compatibility and migration issues, for instance, by focusing on providing mechanisms
SHOULDが、例えば、集中するのによる互換性と移動問題がメカニズムを提供するのを防ぐマルチキャストVPN解決策
Morin Informational [Page 29] RFC 4834 L3VPN Mcast Reqs April 2007
[29ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
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.
下位互換を容易にします。 最も著しく、要件の部分集合だけをサポートする解決策は本書ではSHOULDを急送しました。設計されていて、互換性がさらなる改正で導入されるのを許容してください。
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.
それ、SHOULD、できるだけ後方の多くの互換性を提供するどんなマルチキャストVPN解決策の目的になってください。 理想的に、解決策には、VPNがどんなマルチキャストも支持しないいくつかの遺産ルータを含むネットワークの向こう側に修理するマルチキャストにVPNの特定の特徴を提供する能力があるでしょう。
In any case, a solution SHOULD state a migration policy from possibly existing deployments.
ことによると既存の展開からのどんなケース、解決策SHOULD状態の移動方針。
5.2.12. Troubleshooting
5.2.12. トラブルシューティング
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解決策は障害調査しにくい不都合を被るかもしれません。 助けるために、このような場合には、マルチキャストネットワーク問題(クライアント交通がどう運ばれるかを(例えば、解決策がマルチキャストベースのMDTunnelsを使用するなら、どのプロバイダーマルチキャストが分類されるかは与えられたクライアントマルチキャストの流れに使用されます)ネットワークに説明する情報をモニターするSHOULDが提供するマルチキャストVPN解決法)を診断してください。 また、解決策はどんなダイナミックな変化も避けるために設定オプションを提供するかもしれません、特定のVPNか特定のマルチキャストの流れのマルチキャスト交通に。
Moreover, a solution MAY provide mechanisms that allow network operators to check that all VPN sites that advertised interest in a particular customer multicast stream are properly associated with the corresponding MDTunnel. Providing operators with means to check the proper setup and operation of MDTunnels MAY also be provided (e.g., when P2MP MPLS is used for MDTunnels, troubleshooting functionalities SHOULD integrate mechanisms compliant with [RFC4687], such as LSP Ping [RFC4379][LSP-PING]). Depending on the implementation, such verification could be initiated by a source-PE or a receiver-PE.
そのうえ、解決策はネットワーク・オペレータが、うるさい顧客マルチキャストの流れで関心の広告を出したすべてのVPNサイトが適切に対応するMDTunnelに関連づけられるのをチェックできるメカニズムを提供するかもしれません。 また、MDTunnelsの適切なセットアップと操作をチェックする手段をオペレータに提供するのを提供するかもしれません(例えば、P2MP MPLSがMDTunnelsに使用されるとき、トラブルシューティング機能性SHOULDは[RFC4687]に伴う対応することのメカニズムを統合します、LSP Ping[RFC4379][LSP-PING]などのように)。 実現によって、ソース-PEか受信機-PEがそのような検証を開始できました。
6. Security Considerations
6. セキュリティ問題
This document does not by itself raise any particular security issue.
このドキュメント自体は少しの特定の安全保障問題も提起しません。
A set of security issues has been identified that MUST be addressed when considering the design and deployment of multicast-enabled L3 PPVPNs. Such issues have been described in Section 5.1.5 and Section 5.2.8.
マルチキャストで可能にされたL3 PPVPNsのデザインと展開を考えるとき記述しなければならない1セットの安全保障問題は特定されました。 そのような問題はセクション5.1.5とセクション5.2.8で説明されます。
Morin Informational [Page 30] RFC 4834 L3VPN Mcast Reqs April 2007
[30ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
7. Contributors
7. 貢献者
The main contributors to this document are listed below, in alphabetical order:
このドキュメントへの主な寄稿者は以下にアルファベット順に記載されています:
o Christian Jacquenet
France Telecom
3, avenue Francois Chateau
CS 36901 35069 RENNES Cedex, France
Email: christian.jacquenet@orange-ftgroup.com
o クリスチャンのJacquenetフランステレコム3、Cedex、フランソアChateau CS36901 35069レンヌフランスがメールする大通り: christian.jacquenet@orange-ftgroup.com
o Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: y.kamite@ntt.com
o Yuji Kamite NTTコミュニケーションズ株式会社新宿、オペラ市の新宿区東京塔3-20-2西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 ジャン・ルイル・ルーのフランステレコムの研究開発2、大通りピアー-Marzin22307Lannion Cedex、フランスメール: jeanlouis.leroux@orange-ftgroup.com
o Nicolai Leymann
Deutsch Telecom
Engineering Networks, Products & Services
Goslarer Ufer 3510589 Berlin, Germany
Email: nicolai.leymann@t-systems.com
o ニコライLeymannドイツ語テレコムの工学ネットワークと製品とServices Goslarer Ufer3510589ベルリン(ドイツ)はメールされます: nicolai.leymann@t-systems.com
o Renaud Moignard
France Telecom R&D
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: renaud.moignard@orange-ftgroup.com
o レノードMoignardフランステレコムの研究開発2、大通りピアー-Marzin22307Lannion Cedex、フランスメール: 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&D2、大通りピアー-Marzin22307Lannion Cedex、フランスメール: thomas.morin@orange-ftgroup.com
8. Acknowledgments
8. 承認
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
作者は荒い年代順にヴィンセントParfait、ズバイル・アフマド、Elodieエモン-Larreur、セバスチアン・ロイ、Rahul Aggarwal、福田等に感謝したがっています、Luyuan Fang、エードリアン・ファレル、ダニエル・キング、Yiqun Cai、ロナルドBonica、レンNieman、Satoru松島、ネツァワルコヨトルOrnelas、ヤコフRekhter、マーシャル・ユーバンクス、ペッカ
Morin Informational [Page 31] RFC 4834 L3VPN Mcast Reqs April 2007
[31ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, valuable input, and feedback.
Savola、ベンジャミン・ニーヴン-ジェンキンス、および彼らのレビュー、貴重な入力、およびフィードバックのためのトーマス・ナドー。
We also thank the people who kindly answered the survey, and Daniel King, who took care of gathering and anonymizing its results.
また、私たちは親切に調査に答えた人々、およびダニエル・キングに感謝します。(キングは、結果を集めて、anonymizingするように注意しました)。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for
Layer 3 Provider-Provisioned Virtual Private
Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031]CarugiとM.とD.McDysan、「層3のプロバイダーで食糧を供給された仮想私設網(PPVPNs)のためのサービス要件」、RFC4031、2005年4月。
[RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned
Virtual Private Network (VPN) Terminology",
RFC 4026, March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーで食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
Kouvelas, "Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised)",
RFC 4601, August 2006.
[RFC4601] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
for IP", RFC 4607, August 2006.
[RFC4607] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、2006年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual
Private Networks (L3VPN) Operations and Management",
RFC 4176, October 2005.
[RFC4176] 高架鉄道Mghazli、Y.、ナドー、T.、Boucadair、M.、チェン、K.、およびA.Gonguet、「層3の仮想私設網(L3VPN)操作と管理のための枠組み」、RFC4176(2005年10月)。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised)", RFC 3973,
January 2005.
[RFC3973] アダムス、A.、ニコラス、J.、およびW.Siadak、「プロトコルの独立しているマルチキャスト--濃いモード(PIM-DM):、」 「プロトコル仕様(改訂される)」、RFC3973、2005年1月。
Morin Informational [Page 32] RFC 4834 L3VPN Mcast Reqs April 2007
[32ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
9.2. Informative References
9.2. 有益な参照
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[VRs] Ould-Brahim, H., "Network based IP VPN Architecture
Using Virtual Routers", Work in Progress,
March 2006.
[VRs]オールド-Brahim、H.、「ネットワークのベースのIP VPN Architecture Using Virtual Routers」、Progress、2006年3月のWork。
[RFC2432] Dubray, K., "Terminology for IP Multicast
Benchmarking", RFC 2432, October 1998.
[RFC2432] Dubray、K.、「IPマルチキャストベンチマーキングのための用語」、RFC2432、1998年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC 2236, November 1997.
w.[RFC2236]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[P2MP-RSVP-TE] Aggarwal, R., "Extensions to RSVP-TE for Point-to-
Multipoint TE LSPs", Work in Progress, August 2006.
R.、「ポイントから多点へのTe LSPsのためのRSVP-Teへの拡大」という[P2MP-RSVP-Te]Aggarwalは進歩、2006年8月に働いています。
[PIM-BSR] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for
PIM", Work in Progress, June 2006.
N.、「PIMのためにルータ(BSR)メカニズムを独力で進んでください」という[PIM-BSR]Bhaskarは進歩、2006年6月に働いています。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]ファリナッチとD.とY.Cai、「プロトコルの独立しているマルチキャスト(PIM)を使用するAnycast-RP」、RFC4610、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] キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、「プロトコルの無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコル(MSDP)を使用するAnycast Rendevous Point(RP)メカニズム」、RFC3446(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.
I.と、「ポイントツーマルチポイントのためのラベル分配プロトコル拡大と多点から多点へのラベル切り換えられた経路」という[P2MP-自由民主党]Mineiは進歩、2006年10月に働いています。
[P2MP-LDP-REQS] Roux, J., "Requirements for point-to-multipoint
extensions to the Label Distribution Protocol",
Work in Progress, June 2006.
[P2MP自由民主党REQS]ルー、J.、「Label Distributionプロトコルへのポイントツーマルチポイント拡大のための要件」、Progress、2006年6月のWork。
Morin Informational [Page 33] RFC 4834 L3VPN Mcast Reqs April 2007
[33ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
[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.、ファレル、A.、キング、D.、およびT.ナドー、「ポイントツーマルチポイントMPLSネットワークのための操作と管理(OAM)要件」、RFC4687(2006年9月)。
[BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent
Multicast (BIDIR-PIM)", Work in Progress,
October 2005.
[BIDIR-PIM] ハンドレー、M.、「双方向のプロトコル独立しているマルチキャスト(BIDIR-PIM)」が進歩、2005年10月に働いています。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、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.
オームス、販売(B.)が賑す[RFC3353]D.、W.、Acharya、A.、Griffoul、F.、およびF.Ansari、「マルチプロトコルラベルスイッチング(MPLS)環境における、IPマルチキャストの概観」RFC3353(2002年8月)。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
X. Xiao, "Overview and Principles of Internet
Traffic Engineering", RFC 3272, May 2002.
[RFC3272] Awduche、D.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、およびX.Xiao、「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[IPFIX-PROT] Claise, B., "Specification of the IPFIX Protocol for
the Exchange", Work in Progress, November 2006.
B.、「交換のためのIPFIXプロトコルの仕様」という[IPFIX-PROT]Claiseは進歩、2006年11月に働いています。
[RFC4045] Bourdon, G., "Extensions to Support Efficient
Carrying of Multicast Traffic in Layer-2 Tunneling
Protocol (L2TP)", RFC 4045, April 2005.
G. [RFC4045]低音部音栓、RFC4045、「サポート効率的への拡大は層-2トンネリングプロトコル(L2TP)におけるマルチキャスト交通を運ぶ」4月2005日
[RFC3809] Nagarajan, A., "Generic Requirements for Provider-
Provisioned Virtual Private Networks (PPVPN)",
RFC 3809, June 2004.
[RFC3809]Nagarajan、A.、「プロバイダーのための一般的な要件は仮想私設網(PPVPN)に食糧を供給した」RFC3809、2004年6月。
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", RFC 3811, June 2004.
[RFC3811] ナドー、T.、およびJ.Cucchiara、「Multiprotocolのための原文のコンベンション(TCs)の定義は切り換え(MPLS)を管理とラベルします」、RFC3811、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.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
Morin Informational [Page 34] RFC 4834 L3VPN Mcast Reqs April 2007
[34ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
[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.ナドー、「Multiprotocolはラベル切り換えルータ(LSR)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3813、2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
"Multiprotocol Label Switching (MPLS) Forwarding
Equivalence Class To Next Hop Label Forwarding Entry
(FEC-To-NHLFE) Management Information Base (MIB)",
RFC 3814, June 2004.
[RFC3814] ナドー、T.、Srinivasan、C.、およびA.Viswanathan、「次に跳ぶために同値類を進めるMultiprotocolラベル切り換え(MPLS)が推進エントリー(FECからNHLFE)を管理情報ベース(MIB)とラベルします」、RFC3814、2004年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
BCP 23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2330]パクソン(V.とAlmesとG.とMahdavi、J.とM.マシス、「IPパフォーマンス測定基準のための枠組み」RFC2330)は1998がそうするかもしれません。
[MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for
spatial and multicast", Work in Progress,
October 2006.
[MULTIMETRICS]シュテファン、E.、「IPパフォーマンスMetrics(IPPM)、空間的である、マルチキャスト、」、Progress、10月2006日のWork
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
233/8", BCP 53, RFC 3180, September 2001.
[RFC3180] マイヤーとD.とP.Lothberg、「233/8インチ、BCP53、RFCに3180、2001年9月を記述するGLOP。」
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3411] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理枠組みについて説明するための構造」、STD62、RFC3411(2002年12月)。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC2578]McCloghrie、K.(エド)、パーキンス、D.(エド)、およびJ.Schoenwaelder(エド)、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3
Virtual Private Network (VPN) Management Information
Base", RFC 4382, February 2006.
[RFC4382] ナドー、T.、およびH.はderリンデ、「MPLS/BGP層3の仮想私設網(VPN)管理情報ベース」をバンに積みます、RFC4382、2006年2月。
Morin Informational [Page 35] RFC 4834 L3VPN Mcast Reqs April 2007
[35ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Protocol Label Switched (MPLS) Data Plane Failures",
RFC 4379, February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane
Failures in Point-to-Multipoint Multiprotocol",
Work in Progress, September 2006.
「多点へのポイントのデータ飛行機失敗Multiprotocolを検出し」て、[LSP-ピング]のファレル、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と断片化がコネで発行する、-、ネットワーク、トンネリング、」、RFC4459、4月2006日
Author's Address
作者のアドレス
Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France
トーマスモーリン(エディタ)フランステレコムR&D2、大通りピアー・Marzin Lannion22307フランス
EMail: thomas.morin@orange-ftgroup.com
メール: thomas.morin@orange-ftgroup.com
Morin Informational [Page 36] RFC 4834 L3VPN Mcast Reqs April 2007
[36ページ]RFC4834L3VPN Mcast Reqs2007年4月の情報のモーリン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Morin Informational [Page 37]
モーリンInformationalです。[37ページ]
一覧
スポンサーリンク
