[要約] RFC 4110は、レイヤー3のプロバイダ提供仮想プライベートネットワーク（PPVPN）のフレームワークを提供しています。このRFCの目的は、異なるネットワーク間でセキュアな通信を実現するためのガイドラインを提供することです。
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)
レイヤー3プロバイダーがプロビジョニングした仮想プライベートネットワーク（PPVPNS）のフレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document provides 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 PPVPNをサポートするためのプロトコルとメカニズムの標準化を支援することを目的としています。このドキュメントの意図は、レイヤー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 PPVPNをサポートするためのプロトコルとメカニズムの標準化を支援することを目的としています。
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).
「プロバイダーが提供するVPNS」という用語は、セクション1.3で定義されているように、サービスプロバイダー（SP）がVPNの管理とプロビジョニングに参加する仮想プライベートネットワーク（VPN）を指します。プロバイダーがVPNの管理とプロビジョニングに参加できる複数の方法があります。したがって、複数の異なるタイプのPPVPNがあります。フレームワークドキュメントでは、レイヤー3 VPNSについて説明します（セクション1.3で定義されています）。
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 PPVPNに適用されるセキュリティの問題に対処します。
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.
場合によっては、ある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ソリューションは、最小限の協力的なSPネットワークの任意のセット（つまり、パブリックインターネット）でVPNサービスを提供できるようにすることを目的としています。
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アドレスがグローバルに一意であるという保証はありません。ある顧客のネットワークで使用されるアドレスは、他の顧客で使用されるアドレスと重複する場合があります。ただし、単一のPEデバイスを使用して、これらの顧客ネットワークにオーバーラップアドレスがある場合でも、複数の顧客ネットワークにVPNサービスを提供できます。PEベースのレイヤー3 VPNSでは、PEデバイスは、IPヘッダーにある顧客アドレスに基づいてVPNトラフィックをルーティングできます。これは、PEデバイスが異なる顧客ネットワークからのパケット間の分離レベルを維持する必要があることを意味します。CEベースのレイヤー3 VPNでは、PESは顧客のプライベートアドレスに基づいてルーティングの決定を下さないため、この問題は発生しません。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ネットワークを幅広くプロトコルすることを可能にするなど、他の理由でも重要です。
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リンクを手動で構成することが難しすぎると判断する場合があります。これにより、SPはCEデバイス[VPN-L2]間のレイヤー2 VPNサービスにATMリンクを置き換えることができます。自動配信は、CEデバイス間のリンクの構成を簡素化するために使用される場合があり、MPLSサービスはATMサービスの代わりにCEデバイス間で使用される場合があります（たとえば、プロバイダーの高速IPまたはMPLSバックボーンを利用するため）。
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に専念する可能性があります。操作は変更されていない場合があります（エッジルーターからプライベートネットワーク内の他のルーターへのリンクがLANリンクの代わりにManリンクになり、エッジルーターからプロバイダーコアルーターへのリンクはManリンクの代わりにLANリンクになります）。問題のルーターは、プロバイダーのエッジルーターと見なされるようになり、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).
機器のコストを最小限に抑えるために、プロバイダーは、いくつかの専用PEデバイスを単一の物理ルーターに、仮想ルーター（VR）[VPN-VR]を実行する機能に置き換えることを決定する場合があります。プロトコル操作は変更されていない場合があります。この場合、プロバイダーはVR機能を使用するレイヤー3 VPNサービスを提供しています。自己発見は、上記のレイヤー2 VPNケースでどのように行われたかに非常に似た方法で使用される可能性があることに注意してください（たとえば、同じVPNをサポートする他のVRを発見するためにBGPが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.
実際には、1つのネットワークが実際にこれらのアプローチのすべてをさまざまな時点で進化させることはほとんどありません。ただし、この例は、可能なアプローチの連続体があり、各アプローチが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パケットを受信することを期待しています。CEベースのVPNをプロバイダーで提供された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ベースのVPNSでは、顧客ネットワークのバックボーンは、エンドポイントがCEデバイスであるトンネルのセットです。さまざまな種類のトンネル（GRE、IP-in-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 Edgeデバイス」を使用して、VPN固有の機能を実行する顧客ネットワークとVPNバックボーンの両方に接続されたデバイスを参照します。CEベースのVPNSの場合、VPN EdgeデバイスはCEデバイスです。PEベースのVPNSの場合、VPN Edgeデバイスは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が定義によりプロバイダーがプロビジョニングしたVPNSであることを意味します。
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 Squared」（実際には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プロトコルに関する知識が必要です。結果の1つは、VPNによってサポートできるレイヤー3プロトコルのセットが、PE（実際にはIPに限定されていることを意味する）によってサポートされているものに限定されていることです。もう1つの結果は、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サポートを含む）を単純に提供するためのサービスが限られています。これは「ネットワーク接続サービス」と呼ばれます。ファイアウォール、ユーザーまたはサイト認証サイト、アドレスの割り当てなど、他の可能なサービスが多数あります（たとえば、RADIUSまたは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）プロトコルを使用したPPVPNの議論を除外します（たとえば、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、IS-IS、RIP、BGP、または同様のプロトコルなど）を実行するデバイス。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ベースのVPNS：PEデバイスは、特定のトラフィックがVPNトラフィックであることを知っています。パケットの宛先IPアドレスに基づいて、およびパケットのIPヘッダーの他の情報に基づいて、トラフィックを（トンネルを介して）転送します。PEデバイス自体はトンネルエンドポイントです。トンネルは、さまざまなカプセルを使用して、SPネットワーク上にトラフィックを送信する場合があります（GRE、IP-in-IP、IPSEC、またはMPLSトンネルなど）。
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側（顧客インターフェイス）の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）：VPNSは、CEベースであろうとPEベースであろうと、エンド顧客ではなくSPによって積極的に管理されています。
Route Reflectors: An SP-owned network element that is used to distribute BGP routes to the SP's BGP-enabled routers.
ルートリフレクター：BGPルートをSPの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.
Virtual Private Network（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 Edgeデバイス：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トンネル：VPNトラフィックを運ぶために使用され、これら2つのエンティティ間で送信されるカプセル化パケットによって実装された2つのPEまたは2つのCEエンティティ間の論理リンク。
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
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を構築および展開するために必要な一般的なコンポーネントとピースを明確にすることです。2種類の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ベースのVPNSの参照モデルと図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の各ペア間の単一の論理トンネルを示しています。他のオプションが可能です。たとえば、2つのPEの間に1つのトンネルが発生し、PEからPEトンネルの上に多重化された複数のVFIトンネルが発生する可能性があります。同様に、たとえば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ベースのVPNSのコンテキストでは、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デバイスを相互接続するために使用されるプロバイダーネットワーク内のルーター。
o Provider edge (PE) device
o プロバイダーエッジ（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ベースのVPNSのコンテキストでは、PEデバイスは1つ以上のVFIを実装し、1つ以上のVPNをサポートするためにVPNごとの状態を維持します。これは、Router、LSR、またはVFISおよびプロバイダーEDGE VPN機能を含むその他のデバイスである場合があります。（アクセス接続は、機能的な観点からVFIによって終了することに注意してください）。PEデバイスは、1つ以上の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接続を表します。アクセス接続は、たとえば、専用の物理回路、論理回路（FR、ATM、MACなど）、またはIPトンネル（IPSEC、L2TP、またはMPLSを使用するなど）にすることができます。
o Access network
o アクセスネットワーク
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デバイス間のアクセス接続を提供します。TDMネットワーク、レイヤー2ネットワーク（FR、ATM、およびイーサネットなど）、またはアクセスがトンネル化されているIPネットワーク（L2TP [RFC2661]またはMPLSを使用）を担当する場合があります。
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た1つのトンネルを単一のPEからPEトンネル（GRE、IP-in-IP、IPSEC、またはMPLSトンネルなど）に多重化できます。これを図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は、PEに存在する論理的エンティティであり、VPNのルーター情報ベースと転送情報ベースを含みます。ルーティングと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アプローチを選択し、異なるSPSが異なるアプローチを選択する可能性があることを意味します。（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ネットワーク間の境界に配置される場合があります。これらのポイントの1つでの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アプローチでサポートするPES間のトンネルを使用してインターワーキングを可能にします。図2.6に示すように、インターワーキングインターフェイスは、PESのペア間に存在し、異なるアプローチで実装された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が別の種類に接続されている場合、2種類のVPN間の通信が自動的に発生します。
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.
図2.7：レイヤー3プロバイダーがプロビジョニングしたCEベースの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ベースのVPNSのコンテキストでは、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
o プロバイダーエッジ（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ベースのVPNSのコンテキストでは、PEデバイスは、VPN固有の機能を持たないルーター、LSR、またはその他のデバイスである場合があります。1つ以上の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ベースのVPNSのコンテキストでは、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ベースのVPNSのコンテキストでは、VPNトンネルはIPトンネル（例：GRE、IP-in-IP、IPSEC、またはL2TPを使用）または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またはCEデバイスの属性とその関係のプロビジョニングと監視をサポートし、顧客VPNのVPN接続を定義する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、CES、およびPESの関連付けを指します。特定のCEは、1つ以上のVPNに属します。したがって、各PEはVPNのセットに関連付けられており、特定のVPNには、そのVPNをサポートしている関連PESのセットがあります。PEに特定のVPNに属する少なくとも1つのCEがある場合、そのVPN（例：VPNルート）の状態情報がそのPEに存在する必要があります。PEに存在するVPNのセットは、顧客サイトがVPNSに追加または削除されると、時間とともに変化する場合があります。
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ルーティング情報の分布を制約するものもあります。
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.
動的結合は、一部のリアルタイムプロトコル相互作用が特定のPE-CEアクセスリンクを特定のVPNに一時的に結合すると発生します。たとえば、モバイルユーザーはプロバイダーネットワークをダイヤルアップし、ユーザー認証とVPN選択手順を実行できます。次に、ユーザーが添付されているPEは、ユーザーに永続的に関連付けられているものではなく、通常、モバイルユーザーがたまたま地理的に近いものです。動的な結合のもう1つの例は、ホテルや会議センターなどの公共施設での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と半径が一般的に使用されます。他のメカニズムも可能です。たとえば、ユーザーの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ベースのVPNSでは、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デバイスには、PEデバイスへの接続を介してIPまたはMPLS接続があります。これは、グローバルIPアドレススペースまたは特定のSPSネットワークでユニークなアドレススペースへの通常の接続を提供するだけです。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の確立は、各CEデバイスで行われ、他のCEデバイスまたはMPLS接続を使用します。したがって、特定の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ベースのVPNSの場合、交換は通常のIPパケットであり、一般的な相互接続ルーターに使用できるのと同じ形式で送信されます。たとえば、IPパケットは、イーサネット、SONET、T1、T3、ダイヤルアップライン、およびルーターが利用できるその他のリンクレイヤーを介して交換できます。これらのリンクレイヤーは、IPパケットを運ぶ目的でインターフェイスに厳密にローカルであり、顧客インターフェイスの両端で終了していることに注意することが重要です。IPパケットには、VPN内では一意ではありますが、VPNバックボーンでは一意ではないアドレスが含まれている場合があります。オプションで、データ交換はMPLSを使用してIPパケットを運ぶ場合があります。
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パケットであるかどうかを知りません。現時点では、MPLSは一般に顧客可視サービスとして提供されていないため、CEベースのVPNは最も一般的にIPサービスを利用しています。
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 Edgeデバイスで実行する必要があります。
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.
PEがCEを介して到達可能な顧客ネットワークからPEがそれらのアドレスを取得できるようにするPE-CEルーティングインタラクションがあります。PE-CEルーティングインタラクションにより、CEデバイスは、PEを介して到達可能な顧客ネットワークからこれらのアドレスを取得できます。これらは通常、顧客ネットワークの他のサイトにあるアドレスです。
The PE-CE routing interaction can make use of static routing, an IGP (such as RIP, OSPF, IS-IS, etc.), or BGP.
PE-CEルーティングの相互作用は、静的ルーティング、IGP（RIP、OSPF、IS-ISなど）、またはBGPを使用できます。
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つはバックボーンルーティング用、もう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の追加インスタンスをサポートする場合があります。あるいは、PEは、たとえば異なるBGPアドレスファミリーを使用して、パブリックインターネットルートをVPNルートと区別するために、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.
特定のVPNでPEがCEから学習するルーティング情報は、同じVPNに接続されている他のPESに転送する必要があります。これらのPEは、そのVPNの他のCESに情報を順番に転送する必要があります。
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つのルーティングインスタンスをサポートする必要があり、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ベースのVPNSの場合、単一のPEデバイスは、いくつかの異なるVPNにサービスを提供する可能性があります。異なるVPNには相互に一意ではないアドレススペースがある可能性があるため、PEデバイスにはいくつかの転送テーブルが必要です。これらは、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
o 単一のIGP内の複数の領域
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).
o 各サイト内の別のIGPで、各サイトからバックボーンルーティングにルートを再分配します（つまり、顧客ネットワークで見られるバックボーンに）。
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.
単一のIGP領域（単一のOSPF領域、単一のIS-I-ISエリア、またはルーター間のRIPの単一インスタンスなど）を使用できます。顧客ネットワーク内のすべてのルーター（各PE内のVFIを含むPESを含む、またはより正確に）が1つの領域内に表示される可能性があります。PES間のトンネルも通常のリンクとして表示される可能性があります。
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またはIS-ISレベル2）として相互接続される場合があります。したがって、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トンネル、アクセス接続、またはバックドアリンクを介して最短コストパスを使用できます。VPNの複数のサイトが一般的なIGPを使用しない場合、またはバックボーンがサイトと同じ一般的な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.
エクストラネットの場合、相互接続されるサイトは複数の異なる管理に属します。この場合、IGPS（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領域の境界境界または境界ルーターとしての場合があります。この場合、静的ルーティング、BGP、またはバックボーンで使用されるルーティングは、顧客インターフェイス全体で使用できます。
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-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ネットワークでのTunneled Customer Packetsの転送はグローバル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.
o 独自のプライベートネットワーク（VPNルーティング）、独自のサイト内およびVPNトンネルを介して他のVPNサイトを使用して、おそらくプライベートアドレスを使用してルーティングします。
o routing in the SP network (global routing), as such peering with its PE.
o 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はインテリアゲートウェイプロトコルであり、自律システム内で使用されます。定期的に、およびネットワークトポロジが変更されるたびにルーティングアップデートを送信します。ルーティング情報は、隣接するルーターによって近隣のルーター、したがってネットワーク全体に伝播されます。ソースから宛先へのルートは、ルーターの数が少ないパスです。この数値は「ホップカウント」と呼ばれ、最大値は15です。これは、RIPが小型または中サイズのネットワークに適していることを意味します。
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を意味します。これでは、リンク状態がConnectionless Network Serviceを介して宣伝されています。IS-ISには、OSPFと同じ基本機能があります。これらには、リンク状態広告とエリア内のトポロジデータベースのメンテナンス、最短パスのツリーの計算、最短パスのツリーからのルーティングテーブルの生成、エリアルーティングスキーム、指定されたルーター、可変長さサブネットマスク。
o BGP-4 (Border Gateway Protocol version 4) [RFC1771]
o BGP-4（Border Gateway Protocolバージョン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は、自律システムをより小さな自律システムに分割し、それらを単一の連合にグループ化することにより、IBGPセッションの数を減らすことができます[RFC3065]。ルートリフレクションは、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]をサポートするために拡張されています。Multiprotocol BGP-4は、複数の「アドレスファミリ」からルートを運びます。
The basic functional components of an implementation of a VPN are:
VPNの実装の基本的な機能コンポーネントは次のとおりです。
o A mechanism to acquire VPN membership/capability information
o VPNメンバーシップ/機能情報を取得するメカニズム
o A mechanism to tunnel traffic between VPN sites
o VPNサイト間のトラフィックをトンネルするメカニズム
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エッジデバイスはお互いを学びます。第2段階では、彼らは互いにトンネルを確立します。第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 Edgeデバイスで構成されたVPNのVPN識別子を交換することで実現できます。トンネリングやルーティングの一般的なメカニズムに同意できるように、VPNエッジデバイスの機能を決定する必要があります。たとえば、サイトAがトンネルメカニズムとしてIPSECとMPLの両方をサポートし、サイトBがMPLのみをサポートする場合、両方ともトンネリングにMPLSを使用することに同意できます。場合によっては、機能情報が暗黙的に決定される場合があります。たとえば、一部のSPSは単一の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の確立とメンテナンスを担当します。レイヤー3 PPVPNを提供するためには、さまざまなアプローチとスキームが可能ですが、VPNソリューションに対処する必要がある一般的な問題があります。
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に追加されると、他のPESはどのようにそれを知りますか？PEが最初に特定のVPNに接続されると、同じVPNにどのような他のPEが取り付けられているかがどのように決定されますか。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のすべてのルートはすべてのPESに存在することはできません。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.
物理的なネットワークを使用すると、同等の問題は、リンクの物理的相互接続の制御によって解決され、ルーターにローカルに接続されたリンク上でディスカバリー/ハロープロトコルを実行することにより解決できます。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発見には、さまざまなアプローチが可能です。1つのスキームでは、ネットワーク管理システムを使用して、VPNエッジデバイスを構成およびプロビジョニングします。このアプローチは、独自のプロトコルを使用するか、標準管理プロトコルとMIBを使用して、VPN発見情報を配布するためにも使用できます。別のアプローチは、VPN EdgeデバイスがVPNディスカバリー情報を含む集中ディレクトリまたはデータベースサーバーのクライアントとして機能する場合です。別の可能性は、VPNディスカバリー情報がVPN Edgeデバイス[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.
SPSはネットワーク管理を広範囲に使用して、ネットワーク全体に広がるさまざまなデバイスを構成および監視します。このアプローチは、VPN関連情報の配布にも使用できます。SPが使用して、さまざまな場所の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.
異なる実装間の相互運用性を容易にするため、および異なるSPSの管理システム間では、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.
VPNメンバーシップ情報の分布のための既存のBGPメカニズムの使用の拡張は、[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ルートリフレクターを使用している場合、PESを互いの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を使用する場合、パブリックインターネットルーティング情報を配布するために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ネットワークに接続されている場合、SPSはメンバーシップ/能力情報を交換するための共通のメカニズムをサポートする必要があります。これにより、SPS間の手動構成または自動化された情報交換が使用される場合があります。VPN発見のための1つ以上のメカニズムが標準化され、複数のSPS全体でサポートされている場合、自動交換が促進される場合があります。たとえば、どの情報とVPNに関する情報をSPS間で交換できるかを決定するために、SP間の信頼関係を確立する必要があります。
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.
SPS間で共有する必要がある情報の量は、マルチSP VPNのサイズ数によって大きく異なる場合があります。したがって、SPSは、交換する予想されるメンバーシップ情報とこの情報の動的な性質を決定し、同意する必要があります。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情報の分布は、インターネット全体に分配する必要があるため、Provider間ルーティング情報の分布とは異なります。さらに、2つのSPSによるVPNの共同サポートは、そのVPNの状態を維持するために3番目のSPを必要としないはずです。繰り返しますが、プロバイダー間ルーティングに関する違いに注意してください。プロバイダー間ルーティングでは、あるSPから別のSPにトラフィックを送信するには、実際に3番目の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.
考えられる例として：共通のVPNをサポートしたい2つのSPS AとCがあると仮定します。AとCがSP Bを介して相互接続されていると仮定します。この場合、BはAとCの間でトラフィックをルーティングする方法を知る必要があるため、AとCについて何かを知る必要があります（IPトラフィックを転送するのに十分なルーティング情報などを知る必要があります。/または、Aおよびc）のPESまたはルートリフレクター間のMPLS LSPを接続します。ただし、スケーリングのために、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ベースのVPNSでは、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ベースのVPNSでは、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ごとのトンネルを確立する必要があり、その後、ルートはそれらのトンネルを介して分布します。したがって、適切なトンネルのセットを確立することにより、1つはVPNごとのルーティング情報の分布を暗黙的に制約および制御します。このスキームでは、メンバーシップ情報の分布は、各PEに存在するVPNのセットと、目的のトポロジに関する情報で構成されています。これにより、PEは特定のVPNのトンネルを確立する必要があるリモート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ルーティング情報の分布はルートフィルタリングによって制約されます。VPNメンバーシップがPEで変更されると、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サイトは互いに到達できます。トポロジは、サイト間のトラフィックのルーティング方法を単に制約します。たとえば、サイトAとサイトBの間のあるトポロジートラフィックでは、VPNバックボーンを介して直接直接移動します。別のトポロジでは、サイトAからサイトBへのトラフィックは、サイト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 Edgeデバイスでいくつかのリソースを消費し、トンネルの種類に応じて、中間ルーターまたはLSRでリソースを消費する場合としない場合があります。部分的なメッシュトポロジを使用する理由の1つは、VPNエッジデバイス、および/またはネットワークをサポートする必要があるトンネルの数を減らすことです。もう1つの理由は、管理者が特定のサイトからのすべてのトラフィックが、ファイアウォールを介してトラフィックを強制するか、監視または会計目的のために特定のサイトまたは制御上の理由でいくつかの特定のサイトを通過することを要求するシナリオをサポートすることです。各VPNに使用されるトポロジーは個別であるため、同じVPNエッジデバイスが1つの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エッジデバイスに添付されているSKIED EDGEデバイスにテレコミューターが取り付けられているため、基礎となるトラフィックフローにマッピングされます。電気在庫間のトラフィックは依然としてサポートされていますが、このトラフィックはハブ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 EdgeデバイスがVPNごとのトポロジ情報を他のVPN Edgeデバイスに宣伝できるようになります。同じメカニズムを使用して、メンバーシップ情報が宣伝されていると同時にこれを宣伝するのが最も簡単かもしれません。
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 Edgeデバイスは一連のトポロジグループを宣伝できます。これは、グループが共通している場合は、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 Edgeデバイスから別のデバイスに輸送するために、トンネリングを使用します。さまざまな種類のトンネルプロトコル、トンネルの確立と維持方法、およびトンネルをVPNに関連付けるさまざまな方法（たとえば、共有と専用のVPNごとのトンネルなど）があります。セクション4.3.1〜4.3.5では、あらゆる形態のトンネリングが共有するいくつかの一般的な特性と、トンネルがソリューションを提供するいくつかの一般的な問題について説明します。セクション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トラフィックは、非ユニークまたはプライベートIPアドレス指定[RFC1918]を使用できます。また、IPv4プロバイダーバックボーン全体にIPv6 VPNを実装できます。そのため、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.
このセクションで検討されている特定のトンネルプロトコルは、GRE、IP-in-IP、IPSEC、およびMPLSです。これらは、VPNバックボーン全体にVPNトラフィックを運ぶのに最も適しているためです。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.
トンネルプロトコルの特徴の1つは、カプセル化されたパケットを転送するために、SPネットワークでトンネルごとの状態が必要かどうかです。IPトンネルスキーム（GRE、IP-in-IP、およびIPSEC）の場合、トンネルごとの状態は、VPNエッジデバイスに完全に限定されています。他のルーターはトンネルに気付いておらず、IPヘッダーに従って前方に進みます。MPLSの場合、ラベルスタックのトップレーベルを検査し、中間LSRによって交換する必要があるため、トンネルごとの状態が必要です。必要な状態の量は、以下で説明するように、階層的な多重化とマルチポイントを使用するためにトンネルをポイントすることによって最小限に抑えることができます。
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.
もう1つの特徴は、導入されたトンネリングオーバーヘッドです。IPSECを使用すると、ESPヘッダー、ESPトレーラー、追加のIPヘッダーなど、オーバーヘッドにはかなりの場合があります。リストされている他のメカニズムは、より少ないオーバーヘッドを使用し、MPLSが最も軽量です。トンネルメカニズムに固有のオーバーヘッドは、結果のパケットが大きすぎて基礎となるリンクレイヤーによって運ばれない場合、追加のIPパケット断片化をもたらす可能性があります。そのため、可能な限り断片化を避けるために、PATH 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にカプセル化されたパケットが複数のSPSのネットワークを越えなければならない場合、隣接するSPSは、MPLSパケットを相互に受け入れるために二国間協定を必要とする必要があります。バックボーンを横切るパスの一部のみにMPLSサポートがない場合、MPLS-in-IPカプセル化を使用して、バックボーンのその部分にMPLSパケットを移動できます。ただし、これは複雑さを追加します。一方、MPLには、特にカプセルがネストする必要がある環境では、効率の利点があります。
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.
o GRE：ソースIPアドレス、宛先IPアドレス、キーフィールドによるVPNに関連付けられたパケット。キーフィールドは元々認証を目的としていました。
o IP-in-IP: Packets associated to VPN by IP destination address in outer header.
o IP-in-IP：外側ヘッダーのIP宛先アドレスによるVPNに関連付けられたパケット。
o IPsec: Packets associated to VPN by IP source address, IP destination address, and SPI field.
o IPSEC：IPソースアドレス、IP宛先アドレス、およびSPIフィールドによるVPNに関連付けられたパケット。
o MPLS: Packets associated to VPN by label stack.
o MPLS：ラベルスタックによる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-in-IPトンネリングには実際の多重化フィールドがないため、特定のPEでサポートされているすべてのVPNに別のIP宛先アドレスを使用する必要があることに注意してください。他のIPベースのカプセルでは、特定のPEニーズには単一のIPアドレスしかなく、多重化フィールドを使用してPEでサポートされているさまざまなVPNを区別します。したがって、IP-in-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, 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.
一部のトンネルプロトコルの場合、トンネルをセットアップするには、シグナリングメッセージの明示的な交換が必要です。一般に、この交換の一環として、多重化フィールド値が合意されます。たとえば、IPSECカプセル化が使用される場合、SPIフィールドは多重化フィールドの役割を果たし、IKEシグナリングを使用してSPI値を分布させます。MPLSカプセル化が使用される場合、LDP、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-in-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 Edgeデバイスでこれに必要なリソースは重要な場合があり、回復までの時間には多数の回復に必要な時間が含まれているため、デバイスの障害後に回復するのに必要な時間などの問題は考慮に入れる必要がある場合があります。トンネル。
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.
コアルーターがトンネルごとの状態をまったく維持する必要がある場合、階層的なトンネルを使用することでスケーリングを大幅に改善できます。VPNエッジデバイスの各ペアの間に1つのトンネルを確立でき、複数の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エッジデバイスで維持される状態の量を減らすこともできます。特に、外側のトンネルを維持するには、外側のトンネル内で走る1つの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.
階層トンネルを使用した例の1つは、さまざまなIPSECセキュリティ協会の確立であり、VPNエッジデバイスの特定のペア間で異なるレベルのセキュリティを提供します。その後、VPNごとのGREトンネルをグループ化してから、VPNごとに別のIPSECトンネルを持つのではなく、適切なIPSECトンネルを持ち越すことができます。別の例は、MPLSラベルスタックの使用です。単一のPE-PE LSPを使用して、すべてのVPN LSPを運ぶために使用されます。ラベル確立に使用されるメカニズムは通常、異なります。PE-PE LSPは、セクション3.3.1.3および4.1で説明されているVPNルーティング（例：BGPを使用）でピギーバックすることによって確立された、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トンネルへの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ベースのVPNSおよびVRスキームにより、ルーティングの1つの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ラベルなし）、高層「Hello」メカニズムのタイムアウト（例：、IGP Hellos、トンネルがいくつかの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.
階層的なトンネルでは、接続性の損失のために最も外側のトンネルのみを監視するだけで十分かもしれません。ただし、最も外側のトンネルが上昇しているが、内側のトンネルの1つが下がっているデバイスに故障モードがある場合があります。
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].
トンネリングメカニズムは、2つの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スイッチベンダーは一般に、IPトンネリングと積み重ねられたVLANオーバーヘッドを認識しているため、多くのスイッチは実際に約1512バイトのMTUを許可しています。この場合、断片化のリスクがある前に、最大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であり、キーフィールドが存在しない場合、GREのカプセル化は、少なくとも28バイトのオーバーヘッドを追加します（キーフィールド拡張を使用する場合、36バイト）。
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-in-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-in-IP仕様は、多重化を明示的にサポートしていません。ただし、VPNごとに別のIPアドレスが使用される場合、この目的には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-in-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-in-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-in-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-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-Security Associationが構成されています。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に存在するメカニズムを継承します。「IPSECデータフローのRSVP拡張機能」[RFC2207]やDiffServ拡張[RFC2983]などの他のメカニズムを使用することができます。
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が複数のSPSによって共同で提供されている場合、そのトップレーベルが実際にそのルーターに配布されたものである場合にのみ、別の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をサポートしない3分の1で区切られている場合、MPLS-in-IPまたはMPLS-in-IPECトンネリングの間で行われる場合があります。
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ベースのVPNSでは、PEデバイスは、顧客ネットワークから受け取ったパケットのIPヘッダーを調べます。転送は、顧客ネットワークから受け取ったルーティング情報に基づいています。これは、PEデバイスが顧客ネットワークのルーティングに何らかの方法で参加する必要があることを意味します。セクション3.3では、顧客インターフェイスを含む顧客ネットワークでルーティングがどのように行われるかについて説明しました。このセクションでは、特定のVPNからのルーティング情報が、そのVPNに付着するPESのセットの中で、共有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.
PESは、2種類のルーティング情報を相互に配布する必要があります。（i）パブリックルーティング：VPNバックボーンのアドレスに到達する方法を指定するルーティング情報（つまり、「パブリックアドレス」）。これを「パブリックルーティング情報」（ii）VPNルーティング：VPNにあるアドレス（「プライベートアドレス」）に到達する方法を指定するCESから取得したルーティング情報。
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.
最初のカテゴリのルーティング情報が分散される方法は、このドキュメントの範囲外です。2番目のカテゴリのルーティング情報の分布のみについて説明します。もちろん、VPNルーティング情報を配布するための要件の1つは、公開情報とは別々に識別されることです。別の要件は、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.
同様に、1つの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ベースのVPNSのように、この問題はCEベースのVPNSでは発生しないことに注意してください。PEデバイスは、パケットがパブリックアドレスのみを持つ外側ヘッダーにカプセル化されるまで、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 RIP [RFC2453]
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ベースのVPNSでは、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ベースのVPNSでは、同じVPNにあるいくつかのCEデバイスに接続された単一のPEデバイスであり、異なるVPNのCEデバイスにも接続される場合があります。特定のパケット内の特定のIP宛先アドレスに対してPEが選択するルートは、パケットが受信された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.
ローカルサイトへのルートは、いくつかの方法で取得できます。1つの方法は、静的ルートをVFIに明示的に構成することです。これは簡単な展開で役立つ場合がありますが、顧客のネットワーク内の1つ以上のデバイスを静的ルート（おそらくデフォルトルートのみ）で構成する必要があります。そのため、トラフィックはサイトからPEデバイスに向けられます。
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（たとえば、CEのVPNのリモートサイトからPEが取得したすべてのルート）に多数のルートを宣伝する必要がある場合があります。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のルーティング情報を提供する場合があります。詳細については、セクション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.
1つのオプションは、各VPNの1つのインスタンスであるPES間のルーティングプロトコルの個別のインスタンスを操作することです。これが完了すると、各顧客ネットワークのルーティングプロトコルパケットを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.
別のオプションは、PES間にVPNルーティング情報を運ぶために、ルーティングプロトコルの1つのインスタンスを使用することです。この方法では、複数の異なる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のペア間で複数のそのような隣接を維持する必要がなくなったため、PESが維持しなければならないルーティング隣接の数を大幅に削減します。単一のルーティングプロトコルが階層ルート分布メカニズム（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とそのローカルに接続されたCESの間のルーティング情報の交換をサポートするには、追加のルーティングインスタンスが引き続き必要になる場合があります。これらは、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デバイスのルーティングプロトコルインスタンスの数は、PEデバイスとCEデバイス間のルーティングが静的またはBGP-4の場合、PEデバイスでサポートされるCEの数に依存しません。ただし、BGP-4を除き、ルーティングプロトコルを使用してVPN交換ルート情報内のCEおよびPEデバイスは、PEデバイスのルーティングプロトコルエンティティの数は、PEデバイスでサポートされるCESの数に依存します。
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デバイスのみが1つの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ネットワークは、SPネットワーク内のインテリアルーティングにOSPFまたは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の両方は、リンク状態ルーティングプロトコルです。リンク状態ルーティングでは、ルーティング情報は洪水プロトコルを介して配布されます。ルーティングピアのセットは一般に完全にはメッシュ化されていませんが、セットのルーターから他のルーターへのパスがあります。洪水により、1つのルーターからのルーティング情報が他のすべてのルーターに到達することが保証されます。これには、同じルーティング情報を維持するために、セット内のすべてのルーターが必要です。さらに下流のピアがその情報を必要としないことがわかっていない限り、特定のピアからのルーティング情報を差し控えることはできませんでした。
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.
その結果、ルーティングピアのセットにあるすべてのPESを使用して、OSPFを使用して集約されたルーティングを実行しようとした場合、すべてのPEはまったく同じルーティング情報になります。ルーティング情報の分布をPESのサブセットに制約する方法はありません。多数の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に集約された場合、IGPルーティング情報のリーチを領域間およびSPS間で拡張するために、何らかの方法を使用する必要があります。
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ルーティング情報をパブリックインターネットルーティング情報と明確に区別する必要があります。これは通常、BGPの複数のアドレスファミリを処理する能力を利用し、VPNルートをパブリックインターネットルートとは異なる住所ファミリに扱うことによって行われます。通常、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.
VPN情報の携帯にBGPが使用される場合、BGP（インターネットルートとVPNルートを含む）で運ばれる情報の合計量は非常に大きい場合があります。上記のように、特定のプロバイダーによってサポートされている多数のVPNが存在する可能性があり、すべてのVPNに関連付けられたルーティング情報の合計量は非常に大きい場合があります。ただし、一般に、1人のPEは少数のVPNを認識する必要があります。これは、VPNルーティング情報がBGPに集約されている場合、どのVPN情報がどのPESに分散されるかを制限できることが望ましいことを意味します。
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ネットワーク内の集約されたルーティングの要件の1つを満たします。これにより、特定の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.
「Exterior BGP」（EBGP）では、ルーティングピアはルーティング情報を相互に再配分します。ただし、ルーティング情報の特定のアイテムの分布を制約することは非常に一般的です。これにより、「知る必要がある」が必要なのは、どのパスがどのパスがどのアドレスにつながるかについての先験的な知識が必要ですが、「知る必要がある」外部のピアにのみ行くことが非常に一般的です。。VPNルーティングの場合、VPNが小さな協力SPSのセットによって提供されている場合、そのような制約を適用して、そのVPNに関連するルーティング情報が必要ではない場所に配布されないようにすることができます。特定のVPNがプライベートピアリングアレンジメントを備えた少数の協力SPSによってサポートされる限り、これは特に簡単です。特定の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.
単一のルーティングドメイン（レイヤー3 VPNコンテキストでは、通常、単一のSPのネットワーク内で意味）は、IBGPルーターを1つまたは2つのルートリフレクターと直接ピアに並べるのではなく、1つまたは2つのルートリフレクターで直接ピアにすることがよくあります。これにより、1つのルーターがサポートする必要があるIBGP隣接の数が大幅に減少します。さらに、ルートリフレクターはルーティング情報を再配分するだけでなく、独自の決定プロセスを実行することにより、最初に情報を「消化」します。決定プロセスに耐えるルートのみが再配布されます。
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には、直接添付されているPESのみがVPNルーティング情報を持っているとすでに述べられています。スケーラビリティについては、すべてのVPNのすべてのルーティング情報を1つのルートリフレクターに必要としないようにすることも同様に重要です。結局のところ、VPNルートの総数（SPによってサポートされているすべてのVPNを超えて）が、単一のルートリフレクターでサポートできる数を超えることができます。したがって、VPNルート自体がパーティション化される場合があります。一部のルートリフレクターは、VPNルートの1つのサブセットと異なるサブセットを運ぶ他のルートリフレクターを搭載しています。パブリックインターネットルートを運ぶルートリフレクターは、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および1つのルートリフレクターが、PEとルートリフレクターが両方とも関心を持っているVPNのみに関する情報を交換できます。直接サポートしている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ルートがPESおよび/またはルートリフレクターの間で分割される方法は、展開の問題です。適切な展開手順では、これらのデバイスの容量が限られているため、サポートできる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.
o CE-PEルーティングが静的またはBGPの場合、VPNルートのPE-PE分布に使用される同じBGPインスタンスをPE-CEルート分布に使用できます。PESと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ベースのVPNSの場合、VPNサービスに使用されるのと同じリンク上のサービスプロバイダーがインターネットアクセスをサポートする場合があります。したがって、特定のCEからPEリンクは、プライベートネットワークIPパケット（VPNサービスを使用してプライベートネットワークのサイト間の送信）とパブリックインターネットトラフィック（プライベートサイトからインターネットへの送信、およびインターネットからのプライベートサイト）。このセクションでは、この場合のルーティングのスケーラビリティと安定性について説明します。この種の問題は、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ベースのVPNSの場合、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をサポートしているPESのインターネットルーティングへの参加を制限することが望ましい場合があります。または、大きな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の接頭辞に加えて、インターネットに100,000を超えるプレフィックスをサポートする必要がある場合があります。拡張および凝集したルーティングを使用すると、これは単一のルーティングプロトコル（おそらくBGP）で宣伝される可能性のある多数のルートを意味します。VRアプローチが使用される場合、さまざまなVPNごとのルーティングプロトコルインスタンスに100,000の近隣隣接もあります。場合によっては、この数のルーティングプレフィックスおよび/またはこの数の隣接を1つのデバイスでサポートするのが難しい場合があります。
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のインターネットルーティングへの参加を絶対的な最小限に制限することです。具体的には、PEは、直接接続されたCEデバイスを介してどのインターネットアドレスのプレフィックスに到達できるかを知る必要があります。他のすべてのインターネットルートは、1つ以上のPルーターを指す単一のデフォルトルートに要約される場合があります。多くの場合、デフォルトのルートが指示されるPルーターは、PEデバイスが直接接続されているPルーター（ほとんどのインターネットトラフィックの転送に使用する必要があるものです）である可能性があります。したがって、PEに直接接続されているM CEデバイスがあり、これらのMEデバイスがグローバルにアドレス指定可能なインターネットアドレスの合計の次のホップである場合、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サービスを実行するために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の数を制限する場合があります。たとえば、場合によっては、CESの完全なセットからのデータトラフィックを処理するのに十分なスループットがある場合でも、複数のCEのセットのVPNサービスをサポートするために2つの異なるPEデバイスを使用する必要がある場合があります。同様に、1つの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.
PESはすべての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から保護するために役立つ場合があります。または、インターネットルーティングを優先することにより、インターネットルーティングシステムをVPNルーティングシステムから保護しようとすることもできます。このような実装の問題は、このドキュメントの範囲外です。実装に不十分な信頼がある場合は、上記のように、VPNルーティングからインターネットルーティングを分離するために、展開手順を使用できます。
The following technologies for QoS/SLA may be applicable to PPVPNs.
QOS/SLAの次のテクノロジーは、PPVPNに適用できる場合があります。
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.
統合サービス、または略してIntServは、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 CodePointが割り当てられます。ネットワーク内では、トラフィックはDiffServ CodePointに従って処理されます。一部の動作集合体はすでに定義されています。迅速な転送挙動[RFC3246]はQoSを保証しますが、保証された転送動作[RFC2597]はトラフィックパケットの優先順位値を区別します。
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ネットワーク内で均等に扱われます。ポリシングは、1人のユーザーが割り当てを超えてクラス全体のプロビジョニングを敗北させることを防ぐために、入力で行われます。ユーザーがトラフィック契約を超えた場合、余分なパケットがオプションで破棄されるか、「契約過剰」としてマークされる場合があります。ネットワーク全体のルーターは、契約トラフィックで意図されたサービス保証をそのようなパケットが無効にしないことを確認するために、混雑に応じて契約パケットを優先的に破棄できます。
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.
このシナリオでは、プライベートアドレスの使用と潜在的なセキュリティスレッドの2つの潜在的な問題が特定されています。
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アドレスは、おそらくプライベートルーティングの領域に属し、パブリックインターネットでは使用できません。これは、VPN顧客がパブリックインターネットにアクセスできるようにするために、ネットワークアドレス変換関数（NATなど）を実装する必要があることを意味します。
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ベースのVPNSの場合、この翻訳関数はCEデバイスが接続されているPEに実装されます。レイヤー3プロバイダーがプロビジョニングしたCEベースのVPNSの場合、この翻訳関数は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 PEベースのVPNSの場合、このトラフィック分析機能はPEデバイス（または特定のVPNをサポートするVFI）に実装されますが、レイヤー3プロバイダーの場合、CEベースのVPNを提供する場合、この関数はCEデバイスに実装されます。
o Handling of a customer IP packet destined for the Internet
o インターネット用に運命づけられた顧客IPパケットの処理
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ベースのVPNSの場合、顧客サイトからの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).
さまざまな実装の選択が可能であることに注意してください。すべてのVFI（またはレイヤー3プロバイダーがプロビジョニングされたCEベースのVPNSのコンテキストの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を表示し、オプションで管理できる場所を1つ持っていると便利です。したがって、NMSは、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.
1つの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).
VPNS情報の分離されたアクセスは、顧客がいくつかの方法で情報へのアクセスを必要とすることがあるという点で重要です。まず、一部の顧客（またはオペレーター）が統計、構成、またはステータス情報にアクセスするために、VPNごとの特定のVPNのコンテキスト内でPE、CES、または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.
情報分離の場合、1人の顧客は、独自のVPNまたはVPNに関連する情報のみを表示できる必要があります。情報分離を使用して、SPがデバイスを管理するためにより便利にするように、デバイス上の管理オブジェクトのスペースを分割することもできます。特定の展開では、SPがすべてのVPNに関連する情報にアクセスできることも重要です。したがって、SPが既存のVPNに重複する管理ドメイン内に仮想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ごとに情報の分離とセキュリティアクセスも、運送業者のパラダイムのキャリアが採用されている場合に重要です。この場合、顧客（すなわち、サブキャリアまたはVPN卸売業者）が、キャリアのSPのキャリアへの管理オーバーヘッドコストを削減するために、それぞれのデバイスでVPN内のサービスを管理および提供することが望ましい場合があります。この場合、情報の隠れ、分離、暗号化に関する情報に関するガイドラインを遵守することが重要です。キャリアのsp。Carriers SPのキャリアが、PESまたは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アプローチの間の論理インターフェイスに位置する場合を示しています。このアプローチにより、2つ以上のレイヤー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パケットを転送できます。たとえば、レイヤー3 VPNをサポートするPEデバイスが、それぞれがプライベートネットワークの転送とルーティングをサポートする複数の論理VFI（セクション1、2、3.3.1、4.4.2）を含むことが一般的かもしれません。
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デバイスは1つのレイヤー3 VPNアプローチの操作に参加します。アプローチ間のインターワーキングは、PE間に設定されたVPNごとのトンネルを使用します。各PEは、それが通常のPESであるかのように動作し、各トンネルを特定の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インターフェイスに送信するのと同じ方法で、インターワーキングインターフェイスを介して送信できます。
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ネットワークにまたがる1つ以上の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ネットワークのPESは、ネットワーククラウドを介してのみ通信する可能性があるため、ネットワーククラウドを通じて確立された適切なトンネルは、インターワークされた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デバイスのVFI（PPVPNに関連付けられている）によって終了します。このシナリオの結果、インターワーキングインターフェイスによってサポートされ、複数のSPネットワークにまたがるPPVPNのトラフィックアイソレーションが実装されます（各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.
次のトンネルメカニズムは、インターワーキングインターフェイスで使用できます。利用可能なトンネルメカニズムには、GRE、IP-in-IP、ATM上のIP、FR、IPSEC、およびMPLSが含まれます（ただしに限定されません）。
o GRE
o GRE
The tunnels at interworking interface may be provided by GRE [RFC2784] with key and sequence number extensions [RFC2890].
インターワーキングインターフェイスのトンネルは、キーおよびシーケンス番号拡張[RFC2890]を使用してGRE [RFC2784]によって提供される場合があります。
o IP-in-IP
o IP-in-IP
The tunnels at interworking interface may be provided by IP-in-IP [RFC2003] [RFC2473].
インターワーキングインターフェイスのトンネルは、IP-in-IP [RFC2003] [RFC2473]によって提供される場合があります。
o IP over ATM AAL5
o ATM AAL5を介してIP
The tunnels at interworking interface may be provided by IP over ATM AAL5 [RFC2684] [RFC2685].
インターワーキングインターフェイスのトンネルは、ATM AAL5 [RFC2684] [RFC2685]を介してIPによって提供される場合があります。
o IP over FR
o FRを超えるIP
The tunnels at interworking interface may be provided by IP over FR.
インターワーキングインターフェイスのトンネルは、FRを介してIPによって提供される場合があります。
o IPsec
o IPSEC
The tunnels at interworking interface may be provided by IPsec [RFC2401] [RFC2402].
インターワーキングインターフェイスのトンネルは、IPSEC [RFC2401] [RFC2402]によって提供される場合があります。
o MPLS
o 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ベースのVPNSのサービスとして、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、IP-in-IP、IPSEC、およびMPLSトンネルのQOS/SLA管理メカニズムについては、セクション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、IS-IS、RIP、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に関する重要な要件の1つです。ネットワーク環境では、セキュリティという用語は現在、ネットワーキングの観点から最も重要なものが今後まもなく議論される多くの異なる側面をカバーしています。
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.
ネットワークまたはネットワークの一部がプライベートである場合、要件の1つは、そのネットワーク（パーツ）へのアクセスが限られた数の明確に定義された顧客に制限されている必要があることです。この要件を達成するために、責任当局は、ネットワークへのあらゆる可能なアクセスを制御する必要があります。
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.
特定のエンティティからデータを受け取ると、送信者の身元を確認したいと思います。送信エンティティは、実際に彼または彼女が主張する人であり、送信エンティティが特定の目的地に到達することを許可されていることを確認したいと思います。
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ネットワークを介して顧客サイトからPESによって受信されたデータと顧客サイトに向けられているデータの両方を認証する必要があります。
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ベースのVPNSのコンテキストでは、エンドポイント認証は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.
ネットワークの特定の部分で情報が交換されると、取引所の受信当事者が受信した情報が、交換の送信者によって送信された情報と同一であることを確認したいと思います。
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ベースのVPNSのコンテキストでは、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.
ある当事者から別の当事者に送信されている情報は受け取られず、他の当事者が読み取れないことを望みます。トラフィックフローの機密性により、送信された情報の特性が第三者から隠されていることを望んでいます。データプライバシーは、ユーザーデータの機密性です。
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.
レイヤー3 PEベースのVPNのコンテキストでは、SPネットワーク（およびより正確には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ネットワークは、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-To-PEの機密性は十分ではなく、VPN顧客が独自のプライベート機器にエンドツーエンドの暗号化を実装します（たとえば、提供されたVPN上のCEベースの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.
以前のサブセクションはユーザーデータの保護に焦点を当てていましたが、すべての制御データ（たとえば、VFIまたはCEデバイスの構成に使用されるVPNトンネルのセットアップに使用されます（レイヤー3プロバイダープロビジョニングベースのCEベースのCEベースのコンテキストでVPNS））は、プロバイダーがプロビジョニングしたVPNの意図的な誤解を防ぐために、SPによって保護されます。
In certain scenarios, a single VPN will need to cross multiple SPs.
特定のシナリオでは、単一のVPNを複数のSPSを越える必要があります。
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.
別のポイントは、関係するSPSが、異なるSPSに接続されたVPNネットワーク要素（VFI、PES、CEデバイスなど）の競合する構成情報を避けて密接に対話する必要があることです。
Appendix A: Optimizations for Tunnel Forwarding
付録A：トンネル転送の最適化
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をサポートするために、PES内の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.
これは、最も簡単な実装では、単一のPEデバイスで3つのヘッダールックアップが必要になる可能性があることを意味します。1つのルックアップは、これがVPNトンネルの終わりであることを識別する可能性があります（関連するヘッダーを取り除く必要性を意味します）。2回目の検索では、これがVPN固有のトンネルの終わりであることを特定する場合があります。このルックアップにより、2番目のカプセル化ヘッダーが剥がれ、最終検索のVFIコンテキストが識別されます。最後のルックアップは、VPNに関連付けられたIPアドレススペースを使用し、パケットが正しいVPN内の正しいCEに転送されます。
Penultimate hop popping is an optimization which is described in the MPLS architecture document [RFC3031].
Penultimate Hop Poppingは、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ヘッダーは実際には有用な情報を伝えません（以下で説明する1つの状況を除く）。
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ヘッダーをストリップすることを要求できます。要求された場合、これは、最後から2番目のノードに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ヘッダーが有用な情報を伝えるケースは1つあります。これは、PEデバイスで終了するVPN固有のLSPの場合です。この場合、ラベルの値は、パケットがどのLSPが到着しているかをPEに伝えます。これは、パケットに使用されるVFI（つまり、どのVPN固有の転送テーブルを使用する必要があるかを決定するために使用されます。パケット）。
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-To-PE LSP内で多重化されている場合を考えてください。また、この場合、出口PEは、そのPEのコンテキストですべての着信ラベル（すべてのLSPに対して）がユニークであることを選択したと仮定します。これは、PE-ToPE LSPに関連付けられたラベルが出口ノードでは必要ないことを意味します。むしろ、VPN固有のLSPに基づいて使用するVFIを決定できます。この場合、出力PEは、PE-To-PE LSPの最後から2番目のLSRが最後から2番目のラベルを実行することを要求できます。これにより、出口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.
最後から2番目のノードラベルポップは、複数のレベルのLSPを使用するVPN標準にのみ適用できることに注意してください。この場合でも、ペラルテーションノードラベルポップは、出力ノードが最後から2番目のノードから特別に要求した場合にのみ行われます。
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はどのセットのVPNパケットを特定のLSPにマッピングできるかを知る必要があります。
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がそれに応じてセットアップされている場合、出力ノードは他のPESからLSPに到着するVPNトラフィックを検索する必要はありません（言い換えれば、PEデバイスは、出力ノード）。
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はまだ1つのヘッダールックアップのみを実行する必要があります。
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トンネルで使用する場合、このオプションの最適化により、ヘッダールックアップの必要性が減り、割り当てられる必要があるラベル値の数を増やす可能性があります（1つのラベルを次の各デバイスに割り当てる必要があります。すべてのVFIの1つのラベルよりも）。
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-in-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.
ただし、このドキュメントのソースは、著者や貢献者の同僚からのさまざまな入力に基づいています。unichi junichi、Kosei Suzuki、kurakimi、Hiroshi Hamano、Naoto Makinae、Kinichi Kitami、Rajesh Balay、Anoop Ghanwani、Harpreet Chadha、Samir Jain、Lianghwa Jou、vijay srinivasan、
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.
また、Yakov Rekhter、Scott Bradner、Dave McDysan、Marco Carugi、Pascal Menezes、Thomas Nadeau、Alex Zininの貴重なコメントと提案に感謝します。
Normative References
引用文献
[PPVPN-REQ] Nagarajan, A., Ed., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[PPVPN-REQ] Nagarajan、A.、ed。、「プロバイダープロビジョニング仮想プライベートネットワーク（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.、ed。and D. McDysan、ed。、「レイヤー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] Sangli、S.、et al。、「BGP Extended Communities Attribution」、Work in Progress、2005年2月。
[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] Le Faucheur、F.、ed。、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張」、2004年12月、進行中の作業。
[VPN-2547BIS] Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.
[VPN-2547bis] Rosen、E.、et al。、「BGP/MPLS VPNS」、作業進行中。
[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] Rosen、E.、et al。、「BGP/MPLS IP VPNSのプロバイダー/カスタマーエッジプロトコルとしてのOSPF」、2005年5月、進行中の作業。
[VPN-CE] De Clercq, J., et al., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work In Progress.
[VPN-CE] de Clercq、J.、et al。、「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.
[VPN-Disc] Oould-Brahim、H.、et al。、「レイヤー3およびレイヤー-2 VPNの自動発見メカニズムとしてBGPを使用する」、進行中の作業。
[VPN-L2] Andersson, L. and E. Rosen, Eds., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work In Progress.
[VPN-L2] Andersson、L。and E. Rosen、eds。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、進行中の作業。
[VPN-VR] Knight, P., et al., "Network based IP VPN Architecture Using Virtual Routers", Work In Progress, July 2002.
[VPN-VR] Knight、P.、et al。、「仮想ルーターを使用したネットワークベースのIP VPNアーキテクチャ」、2002年7月の作業。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities属性」、RFC 1997、2001年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Mankin、A.、ed。、Baker、F.、Braden、B.、Bradner、S.、O'Dell、M.、Romanow、A.、Weinrib、A.、およびL. Zhang、 "Resource予約プロトコル（RSVP）バージョン1の適用性ステートメント展開に関するいくつかのガイドライン」、RFC 2208、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張」、RFC 2207、1997年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1994.
[RFC2453] Malkin、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] Conta、A。およびS. Deering、「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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、「レイヤー2トンネリングプロトコル 'L2TP'」、RFC 2661、1999年8月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation Over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[RFC2685] Fox B. and B. Gleeson, "Virtual Private Networks Identifier," RFC 2685, September 1999.
[RFC2685] Fox B.およびB. Gleeson、「仮想プライベートネットワーク識別子」、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. Zhang、「RSVP Operation over IP Tunnels」、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] Gleeson、B.、Lin、A.、Heinanen、J.、Armitage、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（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.
[RFC2858] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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] Rosen E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「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] Davie、B.、Lawrence、J.、McCloghrie、K.、Rosen、E.、Swallow、G.、Rekhter、Y.、およびP. Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC 3035、2001年1月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, June 1996.
[RFC3065] Traina、P.、McPherson、D。、およびJ. Scudder、「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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」PHB（ホップごとの動作）を転送する」、RFC 3246、2002年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。
Contributors' Addresses
貢献者の住所
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium
Jeremy de Clercq Alcatel Fr.Wellesplein 1、2018 Antwerpen、ベルギー
EMail: jeremy.de_clercq@alcatel.be
Bryan Gleeson Nokia 313 Fairchild Drive, Mountain View, CA 94043 USA.
ブライアングリーソンノキア313フェアチャイルドドライブ、マウンテンビュー、カリフォルニア94043 USA。
EMail: bryan.gleeson@nokia.com
Andrew G. Malis Tellabs 90 Rio Robles Drive San Jose, CA 95134 USA
Andrew G. Malis Tellabs 90 Rio Robles Drive San Jose、CA 95134 USA
EMail: andy.malis@tellabs.com
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886, USA
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford、MA 01886、USA
EMail: mkarthik@lucent.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719, USA
Eric C. Rosen Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA、01719、USA
EMail: erosen@cisco.com
Chandru Sargor Redback Networks 300 Holger Way San Jose, CA 95134, USA
Chandru Sargor Redback Networks 300 Holger Way San Jose、CA 95134、USA
EMail: apricot+l3vpn@redback.com
Jieyun Jessica Yu
University of California, Irvine
5201 California Ave., Suite 150,
Irvine, CA, 92697 USA
EMail: jyy@uci.edu
Authors' Addresses
著者のアドレス
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146, USA
ロスコロンジュニパーネットワーク10テクノロジーパークドライブマサチューセッツ州ウェストフォード01886-3146、米国
EMail: rcallon@juniper.net
Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
Suzuki NTT NTT情報共有プラットフォームラボ。3-9-11、Midori-Cho、Musashino-Shi、Tokyo 180-8585、日本
EMail: suzuki.muneyoshi@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet gement
RFCエディター関数の資金は現在、インターネットゲメントによって提供されています