Network Working Group A. Nagarajan, Ed.
Request for Comments: 3809 Juniper Networks
Category: Informational June 2004
Generic Requirements for Provider Provisioned
Virtual Private Networks (PPVPN)
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 Internet Society (2004).
著作権（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.
この文書では、プロバイダーのプロビジョニングされた仮想プライベートネットワーク（PPVPN）のための一般的な要件について説明します。要件は、サービス要件、プロバイダーの要件と技術要件に分類されています。これらの要件は、PPVPN技術のいずれかの特定のタイプに固有ではなく、むしろすべてのPPVPN技術に適用されます。すべてのPPVPN技術は、この文書に記載されている要件の傘セットを満たすことが期待されています。
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
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].
この文書では、仮想プライベートネットワーク（PPVPN）プロビジョニングされたプロバイダでPPVPNsワーキンググループの要件を開発するために形成されたデザインチームの出力であり、両方のレイヤ2個の仮想プライベートネットワーク（L2VPN）、レイヤ3つの仮想プライベートネットワーク汎用的な要件を（提供しますL3VPN）。この文書では、サービスプロバイダおよびエンジニアリング要件として分類ジェネリックPPVPN要件について説明します。これらは、PPVPN技術の任意の特定のタイプとは無関係です。言い換えれば、すべてのPPVPN技術は、この文書に記載されている要件の傘セットを満たすことが期待されています。 PPVPNsは、単一または複数のプロバイダのネットワークおよび/または自律システム（のAS）を横切って構築されてもよいです。ほとんどの場合、このドキュメントで説明する一般的な要件は、展開シナリオとは無関係です。しかしながら、PPVPNは、単一または複数のプロバイダ（および/またはのAS）に配備されているか否かに基づいて異なる特定の要件は、文書で指摘されるであろう。 3 PPVPNsの層に関連する特定の要件は、[L3REQTS]に記載されています。同様に、2 PPVPNsを層に特定されている要件は、[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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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）として建設されました。時間が経つにつれて別のサイト上でのネットワークを相互接続するための可能性がますます重要になってきています。企業ネットワークの接続は、主に、フレームリレー（FR）または非同期転送モード（ATM）接続、そして最近でイーサネットおよびIPベースのトンネルなどのように、サービスプロバイダによって提供されています。共有ネットワークインフラストラクチャ上でサイトの数を相互接続するネットワークのこのタイプは、仮想プライベートネットワーク（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つ以上の共有ネットワーク上のデータや通信接続を提供するサービスプロバイダーを探しています。
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.
異なる顧客に属するトラフィック間のアイソレーションを提供するために、そのようなレイヤ2つの接続またはレイヤ2/3トンネルなどの機構が必要です。共有インフラストラクチャは、IPネットワークである場合、典型的に使用されるトンネリング技術は、IPsec、MPLS、L2TP、GRE、IPインIP等であります
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をもとにしています。サービスプロバイダは、今、このようなセキュリティに加えて、その他のサービスの差別化、トラフィック管理、レイヤ2およびレイヤ3接続、などの機能を提供強化された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ソリューションは現在展開されているVPNの伝統的なタイプだけでなく、高度なサービスに対応できなければなりません。彼らはだけでなく、サービスプロバイダーのセットの間とインターネットを介して、単一のサービスプロバイダのネットワークで実行できるようにする必要があります。そうすることでVPNは、インターネットルーティングテーブルの成長を基本的なインターネットの設計原理に違反したり、インターネットのコアルータに過負荷をかけたり加速させてはなりません。具体的には、インターネット・コア・ルータは関係なく、インターネット・ルーティング・プロトコルは、この情報を配布したりしないために使用されているかどうかの、VPNに関連する情報を維持することを要しありません。これを達成するために、様々なPPVPNソリューションを開発するために使用されるメカニズムは、発見のような、一般的なインターネット基盤機構、シグナリング、ルーティング、および管理を可能な限り一般的でなければなりません。同時に、既存のインターネットインフラの仕組みは、オーバーロードされないものとします。
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サービスの種類ごとに完全に異なる溶液のアプローチを必要とすることが望ましくないことがあります。
There are three different deployment scenarios that need to be considered for PPVPN services:
PPVPNサービスのために考慮する必要がある三つの異なる展開シナリオがあります。
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.シングル・プロバイダ、シングルAS：これはPPVPNサービスは、単一の自律システムにまたがる単一のサービスプロバイダのネットワークを介して提供されている最も複雑なシナリオです。
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 that has been created by mergers and acquisitions of multiple networks). This scenario involves the constrained distribution of routing information across multiple Autonomous Systems.
2.単一のプロバイダ、マルチAS：このシナリオでは、単一のプロバイダは、複数の自律システムを有していてもよい（例えば、異なるのASは、グローバル位置、又は合併によって作成されたISPに応じてグローバルのTier-1 ISPそして複数のネットワークの買収）。このシナリオでは、複数の自律システム間でルーティング情報の制約分布を含みます。
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の顧客のためのセキュリティとサービスレベル契約を満たすために、複数のサービスプロバイダのバックボーン全体になされる必要が前記このシナリオは、最も複雑です。このシナリオには、複数のサービスプロバイダーネットワークの構成インターネットをカバーするために一般化することができます。顧客が複数のプロバイダ間で、独自のVPNを構築できることに留意すべきです。しかし、このようなVPNは、彼らは、「プロバイダ・プロビジョニング」ではないでしょうとしてここでは考慮されていません。
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.
第四のシナリオは、「キャリアのキャリア」VPNも考慮することができます。このシナリオでは、サービスプロバイダ（例えば、ティア1サービスプロバイダ）に順番に顧客へのVPNにVPNサービスを提供する別のサービスプロバイダ（例えば、ティア2サービスプロバイダ）にVPNサービスを提供します。上記の例では、ティア2プロバイダの顧客は、ティア2プロバイダのネットワーク内に含まれ、そして第2層のプロバイダ自体は、ティア1プロバイダのネットワークの顧客です。単一のプロバイダの要件のすべてが、この場合にも同様に適用されることになるので、このように、このシナリオでは、文書内に別々に処理されていません。
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つの展開シナリオとは無関係であることが期待されます。しかし、実際に展開シナリオに依存している特定の要件は、この文書で指摘されます。
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.
この文書では、プロバイダーのプロビジョニングされた仮想プライベートネットワーク（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技術の分類法を提示しています。分類は、レイヤ2およびレイヤ3つのVPNを表す2つの広いクラスが含まれています。各トップレベルのVPNクラスは、下位クラスが含まれています。例えば、レイヤ3 VPNクラスは、PEベースのレイヤ3つのVPNの下位クラスを含みます。
Sections 4, 5, 6 describe generic PPVPN requirements.
セクション4、5、6は、一般的なPPVPN要件について説明します。
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）プロバイダーの要件 - 特性は、サービスプロバイダは、PPVPNサービスの費用対効果を判断するために使用すること。スケーリングと管理は、プロバイダの要件の例です。
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メカニズムの共通性に関する要件。
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のための一般的な要件にサービスプロバイダビューを提示したサービスプロバイダのフォーカスグループの一部であった数人の組み合わせの努力でした。要件の重要なセットは、直接、レイヤ3 PPVPN [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 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)
Yetik Serbest (yetik_serbest@labs.sbc.com) Luyuan Fang (luyuanfang@att.com) Javier Achirica (achirica@telefonica.net)
アダルト無料（yetik_serbest@labs.sbc.co I）ハビエルAchiranaによってLuyuan牙（luyuanfang@att.coのI）（achirica@telefonica.net）
The terminology used in this document is defined in [TERMINOLOGY]. In addition the following terminology is used:
本書で使用される用語は[用語]で定義されています。さらに、以下の用語が使用されます。
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
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ベースのレイヤ2つのVPNはまた、ポイントツーポイント（P2P）またはポイントツーマルチポイント（P2MP）として分類することができます。また、ソリューションの数が限られているためにワーキンググループの意図であり、この文書で指定された要件を満たすソリューションを提案する際、この目標は、念頭に置いておく必要があります。 CEベースおよびPEベースPPVPNsの定義は、[L3FRAMEWORK]から得ることができます。レイヤ2つの特定の定義は、[L2FRAMEWORK]から得ることができます。
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.
これらは、顧客がサービスプロバイダ（SP）が提供PPVPNサービスが十分であるかどうかを確認するためには、観察または測定することができます要件です。前に述べたように、特に断らない限り、これらの要件のそれぞれ3つの展開シナリオの各全体に均等に適用されます。
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サービスは、高可用性を持たなければなりません。いくつかのサイトに分散されているVPNは、でも、ネットワーク障害や劣化したサービスのイベントで維持されるように接続が必要です。
This can be achieved via various redundancy techniques such as:
これは、のような様々な冗長性技術を介して達成することができます。
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.
複数（CEベースPPVPNs用）のCEまたは（PEベースPPVPNs用）のPE、または別のPOP、あるいは異なるサービスプロバイダに接続された単一のサイト。
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トラフィックは既に設定されている他のトンネルを横切って流れ続けることができるように、冗長なトンネルは（PEベースのPPVPN IN）のPEまたは（CEベースのPPVPNで）のCEとの間に設定することができます事前に-UP。
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.
トンネルの冗長性は、物理的な多様性を越えて上方に設けられてもよいです。例えば、単一部位が（CEベースPPVPNs用）は、2つのCEまたは（PEベースPPVPNs用）は、2つのPEに接続されてもよいです。 （場合に応じて、またはPES）トンネルは、異なるサイト間のCEのそれぞれとの間に設定されてもよいです。
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サービスは、複数のプロバイダ間であるとき、高可用性を保証することは困難であることに留意すべきです。
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サービスの安定性は、サービスを確立するために使用されるメカニズムとプロトコルの安定性に直接関係します。また、VPNサービスに影響を与えることなく、ネットワークのアップグレードおよび保守手順を許可することが可能であるべきです。
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 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.
VPNサービスは、（ポイントするようにまたはポイント）トラフィックをユニキャストをサポートしなければならないし、多対多マルチキャストおよびブロードキャストトラフィックを含むか、ポイントツーマルチポイントトラフィックをサポートする必要があります。放送モデルでは、ネットワークにかかわらず、そのストリームへの関心の、サブネットワークのすべてのメンバーにストリームを配信します。マルチキャストモデルでは、ネットワークは、ストリームへの関心を登録した目的地のセットにストリームを配信します。すべての宛先は、同じサブネットワークに属している必要はありません。放送はのL2VPNにより適用可能であるが、マルチキャストは、L3 VPNにより適用されます。イントラネットやエクストラネットに範囲が限定され、マルチキャストをサポートすることが望ましいです。溶液は、スケーラブルな方法でそのようなイントラネットやエクストラネット、特定のマルチキャストグループの多くをサポートすることができるべきです。
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.
すべてのPPVPNアプローチは、IPv4およびIPv6トラフィックの両方をサポートします。特定L2のトラフィックタイプ（例えば、ATM、フレームリレーとイーサネット）のL2VPNの場合にはIPまたはMPLSトンネルでカプセル化を介してサポートされます。
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は、転送プレーンの分離をサポートしなければなりません。 2つのVPNは、イントラネットやエクストラネットに参加しない限り、ネットワークは、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.
プロバイダネットワークシグナリングまたは1 VPNからルーティング情報を受信した場合、2つのVPN、イントラネットまたはエクストラネットに参加していない限りさらに、別のVPNへの情報を明らかにしてはなりません。エクストラネットを横切る任意のシグナリング/ルーティング情報の開示は、エクストラネットに参加している組織間エクストラネット契約ごとにフィルタリングされなければならないことに留意すべきです。
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の支援に関わるサービスプロバイダのリソースを保護する必要性によってサポートされる必要があります。これらのセキュリティ機能は、[VPN-SEC]に概説フレームワークに基づいて実施されるべきです。各PPVPNソリューションは、それがサポートするセキュリティ機能を必ず明記してください、どのような機能は、顧客ごとに設定することができます。サービス拒否（DoS）攻撃に対する保護は、セキュリティ・メカニズムの重要な要素です。 DoS攻撃の例は、PEまたはCEのCPUへの攻撃、アクセス接続の輻輳、TCP SYN攻撃とping攻撃を含みます。
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 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.
（例えばCE-に-CEベースでのIPsecの使用など）、いくつかのセキュリティメカニズムに関係なく、VPNの範囲の同等に有用であり得ます。他のメカニズムは他に比べていくつかのスコープで、より適用することができます。例えば、単一のプロバイダ単-AS VPNのいくつかのケースでは、VPNサービスは他のサービスのために使用されるインフラストラクチャからVPNをサポートするために使用されるインフラストラクチャを単離することによって、攻撃のいくつかの形態から単離することができます。しかし、セキュリティの要件に関係なく、VPNサービスの適用範囲の共通しています。
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.
ユーザデータのセキュリティをサポートするPPVPNソリューションは、機密性、完全性、認証およびリプレイ攻撃防止を達成するために、標準的な方法（例えば、IPsec）を使用すべきです。そのようなセキュリティ方式は、CE-CE、PE-PE、およびCE-PEのような異なるエンドポイント間の設定でなければなりません。ルートごと、またはVPNベースでセキュリティを設定することが望ましいです。暗号化を使用してユーザーデータのセキュリティは、マルチプロバイダのシナリオで特に望ましいです。
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の間で適用可能でなければなりません。そのようなアクセス制御メカニズムは、マルチプロバイダーシナリオにおいて望ましいです。
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)
- サイト自体（サイトの認証および承認）
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）攻撃の異なる種類を防ぐために、適切なセキュリティメカニズムを持たなければなりません。これは、マルチサービスプロバイダーの展開シナリオのために特に重要です。しかし、これはまた、単一のプロバイダのマルチASシナリオで重要になります。
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.
VPNは、ハブアンドスポーク、パーシャルメッシュからフルメッシュトポロジに、例えば、至るまで、任意の、顧客が定義サイト間の接続をサポートする必要があります。これらは、実際にサービスプロバイダが使用するトポロジーと異なる場合があります。可能な範囲で、PPVPNサービスは、展開の地理的範囲と無関係であるべきです。
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.
顧客サイトごとに複数のVPNはVPNごとに、追加のハードウェアリソースを必要とせずにサポートされる必要があります。これはまた、L2とL3 VPNの自由なミックスを含むべきです。
To the extent possible, the PPVPN services SHOULD be independent of access network technology.
可能な範囲で、PPVPNサービスは、アクセスネットワーク技術と無関係であるべきです。
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]で説明したように、だけでなく、顧客のアドレスの重複はサポートされなければなりません。顧客ごとに一つまたは複数のVPNが付け直すためにそれらのいずれかを必要とせずに、同じインフラストラクチャ上に構築することができます。解決策は、その目標を達成するために顧客のトラフィックに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.
それは、レイヤ2 VPNである場合、VPNサービスは、カプセル化技術を介して非IP顧客のアドレスをサポートすることができるものでなければならない（例えば、フレームリレー、ATM、イーサネット（登録商標））。非IPレイヤのサポートは3つのアドレスは、いくつかのケースでは望ましいことではなく、IETFで開発されたVPNソリューションの範囲を超えて、そのため、このドキュメントがあります。
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.
VPNをサポートするための技術的アプローチは、DiffservのようなIETF標準化された機構を介してQoSをサポートできなければなりません。ベストエフォート型トラフィックのサポートは、すべてのPPVPNタイプのために必須とされなければなりません。任意の特定のVPNサービスへの広がりは、QoSをサポートするサービスプロバイダ次第です。多くの場合、単一のプロバイダのシングルAS VPNは、QoS保証を提供します。マルチサービス・プロバイダーの場合、QoS保証のサポートサービスを提供に関与する様々なサービスプロバイダ間の協力が必要になります。
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.
マルチプロバイダーシナリオにおける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管理の二つの方向があります。
- From the CE across the access network to the PE - From the PE across the access network to CE
- PEへのアクセスネットワークを介してCEから - アクセスネットワークを介してPEから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デバイスがPPVPN（L2又はL3）の特定のタイプに適用できるように、アクセスネットワークの少なくとも以下のサブセットを横切ってQoSをサポートすることができなければなりません。しかし、可能な範囲で、PPVPNの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仮想接続（VCは） - フレームリレーデータリンク接続識別子（DLCI） - 802.1Dは、イーサネットの優先順位付け - MPLSベースのアクセス - マルチマルチクラスPPP - QoS対応無線（例えば、LMDS、MMDS） - ケーブルモデム - QoS対応しますデジタル加入者線（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の提供に達成することは困難です。
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:
サービスレベル仕様（SLS）VPNごとに、VPNサイトごとに、および/またはVPNルートごとに、アクセスネットワーク接続ごとに定義することができます。サービスプロバイダは、目的と次サービスレベル目標（SLO）パラメータを使用して、少なくともSLSのための測定間隔を定義することができます。
- QoS and traffic parameters for the Intserv flow or Diffserv class [Y.1541]
- イントサーブフローまたはDiffServクラスの[Y. 1541]のためのQoSおよびトラフィックパラメータ
- Availability for the site, VPN, or access connection
- サイト、VPN、またはアクセス接続の入手可能性
- Duration of outage intervals per site, route or VPN
- サイト、ルートまたは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.
上記のリストは、[FRF.13] [Y.1241]からアイテム、ならびに他のアイテム現在配備VPNサービスのためのSLAの典型的部分を含んでいます。 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.
プロバイダのネットワーク管理システムは、測定し、測定された性能を満たしているか、上記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.
多くの場合、サービスレベル目標のための保証レベル（SLO）のパラメータは、VPNの範囲に依存してもよいです。例えば、保証のいずれかのレベルは、単一のAS内のサービスのために提供される可能性があります。異なる（一般的により厳しくない）保証は、単一のサービスプロバイダ内の複数のAS内に提供されてもよいです。現時点では、ほとんどの場合、特定の保証は、マルチプロバイダVPNのために提供されていない、と保証が提供された場合、彼らはまだあまり厳しくなることが予想される場合があります。
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）を備えて契約上の取決めを交渉することができます。そのような補償の詳細は、このドキュメントの範囲外です。
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の処理として、ネットワークリソースが非VPNインターネットトラフィックとVPNおよび、該当する、との間で共有されるものとします。メカニズムは、利用可能なネットワークリソースを占有し、他の人が失敗する原因から特定のVPNを防ぐために提供されるべきです。この効果へのSLAは、顧客に提供されるべきです。
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の他の制御機構を提供するために使用される場合、VPNサービスをスケーリングするときに、制御プレーンの性能が許容限界を下回る劣化しないことを保証するためのメカニズムが存在しなければならない、またはそのような障害などのネットワークイベント中サービスプロバイダのネットワークは、インターネットサービスを提供するために使用されるので、ルーティングの不安定性など、VPNに加えて、インターネットサービスやその他のVPNの安定動作を確保するためのメカニズムは、大きなことで、リソースホギングの悪影響を避けるために行わなければなりませんVPNの顧客。
This section describes operational requirements for a cost-effective, profitable VPN service offering.
このセクションでは、費用対効果の高い、収益性の高いVPNサービスの提供のための運用要件について説明します。
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ソリューションが対処すべきな側面で構成することを意図しています。明確絶対図面におけるこれらの態様は、VPNの異なるタイプの非常に異なっている - VPLS又はL3VPNは、サイトの大きい数を有することができる、すなわち、サービスポイントツーポイントは、ただ2つの部位を有します。すなわち、3つのサイトと3人のユーザーを持つVPNは、ユーザーのサイトと数十万人とVPNのように生きなければなりません - PPVPNソリューションはハイエンドにスケールだけでなく、ローエンドの上にいることを確認することも重要です。
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ソリューションは、サービスプロバイダーのネットワークごとのVPNの非常に大きな数をサポートするスケーラブルであるべきです。見積もりは、大規模なサービスプロバイダは4年以内にO（10 ^ 4）VPNのサポートを必要とするということです。
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ソリューションは、顧客組織のサイズおよび/または構造に応じて、VPN当たりサイトインターフェイスの数の広い範囲をサポートするスケーラブルであるべきです。サイトインターフェースの数は、いくつかのサイトインターフェイスからVPN当たり50,000以上のサイトインターフェイスに範囲であるべきです。
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ソリューションは、VPNあたりのルートの数の広い範囲のサポートにスケーラブルであるべきです。経路の数は、ISPの（O（10 ^ 5））との間で交換するVPNあたりのルートの数は、典型的な値はO（10 ^ 3）の範囲にあると、わずか数の範囲であってもよいです。ハイエンドの数は多くの大規模なISPが小さいISPや大企業へのVPNサービスを提供することができるという事実を考慮すると特にそうです。典型的には、VPNあたりのルートの数の少なくとも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.
PPVPNソリューションは、オンデマンドビデオ会議VPNまたはサイトの追加/削除のリアルタイムプロビジョニングに、例えば、構成設定、変更の頻度の高い値をサポートしなければなりません。
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.
アプローチは、単一プロバイダーマルチAS間VPN、マルチプロバイダVPNおよびキャリアのキャリアのようなより複雑な展開シナリオのためのスケーリング及び性能限界を明確にすべきです。アプローチはまた、容量要件または制限、管理システム上の任意のスケーラビリティへの影響だけでなく、サポートされているインターワーキング・インスタンスの数として関心のある他の寸法を記述するべきです。
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.
PPVPNソリューションは、現在のインターネットプロトコルと単一PE（PEベースのPPVPNのための）または（CEベースのPPVPNのための）CE上の顧客インターフェースの多数をサポートしなければなりません。
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 VPN間のスケーリングの差のいくつかを指摘します。この文書の著者によって見られるように、このドキュメントで使用されているスケーリング番号は典型的な例として扱われなければならないことに留意すべきです。これらの数字は、スケーリングのためのさまざまな要件を有することができる唯一の代表と異なるサービスプロバイダです。サービスプロバイダーのサイジング予測にさらなる議論は、セクション5.1.1です。用語「利用者」と「サイト」は3章で定義されるようにまた番号が与えられたことに留意すべきであることに注意してください
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、またはマルチプロバイダであるかどうかに応じて異なるであろう。明らかに、範囲が大きいほど、サポートする必要があるかもしれない数字大きいです。しかし、これはまた、より多くの経営課題を意味しています。下の数字は、単一のプロバイダケースの代表として扱うことができます。
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.
サイトあたりのユーザー数は、VPNあたりのユーザーの場合と同じロジックに従います。さらに、非常に大規模なサイトが接続されているのと同じ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 VPNは、サイトごとにO（10 ^ 4）のサイトあたり1人のユーザから拡張すべきです。 L2 VPNは1人のユーザからポイントツーポイントVPNのサイトあたりO（10 ^ 3）およびポイントツーマルチポイントVPNのO（10 ^ 4）に拡大すべきです。
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.
VPNあたりのサイトの数は明らかに、サイトあたりのユーザー数に依存します。 VPNはO（10 ^ 3）VPN当たりの部位に2から拡張すべきです。これらの数字は、通常、デバイスのメモリによって制限されています。
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.
VPNの同じセットをサポートするPEの数、すなわち、直接VPNの逆多重化情報に関する情報を交換する必要があるPEの数は明らかにPEベースのVPNにおけるスケーリングファクタです。同様に、CEベースのVPNに、CEの数はスケーリングファクタです。この数は、また、サービスは、単一のAS /ドメイン内であるか、またはマルチSPまたはマルチなどのネットワークを含むか否かによって、VPNサービスの種類によって駆動されます。典型的には、この数はVPNコストが効果的かつ管理可能にするためにできるだけ低くなければなりません。
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.
PE当たりの部位の数は、いくつかの異なるシナリオに基づいて議論する必要があります。一方PEをサポートすることができ、顧客に面するインターフェイスの数に制限があります。一方、アクセスネットワークは、PE上の単一の高帯域幅インターフェース上に比較的低い帯域幅で接続された複数のサイトを集約してもよいです。ここでスケーリング点は、PEがローエンドとO（10 ^ 4）ハイエンド上の部位に少数または単一のサイトをサポートすることができなければならないということです。この番号は、デバイスのメモリによって制限されます。それに直接影響がコストやVPNの管理ためPPVPNソリューションの実装は、この要件に基づいて評価することができます。
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.
VPNの数は、アクセスネットワークのサイズとPEの数と直線的にすべきです。セクション5.1.1で述べたように、ネットワーク内のVPNの数はO（^ 4〜10）であるべきです。この要件はまた、効果的にネットワークでサポートされるべきであるトンネルの数の要件を課します。 PEベースのVPNは、トンネルの数は、VPNの数と同じオーダーです。 CEベースのVPNのために、コアネットワークにおけるトンネルの数があるため、コアを横切るトンネル凝集または多重化の可能性、少なくてもよいです。
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.
いくつかのケースでは、サービスプロバイダは、サービスプロバイダの同じ顧客のために複数のVPNをサポートすることができます。例えば、これは、VPNごとに提供されるサービスの差異（例えば、異なるQoS、セキュリティレベル、または到達可能性）に、ならびににより顧客ごとに複数のワークグループが存在するために起こり得ます。 1人の顧客は、O（100）のVPNまで実行される可能性があります。
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ソリューションは、プライベート顧客のアドレスをサポートするので、アドレスとアドレスプレフィックスの数は、スケーリングの要件を評価する上で重要です。ルーティングプロトコルおよびVPNに固有のテーブルを転送に使用されるアドレスプレフィクスの数は、典型的なサービス・プロバイダ・バックボーンに見られる非常に大きな数字に（小さい顧客のために）非常に少ないから拡張する必要があります。ハイエンドでは、多くのティア1のSPがTier 2のSPや大企業へのVPNサービスを提供することができることを考えると特にそうです。 L2 VPNの場合、この数は、典型的なネイティブレイヤ2バックボーンでサポートされているアドレスの順序になります。
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ソリューションは、定量的にそのスケーラビリティ特性を文書化しなければなりません。 VPNソリューションは、PEとPデバイスがサポートしなければならないことを状態量を定量化するべきです。これは、サービスプロバイダによってサポートされたVPNとサイトインターフェイスの数の大きさの順の用語で記述されるべきである（SHOULD）。理想的には、すべてのVPN固有の状態は、PEベースのVPN用のPEデバイスに含まれるべきです。同様に、すべてのVPN固有の状態は、CEベースのVPN用のCEデバイスに含まれるべきです。すべての場合において、バックボーンルータ（P・デバイス）は、可能な限りVPN固有の状態を維持しないものとします。
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ベースのソリューションでPEは、それが各VPN用のトンネル固有の情報を維持しなければならないことで、より複雑であるが、CEは、トンネルをサポートする必要がないので簡単です。それはVPN内の他のCEへのトンネルの数を横切ってルーティングを実装する必要があり、それは唯一のルーティングおよび転送インスタンスを有するのでPEが簡単であるので、一方、CEベースのソリューションでは、CEは、より複雑です。従って、PEまたはCEの複雑さは、それらの処理および管理機能の点で注目すべきです。
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サービス（S）を提供する装置に関連する他のパラメータを表示する手段を持たなければなりません。
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のサポートは、サービスプロバイダとの間の緊密な協力が必要です。この協力関係の一の態様は、VPNについて何の情報についての合意を必要とするプロバイダ間で見えるようになり、どのようなネットワーク管理プロトコルがプロバイダーの間で使用されます。
VPN devices SHOULD provide standards-based management interfaces wherever feasible.
どこ可能な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.
顧客は、トポロジ、動作状態、サービスの注文状況、および彼または彼女の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.
SPで管理PPVPNのCE機器や顧客の属性に関する管理情報のすべての側面には、認証および承認された後、顧客によって構成され、維持されることが可能であるべきです。
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 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.
顧客は、トラフィックパラメータへの変更のための動的な要求をすることができるべきです。お客様は、これらの要求に応じて、SPネットワークからのリアルタイムの応答を受信することができます。このようなサービスとしての一例は、そのVPN（複数可）に割り当てられた割り当てられた帯域幅の変化に対する顧客の要求にリアルタイム応答を可能にし、「動的な帯域幅管理」機能、です。顧客は、このような能力を与えることの可能な結果は、他のVPN顧客やインターネットユーザーにサービス拒否攻撃です。この可能性は、セキュリティの考慮事項のセクションに記載されています。
These requirements are driven by implementation characteristics that make service and provider requirements achievable.
これらの要件は、サービスプロバイダとの要件が達成可能にする実装の特性によって駆動されます。
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ソリューションは考え-PREまたはIETFは、そのような中-IP IP-、L2TP、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、そのようなトラフィック・エンジニアリングなどMPLSの他の機能のいくつかの上で実行された場合、影響を受けることになることに留意すべきです。また、サービスプロバイダは、必要に応じてVPNなどの単一のために使用されているよりも、マルチASのVPNに別のカプセル化を使用するように選択することがあります。同様に、サービスプロバイダのグループは、単一のサービスプロバイダ内のVPNよりもマルチサービスプロバイダVPNの異なるカプセル化を使用することを選択することができます。
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.
レイヤ2つのVPNの場合は、ソリューションは、疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ（PWE3）ワーキンググループによって定義されたカプセル化技術を利用すべきで、これらの技術上の任意の新たな要件を課すべきではありません。
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ソリューションはバックボーントラフィックエンジニアリングと管理技術上の任意の制限を課してはなりません。逆に、バックボーン・エンジニアリングと管理技術は離れてサービスに関連するSLA / SLSの保証に影響を与えるから、PPVPNの基本的な操作に影響してはいけません。 SPは、しかしながら、当たり-VPN管理、トンネルの保守およびSLA / SLSを満たすために必要とされる他のメンテナンスを提供するために必要とされるべきです。
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トラフィックから。結局、VPNは、複数の論理（仮想）ネットワークに物理ネットワークを分割する手段です。 VPNトラフィックの分離は、スケーラブルな方法で行われるべきです。しかし、セーフガードは、ネットワークや他のVPNには影響を与えないためにVPNを不正な動作に対して利用できるようにすべきです。
A VPN solution SHOULD NOT impose any hard limit on the number of VPNs provided in the network.
VPNソリューションは、ネットワークで提供VPNの数に任意のハード制限を課すべきではありません。
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ソリューションは、顧客インタフェースおよび/またはルーティング不安定性に対する保護のためのメカニズムを持っているべきです。
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は、ステップの最小数でプロビジョニングされるべきです。例えば、VPNは、すべてのPEで構成する必要はありません。これを達成するために、すべてのVPNソリューションにできるだけ一般的であるべきである自動設定と自動検出プロトコルは、定義されるべきです。しかし、これらのメカニズムは悪影響過度に複雑であることによって、またはプロトコル・スタック内の層を増やすことにより、サービスのコスト、拡張性や安定性に影響を及ぼすべきではありません。
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.
VPNの設定ミスの影響からSPネットワークを保護するためのメカニズムが提供されるべきです。これは、特に、設定ミスがおそらく複数のネットワークに影響を与える可能性があり、マルチプロバイダの場合、に重要です。
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制御プレーンは、自律システム間を通過するように、サービスプロバイダはPPVPN関連する制御プレーンの情報をフィルタリングできるような機構を含まなければなりません。サービスプロバイダーがPPVPN提供をサポートしていますが、サービスプロバイダーの隣人は、その募集に参加しない場合、例えば、サービスプロバイダは、隣接するネットワークにPPVPN制御情報を漏洩しない（SHOULD NOT）。隣接するネットワークは、この情報は、サービスプロバイダがそれを漏らすべきフィルタ機構を備えていなければなりません。これは、マルチプロバイダVPNの場合と同様に、単一のプロバイダのマルチASのVPN上で重要です。
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.
可能な限り、メカニズムは、ゼロから新しいプロトコルを定義する必要性を制限し、よく知られたIETFプロトコルを再使用すべきでVPNサービスを確立するために使用されます。しかし、インターネットベースのVPNサービスの確立と実行のためのインターネットの仕組みの使用は、インターネットまたはインターネットサービスの安定性、堅牢性、およびスケーラビリティに影響を及ぼしてはならないことに留意すべきです。言い換えれば、これらのメカニズムは、インターネットのアーキテクチャの原則と矛盾しない（SHOULD NOT）、またそれは危険で、既存のインターネットシステムを配置する必要があります。例えば、IETF-開発ルーティングプロトコルは、インターネット・コア・ルータにVPN固有の状態を追加することなく、L3 PPVPNトラフィックのルーティングに使用されるべきです。同様に、よく知られているL2技術は、インターネットルータにリスクを与えることなく、L2サービスを提供するVPNを使用する必要があります。溶液は、ネットワーク内のPデバイスに追加の機能を必要とせずに実施可能であり、及びCEベースのVPNにおけるPEベースのVPNおよびCEにおけるPEに最小限の機能しなければなりません。
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の両方）に使用される一般的なインターネット機構、インフラ機構、例えば、発見、シグナリング、ルーティング、および管理を共通に加えて、できるだけ一般的であるべきです。
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.
保証されるべきである同じ技術的解決策の異なる実装の間でのネットワーク要素、ネットワーク及びサービスレベルでマルチベンダの相互運用性（すなわち、対応する標準の完全性に依存している可能性が高いであろう）。これは、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.
技術的な解決策は、PPVPNサービスの利用を作るSPのネットワークインフラストラクチャ内で、だけでなく、顧客のネットワーク機器やサービスだけではなく、マルチベンダーの相互運用可能でなければなりません。
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つのサイトとイーサネット上のフレームリレー）。
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の相互接続、それが顧客のサイトであるかのようにサポートされなければなりません。ただし、レイヤ2つのテクノロジーのインターワーキングは、このドキュメントのために必要な、とワーキンググループの範囲外である、とされていません。
Inter-domain interoperability - It SHOULD be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet.
ドメイン間の相互運用性 - それは、ドメイン間PPVPNソリューション、自律システム、またはインターネットを展開することが可能なはずです。
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.
プロバイダープロビジョニングVPNのセキュリティ要件は、セクション4.5に記載されています。また、次の考慮事項は、プロバイダがVPNサービスは、インターネット接続を提供するために使用されるパブリック・ネットワーク・インフラストラクチャ全体に提供され、プロビジョニングするときに留意する必要があります。一般的に、[VPN-SEC]に記載のセキュリティフレームワークは、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サービスだけでなく、一般的なインターネットサービスだけではないに影響を与える可能性があります。 QoSなどのメカニズムは、PE上でプロビジョニングされている場合、攻撃者が最も優先順位の高いトラフィックや顧客を認識し、監督の攻撃を起動するためにVPNの構成に加えて、それが可能です。ケアは、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からCEに延びるトンネルのおかげで、PEベースのVPNよりもプライバシーを楽しむことができます。 PEベースのVPNにおいて、PEはCEベースのVPN内のCEに付されたものよりも多くの部位を有します。これらのサイトの多くは、[RFC1918]のアドレスを使用することができます。ミスやPEのソフトウェアのバグをプロビジョニングCEベースのVPNとは対照的に、誤って誘導されることにトラフィックをより受けやすいことがあります。ケアはPPVPNsのすべての種類の設定ミスを防ぐために取らなければならないが、これは他の顧客とのインターネットサービスに影響を与える可能性があるとして、より多くのケアは、PEベースのVPNの場合には注意する必要があります。同様のフラッディングを防止するための機構がなければなりません
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.
インターネットルーティングテーブルVPN固有の情報の中継のためのインターネット・ルーティング・プロトコルを使用PPVPN制御機構の設定ミスや障害があるときはいつでも。
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のために必要とされるセキュリティのレベルを決定します。例えば、VPNのような単一の単一のプロバイダのセキュリティを、制御が容易であるため、高価な暗号化技術は、限り、VPNトラフィックは、インターネットから隔離されているように、この場合に使用することはできません。ケアのASを横断VPN経路情報の制約分布を確実にするために注意しなければならないが可能な制御の合理的な量は、ケースなどのマルチ、単一のプロバイダです。セキュリティは、最高レベルのセキュリティを提供するために、暗号化技術を採用する必要があるかもしれないマルチプロバイダの場合、中の課題の詳細です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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個の仮想プライベートネットワーク（のL2VPN）」、進歩、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プロバイダプロビジョニングされた仮想プライベートネットワークのサービス要件"、進歩、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]アウグスティン、W.、Serbest、Y.ら、 "レイヤ2プロバイダーのプロビジョニングされた仮想プライベートネットワークのサービスの要件"、進歩、2003年4月の作業。
[Y.1241] "IP Transfer Capability for the support of IP based Services", Y.1241 ITU-T Draft Recommendation, March 2000.
[Y.1241]、Y.1241 ITU-Tの勧告草案、2000年3月 "IPベースのサービスをサポートするためのIP転送能力は、"。
[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.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、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.、フイン、A.、カールソン、M.、ペリー、J.、およびS. Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress, February 2004.
[VPN-SEC]牙、L.、ら、「プロバイダプロビジョニングされた仮想プライベートネットワークのセキュリティフレームワーク」が進歩、2004年2月に作業。
[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勧告。
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要件については、全体のデザインチームと協議して行われました。テキストの多くは、レイヤ3つの要件のデザインチームによって作らレイヤ3要件文書から適応されました。著者らはまた、スコット・ブラッドナー、アレックスジニン、スティーブBellovin氏、トーマスNarten氏や他のIESGメンバー、およびロスCallonから詳細なコメントからの建設的なフィードバックを確認したいと思います。
Ananth Nagarajan Juniper Networks
Ananthクリシュナンジュニパーネットワークス
EMail: ananth@juniper.net
メールアドレス：ananth@juniper.net
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。