RFC3809 日本語訳
3809 Generic Requirements for Provider Provisioned Virtual PrivateNetworks (PPVPN). A. Nagarajan, Ed.. June 2004. (Format: TXT=60576 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Nagarajan, Ed. Request for Comments: 3809 Juniper Networks Category: Informational June 2004
ワーキンググループA.Nagarajan、エドをネットワークでつないでください。コメントのために以下を要求してください。 3809年の杜松はカテゴリをネットワークでつなぎます: 情報の2004年6月
Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)
プロバイダーの食糧を供給された仮想私設網のためのジェネリック要件(PPVPN)
Status of this Memo
この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 Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.
このドキュメントはProvider Provisioned Virtual兵士のNetworks(PPVPN)のためのジェネリック要件について説明します。 要件はサービス要件、プロバイダー要件、および工学要件に分類されます。 これらの要件はどんな特定のタイプのPPVPN技術にも特定ではありませんが、むしろすべてのPPVPN技術に適用してください。 すべてのPPVPN技術が本書では説明された要件のかさのセットに会うと予想されます。
Nagarajan Informational [Page 1] RFC 3809 PPVPN June 2004
[1ページ]RFC3809PPVPN2004年6月の情報のNagarajan
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Scenarios. . . . . . . . . . . . . . . . . . . 4
1.3. Outline of this document. . . . . . . . . . . . . . . . . 5
2. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . 7
4. Service Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.1. Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Data Isolation. . . . . . . . . . . . . . . . . . . . . . 9
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. User data security . . . . . . . . . . . . . . . . 10
4.5.2. Access Control . . . . . . . . . . . . . . . . . . 10
4.5.3. Site authentication and authorization. . . . . . . 10
4.5.4. Inter domain security. . . . . . . . . . . . . . . 10
4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Quality of Service . . . . . . . . . . . . . . . . . . . 11
4.9. Service Level Agreement and Service Level Specification
Monitoring and Reporting. . . . . . . . . . . . . . . . . 13
4.10.Network Resource Partitioning and Sharing between VPNs. . 14
5. Provider requirements. . . . . . . . . . . . . . . . . . . . . 14
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Provider Capacity Sizing Projections . . . 15
5.1.2. VPN Scalability aspects. . . . . . . . . . . . . . 15
5.1.3. Solution-Specific Metrics. . . . . . . . . . . . . 17
5.2. Management . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Customer Management of a VPN . . . . . . . . . . . 18
6. Engineering requirements . . . . . . . . . . . . . . . . . . . 19
6.1. Forwarding plane requirements . . . . . . . . . . . . . . 19
6.2. Control plane requirements. . . . . . . . . . . . . . . . 20
6.3. Control Plane Containment . . . . . . . . . . . . . . . . 20
6.4. Requirements related to commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms. . . 21
6.5. Interoperability . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References. . . . . . . . . . . . . . . . . . . 23
8.2. Informative References. . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 24
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 問題声明. . . . . . . . . . . . . . . . . . . . 3 1.2。 展開シナリオ。 . . . . . . . . . . . . . . . . . . 4 1.3. このドキュメントのアウトライン。 . . . . . . . . . . . . . . . . 5 2. 貢献は.6 3を書きます。 定義と分類学. . . . . . . . . . . . . . . . . . . 7 4。 要件. . . . . . . . . . . . . . . . . . . . . 7 4.1を修理してください。 有用性. . . . . . . . . . . . . . . . . . . . . . 7 4.2。 安定性. . . . . . . . . . . . . . . . . . . . . . . . 8 4.3。 トラフィックは.84.4をタイプします。 データ分離。 . . . . . . . . . . . . . . . . . . . . . 9 4.5. セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.1。 利用者データセキュリティ. . . . . . . . . . . . . . . . 10 4.5.2。 コントロール. . . . . . . . . . . . . . . . . . 10 4.5.3にアクセスしてください。 サイト認証と承認。 . . . . . . 10 4.5.4. ドメインセキュリティを埋葬してください。 . . . . . . . . . . . . . . 10 4.6. トポロジー. . . . . . . . . . . . . . . . . . . . . . . . 11 4.7。 扱います。 . . . . . . . . . . . . . . . . . . . . . . . 11 4.8. サービスの質. . . . . . . . . . . . . . . . . . . 11 4.9。 サービスレベル協定とサービスは仕様モニターと報告を平らにします。 . . . . . . . . . . . . . . . . 13 4.10. ネットワーク資源仕切りとVPNsを平等に割り当てること。 . 14 5. プロバイダー要件。 . . . . . . . . . . . . . . . . . . . . 14 5.1. スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1。 映像. . . 15 5.1.2を大きさで分けるサービスプロバイダー容量。 VPN Scalability局面。 . . . . . . . . . . . . . 15 5.1.3. ソリューション特有の測定基準。 . . . . . . . . . . . . 17 5.2. 管理. . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1。 VPN. . . . . . . . . . . 18 6の顧客管理。 要件. . . . . . . . . . . . . . . . . . . 19 6.1を設計します。 飛行機要件. . . . . . . . . . . . . . 19 6.2を転送します。 飛行機要件を制御してください。 . . . . . . . . . . . . . . . 20 6.3. 飛行機封じ込め. . . . . . . . . . . . . . . . 20 6.4を制御してください。 要件は互いとジェネリックインターネットメカニズム21…6.5でPPVPNメカニズムの共通点に関連しました。 相互運用性. . . . . . . . . . . . . . . . . . . . 21 7。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 22 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1。 引用規格。 . . . . . . . . . . . . . . . . . . 23 8.2. 有益な参照。 . . . . . . . . . . . . . . . . . 23 9. 承認. . . . . . . . . . . . . . . . . . . . . . . 24 10。 エディタのアドレス. . . . . . . . . . . . . . . . . . . . . . . 24 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 25
Nagarajan Informational [Page 2] RFC 3809 PPVPN June 2004
[2ページ]RFC3809PPVPN2004年6月の情報のNagarajan
1. Introduction
1. 序論
This document is an output of the design team formed to develop requirements for PPVPNs in the Provider Provisioned Virtual Private Networks (PPVPN) working group and provides requirements that are generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3 Virtual Private Networks (L3VPN). This document discusses generic PPVPN requirements categorized as service, provider and engineering requirements. These are independent of any particular type of PPVPN technology. In other words, all PPVPN technologies are expected to meet the umbrella set of requirements described in this document. PPVPNs may be constructed across single or multiple provider networks and/or Autonomous Systems (ASes). In most cases the generic requirements described in this document are independent of the deployment scenario. However, specific requirements that differ based on whether the PPVPN is deployed across single or multiple providers (and/or ASes) will be pointed out in the document. Specific requirements related to Layer 3 PPVPNs are described in [L3REQTS]. Similarly, requirements that are specific to layer 2 PPVPNs are described in [L2REQTS].
このドキュメントは、Provider Provisioned Virtual兵士のNetworks(PPVPN)ワーキンググループでPPVPNsのための要件を開発するために形成されたデザインチームの出力であり、Layer2Virtual兵士のNetworks(L2VPN)とLayer3Virtual兵士のNetworks(L3VPN)の両方にジェネリックである要件を供給します。 このドキュメントはサービス、プロバイダー、および工学要件として分類されたジェネリックPPVPN要件について議論します。 これらはどんな特定のタイプのPPVPN技術からも独立しています。 言い換えれば、すべてのPPVPN技術が本書では説明された要件のかさのセットに会うと予想されます。 PPVPNsは単一であるか複数のプロバイダーネットワーク、そして/または、Autonomous Systems(ASes)の向こう側に組み立てられるかもしれません。 多くの場合、本書では説明されたジェネリック要件は展開シナリオから独立しています。 しかしながら、PPVPNが単一であるか複数のプロバイダー(そして/または、ASes)の向こう側に配布されるかどうかに基づいて異なる決められた一定の要求はドキュメントで指摘されるでしょう。 Layer3PPVPNsに関連する決められた一定の要求は[L3REQTS]で説明されます。 同様に、2PPVPNsを層にするために特定の要件は[L2REQTS]で説明されます。
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]で説明されるように本書では解釈されることであるべきですか?
1.1. Problem Statement
1.1. 問題声明
Corporations and other organizations have become increasingly dependent on their networks for telecommunications and data communication. The data communication networks were originally built as Local Area Networks (LAN). Over time the possibility to interconnect the networks on different sites has become more and more important. The connectivity for corporate networks has been supplied by service providers, mainly as Frame Relay (FR) or Asynchronous Transfer Mode (ATM) connections, and more recently as Ethernet and IP-based tunnels. This type of network, interconnecting a number of sites over a shared network infrastructure is called Virtual Private Network (VPN). If the sites belong to the same organization, the VPN is called an Intranet. If the sites belong to different organizations that share a common interest, the VPN is called an Extranet.
社と他の組織はますますテレコミュニケーションとデータ通信においてそれらのネットワークに依存するようになりました。 データ通信ネットワークは元々、ローカル・エリア・ネットワーク(LAN)として造られました。 時間がたつにつれて、異なったサイトでネットワークとインタコネクトする可能性はますます重要になりました。 企業ネットワークのための接続性は主にFrame Relay(FR)かAsynchronous Transfer Mode(ATM)接続、および最近、イーサネットとIPベースのトンネルとしてのその他としてサービスプロバイダーによって提供されました。 ネットワークのこのタイプであり、共用回線網インフラストラクチャの上で多くのサイトとインタコネクトするのはVirtual兵士のNetwork(VPN)と呼ばれます。 サイトが同じ組織に属すなら、VPNはイントラネットと呼ばれます。 サイトが共通の利益を共有する異なった組織に属すなら、VPNはエクストラネットと呼ばれます。
Customers are looking for service providers to deliver data and telecom connectivity over one or more shared networks, with service level assurances in the form of security, QoS and other parameters.
顧客は、セキュリティ、QoS、および他のパラメタの形でサービスレベル保証でデータとテレコムの接続性に1つ以上の共用回線網を提供するためにサービスプロバイダーを探しています。
Nagarajan Informational [Page 3] RFC 3809 PPVPN June 2004
[3ページ]RFC3809PPVPN2004年6月の情報のNagarajan
In order to provide isolation between the traffic belonging to different customers, mechanisms such as Layer 2 connections or Layer 2/3 tunnels are necessary. When the shared infrastructure is an IP network, the tunneling technologies that are typically used are IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
異なった顧客のものであるトラフィックの間に分離を提供するために、Layer2接続かLayer2/3トンネルなどのメカニズムが必要です。 共有されたインフラストラクチャがIPネットワークであるときに、通常使用されているのが、IPsecであるということであるトンネリング技術、MPLS、L2TP、IPにおけるIP GREですなど。
Traditional Internet VPNs have been based on IPsec to provide security over the Internet. Service providers are now beginning to deploy enhanced VPN services that provide features such as service differentiation, traffic management, Layer 2 and Layer 3 connectivity, etc. in addition to security. Newer tunneling mechanisms have certain features that allow the service providers to provide these enhanced VPN services.
伝統的なインターネットVPNは、インターネットの上にセキュリティを提供するためにIPsecに基づきました。 サービスプロバイダーは現在、セキュリティに加えてサービス分化や輸送管理やLayer2やLayer3の接続性などの特徴を提供する高められたVPNサービスを配布し始めています。 より新しいトンネリングメカニズムには、サービスプロバイダーがこれらの高められたVPNサービスを提供できるある特徴があります。
The VPN solutions we define now MUST be able to accommodate the traditional types of VPNs as well as the enhanced services now being deployed. They need to be able to run in a single service provider's network, as well as between a set of service providers and across the Internet. In doing so the VPNs SHOULD NOT be allowed to violate basic Internet design principles or overload the Internet core routers or accelerate the growths of the Internet routing tables. Specifically, Internet core routers SHALL NOT be required to maintain VPN-related information, regardless of whether the Internet routing protocols are used to distribute this information or not. In order to achieve this, the mechanisms used to develop various PPVPN solutions SHALL be as common as possible with generic Internet infrastructure mechanisms like discovery, signaling, routing and management. At the same time, existing Internet infrastructure mechanisms SHALL NOT be overloaded.
私たちが現在定義するVPNソリューションは現在配布される高度サービスと同様にVPNsの伝統的なタイプに対応できなければなりません。 彼らは、ただ一つのサービスプロバイダーのネットワークに立候補できる必要があります、よく1セットのサービスプロバイダーの間と、そして、インターネットの向こう側に。 そうVPNs SHOULDをする際に、基本的なインターネット設計原理に違反しないでください、インターネットコアルータを積みすぎないでください、またはインターネット経路指定テーブルの腫瘍は加速させられないでください。 明確に、インターネットはルータSHALL NOTの芯を取ります。VPN関連の情報を保守するのを必要であってください、インターネットルーティング・プロトコルがこの情報を分配するのに使用されるかどうかにかかわらず。 メカニズムは、これを達成するために以前はよく様々なPPVPNソリューションSHALLを開発していました。できるだけ発見、シグナリング、ルーティング、および管理のようなジェネリックインターネット基盤メカニズムについて一般的であってください。 存在していて、同じくらいでは、インターネット基盤メカニズムSHALL NOTは調節しています。積みすぎられます。
Another generic requirement from a standardization perspective is to limit the number of different solution approaches. For example, for service providers that need to support multiple types of VPN services, it may be undesirable to require a completely different solution approach for each type of VPN service.
標準化見解からの別のジェネリック要件は異なったソリューションアプローチの数を制限することです。 例えば、複数のVPNサービスのタイプをサポートする必要があるサービスプロバイダーに、それぞれのタイプのVPNサービスのための完全に異なったソリューションアプローチを必要とするのは望ましくないかもしれません。
1.2. Deployment Scenarios
1.2. 展開シナリオ
There are three different deployment scenarios that need to be considered for PPVPN services:
PPVPNサービスのために考えられる必要がある3つの異なった展開シナリオがあります:
1. Single-provider, single-AS: This is the least complex scenario,
where the PPVPN service is offered across a single service
provider network spanning a single Autonomous System.
1. ただ一つのプロバイダーである、単一である、-、: これは最も複雑でないシナリオです。(そこでは、PPVPNサービスが独身のAutonomous Systemにかかるただ一つのサービスプロバイダーネットワークの向こう側に提供されます)。
2. Single-provider, multi-AS: In this scenario, a single provider may
have multiple Autonomous Systems (for e.g., a global Tier-1 ISP
with different ASes depending on the global location, or an ISP
2. ただ一つのプロバイダーである、マルチ、: このシナリオでは、ただ一つのプロバイダーが複数のAutonomous Systemsを持っているかもしれない、(例えば、異なったASesがグローバルな位置、またはISPによっているグローバルなTier-1ISP
Nagarajan Informational [Page 4] RFC 3809 PPVPN June 2004
[4ページ]RFC3809PPVPN2004年6月の情報のNagarajan
that has been created by mergers and acquisitions of multiple
networks). This scenario involves the constrained distribution of
routing information across multiple Autonomous Systems.
複数のネットワークの合併吸収でそれを作成してある、) このシナリオは複数のAutonomous Systemsの向こう側にルーティング情報の強制的な分配にかかわります。
3. Multi-provider: This scenario is the most complex, wherein trust
negotiations need to be made across multiple service provider
backbones in order to meet the security and service level
agreements for the PPVPN customer. This scenario can be
generalized to cover the Internet, which comprises of multiple
service provider networks. It should be noted that customers can
construct their own VPNs across multiple providers. However such
VPNs are not considered here as they would not be "Provider-
provisioned".
3. マルチプロバイダー: このシナリオは最も複雑です、信頼交渉が、PPVPN顧客のためにセキュリティとサービスレベル協定を満たすために複数のサービスプロバイダーバックボーンの向こう側に作られている必要があるところで。 インターネットをカバーするためにこのシナリオを広めることができます。(インターネットは複数のサービスプロバイダーでネットワークを包括します)。 顧客が複数のプロバイダーの向こう側にそれら自身のVPNsを組み立てることができることに注意されるべきです。 そのようなVPNsがここでどのように考えられないでも、彼らのように、「食糧を供給されたプロバイダー」でないでしょう。
A fourth scenario, "Carrier's carrier" VPN may also be considered. In this scenario, a service provider (for example, a Tier 1 service provider) provides VPN service to another service provider (for example, a Tier 2 service provider), which in turn provides VPN service on its VPN to its customers. In the example given above, the Tier 2 provider's customers are contained within the Tier 2 provider's network, and the Tier 2 provider itself is a customer of the Tier 1 provider's network. Thus, this scenario is not treated separately in the document, because all of the single provider requirements would apply equally to this case.
また、4番目のシナリオ、「キャリヤーのキャリヤー」VPNは考えられるかもしれません。 このシナリオでは、サービスプロバイダー(例えば、Tier1つのサービスプロバイダー)は別のサービスプロバイダー(例えば、Tier2サービスプロバイダー)に対するサービスをVPNに供給します。(順番に、それは、顧客へのVPNにおけるサービスをVPNに供給します)。 例では、上、Tierを考えて、2プロバイダーの顧客は2プロバイダーのものがネットワークでつなぐTierの中に含まれています、そして、Tier2プロバイダー自体はプロバイダーの1つのものがネットワークでつなぐTierの顧客です。 したがって、このシナリオは別々にドキュメントで扱われません、ただ一つのプロバイダー要件のすべてが等しく本件に適用されるでしょう、したがって。
It is expected that many of the generic requirements described in this document are independent of the three deployment scenarios listed above. However, specific requirements that are indeed dependent on the deployment scenario will be pointed out in this document.
本書では説明されたジェネリック要件の多くが上に記載された3つの展開シナリオから独立していると予想されます。 しかしながら、本当に、展開シナリオに依存する決められた一定の要求は本書では指摘されるでしょう。
1.3. Outline of this document
1.3. このドキュメントのアウトライン
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The document contains several sections, with each set representing a significant aspect of PPVPN requirements.
このドキュメントはProvider Provisioned Virtual兵士のNetworks(PPVPN)のためのジェネリック要件について説明します。 ドキュメントは各セットがPPVPN要件の重要な局面を表している数人のセクションを含みます。
Section 2 lists authors who contributed to this document. Section 3 defines terminology and presents a taxonomy of PPVPN technologies. The taxonomy contains two broad classes, representing Layer 2 and Layer 3 VPNs. Each top level VPN class contains subordinate classes. For example, the Layer 3 VPN class contains a subordinate class of PE-based Layer 3 VPNs.
セクション2はこのドキュメントに貢献した作者を記載します。 セクション3は、用語を定義して、PPVPN技術の分類学を提示します。 Layer2とLayer3VPNsを表して、分類学は2つの広いクラスを含みます。 それぞれのトップ平らなVPNのクラスは被支配階級を含みます。 例えば、Layer3VPNのクラスはPEベースのLayer3VPNsの被支配階級を含みます。
Sections 4, 5, 6 describe generic PPVPN requirements.
セクション4、5、6はジェネリックPPVPN要件について説明します。
Nagarajan Informational [Page 5] RFC 3809 PPVPN June 2004
[5ページ]RFC3809PPVPN2004年6月の情報のNagarajan
The requirements are broadly classified under the following categories:
要件は以下のカテゴリの下で露骨に分類されます:
1) Service requirements - Service attributes that the customer can
observe or measure. For example, does the service forward frames
or route datagrams? What security guarantees does the service
provide? Availability and stability are key requirements in this
category.
1) サービス要件--顧客が観測するか、または測定できる属性を修理してください。 例えば、サービスはフレームかルートデータグラムを進めますか? サービスはどんなセキュリティ保証を提供しますか? 有用性と安定性はこのカテゴリにおいて主要な要件です。
2) Provider requirements - Characteristics that Service Providers use
to determine the cost-effectiveness of a PPVPN service. Scaling
and management are examples of Provider requirements.
2) プロバイダー要件--Service ProvidersがPPVPNサービスの費用対効果を決定するのに使用する特性。 スケーリングと管理はProvider要件に関する例です。
3) Engineering requirements - Implementation characteristics that
make service and provider requirements achievable. These can be
further classified as:
3) 工学要件--サービスとプロバイダー要件を達成可能にする実装の特性。 以下としてさらにこれらを分類できます。
3a) Forwarding plane requirements - e.g., requirements related to
router forwarding behavior.
3a) 推進飛行機要件--例えば、要件はルータ推進の振舞いに関連しました。
3b) Control plane requirements - e.g., requirements related to
reachability and distribution of reachability information.
3b) コントロール飛行機要件--例えば、要件は可到達性情報の可到達性と分配に関連しました。
3c) Requirements related to the commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms.
3c) 要件は互いとジェネリックインターネットメカニズムがあるPPVPNメカニズムの共通点に関連しました。
2. Contributing Authors
2. 作者を寄付します。
This document was the combined effort of several individuals that were part of the Service Provider focus group whose intentions were to present Service Provider view on the general requirements for PPVPN. A significant set of requirements were directly taken from previous work by the PPVPN WG to develop requirements for Layer 3 PPVPN [L3REQTS]. The existing work in the L2 requirements area has also influenced the contents of this document [L2REQTS].
このドキュメントはPPVPNのための一般的な要件に関するService Provider意見を提示する意志がことであったService Providerフォーカス・グループの一部であった何人かの個人の協力でした。 重要なセットの要件は、Layer3PPVPN[L3REQTS]のための要件を開発するためにPPVPN WGによって前の仕事から直接取られました。 また、L2要件領域での既存の仕事はこのドキュメント[L2REQTS]のコンテンツに影響を及ぼしました。
Besides the editor, the following are the authors that contributed to this document:
エディタ以外に、↓これはこのドキュメントに貢献した作者です:
Loa Andersson (loa@pi.se)
Ron Bonica (ronald.p.bonica@mci.com)
Dave McDysan (dave.mcdysan@mci.com)
Junichi Sumimoto (j.sumimoto@ntt.com)
Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp)
David Meyer (dmm@1-4-5.net)
Marco Carugi (marco.carugi@nortelnetworks.com)
Loaアンデション( loa@pi.se )ロンBonica( ronald.p.bonica@mci.com )デーヴMcDysan( dave.mcdysan@mci.com )Junichi Sumimoto( j.sumimoto@ntt.com )Muneyoshi鈴木・( suzuki.muneyoshi@lab.ntt.co.jp )デヴィッド・マイヤー(dmm@1-4-5.net)マルコCarugi( marco.carugi@nortelnetworks.com )
Nagarajan Informational [Page 6] RFC 3809 PPVPN June 2004
[6ページ]RFC3809PPVPN2004年6月の情報のNagarajan
Yetik Serbest (yetik_serbest@labs.sbc.com)
Luyuan Fang (luyuanfang@att.com)
Javier Achirica (achirica@telefonica.net)
Yetik Serbest( yetik_serbest@labs.sbc.com )Luyuan牙( luyuanfang@att.com )のハビエルAchirica( achirica@telefonica.net )
3. Definitions and Taxonomy
3. 定義と分類学
The terminology used in this document is defined in [TERMINOLOGY]. In addition the following terminology is used:
本書では使用される用語は[TERMINOLOGY]で定義されます。 さらに、以下の用語は使用されています:
Site: a geographical location with one or more users or one or more servers or a combination of servers and users.
サイト: 1人以上のユーザ、1つ以上のサーバまたはサーバとユーザの組み合わせがある地理的な位置。
User: the end user equipment (hosts), e.g., a workstation.
ユーザ: エンドユーザ設備(ホスト)、例えば、ワークステーション。
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|__________|
______|_____
| |
P2P P2MP
PPVPN________________|__________________ | | 層2(L2)の層3(L3)______|_____ ______|________ | | | | PEベース、Ceベース、PEベース、Ceベース|__________| ______|_____ | | P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. PE-based and CE-based Layer 2 VPNs may also be further classified as point-to- point (P2P) or point-to-multipoint (P2MP). It is also the intention of the working group to have a limited number of solutions, and this goal must be kept in mind when proposing solutions that meet the requirements specified in this document. Definitions for CE-based and PE-based PPVPNs can be obtained from [L3FRAMEWORK]. Layer 2 specific definitions can be obtained from [L2FRAMEWORK].
上の図形はPPVPN技術の分類学を提示します。 また、PEベースの、そして、CEベースのLayer2VPNsはポイントからポイント(P2P)かポイントツーマルチポイント(P2MP)としてさらに分類されるかもしれません。 また、それはワーキンググループには限られた数のソリューションがあるという意志です、そして、本書では指定された必要条件を満たすソリューションを提案するとき、この目標を覚えておかなければなりません。 [L3FRAMEWORK]からCEベースの、そして、PEベースのPPVPNsのための定義を得ることができます。 特定の定義を得ることができる2[L2FRAMEWORK]を層にしてください。
4. Service requirements
4. サービス要件
These are the requirements that a customer can observe or measure, in order to verify if the PPVPN service that the Service Provider (SP) provides is satisfactory. As mentioned before, each of these requirements apply equally across each of the three deployment scenarios unless stated otherwise.
これらは顧客が見るか、または測定できるという要件です、Service Provider(SP)が提供するPPVPNサービスが満足できるかどうか確かめるために。 以前言及されるように、別の方法で述べられない場合、それぞれのこれらの要件はそれぞれの3つの展開シナリオの向こう側に等しく適用されます。
4.1. Availability
4.1. 有用性
VPN services MUST have high availability. VPNs that are distributed over several sites require connectivity to be maintained even in the event of network failures or degraded service.
VPNサービスには、高い有用性がなければなりません。 いくつかのサイトにわたって分配されるVPNsは、接続性がネットワーク失敗か降格しているサービスの場合さえ、維持されるのを必要とします。
Nagarajan Informational [Page 7] RFC 3809 PPVPN June 2004
[7ページ]RFC3809PPVPN2004年6月の情報のNagarajan
This can be achieved via various redundancy techniques such as:
以下などの様々な冗長のテクニックでこれを達成できます。
1. Physical Diversity
1. 物理的な多様性
A single site connected to multiple CEs (for CE-based PPVPNs) or
PEs (for PE-based PPVPNs), or different POPs, or even different
service providers.
ただ一つのサイトは複数のCEs(CEベースのPPVPNsのための)、PEs(PEベースのPPVPNsのための)、異なったPOP、または異なったサービスプロバイダーにさえ接続しました。
2. Tunnel redundancy
2. トンネル冗長
Redundant tunnels may be set up between the PEs (in a PE-based
PPVPN) or the CEs (in a CE-based PPVPN) so that if one tunnel
fails, VPN traffic can continue to flow across the other tunnel
that has already been set-up in advance.
余分なトンネルは、1つのトンネルが失敗するなら、VPNトラフィックが、あらかじめ既にセットアップであるもう片方のトンネルの向こう側に流れ続けることができるように、PEs(PEベースのPPVPNの)かCEs(CEベースのPPVPNの)の間でセットアップされるかもしれません。
Tunnel redundancy may be provided over and above physical
diversity. For example, a single site may be connected to two CEs
(for CE-based PPVPNs) or two PEs (for PE-based PPVPNs). Tunnels
may be set up between each of the CEs (or PEs as the case may be)
across different sites.
トンネル冗長を多様性の上と物理的な多様性より上まで提供するかもしれません。 例えば、ただ一つのサイトは2CEs(CEベースのPPVPNsのための)か2PEs(PEベースのPPVPNsのための)につなげられるかもしれません。 Tunnelsは異なったサイト中のそれぞれのCEs(または、場合によってPEs)の間でセットアップされるかもしれません。
Of course, redundancy means additional resources being used, and
consequently, management of additional resources, which would
impact the overall scaling of the service.
もちろん、冗長は総合的なサービスのスケーリングに影響を与える使用される、追加リソース、およびその結果追加リソースの経営者側を意味します。
It should be noted that it is difficult to guarantee high
availability when the VPN service is across multiple providers,
unless there is a negotiation between the different service
providers to maintain the service level agreement for the VPN
customer.
VPNサービスが複数のプロバイダーのむこうにあるとき、高い有用性を保証するのが難しいことに注意されるべきです、VPN顧客のためにサービスレベル協定を維持するために異なったサービスプロバイダーの間には、交渉がない場合。
4.2. Stability
4.2. 安定性
In addition to availability, VPN services MUST also be stable. Stability is a function of several components such as VPN routing, signaling and discovery mechanisms, in addition to tunnel stability. For example, in the case of routing, route flapping or routing loops MUST be avoided in order to ensure stability. Stability of the VPN service is directly related to the stability of the mechanisms and protocols used to establish the service. It SHOULD also be possible to allow network upgrades and maintenance procedures without impacting the VPN service.
また、有用性に加えて、VPNサービスも安定しているに違いありません。 安定性はトンネルの安定性に加えたVPNルーティングや、シグナリングや発見メカニズムなどの数個の部品の関数です。 例えば、ルーティングの場合では、安定性を確実にするためにルートのばたつくかルーティング輪を避けなければなりません。 VPNサービスの安定性は直接メカニズムの安定性に関連します、そして、プロトコルは以前はよくサービスを確立していました。 それ、SHOULD、また、VPNサービスに影響を与えないでネットワークアップグレードと保守手順を許容するのにおいて可能であってください。
4.3. Traffic types
4.3. トラフィックタイプ
VPN services MUST support unicast (or point to point) traffic and SHOULD support any-to-any or point-to-multipoint traffic including multicast and broadcast traffic. In the broadcast model, the network
VPNサービスは、ユニキャスト(または、ポイント・ツー・ポイント)トラフィックとSHOULDがいずれへのサポートいずれかマルチキャストと放送トラフィックを含むポイントツーマルチポイントトラフィックであると、サポートしなければなりません。 ネットワークの放送モデルで
Nagarajan Informational [Page 8] RFC 3809 PPVPN June 2004
[8ページ]RFC3809PPVPN2004年6月の情報のNagarajan
delivers a stream to all members of a subnetwork, regardless of their interest in that stream. In the multicast model, the network delivers a stream to a set of destinations that have registered interest in the stream. All destinations need not belong to the same subnetwork. Multicast is more applicable to L3 VPNs while broadcast is more applicable to L2VPNs. It is desirable to support multicast limited in scope to an intranet or extranet. The solution SHOULD be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner.
そのストリームへの彼らの関心にかかわらずサブネットワークのすべてのメンバーにストリームを提供します。 マルチキャストモデルでは、ネットワークはストリームへの関心を示した1セットの送付先にストリームを提供します。 目的地が必要とするすべてが同じサブネットワークに属しません。 放送はL2VPNsにより適切ですが、マルチキャストはL3 VPNsにより適切です。 範囲でイントラネットかエクストラネットに制限されたマルチキャストをサポートするのは望ましいです。 ソリューションSHOULD、スケーラブルな方法でそのような多くのイントラネットかエクストラネットの特定のマルチキャストグループをサポートすることができてください。
All PPVPN approaches SHALL support both IPv4 and IPv6 traffic. Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) SHALL be supported via encapsulation in IP or MPLS tunnels in the case of L2VPNs.
SHALLがIPv4とIPv6トラフィックの両方をサポートするすべてのPPVPNアプローチ。 特定のL2トラフィックは(例えば、ATM、Frame Relay、およびイーサネット)SHALLをタイプします。IPかMPLSトンネルのカプセル化で、L2VPNsの場合でサポートされてください。
4.4. Data isolation
4.4. データ分離
The PPVPN MUST support forwarding plane isolation. The network MUST never deliver user data across VPN boundaries unless the two VPNs participate in an intranet or extranet.
PPVPN MUSTは、推進が飛行機分離であるとサポートします。 2VPNsがイントラネットかエクストラネットに参加しないなら、ネットワークはVPN境界の向こう側に利用者データを決して提供してはいけません。
Furthermore, if the provider network receives signaling or routing information from one VPN, it MUST NOT reveal that information to another VPN unless the two VPNs participate in an intranet or extranet. It should be noted that the disclosure of any signaling/routing information across an extranet MUST be filtered per the extranet agreement between the organizations participating in the extranet.
その上、プロバイダーネットワークが1VPNからシグナリングかルーティング情報を受け取って、2VPNsがイントラネットかエクストラネットに参加しないなら、それは別のVPNにその情報を明らかにしてはいけません。 エクストラネットに参加する組織の間でエクストラネット協定単位でエクストラネットの向こう側のどんなシグナリング/ルーティング情報の公開もフィルターにかけなければならないことに注意されるべきです。
4.5. Security
4.5. セキュリティ
A range of security features SHOULD be supported by the suite of PPVPN solutions in the form of securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a PPVPN. These security features SHOULD be implemented based on the framework outlined in [VPN-SEC]. Each PPVPN solution SHOULD state which security features it supports and how such features can be configured on a per customer basis. Protection against Denial of Service (DoS) attacks is a key component of security mechanisms. Examples of DoS attacks include attacks to the PE or CE CPUs, access connection congestion, TCP SYN attacks and ping attacks.
さまざまなセキュリティが、顧客に流れを保証する形でPPVPNソリューションのスイートによってサポートされて、一時的であるか、リモートであるかまたはモバイルのユーザ、およびPPVPNをサポートするのにかかわるサービスプロバイダーリソースを保護する必要性に認証サービスを提供であるので、SHOULDを特集します。 これらのセキュリティはSHOULDを特集します。[VPN-SEC]に概説されたフレームワークに基づいて、実装されてください。 それぞれのPPVPNソリューションSHOULDはどのセキュリティ機能をサポートするか、そして、顧客基礎あたりのaでどうしたらそのような特徴は構成できるかを述べます。 サービス妨害(DoS)攻撃に対する保護はセキュリティー対策の主要な部品です。DoS攻撃に関する例はPEかCE CPUと、アクセス接続混雑と、TCP SYN攻撃とピング攻撃に攻撃を含んでいます。
Some security mechanisms (such as use of IPsec on a CE-to-CE basis) may be equally useful regardless of the scope of the VPN. Other mechanisms may be more applicable in some scopes than in others. For example, in some cases of single-provider single-AS VPNs, the VPN service may be isolated from some forms of attack by isolating the
いくつかのセキュリティー対策(CEからCEへのベースにおけるIPsecの使用などの)がVPNの範囲にかかわらず等しく役に立つかもしれません。 いくつかの範囲では、他のメカニズムが他のものより適切であるかもしれません。 例えば、いくつかの場合、ただ一つのプロバイダーの独身のAS VPNsでは、VPNサービスは、いくつかの形式の攻撃から隔離することによって、隔離されるかもしれません。
Nagarajan Informational [Page 9] RFC 3809 PPVPN June 2004
[9ページ]RFC3809PPVPN2004年6月の情報のNagarajan
infrastructure used for supporting VPNs from the infrastructure used for other services. However, the requirements for security are common regardless of the scope of the VPN service.
他のサービスに使用されるインフラストラクチャからVPNsをサポートするのに使用されるインフラストラクチャ。 しかしながら、セキュリティのための要件はVPNサービスの範囲にかかわらず一般的です。
4.5.1. User data security
4.5.1. 利用者データセキュリティ
PPVPN solutions that support user data security SHOULD use standard methods (e.g., IPsec) to achieve confidentiality, integrity, authentication and replay attack prevention. Such security methods MUST be configurable between different end points, such as CE-CE, PE-PE, and CE-PE. It is also desirable to configure security on a per-route or per-VPN basis. User data security using encryption is especially desirable in the multi-provider scenario.
利用者データセキュリティがSHOULDであるとサポートするPPVPNソリューションが秘密性、保全、認証、および反射攻撃防止を達成する標準方法(例えば、IPsec)を使用します。 そのようなセキュリティメソッドはCE-CEや、PE-PEや、CE-PEなどの異なったエンドポイントの間で構成可能であるに違いありません。 また、ルートかVPNあたり1個のベースでセキュリティを構成するのも望ましいです。 暗号化を使用する利用者データセキュリティはマルチプロバイダーシナリオで特に望ましいです。
4.5.2. Access control
4.5.2. アクセス制御
A PPVPN solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers, cryptographic mechanisms or similar mechanisms to apply policy-based access control. Access control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such access control mechanisms are desirable in the multi-provider scenario.
また、PPVPNソリューションには、顧客の要求のときに適切なフィルタリング能力を活性化する能力があるかもしれません。 フィルタは、エクストラネットにかかわる異なった組織のコミュニケーションのポイントにアクセスコントロールを呼び出すことができるようにメカニズムを提供します。 ファイアウォール(方針ベースのアクセスコントロールを適用するルータ、暗号のメカニズムまたは同様のメカニズムの上のアクセスコントロールリスト)でアクセス管理を実施されることができます。 また、アクセスコントロールもCE-CEと、PE-PEとCE-PEの間で適用されるに違いありません。 そのようなアクセス管理機構はマルチプロバイダーシナリオで望ましいです。
4.5.3. Site authentication and authorization
4.5.3. サイト認証と承認
A PPVPN solution requires authentication and authorization of the following:
PPVPNソリューションは以下の認証と承認を必要とします:
- temporary and permanent access for users connecting to sites
(authentication and authorization BY the site)
- サイトに接続するユーザのための一時的で永久的なアクセス(認証、承認BYがサイトをそうする、)
- the site itself (authentication and authorization FOR the site)
- サイト自体(認証、承認FORがサイトをそうする、)
4.5.4. Inter domain security
4.5.4. ドメインセキュリティを埋葬してください。
The VPN solution MUST have appropriate security mechanisms to prevent the different kinds of Distributed Denial of Service (DDoS) attacks mentioned earlier, misconfiguration or unauthorized accesses in inter domain PPVPN connections. This is particularly important for multi- service provider deployment scenarios. However, this will also be important in single-provider multi-AS scenarios.
VPNソリューションには、間のドメインPPVPN接続における、より早く言及された分散型サービス妨害(DDoS)攻撃の異種を防ぐのが適切であるセキュリティー対策、misconfigurationまたは不正アクセスがなければなりません。 マルチサービスプロバイダー展開シナリオには、これは特に重要です。 しかしながら、また、これはただ一つのプロバイダーマルチASシナリオで重要になるでしょう。
Nagarajan Informational [Page 10] RFC 3809 PPVPN June 2004
[10ページ]RFC3809PPVPN2004年6月の情報のNagarajan
4.6. Topology
4.6. トポロジー
A VPN SHOULD support arbitrary, customer-defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. These can actually be different from the topology used by the service provider. To the extent possible, a PPVPN service SHOULD be independent of the geographic extent of the deployment.
A VPN SHOULDは、任意の、そして、顧客によって定義された相互サイトの接続性が例えば、ハブとスポークから変化することでの部分的なメッシュであると完全なメッシュトポロジーにサポートします。 これらは実際にサービスプロバイダーによって使用されたトポロジーと異なっている場合があります。 可能な範囲内で、PPVPNサービスSHOULDは展開の地理的な範囲の如何にかかわらずそうです。
Multiple VPNs per customer site SHOULD be supported without requiring additional hardware resources per VPN. This SHOULD also include a free mix of L2 and L3 VPNs.
複数の顧客サイトSHOULDあたりのVPNsに、いてください。1VPNあたりの追加ハードウェアリソースを必要としないで、サポートされます。 また、このSHOULDはL2とL3 VPNsの無料のミックスを含んでいます。
To the extent possible, the PPVPN services SHOULD be independent of access network technology.
可能な範囲内で、PPVPNサービスSHOULDはアクセスネットワーク技術の如何にかかわらずそうです。
4.7. Addressing
4.7. アドレシング
Each customer resource MUST be identified by an address that is unique within its VPN. It need not be identified by a globally unique address.
VPNの中でユニークなアドレスでそれぞれの顧客リソースを特定しなければなりません。 それはグローバルにユニークなアドレスによって特定される必要はありません。
Support for private addresses as described in [RFC1918], as well as overlapping customer addresses SHALL be supported. One or more VPNs for each customer can be built over the same infrastructure without requiring any of them to renumber. The solution MUST NOT use NAT on the customer traffic to achieve that goal. Interconnection of two networks with overlapping IP addresses is outside the scope of this document.
兵卒のサポートは説明されたコネとして[RFC1918]を扱って、顧客の住所SHALLを重ね合わせることと同様にサポートされてください。 番号を付け替えるために同じインフラストラクチャの上に彼らのいずれも必要としないで各顧客のためのVPNsを造ることができるより多くのもの。 ソリューションは、その目標を達成するのに顧客トラフィックでNATを使用してはいけません。 このドキュメントの範囲の外にIPアドレスを重ね合わせる2つのネットワークのインタコネクトがあります。
A VPN service SHALL be capable of supporting non-IP customer addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses may be desirable in some cases, but is beyond the scope of VPN solutions developed in the IETF, and therefore, this document.
VPNはSHALLを調整します。非IPが顧客の住所であるとカプセル化技術でサポートすることができてください、それがLayer2VPN(例えば、Frame Relay、ATM、イーサネット)であるなら。 非IP Layer3アドレスのサポートは、いくつかの場合望ましいかもしれませんが、IETF、およびしたがって、このドキュメントで見いだされたVPN解決策の範囲を超えています。
4.8. Quality of Service
4.8. サービスの質
A technical approach for supporting VPNs SHALL be able to support QoS via IETF standardized mechanisms such as Diffserv. Support for best-effort traffic SHALL be mandatory for all PPVPN types. The extent to which any specific VPN service will support QoS is up to the service provider. In many cases single-provider single-AS VPNs will offer QoS guarantees. Support of QoS guarantees in the multi- service-provider case will require cooperation between the various service providers involved in offering the service.
サポートVPNs SHALLのためにアプローチしてください。A技術的である、IETFを通したQoSにDiffservなどの標準化されたメカニズムをサポートできてください。 ベストエフォート型トラフィックのためにSHALLをサポートしてください。すべてのPPVPNタイプに義務的にしてください。 どんな特定のVPNサービスもQoSをサポートする範囲はサービスプロバイダーまで達しています。 多くの場合、ただ一つのプロバイダーの独身のAS VPNsは保証をQoSに提供するでしょう。 マルチサービスプロバイダー場合における、QoS保証のサポートはサービスを提供するのにかかわる様々なサービスプロバイダーの間の協力を必要とするでしょう。
Nagarajan Informational [Page 11] RFC 3809 PPVPN June 2004
[11ページ]RFC3809PPVPN2004年6月の情報のNagarajan
It should be noted that QoS mechanisms in the multi-provider scenario REQUIRES each of the participating providers to support the mechanisms being used, and as such, this is difficult to achieve.
それぞれ使用されるメカニズム、およびそういうものとしてこれをサポートする加入業者のマルチプロバイダーシナリオREQUIRESのQoSメカニズムは達成するのが難しいことに注意されるべきです。
Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing.
QoSにかかわるすべてのケースが、CE、そして/または、PEが形成、そして/または、取り締まりを実行するのを必要とするかもしれないことに注意してください。
The need to provide QoS will occur primarily in the access network, since that will often be the bottleneck. This is likely to occur since the backbone effectively statistically multiplexes many users, and is traffic engineered or includes capacity for restoration and growth. Hence in most cases PE-PE QoS is not a major issue. As far as access QoS is concerned, there are two directions of QoS management that may be considered in any PPVPN service regarding QoS:
それがしばしばボトルネックになるので、QoSを提供する必要性は主としてアクセスネットワークで起こるでしょう。 これは、バックボーンが事実上統計的に多くのユーザを多重送信するので起こりそうであって、設計されたトラフィックであるか回復と成長のための容量を含んでいます。 したがって、多くの場合、PE-PE QoSは主要な問題ではありません。 アクセスQoSに関する限り、QoSに関してどんなPPVPNサービスでも考えられるかもしれないQoS管理の2つの方向があります:
- From the CE across the access network to the PE - From the PE across the access network to CE
- PE、アクセスネットワークの向こう側のPEからCEまでのアクセスネットワークの向こう側のCEから
PPVPN CE and PE devices SHOULD be capable of supporting QoS across at least the following subset of access networks, as applicable to the specific type of PPVPN (L2 or L3). However, to the extent possible, the QoS capability of a PPVPN SHOULD be independent of the access network technology:
PPVPN CEとPEデバイスSHOULD、少なくともアクセスネットワークの以下の部分集合の向こう側にQoSをサポートすることができてください、PPVPN(L2かL3)の特定のタイプに適切であるとして。 しかしながら、可能な範囲内で、PPVPN SHOULDのQoS能力はアクセスネットワーク技術の如何にかかわらず以下の通りです。
- ATM Virtual Connections (VCs) - Frame Relay Data Link Connection Identifiers (DLCIs) - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP - QoS-enabled wireless (e.g., LMDS, MMDS) - Cable modem - QoS-enabled Digital Subscriber Line (DSL)
- ATM Virtualコネクションズ(VCs)--フレームRelay Data Link Connection Identifiers(DLCIs)--802.1d Prioritizedイーサネット--MPLSベースのアクセス--マルチリンクMulticlass PPP--QoSによって可能にされたワイヤレス(例えば、LMDS、MMDS)--ケーブルモデム--QoSによって可能にされたDigital Subscriber線(DSL)
Different service models for QoS may be supported. Examples of PPVPN QoS service models are:
QoSの異なったサービスモデルはサポートされるかもしれません。 PPVPN QoSサービスモデルに関する例は以下の通りです。
- Managed access service: Provides QoS on the access connection
between CE and the customer facing ports of the PE. No QoS
support is required in the provider core network in this case.
- 管理されたアクセス・サービス: CEとPEの顧客の面しているポートとのアクセス接続のときにQoSを提供します。 QoSサポートは全くこの場合プロバイダーコアネットワークで必要ではありません。
- Edge-to-edge QoS: Provides QoS across the provider core, either
between CE pairs or PE pairs, depending on the tunnel demarcation
points. This scenario requires QoS support in the provider core
network. As mentioned above, this is difficult to achieve in a
multi-provider VPN offering.
- 縁から縁へのQoS: トンネル画定ポイントによって、CE組かPE組の間のプロバイダーコアの向こう側にQoSを提供します。 このシナリオはプロバイダーコアネットワークでQoSサポートを必要とします。 以上のように、これはマルチプロバイダーVPN提供で達成するのが難しいです。
Nagarajan Informational [Page 12] RFC 3809 PPVPN June 2004
[12ページ]RFC3809PPVPN2004年6月の情報のNagarajan
4.9. Service Level Agreement and Service Level Specification Monitoring
and Reporting
4.9. サービスレベル協定、サービスレベル仕様モニター、および報告
A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement interval for at least the SLS using the following Service Level Objective (SLO) parameters:
Service Level Specification(SLS)はアクセスネットワーク接続単位で定義されるかもしれません、VPNサイト、VPNルートあたりのVPN単位で。 サービスプロバイダーは少なくともSLSのために以下のService Level Objective(SLO)パラメタを使用することで目的と測定間隔を定義するかもしれません:
- QoS and traffic parameters for the Intserv flow or Diffserv class
[Y.1541]
- Intserv流動かDiffservのクラスのためのQoSとトラフィックパラメタ[Y.1541]
- Availability for the site, VPN, or access connection
- サイト、VPN、またはアクセス接続への有用性
- Duration of outage intervals per site, route or VPN
- 1サイトあたりの供給停止間隔、ルートまたはVPNの持続時間
- Service activation interval (e.g., time to turn up a new site)
- サービス起動間隔(例えば、新しいサイトを捜しあてる時間)
- Trouble report response time interval
- 問題レポート応答時間間隔
- Time to repair interval
- 間隔を修理する時間
- Total traffic offered to the site, route or VPN
- サイト、ルートまたはVPNに提供された総トラフィック
- Measure of non-conforming traffic for the site, route or VPN
- サイト、ルートまたはVPNのための非の従うトラフィックの測定
- Delay and delay variation (jitter) bounds
- 遅れと遅れ変化(ジター)領域
- Packet ordering, at least when transporting L2 services sensitive
to reordering (e.g., ATM).
- 少なくともいつが再命令(例えば、ATM)に敏感なL2サービスを輸送して、注文されるパケット。
The above list contains items from [Y.1241], as well as other items typically part of SLAs for currently deployed VPN services [FRF.13]. See [RFC3198] for generic definitions of SLS, SLA, and SLO.
他の項目は良く通常離れていますが、上記のリストは現在配布しているVPNサービス[FRF.13]のためのSLAについて[Y.1241]からの項目を入れてあます。 SLS、SLA、およびSLOのジェネリック定義に関して[RFC3198]を見てください。
The provider network management system SHALL measure, and report as necessary, whether measured performance meets or fails to meet the above SLS objectives.
プロバイダーネットワーク管理システムSHALLは必要に応じて測定して、報告します、測定性能が会うか、または上のSLS目的を満たさないことにかかわらず。
In many cases the guaranteed levels for Service Level Objective (SLO) parameters may depend upon the scope of the VPN. For example, one level of guarantee might be provided for service within a single AS. A different (generally less stringent) guarantee might be provided within multiple ASs within a single service provider. At the current time, in most cases specific guarantees are not offered for multi- provider VPNs, and if guarantees were offered they might be expected to be less stringent still.
多くの場合、Service Level Objective(SLO)パラメタのための保証されたレベルはVPNの範囲に依存するかもしれません。 例えば、独身のASの中のサービスに1つのレベルの保証を提供するかもしれません。 ただ一つのサービスプロバイダーの中で複数のASsの中で異なった(一般にそれほど厳しくない)保証を提供するかもしれません。 多くの場合、現在の時間に、マルチプロバイダーVPNsのために特定の保証を申し出ません、そして、保証を提供するなら、それほどまだ厳しくないとそれらを予想するでしょうに。
Nagarajan Informational [Page 13] RFC 3809 PPVPN June 2004
[13ページ]RFC3809PPVPN2004年6月の情報のNagarajan
The service provider and the customer may negotiate a contractual arrangement that includes a Service Level Agreement (SLA) regarding compensation if the provider does not meet an SLS performance objective. Details of such compensation are outside the scope of this document.
サービスプロバイダーと顧客はプロバイダーがSLSパフォーマンス目標を満たさないなら補償に関してサービス・レベル・アグリーメント(SLA)を含んでいる契約上のアレンジメントを交渉するかもしれません。 このドキュメントの範囲の外にそのような補償の詳細があります。
4.10. Network Resource Partitioning and Sharing between VPNs
4.10. ネットワーク資源仕切りとVPNsを平等に割り当てること。
Network resources such as memory space, FIB table, bandwidth and CPU processing SHALL be shared between VPNs and, where applicable, with non-VPN Internet traffic. Mechanisms SHOULD be provided to prevent any specific VPN from taking up available network resources and causing others to fail. SLAs to this effect SHOULD be provided to the customer.
メモリスペースや、FIBテーブルや、帯域幅やCPU処理SHALLなどのネットワーク資源は、VPNsの間で共有されて、非VPNインターネットと共に適切であるところに取引します。 どんな特定のVPNも利用可能なネットワーク資源を取るのを防ぐために前提とされて、他のものが失敗されるメカニズムSHOULD。 SLAはSHOULDにこれに作用します。顧客に提供します。
Similarly, resources used for control plane mechanisms are also shared. When the service provider's control plane is used to distribute VPN specific information and provide other control mechanisms for VPNs, there SHALL be mechanisms to ensure that control plane performance is not degraded below acceptable limits when scaling the VPN service, or during network events such as failure, routing instabilities etc. Since a service provider's network would also be used to provide Internet service, in addition to VPNs, mechanisms to ensure the stable operation of Internet services and other VPNs SHALL be made in order to avoid adverse effects of resource hogging by large VPN customers.
また、同様に、制御飛行機メカニズムに使用されるリソースは共有されます。 サービスプロバイダーの制御飛行機がVPNサービスをスケーリングするか、または失敗などのネットワークイベントの間、コントロール飛行機性能が以下に下げられないのを保証するメカニズムが合格限界であったならVPN特殊情報を分配して、そこのVPNsのための他の制御機構にSHALLを供給するのに使用されるとき、ルーティング不安定性などです。 また、サービスプロバイダーのネットワークはインターネットのサービスを提供するのに使用されるでしょう、したがって、VPNs、インターネットのサービスの安定稼働を確実にするメカニズム、および他のVPNs SHALLに加えて、大きいVPN顧客によるリソースホッグの悪影響を避けるために作られてください。
5. Provider requirements
5. プロバイダー要件
This section describes operational requirements for a cost-effective, profitable VPN service offering.
このセクションは費用対効果に優れて、有益なVPNサービス提供のための操作上の要件について説明します。
5.1. Scalability
5.1. スケーラビリティ
The scalability for VPN solutions has many aspects. The list below is intended to comprise of the aspects that PPVPN solutions SHOULD address. Clearly these aspects in absolute figures are very different for different types of VPNs - i.e., a point to point service has only two sites, while a VPLS or L3VPN may have a larger number of sites. It is also important to verify that PPVPN solutions not only scales on the high end, but also on the low end - i.e., a VPN with three sites and three users should be as viable as a VPN with hundreds of sites and thousands of users.
VPNソリューションのためのスケーラビリティには、多くの局面があります。 以下のリストが局面でそのPPVPNソリューションSHOULDアドレスを包括することを意図します。 明確に、VPNsの異なったタイプにおいて、絶対値のこれらの局面は非常に異なっています--サービスには、VPLSである間、すなわち、ポイント・ツー・ポイント、2つのサイトがないか、またはL3VPNにより多くのサイトがあるかもしれません。 安値では、終わってください--また、スケールだけではなく、高値に関するPPVPNソリューションが終わることを確かめるのも重要ですが、すなわち、3つのサイトと3人のユーザがいるVPNは何百ものサイトと何千人ものユーザがいるVPNと同じくらい実行可能でもあるべきです。
Nagarajan Informational [Page 14] RFC 3809 PPVPN June 2004
[14ページ]RFC3809PPVPN2004年6月の情報のNagarajan
5.1.1. Service Provider Capacity Sizing Projections
5.1.1. 映像を大きさで分けるサービスプロバイダー容量
A PPVPN solution SHOULD be scalable to support a very large number of VPNs per Service Provider network. The estimate is that a large service provider will require support for O(10^4) VPNs within four years.
PPVPNソリューションSHOULD、多くのService Providerネットワークあたり1VPNsをサポートするのにおいて、スケーラブルであってください。 見積りは大きいサービスプロバイダーが4年以内にO(10^4)VPNsに支持を要するということです。
A PPVPN solution SHOULD be scalable to support a wide range of number of site interfaces per VPN, depending on the size and/or structure of the customer organization. The number of site interfaces SHOULD range from a few site interfaces to over 50,000 site interfaces per VPN.
PPVPNソリューションSHOULD、さまざまな数の1VPNあたりのサイトインタフェースをサポートするのにおいてスケーラブルであってください、顧客組織のサイズ、そして/または、構造によって。 サイトの数は1VPNあたりのいくつかのサイトインタフェースから5万以上のサイトインタフェースまでのSHOULD範囲を連結します。
A PPVPN solution SHOULD be scalable to support of a wide range of number of routes per VPN. The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs (O(10^5)), with typical values being in the O(10^3) range. The high end number is especially true considering the fact that many large ISPs may provide VPN services to smaller ISPs or large corporations. Typically, the number of routes per VPN is at least twice the number of site interfaces.
PPVPNソリューションSHOULD、さまざまな数の1VPNあたりのルートのサポートにスケーラブルにしてください。 1VPNあたりのルートの数はまさしくいくつかからISP(O(10^5))の間で交換されたルートの数まで及ぶかもしれません、O(10^3)範囲にある典型的な値で。 多くの大きいISPが、より小さいISPか大企業に対するサービスをVPNに供給するかもしれないという事実を考える場合、上位番号は特に正しいです。 1VPNあたりのルートの数は通常、少なくともサイトインタフェースの数の2倍です。
A PPVPN solution SHOULD support high values of the frequency of configuration setup and change, e.g., for real-time provisioning of an on-demand videoconferencing VPN or addition/deletion of sites.
SHOULDが例えば、要求次第のテレビ会議VPNの本当の時間の食糧を供給するかサイトの追加/削除のために構成セットアップと変化の頻度の高い値をサポートするPPVPNソリューション。
Approaches SHOULD articulate scaling and performance limits for more complex deployment scenarios, such as single-provider multi-AS VPNs, multi-provider VPNs and carriers' carrier. Approaches SHOULD also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management systems.
SHOULDのはっきりものが言えているスケーリングと性能がただ一つのプロバイダーマルチAS VPNsや、マルチプロバイダーVPNsやキャリアズキャリアなどの、より複雑な展開シナリオのために制限するアプローチ。 また、アプローチSHOULDは興味がある他の寸法について説明します、必要生産能力や限界のように、インスタンスがマネージメントシステムの上のどんなスケーラビリティ含意と同様にサポートした織り込むことの数。
A PPVPN solution SHOULD support a large number of customer interfaces on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with current Internet protocols.
SHOULDが多くの顧客をサポートするPPVPNソリューションは現在のインターネットプロトコルで独身のPE(PEベースのPPVPNのための)かCE(CEベースのPPVPNのための)に連結します。
5.1.2. VPN Scalability aspects
5.1.2. VPN Scalability局面
This section describes the metrics for scaling PPVPN solutions, points out some of the scaling differences between L2 and L3 VPNs. It should be noted that the scaling numbers used in this document must be treated as typical examples as seen by the authors of this document. These numbers are only representative and different service providers may have different requirements for scaling. Further discussion on service provider sizing projections is in Section 5.1.1. Please note that the terms "user" and "site" are as defined in Section 3. It should also be noted that the numbers given
このセクションは、スケーリングPPVPN解決のために測定基準について説明して、L2とL3 VPNsのスケーリング差のいくつかを指摘します。 このドキュメントの作者によって見られるように本書では使用されるスケーリング番号を典型的な例として扱わなければならないことに注意されるべきです。 これらの数は代表するだけです、そして、異なったサービスプロバイダーには、スケーリングのための異なった要件があるかもしれません。 セクション5.1.1にはサービスプロバイダーサイズ処理予測のさらなる議論があります。 用語「ユーザ」と「サイト」はセクション3で定義されるようにそうです。 また、それが注意されるべきである、それ、与えられた数
Nagarajan Informational [Page 15] RFC 3809 PPVPN June 2004
[15ページ]RFC3809PPVPN2004年6月の情報のNagarajan
below would be different depending on whether the scope of the VPN is single-provider single-AS, single-provider multi-AS, or multi- provider. Clearly, the larger the scope, the larger the numbers that may need to be supported. However, this also means more management issues. The numbers below may be treated as representative of the single-provider case.
以下に、異なったオンである依存がVPNの範囲がただ一つのプロバイダーの独身のAS、ただ一つのプロバイダーマルチAS、またはマルチプロバイダーであることにかかわらずあるでしょう。 明確に、範囲が大きければ大きいほど、サポートされる必要があるかもしれない数は、より大きいです。 しかしながら、また、これは、より多くの管理問題を意味します。 以下の数はただ一つのプロバイダーケースの代表として扱われるかもしれません。
5.1.2.1. Number of users per site
5.1.2.1. 1サイトあたりのユーザの数
The number of users per site follows the same logic as for users per VPN. Further, it must be possible to have single user sites connected to the same VPN as very large sites are connected to.
1サイトあたりのユーザの数は1VPNあたりのユーザのように同じ論理に従います。 さらに、非常に大きいサイトとしてのVPNが接続されている同じくらいにシングルユーザーサイトをつなげさせるのは可能でなければなりません。
L3 VPNs SHOULD scale from 1 user per site to O(10^4) per site. L2 VPNs SHOULD scale from 1 user to O(10^3) per site for point-to-point VPNs and to O(10^4) for point-to-multipoint VPNs.
L3 VPNs SHOULDは1サイトあたり1サイトあたり1人のユーザからO(10^4)まで比例します。 L2 VPNs SHOULDはサイト単位で1人のユーザからO(10^3)までポイントツーポイントVPNsとポイントツーマルチポイントVPNsのためのO(10^4)に比例します。
5.1.2.2. Number of sites per VPN
5.1.2.2. 1VPNあたりのサイトの数
The number of sites per VPN clearly depends on the number of users per site. VPNs SHOULD scale from 2 to O(10^3) sites per VPN. These numbers are usually limited by device memory.
1VPNあたりのサイトの数は明確に1サイトあたりのユーザの数に依存します。 VPNs SHOULDはVPN単位で2〜O(10^3)サイトまで比例します。 通常、これらの数はデバイスメモリによって制限されます。
5.1.2.3. Number of PEs and CEs
5.1.2.3. PEsとCEsの数
The number of PEs that supports the same set of VPNs, i.e., the number of PEs that needs to directly exchange information on VPN de- multiplexing information is clearly a scaling factor in a PE-based VPN. Similarly, in a CE-based VPN, the number of CEs is a scaling factor. This number is driven by the type of VPN service, and also by whether the service is within a single AS/domain or involves a multi-SP or multi-AS network. Typically, this number SHOULD be as low as possible in order to make the VPN cost effective and manageable.
VPNsの同じセットを支えるPEsの数、すなわち、VPN反-マルチプレクシング情報で直接情報交換する必要があるPEsの数は明確にPEベースのVPNのけた移動子です。 同様に、CEベースのVPNでは、CEsの数はけた移動子です。 この数は、VPNサービスについてタイプによって運転されるか、またはまた、サービスがただ一つのAS/ドメインの中にあるか、またはマルチSPの、または、マルチASのネットワークにかかわるかによってそうします。 通常、これはSHOULDに付番します。VPNを費用効率がよく処理しやすくするようにできるだけ低くいてください。
5.1.2.4. Number of sites per PE
5.1.2.4. 1PEあたりのサイトの数
The number of sites per PE needs to be discussed based on several different scenarios. On the one hand there is a limitation to the number of customer facing interfaces that the PE can support. On the other hand the access network may aggregate several sites connected on comparatively low bandwidth on to one single high bandwidth interface on the PE. The scaling point here is that the PE SHOULD be able to support a few or even a single site on the low end and O(10^4) sites on the high end. This number is also limited by device memory. Implementations of PPVPN solutions may be evaluated based on this requirement, because it directly impacts cost and manageability of a VPN.
1PEあたりのサイトの数は、いくつかの異なったシナリオに基づいて議論する必要があります。 一方では、PEがサポートすることができる顧客の面しているインタフェースの数への制限があります。 他方では、アクセスネットワークは比較的低い帯域幅でPEの上の1つの単一の高帯域インタフェースにつなげられたいくつかのサイトに集められるかもしれません。 PE SHOULDがいくつかか上位のローエンドとO(10^4)サイトのただ一つのサイトさえサポートできるというスケーリングポイントがここにあります。 また、この数はデバイスメモリによって制限されます。 PPVPNソリューションの実装はこの要件に基づいて評価されるかもしれません、直接VPNの費用と管理可能性に影響を与えるので。
Nagarajan Informational [Page 16] RFC 3809 PPVPN June 2004
[16ページ]RFC3809PPVPN2004年6月の情報のNagarajan
5.1.2.5. Number of VPNs in the network
5.1.2.5. ネットワークにおける、VPNsの数
The number of VPNs SHOULD scale linearly with the size of the access network and with the number of PEs. As mentioned in Section 5.1.1, the number of VPNs in the network SHOULD be O(10^4). This requirement also effectively places a requirement on the number of tunnels that SHOULD be supported in the network. For a PE-based VPN, the number of tunnels is of the same order as the number of VPNs. For a CE-based VPN, the number of tunnels in the core network may be fewer, because of the possibility of tunnel aggregation or multiplexing across the core.
VPNs SHOULDの数はアクセスネットワークのサイズとPEsの数で直線的に比例します。 セクション5.1.1、ネットワークSHOULDにおける、VPNsの数でO(10^4)であるように言及するので。 また、事実上、この要件はSHOULDがネットワークでサポートされるというトンネルの数に関する要件を置きます。 PEベースのVPNに関しては、トンネルの数はVPNsの数として同次のものです。 CEベースのVPNに関しては、コアネットワークにおける、トンネルの数は、より少ないかもしれません、トンネル集合か横切ってコアを多重送信する可能性のために。
5.1.2.6. Number of VPNs per customer
5.1.2.6. 1顧客あたりのVPNsの数
In some cases a service provider may support multiple VPNs for the same customer of that service provider. For example, this may occur due to differences in services offered per VPN (e.g., different QoS, security levels, or reachability) as well as due to the presence of multiple workgroups per customer. It is possible that one customer will run up to O(100) VPNs.
いくつかの場合、サービスプロバイダーはそのサービスプロバイダーの同じ顧客のために複数のVPNsをサポートするかもしれません。 例えば、これはVPN(例えば、異なったQoS、セキュリティー・レベル、または可到達性)単位で提供されたサービスの違いのためと複数の1顧客あたりのワークグループの存在のため起こるかもしれません。 1人の顧客がO(100) VPNsに達するのは、可能です。
5.1.2.7. Number of addresses and address prefixes per VPN
5.1.2.7. 1VPNあたりのアドレスとアドレス接頭語の数
Since any VPN solution SHALL support private customer addresses, the number of addresses and address prefixes are important in evaluating the scaling requirements. The number of address prefixes used in routing protocols and in forwarding tables specific to the VPN needs to scale from very few (for smaller customers) to very large numbers seen in typical Service Provider backbones. The high end is especially true considering that many Tier 1 SPs may provide VPN services to Tier 2 SPs or to large corporations. For a L2 VPN this number would be on the order of addresses supported in typical native Layer 2 backbones.
どんなVPNソリューションSHALLも個人的な顧客の住所をサポートするので、アドレスとアドレス接頭語の数はスケーリング要件を評価するのにおいて重要です。 ルーティング・プロトコルとVPNに特定の推進テーブルで使用されるアドレス接頭語の数は、ほんのわずか(より小さい顧客のための)から非常に大きい典型的なService Providerバックボーンで見られた数まで比例する必要があります。 多くのTier1SPsがTier2SPs、または、大企業に対するサービスをVPNに供給するかもしれないと考える場合、上位は特に本当です。 L2 VPNに関しては、典型的なネイティブのLayer2バックボーンでサポートされたアドレスの注文にはこの数があるでしょう。
5.1.3. Solution-Specific Metrics
5.1.3. ソリューション特有の測定基準
Each PPVPN solution SHALL document its scalability characteristics in quantitative terms. A VPN solution SHOULD quantify the amount of state that a PE and P device has to support. This SHOULD be stated in terms of the order of magnitude of the number of VPNs and site interfaces supported by the service provider. Ideally, all VPN- specific state SHOULD be contained in the PE device for a PE-based VPN. Similarly, all VPN-specific state SHOULD be contained in the CE device for a CE-based VPN. In all cases, the backbone routers (P devices) SHALL NOT maintain VPN-specific state as far as possible.
それぞれのPPVPNソリューションSHALLは量的な用語SHOULDがサポートするためにPEとPデバイスが持っている状態の量を定量化するVPNソリューションにおけるスケーラビリティの特性を記録します。 このSHOULDはVPNsの数の桁で述べられていて、サービスプロバイダーによってサポートされたインタフェースを位置させます。 理想的に、すべてのVPN詳細が、SHOULDがPEベースのVPNのためのPEデバイスに含まれていると述べます。 同様に、すべてのVPN-詳細が、SHOULDがCEベースのVPNのためのCEデバイスに含まれていると述べます。 すべての場合では、バックボーンルータ(Pデバイス)SHALL NOTはVPN特有の状態をできるだけ維持します。
Nagarajan Informational [Page 17] RFC 3809 PPVPN June 2004
[17ページ]RFC3809PPVPN2004年6月の情報のNagarajan
Another metric is that of complexity. In a PE-based solution the PE is more complex in that it has to maintain tunnel-specific information for each VPN, but the CE is simpler since it does not need to support tunnels. On the other hand, in a CE-based solution, the CE is more complex since it has to implement routing across a number of tunnels to other CEs in the VPN, but the PE is simpler since it has only one routing and forwarding instance. Thus, the complexity of the PE or CE SHOULD be noted in terms of their processing and management functions.
別のもの、メートル法であることは、複雑さのものです。 PEベースのソリューションでは、各VPNのためのトンネル特有の情報を保守しなければならないので、PEは、より複雑ですが、トンネルを支える必要はないので、CEは、より簡単です。 他方では、多くのトンネルの向こう側にVPNの他のCEsにルーティングを実装しなければならないので、CEベースのソリューションでは、CEは、より複雑ですが、それには1つのルーティングと推進インスタンスしかないので、PEは、より簡単です。 その結果、複雑さ、PEかCE SHOULDでは、彼らの処理と管理機能で、注意されてください。
5.2. Management
5.2. 管理
A service provider MUST have a means to view the topology, operational state, service order status, and other parameters associated with each customer's VPN. Furthermore, the service provider MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers.
サービスプロバイダーには、各顧客のVPNに関連しているトポロジー、操作上の状態、サービスオーダー状態、および他のパラメタを見る手段がなければなりません。 その上、サービスプロバイダーには、基本的な論理的で物理的なトポロジーを見る手段がなければなりません、操作上の状態、顧客に対するVPNサービスを提供する設備に関連している状態、および他のパラメタに食糧を供給して。
In the multi-provider scenario, it is unlikely that participating providers would provide each other a view to the network topology and other parameters mentioned above. However, each provider MUST ensure via management of their own networks that the overall VPN service offered to the customers are properly managed. In general the support of a single VPN spanning multiple service providers requires close cooperation between the service providers. One aspect of this cooperation involves agreement on what information about the VPN will be visible across providers, and what network management protocols will be used between providers.
マルチプロバイダーシナリオでは、加入業者が前記のようにネットワーク形態と他のパラメタへの意見を互いに提供するのは、ありそうもないです。 しかしながら、各プロバイダーは、サービスが顧客に提供した総合的なVPNが適切に管理されるのをそれら自身のネットワークの経営で確実にしなければなりません。 一般に、複数のサービスプロバイダーにかかる独身のVPNのサポートはサービスプロバイダーの間の厳密な協力を必要とします。 この協力の1つの局面がVPNのどんな情報がプロバイダーの向こう側に目に見えるだろうか、そして、どんなネットワーク管理プロトコルがプロバイダーの間で使用されるかに関する協定にかかわります。
VPN devices SHOULD provide standards-based management interfaces wherever feasible.
VPNデバイスSHOULDは規格ベースの管理インタフェースをどこでも、可能であるところに提供します。
5.2.1. Customer Management of a VPN
5.2.1. VPNの顧客管理
A customer SHOULD have a means to view the topology, operational state, service order status, and other parameters associated with his or her VPN.
顧客SHOULDには、その人のVPNに関連しているトポロジー、操作上の状態、サービスオーダー状態、および他のパラメタを見る手段があります。
All aspects of management information about CE devices and customer attributes of a PPVPN manageable by an SP SHOULD be capable of being configured and maintained by the customer after being authenticated and authorized.
CEデバイスに関する経営情報の全面と顧客が認証された後に、構成して、維持できて、認可されたSP SHOULDが処理しやすいPPVPNの顧客属性。
A customer SHOULD be able to make dynamic requests for changes to traffic parameters. A customer SHOULD be able to receive real-time response from the SP network in response to these requests. One
顧客SHOULD、トラフィックへの変化を求めるダイナミックな要求をパラメタにすることができてください。 顧客SHOULD、これらの要求に対応してSPネットワークからリアルタイムの応答を受けることができてください。 1つ
Nagarajan Informational [Page 18] RFC 3809 PPVPN June 2004
[18ページ]RFC3809PPVPN2004年6月の情報のNagarajan
example of such as service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their VPN(s). A possible outcome of giving customers such capabilities is Denial of Service attacks on other VPN customers or Internet users. This possibility is documented in the Security Considerations section.
サービスとしてのそのようなものに関する例が「ダイナミックなBandwidth管理」能力である、それはそれらのVPN(s)に割り当てられた割り当てられた帯域幅の変化のための顧客の要求へのリアルタイムの応答を可能にします。 そのような能力を顧客に与える可能な結果は他のVPN顧客かインターネットユーザにおけるサービス妨害攻撃です。 この可能性はSecurity Considerations部で記録されます。
6. Engineering requirements
6. 工学要件
These requirements are driven by implementation characteristics that make service and provider requirements achievable.
これらの要件はサービスとプロバイダー要件を達成可能にする実装の特性によって動かされます。
6.1. Forwarding plane requirements
6.1. 推進飛行機要件
VPN solutions SHOULD NOT pre-suppose or preclude the use of IETF developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or IPsec. The separation of VPN solution and tunnels will facilitate adaptability with extensions to current tunneling techniques or development of new tunneling techniques. It should be noted that the choice of the tunneling techniques may impact the service and scaling capabilities of the VPN solution.
VPNソリューションSHOULD NOTはIPにおけるIPなどのテクニック、L2TPにトンネルを堀りながら開発されたIETF、GRE、MPLSまたはIPsecの使用をあらかじめ思うか、または排除します。 VPNソリューションとトンネルの分離は拡大で新しいトンネリングのテクニックの現在のトンネリングのテクニックか開発に適応性を促進するでしょう。 トンネリングのテクニックの選択がVPNソリューションのサービスとスケーリング能力に影響を与えるかもしれないことに注意されるべきです。
It should also be noted that specific tunneling techniques may not be feasible depending on the deployment scenario. In particular, there is currently very little use of MPLS in the inter-provider scenario. Thus, native MPLS support may be needed between the service providers, or it would be necessary to run MPLS over IP or GRE. It should be noted that if MPLS is run over IP or GRE, some of the other capabilities of MPLS, such as Traffic Engineering, would be impacted. Also note that a service provider MAY optionally choose to use a different encapsulation for multi-AS VPNs than is used for single AS VPNs. Similarly, a group of service providers may choose to use a different encapsulation for multi-service provider VPNs than for VPNs within a single service provider.
また、展開シナリオによって、特定のトンネリングのテクニックが可能でないかもしれないことに注意されるべきです。 現在、特に、相互プロバイダーシナリオにおけるMPLSの非常に少ない使用があります。 したがって、ネイティブのMPLSサポートがサービスプロバイダーの間で必要であるかもしれません、またはIPかGREの上にMPLSを実行するのが必要でしょう。 MPLSがIPかGREの上に実行されるなら、Traffic EngineeringなどのMPLSの他の能力のいくつかが影響を与えられることに注意されるべきです。 また、サービスプロバイダーが、独身のAS VPNsに使用されるよりマルチAS VPNsに異なったカプセル化を使用するのを任意に選ぶかもしれないことに注意してください。 同様に、サービスプロバイダーのグループは、ただ一つのサービスプロバイダーの中のVPNsよりマルチサービスプロバイダーVPNsに異なったカプセル化を使用するのを選ぶかもしれません。
For Layer 2 VPNs, solutions SHOULD utilize the encapsulation techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3) Working Group, and SHOULD NOT impose any new requirements on these techniques.
Layer2VPNsのために、ソリューションSHOULDはPseudo-ワイヤ斜めに進むEmulation Edge(PWE3)作業部会によって定義されたカプセル化技術を利用します、そして、SHOULD NOTはどんな新しい要件もこれらのテクニックに課します。
PPVPN solutions MUST NOT impose any restrictions on the backbone traffic engineering and management techniques. Conversely, backbone engineering and management techniques MUST NOT affect the basic operation of a PPVPN, apart from influencing the SLA/SLS guarantees associated with the service. The SP SHOULD, however, be REQUIRED to provide per-VPN management, tunnel maintenance and other maintenance required in order to meet the SLA/SLS.
PPVPNソリューションはバックボーン交通工学と管理技術に少しの制限も課してはいけません。 逆に、バックボーン工学と管理技術はPPVPNの基本的な操作に影響してはいけません、サービスに関連しているSLA/SLS保証に影響を及ぼすことは別として。 SP SHOULD、しかしながら、1VPNあたりの管理を提供するREQUIREDになってください、とトンネルメインテナンスと他のメインテナンスはSLA/SLSに会うために必要としました。
Nagarajan Informational [Page 19] RFC 3809 PPVPN June 2004
[19ページ]RFC3809PPVPN2004年6月の情報のNagarajan
By definition, VPN traffic SHOULD be segregated from each other, and from non-VPN traffic in the network. After all, VPNs are a means of dividing a physical network into several logical (virtual) networks. VPN traffic separation SHOULD be done in a scalable fashion. However, safeguards SHOULD be made available against misbehaving VPNs to not affect the network and other VPNs.
定義上、隔離されていて、VPNは互いと、ネットワークにおける非VPNトラフィックからSHOULDを取引します。 結局、VPNsは物理ネットワークをいくつかの論理的な(仮想の)ネットワークに分割する手段です。 VPNはされたコネがスケーラブルなファッションであったなら分離SHOULDを取引します。 しかしながら、ネットワークともう片方に影響しない人工の利用可能なふらちな事ををしているVPNsがVPNsであったならSHOULDを保護しています。
A VPN solution SHOULD NOT impose any hard limit on the number of VPNs provided in the network.
VPNソリューションSHOULD NOTはネットワークに提供されたVPNsの数にどんな困難な限界も課します。
6.2. Control plane requirements
6.2. コントロール飛行機要件
The plug and play feature of a VPN solution with minimum configuration requirements is an important consideration. The VPN solutions SHOULD have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services or impact general Internet traffic handling in any way.
最小の構成必要条件があるVPNソリューションのプラグアンドプレイ機能は重要な考慮すべき事柄です。 VPNソリューションSHOULDが顧客インタフェース、そして/または、ルーティングの不安定性に保護のためのメカニズムを抱くので、それらは、他の顧客のサービスに影響を与えもしませんし、何らかの方法で一般的なインターネットトラフィック取り扱いに影響を与えもしません。
A VPN SHOULD be provisioned with minimum number of steps. For instance, a VPN need not be configured in every PE. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which SHOULD be as common as possible to all VPN solutions, SHOULD be defined. However, these mechanisms SHOULD NOT adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack.
VPN SHOULD、最小の数のステップで、食糧を供給されてください。 例えば、VPNはあらゆるPEで構成されなければならないというわけではありません。 SHOULD、これが達成されるために、自動構成と自動発見は議定書を作って、どのSHOULDができるだけすべてのVPNソリューションに共通であるか。定義されます。 しかしながら、ひどく複雑であるか、またはプロトコル・スタックで層を増強することによって、これらのメカニズムSHOULD NOTはサービスの費用、スケーラビリティまたは安定性に悪影響を与えます。
Mechanisms to protect the SP network from effects of misconfiguration of VPNs SHOULD be provided. This is especially of importance in the multi-provider case, where misconfiguration could possibly impact more than one network.
メカニズム、VPNs SHOULDのmisconfigurationの効果からSPネットワークを保護するには、提供してください。 これはマルチプロバイダー場合で特に重要です。そこでは、misconfigurationが1つ以上のネットワークに影響を与えることができました。
6.3. Control Plane Containment
6.3. 制御飛行機封じ込め
The PPVPN control plane MUST include a mechanism through which the service provider can filter PPVPN related control plane information as it passes between Autonomous Systems. For example, if a service provider supports a PPVPN offering, but the service provider's neighbors do not participate in that offering, the service provider SHOULD NOT leak PPVPN control information into neighboring networks. Neighboring networks MUST be equipped with mechanisms that filter this information should the service provider leak it. This is important in the case of multi-provider VPNs as well as single- provider multi-AS VPNs.
PPVPN制御飛行機はAutonomous Systemsの間を通るときサービスプロバイダーがPPVPNの関連するコントロール飛行機情報をフィルターにかけることができるメカニズムを含めなければなりません。例えば、サービスプロバイダーがPPVPN提供を支えますが、サービスプロバイダーの隣人がその提供に参加しないなら、サービスプロバイダーSHOULD NOTはPPVPN制御情報を隣接しているネットワークに漏らします。 隣接しているネットワークはサービスプロバイダーがそれを漏らすならこの情報をフィルターにかけるメカニズムを備えなければなりません。 これはただ一つのプロバイダーマルチAS VPNsと同様にマルチプロバイダーVPNsの場合で重要です。
Nagarajan Informational [Page 20] RFC 3809 PPVPN June 2004
[20ページ]RFC3809PPVPN2004年6月の情報のNagarajan
6.4. Requirements related to commonality of PPVPN mechanisms with each
other and with generic Internet mechanisms
6.4. 互いとジェネリックインターネットメカニズムがあるPPVPNメカニズムの共通点に関連する要件
As far as possible, the mechanisms used to establish a VPN service SHOULD re-use well-known IETF protocols, limiting the need to define new protocols from scratch. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based VPN service, SHALL NOT affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms SHOULD NOT conflict with the architectural principles of the Internet, nor SHOULD it put at risk the existing Internet systems. For example, IETF-developed routing protocols SHOULD be used for routing of L3 PPVPN traffic, without adding VPN-specific state to the Internet core routers. Similarly, well-known L2 technologies SHOULD be used in VPNs offering L2 services, without imposing risks to the Internet routers. A solution MUST be implementable without requiring additional functionality to the P devices in a network, and minimal functionality to the PE in a PE-based VPN and CE in a CE-based VPN.
できるだけ、VPNサービスSHOULDを証明するのに使用されるメカニズムはよく知られるIETFプロトコルを再使用します、最初から新しいプロトコルを定義する必要性を制限して。 しかしながら、インターネットメカニズムのインターネットを利用するVPNサービスの設立と稼働の使用であり、SHALL NOTがインターネットかインターネットのサービスの安定性、丈夫さ、およびスケーラビリティに影響することに注意されるべきです。 言い換えれば、これらのメカニズムSHOULD NOTは. 例えば危険な状態に既存のインターネット・システムのIETFによって開発されたルーティング・プロトコルSHOULDを置いたというインターネット、およびSHOULDの建築本質と衝突します。L3 PPVPNトラフィックのルーティングに使用されてください、インターネットコアルータにVPN特有の状態を加えないで。 同様である、よく知られるL2技術SHOULD、インターネットルータに危険を課さないでサービスをL2に提供するVPNsで使用されてください。 ネットワークにおけるPデバイスに追加機能性を必要として、PEベースのVPNのPEとCEベースのVPNのCEに最小量の機能性は必要としないで、ソリューションが実装可能であるに違いありません。
In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different PPVPN solutions (both L2 and L3), e.g., discovery, signaling, routing and management, SHOULD be as common as possible.
例えば、ジェネリックインターネットメカニズムと異なったPPVPNソリューション(L2とL3の両方)に使用されるインフラストラクチャメカニズムと発見とシグナリングとルーティングと管理、SHOULDがある共通点に加えて、できるだけ一般的であってください。
6.5. Interoperability
6.5. 相互運用性
Each technical solution is expected to be based on interoperable Internet standards.
各技術的解決法によって共同利用できるインターネット標準に基礎づけられると予想されます。
Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution SHOULD be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers.
ネットワーク要素、ネットワーク、およびサービスにおけるマルチベンダ相互運用性は同じ技術的解決法の異なった実装の中でSHOULDを平らにします。確実にされてください(それはおそらく対応する規格の完全性を当てにするでしょう)。 これはSPsと顧客のための中央の要件です。
The technical solution MUST be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service.
技術的解決法は共同利用できるSPネットワークインフラは作るだけではなく、顧客のネットワーク装置とサービスもPPVPNサービスの用法を作っていてマルチベンダであるに違いありません。
Customer access connections to a PPVPN solution may be different at different sites (e.g., Frame Relay on one site and Ethernet on another).
PPVPNソリューションとの顧客アクセス接続は異なったサイト(例えば、1つのサイトのFrame Relayと別のもののイーサネット)で異なっているかもしれません。
Interconnection of a L2VPN over an L3VPN as if it were a customer site SHALL be supported. However, interworking of Layer 2 technologies is not required, and is outside the scope of the working group, and therefore, of this document.
L3VPNの上のL2VPNのインタコネクトはまるでそれが顧客であるかのようにSHALLを位置させます。サポートされます。 しかしながら、Layer2技術を織り込むことは、必要でなく、ワーキンググループ、およびしたがって、このドキュメントの範囲の外にあります。
Nagarajan Informational [Page 21] RFC 3809 PPVPN June 2004
[21ページ]RFC3809PPVPN2004年6月の情報のNagarajan
Inter-domain interoperability - It SHOULD be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet.
相互ドメイン相互運用性--、それ、SHOULD、ドメイン、Autonomous Systems、またはインターネットの向こう側にPPVPNソリューションを配布するのにおいて、可能であってください。
7. Security Considerations
7. セキュリティ問題
Security requirements for Provider Provisioned VPNs have been described in Section 4.5. In addition, the following considerations need to be kept in mind when a provider provisioned VPN service is provided across a public network infrastructure that is also used to provide Internet connectivity. In general, the security framework described in [VPN-SEC] SHOULD be used as far as it is applicable to the given type of PPVPN service.
Provider Provisioned VPNsのためのセキュリティ要件はセクション4.5で説明されます。 さらに、また、インターネットの接続性を提供するのに使用される公衆通信回線インフラストラクチャの向こう側に以下のプロバイダーがVPNサービスに食糧を供給したとき覚えておかれるべき問題の必要性を提供します。 一般に、セキュリティフレームワークは[VPN-SEC]でSHOULDについて説明しました。それが与えられたタイプのPPVPNサービスに適切である限り、使用されてください。
The PE device has a lot of functionality required for the successful operation of the VPN service. The PE device is frequently also part of the backbone providing Internet services, and is therefore susceptible to security and denial of service attacks. The PE control plane CPU is vulnerable from this point of view, and it may impact not only VPN services but also general Internet services if not adequately protected. In addition to VPN configuration, if mechanisms such as QoS are provisioned on the PE, it is possible for attackers to recognize the highest priority traffic or customers and launch directed attacks. Care SHOULD be taken to prevent such attacks whenever any value added services such as QoS are offered.
PEデバイスで、うまくいっているVPNサービスの操作のために多くの機能性を必要とします。 PEデバイスは、また、頻繁のインターネットのサービスを提供するバックボーンの一部であり、したがって、セキュリティとサービス不能攻撃に影響されやすいです。 PE制御飛行機CPUはこの観点から考えると被害を受け易いです、そして、適切に保護されないなら、それはVPNサービスだけではなく、一般的なインターネットのサービスにも影響を与えるかもしれません。 VPN構成に加えて、QoSなどのメカニズムがPEで食糧を供給されるなら、攻撃者が、最優先トラフィックか顧客と着手が攻撃を指示したと認めるのは、可能です。 SHOULDについて気にかけてください。取って、QoSなどのどんな付加価値サービスも提供するときはいつも、そのような攻撃を防いでください。
When a service such as "Dynamic Bandwidth Management" as described in Section 5.2.1 is provided, it allows customers to dynamically request for changes to their bandwidth allocation. The provider MUST take care to authenticate such requests and detect and prevent possible Denial-of-Service attacks. These DoS attacks are possible when a customer maliciously or accidentally may cause a change in bandwidth allocation that may impact the bandwidth allocated to other VPN customers or Internet users.
セクション5.2.1で説明される「ダイナミックな帯域幅管理」などのサービスを提供するとき、それは彼らの帯域幅配分への変化のためにダイナミックに要求する顧客を許容します。 プロバイダーは、可能なサービス不能攻撃をそのような要求を認証して、検出して、防ぐために注意されなければなりません。 顧客が陰湿か偶然他のVPN顧客かインターネットユーザに割り当てられた帯域幅に影響を与えるかもしれない帯域幅配分における変化を引き起こすとき、これらのDoS攻撃は可能です。
Different choices of VPN technology have different assurance levels of the privacy of a customer's network. For example, CE-based solutions may enjoy more privacy than PE-based VPNs by virtue of tunnels extending from CE to CE, even if the tunnels are not encrypted. In a PE-based VPN, a PE has many more sites than those attached to a CE in a CE-based VPN. A large number of these sites may use [RFC1918] addresses. Provisioning mistakes and PE software bugs may make traffic more prone to being misdirected as opposed to a CE-based VPN. Care MUST be taken to prevent misconfiguration in all kinds of PPVPNs, but more care MUST be taken in the case of PE-based VPNs, as this could impact other customers and Internet services. Similarly, there SHOULD be mechanisms to prevent the flooding of
VPN技術の異なった選択には、顧客のネットワークのプライバシーの異なった保証レベルがあります。 例えば、CEベースのソリューションはトンネルによるCEによって広がりながら、PEベースのVPNsより多くのプライバシーを楽しむかもしれません、トンネルが暗号化されていなくても。 PEベースのVPNでは、PEはCEベースのVPNのCEに付けられたものよりずっと多くのサイトを持っています。 これらの多くのサイトが[RFC1918]アドレスを使用するかもしれません。 誤りとPEソフトウェアのバグに食糧を供給するのに、トラフィックはCEベースのVPNと対照的に的外れにより傾向があるようになるかもしれません。 すべての種類のPPVPNsでmisconfigurationを防ぐために注意しなければなりませんが、PEベースのVPNsの場合で、より多くの注意を払わなければなりません、これが他の顧客とインターネットのサービスに影響を与えることができたとき。 同様と、そこ、SHOULD、氾濫を防ぐメカニズムになってください。
Nagarajan Informational [Page 22] RFC 3809 PPVPN June 2004
[22ページ]RFC3809PPVPN2004年6月の情報のNagarajan
Internet routing tables whenever there is a misconfiguration or failure of PPVPN control mechanisms that use Internet routing protocols for relay of VPN-specific information.
PPVPNのmisconfigurationか失敗があるときはいつも、インターネット経路指定テーブルはVPN-特殊情報のリレーにインターネットルーティング・プロトコルを使用するメカニズムを制御します。
Different deployment scenarios also dictate the level of security that may be needed for a VPN. For example, it is easier to control security in a single provider, single AS VPN and therefore, expensive encryption techniques may not be used in this case, as long as VPN traffic is isolated from the Internet. There is a reasonable amount of control possible in the single provider, multi AS case, although care SHOULD be taken to ensure the constrained distribution of VPN route information across the ASes. Security is more of a challenge in the multi-provider case, where it may be necessary to adopt encryption techniques in order to provide the highest level of security.
また、異なった展開シナリオはVPNに必要であるかもしれないセキュリティのレベルを決めます。 例えば、AS VPNを選抜して、ただ一つのプロバイダーにおけるセキュリティを制御するのが、より簡単であり、したがって、高価な暗号化のテクニックはこの場合使用される必要はありません、VPNトラフィックがインターネットから隔離される限り。 ただ一つのプロバイダーで可能なコントロールの十分な量があります、マルチASケース、注意SHOULDですが。ASesの向こう側にVPN経由地案内の強制的な分配を確実にするために、取ります。 セキュリティはマルチプロバイダー場合における挑戦の以上です、暗号化のテクニックを採用するのがセキュリティの最高水準を提供するのに必要であるかもしれないところで。
8. References
8. 参照
8.1. Normative References
8.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月。
8.2. Informative References
8.2. 有益な参照
[TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider
Provisioned Virtual Private Networks", Work in
Progress.
[用語] アンデション、L.、マドセン、T.、「プロバイダーの食糧を供給された仮想私設網のための用語」が進行中で働いています。
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for Layer 3
Provider Provisioned Virtual Private Networks", Work in
Progress, March 2003.
[L3FRAMEWORK] Callon、R.、鈴木、M.、他 「層3のプロバイダーのためのフレームワークは仮想私設網に食糧を供給した」処理中の作業、2003年3月。
[L2FRAMEWORK] Andersson, L., et al. "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Work in Progress, March
2004.
[L2FRAMEWORK] アンデション、L.、他 「層2の仮想私設網(L2VPNs)のためのフレームワーク」、処理中の作業、2004年3月。
[L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private
Networks", Work in Progress, April 2003.
[L3REQTS]Carugi、M.、McDysan、D.他、「層3のプロバイダーのためのサービス要件は仮想私設網に食糧を供給しました」、ProgressのWork、2003年4月。
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service
Requirements for Layer 2 Provider Provisioned Virtual
Private Networks", Work in Progress, April 2003.
[L2REQTS]Augustyn、W.、Serbest、Y.、他、「層2のプロバイダーのためのサービス要件は仮想私設網に食糧を供給しました」、ProgressのWork、2003年4月。
Nagarajan Informational [Page 23] RFC 3809 PPVPN June 2004
[23ページ]RFC3809PPVPN2004年6月の情報のNagarajan
[Y.1241] "IP Transfer Capability for the support of IP based
Services", Y.1241 ITU-T Draft Recommendation, March
2000.
[Y.1241] 「IPのサポートのためのIP Transfer CapabilityはServicesを基礎づけた」Y.1241 ITU-T Draft Recommendation、2000年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
Carlson, M., Perry, J. and S. Waldbusser, "Terminology
for Policy-Based Management", RFC 3198, November 2001.
[RFC3198]WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.、クインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。
[VPN-SEC] Fang, L., et al., "Security Framework for Provider
Provisioned Virtual Private Networks", Work in
Progress, February 2004.
[VPN-SEC] 牙、L.、他、「プロバイダーの食糧を供給された仮想私設網のためのセキュリティフレームワーク」、Progress、2004年2月のWork。
[FRF.13] Frame Relay Forum, "Service Level Definitions
Implementation Agreement", August 1998.
[FRF.13] フレームリレーフォーラム、「サービスレベル定義実装協定」、1998年8月。
[Y.1541] "Network Performance Objectives for IP-based Services",
Y.1541, ITU-T Recommendation.
[Y.1541] 「IPベースのサービスのためのネットワークパフォーマンス目標」、Y.1541、ITU-T推薦。
9. Acknowledgements
9. 承認
This work was done in consultation with the entire design team for PPVPN requirements. A lot of the text was adapted from the Layer 3 requirements document produced by the Layer 3 requirements design team. The authors would also like to acknowledge the constructive feedback from Scott Bradner, Alex Zinin, Steve Bellovin, Thomas Narten and other IESG members, and the detailed comments from Ross Callon.
PPVPN要件のために全体のデザインチームとの相談でこの仕事をしました。 多くのテキストが要件デザインが組にするLayer3によって製作されたLayer3要件ドキュメントから翻案されました。 作者は、スコット・ブラドナー、アレックス・ジニン、スティーブBellovin、トーマスNarten、および他のIESGメンバーから建設的なフィードバックを承認して、また、ロスCallonから詳細なコメントを承認したがっています。
10. Editor's Address
10. エディタのアドレス
Ananth Nagarajan Juniper Networks
Ananth Nagarajan杜松ネットワーク
EMail: ananth@juniper.net
メール: ananth@juniper.net
Nagarajan Informational [Page 24] RFC 3809 PPVPN June 2004
[24ページ]RFC3809PPVPN2004年6月の情報のNagarajan
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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機能のための基金は現在、インターネット協会によって提供されます。
Nagarajan Informational [Page 25]
Nagarajan情報です。[25ページ]
一覧
スポンサーリンク
