[要約] 要約：RFC 4031は、レイヤー3のプロバイダ提供仮想プライベートネットワーク（PPVPN）のサービス要件に関する情報を提供しています。 目的：このRFCの目的は、PPVPNの実装と運用に関するガイドラインを提供し、ネットワークプロバイダが顧客に高品質の仮想プライベートネットワークサービスを提供できるようにすることです。
Network Working Group M. Carugi, Ed.
Request for Comments: 4031 Nortel Networks
Category: Informational D. McDysan, Ed.
MCI
April 2005
Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
レイヤー3プロバイダープロビジョニングされた仮想プライベートネットワーク（PPVPNS）のサービス要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.
このドキュメントは、レイヤー3仮想プライベートネットワーク（L3VPNS）の要件を提供します。サービスプロバイダーが仮想プライベートネットワーク（VPN）サービスのプロビジョニングに使用できる多くの個別のアプローチに適用される要件を特定します。このドキュメントでは、IPベースのサービスサービスでの過去の経験と、そのようなサービスの顧客の継続的なニーズに基づいて、サービスプロバイダーの視点を表現しています。この目的に向けて、最初に用語を定義し、一般的な要件を述べます。詳細な要件は、顧客の観点から、およびサービスプロバイダーの要件から表されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document. . . . . . . . . . . . . . . . . 4
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Contributing Authors. . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Virtual Private Network . . . . . . . . . . . . . . . . 6
3.2. Users, Sites, Customers, and Agents . . . . . . . . . . 6
3.3. Intranets, Extranets, and VPNs. . . . . . . . . . . . . 6
3.4. Networks of Customer and Provider Devices . . . . . . . 7
3.5. Access Networks, Tunnels, and Hierarchical Tunnels. . . 7
3.6. Use of Tunnels and Roles of CE and PE in L3VPNs . . . . 8
3.6.1. PE-Based L3VPNs and Virtual Forwarding
Instances . . . . . . . . . . . . . . . . . . . 8
3.6.2. CE-Based L3VPN Tunnel Endpoints and Functions . 10
3.7. Customer and Provider Network Management. . . . . . . . 10
4. Service Requirements Common to Customers and Service
Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Isolated Exchange of Data and Routing Information . . . 11
4.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Quality of Service. . . . . . . . . . . . . . . . . . . 12
4.3.1. QoS Standards . . . . . . . . . . . . . . . . . 12
4.3.2. Service Models. . . . . . . . . . . . . . . . . 13
4.4. Service Level Specification and Agreements. . . . . . . 14
4.5. Management. . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Interworking. . . . . . . . . . . . . . . . . . . . . . 15
5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 15
5.1. VPN Membership (Intranet/Extranet). . . . . . . . . . . 15
5.2. Service Provider Independence . . . . . . . . . . . . . 16
5.3. Addressing. . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Routing Protocol Support. . . . . . . . . . . . . . . . 16
5.5. Quality of Service and Traffic Parameters . . . . . . . 16
5.5.1. Application Level QoS Objectives. . . . . . . . 17
5.5.2. DSCP Transparency . . . . . . . . . . . . . . . 17
5.6. Service Level Specification/Agreement . . . . . . . . . 18
5.7. Customer Management of a VPN. . . . . . . . . . . . . . 18
5.8. Isolation . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. Migration Impact. . . . . . . . . . . . . . . . . . . . 19
5.11. Network Access. . . . . . . . . . . . . . . . . . . . . 19
5.11.1. Physical/Link Layer Technology. . . . . . . . . 20
5.11.2. Temporary Access. . . . . . . . . . . . . . . . 20
5.11.3. Sharing of the Access Network . . . . . . . . . 20
5.11.4. Access Connectivity . . . . . . . . . . . . . . 20
5.12. Service Access. . . . . . . . . . . . . . . . . . . . . 23
5.12.1. Internet Access . . . . . . . . . . . . . . . . 23
5.12.2. Hosting, Application Service Provider . . . . . 24
5.12.3. Other Services. . . . . . . . . . . . . . . . . 24
5.13. Hybrid VPN Service Scenarios. . . . . . . . . . . . . . 24
6. Service Provider Network Requirements . . . . . . . . . . . . 24
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Discovering VPN Related Information . . . . . . . . . . 26
6.5. SLA and SLS Support . . . . . . . . . . . . . . . . . . 26
6.6. Quality of Service (QoS) and Traffic Engineering. . . . 27
6.7. Routing . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Isolation of Traffic and Routing. . . . . . . . . . . . 28
6.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 28
6.9.1. Support for Securing Customer Flows . . . . . . 28
6.9.2. Authentication Services . . . . . . . . . . . . 29
6.9.3. Resource Protection . . . . . . . . . . . . . . 30
6.10. Inter-AS (SP)VPNs . . . . . . . . . . . . . . . . . . . 30
6.10.1. Routing Protocols . . . . . . . . . . . . . . . 31
6.10.2. Management. . . . . . . . . . . . . . . . . . . 31
6.10.3. Bandwidth and QoS Brokering . . . . . . . . . . 31
6.10.4. Security Considerations . . . . . . . . . . . . 32
6.11. L3VPN Wholesale . . . . . . . . . . . . . . . . . . . . 32
6.12. Tunneling Requirements. . . . . . . . . . . . . . . . . 33
6.13. Support for Access and Backbone Technologies. . . . . . 33
6.13.1. Dedicated Access Networks . . . . . . . . . . . 34
6.13.2. On-Demand Access Networks . . . . . . . . . . . 34
6.13.3. Backbone Networks . . . . . . . . . . . . . . . 35
6.14. Protection, Restoration . . . . . . . . . . . . . . . . 35
6.15. Interoperability. . . . . . . . . . . . . . . . . . . . 35
6.16. Migration Support . . . . . . . . . . . . . . . . . . . 36
7. Service Provider Management Requirements. . . . . . . . . . . 36
7.1. Fault Management. . . . . . . . . . . . . . . . . . . . 37
7.2. Configuration Management. . . . . . . . . . . . . . . . 37
7.2.1. Configuration Management for PE-Based VPNs. . . 38
7.2.2. Configuration Management for CE-Based VPNs. . . 39
7.2.3. Provisioning Routing. . . . . . . . . . . . . . 39
7.2.4. Provisioning Network Access . . . . . . . . . . 39
7.2.5. Provisioning Security Services. . . . . . . . . 40
7.2.6. Provisioning VPN Resource Parameters. . . . . . 40
7.2.7. Provisioning Value-Added Service Access . . . . 40
7.2.8. Provisioning Hybrid VPN Services. . . . . . . . 41
7.3. Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Performance Management. . . . . . . . . . . . . . . . . 42
7.4.1. Performance Monitoring. . . . . . . . . . . . . 42
7.4.2. SLA and QoS Management Features . . . . . . . . 42
7.5. Security Management . . . . . . . . . . . . . . . . . . 43
7.5.1. Resource Access Control . . . . . . . . . . . . 43
7.5.2. Authentication. . . . . . . . . . . . . . . . . 43
7.6. Network Management Techniques . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References. . . . . . . . . . . . . . . . . . 45
10.2. Informative References. . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50
This section describes the scope and outline of the document.
このセクションでは、ドキュメントの範囲と概要について説明します。
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 RFC 2119 ([RFC2119]).
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119（[RFC2119]）に記載されているように解釈される。
This document provides requirements specific to Layer 3 Virtual Private Networks (L3VPN). (Requirements that are generic to L2 and L3 VPNs are contained in [RFC3809].)
このドキュメントは、レイヤー3仮想プライベートネットワーク（L3VPN）に固有の要件を提供します。（L2およびL3 VPNにジェネリックの要件は[RFC3809]に含まれています。）
This document identifies requirements that may apply to one or more individual approaches that a Service Provider may use to provision a Layer 3 (e.g., IP) VPN service. It makes use of the terminology and common components for Layer 3 VPNs as defined in [L3VPN-FR] and of the generic VPN terminology defined in [PPVPN-TERM].
このドキュメントは、サービスプロバイダーがレイヤー3（例：IP）VPNサービスをプロビジョニングするために使用できる1つ以上の個別のアプローチに適用される可能性のある要件を特定します。[L3VPN-FR]で定義されているレイヤー3 VPNSの用語と一般的なコンポーネントと、[PPVPN-TERM]で定義されている一般的なVPN用語を使用します。
The specification of technical means to provide L3VPN services is outside the scope of this document. Other documents are intended to cover this aspect, such as the L3 VPN framework document [L3VPN-FR] and several sets of documents, one for each technical approach for providing L3VPN services.
L3VPNサービスを提供する技術手段の仕様は、このドキュメントの範囲外です。他のドキュメントは、L3 VPNフレームワークドキュメント[L3VPN-FR]や、L3VPNサービスを提供するための技術的アプローチごとに1つのドキュメントのセットなど、この側面をカバーすることを目的としています。
Technical approaches targeted by this document include the network-based (PE-based) L3VPN category (aggregated routing VPNs [2547bis] and virtual routers [PPVPN-VR]) and the CE-based L3VPNs category [CE-PPVPN][IPSEC-PPVPN]. The document distinguishes L3VPN categories as to where the endpoints of tunnels exist, as detailed in the L3VPN framework document [L3VPN-FR]. Terminology describing whether equipment faces a customer or the service provider network is used to define the various types of L3VPN solutions.
このドキュメントのターゲットを絞った技術的アプローチには、ネットワークベースの（PEベース）L3VPNカテゴリ（集約されたルーティングVPN [2547BIS]および仮想ルーター[PPVPN-VR]）およびCEベースのL3VPNカテゴリ[CE-PPVPN] [IPSEC-PPVPN]。このドキュメントは、L3VPNフレームワークドキュメント[L3VPN-FR]で詳述されているように、トンネルのエンドポイントが存在する場所に関するL3VPNカテゴリを区別します。機器が顧客に直面しているかサービスプロバイダーネットワークに直面するかを説明する用語を使用して、さまざまなタイプのL3VPNソリューションを定義します。
This document is intended as a "checklist" of requirements, providing a consistent way to evaluate and document how well each approach satisfies specific requirements. The applicability statement documents for each approach should present the results of this evaluation. This document is not intended to compare one approach to another.
このドキュメントは、要件の「チェックリスト」として意図されており、各アプローチが特定の要件をどのように満たすかを評価および文書化する一貫した方法を提供します。各アプローチのアプリケーションステートメント文書は、この評価の結果を提示する必要があります。このドキュメントは、あるアプローチを別のアプローチと比較することを意図したものではありません。
This document provides requirements from several points of view. It begins with some considerations from a point of view common to customers and service providers not covered in the generic provider provisioned VPN requirement document [RFC3809], continues with a customer perspective, and concludes with specific needs of a Service Provider (SP).
このドキュメントは、いくつかの観点から要件を提供します。これは、顧客に共通する視点からのいくつかの考慮事項から始まり、ジェネリックプロバイダーのプロビジョニングVPN要件ドキュメント[RFC3809]でカバーされていないサービスプロバイダーが顧客の観点を継続し、サービスプロバイダー（SP）の特定のニーズで締めくくります。
The following L3VPN deployment scenarios are considered within this document:
次のL3VPN展開シナリオは、このドキュメント内で考慮されます。
1. Internet-wide: VPN sites attached to arbitrary points in the Internet.
1. インターネット全体：インターネット内の任意のポイントに接続されているVPNサイト。
2. Single SP/single AS: VPN sites attached to the network of a single provider within the scope of a single AS.
2. シングルSP/シングルAS：単一のASの範囲内で単一のプロバイダーのネットワークに接続されているVPNサイト。
3. Single SP/multiple ASes: VPN sites attached to the network of a single provider consisting of multiple ASes.
3. 単一のSP/複数ASES：複数のASESで構成される単一プロバイダーのネットワークに接続されているVPNサイト。
4. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide the VPN service.
4. 協力SPS：VPNサービスを提供するために互いに協力するさまざまなプロバイダーのネットワークに接続されているVPNサイト。
The above deployment scenarios have many requirements in common. These include SP requirements for security, privacy, manageability, interoperability, and scalability, including service provider projections for number, complexity, and rate of change of customer VPNs over the next several years. When requirements apply to a specific deployment scenario, the above terminology is used to state the context of those particular requirements.
上記の展開シナリオには、多くの要件が共通しています。これらには、今後数年間の顧客VPNの数、複雑さ、および変化の速度に関するサービスプロバイダーの予測など、セキュリティ、プライバシー、管理性、相互運用性、およびスケーラビリティに関するSP要件が含まれます。特定の展開シナリオに要件が適用される場合、上記の用語を使用して、これらの特定の要件のコンテキストを述べます。
The outline of the rest of the document is as follows: Section 2 lists the contributing authors. Section 3 provides definitions of terms and concepts. Section 4 provides requirements common to both customers and service providers that are not covered in the generic provider provisioned VPN requirement document [RFC3809]. Section 5 states requirements from a customer perspective. Section 6 states network requirements from a service provider perspective. Section 7 states service provider management requirements. Section 8 describes security considerations. Section 9 lists acknowledgments. Section 10 provides a list of references cited herein. Section 11 lists the authors' addresses.
ドキュメントの残りの部分の概要は次のとおりです。セクション2には、貢献者の著者がリストされています。セクション3では、用語と概念の定義を示します。セクション4では、ジェネリックプロバイダープロビジョニングVPN要件ドキュメント[RFC3809]でカバーされていない顧客とサービスプロバイダーの両方に共通の要件を提供します。セクション5には、顧客の観点から要件があります。セクション6には、サービスプロバイダーの観点からネットワークの要件があります。セクション7には、サービスプロバイダー管理の要件が記載されています。セクション8では、セキュリティ上の考慮事項について説明します。セクション9に謝辞を示します。セクション10では、ここで引用した参照のリストを示します。セクション11には、著者のアドレスを示します。
This document is the combined effort of the two co-editors and the following contributing authors:
この文書は、2人の共同編集者と次の貢献著者の組み合わせの努力です。
Luyuan Fang Ananth Nagarajan Junichi Sumimoto Rick Wilder
luyuan fang ananth nagarajan junichi sumimoto Rick Wilder
This section provides the definition of terms and concepts used throughout the document. Terminology used herein is taken from [PPVPN-TERM] and [L3VPN-FR].
このセクションでは、ドキュメント全体で使用される用語と概念の定義を提供します。本明細書で使用される用語は、[PPVPN-TERM]および[L3VPN-FR]から取得されます。
"L3 Virtual Private Network" (L3VPN) refers to the L3 communication between a set of sites making use of a shared network infrastructure.
「L3仮想プライベートネットワーク」（L3VPN）は、共有ネットワークインフラストラクチャを使用する一連のサイト間のL3通信を指します。
"Provider Provisioned VPN" (PPVPN) refers to VPNs for which the service provider participates in management and provisioning of the VPN.
「プロバイダープロビジョニングVPN」（PPVPN）は、サービスプロバイダーがVPNの管理とプロビジョニングに参加するVPNを指します。
User: A user is an entity (e.g., a human being using a host, a server, or a system) authorized to use a VPN service.
ユーザー：ユーザーは、VPNサービスの使用を許可されたエンティティ（ホスト、サーバー、またはシステムを使用する人間）です。
Site: A site is a set of users that have mutual L3 (i.e., IP) reachability without use of a specific service provider network. A site may consist of a set of users that are in geographic proximity. Note that a topological definition of a site (e.g., all users at a specific geographic location) may not always conform to this definition. For example, two geographic locations connected via another provider's network would also constitute a single site as communication between the two locations does not involve the use of the service provider offering the L3 VPN service.
サイト：サイトは、特定のサービスプロバイダーネットワークを使用せずに相互L3（つまり、IP）の到達可能性を持つユーザーのセットです。サイトは、地理的に近接しているユーザーのセットで構成されている場合があります。サイトのトポロジ定義（たとえば、特定の地理的位置にあるすべてのユーザー）は、常にこの定義に適合するとは限らないことに注意してください。たとえば、別のプロバイダーのネットワークを介して接続された2つの地理的場所は、2つの場所間の通信にはL3 VPNサービスを提供するサービスプロバイダーの使用が含まれないため、単一のサイトも構成されます。
Customer: A single organization, corporation, or enterprise that administratively controls a set of sites.
顧客：一連のサイトを管理上管理する単一の組織、企業、または企業。
Agent: A set of users designated by a customer who has the authorization to manage a customer's VPN service offering.
エージェント：顧客のVPNサービスサービスを管理する許可を持っている顧客によって指定されたユーザーのセット。
Intranet: An intranet restricts communication to a set of sites that belong to one customer. An example is branch offices at different sites that require communication with a headquarters site.
イントラネット：イントラネットは、1人の顧客に属する一連のサイトへの通信を制限します。例は、本社サイトとの通信が必要なさまざまなサイトの支店です。
Extranet: An extranet allows the specification of communication between a set of sites that belong to different customers. In other words, two or more organizations have access to a specified set of each other's sites. Examples of extranets include multiple companies cooperating in joint software development, a service provider having access to information from the vendors' corporate sites, different companies, or universities participating in a consortium. An extranet often has further restrictions on reachability, for example, at a host and individual transport level.
エクストラネット：エクストラネットにより、さまざまな顧客に属するサイトのセット間の通信の仕様が可能になります。言い換えれば、2つ以上の組織が、互いのサイトの特定のセットにアクセスできます。エクストラネットの例には、共同ソフトウェア開発に協力している複数の企業、ベンダーの企業サイト、さまざまな企業、またはコンソーシアムに参加している大学からの情報にアクセスできるサービスプロバイダーが含まれます。エクストラネットは、多くの場合、宿主や個々の輸送レベルなど、到達可能性に関するさらなる制限があります。
Note that an intranet or extranet can exist across a single service provider network with one or more ASes, or across multiple service provider networks.
イントラネットまたはエクストラネットは、1つ以上のASEを備えた単一のサービスプロバイダーネットワーク全体、または複数のサービスプロバイダーネットワーク全体に存在できることに注意してください。
L3 Virtual Private Network (L3VPN): An alternative definition of VPN refers to a specific set of sites that have been configured to allow communication as either an intranet or an extranet. Note that a site is a member of at least one VPN and may be a member of many VPNs.
L3仮想プライベートネットワーク（L3VPN）：VPNの代替定義とは、イントラネットまたはエクストラネットとして通信を許可するように構成された特定のサイトセットを指します。サイトは少なくとも1つのVPNのメンバーであり、多くのVPNのメンバーである可能性があることに注意してください。
L3VPNs are composed of the following types of devices.
L3VPNは、次のタイプのデバイスで構成されています。
Customer Edge (CE) device: A CE device faces the users at a customer site. The CE has an access connection to a PE device. It may be a router or a switch that allows users at a customer site to communicate over the access network with other sites in the VPN. In a CE-based L3VPN, as intended in this document (provider-provisioned CE-based VPN), the service provider manages (at least partially) the CE device.
顧客エッジ（CE）デバイス：CEデバイスは、顧客サイトでユーザーに向きます。CEには、PEデバイスへのアクセス接続があります。これは、顧客サイトのユーザーがVPNの他のサイトとアクセスネットワークを介して通信できるようにするルーターまたはスイッチかもしれません。このドキュメント（プロバイダーがプロビジョニングしたCEベースのVPN）で意図したCEベースのL3VPNで、サービスプロバイダーは（少なくとも部分的に）CEデバイスを管理します。
Provider Edge (PE) device: A PE device faces the provider network on one side and attaches via an access connection over one or more access networks to one or more CE devices. It participates in the Packet Switched Network (PSN) in performing routing and forwarding functions.
プロバイダーエッジ（PE）デバイス：PEデバイスは、片側のプロバイダーネットワークに面し、1つ以上のアクセスネットワークを介して1つ以上のCEデバイスにアクセス接続を介して接続します。ルーティングおよび転送機能を実行する際に、パケットスイッチネットワーク（PSN）に参加します。
Note that the definitions of Customer Edge and Provider Edge do not necessarily describe the physical deployment of equipment on customer premises or a provider point of presence.
顧客エッジとプロバイダーのEDGEの定義は、顧客の施設やプロバイダーの存在点での機器の物理的な展開を必ずしも説明していないことに注意してください。
Provider (P) device: A device within a provider network that interconnects PE (or other P) devices but does not have any direct attachment to CE devices. The P router does not keep VPN state and is VPN unaware [PPVPN-TERM].
プロバイダー（P）デバイス：PE（または他のP）デバイスを相互接続するが、CEデバイスに直接接続されていないプロバイダーネットワーク内のデバイス。PルーターはVPN状態を維持せず、VPNが認識していない[PPVPN-TERM]。
Packet Switched Network (PSN): A (IP or MPLS [RFC3031]) network through which the tunnels supporting the VPN services are set up [PPVPN-TERM].
パケットスイッチネットワーク（PSN）：A（IPまたはMPLS [RFC3031]）ネットワークは、VPNサービスをサポートするトンネルがセットアップされます[PPVPN-Term]。
Service Provider (SP) network: An SP network is a set of interconnected PE and P devices administered by a single service provider in one or more ASes.
サービスプロバイダー（SP）ネットワーク：SPネットワークは、1つ以上のASEで単一のサービスプロバイダーによって管理される相互接続されたPEおよびPデバイスのセットです。
VPNs are built between CEs by using access networks, tunnels, and hierarchical tunnels across a PSN.
VPNは、PSN全体でアクセスネットワーク、トンネル、階層トンネルを使用してCES間に構築されます。
Access connection: An access connection provides connectivity between a CE and a PE. This includes dedicated physical circuits, virtual circuits (such as Frame Relay), ATM, Ethernet (V)LAN, or IP tunnels (e.g., IPsec, L2TP [RFC2661]).
アクセス接続：アクセス接続は、CEとPE間の接続を提供します。これには、専用の物理回路、仮想回路（フレームリレーなど）、ATM、イーサネット（V）LAN、またはIPトンネル（IPSEC、L2TP [RFC2661]など）が含まれます。
Access network: An access network provides access connections between CE and PE devices. It may be a TDM network, an L2 network (e.g., FR, ATM, and Ethernet), or an IP network over which access is tunneled (e.g., by using L2TP).
アクセスネットワーク：アクセスネットワークは、CEデバイスとPEデバイス間のアクセス接続を提供します。TDMネットワーク、L2ネットワーク（FR、ATM、イーサネットなど）、またはアクセスがトンネル化されているIPネットワーク（L2TPを使用するなど）です。
Tunnel: A tunnel between two entities is formed by encapsulating packets within another encapsulating header for the purposes of transmission between those two entities in support of a VPN application. Examples of protocols commonly used for tunneling are GRE, IPsec, IP-in-IP tunnels, and MPLS.
トンネル：2つのエンティティ間のトンネルは、VPNアプリケーションをサポートするこれら2つのエンティティ間の送信を目的として、別のカプセル化ヘッダー内のカプセル化パケットによって形成されます。トンネリングに一般的に使用されるプロトコルの例は、GRE、IPSEC、IP-in-IPトンネル、およびMPLSです。
Hierarchical Tunnel: Encapsulating one tunnel within another forms a hierarchical tunnel. The innermost tunnel protocol header defines a logical association between two entities (e.g., between CEs or PEs) [VPNTUNNEL]. Note that the tunneling protocols need not be the same at different levels in a hierarchical tunnel.
階層トンネル：別のトンネルをカプセル化すると、階層的トンネルが形成されます。最も内側のトンネルプロトコルヘッダーは、2つのエンティティ（CESまたはPESの間）間の論理的な関連性を定義します[VPNTUnnel]。トンネルプロトコルは、階層的トンネルの異なるレベルで同じである必要はないことに注意してください。
This section summarizes the points where tunnels terminate and the functions implemented in the CE and PE devices that differentiate the two major categories of L3VPNs for which requirements are stated, namely PE-based and CE-based L3VPNs. See the L3VPN framework document for more detail [L3VPN-FR].
このセクションでは、トンネルが終了するポイントと、要件が記載されているL3VPNの2つの主要なカテゴリ、すなわちPEベースおよびCEベースのL3VPNを区別するCEおよびPEデバイスに実装された関数を要約します。詳細[L3VPN-FR]については、L3VPNフレームワークドキュメントを参照してください。
In a PE-based L3VPN service, a customer site receives IP layer (i.e., layer 3) service from the SP. The PE is attached via an access connection to one or more CEs. The PE forwards user data packets based on information in the IP layer header, such as an IPv4 or IPv6 destination address. The CE sees the PE as a layer 3 device such as an IPv4 or IPv6 router.
PEベースのL3VPNサービスでは、顧客サイトがSPからIPレイヤー（つまり、レイヤー3）サービスを受信します。PEは、1つ以上のCESへのアクセス接続を介して接続されます。PEは、IPv4やIPv6宛先アドレスなど、IPレイヤーヘッダーの情報に基づいてユーザーデータパケットを前進させます。CEは、PEをIPv4やIPv6ルーターなどのレイヤー3デバイスと見なしています。
Virtual Forwarding Instance (VFI): In a PE-based L3VPN service, the PE contains a VFI for each L3 VPN that it serves. The VFI terminates tunnels for interconnection with other VFIs and also terminates access connections for accommodating CEs. VFI contains information regarding how to forward data received over the CE-PE access connection to VFIs in other PEs supporting the same L3VPN. The VFI includes the router information base and the forwarding information base for an L3VPN [L3VPN-FR]. A VFI enables router functions dedicated to serving a particular VPN, such as separation of forwarding and routing and support for overlapping address spaces. Routing protocols in the PEs and the CEs interact to populate the VFI.
仮想転送インスタンス（VFI）：PEベースのL3VPNサービスでは、PEには各L3 VPNのVFIが含まれています。VFIは、他のVFIとの相互接続のためにトンネルを終了し、CESに対応するためにアクセス接続を終了します。VFIには、同じL3VPNをサポートする他のPESでVFIへのCE-PEアクセス接続を介して受信したデータを転送する方法に関する情報が含まれています。VFIには、L3VPN [L3VPN-FR]のルーター情報ベースと転送情報ベースが含まれます。VFIは、転送やルーティングの分離、オーバーラップアドレススペースのサポートなど、特定のVPNの提供に特化したルーター機能を可能にします。PESとCESのルーティングプロトコルが相互作用してVFIに入力します。
The following narrative and figures provide further explanation of the way PE devices use tunnels and hierarchical tunnels. Figure 1.1 illustrates the case where a PE uses a separate tunnel for each VPN. As shown in the figure, the tunnels provide communication between the VFIs in each of the PE devices.
次の物語と図は、PEデバイスがトンネルと階層トンネルを使用する方法のさらなる説明を提供します。図1.1は、PEが各VPNに別のトンネルを使用する場合を示しています。図に示すように、トンネルは各PEデバイスのVFI間の通信を提供します。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.1. PE Usage of Separate Tunnels to Support VPNs
図1.1。VPNをサポートするための個別のトンネルの使用
Figure 1.2 illustrates the case where a single hierarchical tunnel is used between PE devices to support communication for VPNs. The innermost encapsulating protocol header provides the means for the PE to determine the VPN for which the packet is directed.
図1.2は、VPNの通信をサポートするためにPEデバイス間で単一の階層トンネルが使用される場合を示しています。最も内側のカプセル化プロトコルヘッダーは、PEがパケットが指示されるVPNを決定する手段を提供します。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==============< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.2. PE Usage of Shared Hierarchical Tunnels to Support VPNs
図1.2。VPNをサポートするための共有階層トンネルのPEの使用
Figure 1.3 illustrates the CE-based L3VPN reference model. In this configuration, typically a single level of tunnel (e.g., IPsec) terminates at pairs of CEs. Usually, a CE serves a single customer site, and therefore the forwarding and routing is physically separate from all other customers. Furthermore, the PE is not aware of the membership of specific CE devices to a particular VPN. Hence, the VPN functions are implemented with provisioned configurations on the CE devices, and the shared PE and P network is used to only provide the routing and forwarding that supports the tunnel endpoints on between CE devices. The tunnel topology connecting the CE devices may be a full or partial mesh, depending on VPN customer requirements and traffic patterns.
図1.3は、CEベースのL3VPN参照モデルを示しています。この構成では、通常、単一レベルのトンネル（IPSECなど）がCESのペアで終了します。通常、CEは単一の顧客サイトにサービスを提供しているため、転送とルーティングは他のすべての顧客と物理的に分離されています。さらに、PEは特定のVPNに対する特定のCEデバイスのメンバーシップを認識していません。したがって、VPN関数はCEデバイス上のプロビジョニングされた構成で実装され、共有PEおよびPネットワークは、CEデバイス間のトンネルエンドポイントをサポートするルーティングと転送のみを提供するために使用されます。CEデバイスを接続するトンネルトポロジは、VPNの顧客要件とトラフィックパターンに応じて、完全または部分的なメッシュになる場合があります。
+---------+ +--------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +----------+ +----------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | |management| |management| | | : |
|interface| | | function | | function | | |Customer |
| | | +----------+ +----------+ | |interface|
| | | | | |
+---------+ +--------------------------------+ +---------+
| Access | |<-------- SP network(s) ------->| | Access |
| network | | | | network |
Figure 1.3. CE-Based L3VPN
図1.3。CEベースのL3VPN
Customer Network Management Function: A customer network management function provides the means for a customer agent to query or configure customer-specific information, or to receive alarms regarding his or her VPN. Customer-specific information includes data related to contact, billing, site, access network, IP address, and routing protocol parameters. It may use a combination of proprietary network management system, SNMP manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).
顧客ネットワーク管理機能：顧客ネットワーク管理機能は、顧客エージェントが顧客固有の情報を照会または構成する手段を提供し、VPNに関するアラームを受け取る手段を提供します。顧客固有の情報には、連絡先、請求、サイト、アクセスネットワーク、IPアドレス、およびルーティングプロトコルパラメーターに関連するデータが含まれます。独自のネットワーク管理システム、SNMPマネージャー、またはディレクトリサービス（LDAP [RFC3377] [RFC2251]など）の組み合わせを使用する場合があります。
Provider Network Management Function: A provider network management function provides many of the same capabilities as a customer network management system across all customers. This would not include customer confidential information, such as keying material. The intent of giving the provider a view comparable to that of the customer is to aid in troubleshooting and problem resolution. Such a system also provides the means to query, configure, or receive alarms regarding any infrastructure supporting the L3VPN service. It may use a combination of proprietary network management system, SNMP manager, or directory service (e.g., LDAP [RFC3377] [RFC2251]).
プロバイダーネットワーク管理機能：プロバイダーネットワーク管理機能は、すべての顧客全体で顧客ネットワーク管理システムと同じ機能を提供します。これには、キーイング素材などの顧客の機密情報は含まれません。プロバイダーに顧客の見解に匹敵する見解を与えることは、トラブルシューティングと問題解決を支援することです。このようなシステムは、L3VPNサービスをサポートするインフラストラクチャに関するアラームを照会、構成、または受信する手段も提供します。独自のネットワーク管理システム、SNMPマネージャー、またはディレクトリサービス（LDAP [RFC3377] [RFC2251]など）の組み合わせを使用する場合があります。
Many of the requirements that apply to both the customer and the provider and are of an otherwise general nature, or that apply to both L2 and L3VPNs, are described in [RFC3809]. This section contains requirements that are not covered in [RFC3809] and that are specific to L3VPNs.
顧客とプロバイダーの両方に適用され、そうでなければ一般的な性質である、またはL2とL3VPNの両方に適用される要件の多くは、[RFC3809]で説明されています。このセクションには、[RFC3809]でカバーされておらず、L3VPNに固有の要件が含まれています。
A mechanism must be provided for isolating the distribution of reachability information to only those sites associated with a VPN.
VPNに関連付けられたサイトのみに到達可能性情報の分布を分離するためのメカニズムを提供する必要があります。
L3VPN solutions shall define means that prevent routers in a VPN from interacting with unauthorized entities and that avoid introducing undesired routing information that could corrupt the VPN routing information base [VPN-CRIT].
L3VPNソリューションは、VPNのルーターが不正なエンティティと相互作用するのを防ぎ、VPNルーティング情報ベース[VPN-Crit]を破損する可能性のある望ましくないルーティング情報の導入を避ける手段を定義するものとします。
A means must be provided to constrain or isolate the distribution of addressed data to only those VPN sites determined by either routing data and/or configuration.
アドレス指定されたデータの分布を、ルーティングデータおよび/または構成によって決定されるVPNサイトのみに制約または分離するための手段を提供する必要があります。
A single site shall be capable of being in multiple VPNs. The VPN solution must ensure that traffic is exchanged only with sites in the same VPN.
単一のサイトは、複数のVPNに存在できるものとします。VPNソリューションは、トラフィックが同じVPNのサイトとのみ交換されることを確認する必要があります。
The internal structure of a VPN should not be advertised or discoverable from outside that VPN.
VPNの内部構造は、そのVPNの外部から宣伝したり発見したりしないでください。
Note that isolation of forwarded data or exchange of reachability information to only those sites that are part of a VPN may be viewed as a form of security - for example, [Y.1311.1], [MPLSSEC].
VPNの一部であるサイトのみへの転送データまたは到達可能性情報の交換の分離は、たとえば[Y.1311.1]、[MPLSSEC]などのセキュリティの形式と見なされる可能性があることに注意してください。
IP addresses must be unique within the set of sites reachable from the VPNs of which a particular site is a member.
IPアドレスは、特定のサイトがメンバーであるVPNから到達可能なサイトのセット内で一意でなければなりません。
A VPN solution must support IPv4 and IPv6 as both the encapsulating and encapsulated protocol.
VPNソリューションは、カプセンシングプロトコルとカプセル化プロトコルの両方としてIPv4とIPv6をサポートする必要があります。
If a customer has private or non-unique IP addresses, then a VPN service SHOULD be capable of translating such customer private or non-unique IP addresses for communicating with IP systems having public addresses.
顧客がプライベートまたは非ユニークのIPアドレスを持っている場合、VPNサービスは、パブリックアドレスを持つIPシステムと通信するために、そのような顧客プライベートまたは非ユニークのIPアドレスを翻訳できる必要があります。
To the extent possible, L3VPN QoS should be independent of the access network technology.
可能な限り、L3VPN QOSはアクセスネットワークテクノロジーとは無関係である必要があります。
A non-goal of the L3VPN WG effort (as chartered) is the development of new protocols or extension of existing ones. An L3VPN shall be able to support QoS in one or more of the following already defined modes:
L3VPN WGの取り組み（チャーターされた）の非ゴールは、新しいプロトコルの開発または既存のプロトコルの拡張です。L3VPNは、既に定義されているモードの1つ以上でQOをサポートできるものとします。
- Best Effort (mandatory support for all L3VPN types) - Aggregate CE Interface Level QoS ("hose" level QoS) - Site-to-site ("pipe" level QoS) - Intserv (i.e., RSVP) signaled - Diffserv marked - Across packet-switched access networks
- 最善の努力（すべてのL3VPNタイプの必須サポート） - 集約CEインターフェイスレベルQOS（ "HOSE"レベルQOS） - サイトツーサイト（ "パイプ"レベルQOS） - intserv（すなわち、RSVP）シグナル付き - diffservマーク付き - パケット全体 - スイッチされたアクセスネットワーク
Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing.
QoSを含むすべてのケースでは、CEおよび/またはPEがシェーピングおよび/またはポリシングを実行する必要がある場合があることに注意してください。
L3VPN CEs should be capable of supporting integrated services (Intserv) for certain customers in support of session applications, such as switched voice or video. Intserv-capable CE devices shall support the following Internet standards:
L3VPN CESは、スイッチされた音声やビデオなどのセッションアプリケーションをサポートする特定の顧客に統合サービス（INTSERV）をサポートできる必要があります。IntServ対応のCEデバイスは、次のインターネット標準をサポートするものとします。
- Resource reSerVation Protocol (RSVP) [RFC2205] - Guaranteed Quality of Service providing a strict delay bound [RFC2212] - Controlled Load Service providing performance equivalent to that of an unloaded network [RFC2211]
- リソース予約プロトコル（RSVP）[RFC2205] - 厳密な遅延バウンドを提供する保証されたサービス品質[RFC2212] - アンロードされたネットワークのパフォーマンスに相当するパフォーマンスを提供する制御された負荷サービス[RFC2211]
L3VPN CE and PE should be capable of supporting differentiated service (Diffserv). Diffserv-capable L3VPN CE and PE shall support the following per hop behavior (PHB) [RFC2475] types:
L3VPN CEおよびPEは、差別化されたサービス（DIFFSERV）をサポートできる必要があります。diffserv-capable l3vpn ceおよびPEは、ホップごとの動作（PHB）[RFC2475]タイプをサポートするものとします。
- Expedited Forwarding (EF) - The departure rate of an aggregate class of traffic from a device that must equal or exceed a configured rate [RFC3246].
- Expedited Forwarding（EF） - 構成されたレート[RFC3246]に等しく、またはそれを超えなければならないデバイスからのトラフィックの総クラスの出発率。
- Assured Forwarding (AF) - A means for a provider Diffserv (DS) domain to offer different levels of forwarding assurances for IP packets received from a customer DS domain. Four AF classes are defined, where each AF class implies allocation in each DS node of a certain amount of forwarding resources (e.g., buffer space and bandwidth) [RFC2597].
- Assured Forwarding（AF） - プロバイダーDIFFSERV（DS）ドメインが、顧客DSドメインから受け取ったIPパケットのさまざまなレベルの転送保証を提供する手段。4つのAFクラスが定義されています。各AFクラスは、一定量の転送リソース（バッファスペースと帯域幅など）の各DSノードの割り当てを意味します[RFC2597]。
A CE or PE device supporting an L3VPN service may classify a packet for a particular Intserv or Diffserv service based on one or more of the following IP header fields: protocol ID, source port number, destination port number, destination address, or source address.
L3VPNサービスをサポートするCEまたはPEデバイスは、次のIPヘッダーフィールドの1つ以上に基づいて、特定のIntServまたはDiffServサービスのパケットを分類することができます：プロトコルID、ソースポート番号、宛先ポート番号、宛先アドレス、またはソースアドレス。
For a specifiable set of Internet traffic, L3VPN devices should support Random Early Detection (RED) to provide graceful degradation in the event of network congestion.
指定可能なインターネットトラフィックのセットの場合、L3VPNデバイスは、ネットワークの混雑が発生した場合に優雅な劣化を提供するために、ランダムな早期検出（赤）をサポートする必要があります。
A service provider must be able to offer QoS service to a customer for at least the following generic service types: managed-access VPN service or edge-to-edge QoS VPN service [RFC3809]. More detail specific to L3VPNs is provided below.
サービスプロバイダーは、少なくとも次の汎用サービスタイプのQoSサービスを顧客に提供できる必要があります：マネージドアクセスVPNサービスまたはエッジツーエッジQOS VPNサービス[RFC3809]。L3VPNSに固有の詳細を以下に示します。
A managed-access L3VPN service provides QoS on the access connection between the CE and the PE. For example, diffserv would be enabled only on the CE router and the customer-facing ports of the PE router. Note that this service would not require Diffserv implementation in the SP backbone. The SP may use policing for inbound traffic at the PE. The CE may perform shaping for outbound traffic. Another example of a managed-access L3VPN service is when the SP performs the packet classification and diffserv marking. An SP may provide several packet classification profiles that customers may select or may offer custom profiles based on customer specific requirements. In general, more complex QoS policies should be left to the customer for implementation.
マネージドアクセスL3VPNサービスは、CEとPEの間のアクセス接続にQOSを提供します。たとえば、diffservは、CEルーターとPEルーターの顧客向けポートでのみ有効になります。このサービスでは、SPバックボーンでのdiffserv実装は必要ないことに注意してください。SPは、PEでのインバウンドトラフィックにポリシングを使用する場合があります。CEは、アウトバウンドトラフィックのシェーピングを実行する場合があります。マネージドアクセスL3VPNサービスのもう1つの例は、SPがパケット分類とDiffServマーキングを実行するときです。SPは、顧客が顧客固有の要件に基づいてカスタムプロファイルを選択または提供する可能性のあるいくつかのパケット分類プロファイルを提供する場合があります。一般に、実装のために、より複雑なQoSポリシーを顧客に任せる必要があります。
An edge-to-edge QoS VPN service provides QoS from edge device to edge device. The edge device may be either PE or CE, depending on the service demarcation point between the provider and the customer. Such a service may be provided across one or more provider backbones.
エッジツーエッジQOS VPNサービスは、エッジデバイスからエッジデバイスへのQOSを提供します。エッジデバイスは、プロバイダーと顧客の間のサービス境界点に応じて、PEまたはCEのいずれかである場合があります。このようなサービスは、1つ以上のプロバイダーバックボーンで提供される場合があります。
The CE requirements for this service model are the same as the managed access VPN service. However, in this service QoS is provided from one edge of the SP network(s) to the other.
このサービスモデルのCE要件は、マネージドアクセスVPNサービスと同じです。ただし、このサービスでは、QoSはSPネットワークの1つのエッジからもう一方のエッジまで提供されます。
A generic discussion of SLAs is provided in [RFC3809]. Additionally, SLS measurements for quality based on the DiffServ scheme SHOULD be based on the following classification:
SLAの一般的な議論は[RFC3809]で提供されています。さらに、diffservスキームに基づく品質のSLS測定は、次の分類に基づいている必要があります。
- A Point-to-Point SLS [Y.1311.1], sometimes also referred to as the "Pipe" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a pair of VPN sites (i.e., points). A Point-to-Point SLS is analogous to the SLS typically supported over point-to-point Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel. The set of SLS specifications to all other reachable VPN sites would define the overall Point-to-Point SLS for a specific site.
- 「パイプ」モデルとも呼ばれるポイントツーポイントSLS [Y.1311.1]は、VPNサイトのペア間で交換されるトラフィックのQoS目標（つまり、ポイント）と併せてトラフィックパラメーターを定義します。ポイントツーポイントSLSは、ポイントツーポイントフレームリレーまたはATM PVCSまたはエッジツーエッジMPLSトンネルで通常サポートされるSLSに類似しています。他のすべての到達可能なVPNサイトのSLS仕様のセットは、特定のサイトの全体的なポイントツーポイントSLSを定義します。
- A Point-to-Cloud SLS [Y.1311.1], sometimes also referred to as the "Hose" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a CE and a PE for traffic destined to a set (either all or a subset) of other sites in the VPN (i.e., the cloud), as applicable. In other words, a point-to-cloud SLS defines compliance in terms of all packets transmitted from a given VPN site toward the SP network on an aggregate basis (i.e., regardless of the destination VPN site of each packet).
- 「ホース」モデルとも呼ばれるポイントツークラウドSLS [Y.1311.1]は、セットに運命づけられているトラフィックのCEとPEの間で交換されるトラフィックのQOS目標と併せてトラフィックパラメーターを定義します（どちらかです該当する場合、VPN（つまり、クラウド）の他のサイトのすべてまたはサブセット）。言い換えれば、ポイントツークラウドSLSは、特定のVPNサイトからSPネットワークに送信されたすべてのパケットのコンプライアンスを集計ベースで定義します（つまり、各パケットの宛先VPNサイトに関係なく）。
- A Cloud-to-Point SLS (a case not covered by this SLS is where flows originating from multiple sources may congest the interface toward a specific site).
- クラウドからポイントのSLS（このSLSでカバーされていないケースは、複数のソースに由来するフローが特定のサイトにインターフェイスを混雑させる可能性がある場合です）。
Traffic parameters and actions SHOULD be defined for packets to and from the demarcation between the service provider and the site. For example, policing may be defined on ingress, and shaping on egress.
トラフィックパラメーターとアクションは、サービスプロバイダーとサイト間の境界との間のパケットに対して定義する必要があります。たとえば、ポリシングは侵入で定義され、出口で形成される場合があります。
An SP and its customers MUST be able to manage the capabilities and characteristics of their VPN services. To the extent possible, automated operations and interoperability with standard management platforms SHOULD be supported.
SPとその顧客は、VPNサービスの機能と特性を管理できる必要があります。可能な限り、標準管理プラットフォームとの自動化された操作と相互運用性をサポートする必要があります。
The ITU-T Telecommunications Management Network (TMN) model has the following generic requirements structure:
ITU-T Telecommunications Management Network（TMN）モデルには、次の一般的な要件構造があります。
O Engineer, deploy, and manage the switching, routing, and transmission resources supporting the service, from a network perspective (network element management).
oネットワークの観点から、サービスをサポートするスイッチング、ルーティング、および送信リソースをエンジニア、展開、および管理します（ネットワーク要素管理）。
O Manage the VPN networks deployed over these resources (network management).
oこれらのリソース（ネットワーク管理）に展開されているVPNネットワークを管理します。
o Manage the VPN service (service management). o Manage the VPN business, mainly provisioning administrative and accounting information related to the VPN service customers (business management).
o VPNサービス（サービス管理）を管理します。o VPNビジネスを管理し、主にVPNサービス顧客（ビジネス管理）に関連する管理および会計情報を提供します。
Service management should include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Provisioning, and Security, as detailed in section 7.
サービス管理には、次のようにTMN 'FCAPS'機能を含める必要があります。セクション7で詳述されているように、障害、構成、会計、プロビジョニング、セキュリティ。
Interworking scenarios among different solutions providing L3VPN services is highly desirable. See the L3VPN framework document for more details on interworking scenarios [L3VPN-FR]. Interworking SHOULD be supported in a scalable manner.
L3VPNサービスを提供するさまざまなソリューション間のインターワーキングシナリオは非常に望ましいです。インターワーキングシナリオの詳細[L3VPN-FR]の詳細については、L3VPNフレームワークドキュメントを参照してください。インターワーキングは、スケーラブルな方法でサポートする必要があります。
Interworking scenarios MUST at least consider traffic and routing isolation, security, QoS, access, and management aspects. This requirement is essential of network migration, to ensure service continuity among sites belonging to different portions of the network.
インターワーキングシナリオは、少なくともトラフィックとルーティングの分離、セキュリティ、QO、アクセス、および管理の側面を考慮する必要があります。この要件は、ネットワークのさまざまな部分に属するサイト間のサービスの継続性を確保するために、ネットワーク移行に不可欠です。
This section captures additional requirements from a customer perspective.
このセクションでは、顧客の観点から追加の要件をキャプチャします。
When an extranet is formed, a customer agent from each of the organizations first approves addition of a site to an extranet VPN as a business decision between the parties involved. The solution SHOULD provide a means for these organizations to control extranet communication involving the L3VPN exchange of traffic and routing information.
エクストラネットが形成されると、各組織の顧客エージェントは、関係者間のビジネス上の決定として、最初にエクストラネットVPNにサイトを追加することを承認します。このソリューションは、これらの組織がトラフィックとルーティング情報のL3VPN交換を含むエクストラネット通信を制御する手段を提供する必要があります。
Customers MAY require VPN service that spans multiple administrative domains or service provider networks. Therefore, a VPN service MUST be able to span multiple AS and SP networks, but still act and appear as a single, homogeneous VPN from a customer point of view.
顧客は、複数の管理ドメインまたはサービスプロバイダーネットワークにまたがるVPNサービスを必要とする場合があります。したがって、VPNサービスは複数のASとSPネットワークに及ぶことができる必要がありますが、それでも顧客の観点から単一の均質なVPNとして行動し、登場する必要があります。
A customer might also start with a VPN provided in a single AS with a certain SLA but then ask for an expansion of the service, spanning multiple ASes/SPs. In this case, as well as for all kinds of multi-AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to all sites in a VPN regardless of the AS/SP to which it homes.
また、顧客は、特定のSLAと同様に、1つのSLAで提供されるVPNから開始することもできますが、複数のASES/SPSにまたがるサービスの拡張を求めます。この場合、あらゆる種類のMulti-AS/SP VPNの場合、VPNサービスは、それが家のAS/SPに関係なく、VPN内のすべてのサイトに同じSLAを配信できるはずです。
A customer requires support from an L3VPN for the following addressing IP assignment schemes:
顧客は、次のIP割り当てスキームに対処するためにL3VPNからのサポートを必要とします。
o Customer-assigned, non-unique, or [RFC1918] private addresses o Globally unique addresses obtained by the customer o Globally unique addresses statically assigned by the L3VPN service provider o On-demand, dynamically assigned IP addresses (e.g., DHCP), irrespective of whether the access is temporary (e.g., remote) or permanent (e.g., dedicated)
o 顧客が割り当てられた、非不合理、または[RFC1918]プライベートアドレスo顧客が取得したグローバルに一意のアドレスo L3VPNサービスプロバイダーによって静的に割り当てられたグローバルに一意のアドレスoオンデマンドで動的に割り当てられたIPアドレス（DHCPなど）は、それに応じて無関係にアクセスが一時的な（例：リモート）または永続的であるか（例えば、専用）
In the case of combined L3VPN service with non-unique or private addresses and Internet access, mechanisms that permit the exchange of traffic between the customer's address space and the global unique Internet address space MAY be supported. For example, NAT is employed by many customers and by some service providers today to meet this need. A preferred solution would be to assign unique addresses, either IPv4 or IPv6; however, some customers do not want to renumber their networks.
L3VPNサービスを組み合わせた非ユニークまたはプライベートアドレスとインターネットアクセスの場合、顧客の住所スペースとグローバルなユニークなインターネットアドレススペースとの間のトラフィックの交換を可能にするメカニズムがサポートされる場合があります。たとえば、NATは、このニーズを満たすために、多くの顧客や一部のサービスプロバイダーに今日雇用されています。優先ソリューションは、IPv4またはIPv6のいずれかの一意のアドレスを割り当てることです。ただし、一部の顧客は、ネットワークの名前を変更したくありません。
There SHOULD be no restriction on the routing protocols used between CE and PE routers, or between CE routers. At least the following protocols MUST be supported: static routing, IGP protocols such as RIP, OSPF, IS-IS, and BGP [L3VPN-FR].
CEルーターとPEルーター間、またはCEルーター間で使用されるルーティングプロトコルに制限はないはずです。少なくとも次のプロトコルをサポートする必要があります：静的ルーティング、RIP、OSPF、IS-IS、BGPなどのIGPプロトコル[L3VPN-FR]。
QoS is expected to be an important aspect of an L3VPN service for some customers. QoS requirements cover scenarios involving an intranet, an extranet, and shared access between a VPN site and the Internet.
QoSは、一部の顧客にとってL3VPNサービスの重要な側面になると予想されます。QoS要件は、VPNサイトとインターネット間のイントラネット、エクストラネット、および共有アクセスを含むシナリオをカバーしています。
A customer is concerned primarily that the L3VPN service provides his or her applications with the QoS and level of traffic so that the applications perform acceptably. Voice, interactive video, and multimedia applications are expected to require the most stringent QoS. These real-time applications are sensitive to delay, delay variation, loss, availability, and/or reliability. Another set of applications, including some multimedia and interactive video applications, high-performance web browsing, and file transfer intensive applications, requires near real time performance. Finally, best effort applications are not sensitive to degradation, that is they are elastic and can adapt to conditions of degraded performance.
顧客は、主にL3VPNサービスがアプリケーションとトラフィックのレベルを彼または彼女のアプリケーションに提供して、アプリケーションを許容できるように提供することを懸念しています。音声、インタラクティブなビデオ、およびマルチメディアアプリケーションには、最も厳しいQOが必要になると予想されます。これらのリアルタイムアプリケーションは、遅延、遅延の変動、損失、可用性、および/または信頼性に敏感です。いくつかのマルチメディアおよびインタラクティブなビデオアプリケーション、高性能のWebブラウジング、ファイル転送集中アプリケーションなど、別のアプリケーションには、ほぼリアルタイムのパフォーマンスが必要です。最後に、最善の努力アプリケーションは劣化に敏感ではありません。つまり、弾力性があり、劣化したパフォーマンスの状態に適応できます。
The selection of appropriate QoS and service type to meet specific application requirements is particularly important to deal with periods of congestion in an SP network. Sensitive applications will likely select per-flow Integrated service (Intserv) with precise SLA guarantees measured on a per-flow basis. On the other hand, non-sensitive applications will likely rely on a Diffserv class-based QoS.
特定のアプリケーション要件を満たすための適切なQoSとサービスタイプの選択は、SPネットワークでの混雑の期間に対処するために特に重要です。デリケートなアプリケーションは、フローごとに測定された正確なSLA保証を使用して、フローごとの統合サービス（INTSERV）を選択する可能性があります。一方、非敏感なアプリケーションは、DiffServクラスベースのQOSに依存する可能性があります。
The fundamental customer application requirement is that an L3VPN solution MUST support both the Intserv QoS model for selected individual flows and Diffserv for aggregated flows.
基本的な顧客アプリケーションの要件は、L3VPNソリューションが選択された個々のフローのINTSERV QOSモデルと、集約されたフローのDiffServの両方をサポートする必要があることです。
A customer application SHOULD experience consistent QoS independent of the access network technology used at different sites connected to the same VPN.
顧客アプリケーションは、同じVPNに接続されたさまざまなサイトで使用されるアクセスネットワークテクノロジーとは無関係に、一貫したQoSを経験する必要があります。
The Diffserv Code Point (DSCP) set by a user as received by the ingress CE SHOULD be capable of being relayed transparently to the egress CE (see section 2.6.2 of [RFC3270] and [Y.1311.1]). Although RFC 2475 states that interior or boundary nodes within a DS domain can change the DSCP, customer VPNs MAY have other requirements, such as
Ingress CEが受信したユーザーが設定したDiffServコードポイント（DSCP）は、脱出CEに透過的にリレーできる必要があります（[RFC3270]および[Y.1311.1]のセクション2.6.2を参照）。RFC 2475は、DSドメイン内の内部または境界ノードがDSCPを変更できると述べていますが、顧客VPNには他の要件がある場合があります。
o applications that use the DSCP in a manner differently from the DSCP solution supported by the SP network(s), o customers using more DSCPs within their sites than the SP network(s) supports, o support for a carrier's carrier service in which one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to his or her VPN customers independently of the DSCP mapping solution supported by the carrier's carrier SP.
o SPネットワークでサポートされているDSCPソリューションとは異なる方法でDSCPを使用するアプリケーション、o SPネットワークよりもサイト内でより多くのDSCPを使用している顧客は、1つのSPがキャリアのキャリアサービスをサポートしています。別のl3vpn spの顧客です。このようなSPは、キャリアのキャリアSPによってサポートされるDSCPマッピングソリューションとは無関係に、VPNサービスをVPNサービスに再販できるはずです。
Note that support for DSCP transparency has no implication on the QoS or SLA requirements. If an SP supports DSCP transparency, then that SP needs to carry only the DSCP values across its domain but MAY map the received DSCP to some other value for QoS support across its domain.
DSCPの透明性のサポートは、QOSまたはSLA要件に影響を与えないことに注意してください。SPがDSCPの透明性をサポートする場合、そのSPはドメイン全体にDSCP値のみを運ぶ必要がありますが、受信したDSCPをドメイン全体でQoSサポートの他の値にマッピングする必要があります。
Most customers simply want their applications to perform well. An SLA is a vehicle for customer recourse in the event that SP(s) do not perform or manage a VPN service well in a measurable sense. Therefore, when purchasing service under an SLA, a customer agent
ほとんどの顧客は、単にアプリケーションをうまく機能させることを望んでいます。SLAは、SPが測定可能な意味でVPNサービスを適切に実行または管理していない場合、顧客の手段のための手段です。したがって、SLAの下でサービスを購入する場合、顧客エージェント
MUST have access to the measures from the SP(s) that support the SLA.
SLAをサポートするSPからのメジャーにアクセスできる必要があります。
A customer MUST have a means to view the topology, operational state, order status, and other parameters associated with his or her VPN.
顧客は、VPNに関連するトポロジ、運用状態、注文ステータス、およびその他のパラメーターを表示する手段を持っている必要があります。
Most aspects of management information about CE devices and customer attributes of an L3VPN manageable by an SP SHOULD be capable of being configured and maintained by an authenticated, authorized customer agent. However, some aspects, such as encryption keys, SHALL NOT be readable nor writable by management systems.
SPが管理できるL3VPNのCEデバイスと顧客属性に関する管理情報のほとんどの側面は、認証された認定された顧客エージェントによって構成および維持できる必要があります。ただし、暗号化キーなどのいくつかの側面は、管理システムによって読みやすく、書き込み可能ではありません。
A customer agent 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 service is a "Dynamic Bandwidth management" capability that enables real-time response to customer requests for changes of allocated bandwidth allocated to his or her VPN [Y.1311.1].
顧客エージェントは、トラフィックパラメーターの変更を動的にリクエストできる必要があります。顧客は、これらの要求に応じてSPネットワークからリアルタイムの応答を受信できる必要があります。このようなサービスの1つの例は、VPNに割り当てられた割り当てられた帯域幅の変更に対する顧客要求に対するリアルタイムの応答を可能にする「動的帯域幅管理」機能です[Y.1311.1]。
A customer who may not be able to afford the resources to manage his own sites SHOULD be able to outsource the management of the entire VPN to the SP(s) supporting the VPN network.
自分のサイトを管理するためのリソースを購入できない可能性のある顧客は、VPNネットワークをサポートするSP（S）にVPN全体の管理を外部委託できるはずです。
These features include traffic and routing information exchange isolation, similar to that obtained in VPNs based on Layer 1 and Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC].
これらの機能には、レイヤー1とレイヤー2（たとえば、プライベートライン、FR、またはATM）[MPLSSEC]に基づいてVPNで得られたものと同様のトラフィックおよびルーティング情報交換の分離が含まれます。
The suite of L3VPN solutions SHOULD support a range of security related features. Higher levels of security services, such as edge-to-edge encryption, authentication, or replay attack, should be supported. More details on customer requirements for security are described in [VPNSEC].
L3VPNソリューションのスイートは、さまざまなセキュリティ関連機能をサポートする必要があります。エッジツーエッジの暗号化、認証、リプレイ攻撃など、より高いレベルのセキュリティサービスをサポートする必要があります。セキュリティの顧客要件の詳細については、[VPNSEC]で説明しています。
Security in an L3VPN service SHOULD be as transparent as possible to the customer, with the obvious exception of support for remote or temporary user access, as detailed in section 5.11.2.
セクション5.11.2で詳述されているように、L3VPNサービスのセキュリティは、顧客にとって可能な限り透明である必要があります。
L3VPN customers MUST be able to deploy their own internal security mechanisms in addition to those deployed by the SP, in order to secure specific applications or traffic at a granularity finer than that on a site-to-site basis.
L3VPNの顧客は、SPによって展開されているものに加えて、サイトからサイトごとに特定のアプリケーションまたはトラフィックを保護するために、独自の内部セキュリティメカニズムに加えて、独自の内部セキュリティメカニズムを展開できる必要があります。
If a customer requires QoS support in an L3VPN, then this request MUST be communicated to the SP either by using unencrypted fields or via an agreed security association. For example, applications could send RSVP messages in support of Intserv either in the clear or encrypted with a key negotiated with the SP. Another case is that where applications using an IPsec tunnel could copy the DSCP from the encrypted IP header to the header of the tunnel's IP header.
顧客がL3VPNでQOSサポートを必要とする場合、この要求は、暗号化されていないフィールドを使用するか、合意されたセキュリティ協会を介してSPに通知する必要があります。たとえば、アプリケーションは、SPと交渉されたキーとともに、クリアまたは暗号化されたINTSERVをサポートするRSVPメッセージを送信できます。別のケースは、IPSECトンネルを使用するアプリケーションが暗号化されたIPヘッダーからトンネルのIPヘッダーのヘッダーにDSCPをコピーできる場合です。
Often, customers are migrating from an already deployed private network toward one or more L3VPN solutions. A typical private network scenario is CE routers connected via real or virtual circuits. Ideally, minimal incremental cost SHOULD result during the migration period. Furthermore, if necessary, any disruption of service SHOULD also be minimized.
多くの場合、顧客はすでに展開されているプライベートネットワークから1つ以上のL3VPNソリューションに移行しています。典型的なプライベートネットワークシナリオは、実際のサーキットまたは仮想回路を介して接続されたCEルーターです。理想的には、移行期間中に最小限の増分コストが発生するはずです。さらに、必要に応じて、サービスの混乱も最小限に抑える必要があります。
A range of scenarios of customer migration MUST be supported. Full migration of all sites MUST be supported. Support for cases of partial migration is highly desirable [Y.1311.1] - that is, legacy private network sites that belong to the L3VPN service SHOULD still have L3 reachability to the sites that migrate to the L3VPN service.
顧客移行のさまざまなシナリオをサポートする必要があります。すべてのサイトの完全な移行をサポートする必要があります。部分移行の場合のサポートは非常に望ましい[Y.1311.1] - つまり、L3VPNサービスに属するレガシープライベートネットワークサイトは、L3VPNサービスに移行するサイトにL3の到達可能性を持つ必要があります。
Every L3 packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L3VPN.
顧客とSPの間で交換されたすべてのL3パケットは、アクセス接続を介して表示される必要があります。プライベートネットワーク上に表示され、L3VPNが提供するものと同等のサービスを提供する必要があります。
L3VPNs SHOULD support a broad range of physical and link-layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, and mobile radio access. The capacity and QoS achievable may be dependent on the specific access technology in use.
L3VPNは、PSTN、ISDN、XDSL、ケーブルモデム、リースライン、イーサネット、イーサネットVLAN、ATM、フレームリレー、ワイヤレスローカルループ、モバイル無線アクセスなど、幅広い物理的およびリンク層アクセス技術をサポートする必要があります。達成可能な容量とQoSは、使用中の特定のアクセステクノロジーに依存する場合があります。
The VPN service offering SHOULD allow both permanent and temporary access to one or more L3VPNs for authenticated users across a broad range of access technologies. Support for remote or temporary VPN access SHOULD include ISDN, PSTN dial-in, xDSL, or access via another SP network. The customer SHOULD be able to choose from alternatives for authentication of temporary access users. Choices for access authentication are SP-provided, third-party, or customer-provided authentication.
VPNサービスは、幅広いアクセステクノロジーにわたって認証されたユーザー向けに、1つ以上のL3VPNへの永続的および一時的なアクセスの両方を可能にする必要があります。リモートまたは一時的なVPNアクセスのサポートには、ISDN、PSTNダイヤルイン、XDSL、または別のSPネットワークを介したアクセスを含める必要があります。顧客は、一時的なアクセスユーザーの認証のために代替案から選択できる必要があります。アクセス認証の選択肢は、SP専門家、サードパーティ、または顧客が提供する認証です。
A significant number of VPN users may not be permanently attached to one VPN site: in order to limit access to a VPN to authorized users, it is first necessary to authenticate them. Authentication SHALL apply as configured by the customer agent and/or SP where a specific user may be part of one or more VPNs. The authentication function SHOULD be used to invoke all actions necessary to join a user to the VPN automatically.
かなりの数のVPNユーザーが1つのVPNサイトに永続的に接続されていない場合があります。VPNへのアクセスを認定ユーザーに制限するために、最初に認証する必要があります。認証は、特定のユーザーが1つ以上のVPNの一部である場合がある顧客エージェントおよび/またはSPによって構成されているように適用するものとします。認証関数を使用して、ユーザーをVPNに自動的に結合するために必要なすべてのアクションを呼び出す必要があります。
A user SHOULD be able to access an L3VPN via a network having generic Internet access.
ユーザーは、一般的なインターネットアクセスを持つネットワークを介してL3VPNにアクセスできる必要があります。
Mobile users may move within an L3VPN site. Mobile users may also have temporary connections to different L3VPN sites within the same VPN. Authentication SHOULD be provided in both of these cases.
モバイルユーザーは、L3VPNサイト内に移動する場合があります。モバイルユーザーは、同じVPN内の異なるL3VPNサイトへの一時的な接続を持つ場合もあります。これらの両方のケースで認証を提供する必要があります。
In a PE-based L3VPN, if the site shares the access network with other traffic (e.g., access to the Internet), then data security in the access network is the responsibility of the L3VPN customer.
PEベースのL3VPNでは、サイトがアクセスネットワークを他のトラフィック（たとえば、インターネットへのアクセス）と共有している場合、アクセスネットワークのデータセキュリティはL3VPN顧客の責任です。
Various types of physical connectivity scenarios MUST be supported, such as multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks. L3VPN solutions SHOULD support at least the types of physical or link-layer connectivity arrangements shown in Figure 2.1. Support for other physical connectivity scenarios with arbitrary topology is desirable.
マルチホームサイト、顧客サイト間のバックドアリンク、2つ以上のSPネットワークに拠点を置くデバイスなど、さまざまな種類の物理的な接続シナリオをサポートする必要があります。L3VPNソリューションは、図2.1に示すように、少なくとも物理的またはリンク層接続のタイプをサポートする必要があります。任意のトポロジを使用した他の物理的な接続シナリオのサポートが望ましいです。
Access arrangements with multiple physical or logical paths from a CE to other CEs and PEs MUST support redundancy and SHOULD support load balancing. Resiliency uses redundancy to provide connectivity between a CE site and other CE sites and, optionally, other services. Load balancing provides a means to perform traffic engineering so that capacity on redundant links is used to achieve improved performance during periods when the redundant component(s) are available.
CEから他のCEおよびPESへの複数の物理的または論理的なパスを備えたアクセス配置は、冗長性をサポートする必要があり、負荷分散をサポートする必要があります。Resiliencyは、冗長性を使用して、CEサイトと他のCEサイト、およびオプションで他のサービス間の接続性を提供します。ロードバランシングは、交通工学を実行する手段を提供し、冗長リンクの容量を使用して、冗長コンポーネントが利用可能な期間中にパフォーマンスの向上を実現します。
For multi-homing to a single SP, load balancing capability SHOULD be supported by the PE across the CE to PE links. For example, in case (a), load balancing SHOULD be provided by the two PEs over the two links connecting to the single CE. In case (c), load balancing SHOULD be provided by the two PEs over the two links connecting to the two CEs.
単一のSPにマルチホミングするには、CEを越えてPEリンクを横切るPEによってロードバランス機能をサポートする必要があります。たとえば、（a）の場合、単一のCEに接続する2つのリンク上の2つのPESによって負荷分散を提供する必要があります。ケース（c）では、2つのCESに接続する2つのリンクにわたって2つのPESによって負荷分散を提供する必要があります。
In addition, the load-balancing parameters (e.g., the ratio of traffic on the multiple load-balanced links, or the preferred link) SHOULD be provisionable based on customer's requirements. The load-balancing capability may also be used to achieve resiliency in the event of access connectivity failures. For example, in case (b) a CE may connect to two different SPs via diverse access networks. Resiliency MAY be further enhanced as shown in case (d), where CEs connected via a "back door" connection connect to different SPs. Furthermore, arbitrary combinations of the above methods, with a few examples shown in cases (e) and (f), should be supportable by any L3VPN approach.
さらに、負荷バランスパラメーター（たとえば、複数の負荷バランスリンクまたは優先リンクのトラフィックの比率）は、顧客の要件に基づいて提供可能である必要があります。負荷分散機能は、アクセス接続の故障が発生した場合に回復力を実現するために使用することもできます。たとえば、（b）の場合、CEは多様なアクセスネットワークを介して2つの異なるSPSに接続できます。ケース（d）に示すように、弾力性はさらに強化される場合があります。ここで、CESは「バックドア」接続を介して接続されており、異なるSPSに接続します。さらに、上記の方法の任意の組み合わせと、ケース（e）および（f）にいくつかの例が示されているため、L3VPNアプローチではサポートできる必要があります。
For multi-homing to multiple SPs, load balancing capability MAY also be supported by the PEs in the different SPs (clearly, this is a more complex type of load balancing to realize, requiring policy and service agreements between the SPs to interoperate).
複数のSPSへのマルチホーミングの場合、ロードバランス機能は異なるSPSのPESによってサポートされる場合があります（明らかに、これは実現するためにより複雑なタイプの負荷分散であり、SPS間のポリシーとサービス契約を相互運用する必要があります）。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |router| | |router| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|router| +---------|router| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
+---------------
|door \\ | SP network |door \\
+---------------
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
Figure 2.1. Representative types of access arrangements
図2.1。代表的な種類のアクセスアレンジメント
Customers MAY also require access to other services, as described in this section.
このセクションで説明されているように、顧客は他のサービスにアクセスする必要がある場合もあります。
Customers SHOULD be able to have L3VPN and Internet access across the same access network for one or more of the customer's sites.
顧客は、1つ以上の顧客のサイトに対して同じアクセスネットワーク全体でL3VPNとインターネットアクセスを持つことができるはずです。
Customers SHOULD be able to direct Internet traffic from the set of sites in the L3VPN to one or more customer sites that have firewalls, other security-oriented devices, and/or NATs that process all traffic between the Internet and the customer's VPN.
顧客は、L3VPNのサイトのセットから、ファイアウォール、その他のセキュリティ指向のデバイス、および/またはインターネットと顧客のVPN間のすべてのトラフィックを処理するNATを持つ1つ以上の顧客サイトにインターネットトラフィックを向けることができる必要があります。
L3 VPN Customers SHOULD be able to receive traffic from the Internet addressed to a publicly accessible resource that is not part of the VPN, such as an enterprise's public web server.
L3 VPNのお客様は、エンタープライズのパブリックWebサーバーなど、VPNの一部ではない公開可能なリソースに宛てられたインターネットからトラフィックを受信できるはずです。
As stated in section 5.3, if a customer L3VPN employs private or non-unique IP addresses, then network address translation (NAT) or a similar mechanism MUST be provided either by the customer or the SP in order to allow traffic exchange with devices outside the customer's L3VPN.
セクション5.3で述べたように、顧客L3VPNがプライベートまたは非ユニークのIPアドレスを採用している場合、ネットワークアドレス変換（NAT）または同様のメカニズムを顧客またはSPが提供する必要があります。顧客のL3VPN。
A customer SHOULD be able to access hosting, other application services, or other Application Service Providers (ASP) over an L3 L3VPN service. This MAY require that an ASP participate in one or more VPNs with the customers that use such a service.
顧客は、L3 L3VPNサービスを介してホスティング、その他のアプリケーションサービス、またはその他のアプリケーションサービスプロバイダー（ASP）にアクセスできる必要があります。これには、ASPがそのようなサービスを使用する顧客と1つ以上のVPNに参加する必要がある場合があります。
In conjunction with a VPN service, a customer MAY also wish to have access to other services, such as DNS, FTP, HTTP, NNTP, SMTP, LDAP, VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, Streaming, E-commerce, Directory, Firewall, etc. The resources that implement these services could be physically dedicated to each VPN. If the resources are logically shared, then they MUST have access separated and isolated between VPNs in a manner consistent with the L3VPN solution to meet this requirement.
VPNサービスと併せて、顧客は、DNS、FTP、HTTP、NNTP、SMTP、LDAP、VOIP、NAT、LDAP、ビデオ会議、アプリケーション共有、電子ビジネス、ストリーミング、などの他のサービスにアクセスすることも望む場合があります。eコマース、ディレクトリ、ファイアウォールなど。これらのサービスを実装するリソースは、各VPNに物理的に専用する可能性があります。リソースが論理的に共有されている場合、この要件を満たすためにL3VPNソリューションと一致する方法で、VPN間で分離および分離されたアクセスが必要です。
Intranet or extranet customers have a number of reasons for wanting hybrid networks that involve more than one VPN solution type. These include migration, mergers, extranet customers with different VPN types, the need for different capabilities between different sets of sites, temporary access, and different availability of VPN solutions as provided by different service providers.
イントラネットまたはエクストラネットのお客様には、複数のVPNソリューションタイプを含むハイブリッドネットワークを希望する多くの理由があります。これらには、移行、合併、さまざまなVPNタイプのエクストラネット顧客、さまざまなサイトセット間の異なる機能の必要性、一時アクセス、さまざまなサービスプロバイダーが提供するVPNソリューションのさまざまな可用性が含まれます。
The framework and solution approaches SHOULD include provisions for interworking, interconnection, and/or reachability between different
フレームワークとソリューションのアプローチには、異なる間の相互作用、相互接続、および/または到達可能性のための規定を含める必要があります
L3VPN solutions in a way that does not overly complicate provisioning, management, scalability, or performance.
L3VPNソリューションは、プロビジョニング、管理、スケーラビリティ、またはパフォーマンスを過度に複雑にしない方法で。
This section describes requirements from a service provider perspective.
このセクションでは、サービスプロバイダーの観点からの要件について説明します。
[RFC3809] lists projections of L3VPN sizing and scalability requirements and metrics related to specific solutions.
[RFC3809]は、L3VPNサイジングとスケーラビリティ要件と特定のソリューションに関連するメトリックの予測をリストしています。
As described in section 4.2, SPs MUST have support for public and private IP addresses, IPv4 and IPv6, for both unicast and multicast. In order to support this range of addressing schemes, SPs require the following support from L3VPN solutions.
セクション4.2で説明したように、SPSは、ユニキャストとマルチキャストの両方について、パブリックおよびプライベートIPアドレス、IPv4およびIPv6のサポートを持っている必要があります。この範囲のアドレス指定スキームをサポートするために、SPはL3VPNソリューションから次のサポートを必要とします。
An L3VPN solution MUST be able to assign blocks of addresses from its own public IP address space to L3VPN customer sites so that advertisement of routes to other SPs and other sites aggregates efficiently.
L3VPNソリューションは、独自のパブリックIPアドレススペースからL3VPNカスタマーサイトにアドレスのブロックを割り当てることができ、他のSPSや他のサイトへのルートの広告が効率的に集合するようにする必要があります。
An L3VPN solution MUST be able to use address assignments made by a customer. These customer-assigned addresses may be public or private.
L3VPNソリューションは、顧客が作成したアドレス割り当てを使用できる必要があります。これらの顧客が割り当てられた住所は、パブリックまたはプライベートである場合があります。
If private IP addresses are used, an L3VPN solution MUST provide a means for an SP to translate such addresses to public IP addresses for communication with other VPNs by using overlapping addresses or the Internet.
プライベートIPアドレスを使用する場合、L3VPNソリューションは、重複するアドレスまたはインターネットを使用して、SPが他のVPNとの通信のためにそのようなアドレスをパブリックIPアドレスに変換する手段を提供する必要があります。
A number of identifiers MAY be necessary for SP use in management, control, and routing protocols. Requirements for at least the following identifiers are known.
管理、制御、およびルーティングプロトコルでSPを使用するには、多くの識別子が必要になる場合があります。少なくとも次の識別子の要件が既知です。
An SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting a VPN that spans multiple SPs. Ideally, this identifier should be globally unique (e.g., an AS number).
SPドメインは、複数のSPSにまたがるVPNをサポートする場合、少なくともすべての相互接続されたSPネットワークのセット内で一意に識別する必要があります。理想的には、この識別子はグローバルに一意でなければなりません（例：AS数）。
An identifier for each VPN SHOULD be unique, at least within each SP's network. Ideally, the VPN identifier SHOULD be globally unique to support the case where a VPN spans multiple SPs (e.g., [RFC2685]).
各VPNの識別子は、少なくとも各SPのネットワーク内で一意でなければなりません。理想的には、VPN識別子は、VPNが複数のSPSにまたがる場合をサポートするためにグローバルに一意である必要があります（例：[RFC2685]）。
A CE device SHOULD have a unique identifier, at least within each SP's network.
CEデバイスには、少なくとも各SPのネットワーク内に、一意の識別子が必要です。
A PE device SHOULD have a unique identifier, at least within each SP's network.
PEデバイスには、少なくとも各SPのネットワーク内に、一意の識別子が必要です。
The identifier of a device interconnecting SP networks MUST be unique within the set of aforementioned networks.
SPネットワークを相互接続するデバイスの識別子は、前述のネットワークのセット内で一意でなければなりません。
Each site interface SHOULD have a unique identifier, at least within each PE router supporting such an interface.
各サイトインターフェイスには、少なくともそのようなインターフェイスをサポートする各PEルーター内に、一意の識別子が必要です。
Each tunnel SHOULD have a unique identifier, at least within each router supporting the tunnel.
各トンネルには、少なくともトンネルをサポートする各ルーター内に、一意の識別子が必要です。
Configuration of CE and PE devices is a significant task for a service provider. Solutions SHOULD strive to contain methods that dynamically allow VPN information to be discovered (or learned) by the PE and/or CE to reduce configuration complexity. The following specific requirements apply to intra- and inter-provider VPNs [VPNDISC].
CEおよびPEデバイスの構成は、サービスプロバイダーにとって重要なタスクです。ソリューションは、構成の複雑さを減らすために、PEおよび/またはCEによってVPN情報を動的に検出（または学習）する方法を含めるよう努力する必要があります。以下の特定の要件は、イントラおよびパバイダー間VPN [VPNDISC]に適用されます。
Every device involved in a VPN SHALL be able to identify and authenticate itself to other devices in the VPN. After learning the VPN membership, the devices SHOULD be able to exchange configuration information securely. The VPN information MUST include at least the IP address of the PE and may be extensible to provide additional information.
VPNに関与するすべてのデバイスは、VPN内の他のデバイスに識別して認証できるものとします。VPNメンバーシップを学習した後、デバイスは構成情報を安全に交換できるはずです。VPN情報には、少なくともPEのIPアドレスを含める必要があり、追加情報を提供するために拡張可能な場合があります。
Each device in a VPN SHOULD be able to determine which other devices belong to the same VPN. Such a membership discovery scheme MUST prevent unauthorized access and allow authentication of the source.
VPN内の各デバイスは、同じVPNに属する他のデバイスを決定できる必要があります。このようなメンバーシップ発見スキームは、不正アクセスを防ぎ、ソースの認証を許可する必要があります。
Distribution of VPN information SHOULD be limited to those devices involved in that VPN.
VPN情報の配布は、そのVPNに関与するデバイスに限定する必要があります。
In the case of a PE-based VPN, a solution SHOULD support the means for attached CEs to authenticate each other and verify that the SP's VPN network is correctly configured.
PEベースのVPNの場合、ソリューションは、接続されたCESが互いに認証するための手段をサポートし、SPのVPNネットワークが正しく構成されていることを確認する必要があります。
The mechanism SHOULD respond to VPN membership changes in a timely manner. This is no longer than the provisioning timeframe, typically on the order of minutes, and could be as short as the timeframe required for "rerouting", typically on the order of seconds.
メカニズムは、VPNメンバーシップの変更にタイムリーに応答する必要があります。これは、通常は数分でのプロビジョニング時間枠ほどではなく、「再ルーティング」に必要な時間枠と同じくらい短い場合があります。
Dynamically creating, changing, and managing multiple VPN assignments to sites and/or customers is another aspect of membership that MUST be addressed in an L3VPN solution.
複数のVPN割り当てをサイトおよび/または顧客に動的に作成、変更、および管理することは、L3VPNソリューションで対処する必要があるメンバーシップのもう1つの側面です。
Typically, a Service Provider offering an L3VPN service commits to specific Service Level Specifications (SLS) as part of a contract with the customer, as described in section 4.4 and [RFC3809]. Such a Service Level Agreement (SLA) implies SP requirements for measuring Specific Service Level Specifications (SLS) for quality, availability, response time, and configuration intervals.
通常、セクション4.4および[RFC3809]で説明されているように、L3VPNサービスを提供するサービスプロバイダーは、顧客との契約の一部として特定のサービスレベル仕様（SLS）にコミットします。このようなサービスレベル契約（SLA）は、品質、可用性、応答時間、および構成間隔に対して特定のサービスレベル仕様（SLS）を測定するためのSP要件を意味します。
A significant aspect of an L3VPN is support for QoS. Since an SP has control over the provisioning of resources and configuration of parameters in at least the PE and P devices and, in some cases, in the CE device as well, the onus is on the SP to provide either managed QoS access service, or edge-to-edge QoS service, as defined in section 4.3.2.
L3VPNの重要な側面は、QOSのサポートです。SPは、少なくともPEおよびPデバイス、場合によってはCEデバイスのリソースのプロビジョニングとパラメーターの構成を制御しているため、CEデバイスでも、SPには管理されたQoSアクセスサービス、または管理されたQoSアクセスサービスを提供するため、SPはSPにあります。セクション4.3.2で定義されているエッジツーエッジQoSサービス。
Each L3VPN approach MUST describe the traffic engineering techniques available for an SP to meet the QoS objectives. These descriptions of traffic engineering techniques SHOULD quantify scalability and achievable efficiency. Traffic engineering support MAY be on an aggregate or per-VPN basis.
各L3VPNアプローチは、QoS目標を満たすためにSPが利用できるトラフィックエンジニアリング手法を説明する必要があります。トラフィックエンジニアリング手法のこれらの説明は、スケーラビリティと達成可能な効率を定量化する必要があります。トラフィックエンジニアリングのサポートは、総計またはVPNごとに行われる場合があります。
QoS policies MUST not be impacted by security mechanisms. For example, Diffserv policies MUST not be impacted by the use of IPSec tunnels using the mechanisms explained in RFC 2983 [RFC2983].
QoSポリシーは、セキュリティメカニズムの影響を受けてはなりません。たとえば、RFC 2983 [RFC2983]で説明されているメカニズムを使用して、IPSECトンネルの使用によってDiffServポリシーが影響を受けることはありません。
As stated in RFC 2475, a mapping function from customer provided Diffserv marking to marking used in an SP network should be provided for L3 VPN services.
RFC 2475に記載されているように、顧客からSPネットワークで使用されるマーキングを提供する顧客からのマッピング機能は、L3 VPNサービスに提供する必要があります。
If a customer requires DSCP transparency, as described in section 5.5.2, an L3VPN service MUST deliver the same value of DSCP field in the IP header received from the customer to the egress demarcation of the destination.
セクション5.5.2で説明されているように、顧客がDSCPの透明性を必要とする場合、L3VPNサービスは、顧客から目的地の出口境界に受け取ったIPヘッダーでDSCPフィールドの同じ値を提供する必要があります。
The distribution of reachability and routing policy SHOULD be constrained to the sites that are members of the VPN.
到達可能性とルーティングポリシーの分布は、VPNのメンバーであるサイトに制約する必要があります。
Optionally, the exchange of such information MAY use some form of authentication (e.g., MD5).
オプションで、そのような情報の交換は、何らかの形の認証（MD5など）を使用する場合があります。
Functions to isolate the SP network and customer VPNs from anomalous routing behavior from a specific set of customer sites SHOULD be provided. Examples of such functions are controls for route flap dampening, filters that accept only prefixes configured for a specific CE, a maximum number of routes accepted for each CE, or a maximum rate at which route updates can be received from a CE.
特定の一連の顧客サイトからの異常なルーティング動作からSPネットワークと顧客VPNを分離する機能を提供する必要があります。このような関数の例は、ルートフラップ減衰のコントロール、特定のCEに対して構成された接頭辞のみを受け入れるフィルター、各CEに受け入れられる最大数のルート、またはCEからルートの更新を受信できる最大レートです。
When VPN customers use overlapping non-unique IP addresses, the solution MUST define a means to distinguish between such overlapping addresses on a per-VPN basis.
VPNの顧客が重複していないIPアドレスを使用する場合、ソリューションは、VPNごとに重複するアドレスを区別するための手段を定義する必要があります。
Furthermore, the solution SHOULD provide an option that either allows or prevents advertisement of VPN routes to the Internet.
さらに、ソリューションは、VPNルートの広告をインターネットに許可または防止するオプションを提供する必要があります。
Ideally, the choice of an SP's IGP SHOULD not depend on the routing protocol(s) used between PE and CE routers in a PE-based VPN.
理想的には、SPのIGPの選択は、PEベースのVPNでPEルーターとCEルーターの間で使用されるルーティングプロトコルに依存してはなりません。
Furthermore, it is desirable that an SP SHOULD have a choice regarding the IGP routing protocol.
さらに、SPがIGPルーティングプロトコルに関して選択できることが望ましい。
The additional routing burden that an SP must carry should be articulated in each specific L3VPN solution.
SPが携帯しなければならない追加のルーティング負担は、特定の各L3VPNソリューションで明確にする必要があります。
The internal structure of an L3VPN network SHOULD not be visible to outside networks (e.g., the Internet or any connected VPN).
L3VPNネットワークの内部構造は、外部ネットワーク（たとえば、インターネットや接続されたVPN）に表示されないでください。
From a high-level SP perspective, a PE-based L3VPN MUST isolate the exchange of traffic and routing information to only those sites that are authenticated and authorized members of a VPN.
高レベルのSPの観点から、PEベースのL3VPNは、VPNの認証および承認されたメンバーのサイトのみにトラフィックとルーティング情報の交換を分離する必要があります。
In a CE-based VPN, the tunnels that connect the sites effectively meet this isolation requirement if both traffic and routing information flow over the tunnels.
CEベースのVPNでは、トラフィックとルーティング情報の両方がトンネル上で流れる場合、サイトを接続するトンネルがこの分離要件を効果的に満たしています。
An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA requirements that isolates VPN traffic from the effects of traffic offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a means to isolate the effects that traffic congestion produced by sites as part of one VPN can have on another VPN.
L3VPNソリューションは、非VPN顧客が提供するトラフィックの影響からVPNトラフィックを分離するL3VPN QOS SLA要件を満たす手段を提供する必要があります。また、L3VPNソリューションは、あるVPNの一部としてサイトによって生成された交通渋滞が別のVPNで持つ可能性のある効果を分離する手段を提供する必要があります。
This section contains requirements related to securing customer flows; providing authentication services for temporary, remote, or mobile users; and protecting service provider resources involved in supporting an L3VPN. More detailed security requirements are provided in [VPNSEC].
このセクションには、顧客のフローの保護に関連する要件が含まれています。一時的、リモート、またはモバイルユーザーに認証サービスを提供します。L3VPNのサポートに関与するサービスプロバイダーリソースの保護。より詳細なセキュリティ要件が[VPNSEC]に提供されています。
In order to meet the general requirement for providing a range of security options to a customer, each L3VPN solution MUST clearly spell out the configuration options that can work together and how they can do so.
さまざまなセキュリティオプションを顧客に提供するための一般的な要件を満たすために、各L3VPNソリューションは、協力できる構成オプションとその方法を明確に綴る必要があります。
When a VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a flow for a specified subset of a customer's VPN traffic:
VPNソリューションがインターネットの一部で動作する場合、顧客のVPNトラフィックの指定されたサブセットのフローを確保するための次の標準IPSECメソッドの1つ以上をサポートする構成可能なオプションをサポートする必要があります。
o Confidentiality, so that only authorized devices can decrypt it o Integrity, to ensure that the data has not been altered o Authentication, to ensure that the sender is indeed who he or she claims to be o Replay attack prevention.
o 機密性は、承認されたデバイスのみがそれを整合し、データが認証されていないことを保証し、送信者が実際に彼または彼女が再リプレイ攻撃防止であると主張することを確実にすることができるようにします。
The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites between temporary users and sites, and even between temporary users. It SHOULD also be possible to apply these functions to "control traffic", such as routing protocol exchanges, that are not necessarily perceived by the customer but are nevertheless essential to maintain his or her VPN.
上記の機能は、顧客の「データトラフィック」に適用する必要があります。これには、一時的なユーザーとサイト間のサイト間で交換されるトラフィックが含まれます。また、これらの機能を、ルーティングプロトコル交換などの「トラフィックの制御」に適用することも可能であるはずです。これは、必ずしも顧客によって認識されるわけではありませんが、それでもVPNを維持するために不可欠です。
Furthermore, 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 [VPNSEC].
さらに、このようなセキュリティ方法は、CE-CE、PE-PE、CE-PEなどの異なるエンドポイント間で構成可能でなければなりません。また、ルートごとまたはVPNごとにセキュリティを構成することも望ましい[VPNSEC]。
A VPN solution MAY support one or more encryption schemes, including AES, and 3DES. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system.
VPNソリューションは、AESおよび3DEを含む1つ以上の暗号化スキームをサポートする場合があります。暗号化、復号化、および主要な管理は、セキュリティ管理システムの一部としてプロファイルに含める必要があります。
A service provider MUST provide authentication services in support of temporary user access requirements, as described in section 5.11.2.
セクション5.11.2で説明されているように、サービスプロバイダーは、一時的なユーザーアクセス要件をサポートする認証サービスを提供する必要があります。
Furthermore, traffic exchanged within the scope of VPN MAY involve several categories of equipment that must cooperate to provide the service [Y.1311.1]. These network elements can be CE, PE, firewalls, backbone routers, servers, management stations, etc. These network elements learn about each other's identity, either via manual configuration or via discovery protocols, as described in section 6.4. When network elements must cooperate, these network elements SHALL authenticate peers before providing the requested service. This authentication function MAY also be used to control access to network resources.
さらに、VPNの範囲内で交換されるトラフィックには、サービスを提供するために協力しなければならないいくつかのカテゴリの機器が含まれる場合があります[Y.1311.1]。これらのネットワーク要素は、CE、PE、ファイアウォール、バックボーンルーター、サーバー、管理ステーションなどです。これらのネットワーク要素は、セクション6.4で説明されているように、手動構成またはディスカバリープロトコルを介して互いのアイデンティティについて学習します。ネットワーク要素が協力しなければならない場合、これらのネットワーク要素は、要求されたサービスを提供する前にピアを認証するものとします。この認証関数は、ネットワークリソースへのアクセスを制御するためにも使用できます。
The peer identification and authentication function described above applies only to network elements participating in the VPN. Examples include:
上記のピア識別と認証機能は、VPNに参加するネットワーク要素にのみ適用されます。例は次のとおりです。
- traffic between a CE and a PE, - traffic between CEs belonging to the same VPN, - CE or PE routers dealing with route announcements for a VPN, - policy decision point [RFC3198] and a network element, and - management station and an SNMP agent.
- CEとPEの間のトラフィック - 同じVPNに属するCE、VPNのルートアナウンスを扱うCEまたはPEルーター間のトラフィック、 - ポリシー決定ポイント[RFC3198]とネットワーク要素、および - 管理ステーションとSNMPエージェント。
For a peer authentication function, each L3VPN solution SHOULD describe where necessary, how it shall be implemented, how secure it must be, and the way to deploy and maintain identification and authentication information necessary to operate the service.
ピア認証関数の場合、各L3VPNソリューションは、必要に応じて、それがどのように実装されるか、それがどれだけ安全であるか、およびサービスを操作するために必要な識別と認証情報の展開と認証情報を維持する方法を説明する必要があります。
Recall from the definitions in section 3.3 that a site can be part of an intranet with sites from the only same organization, can be part of an extranet involving sites from other organizations, can have access to the Internet, or can have any combination of these scopes of communication. Within these contexts, a site might be subject to various attacks coming from different sources. Potential sources of attack include:
セクション3.3の定義から、サイトが唯一の同じ組織のサイトを持つイントラネットの一部になる可能性があることを思い出してください。コミュニケーションのスコープ。これらのコンテキスト内で、サイトはさまざまなソースからのさまざまな攻撃の対象となる場合があります。潜在的な攻撃源は次のとおりです。
- users connected to the supporting public IP backbone, - users from the Internet, and - users from temporary sites belonging to the intranet and/or extranet VPN the site is part of.
- サポートするパブリックIPバックボーンに接続されているユーザー、インターネットのユーザー、およびサイトのイントラネットおよび/またはエクストラネットVPNに属する一時的なサイトのユーザーは、一部の一部です。
Security threats and risks that a site may encounter include the following:
サイトが遭遇する可能性のあるセキュリティの脅威とリスクには、以下が含まれます。
- Denial of service, for example mail spamming, access connection congestion, TCP SYN attacks, and ping attacks - Intrusion attempts, which may eventually lead to denial of service (e.g., a Trojan horse attack).
- サービスの拒否、たとえば、メールスパム、アクセス接続の混雑、TCP Syn攻撃、およびping攻撃 - 侵入の試みなど、最終的にはサービスの拒否につながる可能性があります（トロイの木馬馬攻撃など）。
Additional threat scenarios are defined in [VPNSEC]. An L3VPN solution MUST state how it addresses each potential threat scenario.
追加の脅威シナリオは[VPNSEC]で定義されています。L3VPNソリューションは、各潜在的な脅威シナリオにどのように対処するかを述べる必要があります。
The devices in the L3VPN network must provide some means of reporting intrusion attempts to the service provider resources.
L3VPNネットワーク内のデバイスは、サービスプロバイダーのリソースに侵入の試みを報告するための何らかの手段を提供する必要があります。
The scenario for VPNs spanning multiple Autonomous Systems (AS) or Service Providers (SP) requires standard solutions. The scenario where multiple ASes are involved is the most general case and is therefore the one described here. The scenarios of concern are the CE-based and PE-based L3VPNs defined in section 3.
複数の自律システム（AS）またはサービスプロバイダー（SP）にまたがるVPNのシナリオには、標準ソリューションが必要です。複数のASEが関与するシナリオが最も一般的なケースであるため、ここで説明するシナリオです。懸念のシナリオは、セクション3で定義されているCEベースおよびPEベースのL3VPNです。
In each scenario, all applicable SP requirements, such as traffic and routing isolation, SLAs, management, security, and provisioning. MUST be preserved across adjacent ASes. The solutions MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters [VPNIW].
各シナリオでは、トラフィックやルーティングの分離、SLA、管理、セキュリティ、プロビジョニングなど、すべての適用可能なSP要件があります。隣接するASES全体に保存する必要があります。ソリューションは、SP間ネットワークインターフェイス、カプセル化方法、ルーティングプロトコル、およびすべての適用可能なパラメーター[VPNIW]を記述する必要があります。
An essential pre-condition for an inter-AS VPN is an agreement between the ASes involved that spells out at least trust, economic, and management responsibilities.
VPN間の重要な事前条件は、少なくとも信頼、経済、および管理の責任を綴る関係するASE間の合意です。
The overall scalability of the VPN service MUST allow the L3VPN service to be offered across potentially hundreds of SPs, with the overall scaling parameters per SP given in [RFC3809].
VPNサービスの全体的なスケーラビリティは、[RFC3809]に与えられたSPごとの全体的なスケーリングパラメーターを使用して、潜在的に数百のSPSでL3VPNサービスを提供できるようにする必要があります。
If the link between ASes is not trusted, routing protocols running between those ASes MUST support some form of authentication. For example, the TCP option for carrying an MD5 digest may be used to enhance security for BGP [RFC2385].
ASE間のリンクが信頼されていない場合、それらのASES間で実行されるルーティングプロトコルは、何らかの形の認証をサポートする必要があります。たとえば、MD5ダイジェストを運ぶためのTCPオプションを使用して、BGP [RFC2385]のセキュリティを強化することができます。
BGP MUST be supported as the standard inter-AS routing protocol to control the path taken by L3VPN traffic.
BGPは、L3VPNトラフィックがとるパスを制御するために、標準のASルーティングプロトコルとしてサポートする必要があります。
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities as follows:
ASESの連結に適用するためのシングルを管理するための一般的な要件。次のような機能の最小サブセット：
- Diagnostic tools (e.g., ping, traceroute) - Secured access to one AS management system by another - Configuration request and status query tools - Fault notification and trouble-tracking tools
- 診断ツール（例：Ping、Traceroute） - 別の管理システムとしての1つの管理システムへのアクセスの保護 - 構成要求とステータスクエリツール - 障害通知とトラブル追跡ツール
When a VPN spans multiple ASes, a brokering mechanism is desired that requests certain SLA parameters, such as bandwidth and QoS, from the other domains and/or networks involved in transferring traffic to various sites. Although bandwidth and QoS brokering across multiple ASes is not common in today's networks, these may be desirable for maintaining SLAs in inter-AS VPNs. This section describes requirements for features that would facilitate these mechanisms. The objective is that a solution SHOULD be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of an L3VPN.
VPNが複数のASEに及ぶ場合、トラフィックをさまざまなサイトに転送することに関与する他のドメインやネットワークから、帯域幅やQOSなどの特定のSLAパラメーターを要求するブローカーメカニズムが望まれます。今日のネットワークでは、複数のASEにわたって帯域幅とQoSブローカーが一般的ではありませんが、これらはVPNとのSLAを維持するために望ましい場合があります。このセクションでは、これらのメカニズムを促進する機能の要件について説明します。目的は、ASESのセットがL3VPNをサポートする均一なQoSを確立および保証できるかどうかを判断できるはずです。
The brokering mechanism can be a manual one, for example, in which one provider requests from another a specific set of bandwidth and QoS parameters for traffic going to and from a specific set of sites. The mechanism could also be an automated one where a device dynamically requests and receives certain bandwidth and SLA/QoS parameters. For instance, in the case of an L3VPN over MPLS, a PE may negotiate the label for different traffic classes to reach a PE residing in a neighboring AS. Or, it might be a combination of both. For additional detailed requirements on the automated approach, see [TE-INTERAS].
ブローカーメカニズムは、たとえば、あるプロバイダーが別のプロバイダーから特定のサイトに出入りするトラフィックの帯域幅とQoSパラメーターの特定のセットを要求するマニュアルのメカニズムにすることができます。このメカニズムは、デバイスが特定の帯域幅とSLA/QoSパラメーターを動的に要求および受信する自動化されたものでもあります。たとえば、MPLS上のL3VPNの場合、PEは、さまざまなトラフィッククラスのラベルを交渉して、隣接するASに居住するPEに到達する場合があります。または、それは両方の組み合わせかもしれません。自動化されたアプローチに関する詳細な要件については、[Te-interas]を参照してください。
Brokering on a per VPN basis is not desirable as this approach would not scale. A solution MUST provide some means to aggregate QoS and bandwidth brokering requests between ASes. One method could be for SPs to make an agreement specifying the maximum amount of bandwidth for specific QoS parameters for all VPN customers using the SP network. Alternatively, such aggregation might be on a per hierarchical tunnel basis between PE routers in different ASes supporting an L3VPN service [TE-INTERAS].
このアプローチが拡大しないため、VPNごとのブローカーは望ましくありません。ソリューションは、ASE間のQoSと帯域幅のブローカー要求を集約するための何らかの手段を提供する必要があります。1つの方法は、SPSがSPネットワークを使用してすべてのVPN顧客の特定のQoSパラメーターの帯域幅の最大量を指定する合意を作成することです。あるいは、このような集約は、L3VPNサービス[Te-interas]をサポートするさまざまなASEのPEルーター間の階層的トンネルごとのトンネルベースに基づいている可能性があります。
If a tunnel traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. These security mechanisms include encryption, authentication, and resource protection, as described in section 6.9, and security management, as covered in section 7.5. For example, a provider should consider using both authentication and encryption for a tunnel used as part of an L3VPN that traverses another service provider's network.
トンネルが複数のSPネットワークを通過し、無担保のSP、POP、NAP、またはIXを通過する場合、セキュリティメカニズムを使用する必要があります。これらのセキュリティメカニズムには、セクション6.9で説明されているように、暗号化、認証、およびリソース保護、およびセクション7.5で説明されているセキュリティ管理が含まれます。たとえば、プロバイダーは、別のサービスプロバイダーのネットワークを通過するL3VPNの一部として使用されるトンネルに認証と暗号化の両方を使用することを検討する必要があります。
The architecture MUST support the possibility of one service provider offering VPN service to another service provider. Another example is when one service provider sells L3VPN service at wholesale to another service provider, who then resells that VPN service to his or her customers.
アーキテクチャは、あるサービスプロバイダーが別のサービスプロバイダーにVPNサービスを提供する可能性をサポートする必要があります。別の例は、あるサービスプロバイダーが卸売でL3VPNサービスを別のサービスプロバイダーに販売し、その後、そのVPNサービスを顧客に再販する場合です。
The wholesaler's VPN MUST be transparent to the addressing and routing used by the reseller.
卸売業者のVPNは、再販業者が使用するアドレス指定とルーティングに対して透過的でなければなりません。
Support for additional levels of hierarchy (for example, three levels at which a reseller can again resell the VPN service to yet another VPN provider) SHOULD be provided.
追加の階層レベルのサポート（たとえば、再販業者が再びVPNサービスをさらに別のVPNプロバイダーに再販できる3つのレベル）を提供する必要があります。
The Carrier's Carrier scenario is the term used in this document for this category of L3VPN wholesale (although some scenarios of Inter- AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale category, too). Various carrier's carrier scenarios should be supported, such as when
キャリアのキャリアシナリオは、このドキュメントでこのドキュメントで使用されているこのカテゴリのL3VPN卸売の用語です（ただし、AS/Provider VPNのいくつかのシナリオは、このL3VPN卸売カテゴリにも低下する可能性があります）。さまざまなキャリアのキャリアシナリオをサポートする必要があります。
- the customer carriers do not operate L3VPN services for their clients; - the customer carriers operate L3VPN services for their clients, but these services are not linked with the L3VPN service offered by the Carrier's Carrier and - the customer carriers operate L3VPN services for their clients, and these services are linked with the L3VPN service offered by the Carrier's Carrier ("Hierarchical VPNs" scenario).
- 顧客キャリアは、クライアントのL3VPNサービスを運営していません。 - 顧客キャリアはクライアントのためにL3VPNサービスを運営していますが、これらのサービスは、キャリアのキャリアが提供するL3VPNサービスとリンクしていません。キャリアのキャリア（「階層VPNS」シナリオ）。
Connectivity between CE sites or PE devices in the backbone SHOULD use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-in-IP, and MPLS.
バックボーン内のCEサイトまたはPEデバイス間の接続は、L2TP、IPSEC、GRE、IP-in-IP、MPLなどのトンネルテクノロジーの範囲を使用する必要があります。
To set up tunnels between routers, every router MUST support static configuration for tunneling and MAY support a tunnel setup protocol. If employed, a tunnel establishment protocol SHOULD be capable of conveying information such as the following:
ルーター間にトンネルをセットアップするには、すべてのルーターがトンネリングの静的構成をサポートし、トンネルセットアッププロトコルをサポートする必要があります。雇用されている場合、トンネル設立プロトコルは、次のような情報を伝えることができる必要があります。
- Relevant identifiers - QoS/SLA parameters - Restoration parameters - Multiplexing identifiers - Security parameters
- 関連する識別子 - QOS/SLAパラメーター - 復元パラメーター - 多重化識別子 - セキュリティパラメーター
There MUST be a means to monitor the following aspects of tunnels:
トンネルの次の側面を監視する手段が必要です。
- Statistics, such as amount of time spent in the up and down state. - Count of transitions between the up and down state. - Events, such as transitions between the up and down states.
- 上下状態で費やされる時間などの統計。 - 上下状態の間の移行のカウント。 - 上下状態間の遷移などのイベント。
The tunneling technology used by the VPN Service Provider and its associated mechanisms for tunnel establishment, multiplexing, and maintenance MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc.
VPNサービスプロバイダーが使用するトンネルテクノロジーと、トンネルの確立、多重化、およびメンテナンスに関連するメカニズムは、スケーリング、分離、セキュリティ、QoS、管理可能性などの要件を満たす必要があります。
This section describes requirements for aspects of access and backbone network technologies from an SP point of view.
このセクションでは、SPの観点からアクセスおよびバックボーンネットワークテクノロジーの側面に関する要件について説明します。
Some SPs MAY desire that a single network infrastructure suffices for all services, public IP, VPNs, traffic engineering, and differentiated services [L2VPN].
一部のSPSは、すべてのサービス、パブリックIP、VPN、トラフィックエンジニアリング、差別化されたサービス[L2VPN]に単一のネットワークインフラストラクチャで十分であることを望む場合があります。
Ideally, the L3VPN service SHOULD be independent of physical, link layer, or even network technology of the access network. However, the characteristics of access networks MUST be accounted for when the QoS aspects of SLAs for VPN service offerings are specified.
理想的には、L3VPNサービスは、アクセスネットワークの物理的、リンク層、またはネットワークテクノロジーからも独立している必要があります。ただし、VPNサービス提供のSLAのQoS側面が指定されている場合、アクセスネットワークの特性を考慮する必要があります。
Service providers SHOULD be able to support temporary user access, as described in section 5.11.2, by using dedicated or dial-in access network technology.
サービスプロバイダーは、専用またはダイヤルインアクセスネットワークテクノロジーを使用して、セクション5.11.2で説明するように、一時的なユーザーアクセスをサポートできる必要があります。
L3VPN solutions MUST support the case where a VPN user directly accesses the VPN service through an access network connected to the service provider. They MUST also describe how they can support the case where one or more other service provider networks are used for access to the service provider supporting the L3VPN service.
L3VPNソリューションは、VPNユーザーがサービスプロバイダーに接続されたアクセスネットワークを介してVPNサービスに直接アクセスする場合をサポートする必要があります。また、L3VPNサービスをサポートするサービスプロバイダーにアクセスするために、他の1つ以上のサービスプロバイダーネットワークが使用される場合をどのようにサポートできるかを説明する必要があります。
Ideally, all information necessary to identify and authenticate users for an intranet SHOULD be stored and maintained by the customer. In an extranet, one customer SHOULD be able to maintain the authentication server, or the customers involved in the extranet MAY choose to outsource the function to a service provider.
理想的には、イントラネットのユーザーを識別および認証するために必要なすべての情報は、顧客が保存および維持する必要があります。エクストラネットでは、1人の顧客が認証サーバーを維持できる必要があります。または、エクストラネットに関与する顧客は、サービスをサービスプロバイダーに外注することを選択できます。
Identification and authentication information could be made available to the service provider for controlling access, or the service provider may query a customer maintained server. Furthermore, one SP may act as access for the SP providing the VPN service. If the access SP performs identification and authentication on behalf of the VPN SP, an agreement MUST be reached on a common specification.
アクセスを制御するためにサービスプロバイダーが識別と認証情報を利用できるようにするか、サービスプロバイダーが顧客に維持されたサーバーを照会することができます。さらに、1つのSPは、VPNサービスを提供するSPのアクセスとして機能する場合があります。アクセスSPがVPN SPに代わって識別と認証を実行する場合、共通の仕様で契約に達する必要があります。
Support for at least the following authentication protocols SHALL be supported: PAP, CHAP, and EAP, as they are currently used in a wide range of equipment and services.
少なくとも次の認証プロトコルのサポートは、現在幅広い機器とサービスで使用されているため、PAP、Chap、およびEAPのサポートをサポートするものとします。
Ideally, the backbone interconnecting SP, PE, and P devices SHOULD be independent of physical and link layer technology. Nevertheless, the characteristics of backbone technology MUST be taken into account when specifying the QoS aspects of SLAs for VPN service offerings.
理想的には、SP、PE、およびPデバイスを相互接続するバックボーン相互接続は、物理レイヤーテクノロジーとリンク層技術とは無関係でなければなりません。それにもかかわらず、VPNサービス製品のSLAのQoS側面を指定する際には、バックボーン技術の特性を考慮する必要があります。
When primary and secondary access connections are available, an L3VPN solution MUST provide restoration of access connectivity whenever the primary access link from a CE site to a PE fails. This capability SHOULD be as automatic as possible, that is, the traffic should be directed over the secondary link soon after failure of the primary access link is detected. Furthermore, reversion to the primary link SHOULD be dynamic, if configured to do so [VPN-NEEDS].
プライマリおよびセカンダリアクセス接続が利用可能な場合、L3VPNソリューションは、CEサイトからPEへのプライマリアクセスリンクが失敗するたびに、アクセス接続の復元を提供する必要があります。この機能は、可能な限り自動である必要があります。つまり、プライマリアクセスリンクの故障が検出された直後に、トラフィックをセカンダリリンク上に向ける必要があります。さらに、[VPN-Needs]を設定する場合、プライマリリンクへの逆転は動的でなければなりません。
As mentioned in section 5.11.4, in the case of multi-homing, the load balancing capability MAY be used to achieve a degree of redundancy in the network. In the case of failure of one or more (but not all) of the multi-homed links, the load balancing parameters MAY be dynamically adjusted to redirect the traffic rapidly from the failed link(s) to the surviving links. Once the failed link(s) is (are) restored, the original provisioned load balancing ratio SHOULD be restored to its value prior to the failure.
セクション5.11.4で述べたように、マルチホミングの場合、負荷分散機能を使用して、ネットワークである程度の冗長性を実現できます。マルチホームリンクの1つ以上（すべてではない）が失敗した場合、負荷分散パラメーターを動的に調整して、故障したリンクから存続したリンクにトラフィックを迅速にリダイレクトすることができます。失敗したリンクが復元されたら、障害の前に元のプロビジョニング済み負荷分散比をその値に復元する必要があります。
An SP SHOULD be able to deploy protection and restoration mechanisms within his or her backbone infrastructure to increase reliability and fault tolerance of the VPN service offering. These techniques SHOULD be scalable, and therefore should strive not to perform such function in the backbone on a per-VPN basis.
SPは、VPNサービス提供の信頼性と断層許容度を高めるために、バックボーンインフラストラクチャ内に保護および修復メカニズムを展開できる必要があります。これらの手法はスケーラブルである必要があるため、VPNごとにバックボーンでそのような機能を実行しないように努力する必要があります。
Appropriate measurements and alarms that indicate how well network protection and restoration mechanisms are performing MUST be supported.
ネットワーク保護と回復メカニズムが実行されていることを示す適切な測定とアラームをサポートする必要があります。
Service providers are interested in interoperability in at least the following scenarios:
サービスプロバイダーは、少なくとも次のシナリオで相互運用性に関心があります。
- Facilitating use of PE and managed CE devices within a single SP network. - Implementing L3VPN services across two or more interconnected SP networks.
- 単一のSPネットワーク内のPEおよび管理されたCEデバイスの使用を促進します。-2つ以上の相互接続されたSPネットワークにL3VPNサービスを実装します。
- Achieving interworking or interconnection between customer sites using different L3VPN approaches or different implementations of the same approach.
- 異なるL3VPNアプローチまたは同じアプローチの異なる実装を使用して、顧客サイト間の相互作用または相互接続を達成します。
Each approach MUST describe whether any of the above objectives can be met. If an objective can be met, the approach MUST describe how such interoperability could be achieved. In particular, the approach MUST describe the inter-solution network interface, encapsulation method(s), routing protocol(s), security, isolation, management, and all other applicable aspects of the overall VPN solution provided [VPNIW].
各アプローチは、上記の目的のいずれかを満たすことができるかどうかを説明する必要があります。目的を満たすことができる場合、アプローチはそのような相互運用性をどのように達成できるかを説明する必要があります。特に、アプローチは、ソリューション間ネットワークインターフェイス、カプセル化方法、ルーティングプロトコル、セキュリティ、分離、管理、および提供された全体的なVPNソリューションの他のすべての適用される側面を説明する必要があります[VPNIW]。
Service providers MUST have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis to an L3VPN approach.
サービスプロバイダーは、L3VPNアプローチにサイトごとにサービスの中断を最小限に抑えて顧客を移行するための優雅な手段を持っている必要があります。
If L3VPN approaches can interwork or interconnect, then service providers MUST have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis whenever interworking or interconnection is changed.
L3VPNアプローチがインターワークまたは相互接続できる場合、サービスプロバイダーは、インターワーキングまたは相互接続が変更されるたびに、サイトごとにサービスの中断を最小限に抑えて顧客を移行するための優雅な手段を持たなければなりません。
A service provider MUST have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. Furthermore, an SP 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に関連付けられたトポロジ、運用状態、注文ステータス、およびその他のパラメーターを表示する手段が必要です。さらに、SPには、VPNサービスを顧客に提供する機器に関連する基礎となる論理的および物理的トポロジ、運用状態、プロビジョニングステータス、およびその他のパラメーターを表示する手段が必要です。
Currently, proprietary methods are often used to manage VPNs. The additional expense associated with operators using multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. Therefore, devices SHOULD provide standards-based interfaces wherever feasible.
現在、独自の方法は、VPNを管理するためによく使用されています。そのようなシステムにアクセスするために複数の独自の管理方法（コマンドラインインターフェイス（CLI）言語など）を使用したオペレーターに関連する追加費用は望ましくありません。したがって、デバイスは、実行可能な場所に標準ベースのインターフェイスを提供する必要があります。
The remainder of this section presents detailed SP management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. Much of this text was adapted from ITU-T Y.1311.1.
このセクションの残りの部分では、従来の障害、構成、会計、パフォーマンス、セキュリティ（FCAPS）管理カテゴリにおけるネットワーク管理システム（NMS）の詳細なSP管理要件を示しています。このテキストの多くは、itu-t y.1311.1から採用されました。
Support for fault management includes:
障害管理のサポートには以下が含まれます。
- indication of customers impacted by failure, - fault detection (incidents reports, alarms and failure visualization), - fault localization (analysis of alarms reports and diagnostics), - incident recording or logs (creation and follow-through of trouble tickets), and - corrective actions (traffic, routing, and resource allocation).
- 障害の影響を受けた顧客の兆候、障害検出（インシデントレポート、アラーム、障害の視覚化）、障害のローカリゼーション（アラームレポートと診断の分析）、インシデント記録またはログ（トラブルチケットの作成とフォロースルー）、および - 是正措置（トラフィック、ルーティング、リソース割り当て）。
As PE-based VPNs rely on a common network infrastructure, the NMS MUST provide a means to inform the provider of the VPN customers impacted by a failure in the infrastructure. The NMS SHOULD provide pointers to the related customer configuration information to aid in fault isolation and determining corrective action.
PEベースのVPNは共通のネットワークインフラストラクチャに依存しているため、NMSは、インフラストラクチャの障害の影響を受けたVPN顧客をプロバイダーに通知する手段を提供する必要があります。NMSは、関連する顧客構成情報へのポインターを提供して、障害の分離と是正措置の決定を支援する必要があります。
Detecting faults caused by configuration errors is desirable, because these may cause VPN service failure or may disrupt other requirements (e.g., traffic and routing isolation). This is a likely case of compromised security [VPNSEC]. Detection of such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. One approach could be a protocol that systematically checks whether all constraints and consistency checks hold among tunnel configuration parameters at the various end points.
構成エラーによって引き起こされる障害の検出が望ましいです。これは、VPNサービスの障害を引き起こす可能性があるか、他の要件（トラフィックやルーティングの分離など）を破壊する可能性があるためです。これは、セキュリティが侵害された可能性のあるケース[VPNSEC]です。問題には複数のノードが含まれ、グローバルな視点に及ぶ可能性があるため、このようなエラーの検出は本質的に困難です。1つのアプローチは、さまざまなエンドポイントでトンネル構成パラメーター間ですべての制約と一貫性チェックが当てはまるかどうかを体系的にチェックするプロトコルです。
A capability to verify L3 reachability within a VPN MUST be provided for diagnostic purposes.
VPN内のL3の到達可能性を検証する機能を診断目的で提供する必要があります。
A capability to verify the parameter configuration of a device supporting an L3VPN MUST be provided for diagnostic purposes.
L3VPNをサポートするデバイスのパラメーター構成を検証する機能を診断目的で提供する必要があります。
Overall, the NMS must support a configuration necessary to realize the desired L3-reachability of an L3VPN. Toward this end, an NMS MUST provide configuration management to provision at least the following L3VPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option MUST also be configurable.
全体として、NMSは、L3VPNの望ましいL3測定可能性を実現するために必要な構成をサポートする必要があります。この目的に向けて、NMSは、このセクションで詳述されているように、少なくとも次のL3VPNコンポーネントをプロビジョニングするために、少なくとも次のL3VPNコンポーネントを提供するための構成管理を提供する必要があります。インターネットへの共有アクセスが提供されている場合、このオプションも設定可能でなければなりません。
As VPN configuration and topology are highly dependent on a customer's organization, provisioning systems MUST address a broad range of customer-specific requirements. The NMS MUST ensure that these devices and protocols are provisioned consistently and correctly.
VPNの構成とトポロジーは顧客の組織に大きく依存しているため、プロビジョニングシステムは幅広い顧客固有の要件に対処する必要があります。NMSは、これらのデバイスとプロトコルが一貫して正しくプロビジョニングされることを確認する必要があります。
Provisioning for adding or removing sites SHOULD be as localized and automated as possible.
サイトを追加または削除するためのプロビジョニングは、可能な限りローカライズされ、自動化する必要があります。
Configuration management for VPNs, according to service templates defined by the provider MUST be supported. A service template contains fields that, when used, yield a definite service requirement or policy. For example, a template for an IPSec tunnel would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, pre-shared keys (if any), and traffic filters. An SLA template would contain fields such as delay, jitter, and throughput and packet loss thresholds, as well as end points over which the SLA has to be satisfied. In general, a customer's service order can be regarded as a set of instantiated service templates. This set can, in turn, be regarded as the logical service architecture of the customer's VPN.
プロバイダーによって定義されたサービステンプレートに従って、VPNの構成管理をサポートする必要があります。サービステンプレートには、使用すると明確なサービス要件またはポリシーが得られるフィールドが含まれています。たとえば、IPSECトンネルのテンプレートには、トンネルエンドポイント、認証モード、暗号化と認証アルゴリズム、事前共有キー（もしあれば）、トラフィックフィルターなどのフィールドが含まれます。SLAテンプレートには、遅延、ジッター、スループットおよびパケット損失のしきい値などのフィールドと、SLAが満たさなければならないエンドポイントが含まれます。一般に、顧客のサービス注文は、インスタンス化されたサービステンプレートのセットと見なすことができます。このセットは、顧客のVPNの論理サービスアーキテクチャと見なすことができます。
Service templates can also be used by the provider to define the service architecture of the provider's own network. For example, OSPF templates could contain fields such as the subnets that form a particular area, the area identifier, and the area type. BGP service template could contain fields that, when used, would yield a BGP policy, such as for expressing a preference about an exit router for a particular destination.
サービステンプレートは、プロバイダーがプロバイダー自身のネットワークのサービスアーキテクチャを定義するために使用することもできます。たとえば、OSPFテンプレートには、特定の領域を形成するサブネット、領域識別子、エリアタイプなどのフィールドを含めることができます。BGPサービステンプレートには、使用すると、特定の宛先の出口ルーターに関する好みを表現するなど、BGPポリシーが生成されるフィールドが含まれています。
The set of service templates SHOULD be comprehensive in that it can capture all service orders in some meaningful sense.
サービステンプレートのセットは、何らかの意味のある意味ですべてのサービス注文をキャプチャできるという点で包括的である必要があります。
The provider SHOULD provide means to translate service templates into device configurations so that associated services can be provisioned.
プロバイダーは、関連するサービスをプロビジョニングできるように、サービステンプレートをデバイス構成に変換する手段を提供する必要があります。
Finally, the approach SHOULD provide means to check whether a service order is correctly provisioned. This would represent one method of diagnosing configuration errors. Configuration errors can arise due to a variety of reasons: manual configuration, intruder attacks, and conflicting service requirements.
最後に、このアプローチは、サービス注文が正しくプロビジョニングされているかどうかを確認する手段を提供する必要があります。これは、構成エラーの診断の1つの方法を表します。構成エラーは、手動の構成、侵入者攻撃、競合するサービス要件など、さまざまな理由により発生する可能性があります。
Requirements for configuration management unique to a PE-based VPN are as follows:
PEベースのVPNに固有の構成管理の要件は次のとおりです。
o The NMS MUST support configuration of at least the following aspects of L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, and tunnels.
o NMSは、L3 PEルーターの少なくとも以下の側面の構成をサポートする必要があります：イントラネットおよびエクストラネットメンバーシップ、各アクセス接続のCEルーティングプロトコル、ルーティングメトリック、トンネル。
o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs, hierarchical tunnels, and access connections, as described in section 6.3.
o NMSは、セクション6.3で説明されているように、SPS、L3VPN、PES、CES、階層トンネル、およびアクセス接続の識別子を使用する必要があります。
o Tunnels MUST be configured between PE and P devices. This requires coordination of identifiers of tunnels, hierarchical tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
o トンネルは、PEデバイスとPデバイス間で構成する必要があります。これには、トンネル、階層トンネル、VPN、および関連するサービス情報の識別子の調整が必要です。たとえば、QoS/SLAサービス。
o Routing protocols running between PE routers and CE devices MUST be configured per VPN.
o PEルーターとCEデバイス間で実行されるルーティングプロトコルは、VPNごとに構成する必要があります。
o For multicast service, multicast routing protocols MUST also be configurable.
o マルチキャストサービスの場合、マルチキャストルーティングプロトコルも設定可能でなければなりません。
o Routing protocols running between PE routers and between PE and P routers MUST also be configured.
o PEルーター間とPEとPルーターの間で実行されるルーティングプロトコルも構成する必要があります。
o The configuration of a PE-based L3VPN MUST be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks interconnecting components of an L3VPN.
o PEベースのL3VPNの構成は、L3VPNのコンポーネントを相互接続するレイヤー1および2ネットワークを含む、基礎となるインフラストラクチャの構成と調整する必要があります。
Requirements for configuration management unique to a CE-based VPN are as follows:
CEベースのVPNに固有の構成管理の要件は次のとおりです。
o Tunnels MUST be configured between CE devices. This requires coordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
o トンネルはCEデバイス間で構成する必要があります。これには、トンネル、VPN、および関連するサービス情報、たとえばQOS/SLAサービスの識別子の調整が必要です。
o Routing protocols running between PE routers and CE devices MUST be configured. For multicast service, multicast routing protocols MUST also be configurable.
o PEルーターとCEデバイス間で実行されるルーティングプロトコルを構成する必要があります。マルチキャストサービスの場合、マルチキャストルーティングプロトコルも設定可能でなければなりません。
A means for a service provider to provision parameters for the IGP for an L3VPN MUST be provided. This includes link level metrics, capacity, QoS capability, and restoration parameters.
サービスプロバイダーがL3VPNのIGPのパラメーターを提供する手段を提供する必要があります。これには、リンクレベルのメトリック、容量、QoS機能、および復元パラメーターが含まれます。
A service provider MUST have the means to provision network access between SP-managed PE and CE, as well as the case where the customer manages the CE.
サービスプロバイダーには、SPが管理したPEとCEの間にネットワークアクセスを提供する手段と、顧客がCEを管理する場合が必要です。
When a security service is requested, an SP MUST have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE or the PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis.
セキュリティサービスが要求された場合、SPにはサービスに関係するエンティティと関連するパラメーターを提供する手段が必要です。たとえば、IPSECサービスの場合、トンネル、オプション、キー、およびその他のパラメーターは、CEまたはPEでプロビジョニングする必要があります。侵入検知サービスの場合、フィルタリングおよび検出ルールはVPNベースでプロビジョニングする必要があります。
A service provider MUST have a means to provision resources associated with VPN services dynamically. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable.
サービスプロバイダーには、VPNサービスに関連するリソースを動的に提供する手段が必要です。たとえば、PEベースのサービスでは、仮想スイッチングおよび転送テーブルインスタンスの数とサイズは提供可能でなければなりません。
Dynamic VPN resource assignment is crucial for coping with the frequent change requests from customers (e.g., sites joining or leaving a VPN), as well as for achieving scalability. The PEs SHOULD be able to dynamically assign the VPN resources dynamically. This capability is especially important for dial and wireless VPN services.
動的なVPNリソースの割り当ては、顧客からの頻繁な変更要求に対処するために重要です（たとえば、VPNに参加または離れるサイトなど）、およびスケーラビリティを達成するためには重要です。PESは、VPNリソースを動的に動的に割り当てることができるはずです。この機能は、ダイヤルおよびワイヤレスVPNサービスにとって特に重要です。
If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system MUST be able to make requested changes within the ranges and bounds specified in the SLA. Examples of SLA parameters are response time and probability of being able to service such a request.
SPが「動的帯域幅管理」サービスをサポートする場合、プロビジョニングシステムは、SLAで指定された範囲と境界内で要求された変更を行うことができなければなりません。SLAパラメーターの例は、応答時間とそのような要求に対応できる確率です。
An L3VPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services. (for example, Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, and backup). It is outside of the scope of this document to define whether and how these different services interact with the VPN to solve issues such as addressing, integrity, and security. However, the VPN service MUST be able to provide access to these various types of value-added services.
L3VPNサービスは、共通のバックボーンを介した一連のサイト間で制御されたアクセスを提供します。ただし、多くのサービスプロバイダーは、さまざまな付加価値サービスも提供しています。（たとえば、インターネットアクセス、ファイアウォールサービス、侵入保護、IPテレフォニーおよびIP Centrex、アプリケーションホスティング、バックアップ）。これらの異なるサービスがVPNと相互作用して、アドレス指定、整合性、セキュリティなどの問題を解決するかどうか、どのように相互作用するかを定義するのは、このドキュメントの範囲外です。ただし、VPNサービスは、これらのさまざまな種類の付加価値サービスへのアクセスを提供できる必要があります。
A VPN service SHOULD allow the SP to supply the customer with different kinds of standard IP services, such as DNS, NTP, and RADIUS, that are needed for ordinary network operation and management. The provider SHOULD be able to provide IP services to multiple VPN customers.
VPNサービスでは、SPが通常のネットワークの操作と管理に必要なDNS、NTP、RADIUSなどのさまざまな種類の標準IPサービスを顧客に提供できるようにする必要があります。プロバイダーは、複数のVPN顧客にIPサービスを提供できるはずです。
A firewall function MAY be required to restrict access to the L3VPN from the Internet [Y.1311].
インターネットからL3VPNへのアクセスを制限するには、ファイアウォール機能が必要になる場合があります[Y.1311]。
A managed firewall service MUST be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Managed firewall services that may be provided include dropping specified protocol types, intrusion protection, and traffic-rate limiting against malicious attacks.
マネージドファイアウォールサービスは、キャリアグレードでなければなりません。冗長性と障害回復のために、ファイアウォールのフェールオーバーの手段を提供する必要があります。提供される可能性のある管理されたファイアウォールサービスには、指定されたプロトコルタイプ、侵入保護、および悪意のある攻撃に対するトラフィックレートの制限が含まれます。
Managed firewalls MUST be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device (e.g., in a PE-based solution). Managed firewalls SHOULD be provided at the major access point(s) for the L3VPN. Managed firewall services may be embedded in CE or PE device or implemented in standalone devices.
マネージドファイアウォールは、VPNごとにサポートする必要がありますが、複数のVPNは同じ物理デバイス（PEベースのソリューションなど）によってサポートされる場合があります。管理されたファイアウォールは、L3VPNの主要なアクセスポイントで提供する必要があります。管理されたファイアウォールサービスは、CEまたはPEデバイスに組み込まれているか、スタンドアロンデバイスに実装されている場合があります。
The NMS SHOULD allow a customer to outsource the management of an IP networking service to the SP providing the VPN or to a third party.
NMSは、顧客がVPNまたはサードパーティを提供するSPにIPネットワーキングサービスの管理を外部委託できるようにする必要があります。
The NMS SHOULD support collection of information necessary for optimal allocation of IP services in response to customer orders.
NMSは、顧客の注文に応じてIPサービスの最適な割り当てに必要な情報の収集をサポートする必要があります。
Reachability to and from the Internet to sites within a VPN MUST be configurable by an SP. This could be controlled by configuring routing policy to control distribution of VPN routes advertised to the Internet.
インターネットとVPN内のサイトへの到達可能性は、SPによって構成可能でなければなりません。これは、インターネットに宣伝されているVPNルートの配布を制御するためにルーティングポリシーを構成することで制御できます。
Configuration of interworking or interconnection between L3VPN solutions SHOULD be also supported. Ensuring that security and end-to-end QoS issues are provided consistently SHOULD be addressed.
L3VPNソリューション間のインターワーキングまたは相互接続の構成もサポートする必要があります。セキュリティとエンドツーエンドのQOSの問題が一貫して提供されるようにすることを保証する必要があります。
Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS MAY need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time when the SLS is not met.
多くのサービスプロバイダーは、会計目的でリソース使用に関する測定の収集を必要とします。NMSは、SLSが満たされていない期間SLAの規定を考慮した請求を作成するために、会計情報をパフォーマンスおよび障害管理情報と相関させる必要がある場合があります。
An L3VPN solution MUST describe how the following accounting functions can be provided:
L3VPNソリューションは、以下の会計機能をどのように提供できるかを説明する必要があります。
- Measurements of resource utilization. - collection of accounting information. - storage and administration of measurements.
- リソース利用の測定。 - 会計情報の収集。 - 測定の保管と管理。
Some providers may require near - real time reporting of measurement information and may offer this as part of a customer network management service.
一部のプロバイダーは、測定情報の近くでリアルタイムのレポートを必要とする場合があり、顧客ネットワーク管理サービスの一部としてこれを提供する場合があります。
If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts, and interval required to perform requested bandwidth allocation change(s) MUST be traceable for monitoring and accounting purposes.
SPが「動的帯域幅管理」サービスをサポートする場合、要求された帯域幅の割り当ての変更を実行するために必要な日付、時間、量、および間隔は、監視と会計目的で追跡可能でなければなりません。
Solutions should state compliance with accounting requirements, as described in section 1.7 of RFC 2975 [RFC2975].
RFC 2975 [RFC2975]のセクション1.7で説明されているように、ソリューションは会計要件に準拠する必要があります。
Performance management MUST support functions involved with monitoring and collecting performance data for devices, facilities, and services, as well as determining conformance to SLS, such as QoS and availability measurements.
パフォーマンス管理は、デバイス、施設、サービスのパフォーマンスデータの監視と収集、およびQoSや可用性測定などのSLSへの適合を決定することに伴う機能をサポートする必要があります。
Performance management SHOULD also support analysis of important aspects of an L3VPN, such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data.
パフォーマンス管理は、帯域幅の利用、応答時間、可用性、QoS統計、収集されたデータに基づく傾向など、L3VPNの重要な側面の分析もサポートする必要があります。
The NMS MUST monitor device behavior to evaluate performance metrics associated with an SLA. Different measurement techniques may be necessary depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques MAY be either intrusive or non-intrusive depending on the parameters being monitored.
NMSは、SLAに関連するパフォーマンスメトリックを評価するためにデバイスの動作を監視する必要があります。SLAが提供されるサービスに応じて、さまざまな測定技術が必要になる場合があります。サンプルサービスは、QoS、セキュリティ、マルチキャスト、および一時アクセスです。これらの手法は、監視されているパラメーターに応じて、侵入的または非邪魔になる場合があります。
The NMS MUST also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization, state of devices, and transmission facilities, as well as control of monitoring resources such as probes and remote agents at network access points used by customers and mobile users.
また、NMSは、リソース利用、デバイスの状態、送信設備など、SLAに直接関連付けられていないVPNの側面、および顧客が使用するネットワークアクセスポイントでのプローブやリモートエージェントなどの監視リソースの制御も監視する必要があります。モバイルユーザー。
The NMS SHOULD support SLAs between an SP and the various VPN customers according to the corresponding SLSes by measurement of the indicators defined within the context of the SLA, on a regular basis.
NMSは、定期的にSLAのコンテキスト内で定義されたインジケータの測定により、対応するSLSに従ってSPとさまざまなVPN顧客の間のSLAをサポートする必要があります。
The NMS SHOULD use the QoS parameter measurement definitions, techniques, and methods as defined by the IETF IP Performance Metrics (IPPM) working group for delay, loss, and delay variation.
NMSは、遅延、損失、および遅延の変動のために、IETF IPパフォーマンスメトリック（IPPM）ワーキンググループで定義されるQoSパラメーター測定定義、手法、および方法を使用する必要があります。
The NMS SHOULD support allocation and measurement of end-to-end QoS requirements to QoS parameters for one or more VPN network(s).
NMSは、1つ以上のVPNネットワークのQoSパラメーターへのエンドツーエンドQoS要件の割り当てと測定をサポートする必要があります。
Devices supporting L3VPN SLAs SHOULD have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable.
L3VPN SLAをサポートするデバイスには、インジケータとしきい値の交差アラートがあるリアルタイムパフォーマンス測定値が必要です。このようなしきい値は構成可能である必要があります。
The security management function of the NMS MUST include management features to guarantee the security of devices, access connections, and protocols within the L3VPN network(s), as well as the security of customer data and control as described in section 6.9.
NMSのセキュリティ管理機能には、L3VPNネットワーク内のデバイス、アクセス接続、およびプロトコルのセキュリティ、およびセクション6.9で説明されている顧客データと制御のセキュリティを保証するための管理機能を含める必要があります。
Resource access control determines the privileges that a user has to access particular applications and VPN network resources. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the L3VPN network unprotected. Access control capabilities protect these devices to ensure that users have access only to the resources and applications they are authorized to use.
リソースアクセス制御により、ユーザーが特定のアプリケーションとVPNネットワークリソースにアクセスする権限を決定します。このような制御がなければ、データと制御トラフィックのセキュリティのみが保護され、L3VPNネットワークを保護しないデバイスを提供します。アクセス制御機能は、これらのデバイスを保護して、ユーザーが使用することが許可されているリソースとアプリケーションのみにアクセスできるようにします。
In particular, access to the routing and switching resources managed by the SP MUST be tightly controlled to prevent and/or effectively mitigate a malicious attack. More detailed requirements in this area are described in [VPNSEC].
特に、SPが管理するルーティングおよびスイッチングリソースへのアクセスは、悪意のある攻撃を防止および/または効果的に緩和するために、しっかりと制御する必要があります。この分野のより詳細な要件は、[VPNSEC]で説明されています。
Authentication is the process of verifying that the sender is actually who he or she claims to be. The NMS MUST support standard methods for authenticating users attempting to access management services.
認証とは、送信者が実際に彼または彼女が主張する人であることを確認するプロセスです。NMSは、管理サービスにアクセスしようとするユーザーを認証するための標準的な方法をサポートする必要があります。
Scalability is critical, as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments MUST be manageable for large numbers of users and VPN access points.
Nomadic/Mobileクライアントの数が急速に増加しているため、スケーラビリティが重要です。このような展開に実装された認証スキームは、多数のユーザーとVPNアクセスポイントに対して管理可能でなければなりません。
Strong authentication schemes SHALL be supported to ensure the security of both VPN access point-to-VPN access point (e.g., PE to PE in a PE-based case) and client-to-VPN access point (e.g., CE-to-PE in a PE-based case) communications. This is particularly important for preventing VPN access point spoofing, a situation where an attacker tries to convince a PE or CE that the attacker is the VPN access point. If an attacker can convince a PE or CE device of this, then that device will send VPN traffic to the attacker (who could forward it to the true access point after compromising confidentiality or integrity). In other words, a non-authenticated VPN AP can be spoofed with a man-in-the-middle attack, because the endpoints never verify each other. A weakly authenticated VPN AP may be subject to such an attack. Strongly authenticated VPN APs are not subject to such attacks, because the man-in-the-middle cannot be authenticated as the real AP due to the strong authentication algorithms.
強力な認証スキームは、VPNアクセスポイントからVPNアクセスポイントのセキュリティ（PEベースのケースでのPEへのPE）とクライアント間アクセスポイント（CE-to-PEの両方のセキュリティを確保するためにサポートされなければなりません。PEベースの場合）通信。これは、攻撃者が攻撃者がVPNアクセスポイントであることをPEまたはCEに納得させようとする状況である、VPNアクセスポイントのスプーフィングを防ぐために特に重要です。攻撃者がこれをPEまたはCEデバイスに納得させることができる場合、そのデバイスはVPNトラフィックを攻撃者に送信します（機密性や整合性を損なう後、真のアクセスポイントに転送できます）。言い換えれば、エンドポイントが互いに検証しないため、無認定VPN APは中間の攻撃でスプーフィングできます。弱く認証されたVPN APは、このような攻撃の対象となる場合があります。強く認証されたVPN APは、そのような攻撃の対象ではありません。これは、強力な認証アルゴリズムのために、中間のマンを実際のAPとして認証することはできないからです。
Each L3VPN solution approach MUST specify the management information bases (MIB) modules for the network elements involved in L3VPN services. This is an essential requirement in network provisioning. The approach SHOULD identify any information not contained in a standard MIB related to FCAPS that is necessary to meet a generic requirement.
各L3VPNソリューションアプローチは、L3VPNサービスに関与するネットワーク要素の管理情報ベース（MIB）モジュールを指定する必要があります。これは、ネットワークプロビジョニングにおいて重要な要件です。このアプローチは、一般的な要件を満たすために必要なFCAPに関連する標準MIBに含まれていない情報を特定する必要があります。
An IP VPN (Policy) Information model, when available, SHOULD reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ]. This includes the QoS Policy Information Model [QPIM] and the IPSEC Configuration Policy Model [IPSECIM]. The IP VPN Information model SHOULD provide the OSS with adequate "hooks" to correlate service level specifications with traffic data collected from network elements. The use of policies includes rules that control corrective actions taken by OSS components responsible for monitoring the network and ensuring that it meets service requirements.
IP VPN（ポリシー）情報モデルは、利用可能な場合、特定のIPネットワーク機能[IM-Req]に対して並行して開発されているポリシー情報モデルを再利用する必要があります。これには、QoSポリシー情報モデル[QPIM]およびIPSEC構成ポリシーモデル[IPSECIM]が含まれます。IP VPN情報モデルは、OSSに適切な「フック」を提供して、サービスレベルの仕様をネットワーク要素から収集したトラフィックデータと相関させる必要があります。ポリシーの使用には、ネットワークの監視を担当し、サービス要件を満たすことを保証するOSSコンポーネントが取った是正措置を制御するルールが含まれます。
Additional requirements on VPN information models are given in reference [IM-PPVPN]. In particular, an information model MUST allow an SP to change VPN network dimensions with minimal influence on provisioning issues. The adopted model SHOULD be applicable to both small/medium size and large-scale L3VPN scenarios.
VPN情報モデルに関する追加要件は、参照[IM-PPVPN]に記載されています。特に、情報モデルでは、SPがプロビジョニングの問題に最小限の影響を与えるVPNネットワークディメンションを変更できるようにする必要があります。採用されたモデルは、小型/中サイズと大規模なL3VPNシナリオの両方に適用する必要があります。
Some service providers MAY require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers.
一部のサービスプロバイダーは、視覚的、聴覚的、または論理的にFCAPS情報を内部オペレーターや顧客に提示するシステムを必要とする場合があります。
Security considerations occur at several levels and dimensions within L3VPNs, as detailed within this document. This section provides a summary with references to detailed supporting information [L3VPN-SEC] [VPNSEC].
このドキュメント内で詳述されているように、セキュリティ上の考慮事項は、L3VPN内のいくつかのレベルと寸法で発生します。このセクションでは、詳細なサポート情報[L3VPN-SEC] [VPNSEC]への参照を含む要約を示します。
The requirements in this document separate traditional notions of security requirements, such as integrity, confidentiality, and authentication, from issues such as isolating (or separating) the exchange of VPN data and control traffic between specific sets of sites (as defined in sections 3.3 and 4.1). Further detail on security requirements is given from the customer and service provider perspectives in sections 5.9 and 6.9, respectively. Further detail on data and control traffic isolation requirements are given from the customer and service provider perspectives in sections 5.1 and 6.8, respectively.
このドキュメントの要件は、整合性、機密性、認証などのセキュリティ要件の従来の概念を、VPNデータの交換と特定のサイトのセット間のトラフィックの交換を分離（または分離）するなどの問題から分離します（セクション3.3およびセクションで定義されています。4.1）。セキュリティ要件に関する詳細は、それぞれセクション5.9と6.9の顧客とサービスプロバイダーの観点から提供されています。データと制御トラフィックの分離要件の詳細は、それぞれセクション5.1と6.8の顧客およびサービスプロバイダーの観点から得られます。
Furthermore, requirements regarding management of security from a service provider perspective are described in section 7.5.
さらに、サービスプロバイダーの観点からのセキュリティの管理に関する要件については、セクション7.5に記載されています。
The authors of this document would like to acknowledge the contributions from the people who launched the work on VPN requirements inside ITU-T SG13 and the authors of the original IP VPN requirements and framework document [RFC2764], as well as Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Garrec. The authors are also grateful to the helpful suggestions and direction provided by the technical advisors, Alex Zinin, Scott Bradner, Bert Wijnen, and Rob Coltun. Finally, the authors wish to acknowledge the insights and requirements gleaned from the many documents listed in the references section. Citations to these documents were made only where the authors believed that additional insight could be obtained from reading the source document.
この文書の著者は、ITU-T SG13内のVPN要件に関する作業を開始した人々と、元のIP VPN要件およびフレームワークドキュメント[RFC2764]の著者と、トム・ワースター、ロン・ボニカの著者からの貢献を認めたいと思います。、Sanjai Narain、Suzhi Suzuki、Tom Nadeau、Nail Akar、Derek Atkins、Bryan Gleeson、Greg Burns、Frederic Le Garrec。著者は、テクニカルアドバイザー、アレックス・ジニン、スコット・ブラッドナー、バート・ウィジネン、ロブ・コルトンが提供する有益な提案と方向性にも感謝しています。最後に、著者は、参照セクションにリストされている多くの文書から収集された洞察と要件を認めたいと考えています。これらのドキュメントの引用は、著者がソースドキュメントを読むことから追加の洞察を得ることができると信じていた場合にのみ行われました。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。
[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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、RFC 2685、1999年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocolラベルスイッチング（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809] Nagarajan、A。、「プロバイダープロビジョニング仮想プライベートネットワーク（PPVPN）の一般的な要件」、RFC 3809、2004年6月。
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in Progress.
[2547bis] Rosen、E.、Rekhter、Y。et al。、「BGP/MPLS VPNS」、進行中の作業。
[IM-PPVPN] Lago, P., et al., "An Information Model for Provider Provisioned Virtual Private Networks", Work in Progress.
[IM-PPVPN] Lago、P.、et al。、「プロバイダープロビジョニング仮想プライベートネットワークの情報モデル」、進行中の作業。
[IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy Information Model", Work in Progress.
[IM-Req] Iyer、M.、et al。、「IP VPNポリシー情報モデルの要件」、進行中の作業。
[IPSECIM] Jason, J., "IPsec Configuration Policy Model", Work in Progress.
[IPSECIM] Jason、J。、「IPSEC構成ポリシーモデル」、進行中の作業。
[CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress.
[ce-ppvpn] de clercq、J.、Paridaens、O.、Krywaniuk、A.、Wang、C。、「IPSECを使用してCEベースの仮想プライベートネットワークを提供するプロバイダーのアーキテクチャ」、進行中の作業。
[IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned VPNs", Work in Progress.
[IPSEC-PPVPN] GLEESON、B。、「プロバイダープロビジョニングVPNSを使用したIPSECの使用」、進行中の作業。
[L2VPN] Rosen, E., et al., "An Architecture for L2VPNs", Work in Progress.
[L2VPN] Rosen、E.、et al。、「L2VPNSのアーキテクチャ」、進行中の作業。
[MPLSSEC] Behringer, M., "Analysis of the Security of the MPLS Architecture", Work in Progress.
[MPLSSEC] Behringer、M。、「MPLSアーキテクチャのセキュリティの分析」、進行中の作業。
[PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology", Work in Progress.
[PPVPN-TERM] Andersson、L.、Madsen、T。、「PPVPN用語」、進行中の作業。
[L3VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress.
[L3VPN-SEC] Fang、L.、et al。、「プロバイダープロビジョニング仮想プライベートネットワークのセキュリティフレームワーク」、進行中の作業。
[L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress.
[L3VPN-FR] Callon、R.、Suzuki、M.、et al。「レイヤー3プロバイダーのプロビジョニング仮想プライベートネットワークのフレームワーク」が進行中です。
[PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network based IP VPN Architecture using Virtual Routers", Work in Progress.
[PPVPN-VR] Knight、P.、Oould-Brahim、H.、Gleeson、B。、「仮想ルーターを使用したネットワークベースのIP VPNアーキテクチャ」、進行中の作業。
[QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS Information Model", Work in Progress.
[QPIM] Snir、Ramberg、Strassner、Cohen、Moore、「ポリシーQoS情報モデル」、作業進行中。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764] Gleeson、B.、Lin、A.、Heinanen、J.、Armitage、G。、およびA. Malis、「IPベースの仮想プライベートネットワークのフレームワーク」、RFC 2764、2000年2月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「会計管理の紹介」、RFC 2975、2000年10月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J。、およびS。Waldbusser、「政策ベースの管理の用語」、RFC 3198、2001年11月。
[TE-INTERAS] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering requirements", Work in Progress.
[Te-Interas] Zhang、R.、Vasseur、J.P。、「MPLS as Traffic Engineering要件」、進行中の作業。
[VPNDISC] Squire, M. et al., "VPN Discovery Discussions and Options", Work in Progress.
[VPNDISC] Squire、M。et al。、「VPN Discovery Discussions and Options」、進行中の作業。
[VPNIW] Kurakami, H., et al., "Provider-Provisioned VPNs Interworking", Work in Progress.
[VPNIW] Kurakami、H.、et al。、「プロバイダーがプロビジョニングしたVPNSインターワーキング」、進行中の作業。
[VPNSEC] De Clercq, J., et al., "Considerations about possible security extensions to BGP/MPLS VPN", Work in Progress.
[VPNSEC] De Clercq、J.、et al。、「BGP/MPLS VPNに対するセキュリティ拡張の可能性に関する考慮事項」、進行中の作業。
[VPNTUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN Tunnels and Core Connectivity", Work in Progress.
[Vpntunnel] Worster、T.、et al。、「PPVPN層分離：VPNトンネルとコア接続」、進行中の作業。
[VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., "Criteria for Evaluating VPN Implementation Mechanisms", Work in Progress.
[VPN-Crit] Yu、J.、Jou、L.、Matthews、A。、Srinivasan、V。、「VPN実装メカニズムを評価するための基準」、進行中の作業。
[VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of an IP VPN service offering : a service provider perspective", Work in Progress.
[VPN-Needs] Jacquenet、C。、「IP VPNサービス提供の展開のための機能的ニーズ：サービスプロバイダーの視点」、進行中の作業。
[Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture", Y.1311.1 ITU-T Recommendation, July 2001.
[Y.1311.1] Carugi、M。（編集者）、「ネットワークベースのIP VPN over MPLSアーキテクチャ」、Y.1311.1 ITU-T推奨、2001年7月。
[Y.1311] Knightson, K. (editor), "Network based VPNs - Generic Architecture and Service Requirements", Y.1311 ITU-T Recommendation, March 2002.
[Y.1311] Knightson、K。（編集者）、「ネットワークベースのVPNS-ジェネリックアーキテクチャとサービス要件」、Y.1311 ITU -T推奨、2002年3月。
Authors' Addresses
著者のアドレス
Marco Carugi (co-editor) Nortel Networks Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE
Marco Carugi（共同編集者）Nortel Networks Parc D'Magny -Chateaufort Les Jeunes Bois -MS CTF 32B5 -Chateaufort 78928 Yvelines Cedex 9 -France
EMail: marco.carugi@nortel.com
Dave McDysan (co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA
Dave McDysan（共同編集者）MCI 22001 Loudoun County Parkway Ashburn、20147、米国
EMail: dave.mcdysan@mci.com
Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA
Luyuan Fang AT＆T 200 Laurel Ave-ルームC2-3B35ミドルタウン、ニュージャージー07748 USA
EMail: Luyuanfang@att.com
Ananth Nagarajan Juniper Networks
Ananth Nagarajan Juniperネットワーク
EMail: ananth@juniper.net
Junichi Sumimoto NTT Communications Corporation 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
Junichi sumimoto ntt Communications Corporation 3-20-2 Nishi-shinjuku、Shinjuku-ku、東京163-1421、日本
EMail: j.sumimoto@ntt.com
Rick Wilder Alcatel
リック・ワイルダー・アルカテル
EMail: rick.wilder@alcatel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。