Network Working Group R. Callon
Request for Comments: 4110 Juniper Networks
Category: Informational M. Suzuki
NTT Corporation
July 2005
A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (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).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.
この文書では、レイヤ3のプロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのフレームワークを提供します。このフレームワークは、レイヤ3 PPVPNsのサポートのためのプロトコルおよびメカニズムの標準化を補助することを意図しています。レイヤ3 PPVPNソリューションの設計において重要である重要な技術的な問題のコヒーレント記述を生成するために、このドキュメントの意図です。具体的なアプローチの選択は、エンジニアリングのトレードオフ、および詳細なプロトコル仕様に関する選択肢を作る、この枠組み文書の範囲外です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives of the Document . . . . . . . . . . . . . . . 3
1.2. Overview of Virtual Private Networks . . . . . . . . . . 4
1.3. Types of VPNs. . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. CE- vs PE-based VPNs . . . . . . . . . . . . . . 8
1.3.2. Types of PE-based VPNs . . . . . . . . . . . . . 9
1.3.3. Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
1.4. Scope of the Document. . . . . . . . . . . . . . . . . . 10
1.5. Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
2.1.1. Entities in the Reference Model. . . . . . . . . 16
2.1.2. Relationship Between CE and PE . . . . . . . . . 18
2.1.3. Interworking Model . . . . . . . . . . . . . . . 19
2.2. Reference Model for Layer 3 Provider-Provisioned
CE-based VPN . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1. Entities in the Reference Model. . . . . . . . . 22
3. Customer Interface . . . . . . . . . . . . . . . . . . . . . . 23
3.1. VPN Establishment at the Customer Interface. . . . . . . 23
3.1.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 23
3.1.1.1. Static Binding . . . . . . . . . . . . 24
3.1.1.2. Dynamic Binding. . . . . . . . . . . . 24
3.1.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 25
3.2. Data Exchange at the Customer Interface. . . . . . . . . 25
3.2.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 25
3.2.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 26
3.3. Customer Visible Routing . . . . . . . . . . . . . . . . 26
3.3.1. Customer View of Routing for Layer 3 PE-based
VPNs . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1.1. Routing for Intranets . . . . . . . . 27
3.3.1.2. Routing for Extranets . . . . . . . . 28
3.3.1.3. CE and PE Devices for Layer 3
PE-based VPNs. . . . . . . . . . . . . 29
3.3.2. Customer View of Routing for Layer 3 Provider-
Provisioned CE-based VPNs. . . . . . . . . . . . 29
3.3.3. Options for Customer Visible Routing . . . . . . 30
4. Network Interface and SP Support of VPNs . . . . . . . . . . . 32
4.1. Functional Components of a VPN . . . . . . . . . . . . . 32
4.2. VPN Establishment and Maintenance. . . . . . . . . . . . 34
4.2.1. VPN Discovery . . . . . . . . . . . . . . . . . 35
4.2.1.1. Network Management for Membership
Information. . . . . . . . . . . . . . 35
4.2.1.2. Directory Servers. . . . . . . . . . . 36
4.2.1.3. Augmented Routing for Membership
Information. . . . . . . . . . . . . . 36
4.2.1.4. VPN Discovery for Inter-SP VPNs. . . . 37
4.2.2. Constraining Distribution of VPN Routing
Information . . . . . . . . . . . . . . . . . . 38
4.2.3. Controlling VPN Topology . . . . . . . . . . . . 38
4.3. VPN Tunneling . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Tunnel Encapsulations. . . . . . . . . . . . . . 40
4.3.2. Tunnel Multiplexing. . . . . . . . . . . . . . . 41
4.3.3. Tunnel Establishment . . . . . . . . . . . . . . 42
4.3.4. Scaling and Hierarchical Tunnels . . . . . . . . 43
4.3.5. Tunnel Maintenance . . . . . . . . . . . . . . . 45
4.3.6. Survey of Tunneling Techniques . . . . . . . . . 46
4.3.6.1. GRE . . . . . . . . . . . . . . . . . 46
4.3.6.2. IP-in-IP Encapsulation . . . . . . . . 47
4.3.6.3. IPsec. . . . . . . . . . . . . . . . . 48
4.3.6.4. MPLS . . . . . . . . . . . . . . . . . 49
4.4. PE-PE Distribution of VPN Routing Information. . . . . . 51
4.4.1. Options for VPN Routing in the SP. . . . . . . . 52
4.4.2. VPN Forwarding Instances . . . . . . . . . . . . 52
4.4.3. Per-VPN Routing . . . . . . . . . . . . . . . . 53
4.4.4. Aggregated Routing Model . . . . . . . . . . . . 54
4.4.4.1. Aggregated Routing with OSPF or IS-IS. 55
4.4.4.2. Aggregated Routing with BGP. . . . . . 56
4.4.5. Scalability and Stability of Routing with Layer
3 PE-based VPNs. . . . . . . . . . . . . . . . . 59
4.5. Quality of Service, SLAs, and IP Differentiated Services 61
4.5.1. IntServ/RSVP . . . . . . . . . . . . . . . . . . 61
4.5.2. DiffServ . . . . . . . . . . . . . . . . . . . . 62
4.6. Concurrent Access to VPNs and the Internet . . . . . . . 62
4.7. Network and Customer Management of VPNs. . . . . . . . . 63
4.7.1. Network and Customer Management. . . . . . . . . 63
4.7.2. Segregated Access of VPN Information . . . . . . 64
5. Interworking Interface . . . . . . . . . . . . . . . . . . . . 66
5.1. Interworking Function. . . . . . . . . . . . . . . . . . 66
5.2. Interworking Interface . . . . . . . . . . . . . . . . . 66
5.2.1. Tunnels at the Interworking Interface. . . . . . 67
5.3. Support of Additional Services . . . . . . . . . . . . . 68
5.4. Scalability Discussion . . . . . . . . . . . . . . . . . 69
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 69
6.1. System Security. . . . . . . . . . . . . . . . . . . . . 70
6.2. Access Control . . . . . . . . . . . . . . . . . . . . . 70
6.3. Endpoint Authentication . . . . . . . . . . . . . . . . 70
6.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . 71
6.5. Confidentiality. . . . . . . . . . . . . . . . . . . . . 71
6.6. User Data and Control Data . . . . . . . . . . . . . . . 72
6.7. Security Considerations for Inter-SP VPNs . . . . . . . 72
Appendix A: Optimizations for Tunnel Forwarding. . . . . . . . . . 73
A.1. Header Lookups in the VFIs . . . . . . . . . . . . . . . 73
A.2. Penultimate Hop Popping for MPLS . . . . . . . . . . . . 73
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 74
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 75
Normative References . . . . . . . . . . . . . . . . . . . . . . . 76
Informative References . . . . . . . . . . . . . . . . . . . . . . 76
Contributors' Addresses. . . . . . . . . . . . . . . . . . . . . . 80
This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable layer 3 PPVPNs.
この文書では、レイヤ3のプロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのフレームワークを提供します。このフレームワークは、相互運用可能なレイヤ3 PPVPNsをサポートするためのプロトコルおよびメカニズムを標準化するのを助けることを意図しています。
The term "provider-provisioned VPNs" refers to Virtual Private Networks (VPNs) for which the Service Provider (SP) participates in management and provisioning of the VPN, as defined in section 1.3. There are multiple ways in which a provider can participate in managing and provisioning a VPN; therefore, there are multiple different types of PPVPNs. The framework document discusses layer 3 VPNs (as defined in section 1.3).
用語「プロバイダープロビジョニングVPNは、」セクション1.3で定義されたサービス・プロバイダ（SP）は、VPNの管理とプロビジョニングに参加するために、仮想プライベートネットワーク（VPN）を指します。プロバイダーはVPNを管理およびプロビジョニングに参加できる複数の方法があります。そのため、PPVPNsの複数の異なる種類があります。フレームワークドキュメントは（セクション1.3で定義されるように）3つのVPNの層について説明します。
First, this document provides a reference model for layer 3 PPVPNs. Then technical aspects of layer 3 PPVPN operation are discussed, first from the customer's point of view, then from the providers point of view. Specifically, this includes discussion of the technical issues which are important in the design of standards and mechanisms for the operation and support of layer 3 PPVPNs. Furthermore, technical aspects of layer 3 PPVPN interworking are clarified. Finally, security issues as they apply to layer 3 PPVPNs are addressed.
まず、この文書は、レイヤ3 PPVPNsのための参照モデルを提供します。次に、レイヤ3 PPVPN操作の技術的な側面は、ビューの提供の観点から、最初の顧客の視点から、議論されています。具体的には、レイヤ3 PPVPNsの操作とサポートのための規格とメカニズムの設計において重要な技術的な問題の議論を含んでいます。さらに、レイヤ3 PPVPNインターワーキングの技術的な側面が明らかにされています。最後に、セキュリティ上の問題は、彼らが3 PPVPNsがアドレス指定されているレイヤーに適用されます。
This document takes a "horizontal description" approach. For each technical issue, it describes multiple approaches. To specify a particular PPVPN strategy, one must choose a particular way of solving each problem, but this document does not make choices, and does not select any particular approach to support VPNs.
この文書では、「水平の説明」アプローチを採用しています。各技術的な問題については、複数のアプローチを説明しています。特定のPPVPN戦略を指定するためには、各問題を解決するための特定の方法を選択する必要がありますが、この文書では、選択をしていない、とVPNをサポートするために、特定のアプローチを選択していません。
The "vertical description" approach is taken in other documents, viz., in the documents that describe particular PPVPN solutions. Note that any specific solution will need to make choices based on SP requirements, customer needs, implementation cost, and engineering tradeoffs. Solutions will need to chose between flexibility (supporting multiple options) and conciseness (selection of specific options in order to simplify implementation and deployment). While a framework document can discuss issues and criteria which are used as input to these choices, the specific selection of a solution is outside of the scope of a framework document.
「垂直な説明」アプローチは、他の文書に取り込まれるすなわち、特定のPPVPNソリューションを記述する文書に。任意の特定のソリューションは、SPの要件、顧客のニーズ、実装コスト、およびエンジニアリングのトレードオフに基づいて選択をする必要があることに注意してください。ソリューション（実装と展開を簡素化するために特定のオプションの選択）柔軟性（複数のオプションをサポートしている）と簡潔間で選択することが必要になります。フレームワークドキュメントが問題とこれらの選択への入力として使用される基準を議論することができるが、溶液の特定の選択は、フレームワーク文書の範囲外です。
The term "Virtual Private Network" (VPN) refers to a set of communicating sites, where (a) communication between sites outside the set and sites inside the set is restricted, but (b) communication between sites in the VPN takes place over a network infrastructure that is also used by sites which are not in the VPN. The fact that the network infrastructure is shared by multiple VPNs (and possibly also by non-VPN traffic) is what distinguishes a VPN from a private network. We will refer to this shared network infrastructure as the "VPN Backbone".
用語「仮想プライベートネットワーク」（VPN）は、（a）はセット外のサイトやセット内のサイト間の通信が制限されている通信サイトの集合を意味するが、（b）はVPN内のサイト間の通信は、を介して行われますまた、VPNに含まれていないサイトで使用されたネットワークインフラストラクチャ。ネットワークインフラストラクチャは、複数のVPN（そしておそらく、非VPNトラフィックによって）によって共有されているという事実は、プライベートネットワークからVPNを区別するものです。私たちは、「VPNバックボーン」として、この共有ネットワークインフラストラクチャを参照します。
The logical structure of the VPN, such as addressing, topology, connectivity, reachability, and access control, is equivalent to part of or all of a conventional private network using private facilities [RFC2764] [VPN-2547BIS].
例えば、トポロジー、接続性、可到達性、およびアクセス制御をアドレスとしてVPNの論理構造は、一部または民間施設[RFC2764] [VPN-2547BIS]を用いた従来のプライベートネットワークの全てに相当します。
In this document, we are concerned only with the case where the shared network infrastructure (VPN backbone) is an IP and/or MPLS network. Further, we are concerned only with the case where the Service Provider's edge devices, whether at the provider edge (PE) or at the Customer Edge (CE), determine how to route VPN traffic by looking at the IP and/or MPLS headers of the packets they receive from the customer's edge devices; this is the distinguishing feature of Layer 3 VPNs.
この文書では、我々は唯一の共有ネットワークインフラストラクチャ（VPNバックボーン）は、IPおよび/またはMPLSネットワークである場合と懸念しています。さらに、我々は唯一のサービスプロバイダーのエッジデバイスは、プロバイダーエッジ（PE）で、またはカスタマーエッジ（CE）のかどうか、判断する場合に関係しているかIPおよび/またはMPLSヘッダのを見て、ルートのVPNトラフィックをします彼らは顧客のエッジデバイスから受信するパケット。これは、レイヤ3 VPNの際立った特徴です。
In some cases, one SP may offer VPN services to another SP. The former SP is known as a carrier of carriers, and the service it offers is known as "carrier of carriers" service. In this document, in cases where the customer could be either an enterprise or SP network, we will make use of the term "customer" to refer to the user of the VPN services. Similarly we will use the term "customer network" to refer to the user's network.
いくつかのケースでは、1つのSPは別のSPへのVPNサービスを提供することがあります。旧SPは、キャリアのキャリアとして知られており、それが提供するサービスは、サービス「のキャリアのキャリア」として知られています。この文書では、顧客が企業やSPのネットワークのいずれかである場合には、我々は、VPNサービスのユーザーを参照するために用語「顧客」を利用します。同様に、私たちは、ユーザのネットワークを参照するために用語「顧客ネットワーク」を使用します。
VPNs may be intranets, in which the multiple sites are under the control of a single customer administration, such as multiple sites of a single company. Alternatively, VPNs may be extranets, in which the multiple sites are controlled by administrations of different customers, such as sites corresponding to a company, its suppliers, and its customers.
VPNは、単一の企業の複数のサイトなど、複数のサイトが単一の顧客管理の制御下である、イントラネットであってもよいです。代替的に、VPNは、複数のサイトは、企業、サプライヤー、その顧客に対応する部位として、異なる顧客の投与によって制御されたエクストラネットであってもよいです。
Figure 1.1. illustrates an example network, which will be used in the discussions below. PE1 and PE2 are Provider Edge devices within an SP network. CE1, CE2, and CE3 are Customer Edge devices within a customer network. Routers r3, r4, r5, and r6 are IP routers internal to the customer sites.
図1.1。以下の議論で使用される例示的なネットワークを示す図です。 PE1とPE2は、SPネットワーク内のプロバイダーエッジデバイスです。 CE1、CE2、およびCE3は、顧客のネットワーク内のカスタマーエッジデバイスです。ルータR3、R4、R5、R6は、顧客サイトへの内部IPルータです。
............ ................. ............
. . . . . .
. +---+ +-------+ +-------+ +---+ .
. r3---| | | | | |----|CE2|---r5 .
. | | | | | | +---+ .
. |CE1|----| PE1 | | PE2 | : .
. | | | | | | +---+ .
. r4---| | | | | |----|CE3|---r6 .
. +---+ +-------+ +-------+ +---+ .
. Customer . . Service . . Customer .
. site 1 . . provider(s) . . site 2 .
............ ................. ............
Figure 1.1.: VPN interconnecting two sites.
図1.1：VPNは、2つのサイトを相互接続します。
In many cases, Provider Edge (PE) and Customer Edge (CE) devices may be either routers or LSRs.
多くの場合、プロバイダエッジ（PE）とカスタマエッジ（CE）デバイスは、ルータやLSRのいずれであってもよいです。
In this document, the Service Providers' network is an IP or MPLS network. It is desired to interconnect the customer network sites via the Service Providers' network. Some VPN solutions require that the VPN service be provided either over a single SP network, or over a small set of closely cooperating SP networks. Other VPN solutions are intended to allow VPN service to be provided over an arbitrary set of minimally cooperating SP networks (i.e., over the public Internet).
このドキュメントでは、サービスプロバイダのネットワークは、IPまたはMPLSネットワークです。サービスプロバイダのネットワークを介して顧客のネットワークサイトを相互接続することが望まれます。いくつかのVPNソリューションは、VPNサービスは、単一のSPネットワークを介した、または密接SPネットワークを協力の小さなセット上のいずれかに提供する必要があります。他のVPNソリューションは、VPNサービスが最小限協働するSPネットワーク（すなわち、公衆インターネット上）の任意のセットを介して提供されることを可能にするように意図されています。
In many cases, customer networks will make use of private IP addresses [RFC1918] or other non-unique IP address (i.e., unregistered addresses); there is no guarantee that the IP addresses used in the customer network are globally unique. The addresses used in one customer's network may overlap the addresses used in others. However, a single PE device can be used to provide VPN service to multiple customer networks, even if those customer networks have overlapping addresses. In PE-based layer 3 VPNs, the PE devices may route the VPN traffic based on the customer addresses found in the IP headers; this implies that the PE devices need to maintain a level of isolation between the packets from different customer networks. In CE-based layer 3 VPNs, the PEs do not make routing decisions based on the customer's private addresses, so this issue does not arise. For either PE or CE-based VPNs, the fact that the VPNs do not necessarily use globally unique address spaces also implies that IP packets from a customer network cannot be transmitted over the SP network in their native form. Instead, some form of encapsulation/tunneling must be used.
多くの場合、顧客のネットワークは、プライベートIPアドレス[RFC1918]または他の非固有のIPアドレス（すなわち、未登録アドレス）を利用します。顧客のネットワークで使用されるIPアドレスは、グローバルに一意である保証はありません。 1人の顧客のネットワークで使用するアドレスは、他の人に使用されているアドレスを重複していてもよいです。しかし、単一PEデバイスは、これらの顧客のネットワークが重複アドレスを持っている場合でも、複数の顧客ネットワークにVPNサービスを提供するために使用することができます。 PEベースのレイヤ3つのVPN、PEデバイスは、IPヘッダに見られる顧客のアドレスに基づいて経路VPNトラフィックを得ます;これは、PEデバイスが異なる顧客ネットワークからのパケットとの間のアイソレーションのレベルを維持する必要があることを意味します。 CEベースのレイヤ3のVPNでは、PEは、顧客のプライベートアドレスに基づいてルーティング決定をしないので、この問題は発生しません。 PEまたはCEベースのVPNのいずれかの場合は、VPNは必ずしもグローバルに一意なアドレス空間を使用していないという事実は、顧客のネットワークからIPパケットは、ネイティブ形式でSPネットワークを介して送信することができないことを意味します。代わりに、カプセル化/トンネルのいくつかのフォームを使用する必要があります。
Tunneling is also important for other reasons, such as providing isolation between different customer networks, allowing a wide range of protocols to be carried over an SP network, etc. Different QoS and security characteristics may be associated with different tunnels.
トンネリングは、そのようなプロトコルの広い範囲は、SPネットワークを介して行うことができるように、異なる顧客ネットワークとの間のアイソレーションを提供するなど、他の理由などのために異なるQoS及びセキュリティ特性が異なるトンネルに関連付けることができることも重要です。
This section describes multiple types of VPNs, and some of the engineering tradeoffs between different types. It is not up to this document to decide between different types of VPNs. Different types of VPNs may be appropriate in different situations.
このセクションでは、複数のVPNの種類、および異なる種類の間でのエンジニアリングトレードオフのいくつかを説明します。これは、VPNのさまざまな種類の間で決定するために、このドキュメント次第ではありません。 VPNのさまざまな種類の異なる状況で適切かもしれません。
There is a wide spectrum of types of possible VPNs, and it is difficult to split the types of VPNs into clearly distinguished categories.
そこの可能なVPNの種類の広いスペクトルがあり、明確に区別のカテゴリにVPNの種類を分割することは困難です。
As an example, consider a company making use of a private network, with several sites interconnected via leased lines. All routing is done via routers which are internal to the private network.
例として、専用線を経由して相互接続された複数のサイトを持つプライベートネットワークを利用して会社を、検討してください。すべてのルーティングは、プライベートネットワークの内部にあるルータを介して行われます。
At some point, the administrator of the private network might decide to replace the leased lines by ATM links (using an ATM service from an SP). Here again all IP-level routing is done between customer premises routers, and managed by the private network administrator.
ある時点で、プライベートネットワークの管理者は、ATMリンク（SPからのATMサービスを使用）により、専用線を交換することを決定するかもしれません。ここで再びすべてのIPレベルのルーティングは、顧客宅内ルータ間で行われ、プライベートネットワーク管理者によって管理されています。
In order to reduce the network management burden on the private network, the company may decide to make use of a provider-provisioned CE devices [VPN-CE]. Here the operation of the network might be unchanged, except that the CE devices would be provided by and managed by an SP.
プライベートネットワーク上のネットワーク管理の負担を軽減するために、同社は、プロバイダプロビジョニングCEデバイス[VPN-CE]を使用するように決めることができます。ここではネットワークの動作は、CEデバイスはによって提供され、SPによって管理されることを除いて、変わらないかもしれません。
The SP might decide that it is too difficult to manually configure each CE-CE link. This might lead the SP to replace the ATM links with a layer 2 VPN service between CE devices [VPN-L2]. Auto-discovery might be used to simplify configuration of links between CE devices, and an MPLS service might be used between CE devices instead of an ATM service (for example, to take advantage of the provider's high speed IP or MPLS backbone).
SPは、手動で各CE-CEリンクを設定することが非常に困難であると判断することがあります。これはCEデバイス[VPN-L2]の間にレイヤ2 VPNサービスとATMリンクを置き換えるためにSPを招くかもしれません。自動検出は、CEデバイス間のリンクの構成を簡素化するために使用されるかもしれない、とMPLSサービスは、（例えば、プロバイダの高速IPまたはMPLSバックボーンを活用するために）、CEデバイスの代わりに、ATMサービスとの間で使用される可能性があります。
After a while the SP might decide that it is too much trouble to be managing a large number of devices at the customers' premises, and might instead physically move these routers to be on the provider premises. Each edge router at the provider premises might nonetheless be dedicated to a single VPN. The operation might remain unchanged (except that links from the edge routers to other routers in the private network become MAN links instead of LAN links, and the link from the edge routers to provider core routers become LAN links instead of MAN links). The routers in question can now be considered to be provider edge routers, and the service provided by the SP has now become essentially a layer 3 VPN service.
しばらくするとSPは、それが顧客の構内に多数のデバイスを管理するためにあまりにも面倒であることを決めるかもしれませんし、代わりに物理的にプロバイダの敷地内にあることをこれらのルーターを移動することがあります。プロバイダ構内の各エッジルータは、それにもかかわらず、単一のVPN専用にされる可能性があります。操作は、（MANリンクの代わりに、LANリンクになって、プライベートネットワーク内の他のルータにエッジルータからのリンクを除き、およびプロバイダーのコアルータにエッジルータからのリンクは、LANリンクの代わりに、MANリンクになって）変わらないかもしれません。当該ルータは現在、プロバイダエッジルータであると考えることができ、SPによって提供されるサービスは、現在、基本的にレイヤ3 VPNサービスとなっています。
In order to minimize the cost of equipment, the provider might decide to replace several dedicated PE devices with a single physical router with the capability of running virtual routers (VR) [VPN-VR]. Protocol operation may remain unchanged. In this case the provider is offering a layer 3 VPN service making use of a VR capability. Note that autodiscovery might be used in a manner which is very similar to how it had been done in the layer 2 VPN case described above (for example, BGP might be used between VRs for discovery of other VRs supporting the same VPN).
機器のコストを最小限にするために、プロバイダは、仮想ルーター（VR）[VPN-VR]を実行する機能を備えた単一の物理的なルータでいくつかの専用PEデバイスを交換することを決定するかもしれません。プロトコルの動作は変わらないことがあります。この場合、プロバイダは、VR機能を利用してレイヤ3 VPNサービスを提供しています。その自動検出は、それが上述したレイヤ2 VPNの場合に行われていた方法に非常に類似している方法で使用されるかもしれない音符（例えば、BGPは、同じVPNをサポートする他のVRの発見のためのVRとの間に使用されるかもしれません）。
Finally, in order to simplify operation of routing protocols for the private network over the SP network, the provider might decide to aggregate multiple instances of routing into a single instance of BGP [VPN-2547BIS].
最後に、SPネットワークを介してプライベートネットワークのルーティングプロトコルの動作を簡単にするために、プロバイダは、BGP [VPN-2547BIS]の単一のインスタンスにルーティングの複数のインスタンスを集約することを決定するかもしれません。
In practice it is highly unlikely that any one network would actually evolve through all of these approaches at different points in time. However, this example illustrates that there is a continuum of possible approaches, and each approach is relatively similar to at least some of the other possible approaches for supporting VPN services. Some techniques (such as auto-discovery of VPN sites) may be common between multiple approaches.
実際には、いずれかのネットワークが実際に異なる時点でこれらのアプローチのすべてを進化させるということはほとんどありません。しかし、この例では、可能なアプローチの連続があることを示しており、各アプローチは、VPNサービスをサポートするための他の可能なアプローチのうちの少なくとも一部に比較的類似しています。 （このようなVPNサイトの自動検出のような）いくつかの技術は、複数のアプローチの間で共通であってもよいです。
The term "CE-based VPN" (or Customer Edge-based Virtual Private Network) refers to an approach in which the PE devices do not know anything about the routing or the addressing of the customer networks. The PE devices offer a simple IP service, and expect to receive IP packets whose headers contain only globally unique IP addresses. What makes a CE-based VPN into a Provider-Provisioned VPN is that the SP takes on the task of managing and provisioning the CE devices [VPN-CE].
用語「CEベースのVPN」（またはカスタマーエッジベースの仮想プライベートネットワーク）は、PEデバイスがルーティングや顧客ネットワークのアドレス指定については何も知らないようなアプローチを指します。 PEデバイスは、単純なIPサービスを提供し、そのヘッダのみグローバルに一意のIPアドレスを含むIPパケットを受信することを期待しています。何プロバイダープロビジョニングVPNにCEベースのVPNを作成すると、SPは、CEデバイスの管理およびプロビジョニングのタスク[VPN-CE]の上にかかることです。
In CE-based VPNs, the backbone of the customer network is a set of tunnels whose endpoints are the CE devices. Various kinds of tunnels may be used (e.g., GRE, IP-in-IP, IPsec, L2TP, MPLS), the only overall requirement being that sending a packet through the tunnel requires encapsulating it with a new IP header whose addresses are globally unique.
CEベースのVPNでは、顧客ネットワークのバックボーンは、エンドポイントのCEデバイスであり、トンネルのセットです。トンネルの各種が使用されてもよい（例えば、GRE、IPインIP、IPsecの、L2TP、MPLS）トンネルを介してパケットを送信すると、そのアドレスがグローバルに一意である新しいIPヘッダとそれをカプセル化する必要があることであるだけ全体的な要件。
For customer provisioned CE-based VPNs, provisioning and management of the tunnels is the responsibility of the customer network administration. Typically, this makes use of manual configuration of the tunnels. In this case the customer is also responsible for operation of the routing protocol between CE devices. (Note that discussion of customer provisioned CE-based VPNs is out of scope of the document).
顧客プロビジョニングCEベースのVPNの場合は、トンネルのプロビジョニングと管理は、お客様のネットワーク管理者の責任です。通常、これはトンネルの手動設定を使用しています。この場合、顧客はまた、CEデバイス間のルーティングプロトコルの動作を担当します。 （顧客プロビジョニングCEベースのVPNの議論は、文書の範囲外であることに注意してください）。
For provider-provisioned CE-based VPNs, provisioning and management of the tunnels is the responsibility of the SP. In this case the provider may also configure routing protocols on the CE devices. This implies that routing in the private network is partially under the control of the customer, and partially under the control of the SP.
プロバイダプロビジョニングCEベースのVPNの場合は、トンネルのプロビジョニングと管理は、SPの責任です。この場合、プロバイダは、CEデバイス上のルーティングプロトコルを設定してもよいです。これは、プライベートネットワークにルーティングすることは、部分的に顧客の制御の下で、部分的にSPの制御下にあることを意味します。
For CE-based VPNs (whether customer or provider-provisioned) routing in the customer network treats the tunnels as layer 2 links.
CEベースのVPN（顧客またはプロバイダプロビジョニングか）に対する顧客のネットワーク内のルーティングは、レイヤ2リンクとしてトンネルを扱います。
In a PE-based VPN (or Provider Edge-based Virtual Private Network), customer packets are carried through the SP networks in tunnels, just as they are in CE-based VPNs. However, in a PE-based VPN, the tunnel endpoints are the PE devices, and the PE devices must know how to route the customer packets, based on the IP addresses that they carry. In this case, the CE devices themselves do not have to have any special VPN capabilities, and do not even have to know that they are part of a VPN.
PEベースのVPN（またはプロバイダーエッジベースの仮想プライベートネットワーク）では、顧客のパケットは、CEベースのVPNであるのと同様に、トンネル内のSPネットワークを通じて運ばれます。しかし、PEベースのVPNで、トンネルエンドポイントは、PEデバイスであり、PEデバイスがIPに基づいて顧客のパケットは、彼らが運ぶことをどのように対処するかへのルートを知っている必要があります。この場合、CEデバイス自体は特別なVPN機能を持っている必要はありません、とさえ彼らはVPNの一部であることを知っている必要はありません。
In this document we will use the generic term "VPN Edge Device" to refer to the device, attached to both the customer network and the VPN backbone, that performs the VPN-specific functions. In the case of CE-based VPNs, the VPN Edge Device is a CE device. In the case of PE-based VPNs, the VPN Edge Device is a PE device.
この文書では、VPN-特定の機能を実行し、顧客のネットワークとVPNバックボーンの両方に接続されたデバイス、を参照するために、一般的な用語「VPNエッジデバイス」を使用します。 CEベースのVPNの場合、VPNエッジデバイスは、CEデバイスです。 PEベースのVPNの場合、VPNエッジデバイスは、PEデバイスです。
Different types of PE-based VPNs may be distinguished by the service offered.
PEベースのVPNの異なるタイプが提供されるサービスによって区別することができます。
o Layer 3 service
Oレイヤ3サービス
When a PE receives a packet from a CE, it determines how to forward the packet by considering both the packet's incoming link, and the layer 3 information in the packet's header.
PEは、CEからパケットを受信すると、パケットのヘッダ内のパケットの着信リンク、およびレイヤ3情報の両方を考慮してパケットを転送する方法を決定します。
o Layer 2 service
Oレイヤ2サービス
When a PE receives a frame from a CE, it determines how to forward the packet by considering both the packet's incoming link, and the layer 2 information in the frame header (such as FR, ATM, or MAC header). (Note that discussion of layer 2 service is out of scope of the document).
PEは、CEからのフレームを受信すると、パケットの着信リンク、及びフレームヘッダのレイヤ2情報（例えば、FR、ATM、またはMACヘッダなど）の両方を考慮してパケットを転送する方法を決定します。 （レイヤ2サービスの議論は、文書の範囲外であることに注意してください）。
A layer 3 PE-based VPN is one in which the SP takes part in IP level forwarding based on the customer network's IP address space. In general, the customer network is likely to make use of private and/or non-unique IP addresses. This implies that at least some devices in the provider network needs to understand the IP address space as used in the customer network. Typically this knowledge is limited to the PE devices which are directly attached to the customer.
レイヤ3 PEベースのVPNは、SPは、顧客ネットワークのIPアドレス空間に基づいて、IPレベルの転送に関与するものです。一般的には、顧客ネットワークは、プライベートおよび/または非一意のIPアドレスを利用する可能性があります。これは、顧客のネットワークで使用されるプロバイダ・ネットワーク内の少なくともいくつかのデバイスは、IPアドレス空間を理解する必要があることを意味します。典型的には、この知識は、直接顧客に接続されているPEデバイスに限定されます。
In a layer 3 PE-based VPN, the provider will need to participate in some aspects of management and provisioning of the VPNs, such as ensuring that the PE devices are configured to support the correct VPNs. This implies that layer 3 PE-based VPNs are by definition provider-provisioned VPNs.
レイヤ3 PEベースのVPNでは、プロバイダは、PEデバイスが正しいVPNをサポートするように構成されることを保証するように、VPNの管理およびプロビジョニングのいくつかの局面に参加する必要があります。これは、レイヤ3 PEベースのVPNが定義プロバイダプロビジョニングのVPNによるものであることを意味します。
Layer 3 PE-based VPNs have the advantage that they offload some aspects of VPN management from the customer network. From the perspective of the customer network, it looks as if there is just a normal network; specific VPN functionality is hidden from the customer network. Scaling of the customer network's routing might also be improved, since some layer 3 PE-based VPN approaches avoid the need for the customer's routing algorithm to see "N squared" (actually N*(N-1)/2) point to point duplex links between N customer sites.
レイヤ3 PEベースのVPNは、彼らが顧客のネットワークからVPN管理のいくつかの側面をオフロードという利点があります。ただ、通常のネットワークがあるかのように、顧客のネットワークの観点から、それが見えます。特定のVPN機能は、顧客のネットワークから隠されています。いくつかのレイヤ3 PEベースのVPNアプローチは二重ポイントツーポイント「N二乗」（実際にはN *（N-1）/ 2）を参照する顧客のルーティングアルゴリズムの必要性を回避するので、顧客のネットワークのルーティングのスケーリングもまた、改善されるかもしれませんNの顧客サイト間のリンク。
However, these advantages come along with other consequences. Specifically, the PE devices must have some knowledge of the routing, addressing, and layer 3 protocols of the customer networks to which they attach. One consequence is that the set of layer 3 protocols which can be supported by the VPN is limited to those supported by the PE (which in practice means, limited to IP). Another consequence is that the PE devices have more to do, and the SP has more per-customer management to do.
しかし、これらの利点は、他の結果と一緒に来ます。具体的には、PEデバイスは、いくつかのルーティングの知識、アドレッシング、及び層それらが付着た顧客ネットワークの3つのプロトコルを有していなければなりません。一つの結果は、VPNによって支持することができるレイヤ3つのプロトコルのセットはPEによってサポートされるものに限定されることである（これはIPに限定されるもので練習手段、IN）。他の結果は、PEデバイスがやるべきことがあり、SPが行うために、よりごとの顧客管理を持っているということです。
An SP may offer a range of layer 3 PE-based VPN services. At one end of the range is a service limited to simply providing connectivity (optionally including QoS support) between specific customer network sites. This is referred to as "Network Connectivity Service". There is a spectrum of other possible services, such as firewalls, user or site of origin authentication, and address assignment (e.g., using Radius or DHCP).
SPは、レイヤ3 PEベースのVPNサービスの範囲を提供することができます。範囲の一方の端部に単に特定の顧客ネットワークサイト間（任意にQoSサポートを含む）の接続性を提供することに限定されたサービスです。これは、「ネットワーク接続サービス」と呼ばれています。このようなファイアウォール、元認証のユーザまたはサイト、およびアドレス割り当てのような他の可能なサービスのスペクトル（例えば、半径またはDHCPを使用して）があります。
This framework document will discuss methods for providing layer 3 PE-based VPNs and layer 3 provider-provisioned CE-based VPNs. This may include mechanisms which will can be used to constrain connectivity between sites, including the use and placement of firewalls, based on administrative requirements [PPVPN-REQ] [L3VPN-REQ]. Similarly the use and placement of NAT functionality is discussed. However, this framework document will not discuss methods for additional services such as firewall administration and address assignment. A discussion of specific firewall mechanisms and policies, and detailed discussion of NAT functionality, are outside of the scope of this document.
このフレームワークドキュメントはレイヤ3 PEベースのVPNおよびレイヤ3プロバイダプロビジョニングCEベースのVPNを提供するための方法について説明します。これは、管理要件に基づいて、ファイアウォールの使用と配置を含むサイト間の接続性を制約するために使用することができるであろうメカニズム、[PPVPN-REQ] [L3VPN-REQ]を含んでいてもよいです。同様にNAT機能を使用すると配置が議論されています。しかし、この枠組み文書は、このようなファイアウォール管理とアドレスの割り当てなどの追加サービスのための方法を説明しません。特定のファイアウォールのメカニズムと政策の議論、およびNAT機能の詳細については、この文書の範囲外です。
This document does not discuss those forms of VPNs that are outside of the scope of the IETF Provider-Provisioned VPN working group. Specifically, this document excludes discussion of PPVPNs using VPN native (non-IP, non-MPLS) protocols as the base technology used to provide the VPN service (e.g., native ATM service provided using ATM switches with ATM signaling). However, this does not mean to exclude multiprotocol access to the PPVPN by customers.
この文書は、IETFプロバイダープロビジョニングVPNワーキンググループの範囲の外にあるのVPNの形態のものについては説明しません。具体的には、この文書は、VPNサービスを提供するために使用される基盤技術として、VPNのネイティブ（非IP、非MPLS）プロトコルを使用してPPVPNsの議論を排除する（例えば、ネイティブATMサービスは、ATMはATMシグナル伝達を切り替える使用して提供しました）。しかし、これは顧客がPPVPNへのマルチアクセスを除外することを意味するものではありません。
Backdoor Links: Links between CE devices that are provided by the end customer rather than the SP; may be used to interconnect CE devices in multiple-homing arrangements.
バックドアリンク：むしろSPよりも最終顧客によって提供されているCEデバイス間のリンク。複数ホーミング構成でCEデバイスを相互接続するために使用されてもよいです。
CE-based VPN: An approach in which all the VPN-specific procedures are performed in the CE devices, and the PE devices are not aware in any way that some of the traffic they are processing is VPN traffic.
CEベースのVPN：すべてのVPN固有の手順は、CEデバイスで実行されたアプローチ、およびPEデバイスは、それらが処理されるトラフィックの一部がVPNトラフィックであることをどのような方法で認識していません。
Customer: A single organization, corporation, or enterprise that administratively controls a set of sites belonging to a VPN.
お客様：管理上VPNに属するサイトのセットを制御する単一の組織、企業、または企業。
Customer Edge (CE) Device: The equipment on the customer side of the SP-customer boundary (the customer interface).
カスタマーエッジ（CE）デバイス：SP-顧客境界の顧客側の機器（顧客インタフェース）。
IP Router: A device which forwards IP packets, and runs associated IP routing protocols (such as OSPF, IS-IS, RIP, BGP, or similar protocols). An IP router might optionally also be an LSR. The term "IP router" is often abbreviated as "router".
IPルータ：IPパケットを転送し、関連するIPルーティングプロトコル実行デバイス（OSPFなどを、RIP、BGP、または同様のプロトコル-ISです。）。 IPルータはまた、任意LSRかもしれません。用語「IPルータ」はしばしば「ルータ」と略記されます。
Label Switching Router: A device which forwards MPLS packets and runs associated IP routing and signaling protocols (such as LDP, RSVP-TE, CR-LDP, OSPF, IS-IS, or similar protocols). A label switching router is also an IP router.
ラベルスイッチングルーター：MPLSパケットと実行関連するIPルーティングと（例えばLDP、RSVP-TE、CR-LDP、OSPF、IS-IS、又は同様のプロトコルなどの）シグナリングプロトコルを転送するデバイス。ラベルスイッチングルータは、IPルータです。
PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet, and optionally on based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
PEベースのVPN：PEデバイス特定のトラフィックがVPNトラフィックであることを知っています。彼らは、パケットのIPヘッダ内の他の情報に基づいてパケットの宛先IPアドレスに基づいて（トンネルを介して）トラフィックを転送し、必要に応じてオン。 PEデバイスは、自身のトンネルエンドポイントです。トンネルは、様々なカプセル化の使用は、（例えば、これに限定されず、GRE、IP-で-IP、IPsecの、またはMPLSトンネルなど）SPネットワーク上のトラフィックを送信することがあります。
Private Network: A network which allows communication between a restricted set of sites, over an IP backbone that is used only to carry traffic to and from those sites.
プライベートネットワーク：サイトのみにしてからのトラフィックを運ぶために使用されるIPバックボーン上で、サイトの制限されたセットの間の通信を可能にするネットワーク。
Provider Edge (PE) Device: The equipment on the SP side of the SP-customer boundary (the customer interface).
プロバイダエッジ（PE）デバイス：SP-顧客境界のSP側の機器（顧客インタフェース）。
Provider-Provisioned VPNs (PPVPNs): VPNs, whether CE-based or PE-based, that are actively managed by the SP rather than by the end customer.
プロバイダ・プロビジョニングのVPN（PPVPNs）：VPNを、CEベースまたはPEベースのかどうか、積極的にSPによってではなく、エンドユーザーによって管理されています。
Route Reflectors: An SP-owned network element that is used to distribute BGP routes to the SP's BGP-enabled routers.
ルートリフレクタ：SPのBGP対応ルータにBGPルートを配布するために使用されるSP-所有するネットワーク要素。
Virtual Private Network (VPN): Restricted communication between a set of sites, making use of an IP backbone which is shared by traffic that is not going to or coming from those sites.
仮想プライベートネットワーク（VPN）は：に行くか、これらのサイトから来ていないトラフィックによって共有されているIPバックボーンを利用して、サイトのセットとの間の通信を制限します。
Virtual Router (VR): An instance of one of a number of logical routers located within a single physical router. Each logical router emulates a physical router using existing mechanisms and tools for configuration, operation, accounting, and maintenance.
仮想ルータ（VR）：単一の物理ルータ内に配置された論理ルータのうちの1つのインスタンス。各論理ルータは、設定、操作、会計、および保守のための既存のメカニズムとツールを使用して、物理ルータをエミュレートします。
VPN Forwarding Instance (VFI): A logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN.
VPN転送インスタンス（VFI）：VPNルータ情報ベース及び転送情報ベースを含むPEに存在する論理エンティティ。
VPN Backbone: IP and/or MPLS network which is used to carry VPN traffic between the customer sites of a particular VPN.
VPNバックボーン：特定のVPNの顧客サイト間のVPNトラフィックを運ぶために使用されるIPおよび/またはMPLSネットワーク。
VPN Edge Device: Device, attached to both the VPN backbone and the customer network, which performs VPN-specific functions. For PE-based VPNs, this is the PE device; for CE-based VPNs, this is the CE device.
VPNエッジ装置：VPN固有の機能を実行するVPNバックボーンと顧客ネットワークの両方に接続されたデバイス、。 PEベースのVPNの場合、これはPEデバイスです。 CEベースのVPNのために、これはCEデバイスです。
VPN Routing: Routing that is specific to a particular VPN.
VPNルーティング：特定のVPNに固有であるルーティング。
VPN Tunnel: A logical link between two PE or two CE entities, used to carry VPN traffic, and implemented by encapsulating packets that are transmitted between those two entities.
VPNトンネルの2つのPE又は二CEエンティティ間の論理リンクは、VPNトラフィックを運ぶために使用され、これらの2つのエンティティの間で伝送されるパケットをカプセル化することによって実現します。
ATM Asynchronous Transfer Mode BGP Border Gateway Protocol CE Customer Edge CLI Command Line Interface CR-LDP Constraint-based Routing Label Distribution Protocol EBGP External Border Gateway Protocol FR Frame Relay GRE Generic Routing Encapsulation IBGP Internal Border Gateway Protocol IKE Internet Key Exchange IGP Interior Gateway Protocol (e.g., RIP, IS-IS and OSPF are all IGPs) IP Internet Protocol (same as IPv4) IPsec Internet Protocol Security protocol IPv4 Internet Protocol version 4 (same as IP) IPv6 Internet Protocol version 6 IS-IS Intermediate System to Intermediate System routing protocol L2TP Layer 2 Tunneling Protocol LAN Local Area Network LDAP Lightweight Directory Access Protocol LDP Label Distribution Protocol LSP Label Switched Path LSR Label Switching Router MIB Management Information Base MPLS Multi Protocol Label Switching NBMA Non-Broadcast Multi-Access NMS Network Management System OSPF Open Shortest Path First routing protocol P Provider equipment PE Provider Edge PPVPN Provider-Provisioned VPN QoS Quality of Service RFC Request For Comments RIP Routing Information Protocol RSVP Resource Reservation Protocol RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SNMP Simple Network Management Protocol SP Service Provider VFI VPN Forwarding Instance VPN Virtual Private Network VR Virtual Router
ATM非同期転送モードBGPボーダーゲートウェイプロトコルCEカスタマーエッジCLIコマンドラインインターフェースCR-LDP制約ベースルーティングラベル配布プロトコルEBGP外部ボーダーゲートウェイプロトコルFRフレームリレーGRE総称ルーティングカプセル化IBGP内部ボーダーゲートウェイプロトコルIKEインターネットキー交換IGP内部ゲートウェイプロトコルIPインターネットプロトコルのIPsecインターネットプロトコルセキュリティプロトコルIPv4インターネットプロトコルバージョン4（同じIPなど）IPv6インターネットプロトコルバージョン6は、IS-IS中間システム（同じIPv4のような）中間システムに（例えば、RIP、IS-IS、およびOSPFは、すべてのIGPです）ルーティングプロトコルL2TPレイヤ2トンネリングプロトコルLANローカルエリアネットワークLDAPライトウェイトディレクトリアクセスプロトコルLDPラベル配布プロトコルのLSPラベルはNBMA非ブロードキャストマルチアクセスNMSネットワーク管理システムOSPFオープンスイッチングルータMIB管理情報ベースMPLSマルチプロトコルラベルスイッチングパスLSRのラベルスイッチド最短パス優先ルーティングプロトコルPプロバイダ機器PEプロバイダEコメントのためのサービスRFC要求のDGE PPVPNプロバイダープロビジョニングVPN QoSの品質は、RIPルーティング情報プロトコルRSVPリソース予約プロトコルRSVP-TEトラフィックエンジニアリング拡張SNMP簡易ネットワーク管理プロトコルSPサービスプロバイダーVFI VPN転送インスタンスVPN仮想プライベートネットワークVRバーチャルとリソース予約プロトコルルータ
This section describes PPVPN reference models. The purpose of discussing reference models is to clarify the common components and pieces that are needed to build and deploy a PPVPN. Two types of VPNs, layer 3 PE-based VPN and layer 3 provider-provisioned CE-based VPN are covered in separated sections below.
このセクションでは、PPVPNの参照モデルを説明しています。参照モデルを議論する目的は、PPVPNを構築し、展開するために必要な共通のコンポーネントと駒を明らかにすることです。 VPNの二つのタイプ、層3 PEベースのVPNおよびレイヤ3プロバイダプロビジョニングCEベースのVPNは、以下の分離の節で覆われています。
This subsection describes functional components and their relationship for implementing layer 3 PE-based VPN.
ここでは、機能性成分と層3 PEベースのVPNを実現するための関係を記述しています。
Figure 2.1 shows the reference model for layer 3 PE-based VPNs and Figures 2.2 and 2.3 show relationship between entities in the reference model.
図2.1は、レイヤ3 PEベースのVPNのための参照モデルを示し、参照モデル内のエンティティ間の2.2と2.3ショーの関係を図。
As shown in Figure 2.1, the customer interface is defined as the interface which exists between CE and PE devices, and the network interface is defined as the interface which exists between a pair of PE devices.
図2.1に示すように、顧客インタフェースは、CEおよびPEデバイスとの間に存在するインターフェースとして定義され、ネットワークインタフェースは、PEデバイスのペアの間に存在するインターフェースとして定義されます。
Figure 2.2 illustrates a single logical tunnel between each pair of VFIs supporting the same VPN. Other options are possible. For example, a single tunnel might occur between two PEs, with multiple per-VFI tunnels multiplexed over the PE to PE tunnel. Similarly, there may be multiple tunnels between two VFIs, for example to optimize forwarding within the VFI. Other possibilities will be discussed later in this framework document.
図2.2は、同じVPNをサポートするのVFIの各対の間に単一の論理トンネルを示しています。その他のオプションが可能です。例えば、単一のトンネルごとのVFIのPEトンネルへPEに多重トンネル複数有する2つのPE間に発生する可能性があります。同様に、VFI内の転送を最適化するために、例えば2つのVFIの間に複数のトンネルがあってもよいです。他の可能性は、このフレームワーク文書で後述します。
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel : |router| |device| : | of |
| of |-:--| |================:===============| |--:-|VPN A|
|VPN A| : | | : +------+ +------+ : +------+
+------+ : | PE | : | | : |
+------+ : |device| Network interface | | : |
| CE | : | | : +------+ : +------+
|device|-:--| |================:===============| |--:-| CE |
| of | : +------+ : VPN tunnel | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | single or multiple SP domains | | network |
Figure 2.1: Reference model for layer 3 PE-based VPN.
図2.1：層3 PEベースのVPNのための参照モデル。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
| CE | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.2: Relationship between entities in reference model (1).
図2.2：参照モデル内のエンティティ間の関係（1）。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | | |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 2.3: Relationship between entities in reference model (2).
図2.3：参照モデル内のエンティティ間の関係（2）。
The entities in the reference model are described below.
参照モデル内のエンティティは、以下に記載されています。
o Customer edge (CE) device
Oカスタマエッジ（CE）デバイス
In the context of layer 3 provider-provisioned PE-based VPNs, a CE device may be a router, LSR, or host that has no VPN-specific functionality. It is attached via an access connection to a PE device.
レイヤ3プロバイダプロビジョニングPEベースのVPNの文脈では、CEデバイスにはVPN固有の機能を持っていないルータ、LSR、またはホストであってもよいです。これは、PEデバイスへのアクセス接続を介して取り付けられています。
o P router
O Pルータ
A router within a provider network which is used to interconnect PE devices, but which does not have any VPN state and does not have any direct attachment to CE devices.
PEデバイスを相互接続するために使用されるプロバイダ・ネットワーク内のルータが、その任意のVPN状態を有していないとCEデバイスへの直接接続を持っていません。
o Provider edge (PE) device
プロバイダエッジ（PE）デバイス
In the context of layer 3 provider-provisioned PE-based VPNs, a PE device implements one or more VFIs and maintains per-VPN state for the support of one or more VPNs. It may be a router, LSR, or other device that includes VFIs and provider edge VPN functionality such as provisioning, management, and traffic classification and separation. (Note that access connections are terminated by VFIs from the functional point of view). A PE device is attached via an access connection to one or more CE devices.
レイヤ3プロバイダプロビジョニングPEベースのVPNの文脈では、PEデバイスは、一の以上のVFIを実装し、一の以上のVPNをサポートするため当たり-VPN状態を維持します。そのようなプロビジョニング、管理、及びトラフィックの分類と分離等のVFIとプロバイダエッジVPN機能を含むルータ、LSR、または他のデバイスであってもよいです。 （アクセス接続は、機能的な観点からのVFIによって終端されていることに注意）。 PEデバイスは、一つ以上のCE機器へのアクセス接続を介して取り付けられています。
o Customer site
Oカスタマーサイト
A customer site is a set of users that have mutual IP reachability without use of a VPN backbone that goes beyond the site.
顧客サイトでは、サイトを越えてVPNバックボーンを使用せずに相互のIP到達可能性を持っているユーザーのセットです。
o SP networks
OのSPネットワーク
An SP network is an IP or MPLS network administered by a single service provider.
SPのネットワークは、単一のサービスプロバイダによって管理IPまたはMPLSネットワークです。
o Access connection
Oアクセス接続
An access connection represents an isolated layer 2 connectivity between a CE device and a PE device. Access connections can be, e.g., dedicated physical circuits, logical circuits (such as FR, ATM, and MAC), or IP tunnels (e.g., using IPsec, L2TP, or MPLS).
アクセス接続は、CEデバイスとPEデバイスとの間の単離されたレイヤ2接続を表します。アクセス接続は、例えば、（例えば、IPsecの、L2TP、またはMPLSを使用して）物理的な回路（例えば、FR、ATM、およびMACなど）、論理回路、またはIPトンネルを専用にすることができます。
o Access network
お あっせっｓ ねとぉｒｋ
An access network provides access connections between CE and PE devices. It may be a TDM network, layer 2 network (e.g., FR, ATM, and Ethernet), or IP network over which access is tunneled (e.g., using L2TP [RFC2661] or MPLS).
アクセスネットワークは、CEとPEデバイス間のアクセス接続を提供します。これは、（例えば、L2TP [RFC2661]またはMPLSを使用して）アクセスがトンネリングされ、その上TDMネットワーク、レイヤ2ネットワーク（例えば、FR、ATM、およびイーサネット（登録商標））、またはIPネットワークであってもよいです。
o VPN tunnel
O VPNトンネル
A VPN tunnel is a logical link between two VPN edge devices. A VPN packet is carried on a tunnel by encapsulating it before transmitting it over the VPN backbone.
VPNトンネルは、2つのVPNエッジデバイス間の論理リンクです。 VPNパケットは、VPNバックボーンを介して送信する前にそれをカプセル化することによって、トンネル上に担持されます。
Multiple VPN tunnels at one level may be hierarchically multiplexed into a single tunnel at another level. For example, multiple per-VPN tunnels may be multiplexed into a single PE to PE tunnel (e.g., GRE, IP-in-IP, IPsec, or MPLS tunnel). This is illustrated in Figure 2.3. See section 4.3 for details.
あるレベルで複数のVPNトンネルは、階層別のレベルで単一のトンネルに多重化されてもよいです。例えば、複数毎のVPNトンネルは、PEトンネル（例えば、GRE、IPインIP、IPsecの、又はMPLSトンネル）に単一のPEに多重化されてもよいです。これは、図2.3に示されています。詳細については、4.3節を参照してください。
o VPN forwarding instance (VFI)
O VPN転送インスタンス（VFI）
A single PE device is likely to be connected to a number of CE devices. The CE devices are unlikely to all be in the same VPN. The PE device must therefore maintain a separate forwarding instances for each VPN to which it is connected. A VFI is a logical entity, residing in a PE, that contains the router information base and forwarding information base for a VPN. The interaction between routing and VFIs is discussed in section 4.4.2.
単一のPEデバイスは、CEデバイスの数に接続される可能性があります。 CEデバイスはすべて同じVPNにされそうにありません。 PEデバイスは、したがって、それが接続されている各VPNのための別個の転送インスタンスを維持しなければなりません。 VFIはVPNルータ情報ベース及び転送情報ベースを含有するPEに存在する、論理的なエンティティです。ルーティングとのVFIの間の相互作用は、セクション4.4.2に記載されています。
o Customer management function
O顧客管理機能
The customer management function supports the provisioning of customer specific attributes, such as customer ID, personal information (e.g., name, address, phone number, credit card number, and etc.), subscription services and parameters, access control policy information, billing and statistical information, and etc.
顧客管理機能は、顧客ID、個人情報（例えば、名前、住所、電話番号、クレジットカード番号、およびなど）、サブスクリプションサービスやパラメータ、アクセス制御ポリシー情報、課金や、顧客の特定の属性のプロビジョニングをサポートしています統計情報、およびなど
The customer management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
顧客管理機能は、SNMPマネージャ、ディレクトリサービス（例えば、LDAP [RFC3377]）、または独自のネットワーク管理システムの組み合わせを使用することができます。
o Network management function
Oネットワーク管理機能
The network management function supports the provisioning and monitoring of PE or CE device attributes and their relationships.
ネットワーク管理機能は、PEまたはCEデバイス属性およびそれらの関係のプロビジョニングおよびモニタリングをサポートします。
The network management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
ネットワーク管理機能は、SNMPマネージャ、ディレクトリサービス（例えば、LDAP [RFC3377]）、または独自のネットワーク管理システムの組み合わせを使用することができます。
For robustness, a CE device may be connected to more than one PE device, resulting in a multi-homing arrangement. Four distinct types of multi-homing arrangements, shown in Figure 2.4, may be supported.
ロバスト性のために、CEデバイスは、マルチホーミング構成で得られた、複数のPEデバイスに接続されてもよいです。図2.4に示したマルチホーミング構成の4つの異なるタイプは、サポートされてもよいです。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
This type includes a CE device connected
to a PE device via two access connections.
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
（C）（D）
Figure 2.4: Four types of double-homing arrangements.
図2.4：二重ホーミング配置の4種類。
It is quite natural to assume that multiple different layer 3 VPN approaches may be implemented, particularly if the VPN backbone includes more than one SP network. For example, (1) each SP chooses one or more layer 3 PE-based VPN approaches out of multiple vendor's implementations, implying that different SPs may choose different approaches; and (2) an SP may deploy multiple networks of layer 3 PE-based VPNs (e.g., an old network and a new network). Thus it is important to allow interworking of layer 3 PE-based VPNs making use of multiple different layer 3 VPN approaches.
VPNバックボーンは、複数のSPネットワークを含む場合は特に、その複数の異なるレイヤ3 VPNアプローチを実施することができると仮定するのは非常に自然です。例えば、（1）各SPには、1つまたは複数のレイヤを選択する3 PEベースのVPNが異なるSPは異なるアプローチを選択することができることを意味し、複数のベンダの実装のうち近づきます。 （2）SPは、レイヤ3 PEベースのVPN（例えば、古いネットワークと新しいネットワーク）の複数のネットワークを展開することができます。したがって、複数の異なるレイヤ3 VPNアプローチを利用して層3 PEベースのVPNのインターワーキングを可能にするために重要です。
There are three scenarios that enable layer 3 PE-based VPN interworking among different approaches.
異なるアプローチのうちの層3 PEベースのVPNインターワーキングを可能に3つのシナリオがあります。
o Interworking function
Oインターワーキング機能
This scenario enables interworking using a PE that is located at one or more points which are logically located between VPNs based on different layer 3 VPN approaches. For example, this PE may be located on the boundary between SP networks which make use of different layer 3 VPN approaches [VPN-DISC]. A PE at one of these points is called an interworking function (IWF), and an example configuration is shown in Figure 2.5.
このシナリオでは、論理的に異なるレイヤ3 VPNアプローチに基づくVPN間に配置される1つ以上の点に位置するPEを使用して連動可能にします。例えば、このPEは、異なるレイヤ3 VPNアプローチ[VPN-DISC]を利用するSPネットワークとの境界に位置してもよいです。これらの点のいずれかでPEは、インターワーキング機能（IWF）と呼ばれ、構成例を図2.5に示されています。
+------------------+ +------------------+
| | | |
+------+ VPN tunnel +------+ VPN tunnel +------+
| |==============| |==============| |
| | | | | |
| PE | | PE | | PE |
| | |device| | |
|device| |(IWF) | |device|
| | VPN tunnel | | VPN tunnel | |
| |==============| |==============| |
+------+ +------+ +------+
| | | |
+------------------+ +------------------+
|<-VPN approach 1->| |<-VPN approach 2->|
Figure 2.5: Interworking function.
図2.5：インターワーキング機能。
o Interworking interface
インターワーキングインターフェースO
This scenario enables interworking using tunnels between PEs supporting by different layer 3 VPN approaches. As shown in Figure 2.6, interworking interface is defined as the interface which exists between a pair of PEs and connects two SP networks implemented with different approaches. This interface is similar to the customer interface located between PE and CE, but the interface is supported by tunnels to identify VPNs, while the customer interface is supported by access connections.
このシナリオでは、異なるレイヤ3 VPNアプローチによって支持PE間のトンネルを使用してインターワーキングを可能にします。図2.6に示すように、インターワーキングインターフェースは、PEの対の間に存在し、異なる手法で実装2つのSPネットワークを接続するインタフェースとして定義されます。このインターフェイスは、PEとCEの間に位置する顧客インターフェースと類似しているが、インターフェースは顧客インターフェースがアクセス接続によって支持された状態で、VPNを識別するために、トンネルに支持されています。
+------------------+ +------------------+
| | : | |
+------+ VPN tunnel +------+Tunnel: +------+ VPN tunnel +------+
| |============| |======:======| |============| |
| | | | : | | | |
| PE | | PE | : | PE | | PE |
| | | | : | | | |
|device| |device| : |device| |device|
| | VPN tunnel | |Tunnel: | | VPN tunnel | |
| |============| |======:======| |============| |
+------+ +------+ : +------+ +------+
| | : | |
+------------------+ Interworking +------------------+
|<-VPN approach 1->| interface |<-VPN approach 2->|
Figure 2.6: Interworking interface.
図2.6：インターワーキングインターフェース。
o Customer-based interworking
Oの顧客ベースのインターワーキング
If some customer site has a CE attached to one kind of VPN, and a CE attached to another kind, communication between the two kinds of VPN occurs automatically.
一部の顧客サイトは、VPNの一種に添付CE、および他の種類の添付CEを持っている場合は、VPNの2種類の間の通信は自動的に行われます。
This subsection describes functional components and their relationship for implementing layer 3 provider-provisioned CE-based VPN.
ここでは、機能性成分と層3プロバイダプロビジョニングCEベースのVPNを実現するための関係を記述しています。
Figure 2.7 shows the reference model for layer 3 provider-provisioned CE-based VPN. As shown in Figure 2.7, the customer interface is defined as the interface which exists between CE and PE devices.
図2.7は、レイヤ3プロバイダプロビジョニングCEベースのVPNのための参照モデルを示しています。図2.7に示すように、顧客インタフェースは、CEおよびPEデバイスとの間に存在するインターフェースとして定義されます。
In this model, a CE device maintains one or more VPN tunnel endpoints, and a PE device has no VPN-specific functionality. As a result, the interworking issues of section 2.1.3 do not arise.
このモデルでは、CEデバイスは、1つまたは複数のVPNトンネルエンドポイントを維持し、PEデバイスにはVPN固有の機能を有していません。その結果、セクション2.1.3のインターワーキングの問題は発生しません。
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |device| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | VPN 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 2.7: Reference model for layer 3
provider-provisioned CE-based VPN.
The entities in the reference model are described below.
参照モデル内のエンティティは、以下に記載されています。
o Customer edge (CE) device
Oカスタマエッジ（CE）デバイス
In the context of layer 3 provider-provisioned CE-based VPNs, a CE device provides layer 3 connectivity to the customer site. It may be a router, LSR, or host that maintains one or more VPN tunnel endpoints. A CE device is attached via an access connection to a PE device and usually located at the edge of a customer site or co-located on an SP premises.
レイヤ3プロバイダプロビジョニングCEベースのVPNの文脈では、CEデバイスは、顧客サイトにレイヤ3接続性を提供します。これは、1つのまたは複数のVPNトンネルエンドポイントを維持するルータ、LSR、またはホストであってもよいです。 CEデバイスは、PEデバイスへのアクセス接続を介して取り付けられており、通常は顧客サイトの端に位置するか、SPの敷地内に同じ場所に配置されています。
o P router (see section 2.1.1)
OのPルータ（セクション2.1.1を参照）
o Provider edge (PE) device
プロバイダエッジ（PE）デバイス
In the context of layer 3 provider-provisioned CE-based VPNs, a PE device may be a router, LSR, or other device that has no VPN-specific functionality. It is attached via an access connection to one or more CE devices.
レイヤ3プロバイダプロビジョニングCEベースのVPNの文脈では、PEデバイスにはVPN固有の機能を持っていないルータ、LSR、または他のデバイスであってもよいです。それは、一つ以上のCEデバイスへのアクセス接続を介して装着されています。
o Customer Site (see section 2.1.1)
Oの顧客サイト（セクション2.1.1を参照してください）
o SP networks
OのSPネットワーク
An SP network is a network administrated by a single service provider. It is an IP or MPLS network. In the context of layer 3 provider-provisioned CE-based VPNs, the SP network consists of the SP's network and the SP's management functions that manage both its own network and the customer's VPN functions on the CE device.
SPのネットワークは、単一のサービスプロバイダによって管理ネットワークです。これは、IPまたはMPLSネットワークです。レイヤ3プロバイダプロビジョニングCEベースのVPNの文脈では、SPネットワークは、SPのネットワークと独自ネットワークとCEデバイス上の顧客のVPN機能の両方を管理SPの管理機能から成ります。
o Access connection (see section 2.1.1)
Oアクセス接続（セクション2.1.1を参照してください）
o Access network (see section 2.1.1)
Oアクセスネットワーク（セクション2.1.1を参照してください）
o VPN tunnel
O VPNトンネル
A VPN tunnel is a logical link between two entities which is created by encapsulating packets within an encapsulating header for purpose of transmission between those two entities for support of VPNs. In the context of layer 3 provider-provisioned CE-based VPNs, a VPN tunnel is an IP tunnel (e.g., using GRE, IP-in-IP, IPsec, or L2TP) or an MPLS tunnel between two CE devices over the SP's network.
VPNトンネルは、VPNのサポートのために、これら2つのエンティティ間の伝送のためにカプセル化ヘッダ内のパケットをカプセル化することによって作成された2つのエンティティ間の論理リンクです。レイヤ3プロバイダプロビジョニングCEベースのVPNの文脈では、VPNトンネル（例えば、GRE、IPインIP、IPsecの、またはL2TPを使用して）IPトンネルまたはSPのネットワーク上の2つのCE機器間のMPLSトンネルであります。
o Customer management function (see section 2.1.1)
O顧客管理機能（セクション2.1.1を参照してください）
o Network management function
Oネットワーク管理機能
The network management function supports the provisioning and monitoring of PE or CE device attributes and their relationships, covering PE and CE devices that define the VPN connectivity of the customer VPNs.
ネットワーク管理機能は、PEとカスタマVPNのVPN接続を定義するCE機器を覆う、PEまたはCEデバイス属性およびそれらの関係のプロビジョニングおよびモニタリングをサポートします。
The network management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
ネットワーク管理機能は、SNMPマネージャ、ディレクトリサービス（例えば、LDAP [RFC3377]）、または独自のネットワーク管理システムの組み合わせを使用することができます。
It is necessary for each PE device to know which CEs it is attached to, and what VPNs each CE is associated with.
これは、各PEデバイスは、それが接続されたCE知ることが必要である、と各CEをVPNをすることに関連しています。
VPN membership refers to the association of VPNs, CEs, and PEs. A given CE belongs to one or more VPNs. Each PE is therefore associated with a set of VPNs, and a given VPN has a set of associated PEs which are supporting that VPN. If a PE has at least one attached CE belonging to a given VPN, then state information for that VPN (e.g., the VPN routes) must exist on that PE. The set of VPNs that exist on a PE may change over time as customer sites are added to or removed from the VPNs.
VPNメンバーシップは、VPNの、のCE、およびPEの会合をいいます。与えられたCEは、一の以上のVPNに属します。各PEは、したがって、VPNのセットに関連付けられ、所与のVPNは、VPNをサポートしている、関連するPEのセットを有しています。 PEは、所与のVPNに属する少なくとも一つの取り付けられたCEがある場合、そのPEに存在する必要があり、そのVPN（例えば、VPNルート）のための情報を述べます。顧客サイトが追加またはVPNをから除去されるようにPEに存在するVPNのセットは、時間の経過とともに変化してもよいです。
In some layer 3 PE-based PPVPN schemes, VPN membership information (i.e., information about which PEs are attached to which VPNs) is explicitly distributed. In others, the membership information is inferred from other information that is distributed. Different schemes use the membership information in different ways, e.g., some to determine what set of tunnels to set up, some to constrain the distribution of VPN routing information.
いくつかのレイヤ3 PEベースのPPVPNスキームにおいて、VPNメンバーシップ情報は、明示的に分配される（すなわち、情報をどのPEがどののVPNが結合しています）。他では、メンバーシップ情報が配信され、他の情報から推測されます。異なる方式が異なる方法でメンバーシップ情報を使用し、例えば、いくつかは、いくつかのVPNルーティング情報の配布を制限するように、設定するトンネルの設定内容を決定します。
A VPN site may be added or deleted as a result of a provisioning operation carried out by the network administrator, or may be dynamically added or deleted as a result of a subscriber initiated operation; thus VPN membership information may be either static or dynamic, as discussed below.
VPNサイトを追加またはネットワーク管理者によって行わプロビジョニング操作の結果として削除、または動的に追加または加入者に開始操作の結果として削除することができるされてもよいです。後述するようにこのようにしてVPNメンバーシップ情報は、静的または動的のいずれであってもよいです。
Static binding occurs when a provisioning action binds a particular PE-CE access link to a particular VPN. For example, a network administrator may set up a dedicated link layer connection, such as an ATM VCC or a FR DLCI, between a PE device and a CE device. In this case the binding between a PE-CE access connection and a particular VPN to fixed at provisioning time, and remains the same until another provisioning action changes the binding.
プロビジョニング・アクションは、特定のVPNに特定のPE-CEアクセスリンクに結合する場合、静的な結合が生じます。例えば、ネットワーク管理者は、PEデバイス及びCEデバイスとの間のようなATM VCC又はFR DLCIなどの専用のリンクレイヤ接続をセットアップすることができます。この場合、時間をプロビジョニングに固定するPE-CEアクセス接続と特定のVPN間の結合、及び他のプロビジョニング・アクション・バインディングを変更するまで同じままです。
Dynamic binding occurs when some real-time protocol interaction causes a particular PE-CE access link to be temporarily bound to a particular VPN. For example, a mobile user may dial up the provider network and carry out user authentication and VPN selection procedures. Then the PE to which the user is attached is not one permanently associated with the user, but rather one that is typically geographically close to where the mobile user happens to be. Another example of dynamic binding is that of a permanent access connection between a PE and a CE at a public facility such as a hotel or conference center, where the link may be accessed by multiple users in turn, each of which may wish to connect to a different VPN.
動的バインディング、いくつかのリアルタイムプロトコルの相互作用が一時的に特定のVPNにバインドされるように、特定のPE-CEのアクセスリンクが発生したときに発生します。例えば、モバイルユーザは、プロバイダ・ネットワークをダイヤルアップし、ユーザ認証とVPNの選択手順を実行することができます。次いで、ユーザが接続されているPEが永久ユーザではなく、典型的には、モバイルユーザがあることを起こる場所に地理的に近くにあるものに関連付けられてものではありません。動的バインディングの別の例は、に接続することを望むかもしれないそれぞれがリンクを順番に複数のユーザによってアクセスされ得るようなホテルや会議場などの公共施設、におけるPEとCEの間の恒久的なアクセス接続のものです異なるVPN。
To support dynamically connected users, PPP and RADIUS are commonly used, as these protocols provide for user identification, authentication and VPN selection. Other mechanisms are also possible. For example a user's HTTP traffic may be initially intercepted by a PE and diverted to a provider hosted web server. After a dialogue that includes user authentication and VPN selection, the user can then be connected to the required VPN. This is sometimes referred to as a "captive portal".
これらのプロトコルは、ユーザ識別、認証、およびVPNの選択を提供するように動的に接続されたユーザをサポートするために、PPPおよびRADIUSは、一般的に、使用されています。他のメカニズムも可能です。たとえば、ユーザのHTTPトラフィックが最初にPEによって傍受される可能性や、プロバイダホストされたWebサーバーに転用します。ユーザ認証とVPNの選択を含む対話した後、ユーザは、必要なVPNに接続することができます。これは、「キャプティブポータル」と呼ばれています。
Independent of the particular mechanisms used for user authentication and VPN selection, an implication of dynamic binding is that a user for a given VPN may appear at any PE at any time. Thus VPN membership may change at any time as a result of user initiated actions, rather than as a result of network provisioning actions. This suggests that there needs to be a way to distribute membership information rapidly and reliably when these user-initiated actions take place.
ユーザ認証とVPNの選択のために使用される特定のメカニズムに関係なく、動的結合の含意は、所与のVPNのユーザがいつでもPEに現れる可能性があることです。したがって、VPNのメンバーシップは、ユーザーが開始した行動の結果としてではなく、ネットワークのプロビジョニング・アクションの結果として、随時変更されることがあります。これは、これらのユーザーが開始したアクションが行われたときに迅速かつ確実に会員情報を配布するための方法が必要ということを示唆しています。
In layer 3 provider-provisioned CE-based VPNs, the PE devices have no knowledge of the VPNs. A PE device attached to a particular VPN has no knowledge of the addressing or routing information of that specific VPN.
レイヤ3プロバイダプロビジョニングCEベースのVPNにおいて、PEデバイスがVPNの知識がありません。特定のVPNに取り付けられたPEデバイスは、その特定のVPNのアドレッシングやルーティング情報の知識を持ちません。
CE devices have IP or MPLS connectivity via a connection to a PE device, which just provides ordinary connectivity to the global IP address space or to an address space which is unique in a particular SPs network. The IP connectivity may be via a static binding, or via some kind of dynamic binding.
CEデバイスは、単にグローバルIPアドレス空間に、または特定のSPSネットワーク内で一意のアドレス空間に通常の接続を提供するPEデバイスへの接続を介して、IPまたはMPLS接続を有しています。 IP接続は、静的な結合を介して、または動的結合のいくつかの種類を介してもよいです。
The establishment of the VPNs is done at each CE device, making use of the IP or MPLS connectivity to the others. Therefore, it is necessary for a given CE device to know which other CE devices belong to the same VPN. In this context, VPN membership refers to the association of VPNs and CE devices.
VPNの確立は他の人にIPまたはMPLS接続を利用して、各CE機器で行われます。したがって、他のCEデバイスが同じVPNに属するかを知るために、所与のCE装置のために必要です。この文脈では、VPNのメンバーシップは、VPNおよびCE機器の会合を指します。
For layer 3 PE-based VPNs, the exchange is normal IP packets, transmitted in the same form which is available for interconnecting routers in general. For example, IP packets may be exchanged over Ethernet, SONET, T1, T3, dial-up lines, and any other link layer available to the router. It is important to note that those link layers are strictly local to the interface for the purpose of carrying IP packets, and are terminated at each end of the customer interface. The IP packets may contain addresses which, while unique within the VPN, are not unique on the VPN backbone. Optionally, the data exchange may use MPLS to carry the IP packets.
レイヤ3 PEベースのVPNのため、交換は、一般的にルータを相互接続するために利用可能である同じ形式で送信通常のIPパケットです。例えば、IPパケットは、イーサネット、SONET、T1、T3、ダイヤルアップ回線、およびルータに利用可能な任意の他のリンク層の上で交換することができます。これらのリンク層がIPパケットを運ぶために、インターフェイスに厳密にローカルであり、および顧客インターフェースの各端で終端されていることに注意することが重要です。 IPパケットは、VPN内で一意ながら、VPNバックボーン上で一意ではありません、アドレスが含まれていてもよいです。必要に応じて、データ交換は、IPパケットを運ぶためにMPLSを使用することができます。
The data exchanged at the customer interface are always normal IP packets that are routable on the VPN backbone, and whose addresses are unique on the VPN backbone. Optionally, MPLS frames can be used, if the appropriate label-switched paths exist across the VPN backbone. The PE device does not know whether these packets are VPN packets or not. At the current time, MPLS is not commonly offered as a customer-visible service, so that CE-based VPNs most commonly make use of IP services.
データは常にVPNバックボーンでルーティング可能な通常のIPパケットであり、そのアドレスがVPNバックボーン上で一意である顧客インタフェースで交換しました。適切なラベルスイッチパスがVPNバックボーンを横切って存在する場合、任意に、MPLSフレームを使用することができます。 PEデバイスは、これらのパケットがVPNパケットであるかどうか分かりません。 CEベースのVPNは、最も一般的にIPサービスを利用するように、現在の時点では、MPLSは、一般的に、顧客から見えるサービスとして提供されていません。
Once VPN tunnels are set up between pairs of VPN edge devices, it is necessary to set up mechanisms which ensure that packets from the customer network get sent through the proper tunnels. This routing function must be performed by the VPN edge device.
VPNトンネルは、VPNエッジデバイスのペアの間に設定されると、顧客のネットワークからパケットが適切なトンネルを介して送信され得ることを保証するメカニズムを設定する必要があります。このルーティング機能は、VPNエッジ装置によって実行されなければなりません。
There is a PE-CE routing interaction which enables a PE to obtain those addresses, from the customer network, that are reachable via the CE. The PE-CE routing interaction also enables a CE device to obtain those addresses, from the customer network, which are reachable via the PE; these will generally be addresses that are at other sites in the customer network.
CEを介して到達可能な顧客ネットワークから、それらのアドレスを取得するためにPEを可能PE-CEルーティング相互作用があります。 PE-CEルーティングの相互作用はまた、PEを介して到達可能な顧客ネットワークから、これらのアドレスを取得するためにCEデバイスを可能にします。これらは一般的に、顧客のネットワーク内の他のサイトにあるアドレスになります。
The PE-CE routing interaction can make use of static routing, an IGP (such as RIP, OSPF, IS-IS, etc.), or BGP.
PE-CEルーティングの相互作用は、スタティックルーティングを利用することができ、またはBGP（例えばRIP、OSPF、IS-ISなど）IGP。
If the PE-CE interaction is done via an IGP, the PE will generally maintain at least several independent IGP instances; one for the backbone routing, and one for each VPN. Thus the PE participates in the IGP of the customer VPNs, but the CE does not participate in the backbone's IGP.
PE-CEの相互作用がIGPを介して行われる場合、PEは、一般に、少なくともいくつかの独立したIGPインスタンスを維持します。バックボーンルーティングのための1、および各VPNに1つ。したがって、PEは、顧客のVPNのIGPに参加しますが、CEは、バックボーンのIGPに参加しません。
If the PE-CE interaction is done via BGP, the PE MAY support one instance of BGP for each VPN, as well as an additional instance of BGP for the public Internet routes. Alternatively, the PE might support a single instance of BGP, using, e.g., different BGP Address Families to distinguish the public Internet routes from the VPN routes.
PE-CEの相互作用は、BGPを介して行われる場合、PEは、各VPNのためのBGPの1つのインスタンスをサポートするだけでなく、公共のインターネットルートのBGPの追加インスタンスMAY。代替的に、PEはVPNルートから公共のインターネットルートを区別するために、例えば、異なるBGPアドレスファミリを使用して、BGPの単一のインスタンスをサポートするかもしれません。
Routing information which a PE learns from a CE in a particular VPN must be forwarded to the other PEs that are attached to the same VPN. Those other PEs must then forward the information in turn to the other CEs of that VPN.
PEは、特定のVPNにCEから学習経路情報は、同じVPNに接続されている他のPEに転送されなければなりません。これらの他のPEは、そのVPNの他のCEに順番に情報を転送する必要があります。
The PE-PE routing distribution can be done as part of the same routing instance to which the PE-CE interface belongs. Alternatively, it can be done via a different routing instance, possibly using a different routing algorithm. In this case, the PE must redistribute VPN routes from one routing instance to another.
PE-PEルーティング分布は、PE-CEインターフェイスが属する同一のルーティングインスタンスの一部として行うことができます。あるいは、それはおそらく異なるルーティングアルゴリズムを使用して、異なるルーティングインスタンスを介して行うことができます。この場合、PEは、別のルーティングインスタンスからVPNルートを再配布しなければなりません。
Note that VPN routing information is never distributed to the P routers. VPN routing information is known at the edge of the VPN backbone, but not in the core.
VPNルーティング情報は、Pルータに配信されることはありませんので注意してください。 VPNルーティング情報はなく、コアに、VPNバックボーンのエッジで知られています。
If the VPN's IGP is different than the routing algorithm running on the CE-PE link, then the CE must support two routing instances, and must redistribute the VPN's routes from one instance to the other (e.g., [VPN-BGP-OSPF]).
VPNのIGPは、CE-PEリンク上で実行されているルーティングアルゴリズムと異なる場合は、CEは、2つのルーティングインスタンスをサポートする必要があり、そして他の1つのインスタンスからVPNのルートを再配布しなければならない（例えば、[VPN-BGP-OSPF]） 。
In the case of layer 3 PE-based VPNs a single PE device is likely to provide service for several different VPNs. Since different VPNs may have address spaces which are not mutually unique, a PE device must have several forwarding tables, in general one for each VPN to which it is attached. These will be referred to as VPN Forwarding Instances (VFIs). Each VFI is a logical entity internal to the PE device. VFIs are defined in section 2.1.1, and discussed in more detail in section 4.4.2.
レイヤ3 PEベースのVPNの場合には、単一のPEデバイスは、いくつかの異なるVPNにサービスを提供する可能性があります。異なるVPNは互いにユニークでないアドレス空間を有することができるので、PEデバイスは、それが結合している各VPNのための一般的なもので、いくつかの転送テーブルを有していなければなりません。これらは、VPN転送インスタンス（のVFI）と呼ぶことにします。各VFIは、PE装置の内部論理エンティティです。 VFIは、セクション2.1.1で定義され、セクション4.4.2でより詳細に議論されます。
The scaling and management of the customer network (as well as the operation of the VPN) will depend upon the implementation approach and the manner in which routing is done.
スケーリングと顧客ネットワーク（ならびにVPNの動作）の管理は、実装手法とルーティングが行われている方法に依存するであろう。
In the intranet case all of the sites to be interconnected belong to the same administration (for example, the same company). The options for routing within a single customer network include:
イントラネットの場合、相互に接続するすべてのサイトは、同じ管理（例えば、同じ会社）に属しています。単一の顧客ネットワーク内でルーティングするためのオプションが含まれます：
o A single IGP area (using OSPF, IS-IS, or RIP)
O単一のIGP領域（OSPFを使用して、IS-IS、またはRIP）
o Multiple areas within a single IGP
単一IGP内のO複数のエリア
o A separate IGP within each site, with routes redistributed from each site to backbone routing (i.e., to a backbone as seen by the customer network).
（すなわち、顧客ネットワークによって見られるような骨格に）ルーティング骨格に各サイトから再配布されたルートと各サイト内の別のIGP、O。
Note that these options look at routing from the perspective of the overall routing in the customer network. This list does not specify whether PE device is considered to be in a site or not. This issue is discussed below.
これらのオプションは、顧客のネットワークの全体的なルーティングの観点からのルーティングを見ていることに注意してください。このリストは、PEデバイスがサイトまたはないと見なされているかどうかを指定しません。この問題は、以下に説明されます。
A single IGP area (such as a single OSPF area, a single IS-IS area, or a single instance of RIP between routers) may be used. One could have, all routers within the customer network (including the PEs, or more precisely, including a VFI within each PE) appear within a single area. Tunnels between the PEs could also appear as normal links.
（例えば、単一のOSPFエリアとして、単一のIS-IS領域、またはルータ間RIPの単一のインスタンス）は、単一のIGP領域を使用することができます。一つは、（各PE内VFIなどのPE、またはより正確には、含む）顧客ネットワーク内のすべてのルータが単一の領域内に現れる可能性があります。 PE間のトンネルは、通常のリンクとして表示されることがあります。
In some cases the multi-level hierarchy of OSPF or IS-IS may be used. One way to apply this to VPNs would be to have each site be a single OSPF or IS-IS area. The VFIs will participate in routing within each site as part of that area. The VFIs may then be interconnected as the backbone (OSPF area 0 or IS-IS level 2). If OSPF is used, the VFIs therefore appear to the customer network as area border routers. If IS-IS is used, the VFIs therefore participate in level 1 routing within the local area, and appear to the customer network as if they are level 2 routers in the backbone.
いくつかのケースでは、マルチレベルOSPFの階層またはIS-ISを使用してもよいです。 VPNにこれを適用する1つの方法は、各サイトは、単一のOSPFなる持っているだろうか、エリアIS-IS。 VFIは、その領域の一部として、各サイト内でのルーティングに参加します。 VFIは、次いで骨格として相互接続することができる（OSPFエリア0またはレベル2 IS-IS）。 OSPFを使用する場合、のVFIは、したがって、エリア境界ルータとしての顧客ネットワークに表示されます。 IS-ISを使用した場合、のVFIは、したがって、ローカルエリア内でレベル1のルーティングに参加し、彼らがバックボーンに2ルータレベルであるかのように、顧客のネットワークに表示されます。
Where an IGP is used across the entire network, it is straightforward for VPN tunnels, access connections, and backdoor links to be mixed in a network. Given that OSPF or IS-IS metrics will be assigned to all links, paths via alternate links can be compared and the shortest cost path will be used regardless of whether it is via VPN tunnels, access connections, or backdoor links. If multiple sites of a VPN do not use a common IGP, or if the backbone does not use the same common IGP as the sites, then special procedures may be needed to ensure that routes to/from other sites are treated as intra-area routes, rather than as external routes (depending upon the VPN approach taken).
IGPは、ネットワーク全体にわたって使用される場合、それは、VPNトンネル、アクセス接続、およびネットワーク内で混合されるバックドアリンクのために簡単です。 OSPFまたはIS-ISメトリックがすべてのリンクに割り当てられることを考えると、代替リンクを介してパスを比較することができ、最短コスト経路にかかわらず、それがVPNトンネル、アクセス接続、またはバックドアリンクを介しているかどうかの使用されるであろう。バックボーンはサイトと同じ一般的なIGPを使用していない場合は、VPNの複数のサイトが共通のIGPを使用するか、しない場合は、特別な手順は、ルートがに/他のサイトから、エリア内ルートとして扱われることを保証するために必要かもしれませんなく、外部経路（とらVPNアプローチに依存する）として。
Another option is to operate each site as a separate routing domain. For example each site could operate as a single OSPF area, a single IS-IS area, or a RIP domain. In this case the per-site routing domains will need to redistribute routes into a backbone routing domain (Note: in this context the "backbone routing domain" refers to a backbone as viewed by the customer network). In this case it is optional whether or not the VFIs participate in the routing within each site.
別のオプションは、別のルーティングドメインとして各サイトを動作させることです。例えば、各サイトには、単一のOSPFエリア、シングルIS-ISエリア、またはRIPドメインとして動作することができます。この場合、サイトごとのルーティングドメインは、バックボーンルーティングドメインにルートを再配布する必要があります（：顧客ネットワークによって見られるように、この文脈において「バックボーンルーティングドメイン」とは、骨格を指します）。この場合、のVFIは、各サイト内のルーティングに参加したか否かは任意です。
In the extranet case the sites to be interconnected belong to multiple different administrations. In this case IGPs (such as OSPF, IS-IS, or RIP) are normally not used across the interface between organizations. Either static routes or BGP may be used between sites. If the customer network administration wishes to maintain control of routing between its site and other networks, then either static routing or BGP may be used across the customer interface. If the customer wants to outsource all such control to the provider, then an IGP or static routes may be used at this interface.
エクストラネットの場合、相互に接続されるサイトは、複数の異なる行政に属しています。この場合のIGP（OSPFなどは、IS-IS、またはRIP）は、通常の組織との間の界面を横切って使用されていません。静的ルートまたはBGPのいずれかの部位との間で使用されてもよいです。顧客ネットワークの管理は、そのサイトと他のネットワーク間のルーティングの制御を維持することを望む場合には、スタティックルーティング、またはBGPのいずれかは、顧客インタフェースを介して使用することができます。顧客がプロバイダにすべてのこのような制御をアウトソースすることを望む場合、IGPまたはスタティックルートは、このインターフェイスで使用することができます。
The use of BGP between sites allows for policy based routing between sites. This is particularly useful in the extranet case. Note that private IP addresses or non-unique IP address (e.g., unregistered addresses) should not be used for extranet communication.
サイト間のBGPの使用は、サイト間でポリシーベースのルーティングが可能になります。これは、エクストラネットの場合に特に有用です。プライベートIPアドレスまたは非固有のIPアドレス（例えば、未登録アドレス）エクストラネットの通信のために使用すべきではないことに注意してください。
When using a single IGP area across an intranet, the entire customer network participates in a single area of an IGP. In this case, for layer 3 PE-based VPNs both CE and PE devices participate as normal routers within the area.
イントラネットにまたがる単一のIGP領域を使用する場合、全体の顧客ネットワークは、IGPの単一領域に関与します。この場合、層3 PEベースのVPNのためのCEおよびPEの両方のデバイスは、エリア内の通常のルータとして参加します。
The other options make a distinction between routing within a site, and routing between sites. In this case, a CE device would normally be considered as part of the site where it is located. However, there is an option regarding how the PE devices should be considered.
他のオプションは、サイト内のルーティング、およびサイト間のルーティングの間の区別をします。この場合、CEデバイスは、通常、それが配置されているサイトの一部として考えられます。しかし、PEデバイスが考慮されるべきかについてのオプションがあります。
In some cases, from the perspective of routing within the customer network, a PE device (or more precisely a VFI within a PE device) may be considered to be internal to the same area or routing domain as the site to which it is attached. This simplifies the management responsibilities of the customer network administration, since inter-area routing would be handled by the provider.
いくつかのケースでは、顧客のネットワーク内のルーティングの観点から、PEデバイス（またはより正確にPEデバイス内VFI）は、それが結合する部位と同じ地域又はルーティングドメインの内部にあると考えることができます。エリア間のルーティングは、プロバイダによって処理されるので、これは、顧客ネットワーク管理の管理責任を簡素化します。
For example, from the perspective of routing within the customer network, the CE devices may be the area border or AS boundary routers of the IGP area. In this case, static routing, BGP, or whatever routing is used in the backbone, may be used across the customer interface.
例えば、顧客ネットワーク内のルーティングの観点から、CEデバイスは、エリア境界またはIGP領域のAS境界ルータであってもよいです。この場合、スタティックルーティング、BGP、または任意のルーティングバックボーンで使用さで、顧客インターフェースにわたって使用されてもよいです。
3.3.2. Customer View of Routing for Layer 3 Provider-Provisioned CE-based VPNs
3.3.2. レイヤ3プロバイダプロビジョニングCEベースのVPNのルーティングのカスタマービュー
For layer 3 provider-provisioned CE-based VPNs, the PE devices are not aware of the set of addresses which are reachable at particular customer sites. The CE and PE devices do not exchange the customer's routing information.
レイヤ3プロバイダプロビジョニングCEベースのVPNのために、PEデバイスは、特定の顧客サイトに到達可能なアドレスのセットを認識していません。 CEとPEデバイスは、顧客のルーティング情報を交換しません。
Customer sites that belong to the same VPN may exchange routing information through the CE-CE VPN tunnels that appear, to the customers IGP, as router adjacencies. Alternatively, instead of exchanging routing information through the VPN tunnels, the SP's management system may take care of the configuration of the static route information of one site towards the other sites in the VPN.
同じVPNに所属する顧客サイトでは、ルータの隣接として、顧客IGPに、表示されるCE-CE VPNトンネル経由のルーティング情報を交換することができます。あるいは、代わりに、VPNトンネルを介してルーティング情報を交換する、SPの管理システムは、VPN内の他のサイトに対する一つのサイトの静的経路情報の構成の世話をすることができます。
Routing within the customer site may be done in any possible way, using any kind of routing protocols (see section 3.3.3).
顧客サイト内のルーティングは、ルーティングプロトコル（セクション3.3.3を参照）のいずれかの種類を使用して、任意の可能な方法で行うことができます。
As the CE device receives an IP or MPLS service from the SP, the CE and PE devices may exchange routing information that is meaningful within the SP routing realm.
CEデバイスは、SPからIPまたはMPLSサービスを受けるように、CEおよびPEデバイスは、SPルーティング領域内の意味のあるルーティング情報を交換することができます。
Moreover, as the forwarding of tunneled customer packets in the SP network will be based on global IP forwarding, the routes to the various CE devices must be known in the entire SP's network.
SPネットワークにトンネリング顧客パケットの転送は、グローバルIP転送に基づくであろうようにまた、様々なCEデバイスへのルートは、全SPのネットワークに知られていなければなりません。
This means that a CE device may need to participate in two different routing processes:
これは、CEデバイスに2つの異なるルーティングプロセスに参加する必要があるかもしれないことを意味します：
o routing in its own private network (VPN routing), within its own site and with the other VPN sites through the VPN tunnels, possibly using private addresses.
プライベートアドレスを使用して、おそらく、独自のサイト内およびVPNトンネルを介して他のVPNサイトで、独自のプライベートネットワーク（VPNルーティング）にルーティングO。
o routing in the SP network (global routing), as such peering with its PE.
OのPEとのピアリングなど、SPネットワーク（グローバルルーティング）にルーティングします。
However, in many scenarios, the use of static/default routes at the CE-PE interface might be all the global routing that is required.
しかし、多くのシナリオでは、CE-PE界面における静的/デフォルトルートの使用が必要とされるすべてのグローバルルーティング可能性があります。
The following technologies are available for the exchange of routing information.
以下の技術は、ルーティング情報の交換に利用されています。
o Static routing
Oスタティックルーティング
Routing tables may be configured through a management system.
ルーティングテーブルは、管理システムを介して構成することができます。
o RIP (Routing Information Protocol) [RFC2453]
OのRIP（ルーティング情報プロトコル）[RFC2453]
RIP is an interior gateway protocol and is used within an autonomous system. It sends out routing updates at regular intervals and whenever the network topology changes. Routing information is then propagated by the adjacent routers to their neighbors and thus to the entire network. A route from a source to a destination is the path with the least number of routers. This number is called the "hop count" and its maximum value is 15. This implies that RIP is suitable for a small- or medium-sized networks.
RIPは、内部ゲートウェイプロトコルであり、自律システム内で使用されています。これは、定期的とするたびに、ネットワークトポロジの変更でルーティングアップデートを送信します。ルーティング情報は、隣人へのため、ネットワーク全体に隣接するルータによって伝播されます。ソースから宛先へのルートがルータ数が最も少ない経路です。この番号は、「ホップカウント」と呼ばれ、その最大値は、これはRIPは小規模または中規模のネットワークに適していることを意味15です。
o OSPF (Open Shortest Path First) [RFC2328]
O OSPF（オープンショーテストパスファースト）[RFC2328]
OSPF is an interior gateway protocol and is applied to a single autonomous system. Each router distributes the state of its interfaces and neighboring routers as a link state advertisement, and maintains a database describing the autonomous system's topology. A link state is advertised every 30 minutes or when the topology is reconfigured.
OSPFは、内部ゲートウェイプロトコルであり、単一の自律システムに適用されます。各ルータは、リンク状態アドバタイズメントとしてのインタフェースと隣接ルータの状態を分配、および自律システムのトポロジを記述するデータベースを維持します。リンク状態が30分ごとに広告を出しているか、トポロジが再構成されたとき。
Each router maintains an identical topological database, from which it constructs a tree of shortest paths with itself as the root. The algorithm is known as the Shortest Path First or SPF. The router generates a routing table from the tree of shortest paths. OSPF supports a variable length subnet mask, which enables effective use of the IP address space.
各ルータは、ルートとしてそれ自体で最短経路のツリーを構築、そこから同じトポロジーデータベースを維持します。アルゴリズムは最短パスファーストまたはSPFとして知られています。ルータは、最短経路ツリーからルーティングテーブルを生成します。 OSPFは、IPアドレス空間の有効利用を可能に可変長サブネットマスクをサポートしています。
OSPF allows sets of networks to be grouped together into an area. Each area has its own topological database. The topology of the area is invisible from outside its area. The areas are interconnected via a "backbone" network. The backbone network distributes routing information between the areas. The area routing scheme can reduce the routing traffic and compute the shortest path trees and is indispensable for larger scale networks.
OSPFは、ネットワークのセットを領域にグループ化することを可能にします。各エリアには、独自のトポロジカルデータベースを持っています。エリアのトポロジは、そのエリア外からは見えません。エリアは「バックボーン」ネットワークを介して接続されています。バックボーンネットワークは、エリア間のルーティング情報を配信します。エリア・ルーティング方式は、ルーティングトラフィックを削減し、最短経路ツリーを計算し、大規模ネットワークのために不可欠であることができます。
Each multi-access network with multiple routers attached has a designated router. The designated router generates a link state advertisement for the multi-access network and synchronizes the topological database with other adjacent routers in the area. The concept of designated router can thus reduce the routing traffic and compute shortest path trees. To achieve high availability, a backup designated router is used.
接続された複数のルータと各マルチアクセスネットワークは、指定ルータを持っています。指定ルータは、マルチアクセスネットワークのリンク状態アドバタイズメントを生成し、領域内の他の隣接ルータとのトポロジーデータベースを同期させます。指定ルータのコンセプトは、このように、ルーティングトラフィックを削減し、最短経路木を計算することができます。高可用性を実現するために、バックアップ指定ルータが使用されています。
o IS-IS (intermediate system to intermediate system) [RFC1195]
Oは、IS-IS（中間システムへの中間システム）[RFC1195]
IS-IS is a routing protocol designed for the OSI (Open Systems Interconnection) protocol suites. Integrated IS-IS is derived from IS-IS in order to support the IP protocol. In the Internet community, IS-IS means integrated IS-IS. In this, a link state is advertised over a connectionless network service. IS-IS has the same basic features as OSPF. They include: link state advertisement and maintenance of a topological database within an area, calculation of a tree of shortest paths, generation of a routing table from a tree of shortest paths, the area routing scheme, a designated router, and a variable length subnet mask.
IS-ISは、OSI（Open Systems Interconnection）プロトコルスイートのために設計されたルーティングプロトコルです。統合IS-ISが由来されたIPプロトコルをサポートするために、IS-IS。インターネットコミュニティでは、IS-ISは、統合は、IS-ISを意味します。この中で、リンク状態は、コネクションレスネットワークサービス上でアドバタイズされます。 IS-ISは、OSPFと同じ基本機能を備えています。彼らは：最短経路のツリーからリンク状態広告と領域内のトポロジーデータベースの維持、最短経路ツリーの計算は、ルーティングテーブルの生成を、エリアルーティングスキーム、指定ルータ、および可変長サブネットマスク。
o BGP-4 (Border Gateway Protocol version 4) [RFC1771]
BGP-4 O（ボーダーゲートウェイプロトコルバージョン4）[RFC1771]
BGP-4 is an exterior gateway protocol and is applied to the routing of inter-autonomous systems. A BGP speaker establishes a session with other BGP speakers and advertises routing information to them. A session may be an External BGP (EBGP) that connects two BGP speakers within different autonomous systems, or an internal BGP (IBGP) that connects two BGP speakers within a single autonomous system. Routing information is qualified with path attributes, which differentiate routes for the purpose of selecting an appropriate one from possible routes. Also, routes are grouped by the community attribute [RFC1997] [BGP-COM].
BGP-4は、外部ゲートウェイプロトコルであり、相互自律システムのルーティングに適用されます。 BGPスピーカが他のBGPスピーカとのセッションを確立し、それらにルーティング情報をアドバタイズします。セッションは、異なる自律システム内の2つのBGPスピーカを接続する外部BGP（EBGP）、または単一の自律システム内の2つのBGPスピーカを接続する内部BGP（IBGP）であってもよいです。ルーティング情報は可能な経路から適切なものを選択するためにルートを区別パス属性で修飾します。また、ルートは、コミュニティ属性[RFC1997] [BGP-COM]によってグループ化されています。
The IBGP mesh size tends to increase dramatically with the number of BGP speakers in an autonomous system. BGP can reduce the number of IBGP sessions by dividing the autonomous system into smaller autonomous systems and grouping them into a single confederation [RFC3065]. Route reflection is another way to reduce the number of IBGP sessions [RFC1966]. BGP divides the autonomous system into clusters. Each cluster establishes the IBGP full mesh within itself, and designates one or more BGP speakers as "route reflectors," which communicate with other clusters via their route reflectors. Route reflectors in each cluster maintain path and attribute information across the autonomous system. The autonomous system still functions like a fully meshed autonomous system. On the other hand, confederations provide finer control of routing within the autonomous system by allowing for policy changes across confederation boundaries, while route reflection requires the use of identical policies.
IBGPのメッシュサイズは、自律システム内のBGPスピーカーの数を劇的に増加する傾向があります。 BGPは、より小さな自律システムに自律システムを分割し、単一の連合[RFC3065]にそれらをグループ化することによって、IBGPセッションの数を減らすことができます。経路反射はIBGPセッション[RFC1966]の数を減少させる別の方法です。 BGPは、クラスタに自律システムを分割します。各クラスタは、それ自体内IBGPフルメッシュを確立し、それらのルートリフレクタを介して他のクラスタと通信する「ルートリフレクタ」などの1つまたは複数のBGPスピーカを指定します。各クラスタ内のルートリフレクタは、パスを維持し、自律システム全体の属性情報。自律システムはまだ完全にメッシュ自律システムのように機能します。経路反射は同じポリシーの使用を必要とする一方で、同盟は、同盟の境界を越えてポリシーの変更を可能にすることによって、自律システム内のルーティングのより細かい制御を提供します。
BGP-4 has been extended to support IPv6, IPX, and others as well as IPv4 [RFC2858]. Multiprotocol BGP-4 carries routes from multiple "address families".
BGP-4は、IPv6、IPX、および他の同様のIPv4 [RFC2858]をサポートするように拡張されています。マルチプロトコルBGP-4は、複数の「アドレスファミリー」からのルートを運びます。
The basic functional components of an implementation of a VPN are:
VPNの実装の基本的な機能コンポーネントは以下のとおりです。
o A mechanism to acquire VPN membership/capability information
VPNメンバーシップ/能力情報を取得するためのメカニズムO
o A mechanism to tunnel traffic between VPN sites
VPNサイト間のトンネルトラフィックに対するO機構
o For layer 3 PE-based VPNs, a means to learn customer routes, distribute them between the PEs, and to advertise reachable destinations to customer sites.
O層3 PEベースのVPNの場合、手段は、顧客のルートを学習するためのPE間でそれらを配布し、顧客サイトに到達可能な目的地を宣伝します。
Based on the actual implementation, these functions could be implemented on a per-VPN basis or could be accomplished via a common mechanism shared by all VPNs. For instance, a single process could handle the routing information for all the VPNs or a separate process may be created for each VPN.
実際の実装に基づいて、これらの機能は当り-VPNに基づいて実施することができる、またはすべてのVPNが共有する共通のメカニズムを介して達成することができます。例えば、単一のプロセスは、すべてのVPNのためのルーティング情報を扱うことができるか、別のプロセスは、各VPNのために作成されてもよいです。
Logically, the establishment of a VPN can be thought of as composed of the following three stages. In the first stage, the VPN edge devices learn of each other. In the second stage, they establish tunnels to each other. In the third stage, they exchange routing information with each other. However, not all VPN solutions need be decomposed into these three stages. For example, in some VPN solutions, tunnels are not established after learning membership information; rather, pre-existing tunnels are selected and used. Also, in some VPN solutions, the membership information and the routing information are combined.
論理的に、VPNの確立は、以下の3つの段階からなると考えることができます。第一段階では、VPNエッジデバイスは、互いを知ります。第二段階では、彼らはお互いにトンネルを確立します。第3段階で、それらは相互にルーティング情報を交換します。ただし、すべてのVPNソリューションは、これらの3つの段階に分解される必要があります。例えば、いくつかのVPNソリューションでは、トンネルは、会員情報を学習した後に確立されていません。むしろ、既存のトンネルを選択して使用されています。また、いくつかのVPNソリューションでは、会員情報とルーティング情報が組み合わされます。
In the membership/capability discovery stage, membership and capability information needs to be acquired to determine whether two particular VPN edge devices support any VPNs in common. This can be accomplished, for instance, by exchanging VPN identifiers of the configured VPNs at each VPN edge device. The capabilities of the VPN edge devices need to be determined, in order to be able to agree on a common mechanism for tunneling and/or routing. For instance, if site A supports both IPsec and MPLS as tunneling mechanisms and site B supports only MPLS, they can both agree to use MPLS for tunneling. In some cases the capability information may be determined implicitly, for example some SPs may implement a single VPN solution. Likewise, the routing information for VPNs can be distributed using the methods discussed in section 4.4.
会員/能力発見段階では、会員及び能力情報は、2つの特定のVPNエッジデバイスの共通の任意のVPNをサポートするかどうかを決定するために取得する必要があります。これは、例えば、各VPNエッジ装置で設定VPNのVPN識別子を交換することによって、達成することができます。 VPNエッジデバイスの機能は、トンネルおよび/またはルーティングのための共通の機構に同意することができるようにするために、決定される必要があります。サイトAは、トンネリングメカニズムとしてIPsecとMPLSの両方をサポートし、サイトBのみがMPLSをサポートしている場合例えば、彼らは両方のトンネリングにMPLSを使用することに同意することができます。いくつかのケースでは能力情報は、例えば、いくつかのSPは、単一のVPNソリューションを実装することができる、暗黙的に決定されてもよいです。同様に、VPNのルーティング情報は、セクション4.4で説明した方法を使用して分散させることができます。
In the tunnel establishment stage, mechanisms may need to be invoked to actually set up the tunnels. With IPsec, for instance, this could involve the use of IKE to exchange keys and policies for securing the data traffic. However, if IP tunneling, e.g., is used, there may not be any need to explicitly set up tunnels; if MPLS tunnels are used, they may be pre-established as part of normal MPLS functioning.
トンネル確立段階では、機構は、実際にトンネルを設定するために起動する必要があるかもしれません。 IPsecで、例えば、これは、データトラフィックを保護するための鍵とポリシーを交換するIKEの使用を含むことができます。 IPトンネリングは、例えば、使用されている場合は、明示的にトンネルを設定する必要はないかもしれません。 MPLSトンネルが使用される場合、それらは通常のMPLS機能の一部として、事前に確立されてもよいです。
In the VPN routing stage, routing information for the VPN sites must be exchanged before data transfer between the sites can take place. Based on the VPN model, this could involve the use of static routes, IGPs such as OSPF/ISIS/RIP, or an EGP such as BGP.
サイト間のデータ転送を行う前にVPNルーティング段階では、VPNサイトのルーティング情報を交換する必要があります。 VPNモデルに基づいて、これは静的ルートの使用、例えばOSPF / ISIS / RIPなどのIGP、又はBGPなどのEGPを含む可能性があります。
VPN membership and capability information can be distributed from a central management system, using protocols such as, e.g., LDAP. Alternatively, it can be distributed manually. However, as manual configuration does not scale and is error prone, its use is discouraged. As a third alternative, VPN information can be distributed via protocols that ensure automatic and consistent distribution of information in a timely manner, much as routing protocols do for routing information. This may suggest that the information be carried in routing protocols themselves, though only if this can be done without negatively impacting the essential routing functions.
VPNメンバーシップ及び能力情報は、例えば、LDAPなどのプロトコルを使用して、中央管理システムから配信することができます。あるいは、それは手動で分配することができます。手動設定がスケールしないとエラーが発生しやすくなりますしかし、その使用は推奨されません。第3の代替として、VPN情報は、ルーティングプロトコルがルーティング情報のために行う限り、タイムリーに情報を自動的かつ一貫した分布を保証するプロトコルを介して配布することができます。これは場合にのみ、これはマイナス不可欠なルーティング機能に影響を与えることなく行うことができますが情報は、プロトコル自体をルーティングで運ばれることを示唆しています。
It can be seen that quite a lot of information needs to be exchanged in order to establish and maintain a VPN. The scaling and stability consequences need to be analyzed for any VPN approach.
情報のかなり多くが、VPNを確立し、維持するために交換する必要があることを見ることができます。スケーリングと安定性の結果は、任意のVPNのアプローチを分析する必要があります。
While every VPN solution must address the functionality of all three components, the combinations of mechanisms used to provide the needed functionality, and the order in which different pieces of functionality are carried out, may differ.
すべてのVPNソリューションは、すべての3つのコンポーネント、必要な機能を提供するために使用されるメカニズムの組み合わせ、および機能の異なる部分が実行される順序の機能に対処する必要があるが、異なっていてもよいです。
For layer 3 provider-provisioned CE-based VPNs, the VPN service is offering tunnels between CE devices. IP routing for the VPN is done by the customer network. With these solutions, the SP is involved in the operation of the membership/capability discovery stage and the tunnel establishment stage. The IP routing functional component may be entirely up to the customer network, or alternatively, the SP's management system may be responsible for the distribution of the reachability information of the VPN sites to the other sites of the same VPN.
レイヤ3プロバイダプロビジョニングCEベースのVPNのために、VPNサービスは、CEデバイス間のトンネルを提供しています。 VPNのIPルーティングは、カスタマーネットワークによって行われます。これらの溶液を用いて、SPは、会員/能力発見ステージ及びトンネル確立段階の操作に関与しています。機能性成分をIPルーティングは完全に顧客ネットワークまでであってもよいし、または代替的に、SPの管理システムは、同じVPNの他のサイトへのVPNサイトの到達可能性情報の配信に関与し得ます。
For a layer 3 provider-provisioned VPN the SP is responsible for the establishment and maintenance of the VPNs. Many different approaches and schemes are possible in order to provide layer 3 PPVPNs, however there are some generic problems that any VPN solution must address, including:
レイヤ3プロバイダープロビジョニングVPNの場合SPはVPNの確立と維持を担当しています。多くの異なるアプローチや手法は、しかし、任意のVPNソリューションは、などの対処をしなければならないことを、いくつかの一般的な問題があり、レイヤ3 PPVPNsを提供するために可能です。
o For PE-based VPNs, when a new site is added to a PE, how do the other PEs find out about it? When a PE first gets attached to a given VPN, how does it determine which other PEs are attached to the same VPN. For CE-based VPNs, when a new site is added, how does its CE find out about all the other CEs at other sites of the same VPN?
O PEベースのVPNの場合は、新しいサイトがPEに追加されたときに、どのように他のPEは、それを知るのですか？ PEが最初に与えられたVPNに取り付け取得したときに、どのように他のPEは、同じVPNに接続されているかを決定ありません。 CEベースのVPNの場合は、新しいサイトが追加された場合、どのようにそのCEは、同じVPNの他のサイトでは他のすべてのCEを知るのでしょうか？
o In order for layer 3 PE-based VPNs to scale, all routes for all VPNs cannot reside on all PEs. How is the distribution of VPN routing information constrained so that it is distributed to only those devices that need it?
Oスケーリングするレイヤ3 PEベースのVPNためには、すべてのVPNのすべてのルートはすべてのPE上に存在することができません。それはそれを必要とするデバイスのみに配布されるように、どのようにVPNルーティング情報の配信が制約されていますか？
o An administrator may wish to provision different topologies for different VPNs (e.g., a full mesh or a hub & spoke topology). How is this achieved?
O管理者は、規定に異なるVPN（例えば、フルメッシュまたはハブ＆スポークのトポロジー）のための異なるトポロジーを望むことができます。これはどのように達成されますか？
This section looks at some of these generic problems and at some of the mechanisms that can be used to solve them.
このセクションでは、これらの一般的な問題のいくつかで、それらを解決するために使用することができるメカニズムのいくつかを見ます。
Mechanisms are needed to acquire information that allows the establishment and maintenance of VPNs. This may include, for example, information on VPN membership, topology, and VPN device capabilities. This information may be statically configured, or distributed by an automated protocol. As a result of the operation of these mechanisms and protocols, a device is able to determine where to set up tunnels, and where to advertise the VPN routes for each VPN.
メカニズムは、VPNの確立と維持を可能にする情報を取得するために必要とされます。これは、VPNメンバーシップ、トポロジ、およびVPNデバイスの能力に、例えば、情報を含むことができます。この情報は静的に設定、または自動化されたプロトコルによって配信されてもよいです。これらのメカニズムとプロトコルの動作の結果として、デバイスは、トンネルを設定し、ここで、各VPN用のVPNルートをアドバタイズするために場所を決定することができます。
With a physical network, the equivalent problem can by solved by the control of the physical interconnection of links, and by having a router run a discovery/hello protocol over its locally connected links. With VPNs both the routers and the links (tunnels) may be logical entities, and thus some other mechanisms are needed.
物理的なネットワークでは、同等の問題があり、ルータがローカルに接続されたリンク上で発見/ Helloプロトコルを実行することによって、リンクの物理的な相互接続を制御することによって解決することによってすることができます。 VPNを用いてルータとのリンク（トンネル）の両方が論理エンティティであってもよく、したがって、いくつかの他のメカニズムが必要とされています。
A number of different approaches are possible for VPN discovery. One scheme uses the network management system to configure and provision the VPN edge devices. This approach can also be used to distribute VPN discovery information, either using proprietary protocols or using standard management protocols and MIBs. Another approach is where the VPN edge devices act as clients of a centralized directory or database server that contains VPN discovery information. Another possibility is where VPN discovery information is piggybacked onto a routing protocol running between the VPN edge devices [VPN-DISC].
多くの異なるアプローチは、VPNの発見のために可能です。一つの方式は、VPNエッジデバイスを設定して提供するネットワーク管理システムを使用しています。このアプローチはまた、いずれかの独自のプロトコルを使用して、または標準の管理プロトコルとMIBを使用して、VPNの発見情報を配信するために使用することができます。 VPNエッジデバイスがVPNディスカバリ情報が含まれている中央のディレクトリやデータベース・サーバのクライアントとして動作する場所別のアプローチはあります。 VPN発見情報は、VPNエッジデバイス[VPN-DISC]との間に実行されているルーティングプロトコルにピギーバックされる別の可能性があります。
SPs use network management extensively to configure and monitor the various devices that are spread throughout their networks. This approach could be also used for distributing VPN related information. A network management system (either centralized or distributed) could be used by the SP to configure and provision VPNs on the VPN edge devices at various locations. VPN configuration information could be entered into a network management application and distributed to the remote sites via the same means used to distribute other network management information. This approach is most natural when all the devices that must be provisioned are within a single SP's network, since the SP has access to all VPN edge devices in its domain. Security and access control are important, and could be achieved for example using SNMPv3, SSH, or IPsec tunnels.
SPは、自社のネットワーク全体に広がっているさまざまなデバイスを設定および監視するために広くネットワーク管理を使用しています。このアプローチは、VPN関連情報を配信するために使用することができます。ネットワーク管理システム（集中型または分散型のいずれか）は、様々な場所でVPNエッジデバイス上でVPNを設定し、提供するためにSPによって使用することができます。 VPN構成情報は、ネットワーク管理アプリケーションに入力され、他のネットワーク管理情報を配布するために使用されるのと同じ手段を介してリモートサイトに配布することができます。 SPは、そのドメイン内のすべてのVPNエッジデバイスへのアクセスを持っているため、プロビジョニングする必要があり、すべてのデバイスは、単一のSPのネットワーク内にあるときに、このアプローチが最も自然です。セキュリティとアクセス制御が重要であり、およびSNMPv3、SSH、またはIPsecトンネルを使用して、たとえば達成することができました。
An SP typically needs to maintain a database of VPN configuration/membership information, regardless of the mechanisms used to distribute it. LDAPv3 [RFC3377] is a standard directory protocol which makes it possible to use a common mechanism for both storing such information and distributing it.
SPは、典型的には関係なく、それを配布するために使用されるメカニズムの、VPN構成/会員情報のデータベースを維持する必要があります。 LDAPv3の[RFC3377]は、そのような情報を格納し、それを配信の両方に共通の機構を使用することができる標準のディレクトリ・プロトコルです。
To facilitate interoperability between different implementations, as well as between the management systems of different SPs, a standard schema for representing VPN membership and configuration information would have to be developed.
異なる実装の間に、ならびに異なるSPの管理システム間の相互運用性を容易にするために、VPNのメンバーシップおよび構成情報を表すための標準スキーマが開発されなければなりません。
LDAPv3 supports authentication of messages and associated access control, which can be used to limit access to VPN information to authorized entities.
LDAPv3のは、許可のエンティティへのVPN情報へのアクセスを制限するために使用することができ、メッセージと関連付けられたアクセス制御、認証をサポートしています。
Extensions to the use of existing BGP mechanisms, for distribution of VPN membership information, are proposed in [VPN-2547BIS]. In that scheme, BGP is used to distribute VPN routes, and each route carries a set of attributes which indicate the VPN (or VPNs) to which the route belongs. This allows the VPN discovery information and routing information to be combined in a single protocol. Information needed to establish per-VPN tunnels can also be carried as attributes of the routes. This makes use of the BGP protocol's ability to effectively carry large amounts of routing information.
既存のBGP機構の使用に拡張は、VPNメンバーシップ情報の配信のために、[VPN-2547BIS]で提案されています。その方式では、BGPは、VPNルートを分配するために使用され、各ルートは、ルートが属するVPN（またはVPNを）示す属性のセットを搬送されます。これは、単一のプロトコルで結合するVPN発見情報およびルーティング情報を可能にします。情報ごとのVPNトンネルはルートの属性としてもを実施することができる確立するために必要。これは、効果的に情報をルーティングを大量に運ぶためにBGPプロトコルの能力を利用します。
It is also possible to use BGP to distribute just the membership/capability information, while using a different technique to distribute the routing. BGP's update message would be used to indicate that a PE is attached to a particular VPN; BGP's withdraw message would be used to indicate that a PE has ceased to be attached to a particular VPN. This makes use of the BGP protocol's ability to dynamically distribute real-time changes in a reliable and fairly rapid manner. In addition, if a BGP route reflector is used, PEs never have to be provisioned with each other's IP addresses at all. Both cases make use of BGP's mechanisms, such as route filters, for constraining the distribution of information.
ルーティングを配布するために異なる技術を使用しながら、単に会員/機能情報を配布するためにBGPを使用することも可能です。 BGPの更新メッセージはPEが特定のVPNに接続されていることを示すために使用されるであろう。 BGPの撤回メッセージがPEが特定のVPNに取り付けられるように停止したことを示すために使用されるであろう。これは、動的に信頼性が高く、かなり迅速にリアルタイムで変更を配布するBGPプロトコルの能力を利用します。 BGPルートリフレクタが使用されている場合はさらに、PEは全く互いのIPアドレスをプロビジョニングする必要がありません。どちらの場合は、情報の配信を拘束するため、このような経路フィルタなどのBGPのメカニズム、を利用します。
Augmented routing may be done in combination with aggregated routing, as discussed in section 4.4.4. Of course, when using BGP for distributing any kind of VPN-specific information, one must ensure that one is not disrupting the classical use of BGP for distributing public Internet routing information. For further discussion of this, see the discussion of aggregated routing, section 4.4.4.
セクション4.4.4で説明したように拡張ルーティングは、凝集したルーティングと組み合わせて行うことができます。 VPN固有の情報のいずれかの種類を配布するためのBGPを使用する場合は、当然、1は1つが公共のインターネットルーティング情報を配信するためのBGPの古典の使用を中断せていないことを確認する必要があります。これのさらなる議論のために、凝集したルーティングの議論、セクション4.4.4を参照。
When two sites of a VPN are connected to different SP networks, the SPs must support a common mechanism for exchanging membership/capability information. This might make use of manual configuration or automated exchange of information between the SPs. Automated exchange may be facilitated if one or more mechanisms for VPN discovery are standardized and supported across the multiple SPs. Inter-SP trust relationships will need to be established, for example to determine which information and how much information about the VPNs may be exchanged between SPs.
VPNの2つのサイトが異なるSPネットワークに接続されている場合、SPは、会員/能力情報を交換するための共通のメカニズムをサポートしている必要があります。これは、手動での設定やSPの間の情報のやり取り自動化を利用する場合があります。 VPNの検出のための1つ以上の機構を標準化し、複数のSPを横切って支持されている場合は自動交換を容易にすることができます。インターSPの信頼関係は、SP間で交換することのできる情報とどのくらいのVPNに関する情報を決定するために、たとえば、確立する必要があります。
In some cases different service providers may deploy different approaches for VPN discovery. Where this occurs, this implies that for multi-SP VPNs, some manual coordination and configuration may be necessary.
いくつかのケースでは異なるサービスプロバイダは、VPNの発見のためのさまざまなアプローチを展開します。これが発生する場合、これは、マルチSPのVPNのために、いくつかの手動調整および構成が必要であり得ることを意味します。
The amount of information which needs to be shared between SPs may vary greatly depending upon the number of size of the multi-SP VPNs. The SPs will therefore need to determine and agree upon the expected amount of membership information to be exchanged, and the dynamic nature of this information. Mechanisms may also be needed to authenticate the VPN membership information.
SPの間で共有される必要がある情報の量は、マルチSP VPNのサイズの数に応じて大きく変化し得ます。 SPはそのため交換される会員情報の予想量、およびこの情報の動的な性質を決定し、同意する必要があります。メカニズムはまた、VPNメンバーシップ情報を認証するために必要とすることができます。
VPN information should be distributed only to places where it needs to go, whether that is intra-provider or inter-provider. In this way, the distribution of VPN information is unlike the distribution of inter-provider routing information, as the latter needs to be distributed throughout the Internet. In addition, the joint support of a VPN by two SPs should not require any third SP to maintain state for that VPN. Again, notice the difference with respect to inter-provider routing; in inter-provider routing: sending traffic from one SP to another may indeed require routing state in a third SP.
VPN情報は、イントラプロバイダーまたはインタープロバイダであるかどうか、それは行くために必要な場所にのみ配布されなければなりません。後者のニーズがインターネット全体に分散されるように、このようにして、VPN情報の配信は、インタープロバイダルーティング情報の分布とは異なります。さらに、2つのSPによってVPNの関節サポートは、VPNの状態を維持するために、任意の第三のSPを必要とすべきではありません。再び、インタープロバイダルーティングに対する違いに気付きます。インタープロバイダルーティングに：別のSPからのトラフィックを送信することは、実際に第三のSP状態ルーティング必要とするかもしれません。
As one possible example: Suppose that there are two SPs A and C, which want to support a common VPN. Suppose that A and C are interconnected via SP B. In this case B will need to know how to route traffic between A and C, and therefore will need to know something about A and C (such as enough routing information to forward IP traffic and/or connect MPLS LSPs between PEs or route reflectors in A and C). However, for scaling purposes it is desirable that B not need to know VPN-specific information about the VPNs which are supported by A and C.
1基の可能な例としては：一般的なVPNをサポートする2つのSP AとCが存在すると仮定します。このようなIPトラフィックを転送するのに十分なルーティング情報として（方法AとCとの間のトラフィックをルーティングするために知っておく必要があり、従ってAおよびCについて何かを知っている必要がありますAおよびCは、この場合、BはSP Bを介して相互に接続されていると仮定すると/又はA及びC内のPEまたはルートリフレクタとの間のMPLS LSPを接続）。しかし、スケーリングの目的のためには、BはAとCによってサポートされているVPNのVPNに関する固有の情報を知っている必要がないことが望ましいです
In layer 3 provider-provisioned CE-based VPNs, the VPN tunnels connect CE devices. In this case, distribution of IP routing information occurs between CE devices on the customer sites. No additional constraints on the distribution of VPN routing information are necessary.
レイヤ3プロバイダプロビジョニングCEベースのVPNでは、VPNトンネルがCEデバイスを接続します。この場合、IPルーティング情報の配信は、顧客サイトでのCEデバイスとの間で発生します。 VPNルーティング情報の配信には追加の制約は必要ありません。
In layer 3 PE-based VPNs, however, the PE devices must be aware of VPN routing information (for the VPNs to which they are attached). For scalability reasons, one does not want a scheme in which all PEs contain all routes for all VPNs. Rather, only the PEs that are attached to sites in a given VPN should contain the routing information for that VPN. This means that the distribution of VPN routing information between PE devices must be constrained.
レイヤ3 PEベースのVPNでは、しかし、PEデバイスは、（それらが結合しているVPNの）VPNルーティング情報を認識しなければなりません。スケーラビリティの理由から、一つはすべてのPEは、すべてのVPNのすべてのルートが含まれているスキームを望んでいません。むしろ、特定のVPN内のサイトに接続されている唯一のPEは、そのVPNのルーティング情報が含まれている必要があります。これは、PEデバイス間のVPNルーティング情報の配信が拘束されなければならないことを意味します。
As VPN membership may change dynamically, it is necessary to have a mechanism that allows VPN route information to be distributed to any PE where there is an attached user for that VPN, and allows for the removal of this information when it is no longer needed.
VPNメンバーシップを動的に変更することができるように、VPN経路情報は、そのVPNの取り付けユーザが任意のPEに分配することを可能にするメカニズムを有することが必要であり、それがもはや必要とされたときに、この情報を除去することができません。
In the Virtual Router scheme, per-VPN tunnels must be established before any routes for a VPN are distributed, and the routes are then distributed through those tunnels. Thus by establishing the proper set of tunnels, one implicitly constrains and controls the distribution of per-VPN routing information. In this scheme, the distribution of membership information consists of the set of VPNs that exists on each PE, as well as information about the desired topology. This enables a PE to determine the set of remote PEs to which it must establish tunnels for a particular VPN.
VPNのための任意のルートが分散され、ルートがそれらのトンネルを介して配布される前に、仮想ルータ方式では、単位のVPNトンネルが確立されなければなりません。したがってトンネルの適切なセットを確立することによって、人は暗黙的制約ごとのVPNルーティング情報の配布を制御します。この方式では、会員情報の分布は、各PEに存在するVPNのセット、ならびに所望のトポロジに関する情報から構成されています。これは、特定のVPNのためのトンネルを確立しなければならないためにリモートPEのセットを決定するためにPEを可能にします。
In the aggregated routing scheme (see section 4.4.4), the distribution of VPN routing information is constrained by means of route filtering. As VPN membership changes on a PE, the route filters in use between the PE and its peers can be adjusted. Each peer may then adjust the filters in use with each of its peers in turn, and thus the changes propagate across the network. When BGP is used, this filtering may take place at route reflectors as discussed in section 4.4.4.
集約されたルーティング方式（セクション4.4.4を参照）において、VPNルーティング情報の配信は、経路フィルタリングによって制約されます。 PE上のVPNメンバーシップの変更として、PEとそのピアとの間の使用中のルートフィルタを調整することができます。各ピアは、その後、順番にそのピアの各々と、使用中のフィルタを調整することができるので、変更がネットワークを介して伝播します。 BGPを使用する場合セクション4.4.4で説明したように、このフィルタリングは、ルートリフレクタで行うことができます。
The topology for a VPN consists of a set of nodes interconnected via tunnels. The topology may be a full mesh, a hub and spoke topology, or an arbitrary topology. For a VPN the set of nodes will include all VPN edge devices that have attached sites for that VPN. Naturally, whatever the topology, all VPN sites are reachable from each other; the topology simply constrains the way traffic is routed among the sites. For example, in one topology traffic between site A and site B goes from one to the other directly over the VPN backbone; in another topology, traffic from site A to site B must traverse site C before reaching site B.
VPNのトポロジは、トンネルを介して相互接続されたノードのセットからなります。トポロジはフルメッシュ、ハブよく、トポロジー、または任意のトポロジーを話してもよいです。 VPNのためのノードのセットは、VPNのための部位を取り付けたすべてのVPNエッジデバイスを含みます。当然のことながら、どのようなトポロジ、すべてのVPNサイトは、互いに到達可能です。トポロジは、単にトラフィックがサイト間でルーティングされる方法を制約します。例えば、1つのトポロジでサイトAとサイトBの間のトラフィックは、VPNバックボーンを介して直接、一方から他方へ行きます。別のトポロジで、サイトBにサイトAからのトラフィックは、サイトBに到達する前に、サイトCを横断しなければなりません
The simplest topology is a full mesh, where a tunnel exists between every pair of VPN edge devices. If we assume the use of point-to-point tunnels (rather than multipoint-to-point), then with a full mesh topology there are N*(N-1)/2 duplex tunnels or N*(N-1) simplex tunnels for N VPN edge devices. Each tunnel consumes some resources at a VPN edge device, and depending on the type of tunnel, may or may not consume resources in intermediate routers or LSRs. One reason for using a partial mesh topology is to reduce the number of tunnels a VPN edge device, and/or the network, needs to support. Another reason is to support the scenario where an administrator requires all traffic from certain sites to traverse some particular site for policy or control reasons, such as to force traffic through a firewall, or for monitoring or accounting purposes. Note that the topologies used for each VPN are separate, and thus the same VPN edge device may be part of a full mesh topology for one VPN, and of a partial mesh topology for another VPN.
最も単純なトポロジーは、トンネルがVPNエッジデバイスの各ペアの間に存在するフルメッシュです。我々はポイントツーポイントトンネルの使用（よりむしろマルチポイントツーポイント）を想定した場合、その後、フルメッシュトポロジーでN *（N-1）/ 2個の二重トンネルまたはN *（N-1）、単純ですN VPNエッジデバイスのためのトンネル。各トンネルは、VPNエッジデバイスにいくつかのリソースを消費し、トンネルのタイプに応じて、または中間ルータまたはLSRの中にリソースを消費してもしなくてもよいです。部分的なメッシュトポロジーを使用する一つの理由は、トンネルの数をVPNエッジデバイス、及び/又はネットワークを低減することで、サポートする必要があります。もう一つの理由は、管理者が監視または会計目的または、ファイアウォールを通過するトラフィックを強制するなど、ポリシーまたは制御の理由のために、いくつかの特定のサイトを横断する特定のサイトからのすべてのトラフィックを必要とするシナリオをサポートすることです。各VPNのために使用されるトポロジは別個であるので、同一のVPNエッジデバイス一VPNのフルメッシュトポロジの、および他のVPNのための部分的なメッシュトポロジの一部であってもよいことに留意されたいです。
An example of where a partial mesh topology could be suitable is for a VPN that supports a large number of telecommuters and a small number of corporate sites. Most traffic will be between telecommuters and the corporate sites, not between pairs of telecommuters. A hub and spoke topology for the VPN would thus map onto the underlying traffic flow, with the telecommuters attached to spoke VPN edge devices and the corporate sites attached to hub VPN edge devices. Traffic between telecommuters is still supported, but this traffic traverses a hub VPN edge device.
パーシャルメッシュトポロジは、適切な可能性がどこの例は、在宅勤務の多数と企業の少数のサイトをサポートしているVPNのためです。ほとんどのトラフィックはない在宅勤務のペア間、在宅勤務者や企業の部位との間になります。添付在宅勤務は、VPNエッジデバイスとハブVPNエッジデバイスに付属の企業サイトを話してVPNのためのハブとスポークトポロジは、このように、基本的なトラフィックフローにマップします。在宅勤務者間のトラフィックはまだサポートされていますが、このトラフィックは、ハブのVPNエッジデバイスを横断します。
The selection of a topology for a VPN is an administrative choice, but it is useful to examine protocol mechanisms that can be used to automate the construction of the desired topology, and thus reduce the amount of configuration needed. To this end it is useful for a VPN edge device to be able to advertise per-VPN topology information to other VPN edge devices. It may be simplest to advertise this at the same time as the membership information is advertised, using the same mechanisms.
VPNのトポロジーの選択は、管理者の選択であるが、所望のトポロジの構築を自動化するので、必要な構成の量を減少させるために使用することができるプロトコルメカニズムを調べるために有用です。 VPNエッジデバイスは、他のVPNエッジデバイスに当たり-VPNトポロジー情報を宣伝できるようにするために、この目的のために有用です。メンバーシップ情報が広告されているのと同じメカニズムを使用して、同時にこれを宣伝するのが最も簡単することができます。
A simple scheme is where a VPN edge device advertises itself either as a hub or as a spoke, for each VPN that it has. When received by other VPN edge devices this information can be used when determining whether to establish a tunnel. A more comprehensive scheme allows a VPN edge device to advertise a set of topology groups, with tunnels established between a pair of VPN edge devices if they have a group in common.
VPNエッジデバイスが持つ各VPNのために、ハブとして、またはスポークのいずれかとして自分自身を宣伝場所簡単方式です。他のVPNエッジデバイスによって受信されたときにトンネルを確立するかどうかを決定する際にこの情報を使用することができます。より包括的なスキームは、それらが共通のグループを持っている場合、VPNエッジデバイスのペア間で確立されたトンネルで、VPNエッジデバイスは、トポロジグループのセットを広告することを可能にします。
VPN solutions use tunneling in order to transport VPN packets across the VPN backbone, from one VPN edge device to another. There are different types of tunneling protocols, different ways of establishing and maintaining tunnels, and different ways to associate tunnels with VPNs (e.g., shared versus dedicated per-VPN tunnels). Sections 4.3.1 through 4.3.5 discusses some common characteristics shared by all forms of tunneling, and some common problems to which tunnels provide a solution. Section 4.3.6 provides a survey of available tunneling techniques. Note that tunneling protocol issues are generally independent of the mechanisms used for VPN membership and VPN routing.
VPNソリューションは、一つのVPNエッジデバイスから別のものに、VPNバックボーンを横切ってVPNパケットを搬送するためにトンネリングを使用します。トンネリングプロトコルトンネルを確立し、維持するためのさまざまな方法、およびVPNを使用したトンネルを関連付けるための異なる方法の異なるタイプ（例えば、専用当たり-VPNトンネルに対する共有）があります。セクション4.3.5スルー4.3.1トンネリングのすべての形態で共有いくつかの共通の特性、及びトンネルソリューションを提供するために、いくつかの共通の問題を論じています。 4.3.6は、利用可能なトンネリング技術の調査を提供します。トンネリングプロトコルの問題は、VPNメンバーシップとVPNルーティングのために使用されるメカニズムの一般独立していることに留意されたいです。
One motivation for the use of tunneling is that the packet addressing used in a VPN may have no relation to the packet addressing used between the VPN edge devices. For example the customer VPN traffic could use non-unique or private IP addressing [RFC1918]. Also an IPv6 VPN could be implemented across an IPv4 provider backbone. As such the packet forwarding between the VPN edge devices must use information other than that contained in the VPN packets themselves. A tunneling protocol adds additional information, such an extra header or label, to a VPN packet, and this additional information is then used for forwarding the packet between the VPN edge devices.
トンネリングを使用するための1つの動機は、VPNに使用されるパケットのアドレス指定は、VPNエッジデバイス間で使用されるアドレッシングパケットとは関係を持たないことです。たとえば、顧客のVPNトラフィックは、[RFC1918]を取り組む非一意またはプライベートIPを使用することができます。また、IPv6のVPNは、IPv4プロバイダーバックボーン全体で実施することができます。 VPNエッジデバイス間のこのようなパケット転送としてVPNパケット自体に含まれる以外の情報を使用しなければなりません。トンネリングプロトコルは、VPNパケットに、付加的な情報、例えばエクストラヘッダまたはラベルを追加し、この追加情報は、VPNエッジデバイス間でパケットを転送するために使用されます。
Another capability optionally provided by tunneling is that of isolation between different VPN traffic flows. The QoS and security requirements for these traffic flows may differ, and can be met by using different tunnels with the appropriate characteristics. This allows a provider to offer different service characteristics for traffic in different VPNs, or to subsets of traffic flows within a single VPN.
任意にトンネリングによって提供される別の機能は、分離の異なるVPN間のトラフィックが流れることです。これらのトラフィックフローのためのQoSおよびセキュリティ要件が異なる場合があり、適切な特性を有する別のトンネルを使用することによって満たすことができます。これは、異なるVPNに、またはトラフィックのサブセットにトラフィックに対して異なるサービス特性を提供するプロバイダは、単一のVPN内を流れることができます。
The specific tunneling protocols considered in this section are GRE, IP-in-IP, IPsec, and MPLS, as these are the most suitable for carrying VPN traffic across the VPN backbone. Other tunneling protocols, such as L2TP [RFC2661], may be used as access tunnels, carrying traffic between a PE and a CE. As backbone tunneling is independent of and orthogonal to access tunneling, protocols for the latter are not discussed here.
これらは、VPNバックボーン間でVPNトラフィックを運ぶために最も適しているとして、このセクションで考慮特定のトンネリングプロトコルは、GRE、IP-で-IP、IPsecの、およびMPLSです。そのようなL2TP [RFC2661]などの他のトンネリングプロトコルは、PEとCEの間のトラフィックを運ぶ、アクセストンネルとして使用されてもよいです。バックボーントンネルがトンネルにアクセスするための独立した直交するように、後者のためのプロトコルは、ここで説明されていません。
All tunneling protocols use an encapsulation that adds additional information to the encapsulated packet; this information is used for forwarding across the VPN backbone. Examples are provided in section 4.3.6.
すべてのトンネリングプロトコルは、カプセル化されたパケットに追加情報を追加してカプセル化を使用します。この情報は、VPNバックボーン全体で転送するために使用されています。例はセクション4.3.6で提供されます。
One characteristic of a tunneling protocol is whether per-tunnel state is needed in the SP network in order to forward the encapsulated packets. For IP tunneling schemes (GRE, IP-in-IP, and IPsec) per-tunnel state is completely confined to the VPN edge devices. Other routers are unaware of the tunnels, and forward according to the IP header. For MPLS, per-tunnel state is needed, since the top label in the label stack must be examined and swapped by intermediate LSRs. The amount of state required can be minimized by hierarchical multiplexing, and by use of multi-point to point tunnels, as discussed below.
トンネリングプロトコルの一つの特徴ごとのトンネル状態がカプセル化されたパケットを転送するために、SPネットワークで必要とされるかどうかです。 IPトンネリング方式（GRE、IPインIP、およびIPSec）ごとのトンネル状態は完全にVPNエッジデバイスに限定されます。他のルータは、IPヘッダに係るトンネルの気づいていない、およびフォワード。ラベルスタック内のトップラベルが検査され、中間のLSRによって交換されなければならないので、MPLSのために、毎トンネル状態が、必要とされます。後述するように必要な状態量が、トンネルを指すように、階層多重化することにより、マルチポイントを使用することによって最小限に抑えることができます。
Another characteristic is the tunneling overhead introduced. With IPsec the overhead may be considerable as it may include, for example, an ESP header, ESP trailer and an additional IP header. The other mechanisms listed use less overhead, with MPLS being the most lightweight. The overhead inherent in any tunneling mechanism may result in additional IP packet fragmentation, if the resulting packet is too large to be carried by the underlying link layer. As such it is important to report any reduced MTU sizes via mechanisms such as path MTU discovery in order to avoid fragmentation wherever possible.
もう一つの特徴は、導入されたトンネリングオーバーヘッドです。それは含んでいてもよいようにIPsecでオーバーヘッドがかなりあってもよく、例えば、ESPヘッダ、ESPトレーラと追加のIPヘッダ。記載されている他のメカニズムは、MPLSが最も軽量であることと、少ないオーバーヘッドを使用しています。得られたパケットは、下層のリンク層によって運ばれるには大きすぎる場合、任意のトンネリングメカニズムに固有のオーバーヘッドは、追加のIPパケットの断片化をもたらすことができます。そのようなものとして、可能な限り断片化を避けるために、このようなパスMTUディスカバリなどのメカニズムを経由して任意の減少MTUサイズを報告することが重要です。
Yet another characteristic is something we might call "transparency to the Internet". IP-based encapsulation can carry be used to carry a packet anywhere in the Internet. MPLS encapsulation can only be used to carry a packet on IP networks that support MPLS. If an MPLS-encapsulated packet must cross the networks of multiple SPs, the adjacent SPs must bilateral agreements to accept MPLS packets from each other. If only a portion of the path across the backbone lacks MPLS support, then an MPLS-in-IP encapsulation can be used to move the MPLS packets across that part of the backbone. However, this does add complexity. On the other hand, MPLS has efficiency advantages, particularly in environments where encapsulations may need to be nested.
さらに別の特徴は、私たちが「インターネットへの透明性」と呼ぶかもしれないものです。 IPベースのカプセル化はどこでもインターネットでパケットを運ぶために使用することが運ぶことができます。 MPLSカプセル化はMPLSをサポートするIPネットワーク上のパケットを運ぶために使用することができます。 MPLSカプセル化パケットは複数のSPのネットワークを横切らなければならない場合、隣接SPは双務契約は互いからMPLSパケットを受け入れなければなりません。バックボーンを横切る経路の一部のみがMPLSをサポートしていない場合、MPLS-in-IPカプセル化は、主鎖の一部を横切ってMPLSパケットを移動するために使用することができます。しかし、これは複雑さを加えるん。一方、MPLSは、特にカプセル化をネストする必要があるかもしれない環境では、効率の利点を有します。
Transparency to the Internet is sometimes a requirement, but sometimes not. This depends on the sort of service which a SP is offering to its customer.
インターネットへの透明性が、時には必要条件であるが、時にはません。これは、SPは、その顧客に提供しているサービスの種類によって異なります。
When a tunneled packet arrives at the tunnel egress, it must be possible to infer the packet's VPN from its encapsulation header. In MPLS encapsulations, this must be inferred from the packet's label stack. In IP-based encapsulations, this can be inferred from some combination of the IP source address, the IP destination address, and a "multiplexing field" in the encapsulation header. The multiplexing field might be one which was explicitly designed for multiplexing, or one that wasn't originally designed for this but can be pushed into service as a multiplexing field. For example:
トンネリングされたパケットがトンネル出口に到達すると、そのカプセル化ヘッダからパケットのVPNを推定することが可能でなければなりません。 MPLSカプセル化では、これは、パケットのラベルスタックから推測する必要があります。 IPベースのカプセル化では、これは、IPソースアドレス、IP宛先アドレス、及びカプセル化ヘッダ内の「多重化フィールド」のいくつかの組み合わせから推論することができます。多重フィールドは、明示的に多重化するために設計されたもの、または元々、このために設計されていなかったが、多重フィールドとしてサービスに押し込むことができるものであるかもしれません。例えば：
o GRE: Packets associated to VPN by source IP address, destination IP address, and Key field, although the key field was originally intended for authentication.
GRE O：キーフィールドは元々認証のために意図されていたものの、送信元IPアドレス、宛先IPアドレス、およびキーフィールドでVPNに関連するパケット。
o IP-in-IP: Packets associated to VPN by IP destination address in outer header.
IPインIP O：外部ヘッダ内のIP宛先アドレスでVPNに関連するパケット。
o IPsec: Packets associated to VPN by IP source address, IP destination address, and SPI field.
IPsecのO：IPソースアドレス、IP宛先アドレス、およびSPIフィールドでVPNに関連するパケット。
o MPLS: Packets associated to VPN by label stack.
MPLS O：ラベルスタックによってVPNに関連するパケット。
Note that IP-in-IP tunneling does not have a real multiplexing field, so a different IP destination address must be used for every VPN supported by a given PE. In the other IP-based encapsulations, a given PE need have only a single IP address, and the multiplexing field is used to distinguish the different VPNs supported by a PE. Thus the IP-in-IP solution has the significant disadvantage that it requires the allocation and assignment of a potentially large number of IP addresses, all of which have to be reachable via backbone routing.
IP内IPトンネリングが本当の多重フィールドを持っていないので、異なるIP宛先アドレスが与えられたPEでサポートされているすべてのVPNを使用しなければならないことに注意してください。他のIPベースのカプセル化では、所与のPEは、単一のIPアドレスを持つ必要があり、多重化フィールドがPEによってサポートされる異なるVPNを区別するために使用されます。したがってIPインIPソリューションは、バックボーンルーティングを介して到達可能でなければならないすべてがIPアドレスの潜在的に多数の割り当ておよび割り当てを必要とするという重大な欠点を有します。
In the following, we will use the term "multiplexing field" to refer to whichever field in the encapsulation header must is used to distinguish different VPNs at a given PE. In the IP-in-IP encapsulation, this is the destination IP address field, in the other encapsulations it is a true multiplexing field.
以下では、カプセル化ヘッダ内のいずれかのフィールドを指すために、用語「多重化フィールド」を使用する所与のPEに異なるVPNを区別するために使用されなければなりません。 IP-in-IPカプセル化では、これは他のカプセル化では、それは真の多重化フィールドで、送信先IPアドレスフィールドです。
When tunnels are established, the tunnel endpoints must agree on the multiplexing field values which are to be used to indicate that particular packets are in particular VPNs. The use of "well known" or explicitly provisioned values would not scale well as the number of VPNs increases. So it is necessary to have some sort of protocol interaction in which the tunnel endpoints agree on the multiplexing field values.
トンネルが確立されるときに、トンネルエンドポイントは、特定のパケットが特定のVPNにあることを示すために使用される多重化フィールド値に同意しなければなりません。 「周知」または明示的にプロビジョニングされた値を使用することは、VPNの数が増加するようにうまくスケールしないであろう。だから、トンネルエンドポイントは、多重フィールドの値に同意したプロトコルの相互作用のいくつかの並べ替えを持っていることが必要です。
For some tunneling protocols, setting up a tunnel requires an explicit exchange of signaling messages. Generally the multiplexing field values would be agreed upon as part of this exchange. For example, if an IPsec encapsulation is used, the SPI field plays the role of the multiplexing field, and IKE signaling is used to distribute the SPI values; if an MPLS encapsulation is used, LDP,
いくつかのトンネリングプロトコルは、トンネルを設定するシグナリングメッセージの明示的な交換を必要とします。一般的に多重化フィールドの値は、この交換の一環として合意したことになります。 IPsecのカプセル化が使用される場合、例えば、SPIフィールドは、多重化フィールドの役割を果たし、IKEシグナリングは、SPI値を配布するために使用されます。 MPLSカプセル化が使用されている場合、LDP、
CR-LDP or RSVP-TE can be used to distribute the MPLS label value used as the multiplexing field. Information about the identity of the VPN with which the tunnel is to be associated needs to be exchanged as part of the signaling protocol (e.g., a VPN-ID can be carried in the signaling protocol). An advantage of this approach is that per-tunnel security, QoS and other characteristics may also be negotiable via the signaling protocol. A disadvantage is that the signaling imposes overhead, which may then lead to scalability considerations, discussed further below.
CR-LDPまたはRSVP-TEは、多重フィールドとして使用されるMPLSラベル値を配布するために使用することができます。トンネルが関連付けられるVPNのアイデンティティに関する情報（例えば、VPN-IDは、シグナリングプロトコルで実施することができる）シグナリングプロトコルの一部として交換される必要があります。このアプローチの利点はごとトンネルセキュリティ、QoSおよび他の特徴はまた、シグナリングプロトコルを介して交渉することができることです。欠点は、次いで、拡張性の考慮につながる可能性が、シグナリングオーバーヘッド課すことで、以下でさらに論じます。
For some tunneling protocols, there is no explicit protocol interaction that sets up the tunnel, and the multiplexing field values must be exchanged in some other way. For example, for MPLS tunnels, MPLS labels can be piggybacked on the protocols used to distribute VPN routes or VPN membership information. GRE and IP-in-IP have no associated signaling protocol, and thus by necessity the multiplexing values are distributed via some other mechanism, such as via configuration, control protocol, or piggybacked in some manner on a VPN membership protocol.
いくつかのトンネリングプロトコルは、トンネルを設定する明示的なプロトコル相互作用が存在しない、多重フィールド値は他の方法で交換しなければなりません。例えば、MPLSトンネルのため、MPLSラベルはVPNルートまたはVPNメンバーシップ情報を配信するために使用されるプロトコルにピギーバックすることができます。 GREおよびIP-IPには、シグナリングプロトコルを関連付けられていないなしているので、必然的に多重化値は、構成、制御プロトコルを介してのように、いくつかの他の機構を介して配布され、またはVPNメンバーシッププロトコルに何らかの方法でピギーバック。
The resources used by the different tunneling establishment mechanisms may vary. With a full mesh VPN topology, and explicit signaling, each VPN edge device has to establish a tunnel to all the other VPN edge devices for in each VPN. The resources needed for this on a VPN edge device may be significant, and issues such as the time needed to recover following a device failure may need to be taken into account, as the time to recovery includes the time needed to reestablish a large number of tunnels.
異なるトンネル確立のメカニズムによって使用されるリソースが変化してもよいです。フルメッシュVPNトポロジー、および明示的なシグナリングを用いて、各VPNエッジデバイスは、各VPN内のすべての他のVPNエッジデバイスへのトンネルを確立しなければなりません。 VPNエッジデバイス上で、このために必要な資源が重要であってもよく、装置の故障、次のように回復するのに必要な時間などの問題は、回復までの時間が多数を再確立するのに必要な時間を含んでいるとして、考慮に入れる必要がありトンネル。
If tunnels require state to be maintained in the core of the network, it may not be feasible to set up per-VPN tunnels between all adjacent devices that are adjacent in some VPN topology. This would violate the principle that there is no per-VPN state in the core of the network, and would make the core scale poorly as the number of VPNs increases. For example, MPLS tunnels require that core network devices maintain state for the topmost label in the label stack. If every core router had to maintain one or more labels for every VPN, scaling would be very poor.
トンネルは、ネットワークのコア内に維持される状態が必要な場合、いくつかのVPNトポロジーに隣接する全ての隣接デバイス間ごと-VPNトンネルを設定することが可能ではないかもしれません。これは、ネットワークのコアにはあたり-VPNの状態が存在しないことを原則に違反すると、コアがVPNの数が増加するにつれて不十分規模になるだろう。例えば、MPLSトンネルは、コアネットワーク装置は、ラベルスタックの最上位ラベルの状態を維持することを必要とします。すべてのコアルータは、すべてのVPNのための1つ以上のラベルを維持しなければならなかった場合は、スケーリングが非常に悪くなります。
There are also scaling considerations related to the use of explicit signaling for tunnel establishment. Even if the tunneling protocol does not maintain per tunnel state in the core, the number of tunnels that a single VPN edge device needs to handle may be large, as this grows according to the number of VPNs and the number of neighbors per VPN. One way to reduce the number of tunnels in a network is to use a VPN topology other than a full mesh. However this may not always be desirable, and even with hub and spoke topologies the hubs VPN edge devices may still need to handle large numbers of tunnels.
トンネル確立のための明示的なシグナリングの使用に関連するスケーリング考慮事項もあります。トンネリングプロトコルはコアトンネル状態ごとに保持していない場合でも、これはVPNの数とVPN当たりの近隣の数に応じて大きくなるように、単一のVPNエッジ装置が処理する必要のあるトンネルの数は、大きくてもよいです。ネットワーク内のトンネルの数を減らす1つの方法は、フルメッシュ以外のVPNトポロジを使用することです。しかし、これは必ずしも望ましくないかもしれない、とさえハブとハブVPNエッジデバイスは、まだトンネルを大量に処理する必要があるかもしれトポロジを話しました。
If the core routers need to maintain any per-tunnel state at all, scaling can be greatly improved by using hierarchical tunnels. One tunnel can be established between each pair of VPN edge devices, and multiple VPN-specific tunnels can then be carried through the single "outer" tunnel. Now the amount of state is dependent only on the number of VPN edge devices, not on the number of VPNs. Scaling can be further improved by having the outer tunnels be multipoint-to-point "merging" tunnels. Now the amount of state to be maintained in the core is on the order of the number of VPN edge devices, not on the order of the square of that number. That is, the amount of tunnel state is roughly equivalent to the amount of state needed to maintain IP routes to the VPN edge devices. This is almost (if not quite) as good as using tunnels which do not require any state to be maintained in the core.
コアルータはまったくごとトンネル状態を維持する必要がある場合、スケーリングが大幅階層トンネルを使用することによって改善することができます。 1つのトンネルは、VPNエッジデバイスの各対の間に確立することができ、複数のVPN固有のトンネルが単一の「外側」トンネルを介して行うことができます。今状態の量は、VPNエッジデバイスの数ではなく、VPNの数に依存します。スケーリングは、外側トンネルがトンネルを「マージ」マルチポイント・ツー・ポイントで有することによって改善することができます。今コア内に維持されるべき状態の量は、VPNエッジデバイスの数のオーダーではなく、その数の二乗のオーダーです。すなわち、トンネル状態の量は、VPNエッジデバイスにIPルートを維持するために必要な状態量とほぼ同等です。これは、コア内に維持するためにどのような状態を必要としないトンネルを使用してほど良く（なく、かなりの場合）ほとんどです。
Using hierarchical tunnels may also reduce the amount of state to be maintained in the VPN edge devices, particularly if maintaining the outer tunnels requires more state than maintaining the per-VPN tunnels that run inside the outer tunnels.
階層的なトンネルを使用すると、外側のトンネルを維持することが外側のトンネル内で実行ごとのVPNトンネルを維持するよりも多くの状態を必要とする場合は特に、VPNエッジデバイスにおいて維持されるべき状態の量を減少させることができます。
There are other factors relevant to determining the number of VPN edge to VPN edge "outer" tunnels to use. While using a single such tunnel has the best scaling properties, using more than one may allow different QoS capabilities or different security characteristics to be used for different traffic flows (from the same or from different VPNs).
使用するVPNエッジ「外側」トンネルにVPNエッジの数を決定することに関連する他の要因があります。単一のそのようなトンネルを使用して最良のスケーリング特性を有するが、一方が異なるQoS機能を可能にするか、異なるトラフィックのために使用される異なるセキュリティ特性できるよりも多くを使用する（同じ又は異なるVPNからの）が流れます。
When tunnels are used hierarchically, the tunnels in the hierarchy may all be of the same type (e.g., an MPLS label stack) or they may be of different types (e.g., a GRE tunnel carried inside an IPsec tunnel).
トンネルが階層的に使用されている場合、階層内のトンネルはすべて同じ種類（例えば、MPLSラベルスタック）であってもよく、またはそれらは異なる種類のものであってもよい（例えば、IPsecトンネルの内部に運ばGREトンネル）。
One example using hierarchical tunnels is the establishment of a number of different IPsec security associations, providing different levels of security between a given pair of VPN edge devices. Per-VPN GRE tunnels can then be grouped together and then carried over the appropriate IPsec tunnel, rather than having a separate IPsec tunnel per-VPN. Another example is the use of an MPLS label stack. A single PE-PE LSP is used to carry all the per-VPN LSPs. The mechanisms used for label establishment are typically different. The PE-PE LSP could be established using LDP, as part or normal backbone operation, with the per-VPN LSP labels established by piggybacking on VPN routing (e.g., using BGP) discussed in sections 3.3.1.3 and 4.1.
階層的なトンネルを使用して、一例では、VPNエッジデバイスの所与の対の間の異なるレベルのセキュリティを提供し、異なるIPsecセキュリティアソシエーションの数の確立です。毎VPN GREトンネルは、その後一緒にグループ化され、その後、むしろ当たり-VPN別のIPsecトンネルを有するよりも、適切なIPsecトンネルを介して搬送することができます。別の例は、MPLSラベルスタックを使用することです。単一PE-PE LSPは全て当たり-VPN LSPを搬送するために使用されます。ラベルの確立のために使用されるメカニズムは、一般的に異なっています。 PE-PE LSPは、セクション3.3.1.3および4.1で説明した（例えば、BGPを使用して）VPNルーティングにピギーバックすることによって確立あたり-VPN LSPラベルと、一部または通常バックボーン動作として、LDPを使用して確立することができます。
Once a tunnel is established it is necessary to know that the tunnel is operational. Mechanisms are needed to detect tunnel failures, and to respond appropriately to restore service.
トンネルが確立されれば、トンネルが動作していることを知る必要があります。メカニズムは、トンネルの障害を検出するために、サービスを復元するために適切に対応するために必要とされます。
There is a potential issue regarding propagation of failures when multiple tunnels are multiplexed hierarchically. Suppose that multiple VPN-specific tunnels are multiplexed inside a single PE to PE tunnel. In this case, suppose that routing for the VPN is done over the VPN-specific tunnels (as may be the case for CE-based and VR approaches). Suppose that the PE to PE tunnel fails. In this case multiple VPN-specific tunnels may fail, and layer 3 routing may simultaneously respond for each VPN using the failed tunnel. If the PE to PE tunnel is subsequently restored, there may then be multiple VPN-specific tunnels and multiple routing protocol instances which also need to recover. Each of these could potentially require some exchange of control traffic.
複数のトンネルを階層的に多重化されているときの障害の伝播に関する潜在的な問題があります。複数のVPN固有のトンネルをPEトンネルに単一のPE内部に多重化されると仮定する。この場合、VPNのルーティングVPN固有のトンネル（CEベースおよびVRアプローチのためのケースであってもよいように）を介して行われると仮定する。 PE PEへのトンネルに障害が発生したと仮定する。この場合、複数のVPN固有のトンネルが失敗する可能性があり、およびレイヤ3ルーティングが同時に故障したトンネルを使用して各VPNのために応答することができます。 PEトンネルにPEがその後回復した場合、その後も回復する必要が複数のVPNに固有のトンネルと複数のルーティングプロトコルインスタンスが存在してもよいです。これらのそれぞれは、潜在的に制御トラフィックのいくつかの交換が必要になる場合があります。
When a tunnel fails, if the tunnel can be restored quickly, it might therefore be preferable to restore the tunnel without any response by high levels (such as other tunnels which were multiplexed inside the failed tunnels). By having high levels delay response to a lower level failed tunnel, this may limit the amount of control traffic needed to completely restore correct service. However, if the failed tunnel cannot be quickly restored, then it is necessary for the tunnels or routing instances multiplexed over the failed tunnel to respond, and preferable for them to respond quickly and without explicit action by network operators.
トンネルが失敗したときにトンネルを迅速に復元することができれば、したがって（例えば失敗したトンネルの内部に多重化された他のトンネルのような）高レベルによって任意応答なしトンネルを復元することが好ましいかもしれません。高レベルが低レベル失敗トンネルへの応答を遅らせる有することにより、これは完全に正しいサービスを復元するために必要な制御トラフィックの量を制限することができます。失敗したトンネルを迅速に復元できない場合は、それらは、迅速かつネットワークオペレータによって明示的なアクションなしに応答するためしかし、それが応答に失敗したトンネルを介して多重化トンネルまたはルーティングインスタンスのために必要な、そして好ましいです。
With most layer 3 provider-provisioned CE-based VPNs and the VR scheme, a per-VPN instance of routing is running over the tunnel, thus any loss of connectivity between the tunnel endpoints will be detected by the VPN routing instance. This allows rapid detection of tunnel failure. Careful adjustment of timers might be needed to avoid failure propagation as discussed the above. With the aggregated routing scheme, there isn't a per-VPN instance of routing running over the tunnel, and therefore some other scheme to detect loss of connectivity is needed in the event that the tunnel cannot be rapidly restored.
最も層3プロバイダプロビジョニングCEベースのVPNとVR方式で、ルーティングのあたり-VPNインスタンスは、トンネルエンドポイント間の接続性の損失は、VPNルーティングインスタンスによって検出され、したがって、トンネルを介して実行されています。これは、トンネル障害の迅速な検出を可能にします。タイマーの慎重な調整は、上記に述べたように、障害の伝播を防ぐために必要になる場合があります。集約されたルーティング方式と、トンネル上で実行中のルーティングのあたり-VPNインスタンスが存在しないため、接続の喪失を検出するためのいくつかの他の方式は、トンネルが急速に回復することができない場合に必要とされます。
Failure of connectivity in a tunnel can be very difficult to detect reliably. Among the mechanisms that can be used to detect failure are loss of the underlying connectivity to the remote endpoint (as indicated, e.g., by "no IP route to host" or no MPLS label), timeout of higher layer "hello" mechanisms (e.g., IGP hellos, when the tunnel is an adjacency in some IGP), and timeout of keep alive mechanisms in the tunnel establishment protocols (if any). However, none of these techniques provides completely reliable detection of all failure modes. Additional monitoring techniques may also be necessary.
トンネル内の接続の失敗を確実に検出することは非常に難しいことができます。例えば、（障害を検出するために使用することができるメカニズムのうち（「ホストするなしIPルート」又は全くMPLSラベルによって示されるように、例えば）リモートエンドポイントへの基礎となる接続の喪失であり、上位層「ハロー」機構のタイムアウト、IGPのhello、トンネルは、いくつかのIGPに隣接である）、およびトンネル確立プロトコル（もしあれば）にアライブ機構を保つのタイムアウト。しかし、これらの技術はいずれも、すべての故障モードの完全信頼できる検出を提供していません。追加の監視技術も必要になることがあります。
With hierarchical tunnels it may suffice to only monitor the outermost tunnel for loss of connectivity. However there may be failure modes in a device where the outermost tunnel is up but one of the inner tunnels is down.
階層トンネルとだけ接続性の損失の最も外側のトンネルを監視するために十分です。しかし、最も外側のトンネルが起動しているが、内側のトンネルの一方がダウンしているデバイスで故障モードがあってもよいです。
Tunneling mechanisms provide isolated communication between two CE-PE devices. Available tunneling mechanisms include (but are not limited to): GRE [RFC2784] [RFC2890], IP-in-IP encapsulation [RFC2003] [RFC2473], IPsec [RFC2401] [RFC2402], and MPLS [RFC3031] [RFC3035].
トンネリング機構は、二つのCE-PEデバイス間の単離された通信を提供します。利用可能なトンネリング機構は、（これらに限定されない）：GRE [RFC2784]、[RFC2890]、IP-in-IPカプセル化[RFC2003]、[RFC2473]のIPsec [RFC2401]、[RFC2402]、およびMPLS [RFC3031]、[RFC3035]。
Note that the following subsections address tunnel overhead to clarify the risk of fragmentation. Some SP networks contain layer 2 switches that enforce the standard/default MTU of 1500 bytes. In this case, any encapsulation whatsoever creates a significant risk of fragmentation. However, layer 2 switch vendors are in general aware of IP tunneling as well as stacked VLAN overhead, thus many switches practically allow an MTU of approximately 1512 bytes now. In this case, up to 12 bytes of encapsulation can be used before there is any risk of fragmentation. Furthermore, to improve TCP and NFS performance, switches that support 9K bytes "jumbo frames" are also on the market. In this case, there is no risk of fragmentation.
以下のサブセクションでは、断片化のリスクを明確にするために、トンネルのオーバーヘッドに対処することに留意されたいです。いくつかのSPネットワークは、1500バイトの標準/デフォルトMTUを強制レイヤ2スイッチを含みます。この場合、任意のカプセル化は一切断片化の重大なリスクを作成します。しかし、レイヤ2スイッチ・ベンダーは、このように多くのスイッチは、実際に今約1512バイトのMTUを可能にする、IPトンネリングの一般的な認識、ならびに積層VLANオーバーヘッドです。断片化の危険性がある前に、この場合には、カプセル化の最大12バイトを使用することができます。さらに、TCPおよびNFSのパフォーマンスを向上させるために、9Kバイトの「ジャンボフレーム」をサポートするスイッチが市場にもあります。この場合は、断片化の危険性はありません。
Generic Routing Encapsulation (GRE) specifies a protocol for encapsulating an arbitrary payload protocol over an arbitrary delivery protocol [RFC2784]. In particular, it can be used where both the payload and the delivery protocol are IP as is the case in layer 3 VPNs. A GRE tunnel is a tunnel whose packets are encapsulated by GRE.
汎用ルーティングカプセル化（GRE）は、任意の配信プロトコル[RFC2784]上の任意のペイロード・プロトコルをカプセル化するためのプロトコルを指定します。特に、レイヤ3つのVPNの場合のようにペイロード及び配信プロトコルの両方がIPである場合に使用することができます。 GREトンネルは、そのパケットをGREによってカプセル化されたトンネルです。
o Multiplexing
Oの多重化
The GRE specification [RFC2784] does not explicitly support multiplexing. But the key field extension to GRE is specified in [RFC2890] and it may be used as a multiplexing field.
GRE仕様[RFC2784]は、明示的に多重化をサポートしていません。しかし、GRE鍵フィールド拡張は[RFC2890]で指定され、それは多重化フィールドとして使用することができます。
o QoS/SLA
OのQoS / SLA
GRE itself does not have intrinsic QoS/SLA capabilities, but it inherits whatever capabilities exist in the delivery protocol (IP). Additional mechanisms, such as Diffserv or RSVP extensions [RFC2746], can be applied.
GRE自体は固有のQoS / SLA機能を持っていないが、それは能力が配信プロトコル（IP）に存在するものは何でも継承します。例えばDiffservの又はRSVP拡張機能として追加メカニズム、[RFC2746]、適用することができます。
o Tunnel setup and maintenance
Oトンネルのセットアップとメンテナンス
There is no standard signaling protocol for setting up and maintaining GRE tunnels.
設定とGREトンネルを維持するための標準的なシグナリングプロトコルはありません。
o Large MTUs and minimization of tunnel overhead
O大のMTUとトンネルオーバヘッドの最小化
When GRE encapsulation is used, the resulting packet consists of a delivery protocol header, followed by a GRE header, followed by the payload packet. When the delivery protocol is IPv4, and if the key field is not present, GRE encapsulation adds at least 28 bytes of overhead (36 bytes if key field extension is used.)
GREカプセル化を使用した場合、結果として得られるパケットは、ペイロードパケットに続くGREヘッダに続く配信プロトコルヘッダ、から成ります。配信プロトコルは、IPv4であり、キーフィールドが存在しない場合（キーフィールドの拡張が使用される場合36バイト）、GREカプセル化は、オーバーヘッドの少なくとも28バイトを追加すると
o Security
Oのセキュリティ
GRE encapsulation does not provide any significant security. The optional key field can be used as a clear text password to aid in the detection of misconfigurations, but it does not provide integrity or authentication. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. If multi-provider VPNs are being supported, it may be difficult to set up these filters.
GREカプセル化は重大なセキュリティを提供しません。オプションのキーフィールドは、設定ミスの検出を支援するためにクリアテキストのパスワードとして使用することができますが、それは整合性や認証を提供しません。 VPNをサポートしているSPネットワークがVPNを貫通から偽装されたパケットを防ぐために、その境界での大規模なIPアドレスフィルタリングを行う必要があります。マルチプロバイダのVPNがサポートされている場合、これらのフィルタを設定することは困難です。
IP-in-IP specifies the format and procedures for IP-in-IP encapsulation. This allows an IP datagram to be encapsulated within another IP datagram. That is, the resulting packet consists of an outer IP header, followed immediately by the payload packet. There is no intermediate header as in GRE. [RFC2003] and [RFC2473] specify IPv4 and IPv6 encapsulations respectively. Once the encapsulated datagram arrives at the intermediate destination (as specified in the outer IP header), it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original destination address field.
IP-IP-では、IP-in-IPカプセル化のためのフォーマットと手順を指定します。これは、IPデータグラムを別のIPデータグラム内にカプセル化することができます。すなわち、得られたパケットは、外側IPヘッダで構成されている、ペイロードパケットの直後。 GREのような中間のヘッダが存在しません。 [RFC2003]及び[RFC2473]は、それぞれ、IPv4およびIPv6カプセル化を指定します。カプセル化されたデータグラムが（外側のIPヘッダで指定されるように）中間目的地に到着すると、それは、元の宛先アドレスフィールドによって示される宛先に配信され、元のIPデータグラムを得、デカプセル化されています。
o Multiplexing
Oの多重化
The IP-in-IP specifications don't explicitly support multiplexing. But if a different IP address is used for every VPN then the IP address field can be used for this purpose. (See section 4.3.2 for detail).
IP-で-IPの仕様は、明示的に多重化をサポートしていません。異なるIPアドレスがすべてのVPNのために使用されている場合しかし、その後、IPアドレスフィールドには、この目的のために使用することができます。 （詳細はセクション4.3.2を参照してください）。
o QoS/SLA
OのQoS / SLA
IP-in-IP itself does not have intrinsic QoS/SLA capabilities, but of course it inherits whatever capabilities exist for IP. Additional mechanisms, such as RSVP extensions [RFC2764] or DiffServ extensions [RFC2983], may be used with it.
IP-IPにおける自体は、固有のQoS / SLA機能を持っていませんが、もちろんそれはIPのために存在するものは何でも能力を継承します。そのようなRSVPの拡張[RFC2764]またはDiffServの拡張[RFC2983]などの追加の機構は、それと共に使用することができます。
o Tunnel setup and maintenance
Oトンネルのセットアップとメンテナンス
There is no standard setup and maintenance protocol for IP-in-IP.
IP-で-IPのための標準的なセットアップやメンテナンスプロトコルがありません。
o Large MTUs and minimization of tunnel overhead
O大のMTUとトンネルオーバヘッドの最小化
When the delivery protocol is IPv4, IP-in-IP adds at least 20 bytes of overhead.
配信プロトコルがIPv4である場合、IPインIPオーバーヘッドの少なくとも20バイトを追加します。
o Security
Oのセキュリティ
IP-in-IP encapsulation does not provide any significant security. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. If multi-provider VPNs are being supported, it may be difficult to set up these filters.
IP-in-IPカプセル化は、重大なセキュリティを提供しません。 VPNをサポートしているSPネットワークがVPNを貫通から偽装されたパケットを防ぐために、その境界での大規模なIPアドレスフィルタリングを行う必要があります。マルチプロバイダのVPNがサポートされている場合、これらのフィルタを設定することは困難です。
IP Security (IPsec) provides security services at the IP layer [RFC2401]. It comprises authentication header (AH) protocol [RFC2402], encapsulating security payload (ESP) protocol [RFC2406], and Internet key exchange (IKE) protocol [RFC2409]. AH protocol provides data integrity, data origin authentication, and an anti-replay service. ESP protocol provides data confidentiality and limited traffic flow confidentiality. It may also provide data integrity, data origin authentication, and an anti-replay service. AH and ESP may be used in combination.
IPセキュリティ（IPsec）は、IP層[RFC2401]でセキュリティサービスを提供します。これは、認証ヘッダ（AH）プロトコル[RFC2402]、カプセル化セキュリティペイロード（ESP）プロトコル[RFC2406]、およびインターネット鍵交換（IKE）プロトコル[RFC2409]を含みます。 AHプロトコルは、データの整合性、データ発信元認証、およびアンチリプレイサービスを提供しています。 ESPプロトコルは、データの機密性と制限されたトラフィックフロー機密性を提供します。また、データの整合性、データ発信元認証、およびアンチリプレイサービスを提供することができます。 AHとESPを組み合わせて使用することができます。
IPsec may be employed in either transport or tunnel mode. In transport mode, either an AH or ESP header is inserted immediately after the payload packet's IP header. In tunnel mode, an IP packet is encapsulated with an outer IP packet header. Either an AH or ESP header is inserted between them. AH and ESP establish a unidirectional secure communication path between two endpoints, which is called a security association. In tunnel mode, PE-PE tunnel (or a CE-CE tunnel) consists of a pair of unidirectional security associations. The IPsec and IKE protocols are used for setting up IPsec tunnels.
IPsecは、トランスポートまたはトンネルモードのいずれかで使用することができます。トランスポートモードでは、AHまたはESPヘッダのいずれかが、ペイロードパケットのIPヘッダの直後に挿入されます。トンネルモードでは、IPパケットを外側IPパケットのヘッダでカプセル化されています。 AHまたはESPヘッダのいずれかが、それらの間に挿入されます。 AHとESPは、セキュリティアソシエーションと呼ばれる2つのエンドポイント間の一方向の安全な通信路を確立します。トンネルモードでは、PE-PEトンネル（またはCE-CEトンネル）が一方向セキュリティアソシエーションの組から成ります。 IPsecとIKEプロトコルは、IPsecトンネルを設定するために使用されています。
o Multiplexing
Oの多重化
The SPI field of AH and ESP is used to multiplex security associations (or tunnels) between two peer devices.
AHとESPのSPIフィールドは、2つのピアデバイス間のセキュリティアソシエーション（又はトンネル）を多重化するために使用されます。
o QoS/SLA
OのQoS / SLA
IPsec itself does not have intrinsic QoS/SLA capabilities, but it inherits whatever mechanisms exist for IP. Other mechanisms such as "RSVP Extensions for IPsec Data Flows" [RFC2207] or DiffServ extensions [RFC2983] may be used with it.
IPsecの自体は固有のQoS / SLA機能を持っていないが、それはIPのために存在するものは何でもメカニズム継承します。このような[RFC2207]またはDiffServの拡張[RFC2983]は、それと共に使用することができる、「IPsecのデータフローのためのRSVP拡張」などの他のメカニズム。
o Tunnel setup and maintenance
Oトンネルのセットアップとメンテナンス
The IPsec and IKE protocols are used for the setup and maintenance of tunnels.
IPsecとIKEプロトコルはトンネルのセットアップやメンテナンスのために使用されています。
o Large MTUs and minimization of tunnel overhead
O大のMTUとトンネルオーバヘッドの最小化
IPsec transport mode adds at least 8 bytes of overhead. IPsec tunnel mode adds at least 28 bytes of overhead. IPsec transport mode adds minimal overhead. In PE-based PPVPNs, the processing overhead of IPsec (due to its cryptography) may limit the PE's performance, especially if privacy is being provided; this is not generally an issue in CE-based PPVPNs.
IPsecトランスポート・モードは、オーバーヘッドの少なくとも8つのバイトを付加します。 IPsecトンネルモードは、オーバーヘッドの少なくとも28バイトを追加します。 IPsecトランスポートモードでは、最小のオーバーヘッドが追加されます。 PEベースPPVPNsにおいて、（これは、その暗号化に）のIPsecの処理オーバーヘッドは、プライバシーが提供されている場合は特に、PEの性能を制限することができます。これは、一般的にCEベースのPPVPNsの問題ではありません。
o Security
Oのセキュリティ
When IPsec tunneling is used in conjunction with IPsec's cryptographic capabilities, excellent authentication and integrity functions can be provided. Privacy can also be optionally provided.
IPsecのトンネルがIPsecのの暗号化機能と組み合わせて使用される場合、優れた認証と完全な機能を提供することができます。プライバシーはまた、必要に応じて提供することができます。
Multiprotocol Label Switching (MPLS) is a method for forwarding packets through a network. Routers at the edge of a network apply simple labels to packets. A label may be inserted between the data link and network headers, or may be carried in the data link header (e.g., the VPI/VCI field in an ATM header). Routers in the network switch packets according to the labels, with minimal lookup overhead. A path, or a tunnel in the PPVPN, is called a "label switched path (LSP)".
マルチプロトコルラベルスイッチング（MPLS）は、ネットワークを介してパケットを転送するための方法です。ネットワークのエッジにあるルータは、パケットにシンプルなラベルを適用します。ラベルは、データリンクとネットワークヘッダとの間に挿入することができる、またはデータ・リンク・ヘッダで運ばれてもよい（例えば、ATMヘッダ内のVPI / VCIフィールド）。ネットワーク内のルータは、最小限のルックアップオーバーヘッドで、ラベルに応じてパケットを切り替えます。パス、またはPPVPNトンネルは、「ラベルスイッチドパス（LSP）」を呼ばれます。
o Multiplexing
Oの多重化
LSPs may be multiplexed within other LSPs.
LSPは、他のLSPの中に多重化することができます。
o QoS/SLA
OのQoS / SLA
MPLS does not have intrinsic QoS or SLA management mechanisms, but bandwidth may be allocated to LSPs, and their routing may be explicitly controlled. Additional techniques such as DiffServ and DiffServ aware traffic engineering may be used with it [RFC3270] [MPLS-DIFF-TE]. QoS capabilities from IP may be inherited.
MPLSは、固有のQoSやSLA管理の仕組みを持っていませんが、帯域幅は、LSPのに割り当てることができる、と彼らのルーティングは、明示的に制御することができます。このようDiffServのとDiffServの意識トラフィックエンジニアリングなどの追加の技術はそれ[RFC3270] [MPLS-DIFF-TE]と一緒に使用することができます。 IPからのQoS機能を継承することができます。
o Tunnel setup and maintenance
Oトンネルのセットアップとメンテナンス
LSPs are set up and maintained by LDP (Label Distribution Protocol), RSVP (Resource Reservation Protocol) [RFC3209], or BGP.
LSPは、LDP（ラベル配布プロトコル）、RSVP（リソース予約プロトコル）[RFC3209]、またはBGPによって設定され、維持されています。
o Large MTUs and minimization of tunnel overhead.
O大のMTUとトンネルオーバヘッドの最小化。
MPLS encapsulation adds four bytes per label. VPN-2547BIS's [VPN-2547BIS] approach uses at least two labels for encapsulation and adds minimal overhead.
MPLSカプセル化は、ラベルごとに4つのバイトが追加されます。 VPN-2547BISの[VPN-2547BIS]アプローチは、カプセル化のために、少なくとも2つのラベルを使用し、最小のオーバーヘッドを追加します。
o Encapsulation
Oのカプセル化
MPLS packets may optionally be encapsulated in IP or GRE, for cases where it is desirable to carry MPLS packets over an IP-only infrastructure.
MPLSパケットは、必要に応じて、IPのみのインフラストラクチャ上でMPLSパケットを伝送することが望ましい場合のために、IPまたはGREでカプセル化され得ます。
o Security
Oのセキュリティ
MPLS encapsulation does not provide any significant security. An SP which is providing VPN service can refuse to accept MPLS packets from outside its borders. This provides the same level of assurance as would be obtained via IP address filtering when IP-based encapsulations are used. If a VPN is jointly provided by multiple SPs, care should be taken to ensure that a labeled packet is accepted from a neighboring router in another SP only if its top label is one which was actually distributed to that router.
MPLSカプセル化は重大なセキュリティを提供しません。 VPNサービスを提供しているSPは、その境界の外側からMPLSパケットを受け入れることを拒否することができます。これは、IPベースのカプセル化が使用される場合、IPアドレスフィルタリングを介して取得されるような保証の同じレベルを提供します。 VPNが共同で複数のSPによって提供されている場合、注意がそのトップラベルが実際にそのルータに配布されたものである場合にのみ、別のSPでの隣接ルータからラベル付きパケットが受け入れられることを保証するために取られるべきです。
o Applicability
Oの適用性
MPLS is the only one of the encapsulation techniques that cannot be guaranteed to run over any IP network. Hence it would not be applicable when transparency to the Internet is a requirement.
MPLSは、任意のIPネットワーク上で実行するように保証することはできませんカプセル化技術のうちの1つにすぎません。インターネットへの透明性が必要条件であるとき、そのためには適用されないでしょう。
If the VPN backbone consists of several cooperating SP networks which support MPLS, then the adjacent networks may support MPLS at their interconnects. If two cooperating SP networks which support MPLS are separated by a third which does not support MPLS, then MPLS-in-IP or MPLS-in-IPsec tunneling may be done between them.
VPNバックボーンは、MPLSをサポートするいくつかの協力SPネットワークで構成されている場合、隣接するネットワークは、彼らの相互接続でMPLSをサポートすることができます。 MPLSをサポートする2つの協働するSPネットワークがMPLSをサポートしていない第三によって分離されている場合、インIP MPLS-またはMPLS-内のIPsecトンネリングは、それらの間に行うことができます。
In layer 3 PE-based VPNs, PE devices examine the IP headers of packets they receive from the customer networks. Forwarding is based on routing information received from the customer network. This implies that the PE devices need to participate in some manner in routing for the customer network. Section 3.3 discussed how routing would be done in the customer network, including the customer interface. In this section, we discuss ways in which the routing information from a particular VPN may be passed, over the shared VPN backbone, among the set of PEs attaching to that VPN.
レイヤ3 PEベースのVPNにおいて、PEデバイスは、それらが顧客のネットワークからの受信パケットのIPヘッダを調べます。転送は、顧客ネットワークから受信したルーティング情報に基づいています。これは、PEデバイスは、顧客のネットワークのルーティングに何らかの形で参加する必要があることを意味します。セクション3.3は、ルーティングは、顧客インターフェースを含む、顧客のネットワーク内で行われることになる方法について議論しました。このセクションでは、我々は、特定のVPNからのルーティング情報は、そのVPNに付着PEの組のうち、共有VPNバックボーン上、通過することが可能な方法を議論します。
The PEs needs to distribute two types of routing information to each other: (i) Public Routing: routing information which specifies how to reach addresses on the VPN backbone (i.e., "public addresses"); call this "public routing information" (ii) VPN Routing: routing information obtained from the CEs, which specifies how to reach addresses ("private addresses") that are in the VPNs.
PEは、相互にルーティング情報の2種類を配布する必要があります：（I）パブリックルーティング：VPNバックボーン上のアドレス（すなわち、「パブリックアドレス」）に到達する方法を指定するルーティング情報を、この「公共のルーティング情報を、」呼び出し（ⅱ）VPNルーティング部：VPNにあるアドレス（「プライベートアドレス」）に到達する方法を指定したCE、から得られた情報をルーティング。
The way in which routing information in the first category is distributed is outside the scope of this document; we discuss only the distribution of routing information in the second category. Of course, one of the requirements for distributing VPN routing information is that it be kept separate and distinct from the public information. Another requirement is that the distribution of VPN routing information not destabilize or otherwise interfere with the distribution of public routing information.
最初のカテゴリのルーティング情報が分散される方法は、この文書の範囲外です。我々は、第二のカテゴリーでルーティング情報の唯一の分布を議論します。もちろん、VPNルーティング情報を配信するための要件の一つは、それが別々の公開情報とは別個に維持されることです。別の要件は、VPNルーティング情報の配信が不安定または他の公共のルーティング情報の配信を妨害しないことです。
Similarly, distribution of VPN routing information associated with one VPN should not destabilize or otherwise interfere with the operation of other VPNs. These requirements are, for example, relevant in the case that a private network might be suffering from instability or other problems with its internal routing, which might be propagated to the VPN used to support that private network.
同様に、一VPNに関連付けられたVPNルーティング情報の配信は、不安定化またはそうでなければ他のVPNの動作を妨害してはなりません。これらの要件は、例えば、プライベートネットワークがVPNに伝播される可能性がありますその内部ルーティング、と不安定性などの問題に苦しんでされるかもしれないという場合は、関連するが、そのプライベートネットワークをサポートするために使用される、されています。
Note that this issue does not arise in CE-based VPNs, as in CE-based VPNs, the PE devices do not see packets from the VPN until after the packets haven been encapsulated in an outer header that has only public addresses.
パケットの避難所の後にのみ、パブリックアドレスを有する外部ヘッダ内にカプセル化されるまで、CEベースのVPNにおいて、PEデバイスがVPNからのパケットが表示されないように、この問題は、CEベースのVPNでは生じないことに留意されたいです。
The following technologies can be used for exchanging VPN routing information discussed in sections 3.3.1.3 and 4.1.
以下の技術は、セクション3.3.1.3および4.1で説明したVPNルーティング情報を交換するために使用することができます。
o Static routing
Oスタティックルーティング
o RIP [RFC2453]
O [RFC2453]をRIP
o OSPF [RFC2328]
O OSPF [RFC2328]
o BGP-4 [RFC1771]
O BGP-4 [RFC1771]
In layer 3 PE-based VPNs, the PE devices receive unencapsulated IP packets from the CE devices, and the PE devices use the IP destination addresses in these packets to help make their forwarding decisions. In order to do this properly, the PE devices must obtain routing information from the customer networks. This implies that the PE device participates in some manner in the customer network's routing.
レイヤ3 PEベースのVPNでは、PEデバイスは、CEデバイスからカプセル化されていないIPパケットを受信し、PEデバイスは、その転送先を決定することを助けるためにこれらのパケットに宛先IPアドレスを使用します。これを適切に行うために、PEデバイスは、顧客ネットワークからルーティング情報を取得しなければなりません。これは、PEデバイスは、顧客ネットワークのルーティングに何らかの形で関与することを意味します。
In layer 3 PE-based VPNs, a single PE device connected to several CE devices that are in the same VPN, and it may also be connected to CE devices of different VPNs. The route which the PE chooses for a given IP destination address in a given packet will depend on the VPN from which the packet was received. A PE device must therefore have a separate forwarding table for each VPN to which it is attached. We refer to these forwarding tables as "VPN Forwarding Instances" (VFIs), as defined in section 2.1.
層3 PEベースのVPN、同じVPNにあるいくつかのCEデバイスに接続された単一のPEデバイス、及びそれはまた、異なるVPNのCEデバイスに接続することができます。 PEは、与えられたパケットに所定のIP宛先アドレスのために選択した経路は、パケットが受信されたVPNに依存するであろう。 PEデバイスは、したがって、それが結合している各VPNに対して別々の転送テーブルを有していなければなりません。我々は、セクション2.1で定義されるように、「VPN転送インスタンス」（のVFI）として、これらの転送テーブルを参照します。
A VFI contains routes to locally attached VPN sites, as well as routes to remote VPN sites. Section 4.4 discusses the way in which routes to remote sites are obtained.
VFIは、ローカル接続VPNサイトへの経路、ならびに遠隔VPNサイトへのルートを含んでいます。 4.4節では、リモートサイトへのルートが取得される方法について説明します。
Routes to local sites may be obtained in several ways. One way is to explicitly configure static routes into the VFI. This can be useful in simple deployments, but it requires that one or more devices in the customer's network be configured with static routes (perhaps just a default route), so that traffic will be directed from the site to the PE device.
ローカルサイトへのルートはいくつかの方法で得ることができます。一つの方法は、明示的にVFIにスタティックルートを設定することです。これは、単純な展開で役立つことができますが、それは、トラフィックはPEデバイスへのサイトから指示されるように、顧客のネットワーク内の1つまたは複数のデバイスは、スタティックルート（おそらく、単にデフォルトルート）で構成されている必要があります。
Another way is to have the PE device be a routing peer of the CE device, in a routing algorithm such as RIP, OSPF, or BGP. Depending on the deployment scenario, the PE might need to advertise a large number of routes to each CE (e.g., all the routes which the PE obtained from remote sites in the CE's VPN), or it might just need to advertise a single default route to the CE.
別の方法は、RIP、OSPF、またはBGPのようなルーティングアルゴリズムで、PEデバイスは、CEデバイスのルーティングピアであることです。展開シナリオによっては、PEは各CEへのルートが多数を宣伝する必要があるかもしれません（例えば、PEはCEのVPNにリモートサイトから取得したすべてのルート）、またはそれだけで単一のデフォルトルートをアドバタイズする必要がある場合がありますCEへ。
A PE device uses some resources in proportion to the number of VFIs that it has, particularly if a distinct dynamic routing protocol instance is associated with each VFI. A PE device also uses some resources in proportion to the total number of routes it supports, where the total number of routes includes all the routes in all its VFIs, and all the public routes. These scaling factors will limit the number of VPNs which a single PE device can support.
PEデバイスは、別個の動的ルーティングプロトコルのインスタンスが各VFIに関連付けられている場合は特に、それが有することのVFIの数に比例して、いくつかのリソースを使用します。 PE装置は、ルートの合計数は、すべてののVFI内のすべての経路、およびすべての公開ルートを含み、それがサポートするルートの総数に比例して、いくつかのリソースを使用します。これらのスケーリングファクタは、単一のPEデバイスがサポートできるVPNの数を制限します。
When dynamic routing is used between a PE and a CE, it is not necessarily the case that each VFI is associated with a single routing protocol instance. A single routing protocol instance may provide routing information for multiple VFIs, and/or multiple routing protocol instances might provide information for a single VFI. See sections 4.4.3, 4.4.4, 3.3.1, and 3.3.1.3 for details.
ダイナミックルーティングがPEとCEの間で使用される場合、それは必ずしも各VFIが単一のルーティングプロトコルインスタンスに関連付けられている場合ではありません。単一のルーティングプロトコルインスタンスは、複数のVFIのルーティング情報を提供することができる、及び/又は複数のルーティングプロトコルインスタンスは、単一のVFIのための情報を提供するかもしれません。セクション4.4.3、4.4.4、詳細については、3.3.1、および3.3.1.3を参照してください。
There are several options for how VPN routes are carried between the PEs, as discussed below.
以下に説明するようにVPNルートは、PE間で実施されている方法には、いくつかのオプションがあります。
One option is to operate separate instances of routing protocols between the PEs, one instance for each VPN. When this is done, routing protocol packets for each customer network need to be tunneled between PEs. This uses the same tunneling method, and optionally the same tunnels, as is used for transporting VPN user data traffic between PEs.
一つの選択肢は、PES、各VPNのための1つのインスタンス間のルーティングプロトコルの別のインスタンスを動作させることです。これが行われると、各顧客ネットワークのルーティングプロトコルパケットは、PE間でトンネリングする必要があります。これは、同じトンネリング方式を使用して、PE間VPNユーザデータトラフィックを搬送するために使用されるように、同じトンネルを任意。
With per-VPN routing, a distinct routing instance corresponding to each VPN exists within the corresponding PE device. VPN-specific tunnels are set up between PE devices (using the control mechanisms that were discussed in sections 3 and 4). Logically these tunnels are between the VFIs which are within the PE devices. The tunnels then used as if they were normal links between normal routers. Routing protocols for each VPN operate between VFIs and the routers within the customer network.
ごとのVPNルーティングと、各VPNに対応する別個のルーティングインスタンスは、対応するPEデバイス内に存在します。 VPN固有のトンネルは、PEデバイス（セクション3と4で説明した制御機構を使用して）との間に設定されています。論理的にこれらのトンネルは、PEデバイス内にあるのVFIの間です。彼らは通常のルータ間の通常のリンクであるかのようにトンネルは、その後に使用しました。各VPNのルーティングプロトコルは、顧客のネットワーク内でのVFIとルータ間で動作します。
This approach establishes, for each VPN, a distinct "control plane" operating across the VPN backbone. There is no sharing of control plane by any two VPNs, nor is there any sharing of control plane by the VPN routing and the public routing. With this approach each PE device can logically be thought of as consisting of multiple independent routers.
このアプローチは、各VPN、VPNバックボーンを横切る動作の異なる「制御プレーン」を確立します。任意の2つのVPNによる制御プレーンは共有されません、またVPNルーティングおよび公共のルーティングにより、コントロールプレーンのいずれかの共有があります。このアプローチでは、各PEデバイスが論理的に複数の独立したルータから成ると考えることができます。
The multiple routing instances within the PE device may be separate processes, or may be in the same process with different data structures. Similarly, there may be mechanisms internal to the PE devices to partition memory and other resources between routing instances. The mechanisms for implementing multiple routing instances within a single physical PE are outside of the scope of this framework document, and are also outside of the scope of other standards documents.
PEデバイス内の複数のルーティングインスタンスは、別個のプロセスであってもよいし、異なるデータ構造と同一のプロセスであってもよいです。同様に、ルーティングインスタンス間メモリおよび他のリソースを分割するPEデバイスの内部機構が存在してもよいです。単一の物理PE内の複数のルーティングインスタンスを実装するためのメカニズムは、このフレームワーク文書の範囲外であり、他の規格文書の範囲外でもあります。
This approach tends to minimize the explicit interactions between different VPNs, as well as between VPN routing and public routing. However, as long as the independent logical routers share the same hardware, there is some sharing of resources, and interactions are still possible. Also, each independent control plane has its associated overheads, and this can raise issues of scale. For example, the PE device must run a potentially large number of independent routing "decision processes," and must also maintain a potentially very large number of routing adjacencies.
このアプローチは、同様にVPNルーティングおよびパブリックルーティング間など、異なるVPN間の明示的な相互作用を最小にする傾向があります。しかし、限り、独立した論理ルータは、同じハードウェアを共有して、リソースのいくつかの共有があり、かつ相互作用はまだ可能です。また、それぞれの独立した制御プレーンは、それに関連するオーバーヘッドを持っており、これは規模の問題を提起することができます。例えば、PEデバイス「は、意思決定プロセス」の独立したルーティングの潜在的に大きな数を実行する必要があり、また、ルーティング隣接関係の潜在的に非常に大きな数を維持しなければなりません。
Another option is to use one single instance of a routing protocol for carrying VPN routing information between the PEs. In this method, the routing information for multiple different VPNs is aggregated into a single routing protocol.
別のオプションは、PE間のVPNルーティング情報を運ぶためのルーティングプロトコルの単一のインスタンスを使用することです。この方法では、複数の異なるVPNのルーティング情報は、単一のルーティングプロトコルに集約されます。
This approach greatly reduces the number of routing adjacencies which the PEs must maintain, since there is no longer any need to maintain more than one such adjacency between a given pair of PEs. If the single routing protocol supports a hierarchical route distribution mechanism (such as BGP's "route reflectors"), the PE-PE adjacencies can be completely eliminated, and the number of backbone adjacencies can be made into a small constant which is independent of the number of PE devices. This improves the scaling properties.
PEの所与の対の間に複数のそのような隣接関係を維持する必要がなくなるので、このアプローチは大きく、PEが維持しなければならないルーティング隣接の数を低減しません。単一のルーティングプロトコルは、階層のルート分布（例えばBGPの「ルートリフレクタ」のような）メカニズムをサポートする場合、PE-PEの隣接関係を完全になくすことができ、そして骨格の隣接の数が数とは無関係である小さな一定にすることができますPEデバイスの。これは、スケーリング特性を向上させます。
Additional routing instances may still be needed to support the exchange of routing information between the PE and its locally attached CEs. These can be eliminated, with a consequent further improvement in scalability, by using static routing on the PE-CE interfaces, or possibly by having the PE-CE routing interaction use the same protocol instance that is used to distribute VPN routes across the VPN backbone (see section 4.4.4.2 for a way to do this).
追加のルーティングインスタンスは依然としてPEとそのローカル接続のCE間のルーティング情報の交換をサポートするために必要とされてもよいです。これらは、PE-CEインターフェイス上でスタティックルーティングを使用することによって、又はおそらくはPE-CEルーティング相互作用がVPNバックボーンを横切ってVPNルートを配布するために使用される同じプロトコルインスタンスを使用して有することにより、スケーラビリティにおける結果として更なる向上と、除去することができます（これを行う方法についてはセクション4.4.4.2を参照）。
With this approach, the number of routing protocol instances in a PE device does not depend on the number of CEs supported by the PE device, if the routing between PE and CE devices is static or BGP-4. However, CE and PE devices in a VPN exchange route information inside a VPN using a routing protocol except for BGP-4, the number of routing protocol entities in a PE device depends on the number of CEs supported by the PE device.
PEとCEデバイス間のルーティングは、静的またはBGP-4の場合は、このアプローチを用いて、PE装置におけるルーティングプロトコルのインスタンスの数は、PEデバイスによってサポートされるCEの数に依存しません。しかしながら、BGP-4以外のルーティングプロトコルを使用してVPN内部VPN交換経路情報におけるCEおよびPEデバイスは、PEデバイスにおけるルーティングプロトコルエンティティーの数は、PEデバイスによってサポートされるCEの数に依存します。
In principle it is possible for routing to be aggregated using either BGP or on an IGP.
ルーティングはBGPまたはIGPのいずれかを使用して凝集するため、原理的には可能です。
When supporting VPNs, it is likely that there can be a large number of VPNs supported within any given SP network. In general only a small number of PE devices will be interested in the operation of any one VPN. Thus while the total amount of routing information related to the various customer networks will be very large, any one PE needs to know about only a small number of such networks.
VPNをサポートする場合は、任意のSPネットワーク内でサポートのVPNが多数存在できることがあります。一般に、PEデバイスのほんの数は、いずれかのVPNの動作に興味を持つであろう。様々な顧客のネットワークに関連するルーティング情報の総量が非常に大きくなりつつしたがって、いずれかのPEは、そのようなネットワークのほんの数について知る必要があります。
Generally SP networks use OSPF or IS-IS for interior routing within the SP network. There are very good reasons for this choice, which are outside of the scope of this document.
一般SPネットワークは、OSPFを使用するか、SPネットワーク内の内部ルーティングのためにIS-IS。この文書の範囲外であるこの選択のための非常に良い理由があります。
Both OSPF and IS-IS are link state routing protocols. In link state routing, routing information is distributed via a flooding protocol. The set of routing peers is in general not fully meshed, but there is a path from any router in the set to any other. Flooding ensures that routing information from any one router reaches all the others. This requires all routers in the set to maintain the same routing information. One couldn't withhold any routing information from a particular peer unless it is known that none of the peers further downstream will need that information, and in general this cannot be known.
OSPFやIS-ISの両方がリンクステートルーティングプロトコルです。リンク状態ルーティングでは、ルーティング情報をフラッディングプロトコルを介して分配されます。ルーティングピアのセットが完全に噛合しない一般的であるが、他のセット内の任意のルータからの経路があります。洪水は、いずれかのルータからのルーティング情報が他のすべてに到達することを保証します。これは、同じルーティング情報を維持するために、セット内のすべてのルータが必要です。ピアのいずれもさらに下流その情報を必要としないであろうことが知られていない限り一つは、特定のピアからの任意のルーティング情報を差し控えることができなかった、そして一般的に、これは知ることができません。
As a result, if one tried to do aggregated routing by using OSPF, with all the PEs in the set of routing peers, all the PEs would end up with the exact same routing information; there is no way to constrain the distribution of routing information to a subset of the PEs. Given the potential magnitude of the total routing information required for supporting a large number of VPNs, this would have unfortunate scaling implications.
一つは、ルーティングピアのセット内のすべてのPEと、OSPFを使用して集約ルーティングを実行しようとした場合、結果として、全てのPEはまったく同じルーティング情報で終わるだろう。 PEのサブセットにルーティング情報の配布を制限する方法はありません。 VPNの大規模な数をサポートするために必要な総ルーティング情報の潜在的な大きさを考えると、これは不幸なスケーリング意味合いを持っているでしょう。
In some cases VPNs may span multiple areas within a provider, or span multiple providers. If VPN routing information were aggregated into the IGP used within the provider, then some method would need to be used to extend the reach of IGP routing information between areas and between SPs.
いくつかのケースでのVPNは、プロバイダ内の複数の領域にまたがる、または複数のプロバイダにまたがることがあります。 VPNルーティング情報は、プロバイダ内で使用されるIGPに集約した場合、いくつかの方法は、領域間とSPの間IGPルーティング情報の範囲を拡張するために使用される必要があるであろう。
In order to use BGP for aggregated routing, the VPN routing information must be clearly distinguished from the public Internet routing information. This is typically done by making use of BGP's capability of handling multiple address families, and treating the VPN routes as being in a different address family than the public Internet routes. Typically a VPN route also carries attributes which depend on the particular VPN or VPNs to which that route belongs.
集約されたルーティングにBGPを使用するためには、VPNルーティング情報は、ルーティング情報を公衆インターネットから明確に区別する必要があります。これは通常、複数のアドレスファミリーを処理し、公共のインターネットルートとは異なるアドレスファミリにあるものとしてVPNルートを治療するBGPの能力を利用することによって行われます。典型的には、VPN経路は、特定のVPNまたはその経路が属するVPNの依存属性を運びます。
When BGP is used for carrying VPN information, the total amount of information carried in BGP (including the Internet routes and VPN routes) may be quite large. As noted above, there may be a large number of VPNs which are supported by any particular provider, and the total amount of routing information associated with all VPNs may be quite large. However, any one PE will in general only need to be aware of a small number of VPNs. This implies that where VPN routing information is aggregated into BGP, it is desirable to be able to limit which VPN information is distributed to which PEs.
BGPは、VPN情報を運ぶために使用される場合、（インターネットルートとVPNの経路を含む）BGPで運ばれる情報の総量が非常に大きくてもよいです。上述したように、任意の特定のプロバイダによってサポートされているVPNの多数、および非常に大きくすることができるすべてのVPNに関連付けられたルーティング情報の合計量が存在してもよいです。しかし、いずれのPEは、一般的にのみVPNの小さな数を認識する必要があります。これは、VPNルーティング情報をBGPに集約されている場合、どのPEに分散されたVPN情報を制限することができることが望ましいことを意味します。
In "Interior BGP" (IBGP), routing information is not flooded; it is sent directly, over a TCP connection, to the peer routers (or to a route reflector). These peer routers (unless they are route reflectors) are then not even allowed to redistribute the information to each other. BGP also has a comprehensive set of mechanisms for constraining the routing information that any one peer sends to another, based on policies established by the network administration. Thus IBGP satisfies one of the requirements for aggregated routing within a single SP network - it makes it possible to ensure that routing information relevant to a particular VPN is processed only by the PE devices that attach to that VPN. All that is necessary is that each VPN route be distributed with one or more attributes which identify the distribution policies. Then distribution can be constrained by filtering against these attributes.
「内部BGP」（IBGP）において、ルーティング情報をフラッディングされません。これは、ピアルータに（またはルートリフレクタに）、TCP接続を介して、直接送信されます。これらのピアルータは、（それらがルートリフレクタでない限り）をも相互に情報を再配布することはできません。 BGPはまた、いずれかのピアがネットワーク管理によって確立されたポリシーに基づいて、他に送信するルーティング情報を拘束するための機構の包括的なセットを有しています。したがってIBGP満たす単一のSPネットワーク内集約ルーティングの要件のいずれかを - それは、特定のVPNに関連するルーティング情報のみそのVPNに接続PEデバイスによって処理されることを保証することができます。必要であるすべてが各VPNルートが配布ポリシーを識別する1つの以上の属性と一緒に配布されていることです。そして、分布は、これらの属性に対するフィルタリングによって制約することができます。
In "Exterior BGP" (EBGP), routing peers do redistribute routing information to each other. However, it is very common to constrain the distribution of particular items of routing information so that they only go to those exterior peers who have a "need to know," although this does require a priori knowledge of which paths may validly lead to which addresses. In the case of VPN routing, if a VPN is provided by a small set of cooperating SPs, such constraints can be applied to ensure that the routing information relevant to that VPN does not get distributed anywhere it doesn't need to be. To the extent that a particular VPN is supported by a small number of cooperating SPs with private peering arrangements, this is particularly straightforward, as the set of EBGP neighbors which need to know the routing information from a particular VPN is easier to determine.
「外装BGP」（EBGP）において、ルーティングピアは、互いにルーティング情報を再配布します。しかし、彼らが唯一持っているそれらの外部ピアに行くようにルーティング情報の特定の項目の分布を制限するために、これはパスが有効に対処しているにつながる可能性があるの事前知識を必要としないものの「知っておく必要がありますが、」非常に一般的です。 VPNは、SPの協働の小さなセットによって提供される場合VPNルーティングの場合には、そのような制約は、そのVPNに関連するルーティング情報がどこでも、それはである必要はなく、分散されないことを保証するために適用することができます。特定のVPNは、プライベートピアリングの手配をSPの協力の小さな数でサポートされている限り、これはVPNを判断しやすくなり、特定のルーティング情報を知っておく必要がありEBGPネイバーのセットとして、特に簡単です。
BGP also has mechanisms (such as "Outbound Route Filtering," ORF) which enable the proper set of VPN routing distribution constraints to be dynamically distributed. This reduces the management burden of setting up the constraints, and hence improves scalability.
BGPはまた、動的に配信するVPNルーティング分布制約の適切なセットを有効にする（例えば、「アウトバウンドルートフィルタリング、」ORFなど）機構を有しています。これは、制約を設定するための管理負担を軽減し、したがってスケーラビリティが向上します。
Within a single routing domain (in the layer 3 VPN context, this typically means within a single SP's network), it is common to have the IBGP routers peer directly with one or two route reflectors, rather than having them peer directly with each other. This greatly reduces the number of IBGP adjacencies which any one router must support. Further, a route reflector does not merely redistribute routing information, it "digests" the information first, by running its own decision processes. Only routes which survive the decision process are redistributed.
単一のルーティングドメイン内では、IBGPルータではなく、それらが互いに直接ピア有するより1つのまたは2つのルートリフレクタと直接ピア有することが一般的である（レイヤ3 VPNコンテキストでは、これは、典型的には、単一のSPのネットワーク内を意味します）。これは非常にいずれかのルータがサポートしなければならないIBGP隣接関係の数を減らすことができます。さらに、ルートリフレクタは、単にルーティング情報を再配布しない、それはそれ自身の意思決定プロセスを実行することによって、第1の情報を「ダイジェスト」。決定プロセスを生き残る唯一のルートが再配布されています。
As a result, when route reflectors are used, the amount of routing information carried around the network, and in particular, the amount of routing information which any given router must receive and process, is greatly reduced. This greatly increases the scalability of the routing distribution system.
結果として、ルートリフレクタが使用される場合、ネットワーク持ち運びルーティング情報の量、特には、任意のルータが受信して処理しなければならないルーティング情報の量は、大幅に低減されます。これは、大幅にルーティング配信システムのスケーラビリティを増大させます。
It has already been stated that a given PE has VPN routing information only for those PEs to which it is directly attached. It is similarly important, for scalability, to ensure that no single route reflector should have to have all the routing information for all VPNs. It is after all possible for the total number of VPN routes (across all VPNs supported by an SP) to exceed the number which can be supported by a single route reflector. Therefore, the VPN routes may themselves be partitioned, with some route reflectors carrying one subset of the VPN routes and other route reflectors carrying a different subset. The route reflectors which carry the public Internet routes can also be completely separate from the route reflectors that carry the VPN routes.
既に与えられたPEのみ、それが直接結合されているもののPEのためのVPNルーティング情報を有していることを述べました。これは、単一のルートリフレクタは、すべてのVPNのすべてのルーティング情報を有する必要がないべきであることを確実にするために、スケーラビリティのために、同様に重要です。 （SPによってサポートされるすべてのVPNを横切る）VPNルートの合計数は、単一のルートリフレクタによってサポートされ得る数を超過することが結局可能です。したがって、VPNルート自体は、いくつかのVPNルートの一つのサブセットを搬送するルートリフレクタと異なるサブセットを有する他のルートリフレクタと、分割されてもよいです。公共のインターネットルートを搬送ルートリフレクタはまた、VPNルートを搬送ルートリフレクタから完全に分離することができます。
The use of outbound route filters allows any one PE and any one route reflector to exchange information about only those VPNs which the PE and route reflector are both interested in. This in turn ensures that each PE and each route reflector receives routing information only about the VPNs which it is directly supporting. Large SPs which support a large number of VPNs therefore can partition the information which is required for support of those VPNs.
アウトバウンドルートフィルタの使用は、任意の1つのPEとPEとルートリフレクタの両方に興味があるだけのVPNについての情報を交換するためのいずれかのルートリフレクタを可能にする。この順番で各PEと各ルートリフレクタのみについてのルーティング情報を受信することを保証それが直接サポートしているVPNの。したがって、VPNの多くをサポートする大規模なSPは、これらのVPNをサポートするために必要とされる情報を分割することができます。
Generally a PE device will be restricted in the total number of routes it can support, whether those are public Internet routes or VPN routes. As a result, a PE device may be able to be attached to a larger number of VPNs if it does not also need to support Internet routes.
一般PEデバイスは、それらが公共のインターネットルートまたはVPNルートであるかどうか、それがサポートすることができる経路の数に制限されます。また、インターネットルートをサポートする必要がない場合は、結果として、PEデバイスは、VPNのより多くに結合することができるようにしてもよいです。
The way in which VPN routes are partitioned among PEs and/or route reflectors is a deployment issue. With suitable deployment procedures, the limited capacity of these devices will not limit the number of VPNs that can be supported.
VPNルートをPEと/またはルートリフレクタの間で分配される方法は、配置の問題です。適したデプロイメント・プロシージャを使用すると、これらのデバイスの限られた容量をサポートすることができるVPNの数を制限しません。
Similarly, whether a given PE and/or route reflector contains Internet routes as well as VPN routes is a deployment issue. If the customer networks served by a particular PE do not need the Internet access, then that PE does not need to be aware of the Internet routes. If some or all of the VPNs served by a particular PE do need the Internet access, but the PE does not contain Internet routes, then the PE can maintain a default route that routes all the Internet traffic from that PE to a different router within the SP network, where that other router holds the full the Internet routing table. With this approach the PE device needs only a single default route for all the Internet routes.
同様に、PEを与え、および/またはルートリフレクタは、インターネット経路、ならびにVPNルートが含まれているかどうかデプロイメントの問題です。特定のPEが提供する顧客のネットワークは、インターネットへのアクセスを必要としない場合は、そのPEは、インターネットルートを意識する必要はありません。特定のPEが提供するVPNの一部またはすべてがインターネットアクセスが必要ですが、PEは、インターネットルートが含まれていない場合は、PEは、デフォルトルートを維持することができる内の異なるルータへのルートそのPEからのすべてのインターネットトラフィックを他のルータがフルインターネットルーティングテーブルを保持しているSPネットワーク。このアプローチではPEデバイスは、すべてのインターネットルートの唯一のデフォルトルートを必要とします。
For the reasons given above, the BGP protocol seems to be a reasonable protocol to use for distributing VPN routing information. Additional reasons for the use of BGP are:
上記の理由のために、BGPプロトコルは、VPNルーティング情報を配信するために使用する合理的なプロトコルであると思われます。 BGPを使用するための追加的な理由は以下のとおりです。
o BGP has been proven to be useful for distributing very large amounts of routing information; there isn't any routing distribution protocol which is known to scale any better.
O BGPは、ルーティング情報の非常に大きな金額を配布するために有用であることが証明されています。任意のより良いをスケーリングすることが知られている任意のルーティング配布プロトコルは存在しません。
o The same BGP instance that is used for PE-PE distribution of VPN routes can be used for PE-CE route distribution, if CE-PE routing is static or BGP. PEs and CEs are really parts of distinct Autonomous Systems, and BGP is particularly well-suited for carrying routing information between Autonomous Systems.
CE-PEルーティングが静的またはBGPであればO VPNルートのPE-PE分布のために使用される同一のBGPインスタンスは、PE-CE経路配布のために使用することができます。 PEとCEは実際に異なる自律システムの一部であり、BGPは、特に、自律システム間でルーティング情報を運ぶに適しています。
On the other hand, BGP is also used for distributing public Internet routes, and it is crucially important that VPN route distributing not compromise the distribution of public Internet routes in any way. This issue is discussed in the following section.
一方、BGPはまた、公共のインターネットルートを配布するために使用され、VPNルートがどのような方法で公共のインターネットルートの分布を損なわない配布することを決定的に重要です。この問題は、次のセクションで説明されています。
For layer 3 PE-based VPNs, there are likely to be cases where a service provider supports Internet access over the same link that is used for VPN service. Thus, a particular CE to PE link may carry both private network IP packets (for transmission between sites of the private network using VPN services) as well as public Internet traffic (for transmission from the private site to the Internet, and for transmission to the private site from the Internet). This section looks at the scalability and stability of routing in this case. It is worth noting that this sort of issue may be applicable where per-VPN routing is used, as well as where aggregated routing is used.
レイヤ3 PEベースのVPNの場合は、サービスプロバイダは、VPNサービスに使用されるのと同じリンク上でのインターネットアクセスをサポートしています例がある可能性が高いです。このように、PEリンクに特定のCEは、（VPNサービスを利用して、プライベートネットワークのサイト間の伝送のための）プライベートネットワークのIPパケットだけでなく、公共のインターネットトラフィック（インターネットにプライベートサイトからの送信のために、とに送信するための両方を運ぶことができますインターネットからプライベートサイト）。このセクションでは、この場合には、ルーティングのスケーラビリティと安定性を調べます。 VPNごとのルーティングを使用する場合、問題のこの種は、適用してもよいことは注目に値する、と同様に集約されたルーティングが使用されます。
For layer 3 PE-based VPNs, it is necessary for the PE devices to be able to forward IP packets using the addresses spaces of the supported private networks, as well as using the full Internet address space. This implies that PE devices might in some cases participate in routing for the private networks, as well as for the public Internet.
レイヤ3 PEベースのVPNの場合は、PEデバイスがサポートされるプライベートネットワークのアドレス空間を使用して、だけでなく、完全なインターネットアドレス空間を使用してIPパケットを転送できるようにするために必要です。これは、PEデバイスがいくつかのケースでは、公衆インターネットのためだけでなく、プライベートネットワークのルーティングに参加可能性があることを意味します。
In some cases the routing demand on the PE might be low enough, and the capabilities of the PE, might be great enough, that it is reasonable for the PE to participate fully in routing for both private networks and the public Internet. For example, the PE device might participate in normal operation of BGP as part of the global Internet. The PE device might also operate routing protocols (or in some cases use static routing) to exchange routes with CE devices.
いくつかのケースではPE上のルーティング需要は十分に低いかもしれない、とPEの機能は、PEは、プライベートネットワークとパブリックインターネットの両方のルーティングに全面的に参加することが妥当であることを、十分に素晴らしいことかもしれません。例えば、PEデバイスは、グローバルなインターネットの一部としてBGPの通常の動作に関与する可能性があります。 PEデバイスは、ルーティングプロトコルを動作させる（またはいくつかの場合にスタティックルーティングを使用）CEデバイスとルートを交換するかもしれません。
For large installations, or where PE capabilities are more limited, it may be undesirable for the PE to fully participate in routing for both VPNs as well as the public Internet. For example, suppose that the total volume of routes and routing instances supported by one PE across multiple VPNs is very large. Suppose furthermore that one or more of the private networks suffers from routing instabilities, for example resulting in a large number of routing updates being transmitted to the PE device. In this case it is important to prevent such routing from causing any instability in the routing used in the global Internet.
PE能力がより制限されている場合にPEが完全に両方のVPNならびに公共のインターネットのルーティングに参加するための大規模なインストールのために、または、それは望ましくない場合があります。例えば、複数のVPNを横切って1つのPEによってサポートされたルートとルーティングインスタンスの総体積が非常に大きいと仮定する。プライベートネットワークの1つ以上がPE装置に送信されるルーティング更新の多数を生じる、例えば、ルーティング不安定性に苦しんでいることをさらに仮定する。この場合、グローバルインターネットで使用されるルーティングの任意の不安定性を引き起こすことから、このようなルーティングを防止することが重要です。
In these cases it may be necessary to partition routing, so that the PE does not need to maintain as large a collection of routes, and so that the PE is not able to adversely effect Internet routing. Also, given that the total number of route prefixes and the total number of routing instances which the PE needs to maintain might be very large, it may be desirable to limit the participation in Internet routing for those PEs which are supporting a large number of VPNs or which are supporting large VPNs.
これらのケースでは、PEは、経路のような大規模なコレクションを維持する必要はなく、したがってPE効果インターネットルーティングに悪影響を与えることができないこととなるよう、ルーティングを分割する必要があるかもしれません。また、PEは維持する必要がある経路プレフィックスの総数とルーティングインスタンスの総数が非常に大きいかもしれないことを考えると、VPNの多くをサポートしているそれらのPEのためのインターネット・ルーティングへの参加を制限することが望ましいかもしれませんまたは大規模なVPNをサポートしています。
Consider a case where a PE is supporting a very large number of VPNs, some of which have a large number of sites. To pick a VERY large example, let's suppose 1000 VPNs, with an average of 100 sites each, plus 10 prefixes per site on average. Consider that the PE also needs to be able to route traffic to the Internet in general. In this example the PE might need to support approximately 1,000,000 prefixes for the VPNs, plus more than 100,000 prefixes for the Internet. If augmented and aggregated routing is used, then this implies a large number of routes which may be advertised in a single routing protocol (most likely BGP). If the VR approach is used, then there are also 100,000 neighbor adjacencies in the various per-VPN routing protocol instances. In some cases this number of routing prefixes and/or this number of adjacencies might be difficult to support in one device.
PEがサイトの数が多いいくつかのVPNの非常に大きな数をサポートしている場合を考えます。非常に大規模な例を選択する、のは、100個のサイトそれぞれ、プラス平均でサイトごとに10件のプレフィックスの平均で、1000のVPNを仮定してみましょう。 PEはまた、一般的にインターネットにトラフィックをルーティングすることができる必要があることを考えてみましょう。この例では、PEは、インターネットのためのVPNの約1,000,000接頭辞、プラス10万の以上のプレフィックスをサポートする必要がある場合があります。増強および凝集ルーティングが使用される場合、これは単一のルーティングプロトコル（最も可能性が高いBGP）でアドバタイズすることができる経路の数が多いことを意味します。 VRのアプローチが使用される場合、様々な単位のVPNルーティングプロトコルインスタンス100,000ネイバー隣接関係もあります。いくつかのケースでは、ルーティングプレフィックス及び/又は隣接のこの数のこの数は、一つのデバイスでサポートすることは困難かもしれません。
In this case, an alternate approach is to limit the PE's participation in Internet routing to the absolute minimum required: Specifically the PE will need to know which Internet address prefixes are reachable via directly attached CE devices. All other Internet routes may be summarized into a single default route pointing to one or more P routers. In many cases the P routers to which the default routes are directed may be the P routers to which the PE device is directly attached (which are the ones which it needs to use for forwarding most Internet traffic). Thus if there are M CE devices directly connected to the PE, and if these M CE devices are the next hop for a total of N globally addressable Internet address prefixes, then the PE device would maintain N+1 routes corresponding to globally routable Internet addresses.
具体的にはPEが直接接続CEデバイスを介して到達可能であるインターネットアドレスプレフィックス知っておく必要があります。この場合、別のアプローチが必要最小限にインターネットルーティングにおけるPEの参加を制限することです。他のすべてのインターネットルートは、一つ以上のPルータを指し示す単一のデフォルトルートにまとめることができます。多くの場合、デフォルトルートが向けられたPルータは、（それがほとんどのインターネットトラフィックを転送するために使用する必要があるものである）、PEデバイスが直接接続されたPルータであってもよいです。したがってそこに直接PEに接続されたM個のCEデバイスがあり、これらのM CEデバイスは、N、グローバルにアドレス指定可能なインターネットアドレスプレフィックスの合計次のホップである場合、次にPEデバイスはN + 1つのルートは、ルーティング可能なインターネットアドレスをグローバルに対応する維持する場合。
In this example, those PE devices which provide VPN service run routing to compute routes for the VPNs, but don't operate Internet routing, and instead use only a default route to route traffic to all Internet destinations (not counting the addresses which are reachable via directly attached CE devices). The P routers need to maintain Internet routes, and therefore take part in Internet routing protocols. However, the P routers don't know anything about the VPN routes.
この例では、VPNサービスの実行ルーティングを提供これらのPEデバイスが到達可能なアドレスをカウントしない（すべてのインターネット宛先にトラフィックをルーティングするためにのみデフォルトルートを使用する代わりに、VPNのルートを計算するが、インターネットルーティングを操作しないでください、と直接接続されたCEデバイス経由）。 Pルータは、インターネットルートを維持するため、インターネット・ルーティング・プロトコルに参加する必要があります。しかし、PルータはVPNルートについては何も知りません。
In some cases the maximum number of routes and/or routing instances supportable via a single PE device may limit the number of VPNs which can be supported by that PE. For example, in some cases this might require that two different PE devices be used to support VPN services for a set of multiple CEs, even if one PE might have had sufficient throughput to handle the data traffic from the full set of CEs. Similarly, the amount of resources which any one VPN is permitted to use in a single PE might be restricted.
いくつかの場合において、単一のPEデバイスを介して支援ルート及び/又はルーティングインスタンスの最大数は、そのPEによってサポートすることができるVPNの数を制限することができます。例えば、いくつかのケースでは、これは二つの異なるPEデバイスは、1個のPEがCEのフルセットからのデータトラフィックを処理するのに十分なスループットを持っていたかもしれない場合でも、複数のCEのセットのためのVPNサービスをサポートするために使用することが必要かもしれません。同様に、いずれかのVPNは、単一のPEに使用することが許可されているリソースの量が制限されるかもしれません。
There will be cases where it is not necessary to partition the routing, since the PEs will be able to maintain all VPN routes and all Internet routes without a problem. However, it is important that VPN approaches allow partitioning to be used where needed in order to prevent future scaling problems. Again, making the system scalable is a matter of proper deployment.
PEは問題なく、すべてのVPNルートとすべてのインターネットルートを維持することができるようになりますから、ルーティングを分割する必要がない場合があります。しかし、VPNのアプローチは、将来のスケーリングの問題を防ぐために、必要な場所にパーティションを使用できるようにすることが重要です。ここでも、システムはスケーラブル作ることは、適切な展開の問題です。
It may be wondered whether it is ever desirable to have both Internet routing and VPN routing running in a single PE device or route reflector. In fact, if there is even a single system running both Internet routing and VPN routing, doesn't that raise the possibility that a disruption within the VPN routing system will cause a disruption within the Internet routing system?
インターネットのルーティングおよび単一PEデバイスまたはルートリフレクタで実行VPNルーティングの両方を有することがこれまで望まれるかどうかを疑問に思っていてもよいです。実際には、両方のインターネット・ルーティングとVPNルーティングを実行している単一のシステム、それがVPNルーティングシステム内の混乱は、インターネットのルーティングシステム内の混乱の原因となる可能性を提起していなくてもそこにありますか？
Certainly this possibility exists in theory. To minimize that possibility, BGP implementations which support multiple address families should be organized so as to minimize the degree to which the processing and distribution of one address family affects the processing and distribution of another. This could be done, for example, by suitable partitioning of resources. This partitioning may be helpful both to protect Internet routing from VPN routing, and to protect well behaved VPN customers from "mis-behaving" VPNs. Or one could try to protect the Internet routing system from the VPN routing system by giving preference to the Internet routing. Such implementation issues are outside the scope of this document. If one has inadequate confidence in an implementation, deployment procedures can be used, as explained above, to separate the Internet routing from the VPN routing.
確かにこの可能性は、理論的には存在しています。一つのアドレスファミリの処理及び配布は、別の処理や分布に影響する度合いを最小化するようにその可能性を最小限にするために、複数のアドレスファミリーをサポートするBGPの実装では、組織化されなければなりません。これは、リソースを適切に分配することにより、例えば、行うことができます。このパーティションは、VPNルーティングからインターネットルーティングを保護するために、そして「ミスな振舞い」のVPNから行儀VPNの顧客を保護するために、両方の役に立つかもしれません。または1つは、インターネットルーティングに優先を与えることによってVPNルーティングシステムからインターネットルーティングシステムを保護しようとすることができます。このような実装上の問題は、この文書の範囲外です。一つの実装では不十分な自信を持っている場合は、上記説明したように、展開手順は、VPNルーティングからインターネットルーティングを分離するために、使用することができます。
The following technologies for QoS/SLA may be applicable to PPVPNs.
QoSの/ SLAについては、以下の技術がPPVPNsにも適用することができます。
Integrated services, or IntServ for short, is a mechanism for providing QoS/SLA by admission control. RSVP is used to reserve network resources. The network needs to maintain a state for each reservation. The number of states in the network increases in proportion to the number of concurrent reservations.
統合サービス、略してイントサーブ、アドミッション制御でのQoS / SLAを提供するためのメカニズムです。 RSVPは、ネットワークリソースを予約するために使用されます。ネットワークは、各予約の状態を維持する必要があります。ネットワーク内の状態の数は、同時の予約の数に比例して増加します。
In some cases, IntServ on the edge of a network (e.g., over the customer interface) may be mapped to DiffServ in the SP network.
いくつかのケースでは、ネットワークのエッジ上のIntServ（例えば、顧客インターフェースを介して）SPネットワーク内のDiffServにマッピングすることができます。
IP differentiated service, or DiffServ for short, is a mechanism for providing QoS/SLA by differentiating traffic. Traffic entering a network is classified into several behavior aggregates at the network edge and each is assigned a corresponding DiffServ codepoint. Within the network, traffic is treated according to its DiffServ codepoint. Some behavior aggregates have already been defined. Expedited forwarding behavior [RFC3246] guarantees the QoS, whereas assured forwarding behavior [RFC2597] differentiates traffic packet precedence values.
略してIP差別化サービス、またはDiffServは、トラフィックを微分したQoS / SLAを提供するためのメカニズムです。ネットワークに入るトラフィックは、ネットワークのエッジでいくつかの動作凝集体に分類され、それぞれが対応のDiffServコードポイントが割り当てられます。ネットワーク内では、トラフィックがそののDiffServコードポイントに従って処理されます。いくつかの行動の集合体は、すでに定義されています。確実な転送動作は、[RFC2597]は、トラフィックパケットの優先順位値を区別に対し優先転送の振舞い[RFC3246]は、QoSを保証します。
When DiffServ is used, network provisioning is done on a per-traffic-class basis. This ensures a specific class of service can be achieved for a class (assuming that the traffic load is controlled). All packets within a class are then treated equally within an SP network. Policing is done at input to prevent any one user from exceeding their allocation and therefore defeating the provisioning for the class as a whole. If a user exceeds their traffic contract, then the excess packets may optionally be discarded, or may be marked as "over contract". Routers throughout the network can then preferentially discard over contract packets in response to congestion, in order to ensure that such packets do not defeat the service guarantees intended for in contract traffic.
DiffServのを使用する場合は、ネットワークのプロビジョニングごとのトラフィッククラス単位で行われます。これは、サービスの特定のクラスは、（トラフィック負荷が制御されると仮定して）クラスを達成することができる保証します。クラス内のすべてのパケットはSPネットワーク内で同様に扱われます。ポリシングは、それらの割り当てを超え、したがって、全体としてのクラスのプロビジョニングを破ってからいずれかのユーザを防ぐために、入力で行われます。ユーザーが自分のトラフィック契約を超えた場合、超過パケットは、必要に応じて破棄してもよいし、「契約オーバー」としてマークすることができます。ネットワーク全体のルータは、優先的に、このようなパケットが契約トラフィックのために意図サービス保証を倒すことがないようにするために、混雑に応じて契約のパケット上で破棄することができます。
In some scenarios, customers will need to concurrently have access to their VPN network and to the public Internet.
いくつかのシナリオでは、顧客が同時に彼らのVPNネットワークに、パブリックインターネットへのアクセスを持っている必要があります。
Two potential problems are identified in this scenario: the use of private addresses and the potential security threads.
プライベートアドレスを使用すると、潜在的なセキュリティスレッド：二つの潜在的な問題は、このシナリオで識別されます。
o The use of private addresses
プライベートアドレスの使用O
The IP addresses used in the customer's sites will possibly belong to a private routing realm, and as such be unusable in the public Internet. This means that a network address translation function (e.g., NAT) will need to be implemented to allow VPN customers to access the Public Internet.
お客様のサイトで使用されるIPアドレスは、おそらくプライベートルーティング領域に属し、そのように公共のインターネットでは使用できなくなります。これは、ネットワークアドレス変換機能（例えば、NAT）はVPNの顧客は、公衆インターネットへのアクセスを許可するために実装する必要があることを意味します。
In the case of layer 3 PE-based VPNs, this translation function will be implemented in the PE to which the CE device is connected. In the case of layer 3 provider-provisioned CE-based VPNs, this translation function will be implemented on the CE device itself.
レイヤ3 PEベースのVPNの場合には、この翻訳機能は、CE機器が接続されるPEに実装されるであろう。レイヤ3プロバイダプロビジョニングCEベースのVPNの場合には、この翻訳機能は、CE装置自体上に実装されます。
o Potential security threat
O潜在的なセキュリティ上の脅威
As portions of the traffic that flow to and from the public Internet are not necessarily under the SP's nor the customer's control, some traffic analyzing function (e.g., a firewall function) will be implemented to control the traffic entering and leaving the VPN.
公共のインターネットへとからの流れトラフィックの部分は必ずしもSPのも顧客の管理下にないため、一部のトラフィック解析機能（例えば、ファイアウォール機能）は、トラフィック入りを制御するために実装し、VPNを去ることになります。
In the case of layer 3 PE-based VPNs, this traffic analyzing function will be implemented in the PE device (or in the VFI supporting a specific VPN), while in the case of layer 3 provider provisioned CE-based VPNs, this function will be implemented in the CE device.
層3プロバイダプロビジョニングCEベースのVPNの場合、この関数はなるがレイヤ3 PEベースのVPNの場合には、このトラフィック解析機能は、PEデバイス（または特定のVPNをサポートVFIで）に実施されますCEデバイスに実装すること。
o Handling of a customer IP packet destined for the Internet
インターネット宛ての顧客IPパケットのO処理
In the case of layer 3 PE-based VPNs, an IP packet coming from a customer site will be handled in the corresponding VFI. If the IP destination address in the packet's IP header belongs to the Internet, multiple scenarios are possible, based on the adapted policy. As a first possibility, when Internet access is not allowed, the packet will be dropped. As a second possibility, when (controlled) Internet access is allowed, the IP packet will go through the translation function and eventually through the traffic analyzing function before further processing in the PE's global Internet forwarding table.
レイヤ3 PEベースのVPNの場合には、顧客サイトからのIPパケットは、対応するVFIで処理されるであろう。パケットのIPヘッダ内のIP宛先アドレスは、インターネットに属している場合は、複数のシナリオは適応ポリシーに基づいて、可能です。インターネットへのアクセスが許可されていない第一の可能性として、パケットはドロップされます。 （制御）インターネットアクセスが許可されているときに、第2の可能性として、IPパケットは、PEのグローバルなインターネット転送テーブルにさらに処理する前に、翻訳機能を通じて、最終的にトラフィック分析機能を通過します。
Note that different implementation choices are possible. One can choose to implement the translation and/or the traffic analyzing function in every VFI (or CE device in the context of layer 3 provider-provisioned CE-based VPNs), or alternatively in a subset or even in only one VPN network element. This would mean that the traffic to/from the Internet from/to any VPN site needs to be routed through that single network element (this is what happens in a hub and spoke topology for example).
異なる実装の選択が可能であることに注意してください。一つは、翻訳及び/又は、あるいはサブセットで、あるいは一方のみVPNネットワーク要素内のすべてのVFIにおけるトラフィック分析機能（レイヤ3プロバイダプロビジョニングCEベースのVPNのコンテキストまたはCEデバイス）を実装するために選択することができます。これは、（これはハブで発生し、例えば、トポロジを話したものです）に/インターネットから/から任意のVPNサイトへのトラフィックは、その単一のネットワーク要素を経由してルーティングする必要があることを意味します。
Network and customer management systems responsible for managing VPN networks have several challenges depending on the type of VPN network or networks they are required to manage.
VPNネットワークの管理を担当するネットワークと顧客管理システムは、それらが管理するのに必要とされるVPNネットワークやネットワークの種類に応じて、いくつかの課題があります。
For any type of provider-provisioned VPN it is useful to have one place where the VPN can be viewed and optionally managed as a whole. The NMS may therefore be a place where the collective instances of a VPN are brought together into a cohesive picture to form a VPN. To be more precise, the instances of a VPN on their own do not form the VPN; rather, the collection of disparate VPN sites together forms the VPN. This is important because VPNs are typically configured at the edges of the network (i.e., PEs) either through manual configuration or auto-configuration. This results in no state information being kept in within the "core" of the network. Sometimes little or no information about other PEs is configured at any particular PE.
プロバイダープロビジョニングVPNのいずれかのタイプのためには、VPNを閲覧し、必要に応じて、全体として管理することができる一つの場所があると便利です。 NMSは、したがって、VPNの集合インスタンスはVPNを形成するために凝集画像に一緒にされる場所であってもよいです。具体的には、自分でVPNのインスタンスは、VPNを形成しません。むしろ、異種のVPNサイトのコレクションが一緒にVPNを構成しています。 VPNのは、典型的には、手動設定または自動設定を介してネットワークのエッジ（すなわち、PES）で構成されているので、これは重要です。これは、ネットワークの「コア」内に保持されない状態情報をもたらします。時々他のPE約ほとんどまたは全く情報は、任意の特定のPEで構成されています。
Support of any one VPN may span a wide range of network equipment, potentially including equipment from multiple implementors. Allowing a unified network management view of the VPN therefore is simplified through use of standard management interfaces and models. This will also facilitate customer self-managed (monitored) network devices or systems.
いずれかのVPNのサポートは、潜在的に複数の実装から機器を含む、ネットワーク機器の広い範囲に及ぶことができます。従って、標準的な管理インタフェースとモデルの使用によって簡略化されたVPNの統合ネットワーク管理ビューを可能にします。これは、顧客の自己管理（監視対象）ネットワーク機器やシステムを容易にするであろう。
In cases where significant configuration is required whenever a new service is provisioned, it is important for scalability reasons that the NMS provide a largely automated mechanism for this operation. Manual configuration of VPN services (i.e., new sites, or re-provisioning existing ones), could lead to scalability issues, and should be avoided. It is thus important for network operators to maintain visibility of the complete picture of the VPN through the NMS system. This must be achieved using standard protocols such as SNMP, XML, or LDAP. Use of proprietary command-line interfaces has the disadvantage that proprietary interfaces do not lend themselves to standard representations of managed objects.
新しいサービスがプロビジョニングされるたびに重要な設定が必要な場合には、NMSは、この操作のための大部分が自動化されたメカニズムを提供し、スケーラビリティの理由から重要です。 VPNサービス（すなわち、新しいサイト、または再プロビジョニング既存のもの）の手動設定は、スケーラビリティの問題につながる可能性があり、避けるべきです。ネットワークオペレータはNMSシステムを通じてVPNの全体像の可視性を維持することがことが重要です。これは、SNMP、XML、またはLDAPなどの標準プロトコルを使用して達成されなければなりません。独自のコマンドライン・インタフェースを使用すると、独自のインターフェイスは、管理対象オブジェクトの標準表現に向いていないという欠点があります。
To achieve the goals outlined above for network and customer management, device implementors should employ standard management interfaces to expose the information required to manage VPNs. To this end, devices should utilize standards-based mechanisms such as SNMP, XML, or LDAP to achieve this goal.
ネットワークと顧客管理のために上記で概説した目標を達成するには、デバイスの実装は、VPNを管理するために必要な情報を公開するための標準的な管理インターフェイスを採用する必要があります。このため、デバイスは、この目標を達成するために、このようなSNMP、XML、またはLDAPなどの標準ベースのメカニズムを利用する必要があります。
Segregated access of VPNs information is important in that customers sometimes require access to information in several ways. First, it is important for some customers (or operators) to access PEs, CEs or P devices within the context of a particular VPN on a per-VPN-basis in order to access statistics, configuration or status information. This can either be under the guise of general management, operator-initiated provisioning, or SLA verification (SP, customer or operator).
顧客は時々いくつかの方法で情報へのアクセスを必要とする中でのVPN情報の分別アクセスが重要です。まず、統計、構成やステータス情報にアクセスするためにあたり-VPN-基づいて、特定のVPNのコンテキスト内のPE、CEのかPデバイスにアクセスするために一部の顧客（または事業者）のために重要です。これは一般的な管理、オペレータ起動プロビジョニング、またはSLA検証（SP、顧客またはオペレータ）を装ってのいずれかであり得ます。
Where users outside of the SP have access to information from PE or P devices, managed objects within the managed devices must be accessible on a per-VPN basis in order to provide the customer, the SP or the third party SLA verification agent with a high degree of security and convenience.
SPの外部ユーザがPEまたはP・デバイスからの情報へのアクセスを持っている場合は、高いと顧客、SPまたは第三者SLA検証剤を提供するために、あたり-VPNベースでアクセスできる必要があり、管理対象デバイス内のオブジェクトを管理しますセキュリティと利便性の程度。
Security may require authentication or encryption of network management commands and information. Information hiding may use encryption or may isolate information through a mechanism that provides per-VPN access. Authentication or encryption of both requests and responses for managed objects within a device may be employed. Examples of how this can be achieved include IPsec tunnels, SNMPv3 encryption for SNMP-based management, or encrypted telnet sessions for CLI-based management.
セキュリティ、ネットワーク管理コマンドおよび情報の認証や暗号化が必要な場合があります。情報隠蔽は、暗号化を使用したりごとのVPNアクセスを提供するメカニズムを介して情報を隔離することができます。デバイス内の管理対象オブジェクトの両方の要求と応答の認証や暗号化を使用することができます。これを実現する方法の例としては、IPsecトンネル、SNMPベースの管理のためのSNMPv3の暗号化、またはCLIベースの管理のための暗号化されたTelnetセッションが含まれます。
In the case of information isolation, any one customer should only be able to view information pertaining to its own VPN or VPNs. Information isolation can also be used to partition the space of managed objects on a device in such a way as to make it more convenient for the SP to manage the device. In certain deployments, it is also important for the SP to have access to information pertaining to all VPNs, thus it may be important for the SP to create virtual VPNs within the management domain which overlap across existing VPNs.
情報分離の場合には、いずれかの顧客は、独自のVPNまたはVPNに関連する情報を表示することができなければなりません。情報の分離は、デバイスを管理するためのSPのためにそれをより便利にするような方法で、デバイス上の管理対象オブジェクトのスペースを分割するために使用することができます。 SPは、既存のVPN間で重複する管理ドメイン内の仮想VPNを作成するためにSPがすべてのVPNに関連する情報へのアクセス権を持っているため、特定の展開では、それはまた重要である。したがって、それは重要であるかもしれません。
If the user is allowed to change the configuration of their VPN, then in some cases customers may make unanticipated changes or even mistakes, thereby causing their VPN to mis-behave. This in turn may require an audit trail to allow determination of what went wrong and some way to inform the carrier of the cause.
ユーザーが自分のVPNの設定を変更することが許可されている場合は、いくつかのケースでは、顧客は、それによって誤動作するように自分のVPNを引き起こし、予期せぬ変更あるいは間違いを犯すことがあります。これは、順番に何が悪かったのかの決意と原因のキャリアを通知するいくつかの方法を可能にするために、監査証跡が必要な場合があります。
The segregation and security access of information on a per-VPN basis is also important when the carrier of carrier's paradigm is employed. In this case it may be desirable for customers (i.e., sub-carriers or VPN wholesalers) to manage and provision services within their VPNs on their respective devices in order to reduce the management overhead cost to the carrier of carrier's SP. In this case, it is important to observe the guidelines detailed above with regard to information hiding, isolation and encryption. It should be noted that there may be many flavors of information hiding and isolation employed by the carrier of carrier's SP. If the carrier of carriers SP does not want to grant the sub-carrier open access to all of the managed objects within their PEs or P routers, it is necessary for devices to provide network operators with secure and scalable per-VPN network management access to their devices. For the reasons outlined above, it therefore is desirable to provide standard mechanisms for achieving these goals.
キャリアのパラダイムのキャリアを採用した場合につき-VPNベースでの情報の分離とセキュリティのアクセスも重要です。この場合、キャリアのSPのキャリアへの管理オーバーヘッドコストを削減するために、それぞれのデバイス上のそれらのVPN内の顧客（即ち、サブキャリアまたはVPN卸売業者）を管理し、提供サービスのために望ましいかもしれません。この場合、情報隠蔽、分離および暗号化に関しては上記の詳細なガイドラインを遵守することが重要です。キャリアのSPのキャリアで採用情報隠蔽と隔離の多くのフレーバーがあるかもしれないことに留意すべきです。キャリアSPのキャリアは自分のPEまたはPルータ内で管理オブジェクトのすべてのサブキャリアのオープンアクセスを許可したくない場合はデバイスがへのセキュアでスケーラブルあたり-VPNネットワーク管理アクセスとネットワーク事業者に提供することが必要です自分のデバイス。上記で概説した理由のために、したがって、これらの目標を達成するための標準メカニズムを提供することが望ましいです。
This section describes interworking between different layer 3 VPN approaches. This may occur either within a single SP network, or at an interface between SP networks.
このセクションでは、異なるレイヤ3 VPNアプローチとの間のインターワーキングを記述する。これは、単一のSPネットワーク内、またはSPネットワークとの間のインタフェースのいずれかで起こり得ます。
Figure 2.5 (see section 2.1.3) illustrates a case where one or more PE devices sits at the logical interface between two different layer 3 VPN approaches. With this approach the interworking function occurs at a PE device which participates in two or more layer 3 VPN approaches. This might be physically located at the boundary between service providers, or might occur at the logical interface between different approaches within a service provider.
図2.5（セクション2.1.3を参照のこと）は、1つまたは複数のPEデバイスは、2つの異なるレイヤ3 VPNアプローチとの間の論理インタフェースに座った場合を示しています。このアプローチでは、インターワーキング機能は、二つ以上のレイヤ3 VPNアプローチに参加するPEデバイスで起こります。これは、物理的にサービスプロバイダーとの境界に位置するかもしれない、またはサービスプロバイダ内の異なるアプローチの間の論理インタフェースで発生する可能性があります。
With layer 3 VPNs, the PE devices are in general layer 3 routers, and are able to forward layer 3 packets on behalf of one or more private networks. For example, it may be common for a PE device supporting layer 3 VPNs to contain multiple logical VFIs (sections 1, 2, 3.3.1, 4.4.2) each of which supports forwarding and routing for a private network.
レイヤ3 VPNでは、PEデバイスは、一般的なレイヤ3台のルータであり、1つまたは複数のプライベートネットワークに代わってレイヤ3つのパケットを転送することができます。例えば、プライベートネットワークの転送及びルーティングをサポートそれぞれが複数の論理のVFI（セクション1、2、3.3.1、4.4.2）を含有する層3つのVPNをサポートするPEデバイスのための共通であってもよいです。
The PE which implements an interworking function needs to participate in the normal manner in the operation of multiple approaches for supporting layer 3 VPNs. This involves the functions discussed elsewhere in this document, such as VPN establishment and maintenance, VPN tunneling, routing for the VPNs, and QoS maintenance.
インターワーキング機能を実現するPEは、レイヤ3つのVPNを支持するための複数のアプローチの操作で通常の方法で参加する必要があります。これは、VPNの確立および維持、VPNトンネル、VPNのルーティング、およびQoSメンテナンスとして、この文書の他の箇所で論じた機能を、含みます。
VPN establishment and maintenance information, as well as VPN routing information will need to be passed between VPN approaches. This might involve passing of information between approaches as part of the interworking function. Optionally this might involve manual configuration so that, for example, all of the participants in the VPN on one side of the interworking function considers the PE performing the interworking function to be the point to use to contact a large number of systems (comprising all systems supported by the VPN located on the other side of the interworking function).
VPNの確立及び保守情報、ならびにVPNルーティング情報は、VPNアプローチの間を通過する必要があります。これは、インターワーキング機能の一部としてのアプローチの間の情報の受け渡しを伴うかもしれません。例えば、インターワーキング機能の片側にVPNの参加者のすべてが、PEは（すべてのシステムを含む、多数のシステムに連絡するために使用する点であるインターワーキング機能を実行考慮するように必要に応じて、これは手動設定を含むかもしれませんインターワーキング機能の反対側に位置するVPN）によって支持されています。
Figure 2.6 (see section 2.1.3) illustrates a case where interworking is performed by use of tunnels between PE devices. In this case each PE device participates in the operation of one layer 3 VPN approach. Interworking between approaches makes use of per-VPN tunnels set up between PE. Each PEs operates as if it is a normal PEs, and considers each tunnel to be associated with a particular VPN.
図2.6は、（セクション2.1.3を参照）のインターワーキングがPEデバイス間のトンネルを用いて行われる場合を示しています。この場合、各PEデバイスが一つの層3 VPNアプローチの操作に関与します。アプローチの間のインターワーキングは、PE間に設定あたり-VPNトンネルを使用しています。各PEは、それが通常のPEであるかのように動作し、特定のVPNに関連付けられる各トンネルを考慮する。
Information can then be transmitted over the interworking interface in the same manner that it is transmitted over a CE to PE interface.
情報は、それがPEインタフェースにCEを介して送信されるのと同じ方法で、インターワーキングインターフェースを介して送信することができます。
In some cases establishment of the interworking interfaces may require manual configuration, for example to allow each PE to determine which tunnels should be set up, and which private network is associated with each tunnel.
いくつかの場合において、インターワーキングインターフェースの確立は、各PEは、トンネルが設定されるべきであり、かつ、プライベートネットワークは、各トンネルに関連付けられているかを決定できるようにするために、例えば、手動設定を必要とし得ます。
In order to implement an interworking interface between two SP networks for supporting one or more PPVPN spanning both SP networks, a mechanism for exchanging customer data as well as associated control data (e.g., routing data) should be provided.
両方のSPネットワークにまたがるPPVPN一つ以上を支持するための2つのSPネットワーク間のインターワーキングインターフェースを実現するために、顧客データ、ならびに関連する制御データ（例えば、ルーティングデータ）を交換するためのメカニズムが提供されるべきです。
Since PEs of SP networks to be interworked may only communicate over a network cloud, an appropriate tunnel established through the network cloud will be used for exchanging data associated with the PPVPN realized by interworked SP networks.
インターワーキングするSPネットワークのPEが唯一のネットワーククラウドを介して通信することができるので、ネットワーククラウドを介して確立された適切なトンネルは、インターワーキングSPネットワークによって実現PPVPNに関連するデータを交換するために使用されます。
In this way, each interworking tunnel is assigned to an associated layer 3 PE-based VPN; in other words, a tunnel is terminated by a VFI (associated with the PPVPN) in a PE device. This scenario results in implementation of traffic isolation for PPVPNs supported by an Interworking Interface and spanning multiple SP networks (in each SP network, there is no restriction in applied technology for providing PPVPN so that both sides may adopt different technologies). The way of the assignment of each tunnel for a PE-based VPN is specific to implementation technology used by the SP network that is inter-connected to the tunnel at the PE device.
このように、各インターワーキングトンネルは、関連するレイヤ3 PEベースのVPNに割り当てられます。換言すれば、トンネルはPEデバイスで（PPVPNに関連する）VFIによって終了されます。このシナリオでは、インターワーキングインターフェーススパニング複数SPネットワークによってサポートPPVPNsのトラフィック分離の実装になる（各SPネットワークにおいて、両側が異なる技術を採用することができるようにPPVPNを提供するための応用技術に制限がありません）。 PEベースのVPNの各トンネルの割り当ての方法は、PEデバイスでトンネルに相互接続されているSPのネットワークによって使用される実装技術に固有です。
The identifier of layer 3 PE-based VPN at each end is meaningful only in the context of the specific technology of an SP network and need not be understood by another SP network interworking through the tunnel.
各端部層3 PEベースのVPNの識別子は、SPネットワークの特定技術の文脈で意味があり、トンネルを介して他のSPネットワークのインターワーキングによって理解される必要はありません。
The following tunneling mechanisms may be used at the interworking interface. Available tunneling mechanisms include (but are not limited to): GRE, IP-in-IP, IP over ATM, IP over FR, IPsec, and MPLS.
以下トンネリングメカニズムは、インターワーキングインターフェースで使用することができます。利用可能なトンネリングメカニズムが含まれます（ただし、これらに限定されない）：FR、IPsecの、およびMPLSオーバーGRE、IP-で-IP、ATM上でIP、IPを。
o GRE
お Ｇれ
The tunnels at interworking interface may be provided by GRE [RFC2784] with key and sequence number extensions [RFC2890].
インターワーキングインターフェースにおけるトンネルは、キーとシーケンス番号の拡張子を持つGRE [RFC2784]、[RFC2890]で提供されてもよいです。
o IP-in-IP
O IP・イン・IP
The tunnels at interworking interface may be provided by IP-in-IP [RFC2003] [RFC2473].
インターワーキングインターフェースにおけるトンネルは、IPインIP [RFC2003]、[RFC2473]で提供されてもよいです。
o IP over ATM AAL5
ATM AAL5の上にIP O
The tunnels at interworking interface may be provided by IP over ATM AAL5 [RFC2684] [RFC2685].
インターワーキングインターフェースにおけるトンネルはATM AAL5 [RFC2684]、[RFC2685]の上にIPによって提供することができます。
o IP over FR
FRオーバーIP O
The tunnels at interworking interface may be provided by IP over FR.
インターワーキング・インタフェースのトンネルはFRの上にIPによって提供されてもよいです。
o IPsec
IPsecの上
The tunnels at interworking interface may be provided by IPsec [RFC2401] [RFC2402].
インターワーキングインターフェースにおけるトンネルは、IPsec [RFC2401]、[RFC2402]で提供されてもよいです。
o MPLS
MPLS
The tunnels at interworking interface may be provided by MPLS [RFC3031] [RFC3035].
インターワーキングインターフェースにおけるトンネルはMPLS [RFC3031]、[RFC3035]で提供されてもよいです。
This subsection describes additional usages for supporting QoS/SLA, customer visible routing, and customer visible multicast routing, as services of layer 3 PE-based VPNs spanning multiple SP networks.
ここでは、複数のSPネットワークにまたがる層3 PEベースのVPNのサービスとしてのQoS / SLA、顧客可視ルーティング、顧客可視マルチキャストルーティングをサポートするための追加の用途を記載しています。
o QoS/SLA
OのQoS / SLA
QoS/SLA management mechanisms for GRE, IP-in-IP, IPsec, and MPLS tunnels were discussed in sections 4.3.6 and 4.5. See these sections for details. FR and ATM are capable of QoS guarantee. Thus, QoS/SLA may also be supported at the interworking interface.
GREのためのQoS / SLA管理メカニズムは、IP・イン・IP、IPsecの、およびMPLSトンネルは、セクション4.3.6と4.5で議論されました。詳細については、これらのセクションを参照してください。 FRとATMは、QoS保証が可能です。したがって、QoSの/ SLAはまた、インターワーキングインターフェースでサポートされてもよいです。
o Customer visible routing
Oカスタマー可視ルーティング
As described in section 3.3, customer visible routing enables the exchange of unicast routing information between customer sites using a routing protocol such as OSPF, IS-IS, RIP, and BGP-4. On the interworking interface, routing packets, such as OSPF packets, are transmitted through a tunnel associated with a layer 3 PE-based VPN in the same manner as that for user data packets within the VPN.
セクション3.3で説明したように、顧客の可視ルーティングは、OSPFなどのルーティングプロトコルを使用して、顧客サイトとの間のユニキャストルーティング情報の交換を可能にRIP、IS-IS、およびBGP-4。インターワーキングインターフェース上で、そのようなOSPFパケットとしてルーティングパケットは、VPN内のユーザデータパケットと同じ方法で層3 PEベースのVPNに関連付けられたトンネルを介して送信されます。
o Customer visible multicast routing
Oカスタマー可視マルチキャストルーティング
Customer visible multicast routing enables the exchange of multicast routing information between customer sites using a routing protocol such as DVMRP and PIM. On the interworking interface, multicast routing packets are transmitted through a tunnel associated with a layer 3 PE-based VPN in the same manner as that for user data packets within the VPN. This enables a multicast tree construction within the layer 3 PE-based VPN.
顧客可視マルチキャストルーティングは、DVMRPおよびPIMなどのルーティングプロトコルを使用して、顧客サイトとの間のマルチキャストルーティング情報の交換を可能にします。インターワーキングインターフェース上で、マルチキャストルーティングパケットは、VPN内のユーザデータパケットのと同様にレイヤ3 PEベースのVPNに関連付けられたトンネルを介して送信されます。これは、レイヤ3 PEベースのVPN内のマルチキャストツリーの構築を可能にします。
This subsection discusses scalability aspect of the interworking scenario.
ここでは、インターワーキングシナリオのスケーラビリティの側面について説明します。
o Number of routing protocol instances
ルーティングプロトコルインスタンスのO数
In the interworking scenario discussed in this section, the number of routing protocol instances and that of layer 3 PE-based VPNs are the same. However, the number of layer 3 PE-based VPNs in a PE device is limited due to resource amount and performance of the PE device. Furthermore, each tunnel is expected to require some bandwidth, but total of the bandwidth is limited by the capacity of a PE device; thus, the number of the tunnels is limited by the capabilities of the PE. This limit is not a critical drawback.
このセクションで説明するインターワーキングシナリオでは、ルーティングプロトコルのインスタンスの数及びその層の3 PEベースのVPNは同じです。しかし、PEデバイスにおける層3 PEベースのVPNの数は、リソース量とPE装置の性能に限定されます。また、各トンネルは、いくつかの帯域幅を必要とすると予想されるが、帯域幅の合計は、PEデバイスの容量によって制限されます。したがって、トンネルの数は、PEの能力によって制限されます。この制限は重大な欠点ではありません。
o Performance of packet transmission
パケット送信のOパフォーマンス
The interworking scenario discussed in this section does not place any additional burden on tunneling technologies used at interworking interface. Since performance of packet transmission depends on a tunneling technology applied, it should be carefully selected when provisioning interworking. For example, IPsec places computational requirements for encryption/decryption.
このセクションで説明するインターワーキングシナリオは、インターワーキング・インタフェースで使用トンネリング技術上の任意の追加的な負担をかけていません。パケット送信のパフォーマンスが適用されるトンネリング技術に依存するため、インターワーキングをプロビジョニングするとき、それは慎重に選択する必要があります。例えば、IPsecは、暗号化/復号化のための計算要件を課します。
Security is one of the key requirements concerning VPNs. In network environments, the term security currently covers many different aspects of which the most important from a networking perspective are shortly discussed hereafter.
セキュリティは、VPNをに関する重要な要件の一つです。ネットワーク環境では、長期的なセキュリティは、現在のネットワークの観点から最も重要なのは、まもなく以下で議論されている多くの異なる側面をカバーしています。
Note that the Provider-Provisioned VPN requirements document explains the different security requirements for Provider-Provisioned VPNs in more detail.
プロバイダープロビジョニングVPNの要件文書は、より詳細にプロバイダープロビジョニングVPNの異なるセキュリティ要件を説明することに注意してください。
Like in every network environment, system security is the most important security aspect that must be enforced. Care must be taken that no unauthorized party can gain access to the network elements that control the VPN functionality (e.g., PE and CE devices).
すべてのネットワーク環境にいるかのように、システムのセキュリティを施行しなければならない最も重要なセキュリティ面です。ケアは、無許可の当事者がVPN機能（例えば、PEとCEデバイス）を制御するネットワーク要素へのアクセスを得ることができないように注意しなければなりません。
As the VPN customers are making use of the shared SP's backbone, the SP must ensure the system security of its network elements and management systems.
VPNの顧客が共有SPのバックボーンを利用しているとして、SPは、そのネットワーク構成要素と管理システムのシステムのセキュリティを確保する必要があります。
When a network or parts of a network are private, one of the requirements is that access to that network (part) must be restricted to a limited number of well-defined customers. To accomplish this requirement, the responsible authority must control every possible access to the network.
ネットワークまたはネットワークの一部がプライベート場合、要件の一つは、そのネットワーク（一部）へのアクセスが明確に定義された顧客の限られた数に制限されなければならないということです。この要件を達成するために、責任者は、ネットワークへの可能なすべてのアクセスを制御する必要があります。
In the context of PE-based VPNs, the access points to a VPN must be limited to the interfaces that are known by the SP.
PEベースのVPNの文脈では、VPNへのアクセスポイントは、SPによって知られているインターフェースに制限されなければなりません。
When one receives data from a certain entity, one would like to be sure of the identity of the sending party. One would like to be sure that the sending entity is indeed whom he or she claims to be, and that the sending entity is authorized to reach a particular destination.
1は、特定のエンティティからデータを受信すると、1は送信側の身元の確認になりたいです。一つは、送信側エンティティは、彼または彼女があると主張する者、および送信エンティティは、特定の宛先に到達するために許可されていることを確かにあることを確認してくださいしたいと思います。
In the context of layer 3 PE-based VPNs, both the data received by the PEs from the customer sites via the SP network and destined for a customer site should be authenticated.
レイヤ3 PEベースのVPNの文脈において、両方のSPネットワークを介して顧客サイトからのPEによって受信され、顧客サイト宛のデータが認証されなければなりません。
Note that different methods for authentication exist. In certain circumstances, identifying incoming packets with specific customer interfaces might be sufficient. In other circumstances, (e.g., in temporary access (dial-in) scenarios), a preliminary authentication phase might be requested. For example, when PPP is used. Or alternatively, an authentication process might need to be present in every data packet transmitted (e.g., in remote access via IPsec).
認証のためのさまざまな方法が存在することに注意してください。特定の状況では、特定の顧客インターフェースと着信パケットを識別することは十分であるかもしれません。他の状況では、（例えば、一時的なアクセス（ダイヤルイン）のシナリオで）、予備認証フェーズは、要求されるかもしれません。たとえば、PPPを使用した場合。または代わりに、認証プロセス（例えば、IPsecのを経由してリモートアクセスで）送信されたすべてのデータパケットに存在する必要があるかもしれません。
For layer 3 PE-based VPNs, VPN traffic is tunneled from PE to PE and the VPN tunnel endpoint will check the origin of the transmitted packet. When MPLS is used for VPN tunneling, the tunnel endpoint checks whether the correct labels are used. When IPsec is used for VPN tunneling, the tunnel endpoint can make use of the IPsec authentication mechanisms.
レイヤ3 PEベースのVPNは、VPNトラフィックはPEにPEからトンネリングされたVPNトンネルエンドポイントは、送信されたパケットの発信元を確認します。 MPLSは、VPNトンネリングのために使用される場合、トンネルエンドポイントのチェックが正しいラベルが使用されるかどうか。 IPsecはVPNトンネリングのために使用される場合、トンネルエンドポイントは、IPsec認証メカニズムを利用することができます。
In the context of layer 3 provider-provisioned CE-based VPNs, the endpoint authentication is enforced by the CE devices.
レイヤ3プロバイダプロビジョニングCEベースのVPNの文脈では、エンドポイント認証をCEデバイスによって実施されます。
When information is exchanged over a certain part of a network, one would like to be sure that the information that is received by the receiving party of the exchange is identical to the information that was sent by the sending party of the exchange.
情報がネットワークの特定の部分の上で交換された場合、1は交流の受信側で受信された情報は、為替の送信側で送信された情報と同一であることを確認してくださいしたいと思います。
In the context of layer 3 PE-based VPNs, the SP assures the data integrity by ensuring the system security of every network element. Alternatively, explicit mechanisms may be implemented in the used tunneling technique (e.g., IPsec).
レイヤ3 PEベースのVPNの文脈では、SPは、すべてのネットワーク要素のシステムのセキュリティを確保することによって、データの整合性を保証します。代替的に、明示的なメカニズムが使用されるトンネリング技術（例えば、IPsec）の中に実装することができます。
In the context of layer 3 provider-provisioned CE-based VPNs, the underlying network that will tunnel the encapsulated packets will not always be of a trusted nature, and the CE devices that are responsible for the tunneling will also ensure the data integrity, e.g., by making use of the IPsec architecture.
層の文脈では3プロバイダプロビジョニングCEベースのVPNトンネルがカプセル化されたパケットは、常に信頼できる性質のものではありませんし、トンネリングを担当しているCEデバイスはまた、例えば、データの整合性を確保する基盤となるネットワーク、IPsecのアーキテクチャを利用することによって。
One would like that the information that is being sent from one party to another is not received and not readable by other parties. With traffic flow confidentiality one would like that even the characteristics of the information sent is hidden from third parties. Data privacy is the confidentiality of the user data.
一つは、別の関係者から送信されている情報を受信していないし、他の当事者によって読み取り可能されていないことをしたいと思います。トラフィックフローの機密性と1は、送信された情報であっても特性が第三者から隠されていることをしたいと思います。データのプライバシーは、ユーザデータの機密性です。
In the context of PPVPNs, confidentiality is often seen as the basic service offered, as the functionalities of a private network are offered over a shared infrastructure.
プライベートネットワークの機能は、共有インフラストラクチャ上で提供されているようPPVPNsのコンテキストでは、機密性は、多くの場合、提供する基本サービスとして見られています。
In the context of layer 3 PE-based VPNs, as the SP network (and more precisely the PE devices) participates in the routing and forwarding of the customer VPN data, it is the SP's responsibility to ensure confidentiality. The technique used in PE-based VPN solutions is the ensuring of PE to PE data separation. By implementing VFI's in the PE devices and by tunneling VPN packets through the shared network infrastructure between PE devices, the VPN data is always kept in a separate context and thus separated from the other data.
SPネットワークは、（より正確にはPEデバイス）カスタマーVPNデータのルーティングおよび転送に参加するように層3 PEベースのVPNの文脈では、機密性を保証するために、SPの責任です。 PEベースのVPNソリューションで使用される技術は、PEデータ分離PEの確保です。 PEデバイス間の共有ネットワークインフラストラクチャを介してVFIのPEデバイス及びトンネリングVPNパケットによってを実装することにより、VPNデータが常に別のコンテキストに保持され、したがって、他のデータから分離されます。
In some situations, this data separation might not be sufficient. Circumstances where the VPN tunnel traverses other than only trusted and SP controlled network parts require stronger confidentiality measures such as cryptographic data encryption. This is the case in certain inter-SP VPN scenarios or when the considered SP is on itself a client of a third party network provider.
いくつかの状況では、このデータ分離は十分ではないかもしれません。 VPNトンネルは、信頼できるとSP制御ネットワーク部分以外の横断状況は、暗号化データの暗号化などのより強力な機密保持対策を必要とします。これは、特定の間SPのVPNシナリオの場合であるか、と考えSPは、サードパーティ製のネットワークプロバイダのクライアントが自身にあるとき。
For layer 3 provider-provisioned CE-based VPNs, the SP network does not bare responsibility for confidentiality assurance, as the SP just offers IP connectivity. The confidentiality will then be enforced at the CE and will lie in the tunneling (data separation) or in the cryptographic encryption (e.g., using IPsec) by the CE device.
レイヤ3プロバイダプロビジョニングCEベースのVPNの場合は、SPネットワークは、SPだけのIP接続を提供していますように、機密性の保証の責任をむき出していません。機密性は、その後、CEに適用され、CE機器により（IPsecを使用して、例えば）トンネリング（データ分離）または暗号化、暗号化にあるであろう。
Note that for very sensitive user data (e.g., used in banking operations) the VPN customer may not outsource his data privacy enforcement to a trusted SP. In those situations, PE-to-PE confidentiality will not be sufficient and end-to-end cryptographic encryption will be implemented by the VPN customer on its own private equipment (e.g., using CE-based VPN technologies or cryptographic encryption over the provided VPN connectivity).
VPNの顧客が信頼SPに彼のデータプライバシー執行を外部委託しないことがあり（例えば、銀行業務で使用される）非常に敏感なユーザーデータのことに注意してください。そのような状況では、PE-に-PE機密性が十分ではないであろうと、エンドツーエンドの暗号化暗号化は提供VPNでCEベースのVPN技術や暗号化暗号化を使用して、例えば（独自の専用機器のVPNの顧客によって実装されます接続性）。
An important remark is the fact that both the user data and the VPN control data must be protected.
重要な発言は、ユーザデータおよびVPN制御データの両方を保護しなければならないという事実です。
Previous subsections were focused on the protection of the user data, but all the control data (e.g., used to set up the VPN tunnels, used to configure the VFI's or the CE devices (in the context of layer 3 provider-provisioned CE-based VPNs)) will also be secured by the SP to prevent deliberate misconfiguration of provider-provisioned VPNs.
前のサブセクションは、ユーザデータの保護に焦点を当てたが、VPNトンネルを設定するために使用されるすべての制御データ（例えば、レイヤ3プロバイダプロビジョニングCEベースの文脈でVFIのか、CEデバイスを（設定するために使用されましたVPNは））もプロバイダープロビジョニングVPNの意図的な設定ミスを防止するために、SPによって固定されます。
In certain scenarios, a single VPN will need to cross multiple SPs.
特定のシナリオでは、単一のVPNは、複数のSPを横断する必要があります。
The fact that the edge-to-edge part of the data path does not fall under the control of the same entity can have security implications, for example with regards to endpoint authentication.
データパスのエッジ・ツー・エッジ部分が同じエンティティの制御下に該当しないという事実は、エンドポイント認証へに関して、例えば、セキュリティ上の影響を有することができます。
Another point is that the SPs involved must closely interact to avoid conflicting configuration information on VPN network elements (such as VFIs, PEs, CE devices) connected to the different SPs.
もう一つのポイントは、密接に相互作用しなければならない関係SPは別のSPに接続された（例えばのVFI、のPE、CEデバイスなど）VPNネットワーク要素上の矛盾する設定情報を回避することです。
Appendix A: Optimizations for Tunnel Forwarding
付録A：トンネル転送のための最適化
A.1. Header Lookups in the VFIs
A.1。 VFIのヘッダールックアップ
If layer 3 PE-based VPNs are implemented in the most straightforward manner, then it may be necessary for PE devices to perform multiple header lookups in order to forward a single data packet. This section discusses an example of how multiple lookups might be needed with the most straightforward implementation. Optimizations which might optionally be used to reduce the number of lookups are discussed in the following sections.
レイヤ3 PEベースのVPNは、最も簡単な方法で実装されている場合はPEデバイスは、単一のデータ・パケットを転送するために、複数のヘッダールックアップを実行するために、それは必要であってもよいです。このセクションでは、複数のルックアップが最も簡単な実装を必要とするかもしれない方法の一例について説明します。必要に応じてルックアップの数を減らすために使用されるかもしれない最適化は、次のセクションで説明されています。
As an example, in many cases a tunnel may be set up between VFIs within PEs for support of a given VPN. When a packet arrives at the egress PE, the PE may need to do a lookup on the outer header to determine which VFI the packet belongs to. The PE may then need to do a second lookup on the packet that was encapsulated across the VPN tunnel, using the forwarding table specific to that VPN, before forwarding the packet.
一例として、多くの場合、トンネルは、指定されたVPNをサポートするためのPE内のVFIの間に設定することができます。パケットが出口PEに到達すると、PEは、VFIは、パケットが属するかを決定するために外部ヘッダにルックアップを実行する必要があるかもしれません。 PEは、パケットを転送する前に、そのVPNに固有の転送テーブルを使用して、VPNトンネルを横切ってカプセル化したパケットに対して第2のルックアップを実行する必要があるかもしれません。
For scaling reasons it may be desired in some cases to set up VPN tunnels, and then multiplex multiple VPN-specific tunnels within the VPN tunnels.
スケーリング理由から、VPNトンネルを設定するために、いくつかのケースでは所望され得る、およびVPNトンネル内次いで多重複数のVPN固有のトンネル。
This implies that in the most straightforward implementation three header lookups might be necessary in a single PE device: One lookup may identify that this is the end of the VPN tunnel (implying the need to strip off the associated header). A second lookup may identify that this is the end of the VPN-specific tunnel. This lookup will result in stripping off the second encapsulating header, and will identify the VFI context for the final lookup. The last lookup will make use of the IP address space associated with the VPN, and will result in the packet being forwarded to the correct CE within the correct VPN.
一つのルックアップは、これは（関連するヘッダを取り除く必要性を意味する）VPNトンネルの終端であることを識別することができる：これは最も簡単な実装3ヘッダ検索は単一のPEデバイスに必要かもしれないであることを意味します。第2のルックアップは、これはVPN固有のトンネルの終端であることを識別することができます。この検索は、第二のカプセル化ヘッダを剥離になり、最終的なルックアップのためのVFIのコンテキストを識別する。最後のルックアップはVPNに関連付けられたIPアドレス空間を利用することになり、正しいVPN内の正しいCEに転送されるパケットになります。
A.2. Penultimate Hop Popping for MPLS
A.2。 MPLSのための最後から二番目のホップポッピング
Penultimate hop popping is an optimization which is described in the MPLS architecture document [RFC3031].
最後から二番目のホップポッピングは、MPLSアーキテクチャ文書[RFC3031]に記載されている最適化です。
Consider the egress node of any MPLS LSP. The node looks at the label, and discovers that it is the last node. It then strips off the label header, and looks at the next header in the packet (which may be an IP header, or which may have another MPLS header in the case that hierarchical nesting of LSPs is used). For the last node on the LSP, the outer MPLS header doesn't actually convey any useful information (except for one situation discussed below).
すべてのMPLS LSPの出口ノードを考えてみましょう。ノードは、ラベルを見て、それが最後のノードであることを発見します。その後、ラベルヘッダを取り除き、および（IPヘッダであってもよいし、LSPの階層ネスティングが使用される場合の別のMPLSヘッダを有していてもよい）は、パケット内の次のヘッダを調べ。 LSPの最後のノードの場合、外側のMPLSヘッダは、実際に（以下に述べるある状況を除く）任意の有用な情報を伝達しません。
For this reason, the MPLS standards allow the egress node to request that the penultimate node strip the MPLS header. If requested, this implies that the penultimate node does not have a valid label for the LSP, and must strip the MPLS header. In this case, the egress node receives the packet with the corresponding MPLS header already stripped, and can forward the packet properly without needing to strip the header for the LSP which ends at that egress node.
この理由のために、MPLS規格は、出口ノードは最後から二番目のノードストリップことMPLSヘッダを要求することを可能にします。要求された場合は、これが最後から二番目のノードがLSPのための有効なラベルを持っていない、とMPLSヘッダを削除しなければならないことを意味します。この場合、出口ノードは既に剥離対応するMPLSヘッダを有するパケットを受信し、その出口ノードで終わるLSPのためのヘッダを除去することなく、適切にパケットを転送することができます。
There is one case in which the MPLS header conveys useful information: This is in the case of a VPN-specific LSP terminating at a PE device. In this case, the value of the label tells the PE which LSP the packet is arriving on, which in turn is used to determine which VFI is used for the packet (i.e., which VPN-specific forwarding table needs to be used to forward the packet).
MPLSヘッダは有用な情報を伝達する一つの場合がある：これは、PEデバイスで終端するVPN固有LSPの場合です。この場合には、ラベルの値は、パケットが（すなわち、VPN固有のフォワーディングテーブルを転送するために使用する必要のある順番にVFIは、パケットのために使用されるかを決定するために使用される、オン到着するLSP PEに伝えますパケット）。
However, consider the case where multiple VPN-specific LSPs are multiplexed inside one PE-to-PE LSP. Also, let's suppose that in this case the egress PE has chosen all incoming labels (for all LSPs) to be unique in the context of that PE. This implies that the label associated with the PE-to-PE LSP is not needed by the egress node. Rather, it can determine which VFI to use based on the VPN-specific LSP. In this case, the egress PE can request that the penultimate LSR performs penultimate label popping for the PE-to-PE LSP. This eliminates one header lookup in the egress LSR.
しかし、複数のVPN固有のLSPは、1つのPEからPE-LSPの内部に多重化されている場合を考えます。また、のは、この場合には、出口PEがそのPEのコンテキスト内で一意であることが（すべてのLSPのために）すべての着信ラベルを選択したと仮定しましょう。これは、PE-に-PE LSPに関連付けられたラベルが出口ノードによって必要とされないことを意味します。むしろ、VFIは、VPN-特定LSPに基づいて使用するかを決定することができます。この場合、出口PEは最後から二番目のLSRは、PE-に-PE LSPためポッピング最後から二番目のラベルを実行することを要求することができます。これは、出力LSRで1件のヘッダ検索を排除します。
Note that penultimate node label popping is only applicable for VPN standards which use multiple levels of LSPs. Even in this case penultimate node label popping is only done when the egress node specifically requests it from the penultimate node.
最後から二番目のノードラベルポッピングは、LSPの複数のレベルを使用してVPN規格に対してのみ適用可能であることに注意してください。出口ノードは、特に最後から二番目のノードからそれを要求したときにこのような場合であっても最後から二番目のノードラベルポッピングだけ行われます。
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup
A.3。トンネルの出口VFI検索を排除するために多重分離
Consider a VPN standard which makes use of MPLS as the tunneling mechanism. Any standard for encapsulating VPN traffic inside LSPs needs to specify what degree of granularity is available in terms of the manner in which user data traffic is assigned to LSPs. In other words, for any given LSP, the ingress or egress PE device needs to know which LSPs need to be set up, and the ingress PE needs to know which set of VPN packets are allowed to be mapped to any particular LSP.
トンネリングメカニズムとしてのMPLSを利用したVPN標準を考えてみましょう。 LSPの内側にVPNトラフィックをカプセル化するための任意の標準は、ユーザ・データ・トラフィックはLSPのに割り当てされる方法の面で利用可能である粒度のどの程度を指定する必要があります。換言すれば、任意の所与のLSPのために、入力または出力PEデバイスは、LSPをセットアップする必要があるかを知る必要があり、かつ入口PEは、特定のLSPにマッピングすることが許可されているVPNパケットのセットを知る必要があります。
Suppose that a VPN standard allows some flexibility in terms of the mapping of packets to LSPs, and suppose that the standard allows the egress node to determine the granularity. In this case the egress node would need to have some way to indicate the granularity to the ingress node, so that the ingress node will know which packets can be mapped to each LSP.
VPN標準はのLSPへのパケットのマッピングの点である程度の柔軟性を可能にすると仮定し、そして標準の出口ノードは粒度を決定することを可能にすると仮定する。この場合、出口ノードが入口ノードは各LSPにマッピングすることができるパケットを知っているであろうように、入口ノードに粒度を示すためにいくつかの方法を持っている必要があります。
In this case, the egress node might decide to have packets mapped to LSPs in a manner which simplifies the header lookup function at the egress node. For example, the egress node could determine which set of packets it will forward to a particular neighbor CE device. The egress node can then specify that the set of IP packets which are to use a particular LSP correspond to that specific set of packets. For packets which arrive on the specified LSP, the egress node does not need to do a header lookup on the VPN's customer address space: It can just pop the MPLS header and forward the packet to the appropriate CE device. If all LSPs are set up accordingly, then the egress node does not need to do any lookup for VPN traffic which arrives on LSPs from other PEs (in other words, the PE device will not need to do a second lookup in its role as an egress node).
この場合、出口ノードは、出口ノードにおけるヘッダルックアップ機能を簡素化した方法でのLSPにマッピングされるパケットを有することを決定するかもしれません。例えば、出口ノードは、それが特定の隣接CEデバイスに転送するパケットのどのセット決定することができます。出口ノードは、特定のLSPを使用するようにされているIPパケットのセットがパケットの特定のセットに対応するように指定することができます。指定されたLSPに到着したパケットの場合、出口ノードは、VPNの顧客アドレス空間上のヘッダ検索を行う必要はありません：それはちょうどMPLSヘッダをポップし、適切なCEデバイスにパケットを転送することができます。すべてのLSPがそれに応じて設定されている場合は、出口ノードは、他の言葉で（他のPEからのLSPに到着したVPNトラフィックのいずれかの検索を行う必要はありません、PEデバイスは、としての役割に第2のルックアップを行う必要がありません。出口ノード）。
Note that PE devices will most likely also be an ingress routers for traffic going in the other direction. The PE device will need to do an address lookup in the customer network's address space in its role as an ingress node. However, in this direction the PE still needs to do only a single header lookup.
そのPEデバイスは、最も可能性の高い他の方向に行くトラフィックの入力ルーターになります注意してください。 PEデバイスは、入口ノードとしての役割で、顧客のネットワークのアドレス空間内のアドレスのルックアップを行う必要があります。しかし、この方向にPEは依然として単一のヘッダルックアップを行う必要があります。
When used with MPLS tunnels, this optional optimization reduces the need for header lookups, at the cost of possibly increasing the number of label values which need to be assigned (since one label would need to be assigned for each next-hop CE device, rather than just one label for every VFI).
MPLSトンネルで使用される場合、このオプションの最適化ではなく、おそらくつのラベルは、各次ホップCEデバイスに対して割り当てられる必要があるので、（割り当てる必要があり、ラベル値の数を増加させるコストで、ヘッダルックアップの必要性を減少させますすべてのVFIのためのただ一つのラベルより）。
The same approach is also possible when other encapsulations are used, such as GRE [RFC2784] [RFC2890], IP-in-IP [RFC2003] [RFC2473], or IPsec [RFC2401] [RFC2402]. This requires that distinct values are used for the multiplexing field in the tunneling protocol. See section 4.3.2 for detail.
他のカプセル化は、このようなGRE [RFC2784]、[RFC2890]、IPインIP [RFC2003]、[RFC2473]、またはIPsecの[RFC2401]、[RFC2402]として、使用されている場合も同様のアプローチも可能です。これは、異なる値がトンネリングプロトコルにおける多重化フィールドのために使用されることを必要とします。詳細はセクション4.3.2を参照してください。
Acknowledgments
謝辞
This document is output of the framework document design team of the PPVPN WG. The members of the design team are listed in the "contributors" and "author's addresses" sections below.
この文書では、PPVPN WGの枠組み文書のデザインチームの出力です。設計チームのメンバーは、以下の「貢献者」と「作者のアドレス」のセクションに記載されています。
However, sources of this document are based on various inputs from colleagues of authors and contributors. We would like to thank Junichi Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano, Naoto Makinae, Kenichi Kitami, Rajesh Balay, Anoop Ghanwani, Harpreet Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and Abbie Matthews.
しかし、この文書のソースは、著者と貢献者の同僚からの様々な入力に基づいています。私たちは、純一Sumimoto、厚生鈴木寛Kurakami、隆文浜野、直人Makinae、健一北見、ラジェッシュBalay、アヌープGhanwani、Harpreet Chadha、サミル・ジャイン、Lianghwa丈の、ビジェイスリニバサン、とアビーマシューズに感謝したいと思います。
We would also like to thank Yakov Rekhter, Scott Bradner, Dave McDysan, Marco Carugi, Pascal Menezes, Thomas Nadeau, and Alex Zinin for their valuable comments and suggestions.
我々はまた、彼らの貴重なコメントや提案のためのヤコフ・レックター、スコット・ブラッドナー、デイブMcDysan、マルコCarugi、パスカル・メネゼス、トーマスナドー、およびアレックスジニンに感謝したいと思います。
Normative References
引用規格
[PPVPN-REQ] Nagarajan, A., Ed., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[PPVPN-REQ] Nagarajan、A.編、 "プロバイダプロビジョニングされた仮想プライベートネットワーク（PPVPN）のための一般的要件"、RFC 3809、2004年6月。
[L3VPN-REQ] Carugi, M., Ed. and D. McDysan, Ed., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[L3VPN-REQ] Carugi、M.、エド。そして、D. McDysan、エド。、 "レイヤ3プロバイダのサービスの要件プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4031、2005年4月。
Informative References
参考文献
[BGP-COM] Sangli, S., et al., "BGP Extended Communities Attribute", Work In Progress, February 2005.
【は、BGP-COM]サングリ、S.、ら。、進歩、2005年2月、作業の "BGP拡張コミュニティ属性"。
[MPLS-DIFF-TE] Le Faucheur, F., Ed., "Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering", Work In Progress, December 2004.
[MPLS-DIFF-TE]ルFaucheur、F.、エド。、 "差別・サービスを意識したMPLSトラフィックエンジニアリングをサポートするためのプロトコル拡張"、作業の進捗状況、2004年12月。
[VPN-2547BIS] Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.
[VPN-2547BIS]ローゼン、E.、ら、 "BGP / MPLS VPN" を、進行中の作業。
[VPN-BGP-OSPF] Rosen, E., et al., "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs", Work In Progress, May 2005.
[VPN-BGP-OSPF]ローゼン、E.、ら、進歩、2005年5月には、ワーク "OSPFプロバイダー/顧客エッジBGP / MPLS IP VPNのプロトコルとして"。
[VPN-CE] De Clercq, J., et al., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work In Progress.
[VPN-CE]デClercq、J.ら、「IPsecを使用してプロバイダプロビジョニングCEベースの仮想プライベートネットワークのためのアーキテクチャ」、進行中の作業。
[VPN-DISC] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs," Work In Progress.
進行中の作業 "レイヤ3及びレイヤ2のVPN用の自動検出機構としてBGPを使用して" [VPN-DISC]ウルド-Brahimの、H.、ら。、。
[VPN-L2] Andersson, L. and E. Rosen, Eds., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work In Progress.
[VPN-L2]アンダーソン、L.およびE.ローゼン、編、進行中の仕事 "のレイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"。
[VPN-VR] Knight, P., et al., "Network based IP VPN Architecture Using Virtual Routers", Work In Progress, July 2002.
[VPN-VR]騎士、P.ら、進歩、2002年7月の作業 "仮想ルーターを使用してIP VPNアーキテクチャベースのネットワーク"。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためのIS-IS"。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1966] Bates, T., "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC1966]ベイツ、T.、 "BGPルートリフレクション：フルメッシュIBGPへの代替"、RFC 1966、1996年6月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, February 2001.
[RFC1997]チャンドラ、R.、Trainaの、P.、およびT.李、 "BGPコミュニティ属性"、RFC 1997、2001年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]マンキン、A.編、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、オデル、M.、Romanow、A.、Weinrib、A.、およびL.チャン、「リソース予約プロトコル（RSVP）バージョン1適用性に関する声明展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]バーガー、L.とT.オマリー、 "IPSECデータフローのためのRSVP拡張機能"、RFC 2207、1997年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1994.
[RFC2453]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1994年11月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル 'L2TP'"、RFC 2661、1999年8月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation Over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、 "マルチプロトコルカプセル化オーバーATMアダプテーションレイヤ5"、RFC 2684、1999年9月。
[RFC2685] Fox B. and B. Gleeson, "Virtual Private Networks Identifier," RFC 2685, September 1999.
[RFC2685]フォックスB.及びB.グリーソン、 "仮想プライベートネットワーク識別子、" RFC 2685、1999年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[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]グリーソン、B.、林、A.、Heinanen、J.、アーミテージ、G.、およびA. Malis、 "IPベースの仮想プライベートネットワークのための枠組み"、RFC 2764、2000年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年9月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
"BGP-4のためのマルチプロトコル拡張" [RFC2858]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、RFC 2858、2000年6月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3032] Rosen E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼンE.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP. Doolan、 "MPLSスイッチングLDPおよびATM VCを使用して"、RFC 3035 、2001年1月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, June 1996.
[RFC3065] Trainaの、P.、マクファーソン、D.、およびJ.スカダー、 "BGPのための自律システムコンフェデレーション"、RFC 3065、1996年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]ホッジス、J.とR.モルガン、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：技術仕様"、RFC 3377、2002年9月。
Contributors' Addresses
貢献者のアドレス
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium
ジェレミー・デ・Clercqアルカテル神父ウェルズプレイン1、2018年アントワープ、ベルギー
EMail: jeremy.de_clercq@alcatel.be
メールアドレス：jeremy.de_clercq@alcatel.be
Bryan Gleeson Nokia 313 Fairchild Drive, Mountain View, CA 94043 USA.
ブライアン・グリーソンノキア313フェアチャイルドドライブ、マウンテンビュー、CA 94043 USA。
EMail: bryan.gleeson@nokia.com
メールアドレス：bryan.gleeson@nokia.com
Andrew G. Malis Tellabs 90 Rio Robles Drive San Jose, CA 95134 USA
アンドリューG. Malisテラブス90リオロブレスドライブサンノゼ、CA 95134 USA
EMail: andy.malis@tellabs.com
メールアドレス：andy.malis@tellabs.com
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886, USA
カルティクMuthukrishnanルーセント・テクノロジーズ1ロビンス・ロードウェストフォード、MA 01886、USA
EMail: mkarthik@lucent.com
メールアドレス：mkarthik@lucent.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719, USA
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA、01719、USA
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Chandru Sargor Redback Networks 300 Holger Way San Jose, CA 95134, USA
Chandru Sargorレッドバック・ネットワーク300ホルガー・ウェイサンノゼ、CA 95134、USA
EMail: apricot+l3vpn@redback.com
メールアドレス：apricot+l3vpn@redback.com
Jieyun Jessica Yu University of California, Irvine 5201 California Ave., Suite 150, Irvine, CA, 92697 USA
カリフォルニアのJieyunジェシカ・ユー大学アーバイン校5201カリフォルニアアベニュー、スイート150、アーバイン、CA、92697 USA
EMail: jyy@uci.edu
メールアドレス：jyy@uci.edu
Authors' Addresses
著者のアドレス
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146, USA
ロスCallonジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886から3146、USA
EMail: rcallon@juniper.net
メールアドレス：rcallon@juniper.net
Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
むねよし すずき んっｔ いんふぉｒまちおん しゃりんｇ Ｐぁｔふぉｒｍ ぁｂｓ。 ３ー９ー１１、 みどりーちょ、 むさしのーし、 ときょ １８０ー８５８５、 じゃぱん
EMail: suzuki.muneyoshi@lab.ntt.co.jp
メールアドレス：suzuki.muneyoshi@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet gement
RFC Editor機能のための基金は現在、インターネットgementによって提供され