RFC4110 日本語訳
4110 A Framework for Layer 3 Provider-Provisioned Virtual PrivateNetworks (PPVPNs). R. Callon, M. Suzuki. July 2005. (Format: TXT=204159 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Callon
Request for Comments: 4110 Juniper Networks
Category: Informational M. Suzuki
NTT Corporation
July 2005
Callonがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4110年の杜松はカテゴリをネットワークでつなぎます: 情報のM.鈴木NTT社の2005年7月
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)インターネット協会(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.
このドキュメントはLayer3のProviderによって食糧を供給されたVirtual兵士のNetworks(PPVPNs)に枠組みを供給します。 この枠組みが層3のPPVPNsのサポートのためにプロトコルとメカニズムの標準化で支援することを意図します。 層3のPPVPN溶液のデザインで重要であるのは、このドキュメントが重要な専門的な問題の一貫性を持っている記述を起こす意図です。 特定のアプローチの品揃え、工学見返りに関する作成選択、および詳細なプロトコル仕様がこの枠組みのドキュメントの範囲の外にあります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives of the Document . . . . . . . . . . . . . . . 3
1.2. Overview of Virtual Private Networks . . . . . . . . . . 4
1.3. Types of VPNs. . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. CE- vs PE-based VPNs . . . . . . . . . . . . . . 8
1.3.2. Types of PE-based VPNs . . . . . . . . . . . . . 9
1.3.3. Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
1.4. Scope of the Document. . . . . . . . . . . . . . . . . . 10
1.5. Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
2.1.1. Entities in the Reference Model. . . . . . . . . 16
2.1.2. Relationship Between CE and PE . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 ドキュメント. . . . . . . . . . . . . . . 3 1.2の目的。 仮想私設網. . . . . . . . . . 4 1.3の概観。 VPNsのタイプ。 . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. Ce対PEベースのVPNs. . . . . . . . . . . . . . 8 1.3.2 PEベースのVPNs. . . . . . . . . . . . . 9 1.3.3人のタイプ。 3PEベースのVPNsを層にしてください。 . . . . . . . . . . . . . 10 1.4. ドキュメントの範囲。 . . . . . . . . . . . . . . . . . 10 1.5. 用語。 . . . . . . . . . . . . . . . . . . . . . . 11 1.6. 頭文字語. . . . . . . . . . . . . . . . . . . . . . . . 13 2。 参照は.142.1をモデル化します。 層3のPEベースのVPN. . . . . . . . 14 2.1.1のための規範モデル。 参照における実体はモデル化されます。 . . . . . . . . 16 2.1.2. CeとPE. . . . . . . . . 18との関係
Callon & Suzuki Informational [Page 1] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[1ページ]鈴木の情報のRFC4110
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
2.1.3. モデル. . . . . . . . . . . . . . . 19 2.2を織り込みます。 層3のプロバイダーで食糧を供給されたCeベースのVPN. . . . . . . . . . . . . . . . . . . . . . 21 2.2.1のための規範モデル。 参照における実体はモデル化されます。 . . . . . . . . 22 3. 顧客インタフェース. . . . . . . . . . . . . . . . . . . . . . 23 3.1。 顧客のVPN設立は連結します。 . . . . . . 23 3.1.1. 層3のPEベースのVPN. . . . . . . . . . . . . . 23 3.1.1の.1。 .243.1に.2に.1を縛る静電気 ダイナミックな結合。 . . . . . . . . . . . 24 3.1.2. 3のプロバイダーで食糧を供給されたCeベースのVPNを層にしてください。 . . . 25 3.2. 顧客のデータ交換は連結します。 . . . . . . . . 25 3.2.1. 3のPEベースのVPN. . . . . . . . . . . . . . 25 3.2.2を層にしてください。 3のプロバイダーで食糧を供給されたCeベースのVPNを層にしてください。 . . . 26 3.3. 顧客の目に見えるルート設定. . . . . . . . . . . . . . . . 26 3.3.1。 層3のPEベースのVPNs. . . . . . . . . . . . . . . . . . . . . . 26 3.3.1のために.1に掘る顧客視点 イントラネット. . . . . . . . 27 3.3.1のために、.2に掘ります。 エクストラネット. . . . . . . . 28 3.3.1のために、.3に掘ります。 層3のPEベースのVPNsのためのCeとPE装置。 . . . . . . . . . . . . 29 3.3.2. 層3のプロバイダーのためのルート設定の顧客視点はCeベースのVPNsに食糧を供給しました。 . . . . . . . . . . . 29 3.3.3. 顧客の目に見えるルート設定. . . . . . 30 4のためのオプション。 VPNs. . . . . . . . . . . 32 4.1のインタフェースとSPサポートをネットワークでつないでください。 VPN. . . . . . . . . . . . . 32 4.2の機能部品。 VPN設立と維持。 . . . . . . . . . . . 34 4.2.1. VPN発見、.354.2 .1 .1。 会員資格情報のためのネットワークマネージメント。 . . . . . . . . . . . . . 35 4.2.1.2. ディレクトリサーバ。 . . . . . . . . . . 36 4.2.1.3. 会員資格情報のためのルート設定を増大させました。 . . . . . . . . . . . . . 36 4.2.1.4. 相互SP VPNsのためのVPN発見。 . . . 37 4.2.2. VPN経路情報. . . . . . . . . . . . . . . . . . 38 4.2.3の分配を抑制します。 VPNトポロジー. . . . . . . . . . . . 38 4.3を制御します。 VPNトンネリング. . . . . . . . . . . . . . . . . . . . . 40 4.3.1。 カプセル化にトンネルを堀ってください。 . . . . . . . . . . . . . 40 4.3.2. マルチプレクシングにトンネルを堀ってください。 . . . . . . . . . . . . . . 41 4.3.3. 設立. . . . . . . . . . . . . . 42 4.3.4にトンネルを堀ってください。 スケーリングと階層的なTunnels. . . . . . . . 43 4.3.5。 維持. . . . . . . . . . . . . . . 45 4.3.6にトンネルを堀ってください。 トンネリングテクニック. . . . . . . . . 46 4.3.6.1人の調査。 GRE、.464.3 .6 .2。 IPにおけるIPカプセル化. . . . . . . . 47 4.3.6、.3 IPsec。 . . . . . . . . . . . . . . . . 48 4.3.6.4. MPLS. . . . . . . . . . . . . . . . . 49 4.4。 VPN経路情報のPE-PE分配。 . . . . . 51
Callon & Suzuki Informational [Page 2] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[2ページ]鈴木の情報のRFC4110
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
4.4.1. sp.におけるVPNルート設定のためのオプション . . . . . . . 52 4.4.2. VPN推進例. . . . . . . . . . . . 52 4.4の.3。 1VPNあたりのルート設定. . . . . . . . . . . . . . . . 53 4.4.4。 .1にルート設定モデル. . . . . . . . . . . . 54 4.4.4に集めます。 または、OSPFとのルート設定に集合である、- 55 4.4.4.2. BGPとのルート設定に集めました。 . . . . . 56 4.4.5. 層3のPEベースのVPNsとのルート設定のスケーラビリティと安定性。 . . . . . . . . . . . . . . . . 59 4.5. サービスの質、SLA、およびIP微分されたサービス61 4.5.1。 IntServ/RSVP. . . . . . . . . . . . . . . . . . 61 4.5.2。 DiffServ. . . . . . . . . . . . . . . . . . . . 62 4.6。 VPNsへの同時発生のアクセスとインターネット. . . . . . . 62 4.7。 VPNsのネットワークと顧客管理。 . . . . . . . . 63 4.7.1. ネットワークと顧客管理。 . . . . . . . . 63 4.7.2. VPN情報. . . . . . 64 5の隔離されたアクセス。 インタフェース. . . . . . . . . . . . . . . . . . . . 66 5.1を織り込みます。 機能を織り込みます。 . . . . . . . . . . . . . . . . . 66 5.2. インタフェース. . . . . . . . . . . . . . . . . 66 5.2が.1であると織り込みます。 織り込むことにおけるトンネルは連結します。 . . . . . 67 5.3. 追加サービス. . . . . . . . . . . . . 68 5.4のサポート。 スケーラビリティ議論. . . . . . . . . . . . . . . . . 69 6。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 69 6.1. システムセキュリティ。 . . . . . . . . . . . . . . . . . . . . 70 6.2. コントロール. . . . . . . . . . . . . . . . . . . . . 70 6.3にアクセスしてください。 終点認証. . . . . . . . . . . . . . . . 70 6.4。 データの保全. . . . . . . . . . . . . . . . . . . . . 71 6.5。 秘密性。 . . . . . . . . . . . . . . . . . . . . 71 6.6. 利用者データとコントロールデータ. . . . . . . . . . . . . . . 72 6.7。 相互SP VPNs.72付録A:のためのセキュリティ問題 トンネル推進のための最適化。 . . . . . . . . . 73 A.1。 VFIs. . . . . . . . . . . . . . . 73A.2のヘッダールックアップ。 MPLS. . . . . . . . . . . . 73A.3のために飛び出す終わりから二番目のホップ。 トンネル出口VFIルックアップ74承認を排除する逆多重化。 . . . . . . . . . . . . . . . . . . . . . . . . . 75 標準の参照. . . . . . . . . . . . . . . . . . . . . . . 76の有益な参照. . . . . . . . . . . . . . . . . . . . . . 76貢献者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction
1. 序論
1.1. Objectives of the Document
1.1. ドキュメントの目的
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.
このドキュメントはLayer3のProviderによって食糧を供給されたVirtual兵士のNetworks(PPVPNs)に枠組みを供給します。 この枠組みが共同利用できる層3のPPVPNsを支持するためにプロトコルとメカニズムを標準化する際に支援することを意図します。
Callon & Suzuki Informational [Page 3] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[3ページ]鈴木の情報のRFC4110
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」はService Provider(SP)がVPNの管理と食糧を供給することに参加するVirtual兵士のNetworks(VPNs)を示します、セクション1.3で定義されるように。 プロバイダーが管理に参加できる複数の方法とVPNに食糧を供給するのがあります。 したがって、PPVPNsの複数の異なったタイプがあります。 枠組みのドキュメントは層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操作の技術的側面について議論します、最初に、顧客の観点から、そして、プロバイダー観点から。 明確に、これは操作に、規格とメカニズムのデザインで重要な専門的な問題の議論と層の3PPVPNsのサポートを含んでいます。 その上、層3のPPVPNの織り込むことの技術的側面ははっきりさせられます。 最終的に、3PPVPNsを層にするのに申し込むとき、安全保障問題は記述されます。
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戦略を指定するために、各問題を解決する特定の方法を選ばなければなりませんが、このドキュメントは、選択をしないで、またVPNsを支持するために少しの特定のアプローチも選択しません。
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に基づいた選択を要件、顧客の要望、実現費用、および工学見返りにする必要に注意してください。 意志が必要があるソリューションが柔軟性(複数のオプションをサポートする)と簡潔を選んだ、(特定の選択が実現と展開を簡素化するためにゆだねる、) 枠組みのドキュメントはこれらの選択に入力されるように使用された問題と評価基準について議論できますが、解決策の特定の選択が枠組みのドキュメントの範囲の外にあります。
1.2. Overview of Virtual Private Networks
1.2. 仮想私設網の概観
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".
(b) (a) セットとサイトの外のセットにおけるサイトのコミュニケーションが制限されるところで「仮想私設網」(VPN)という用語はサイトを伝えるセットについて言及しますが、VPNのサイトのコミュニケーションはまた、VPNにないサイトによって使用されるネットワークインフラの上で行われます。 ネットワークインフラが複数のVPNs(そしてことによると非VPN交通でも)によって共有されるという事実は私設のネットワークとVPNを区別することです。 私たちは「VPN背骨」とこの共用回線網インフラストラクチャを呼ぶつもりです。
Callon & Suzuki Informational [Page 4] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[4ページ]鈴木の情報のRFC4110
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ネットワークであるケースだけに関係があります。 さらに、それらが顧客のエッジデバイスから受信することをService Providerのエッジデバイスがプロバイダー縁(PE)かCustomer Edge(CE)にかかわらずパケットのIP、そして/または、MPLSヘッダーを見ることによってVPN交通を発送する方法を決定するケースだけに私たちを心配させます。 これはLayer3VPNsの区別の特徴です。
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.
いくつかの場合、1SPが別の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.
VPNsはイントラネットであるかもしれません、複数のサイトがただ一つの顧客管理のコントロールの下でどれであるかで、単一の会社の複数のサイトなどのように。 あるいはまた、VPNsはエクストラネットであるかもしれません、会社、供給者、およびその顧客にとって、対応するサイトなどのように。(そこでは、複数のサイトが異なった顧客の政権によって制御されます)。
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ネットワークの中のProvider Edge装置です。 CE1、CE2、およびCE3は顧客ネットワークの中のCustomer Edge装置です。 ルータのr3、r4、r5、およびr6は顧客サイトへの内部のIPルータです。
Callon & Suzuki Informational [Page 5] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[5ページ]鈴木の情報のRFC4110
............ ................. ............
. . . . . .
. +---+ +-------+ +-------+ +---+ .
. r3---| | | | | |----|CE2|---r5 .
. | | | | | | +---+ .
. |CE1|----| PE1 | | PE2 | : .
. | | | | | | +---+ .
. r4---| | | | | |----|CE3|---r6 .
. +---+ +-------+ +-------+ +---+ .
. Customer . . Service . . Customer .
. site 1 . . provider(s) . . site 2 .
............ ................. ............
............ ................. ............ . . . . . . . +---+ +-------+ +-------+ +---+ r3---| | | | | |----|CE2|---r5。| | | | | | +---+ . . |CE1|----| PE1| | PE2| : . . | | | | | | +---+ r4---| | | | | |----|CE3|---r6+---+ +-------+ +-------+ +---+ 顧客サービス顧客サイト1プロバイダーサイト2。 ................. ............
Figure 1.1.: VPN interconnecting two sites.
図1.1.: 2つのサイトとインタコネクトするVPN。
In many cases, Provider Edge (PE) and Customer Edge (CE) devices may be either routers or LSRs.
多くの場合、Provider Edge(PE)とCustomer Edge(CE)装置は、ルータかLSRsのどちらかであるかもしれません。
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).
本書では、Service Providersのネットワークは、IPかMPLSネットワークです。 Service Providersのネットワークを通して顧客ネットワークサイトとインタコネクトするのは必要です。 いくつかのVPN解決策が、VPNサービスがただ一つのSPネットワークの上、または、小さいセットの密接に協力関係を持っているSPネットワークの上に提供されるのを必要とします。 他のVPN解決策が、VPNサービスが任意のセットの最少量で協力関係を持っているSPネットワーク(すなわち、公共のインターネットの上の)の上に提供されるのを許容することを意図します。
In many cases, customer networks will make use of private IP addresses [RFC1918] or other non-unique IP address (i.e., unregistered addresses); there is no guarantee that the IP addresses used in the customer network are globally unique. The addresses used in one customer's network may overlap the addresses used in others. However, a single PE device can be used to provide VPN service to multiple customer networks, even if those customer networks have overlapping addresses. In PE-based layer 3 VPNs, the PE devices may route the VPN traffic based on the customer addresses found in the IP headers; this implies that the PE devices need to maintain a level of isolation between the packets from different customer networks. In CE-based layer 3 VPNs, the PEs do not make routing decisions based on the customer's private addresses, so this issue does not arise. For either PE or CE-based VPNs, the fact that the VPNs do not necessarily use globally unique address spaces also implies that IP packets from a customer network cannot be transmitted over the SP network in their native form. Instead, some form of encapsulation/tunneling must be used.
多くの場合、顧客ネットワークはプライベートIPアドレス[RFC1918]か他の非固有のIPアドレス(すなわち、登録されていないアドレス)を利用するでしょう。 顧客ネットワークに使用されるIPアドレスがグローバルにユニークであるという保証が全くありません。 1人の顧客のネットワークに使用されるアドレスは他のもので使用されるアドレスを重ね合わせるかもしれません。 しかしながら、複数の顧客ネットワークに対するサービスをVPNに供給するのに単一のPE装置を使用できます、それらの顧客ネットワークに重なっているアドレスがあっても。 PEベースの層の3VPNsでは、PE装置はIPヘッダーで見つけられた顧客の住所に基づくVPN交通を発送するかもしれません。 これは、PE装置が、異なった顧客ネットワークからパケットの間の孤立のレベルを維持する必要であるのを含意します。 CEベースの層の3VPNsでは、PEsがルーティングを顧客のプライベート・アドレスに基づく決定にしないので、この問題は起こりません。 また、PEかCEベースのVPNsのどちらかに関しては、VPNsが必ずグローバルにユニークなアドレス空間を使用するというわけではないという事実は、それらのネイティブのフォームで顧客ネットワークからのIPパケットをSPネットワークの上に伝えることができないのを含意します。 代わりに、何らかのフォームのカプセル化/トンネリングを使用しなければなりません。
Callon & Suzuki Informational [Page 6] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[6ページ]鈴木の情報のRFC4110
Tunneling is also important for other reasons, such as providing isolation between different customer networks, allowing a wide range of protocols to be carried over an SP network, etc. Different QoS and security characteristics may be associated with different tunnels.
また、トンネリングも他の理由で重要です、異なった顧客ネットワークの間に孤立を提供するのなどように、さまざまなプロトコルがSPネットワークなどの上まで運ばれるのを許容して 異なったQoSとセキュリティの特性は異なったトンネルに関連しているかもしれません。
1.3. Types of VPNs
1.3. VPNsのタイプ
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.
このセクションはVPNsの複数のタイプ、および異なったタイプの間の工学見返りのいくつかについて説明します。 VPNsの異なったタイプについてどちらかに決めるのはこのドキュメントまで達していません。 VPNsの異なったタイプは異なった状況で適切であるかもしれません。
There is a wide spectrum of types of possible VPNs, and it is difficult to split the types of VPNs into clearly distinguished categories.
可能なVPNsのタイプの広いスペクトルがあります、そして、VPNsのタイプを明確に区別されたカテゴリに分けるのは難しいです。
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がATMリンクをCE装置[VPN-L2]の間の層2のVPNサービスに取り替えるように導くかもしれません。 自動発見は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
しばらくして、SPは、顧客の構内の多くの装置を管理しているためにそれがあまりに多くの問題であると決めて、プロバイダー構内にあるように代わりに物理的にこれらのルータを動かすかもしれません。 プロバイダー構内のそれぞれの縁のルータはそれにもかかわらず、独身のVPNに捧げられるかもしれません。 操作は変わりがないかもしれない、(私設のネットワークにおける縁のルータから他のルータへのリンクがLANリンクの代わりにMANリンクになって、縁のルータからプロバイダーコアルータへのリンクはLANリンクになります。
Callon & Suzuki Informational [Page 7] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[7ページ]鈴木の情報のRFC4110
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.
の代わりにする、MANリンク) 現在プロバイダー縁のルータであると問題のルータを考えることができます、そして、現在、SPによって提供されたサービスは本質的には3VPNが調整する層になりました。
In order to minimize the cost of equipment, the provider might decide to replace several dedicated PE devices with a single physical router with the capability of running virtual routers (VR) [VPN-VR]. Protocol operation may remain unchanged. In this case the provider is offering a layer 3 VPN service making use of a VR capability. Note that autodiscovery might be used in a manner which is very similar to how it had been done in the layer 2 VPN case described above (for example, BGP might be used between VRs for discovery of other VRs supporting the same VPN).
設備費を最小にするために、プロバイダーは、仮想のルータ(VR)[VPN-VR]を走らせる能力で数台の専用PE装置をただ一つの物理的なルータに取り替えると決めるかもしれません。 プロトコル操作は変わりがないかもしれません。 この場合、プロバイダーはVR能力を利用する3VPNサービスを層に提供しています。 autodiscoveryが2VPNケースが上で説明した層の中でどうそれをしたかと(例えば、BGPは他のVRsの発見に同じVPNを支持しながら、VRsの間で使用されるかもしれません)非常に同様の方法で使用されるかもしれないことに注意してください。
Finally, in order to simplify operation of routing protocols for the private network over the SP network, the provider might decide to aggregate multiple instances of routing into a single instance of BGP [VPN-2547BIS].
最終的に、私設のネットワークのためにSPネットワークの上でルーティング・プロトコルの操作を簡素化するために、プロバイダーは、BGP[VPN-2547BIS]のただ一つの例へのルーティングの複数の例に集めると決めるかもしれません。
In practice it is highly unlikely that any one network would actually evolve through all of these approaches at different points in time. However, this example illustrates that there is a continuum of possible approaches, and each approach is relatively similar to at least some of the other possible approaches for supporting VPN services. Some techniques (such as auto-discovery of VPN sites) may be common between multiple approaches.
実際には、どんなネットワークも時間内に実際にこれらのアプローチのすべてを通して異なったポイントで発展するのは、非常にありそうもないです。 しかしながら、この例は、可能なアプローチの連続があるのを例証します、そして、VPNサービスを支持するのに、それぞれのアプローチは少なくとも他の可能なアプローチのいくつかと比較的同様です。 いくつかのテクニック(VPNサイトの自動発見などの)が複数のアプローチの間で一般的であるかもしれません。
1.3.1. CE- vs PE-based VPNs
1.3.1. Ce PEベースのVPNsに対して
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」(または、Customer EdgeベースのVirtual兵士のNetwork)はPE装置が顧客ネットワークのルーティングかアドレシングに関して何も知らないアプローチを示します。 PE装置は、簡単なIPサービスを提供して、ヘッダーがグローバルにユニークなIPアドレスだけを含むIPパケットを受けると予想します。 Providerによって食糧を供給されたVPNにCEベースのVPNを作りかえることはSPがCE装置[VPN-CE]を管理して、食糧を供給するタスクを引き受けるということです。
In CE-based VPNs, the backbone of the customer network is a set of tunnels whose endpoints are the CE devices. Various kinds of tunnels may be used (e.g., GRE, IP-in-IP, IPsec, L2TP, MPLS), the only overall requirement being that sending a packet through the tunnel requires encapsulating it with a new IP header whose addresses are globally unique.
CEベースのVPNsでは、顧客ネットワークの背骨は終点がCE装置である1セットのトンネルです。 様々な種類のトンネルは使用されるかもしれません(例えば、GRE、IPにおけるIP、IPsec、L2TP、MPLS)、唯一の総合的な要件がトンネルを通してパケットを送るのが、アドレスがグローバルにユニークである新しいIPヘッダーと共にそれを要約するのを必要とするということであり。
For customer provisioned CE-based VPNs, provisioning and management of the tunnels is the responsibility of the customer network administration. Typically, this makes use of manual configuration of
顧客の食糧を供給されたCEベースのVPNsにおいて、トンネルの食糧を供給するのと管理は顧客ネットワーク管理の責任です。 通常、これは手動の構成の使用になります。
Callon & Suzuki Informational [Page 8] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[8ページ]鈴木の情報のRFC4110
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装置の間のルーティング・プロトコルの操作に責任があります。 (ドキュメントの範囲の外に顧客の食糧を供給されたCEベースのVPNsの議論があることに注意します。)
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ベースのVPNsのために、トンネルの食糧を供給するのと管理は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ベースのVPNs(顧客かプロバイダーによって食糧を供給されることにかかわらず)に関しては、顧客ネットワークにおけるルーティングは層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(または、Provider EdgeベースのVirtual兵士のNetwork)では、顧客パケットはトンネルでSPネットワークを通して運ばれます、ちょうどそれらがCEベースのVPNsにあるとき。 しかしながら、PEベースのVPNでは、トンネル終点はPE装置です、そして、PE装置は顧客パケットを発送する方法を知らなければなりません、それらが運ぶIPアドレスに基づいて。 この場合、CE装置自体は、少しの特別なVPN能力も持つ必要はなくて、それらがVPNの一部であることを知る必要さえありません。
In this document we will use the generic term "VPN Edge Device" to refer to the device, attached to both the customer network and the VPN backbone, that performs the VPN-specific functions. In the case of CE-based VPNs, the VPN Edge Device is a CE device. In the case of PE-based VPNs, the VPN Edge Device is a PE device.
本書では私たちは、VPN-具体的な機能を実行する顧客ネットワークとVPN背骨の両方に取り付けられた装置について言及するのに総称「VPNエッジデバイス」を使用するつもりです。 CEベースのVPNsの場合では、VPN Edge DeviceはCE装置です。 PEベースのVPNsの場合では、VPN Edge DeviceはPE装置です。
1.3.2. Types of PE-based VPNs
1.3.2. PEベースのVPNsのタイプ
Different types of PE-based VPNs may be distinguished by the service offered.
PEベースのVPNsの異なったタイプは提供されたサービスで区別されるかもしれません。
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からフレームを受けるとき、それはフレームヘッダー(FR、ATM、またはMACヘッダーなどの)で両方がパケットの入って来るリンクであり、層が2情報であると考えることによってパケットを進める方法を決定します。 (ドキュメントの範囲の外に層2のサービスの議論があることに注意します。)
Callon & Suzuki Informational [Page 9] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[9ページ]鈴木の情報のRFC4110
1.3.3. Layer 3 PE-based VPNs
1.3.3. 層3のPEベースのVPNs
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層の中では、プロバイダーは、管理のいくつかの局面とVPNsの食糧を供給することに参加する必要があるでしょう、PEデバイスが正しいVPNsをサポートするために構成されるのを確実にするのなどように。 これは、層の3のPEベースのVPNsが定義上プロバイダーで食糧を供給された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ベースのVPNsには、利点があります。彼らは顧客ネットワークからVPN管理のいくつかの局面を積み下ろします。 顧客ネットワークの見解から、まるでまさしく正常なネットワークがあるかのように見えます。 顧客ネットワーク特定のVPNの機能性を隠されます。 また、顧客ネットワークのルーティングのスケーリングは改良されるかもしれません、3のPEベースのVPNがアプローチする何らかの層が顧客のルーティング・アルゴリズムが「Nは二乗したこと」が(実際にN*(N-1)/2)N顧客サイトの間の複式のリンクを指すために指すのを見る必要性を避けるので。
However, these advantages come along with other consequences. Specifically, the PE devices must have some knowledge of the routing, addressing, and layer 3 protocols of the customer networks to which they attach. One consequence is that the set of layer 3 protocols which can be supported by the VPN is limited to those supported by the PE (which in practice means, limited to IP). Another consequence is that the PE devices have more to do, and the SP has more per-customer management to do.
しかしながら、これらの利点は他の結果と共に来ます。 明確に、PEデバイスには、それらが付く顧客の3つのプロトコルがネットワークでつなぐルーティング、アドレシング、および層に関する何らかの知識がなければなりません。 ある結果はVPNがサポートできる層3のプロトコルのセットがPE(中でIPに制限された手段を練習する)によってサポートされたものに制限されるということです。 別の結果は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)などのように。
1.4. Scope of the Document
1.4. ドキュメントの範囲
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
このフレームワークドキュメントは、提供している層3のPEベースのVPNsのためにメソッドについて議論して、3プロバイダーで食糧を供給されたCEベースのVPNsを層にするでしょう。 これは抑制するのに意志を使用できるメカニズムを含むかもしれません。
Callon & Suzuki Informational [Page 10] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[10ページ]鈴木の情報のRFC4110
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.
ファイアウォールの使用とプレースメントを含むサイトの間の接続性は[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 Providerによって食糧を供給されたVPNワーキンググループの範囲の外にあるVPNsのそれらのフォームについて議論しません。 明確に、このドキュメントはベース技術が以前はよくVPNサービスを提供していたとき(ATMが合図している状態で、例えばATMを使用することで提供されたネイティブのATMサービスは切り替わります)PPVPNsがVPNの固有(非IPの、そして、非MPLSの)のプロトコルを使用する議論を除きます。 しかしながら、これは、顧客でPPVPNへの「マルチ-プロトコル」アクセスを除くことを意味しません。
1.5. Terminology
1.5. 用語
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に属す1セットのサイトを制御する単純組織、会社、または企業。
Customer Edge (CE) Device: The equipment on the customer side of the SP-customer boundary (the customer interface).
顧客縁(Ce)のデバイス: SP-顧客境界(顧客インタフェース)の顧客側の上の設備。
IP Router: A device which forwards IP packets, and runs associated IP routing protocols (such as OSPF, IS-IS, RIP, BGP, or similar protocols). An IP router might optionally also be an LSR. The term "IP router" is often abbreviated as "router".
IPルータ: IPパケットを進めて、関連IPルーティング・プロトコルを実行するデバイス、(OSPFなどのように-、RIP、BGP、または同様のプロトコル) また、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ルーティングとシグナリングプロトコルを関連づけた、(自由民主党、RSVP-TE、CR-自由民主党、OSPFなどのように-、同様のプロトコル、) また、ラベル切り換えルータは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
PEベースのVPNs: PEデバイスは、あるトラフィックがVPNトラフィックであることを知っています。 彼らはパケットの送付先IPアドレスに基づいていて、パケットのIPヘッダーの他の情報に基づいて任意にオンなトラフィック(トンネルを通る)を進めます。 PEデバイスはそうです。
Callon & Suzuki Informational [Page 11] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[11ページ]鈴木の情報のRFC4110
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).
自分たち、トンネル終点。 トンネルは、SPネットワークの上にトラフィックを送るのに様々なカプセル化を利用するかもしれません(そのようなものにもかかわらず、部外秘でないことで、GRE、IPにおける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側の上の設備。
Provider-Provisioned VPNs (PPVPNs): VPNs, whether CE-based or PE-based, that are actively managed by the SP rather than by the end customer.
プロバイダーで食糧を供給されたVPNs(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.
反射鏡を発送してください: SPによって所有されているネットワーク要素に、それは、SPのBGPによって可能にされたルータにBGPルートを分配するのに使用されます。
Virtual Private Network (VPN): Restricted communication between a set of sites, making use of an IP backbone which is shared by traffic that is not going to or coming from those sites.
仮想私設網(VPN): それらのサイトからの1セットのサイト、そうしないトラフィックによって共有されるIPバックボーンを利用するか、または来るところのコミュニケーションを制限しました。
Virtual Router (VR): An instance of one of a number of logical routers located within a single physical router. Each logical router emulates a physical router using existing mechanisms and tools for configuration, operation, accounting, and maintenance.
仮想のルータ(VR): 多くの論理的なルータの1つのインスタンスはただ一つの物理的なルータの中で場所を見つけられました。 それぞれの論理的なルータは、構成、操作、会計、およびメインテナンスに既存のメカニズムと道具を使用することで物理的なルータを見習います。
VPN Forwarding Instance (VFI): A logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN.
VPN推進インスタンス(VFI): VPNのためのルータ情報ベースと推進情報ベースを含んでいるPEにある論理的な実体。
VPN Backbone: IP and/or MPLS network which is used to carry VPN traffic between the customer sites of a particular VPN.
VPNバックボーン: 特定のVPNの顧客サイトの間までVPNトラフィックを運ぶのに使用されるIP、そして/または、MPLSネットワーク。
VPN Edge Device: Device, attached to both the VPN backbone and the customer network, which performs VPN-specific functions. For PE-based VPNs, this is the PE device; for CE-based VPNs, this is the CE device.
VPNエッジデバイス: VPN-具体的な機能を実行するVPNバックボーンと顧客ネットワークの両方に取り付けられたデバイス。 PEベースのVPNsに関しては、これはPEデバイスです。 CEベースのVPNsに関しては、これは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つの実体の間に伝えられるパケットをカプセルに入れることによって実装された2PEか2つのCE実体の間の論理的なリンク。
Callon & Suzuki Informational [Page 12] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[12ページ]鈴木の情報のRFC4110
1.6. Acronyms
1.6. 頭文字語
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
外部の気圧のインタフェースのCR-自由民主党の規制ベースのルート設定ラベル非同期通信モードBGPボーダ・ゲイトウェイ・プロトコルCe顧客縁のCLIコマンドライン分配のボーダ・ゲイトウェイ・プロトコルFRフレームリレーGRE一般ルーティングのカプセル化プロトコルEBGP IBGP; 内部のボーダ・ゲイトウェイ・プロトコルIKEインターネット・キー・エクスチェンジIGP Interiorゲートウェイプロトコル、(例えば、RIP、-、OSPFによるすべてのIGPs) IPインターネットプロトコル(IPv4と同じ)IPsecインターネット・プロトコル・セキュリティーがIPv4インターネットプロトコルバージョン4(IPと同じ)IPv6について議定書の中で述べるということです; インターネットプロトコルバージョン6、-、Intermediate SystemルーティングへのIntermediate SystemはL2TP Layer2TunnelingプロトコルLANローカル・エリア・ネットワークLDAPライトウェイト・ディレクトリ・アクセス・プロトコル自由民主党のLabel DistributionプロトコルLSP Label Switched Path LSR Label Switching Router MIB Management情報基地のMPLS MultiプロトコルLabel Switching NBMA Non-放送Multi-アクセスNMS Network Management System OSPFオープンShortest Path Firstルーティング・プロトコルP Provider設備PE Provider Edge PPVPN Provider-プロについて議定書の中で述べます。Traffic Engineering Extensions SNMP Simple Network ManagementプロトコルSP Service Provider VFI VPN Forwarding Instance VPN Virtual兵士のNetwork VR Virtual RouterとのService RFC Request For Comments RIPルーティング情報プロトコルRSVP Resource予約プロトコルRSVP-TE Resource予約プロトコルの想像されたVPN QoS Quality
Callon & Suzuki Informational [Page 13] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[13ページ]鈴木の情報のRFC4110
2. Reference Models
2. 規範モデル
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を造って、配布するのに必要である共通成分と断片をはっきりさせることです。 3のプロバイダーで食糧を供給されたCEベースのVPNがカバーされている2つのタイプのVPNs、層3のPEベースのVPN、および層は下のセクションを切り離しました。
2.1. Reference Model for Layer 3 PE-based VPN
2.1. 層3のPEベースの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は、PEベースのVPNsと図2.2と2.3が規範モデルの実体の間の関係を示すのを層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デバイスの間に存在するインタフェースと定義されます、そして、ネットワーク・インターフェースは1組の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をサポートする各組のVFIsの間の単一の論理的なトンネルを例証します。 別の選択肢は可能です。 例えば、単一のトンネルは2PEsの間に現れるかもしれません、複数の1VFIあたりのトンネルをPEトンネルへのPEの上に多重送信していて。 同様に、例えばVFIの中で推進を最適化するために、2VFIsの間には、複数のトンネルがあるかもしれません。 後でこのフレームワークドキュメントで他の可能性について議論するでしょう。
Callon & Suzuki Informational [Page 14] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[14ページ]鈴木の情報のRFC4110
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | 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 |
+---------+ +------------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | Ce| | Ce| : | | | P| | PE| : |デバイス| |デバイス| : +------+ VPNはトンネルを堀ります: |ルータ| |デバイス| : | of| | of|-:--| |================:===============| |--:-|VPN A| |VPN A| : | | : +------+ +------+ : +------+ +------+ : | PE| : | | : | +------+ : |デバイス| ネットワーク・インターフェース| | : | | Ce| : | | : +------+ : +------+ |デバイス|-:--| |================:===============| |--:-| Ce| | of| : +------+ : VPNトンネル| PE| : |デバイス| |VPN B| : | | |デバイス| : | of| +------+ : | | +------------+ +------------+ | | : |VPN B| | : | | | 顧客| | ネットワーク| +------+ : +------+ |顧客| | | 管理| | 管理| | | : | |インタフェース| | | 機能| | 機能| | |顧客| | | | +------------+ +------------+ | |インタフェース| | | | | | | +---------+ +------------------------------------+ +---------+ | アクセス| | <、-、-、-、-、-、-、-、-、-- SPネットワーク--------->|、| アクセス| | ネットワーク| | 単一であるか複数のSPドメイン| | ネットワーク|
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|
+-----+ +----------+ +----------+ +-----+
+----------+ +----------+ +-----+ |PEデバイス| |PEデバイス| +-----+ | Ce| | | | | | Ce| | dev| アクセス| +------+ | | +------+ | アクセス| dev| | of| コン。 | |VFI| | VPNトンネル| |VFI| | コン。 | of| |VPN A|----------|VPN A|======================|VPN A|----------|VPN A| +-----+ | +------+ | | +------+ | +-----+ | | | | +-----+ アクセス| +------+ | | +------+ | アクセス+-----+ | Ce| コン。 | |VFI| | VPNトンネル| |VFI| | コン。 | 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)の実体の間の関係。
Callon & Suzuki Informational [Page 15] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[15ページ]鈴木の情報のRFC4110
+----------+ +----------+
+-----+ |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|
+-----+ +----------+ +----------+ +-----+
+----------+ +----------+ +-----+ |PEデバイス| |PEデバイス| +-----+ | Ce| | | | | | Ce| | dev| アクセス| +------+ | | +------+ | アクセス| dev| | of| コン。 | |VFI| | | |VFI| | コン。 | of| |VPN A|----------|VPN A| | | |VPN A|----------|VPN A| +-----+ | +------+\| トンネル|/+------+ | +-----+ | >=========<| +-----+ アクセス| +------+/| |\+------+ | アクセス+-----+ | Ce| コン。 | |VFI| | | |VFI| | コン。 | 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)の実体の間の関係。
2.1.1. Entities in the Reference Model
2.1.1. 規範モデルの実体
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デバイスとインタコネクトするのに使用されますが、少しのVPN状態も持っていなくて、また少しのダイレクト付属もCEデバイスに持っていないプロバイダーネットワークの中のルータ。
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デバイスは、1VPNsのサポートのために1VFIsを実装して、1VPNあたりの状態を維持します。 それは、VFIsと食糧を供給するのや、管理や、トラフィック分類や分離などのプロバイダー縁のVPNの機能性を含んでいるルータ、LSR、または対向機器であるかもしれません。 (アクセス接続が機能的な観点からのVFIsによって終えられることに注意します。) PEデバイスは1台以上のCEデバイスとのアクセス接続で取り付けられます。
Callon & Suzuki Informational [Page 16] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[16ページ]鈴木の情報のRFC4110
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の可到達性を持っている1セットのユーザです。
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.
階層的で別のレベルで1つのレベルにおける複数のVPNトンネルを単一のトンネルに多重送信するかもしれません。 例えば、倍数、-、PEトンネルへの独身のPEにVPNトンネルを多重送信するかもしれません(例えば、GRE、IPにおける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はVPNのためのルータ情報ベースと推進情報ベースを含むPEにある論理的な実体です。 セクション4.4.2でルーティングとVFIsとの相互作用について議論します。
Callon & Suzuki Informational [Page 17] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[17ページ]鈴木の情報のRFC4110
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])、または独占ネットワーク管理システムを使用するかもしれません。
2.1.2. Relationship Between CE and PE
2.1.2. CeとPEとの関係
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デバイスは1台以上のPEデバイスに接続されるかもしれません。 図2.4に示された4つの異なったタイプのマルチホーミングアレンジメントはサポートされるかもしれません。
Callon & Suzuki Informational [Page 18] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[18ページ]鈴木の情報のRFC4110
+---------------- +---------------
| |
+------+ +------+
+---------| 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)
+---------------- +--------------- | | +------+ +------+ +---------| PE| +---------| PE| | |デバイス| | |デバイス| SPネットワーク| +------+ | +------+ +------+ | +------+ | | Ce| | | Ce| +--------------- |デバイス| | SPネットワーク|デバイス| +--------------- +------+ | +------+ | | +------+ | +------+ | | PE| | | PE| +---------|デバイス| +---------|デバイス| SPネットワーク+------+ +------+ | | +---------------- +--------------- このタイプは2つのアクセス接続でPEデバイスに接続されたCEデバイスを入れます。 (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
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
+---------------- +--------------- | | +------+ +------+ +------+ +------+ | Ce|-----| PE| | Ce|-----| PE| |デバイス| |デバイス| |デバイス| |デバイス| SPネットワーク+------+ +------+ +------+ +------+ | | | | | 裏口| | 裏口+--------------- | リンク| SPネットワーク| リンク+--------------- | | | | +------+ +------+ +------+ +------+ | Ce| | PE| | Ce| | PE| |デバイス|-----|デバイス| |デバイス|-----|デバイス| SPネットワーク+------+ +------+ +------+ +------+ | | +---------------- +---------------
(c) (d)
(c)(d)
Figure 2.4: Four types of double-homing arrangements.
図2.4: 4つのタイプの二重自動誘導アレンジメント。
2.1.3. Interworking Model
2.1.3. モデルを織り込みます。
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
その複数の異なった層がアプローチが実装されるかもしれない3VPNであると仮定するのはかなり当然です、特にVPNバックボーンが1つ以上のSPネットワークを含んでいるなら。 例えば、(1) 各SPが1つを選ぶか、または以上は複数のベンダーの実装から3つのPEベースのVPNアプローチを層にします、異なったSPsが選ぶかもしれないのを含意して相違
Callon & Suzuki Informational [Page 19] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[19ページ]鈴木の情報のRFC4110
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.
アプローチ。 (2) そして、SPは、層の3のPEベースのVPNsの複数のネットワークが(例えば、古いネットワークと新しいネットワーク)であると配布するかもしれません。 したがって、倍数の使用を異なった層3のVPNアプローチにするPEベースのVPNsは層3を織り込むのを許容するのが重要です。
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アプローチに基づくVPNsの間に論理的に位置している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->|
+------------------+ +------------------+ | | | | +------+ VPNトンネル+------+ VPNトンネル+------+ | |==============| |==============| | | | | | | | | PE| | PE| | PE| | | |デバイス| | | |デバイス| |(IWF) | |デバイス| | | VPNトンネル| | VPNトンネル| | | |==============| |==============| | +------+ +------+ +------+ | | | | +------------------+ +------------------+ | <、-VPNアプローチ1>| | <、-VPNアプローチ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に示されるように、インタフェースを織り込むのは、1組のPEsの間に存在するインタフェースと定義されて、異なるアプローチで実装された2つのSPネットワークを接続します。 このインタフェースはPEとCEの間に位置する顧客インタフェースと同様ですが、インタフェースはトンネルによってサポートされて、VPNsを特定します、顧客インタフェースはアクセス接続によってサポートされますが。
Callon & Suzuki Informational [Page 20] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[20ページ]鈴木の情報のRFC4110
+------------------+ +------------------+
| | : | |
+------+ 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->|
+------------------+ +------------------+ | | : | | +------+ VPNトンネル+------+ トンネル: +------+ VPNトンネル+------+ | |============| |======:======| |============| | | | | | : | | | | | PE| | PE| : | PE| | PE| | | | | : | | | | |デバイス| |デバイス| : |デバイス| |デバイス| | | VPNトンネル| |以下にトンネルを堀ってください。 | | VPNトンネル| | | |============| |======:======| |============| | +------+ +------+ : +------+ +------+ | | : | | +------------------+ +を織り込むこと。------------------+ | <、-VPNアプローチ1>| インタフェース| <、-VPNアプローチ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.
何らかの顧客サイトで1種類のVPNにCEを取り付けて、CEがもう1種類に付いたなら、VPNの2種類のコミュニケーションは自動的に現れます。
2.2. Reference Model for Layer 3 Provider-Provisioned CE-based VPN
2.2. 層3のプロバイダーで食糧を供給されたCeベースの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の織り込む問題は起こりません。
Callon & Suzuki Informational [Page 21] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[21ページ]鈴木の情報のRFC4110
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | 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 |
+---------+ +------------------------------------+ +---------+ | | | | | | | | | +------+ +------+ : +------+ +------+ : | | | | | | : | Ce| | Ce| : | | | P| | PE| : |デバイス| |デバイス| : +------+ VPNトンネル|ルータ| |デバイス| : | of| | of|=:====================================================:=|VPN A| |VPN A| : | | +------+ +------+ : +------+ +------+ : | PE| | | : | +------+ : |デバイス| | | : | | Ce| : | | VPNトンネル+------+ : +------+ |デバイス|=:====================================================:=| Ce| | of| : +------+ | PE| : |デバイス| |VPN B| : | | |デバイス| : | of| +------+ : | | +------------+ +------------+ | | : |VPN B| | : | | | 顧客| | ネットワーク| +------+ : +------+ |顧客| | | 管理| | 管理| | | : | |インタフェース| | | 機能| | 機能| | |顧客| | | | +------------+ +------------+ | |インタフェース| | | | | | | +---------+ +------------------------------------+ +---------+ | アクセス| | <、-、-、-、-、-、-、-、-、-- SPネットワーク--------->|、| アクセス| | ネットワーク| | | | ネットワーク|
Figure 2.7: Reference model for layer 3
provider-provisioned CE-based VPN.
図2.7: 層3のための規範モデルはCEベースのVPNにプロバイダーで食糧を供給しました。
2.2.1. Entities in the Reference Model
2.2.1. 規範モデルの実体
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デバイスとのアクセス接続で付けられています。
Callon & Suzuki Informational [Page 22] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[22ページ]鈴木の情報のRFC4110
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ネットワークはCEデバイスでそれ自身のネットワークと顧客のVPN機能の両方を管理するSPのネットワークと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トンネルは2つの実体の間のVPNsのサポートのためにそれらの2つの実体の間でトランスミッションの目的のために要約のヘッダーの中にパケットをカプセルに入れることによって作成される論理的なリンクです。 層の3のプロバイダーで食糧を供給されたCEベースのVPNsの文脈では、VPNトンネルは、IPトンネル(例えば、GREを使用するか、IPにおける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の食糧を供給するのとモニターがデバイス属性とそれらの関係であるとサポートします、顧客VPNsの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])、または独占ネットワーク管理システムを使用するかもしれません。
3. Customer Interface
3. 顧客インタフェース
3.1. VPN Establishment at the Customer Interface
3.1. 顧客インタフェースのVPN設立
3.1.1. Layer 3 PE-based VPN
3.1.1. 層3のPEベースのVPN
It is necessary for each PE device to know which CEs it is attached to, and what VPNs each CE is associated with.
それぞれのPEデバイスがそれがどのCEsに付けられているか、そして、それぞれのCEがどんなVPNsに関連しているかを知るのが必要です。
VPN membership refers to the association of VPNs, CEs, and PEs. A given CE belongs to one or more VPNs. Each PE is therefore
VPN会員資格はVPNs、CEs、およびPEsの協会について言及します。 与えられたCEは1VPNsに属します。 したがって、各PEはそうです。
Callon & Suzuki Informational [Page 23] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[23ページ]鈴木の情報のRFC4110
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.
関連づけられて、VPNs、および与えられたVPNの1セットで、VPNはそれをサポートしている関連PEsをセットしています。 PEが少なくとも1付属CEに与えられたVPNに属させるなら、そのVPN(例えば、VPNルート)のための州の情報はそのPEに存在しなければなりません。 顧客サイトがVPNsから加えられるか取り除かれるのに応じて、PEに存在する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会員資格情報(すなわち、PEsがどのVPNsに取り付けられる情報)は明らかに分配されます。 他のものでは、会員資格情報は他の分配された情報から推論されます。 異なった体系は何のセットのトンネルを設立するかを決定するのに異なった道、例えば、いくつかで会員資格情報を使用します、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会員資格情報は、以下で議論するように静的であるか、またはダイナミックであるかもしれません。
3.1.1.1. Static Binding
3.1.1.1. 静的な結合
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アクセスリンクを縛るとき、静的な結合は起こります。 例えば、ネットワーク管理者はひたむきなリンクレイヤ接続をセットアップするかもしれません、ATM VCCやFR DLCIのように、PEデバイスとCEデバイスの間で。 この場合同じように時間、および残りに食糧を供給するのに修理されることへのPE-CEアクセス接続と特定のVPNの間の別の食糧を供給する動作が結合を変えるまでの結合。
3.1.1.2. Dynamic Binding
3.1.1.2. ダイナミックな結合
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
ダイナミックに接続されたユーザをサポートするのに、PPPとRADIUSは一般的に使用されます、これらのプロトコルがユーザ登録名、認証、およびVPN選択に備えるとき。 また、他のメカニズムはそうです。
Callon & Suzuki Informational [Page 24] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[24ページ]鈴木の情報のRFC4110
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".
可能。 例えばユーザのHTTPトラフィックを、初めは、PEによって妨害されて、プロバイダーの接待されたウェブサーバーに紛らすかもしれません。次に、ユーザー認証と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会員資格はいつでも、動作に食糧を供給するネットワークの結果、というよりむしろユーザの開始している動作の結果、変化するかもしれません。 これは、これらのユーザによって開始された動作が行われるとき、会員資格情報を急速に、そして確かに分配する方法があるのが必要であることを示します。
3.1.2. Layer 3 Provider-Provisioned CE-based VPN
3.1.2. 層3のプロバイダーで食糧を供給されたCeベースの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デバイスはVPNsに関する知識を全く持っていません。 特定のVPNに取り付けられたPEデバイスはその特定のVPNのアドレシングかルーティング情報に関する知識を全く持っていません。
CE devices have IP or MPLS connectivity via a connection to a PE device, which just provides ordinary connectivity to the global IP address space or to an address space which is unique in a particular SPs network. The IP connectivity may be via a static binding, or via some kind of dynamic binding.
CEデバイスには、IPかMPLSの接続性がPEデバイスとの接続であります。(ただ、デバイスはグローバル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.
それぞれのCEデバイスにVPNsの設立をします、IPかMPLSの接続性を他のものに利用して。 したがって、与えられたCEデバイスが、どの他のCEデバイスが同じVPNに属すかを知るのが必要です。 このような関係においては、VPN会員資格はVPNsとCEデバイスの協会について言及します。
3.2. Data Exchange at the Customer Interface
3.2. 顧客インタフェースのデータ交換
3.2.1. Layer 3 PE-based VPN
3.2.1. 層3のPEベースのVPN
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パケットです。 例えば、ルータに利用可能なイーサネット、Sonet、T1、T3、ダイヤルアップ系列、およびいかなる他のリンクレイヤの上ともIPパケットを交換するかもしれません。 それらのリンクレイヤがIPパケットを運ぶ目的のために厳密にインタフェースに地方であり、顧客インタフェースの各端のときに終えられることに注意するのは重要です。 IPパケットはVPNの中でユニークな、しかし、VPNバックボーンでユニークでないアドレスを含むかもしれません。 任意に、データ交換は、IPパケットを運ぶのにMPLSを使用するかもしれません。
Callon & Suzuki Informational [Page 25] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[25ページ]鈴木の情報のRFC4110
3.2.2. Layer 3 Provider-Provisioned CE-based VPN
3.2.2. 層3のプロバイダーで食糧を供給されたCeベースのVPN
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バックボーンで発送可能で、アドレスがVPNバックボーンでユニークであるいつも正常なIPパケットです。 任意に、適切なラベルで切り換えられた経路がVPNバックボーンの向こう側に存在しているなら、MPLSフレームを使用できます。 PEデバイスは、これらのパケットがVPNパケットであるかどうかを知りません。 現在の時間に、MPLSは目に見える顧客サービスとして一般的に提供されません、CEベースのVPNsが最も一般的にIPサービスを利用するように。
3.3. Customer Visible Routing
3.3. 顧客の目に見えるルート設定
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エッジデバイスでこの経路選択機能を実行しなければなりません。
3.3.1. Customer View of Routing for Layer 3 PE-based VPNs
3.3.1. 層3のPEベースのVPNsのためのルート設定の顧客視点
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-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を利用できる、(リップ、OSPFなどのように-、など)、または、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.
IGPを通してPE-CE相互作用をすると、一般に、PEは少なくともいくつかの独立しているIGPインスタンスを維持するでしょう。 バックボーンルーティングのための1つ、および各VPNあたり1つ。 したがって、PEは顧客VPNsの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.
BGPを通してPE-CE相互作用をするなら、PE MAYは各VPNのためにBGPの1つのインスタンスをサポートします、公共のインターネットルートへのBGPの追加インスタンスと同様に。 あるいはまた、PEは、VPNルートと公共のインターネットルートを区別するためにBGP、使用、例えば、異なったBGP Address Familiesのただ一つのインスタンスをサポートするかもしれません。
Routing information which a PE learns from a CE in a particular VPN must be forwarded to the other PEs that are attached to the same VPN. Those other PEs must then forward the information in turn to the other CEs of that VPN.
PEが特定のVPNのCEから学ぶルート設定情報を同じVPNに取り付けられる他のPEsに転送しなければなりません。 そして、それらの他のPEsは順番にそのVPNの他のCEsに情報を転送しなければなりません。
Callon & Suzuki Informational [Page 26] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[26ページ]鈴木の情報のRFC4110
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-CEが連結する同じルーティングインスタンスの一部が属して、PE-PEルーティング分配ができます。 あるいはまた、ことによると異なったルーティング・アルゴリズムを使用して、異なったルーティングインスタンスでそれができます。 この場合、PEは1つのルーティングインスタンスから別のインスタンスまでVPNルートを再配付しなければなりません。
Note that VPN routing information is never distributed to the P routers. VPN routing information is known at the edge of the VPN backbone, but not in the core.
VPNルーティング情報がPルータに決して分配されないことに注意してください。 VPNルーティング情報は、VPNバックボーンの縁で知られていますが、コアで知られているというわけではありません。
If the VPN's IGP is different than the routing algorithm running on the CE-PE link, then the CE must support two routing instances, and must redistribute the VPN's routes from one instance to the other (e.g., [VPN-BGP-OSPF]).
VPNのIGPがCE-PEリンクで走るルーティング・アルゴリズムと異なるなら、CEは2つのルーティングインスタンスをサポートしなければならなくて、1つのインスタンスからもう片方(例えば、[VPN-BGP-OSPF])までVPNのルートを再配付しなければなりません。
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デバイスは数個の異なったVPNsにサービスを供給しそうです。 異なったVPNsには互いにユニークでないアドレス空間があるかもしれないので、一般に、PEデバイスに数個の推進テーブルがなければなりません。それが付けている各VPNあたり1つ。 これらはVPN Forwarding Instances(VFIs)と呼ばれるでしょう。 各VFIはPEデバイスへの内部の論理的な実体です。 VFIsについてセクション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の操作と同様に)のスケーリングと経営はルーティングが行われる実装アプローチと方法によるでしょう。
3.3.1.1. Routing for Intranets
3.3.1.1. イントラネットのためのルート設定
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を使用する、-、裂いてください、)
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デバイスがサイトにあると考えられるかどうか指定しません。 以下でこの問題について議論します。
Callon & Suzuki Informational [Page 27] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[27ページ]鈴木の情報のRFC4110
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領域のようにシングル、-、領域、ルータの間のRIPのただ一つのインスタンス) 使用されるかもしれません。 1はそうしたかもしれません、顧客ネットワーク(各PEの中にVFIを含んでいて、より正確にPEsを含んでいる)の中のルータがただ一つの領域の中で見えるすべて。 また、標準がリンクされるとき、PEsの間のTunnelsは現れることができました。
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のマルチレベル階層構造、-、使用されるかもしれません。 または、これをVPNsに適用する1つの方法が各サイトが独身のOSPFであることを持つだろうことである、-、領域。 VFIsはその領域の一部として各サイトの中でルーティングに参加するでしょう。 または、次に、VFIsがバックボーンとしてインタコネクトされるかもしれない、(OSPF領域0、-、レベル2)。 したがって、OSPFが使用されているなら、VFIsは境界ルータとして顧客ネットワークにおいて現れます。 -、使用されていて、VFIsはしたがって、局部の中で掘られるレベル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に与える、-、測定基準はすべてのリンクに割り当てられて、代替のリンクを通した経路を比較できて、VPNトンネル、アクセス接続、または裏口のリンクを通してそれがあることにかかわらず最も短い費用経路は使用されるでしょう。 バックボーンがサイトと同じ一般的なIGPを使用しないならVPNの複数のサイトが一般的なIGPを使用しないなら、当時の特別な手順が他のサイトからの/へのルートがイントラ領域ルートとして扱われるのを保証するのに必要であるかもしれません、むしろ外部経路(取られたVPNアプローチによって)より。
Another option is to operate each site as a separate routing domain. For example each site could operate as a single OSPF area, a single IS-IS area, or a RIP domain. In this case the per-site routing domains will need to redistribute routes into a backbone routing domain (Note: in this context the "backbone routing domain" refers to a backbone as viewed by the customer network). In this case it is optional whether or not the VFIs participate in the routing within each site.
別のオプションは別々の経路ドメインとして各サイトを操作することです。 例えば各サイトがただ一つのOSPF領域として作動できた、シングル、-、領域、または、RIPドメイン。 この場合、1サイトあたりの経路ドメインは、バックボーン経路ドメインにルートを再配付する必要があるでしょう(注意: このような関係においては「バックボーン経路ドメイン」は顧客ネットワークによって見られるバックボーンを示します)。 この場合、VFIsが各サイトの中でルーティングに参加するか否かに関係なく、それは任意です。
3.3.1.2. Routing for Extranets
3.3.1.2. エクストラネットのためのルート設定
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
エクストラネット場合では、インタコネクトされるべきサイトは複数の異なった政権に属します。 この場合IGPs、(OSPFなどのように-、RIP) 通常、組織の間のインタフェースの向こう側に使用されません。 スタティックルートかBGPのどちらかがサイトの間で使用されるかもしれません。 次に、顧客ネットワーク管理がサイトと他のネットワークの間のルーティングのコントロールを維持したいなら
Callon & Suzuki Informational [Page 28] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[28ページ]鈴木の情報のRFC4110
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.
スタティックルーティングか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アドレス(例えば、登録されていないアドレス)がエクストラネットコミュニケーションに使用されるべきでないことに注意してください。
3.3.1.3. CE and PE Devices for Layer 3 PE-based VPNs
3.3.1.3. 層3のPEベースのVPNsのためのCeとPEデバイス
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ベースのVPNsのために、CEとPEデバイスの両方が正常なルータとして領域の中で関与します。
The other options make a distinction between routing within a site, and routing between sites. In this case, a CE device would normally be considered as part of the site where it is located. However, there is an option regarding how the PE devices should be considered.
別の選択肢はサイトの中のルーティングと、サイトの間のルーティングの間で区別をします。 この場合、通常、CEデバイスはそれが位置しているサイトの一部であるとみなされるでしょう。 しかしながら、PEデバイスがどう考えられるべきであるかに関するオプションがあります。
In some cases, from the perspective of routing within the customer network, a PE device (or more precisely a VFI within a PE device) may be considered to be internal to the same area or routing domain as the site to which it is attached. This simplifies the management responsibilities of the customer network administration, since inter-area routing would be handled by the provider.
いくつかの場合、顧客ネットワークの中のルーティングの見解から、PEデバイス(または、より正確にPEデバイスの中のVFI)がそれが付けているサイトとして同じ領域か経路ドメインに内部であると考えられるかもしれません。 相互領域ルーティングはプロバイダーによって扱われるでしょう、したがって、これが顧客ネットワーク管理の経営者の責任を簡素化します。
For example, from the perspective of routing within the customer network, the CE devices may be the area border or AS boundary routers of the IGP area. In this case, static routing, BGP, or whatever routing is used in the backbone, may be used across the customer interface.
例えば、顧客ネットワークの中のルーティングの見解から、CEデバイスは、IGP領域の領域の境界かAS境界ルータであるかもしれません。 この場合、スタティックルーティング(BGP、またはバックボーンに使用されるどんなルーティング)は、顧客インタフェースの向こう側に使用されるかもしれません。
3.3.2. Customer View of Routing for Layer 3 Provider-Provisioned
CE-based VPNs
3.3.2. 層3のプロバイダーで食糧を供給されたCeベースのVPNsのためのルート設定の顧客視点
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ベースのVPNsにおいて、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
同じVPNに属す顧客サイトは現れるCE-CE VPNトンネルを通ってルーティング情報を交換するかもしれません、顧客IGPに、ルータ隣接番組として。 の代わりにする代わりに。
Callon & Suzuki Informational [Page 29] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[29ページ]鈴木の情報のRFC4110
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トンネルを通ってルーティング情報を交換して、SPのマネージメントシステムは1つのサイトのスタティックルート情報の構成の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のネットワークでSPネットワークにおける、トンネルを堀られた顧客パケットの推進がグローバルなIP推進に基づくので様々なCEデバイスへのルートを知っていなければなりません。
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ネットワーク(グローバルなルーティング)では、PEと共にそういうものとしてじっと見て、掘ります。
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インタフェースの静電気/デフォルトルートの使用はすべて、必要であるグローバルなルーティングであるかもしれません。
3.3.3. Options for Customer Visible Routing
3.3.3. 顧客の目に見えるルート設定のためのオプション
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 (ルーティング情報プロトコル)を裂いてください。[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が小さいか中型のネットワークに適しているのを含意します。
Callon & Suzuki Informational [Page 30] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[30ページ]鈴木の情報のRFC4110
o OSPF (Open Shortest Path First) [RFC2328]
o OSPF(最短パス開いている1番目)[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.
各ルータは同じ位相的なデータベースを維持します。(それは根としてそれ自体でそれから最短パスの木を組み立てます)。 アルゴリズムはShortest Path Firstか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 -、(中間システムへの中間システム)[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.
-、OSI(オープン・システム・インターコネクション)プロトコル群に設計されたルーティング・プロトコルはそうです。 統合、-、派生する、-、IPを支持するには、議定書を作ってください。 インターネットコミュニティで-、手段が統合された、- これでは、コネクションレスなネットワーク・サービスの上にリンク状態の広告を出します。 -、OSPFと同じ基本的特徴を持っています。 それらは: 領域、最短パスの木の計算、最短パスの木からの経路指定テーブルの世代、領域ルーティング計画、代表ルータ、および可変長サブネットマスクの中で位相的なデータベースの州の広告と維持をリンクしてください。
Callon & Suzuki Informational [Page 31] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[31ページ]鈴木の情報のRFC4110
o BGP-4 (Border Gateway Protocol version 4) [RFC1771]
o BGP-4(ボーダ・ゲイトウェイ・プロトコルバージョン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スピーカーに接するか、または単一の自律システムの中で2人のBGPスピーカーに接する内部のBGP(IBGP)に接するExternal BGPであるかもしれません(EBGP)。 ルート設定情報は経路属性で資格があります。(属性は可能なルートから適切なものを選択する目的のためにルートを微分します)。 また、共同体属性[RFC1997][BGP-COM]によってルートは分類されます。
The IBGP mesh size tends to increase dramatically with the number
of BGP speakers in an autonomous system. BGP can reduce the number
of IBGP sessions by dividing the autonomous system into smaller
autonomous systems and grouping them into a single confederation
[RFC3065]. Route reflection is another way to reduce the number of
IBGP sessions [RFC1966]. BGP divides the autonomous system into
clusters. Each cluster establishes the IBGP full mesh within
itself, and designates one or more BGP speakers as "route
reflectors," which communicate with other clusters via their route
reflectors. Route reflectors in each cluster maintain path and
attribute information across the autonomous system. The autonomous
system still functions like a fully meshed autonomous system. On
the other hand, confederations provide finer control of routing
within the autonomous system by allowing for policy changes across
confederation boundaries, while route reflection requires the use
of identical policies.
IBGPメッシュサイズは、BGPスピーカーの数が自律システムにある状態で劇的に増加する傾向があります。 BGPは、自律システムをより小さい自律システムに分割して、それらを単一の同盟者[RFC3065]に分類することによって、IBGPセッションの数を減少させることができます。 ルート反射はIBGPセッション[RFC1966]の数を減少させる別の方法です。 BGPは自律システムをクラスタに分割します。 各クラスタは、「ルート反射鏡」としてそれ自体の中にIBGPの完全なメッシュを設立して、1人以上のBGPスピーカーを任命します。(それは、それらのルート反射鏡を通って他のクラスタで交信します)。 各クラスタのルート反射鏡は自律システムの向こう側に経路と属性情報を保守します。 自律システムは完全にかみ合っている自律システムのようにまだ機能しています。 他方では、同盟者は自律システムの中で同盟者境界の向こう側に政策変更を考慮することによって、ルーティングの、よりよいコントロールを提供します、ルート反射が同じ方針の使用を必要としますが。
BGP-4 has been extended to support IPv6, IPX, and others as well as
IPv4 [RFC2858]. Multiprotocol BGP-4 carries routes from multiple
"address families".
BGP-4は、IPv4と同様にIPv6、IPX、および他のものを支持するために広げられました[RFC2858]。 Multiprotocol BGP-4は複数の「アドレス家族」からルートを運びます。
4. Network Interface and SP Support of VPNs
4. VPNsのネットワーク・インターフェースとSPサポート
4.1. Functional Components of a VPN
4.1. VPNの機能部品
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ベースのVPNs(顧客ルートを学ぶ手段)がPEsの間にそれらを分配する、顧客サイトに届いている目的地の広告を出すために。
Callon & Suzuki Informational [Page 32] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[32ページ]鈴木の情報のRFC4110
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.
実際の実現に基づいて、これらの機能は、1VPNあたり1個のベースで実行できたか、またはすべてのVPNsによって共有された一般的なメカニズムで達成されるかもしれません。 例えば、ただ一つの過程がすべてのVPNsのためのルーティング情報を扱うかもしれませんか、または別々の過程は各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.
論理的に、以下の3つのステージを落ち着かせた状態でVPNの設立を考えることができます。 第一段階では、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エッジデバイスが何か一般的のVPNsを支持するかどうか決定するために取得される必要があります。 例えば、それぞれのVPNエッジデバイスで構成されたVPNsに関するVPN識別子を交換することによって、これを達成できます。 VPNエッジデバイスの能力は、断固とする必要があります、トンネリング、そして/または、ルーティングのために一般的なメカニズムに同意できるように。 例えば、サイトAがメカニズムにトンネルを堀るとしてIPsecとMPLSの両方を支持して、サイトBがMPLSだけを支持するなら、彼らは、トンネリングにMPLSを使用するのにともに同意できます。 いくつかの場合、能力情報がそれとなく決定しているかもしれない、例えば、いくつかのSPsがただ一つのVPNソリューションを実現するかもしれません。 同様に、セクション4.4で議論した方法を使用することでVPNsのためのルーティング情報を分配できます。
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/イシス/RIPなどのIGPs、または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
VPN会員資格と情報が主要なマネージメントシステムから分配されて、プロトコルを使用できる能力、例えば、LDAP。 あるいはまた、手動でそれを分配できます。 しかしながら、手動の構成は比例しないで、誤り傾向があるとき、使用はお勧めできないです。 3分の1に代替として、VPN情報はそうであることができます。
Callon & Suzuki Informational [Page 33] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[33ページ]鈴木の情報のRFC4110
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.
プロトコルがルーティング情報のためにするルーティングとして自動で一貫した情報の流通を直ちに、そして、非常に確実にするプロトコルで、分配されています。 これは、情報がルーティング・プロトコル自体で運ばれるのを示すかもしれません、否定的に影響を与えないでこれができる場合にだけ、不可欠のルーティングは機能しますが。
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ベースのVPNsのために、VPNサービスはCE装置の間のトンネルを提供しています。 顧客ネットワークはVPNのためのIPルーティングを完了しています。 これらの解決策で、SPは会員資格/能力発見ステージとトンネル設立ステージの操作にかかわります。 機能部品を発送するIPは完全に顧客ネットワークまで達しているかもしれませんか、またはあるいはまた、SPのマネージメントシステムが同じVPNの他のサイトへのVPNサイトの可到達性情報の分配に原因となるかもしれません。
4.2. VPN Establishment and Maintenance
4.2. 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はVPNsの設立と維持に責任があります。 多くの異なるアプローチと計画はしかしながら、どんなVPN解決策も訴えなければならないそのいくつかの一般的な問題が提供するために3PPVPNsを層にして、あるのが可能です、である:
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に加えられるとき、PEベースのVPNsに関しては、他のPEsはどのようにそれを見つけますか? PEが最初に与えられたVPNに付けられるとき、それは、どの他のPEsが同じVPNに取り付けられるかをどのように決定しますか? 新しいサイトが加えられるとき、CEベースのVPNsに関しては、CEは同じVPNの他のサイトにどのように他のすべてのCEsを見つけますか?
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ベースのVPNsがスケーリングするように、すべてのVPNsのためのすべてのルートがすべてのPEsにあることができるというわけではありません。 VPNルーティング情報の分配が抑制されるので、それはどうそれを必要とするそれらの装置だけに分配されますか?
Callon & Suzuki Informational [Page 34] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[34ページ]鈴木の情報のRFC4110
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 管理者は異なったVPNs(例えば、a完全なメッシュかハブとスポークトポロジー)のために支給に異なったtopologiesを願うかもしれません。 これはどのように達成されますか?
This section looks at some of these generic problems and at some of
the mechanisms that can be used to solve them.
このセクションはこれらの一般的な問題のいくつかにおいてそれらを解決するのに使用できるメカニズムのいくつかを見ます。
4.2.1. VPN Discovery
4.2.1. VPN発見
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.
メカニズムがVPNsの設立と維持を許す情報を取得するのが必要です。 これは例えば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.
物理ネットワーク、リンクの物理的なインタコネクトのコントロールと、ルータに発見/を走らせることによって解決された同等な問題缶、こんにちは、局所的に接続されたリンクの上に議定書を作ってください。 VPNsと共に、ルータとリンクの両方(トンネル)が論理的な実体であるかもしれません、そして、その結果、ある他のメカニズムが必要です。
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エッジデバイスを使用します。 また、VPN発見情報を分配するのにこのアプローチを使用できます、固有のプロトコルを使用するか、または標準の管理プロトコルとMIBsを使用して。 別のアプローチはVPNエッジデバイスがVPN発見情報を含む集結されたディレクトリかデータベースサーバーのクライアントとして機能するところです。 別の可能性はVPN発見情報がVPNエッジデバイス[VPN-DISC]の間を走るルーティング・プロトコルに背負われるところです。
4.2.1.1. Network Management for Membership Information
4.2.1.1. 会員資格情報のためのネットワークマネージメント
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,
SPsは、それらのネットワーク中で広げられる様々な装置を構成して、モニターするのに手広くネットワークマネージメントを使用します。 また、VPNの関連する情報を分配するのにこのアプローチを使用できました。 SPは、様々な位置のVPNエッジデバイスの上でVPNsを構成して、食糧を供給するのに、ネットワーク管理システム(集結されるか、または分配される)を使用できました。 他のネットワークマネージメント情報を分配するのに使用される同じ手段で、VPN設定情報をネットワークマネージメントアプリケーションに入力して、リモートサイトに分配できるでしょう。 独身のSPのネットワークの中に食糧を供給しなければならないすべての装置があるとき、このアプローチは最も当然です。
Callon & Suzuki Informational [Page 35] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[35ページ]鈴木の情報のRFC4110
since the SP has access to all VPN edge devices in its domain. Security and access control are important, and could be achieved for example using SNMPv3, SSH, or IPsec tunnels.
以来、SPはドメインのすべてのVPNエッジデバイスに近づく手段を持っています。 セキュリティとアクセス管理は、重要であり、例えば、SNMPv3、SSH、またはIPsecトンネルを使用することで達成できるでしょう。
4.2.1.2. Directory Servers
4.2.1.2. ディレクトリサーバ
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情報に制限するのにそれを使用できます)。
4.2.1.3. Augmented Routing for Membership Information
4.2.1.3. 会員資格情報のための増大しているルート設定
Extensions to the use of existing BGP mechanisms, for distribution of VPN membership information, are proposed in [VPN-2547BIS]. In that scheme, BGP is used to distribute VPN routes, and each route carries a set of attributes which indicate the VPN (or VPNs) to which the route belongs. This allows the VPN discovery information and routing information to be combined in a single protocol. Information needed to establish per-VPN tunnels can also be carried as attributes of the routes. This makes use of the BGP protocol's ability to effectively carry large amounts of routing information.
既存のBGPメカニズムのVPN会員資格情報の分配の使用への拡大は[VPN-2547BIS]で提案されます。 その計画では、BGPはVPNルートを分配するのに使用されます、そして、各ルートはルートが属するVPN(または、VPNs)を示す1セットの属性を運びます。 これで、VPN発見情報とルーティング情報はただ一つのプロトコルで結合します。 また、ルートの属性として1VPNあたりのトンネルを確立するのに必要である情報は運ぶことができます。 これは事実上、多量のルーティング情報を運ぶ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
集められたルーティングと組み合わせてセクション4.4.4で議論するように増大しているルーティングをするかもしれません。 もちろんをどんな種類のVPN-特殊情報も分配するのにBGPを使用するとき確実にしなければなりません。
Callon & Suzuki Informational [Page 36] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[36ページ]鈴木の情報のRFC4110
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.
それはBGPの公共のインターネット・ルーティング情報を分配する古典的な使用を中断していません。 このさらなる議論に関しては、集められたルーティング、セクション4.4.4の議論を見てください。
4.2.1.4. VPN Discovery for Inter-SP VPNs
4.2.1.4. 相互SP VPNsのためのVPN発見
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の向こう側に標準化されて、サポートされるなら、自動化された交換は容易にされるかもしれません。 相互SP信用関係は、VPNsのどの情報とどのくらいの情報がSPsの間で交換されるかもしれないかを証明されて、例えば決定する必要があるでしょう。
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 VPNsに、何らかの手動のコーディネートと構成が必要であるかもしれないことを含意します。
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 VPNsのサイズの数に大いに依存する情報の量。 したがって、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情報の分配は相互プロバイダールーティング情報の分配と異なっています、後者が、インターネット中で分配される必要があるとき。 さらに、2SPsによるVPNの共同サポートは、どんな第3SPもそのVPNのために状態を維持するのを必要とするべきではありません。 もう一度、相互プロバイダールーティングに関して違いに気付いてください。 相互プロバイダールーティングで: 本当に、1SPから別の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.
1つの可能な例として: 2SPs AとCがあると仮定してください。(Cは一般的なVPNを支持したがっています)。 AとCがSP B.In本件でBはAとCの間の交通を発送する方法を知るのが必要であり、したがって必要があるインタコネクトされると仮定して、AとC(AとCでPEsかルート反射鏡の間でIP交通を進める、そして/または、MPLS LSPsを接続できるくらいのルーティング情報などの)に関して何かを知ってください。 しかしながら、スケーリング目的のために、BがAとCで支持されるVPNsに関するVPN-特殊情報を知る必要はないのは、望ましいです。
Callon & Suzuki Informational [Page 37] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[37ページ]鈴木の情報のRFC4110
4.2.2. Constraining Distribution of VPN Routing Information
4.2.2. 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ルーティング情報(彼らが付けているVPNsのための)を意識しているに違いありません。 スケーラビリティ理由で、人はすべてのVPNsのために、すべてのPEsがすべてのルートを含む計画が欲しくはありません。 与えられたVPNのサイトに取り付けられるPEsだけがその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.
Virtual Router計画に、次に、VPNのためのどんなルートも分配されていて、ルートがそれらのトンネルを通って分配される前に1VPNあたりのトンネルを確立しなければなりません。 したがって、適切なセットのトンネルを確立することによって、人は、それとなく1VPNあたりのルーティング情報の分配を抑制して、制御します。 この計画では、会員資格情報の分配は各PEに存在するVPNsのセットから成ります、必要なトポロジーの情報と同様に。 これは、PEがそれが特定のVPNのためにトンネルを確立しなければならないリモートPEsのセットを決定するのを可能にします。
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で議論するようにルート反射鏡で行われるかもしれません。
4.2.3. Controlling VPN Topology
4.2.3. VPNトポロジーを制御します。
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
VPNのためのトポロジーはトンネルを通ってインタコネクトされた1セットのノードから成ります。 トポロジーは、完全なメッシュ、ハブであるかもしれなく、トポロジー、または任意のトポロジーを話しました。 VPNに関しては、ノードのセットはそのVPNのためにサイトを添付したすべてのVPNエッジデバイスを含むでしょう。 当然、すべてのVPNサイトがトポロジーが何であっても、互いから届いています。 トポロジーは単に交通が発送される方法を抑制します。
Callon & Suzuki Informational [Page 38] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[38ページ]鈴木の情報のRFC4110
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.
サイトの中で。 例えば、サイトAとサイトの間の1回のトポロジー交通では、BはVPN背骨の直接上に一方からもう一方まで行きます。 別のトポロジーでは、サイトBに達する前に、サイトAからサイトBまでの交通がサイトCを横断しなければなりません。
The simplest topology is a full mesh, where a tunnel exists between every pair of VPN edge devices. If we assume the use of point-to- point tunnels (rather than multipoint-to-point), then with a full mesh topology there are N*(N-1)/2 duplex tunnels or N*(N-1) simplex tunnels for N VPN edge devices. Each tunnel consumes some resources at a VPN edge device, and depending on the type of tunnel, may or may not consume resources in intermediate routers or LSRs. One reason for using a partial mesh topology is to reduce the number of tunnels a VPN edge device, and/or the network, needs to support. Another reason is to support the scenario where an administrator requires all traffic from certain sites to traverse some particular site for policy or control reasons, such as to force traffic through a firewall, or for monitoring or accounting purposes. Note that the topologies used for each VPN are separate, and thus the same VPN edge device may be part of a full mesh topology for one VPN, and of a partial mesh topology for another VPN.
最も簡単なトポロジーは完全なメッシュです。(そこでは、トンネルがすべての組のVPNエッジデバイスの間に存在します)。 私たちがポイントからポイントへのトンネル(多点からポイントよりむしろ)の使用を仮定するなら、完全なメッシュトポロジーをもって、N VPNエッジデバイスのための(N-1)/2つのN*複式のトンネルかN*(N-1)シンプレクストンネルがあります。 各トンネルはVPNエッジデバイスのいくつかのリソースを消費します、そして、トンネルのタイプに頼っていて、中間的ルータかLSRsのリソースを消費するかもしれません。 部分的なメッシュトポロジーが数を減らすことになっている使用の1つの理由がVPNエッジデバイス、そして/または、ネットワーク(支持する必要性)にトンネルを堀ります。 別の理由は方針かコントロール理由(目的をファイアウォール、モニターするか、または説明するための交通を強制するようなもの)で、管理者が何らかの特定のサイトを横断するためにある一定のサイトからのすべての交通を必要とするシナリオを支持することです。 各VPNに使用されるtopologiesが別々であり、その結果、同じVPNエッジデバイスが1VPNに、完全なメッシュトポロジー、および別のVPNのための部分的なメッシュトポロジーの一部であるかもしれないことに注意してください。
An example of where a partial mesh topology could be suitable is for a VPN that supports a large number of telecommuters and a small number of corporate sites. Most traffic will be between telecommuters and the corporate sites, not between pairs of telecommuters. A hub and spoke topology for the VPN would thus map onto the underlying traffic flow, with the telecommuters attached to spoke VPN edge devices and the corporate sites attached to hub VPN edge devices. Traffic between telecommuters is still supported, but this traffic traverses a hub VPN edge device.
部分的なメッシュトポロジーが適当であるかもしれないところに関する例は多くの在宅勤務者と少ない数の法人のサイトをサポートするVPNのためのものです。 在宅勤務者と法人のサイトの間には、ほとんどの交通が在宅勤務者の組の間には、あるのではなく、あるでしょう。 その結果在宅勤務者がスポークVPNエッジデバイスと法人のサイトに付けられている状態でVPNのためのトポロジーが基本的な交通の流れに写像するハブとスポークはハブVPNエッジデバイスに付きました。 在宅勤務者の間の交通はまだ支持されていますが、この交通はハブVPNエッジデバイスを横断します。
The selection of a topology for a VPN is an administrative choice, but it is useful to examine protocol mechanisms that can be used to automate the construction of the desired topology, and thus reduce the amount of configuration needed. To this end it is useful for a VPN edge device to be able to advertise per-VPN topology information to other VPN edge devices. It may be simplest to advertise this at the same time as the membership information is advertised, using the same mechanisms.
VPNのためのトポロジーの選択は管理選択ですが、必要なトポロジーの工事を自動化して、その結果、必要である構成の量を減少させるのに使用できるプロトコルメカニズムを調べるのは役に立ちます。 VPNエッジデバイスが1VPNあたりのトポロジー情報の他のVPNエッジデバイスに広告を出すことができるように、このために、それは役に立ちます。 広告を出して、同じメカニズムを使用する会員資格情報と同時にこれの広告を出すのは最も簡単であるかもしれません。
A simple scheme is where a VPN edge device advertises itself either as a hub or as a spoke, for each VPN that it has. When received by other VPN edge devices this information can be used when determining whether to establish a tunnel. A more comprehensive scheme allows a VPN edge device to advertise a set of topology groups, with tunnels established between a pair of VPN edge devices if they have a group in common.
簡単な体系はVPNエッジデバイスがハブとして、または、スポークとして自分を売り込むところです、それが持っている各VPNのために。 トンネルを確立するかどうか決定するとき、他のVPNエッジデバイスで受け取ると、この情報を使用できます。 より包括的な体系は1セットのトポロジーグループの広告を出すためにVPNエッジデバイスを許容します、グループが共通であるなら1組のVPNエッジデバイスの間で確立されたトンネルで。
Callon & Suzuki Informational [Page 39] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[39ページ]鈴木の情報のRFC4110
4.3. VPN Tunneling
4.3. 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パケットを輸送するのにトンネリングを使用します、1つのVPNエッジデバイスから別のエッジデバイスまで。 異なったタイプのトンネリングプロトコル、トンネルを確立して、維持する異なった方法、およびトンネルをVPNsに関連づける異なった方法(例えば、1VPNあたりの専用トンネルに対して共有される)があります。 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トラフィックは非ユニークであるかプライベートアイピーアドレシング[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とセキュリティ必要条件は、異なるかもしれなくて、適切な特性がある異なったトンネルを使用することによって、満たすことができます。 これで、プロバイダーはトラフィックのために異なったVPNsか、独身の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におけるIPと、IPsecと、MPLSです、これらがVPNバックボーンの向こう側にVPNトラフィックを運ぶのに最も適当であるので。 アクセスがトンネルを堀るとき、L2TPなどの他のトンネリングプロトコル[RFC2661]は使用されるかもしれません、PEとCEの間までトラフィックを運んで。 バックボーントンネリングがアクセストンネリングと独立していて直交しているので、ここで後者のためのプロトコルについて議論しません。
4.3.1. Tunnel Encapsulations
4.3.1. トンネルカプセル化
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に例を提供します。
Callon & Suzuki Informational [Page 40] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[40ページ]鈴木の情報のRFC4110
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つの特性は1トンネルあたりの状態がカプセル化されたパケットを進めるのにSPネットワークで必要であるかどうかということです。 IPトンネリング体系(GRE、IPにおけるIP、およびIPsec)において、1トンネルあたりの状態はVPNエッジデバイスに完全に閉じ込められます。 他のルータは、トンネルに気づかなくて、IPヘッダーに従って、前進しています。 MPLSに、1トンネルあたりの状態が必要です、中間的LSRsがラベルスタックのトップラベルを調べられて、交換しなければならないので。 階層的なマルチプレクシング、およびマルチポイント・ツー・ポイントトンネルの使用で必要である状態の量を最小にすることができます、以下で議論するように。
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.
別の特性はオーバーヘッドが導入したトンネリングです。 例えば超能力ヘッダー、超能力トレーラ、および追加IPヘッダーを含むかもしれないので、IPsecと共に、オーバーヘッドは無視できないかもしれません。 他のメカニズムはMPLSが最も軽量の頭上では、より少ない使用を記載しました。 どんなトンネリングメカニズムにも固有のオーバーヘッドは追加IPパケット断片化をもたらすかもしれません、結果として起こるパケットが基本的なリンクレイヤのそばで運ぶことができないくらい大きいなら。 そういうものとして、いずれもどこでも、可能であるところで断片化を避けるために経路MTU探索などのメカニズムでMTUサイズを減少させたと報告するのは重要です。
Yet another characteristic is something we might call "transparency to the Internet". IP-based encapsulation can carry be used to carry a packet anywhere in the Internet. MPLS encapsulation can only be used to carry a packet on IP networks that support MPLS. If an MPLS-encapsulated packet must cross the networks of multiple SPs, the adjacent SPs must bilateral agreements to accept MPLS packets from each other. If only a portion of the path across the backbone lacks MPLS support, then an MPLS-in-IP encapsulation can be used to move the MPLS packets across that part of the backbone. However, this does add complexity. On the other hand, MPLS has efficiency advantages, particularly in environments where encapsulations may need to be nested.
さらに別の特性は私たちが「インターネットへの透明」と呼ぶかもしれないことです。 IPベースのカプセル化を運ぶことができます。使用されて、インターネットでどこでもパケットを運んでください。 MPLSをサポートするIPネットワークでパケットを運ぶのにMPLSカプセル化を使用できるだけです。 MPLSによってカプセル化されたパケットが複数のSPsのネットワークを越えなければならないなら、互いからMPLSパケットを受け入れる隣接しているSPs必須二国間条約です。 バックボーンの向こう側の経路の部分だけがMPLSサポートを欠いているなら、MPLSパケットをバックボーンのその部分の向こう側に動かすのにIPにおけるMPLSカプセル化を使用できます。 しかしながら、これは複雑さを加えます。 他方では、MPLSには、特にカプセル化が入れ子にされる必要があるかもしれない環境における効率利点があります。
Transparency to the Internet is sometimes a requirement, but sometimes not. This depends on the sort of service which a SP is offering to its customer.
インターネットへの透明は、時々要件にもかかわらず、時々要件ではありません。 これはSPが顧客に提供しているサービスの種類に依存します。
4.3.2. Tunnel Multiplexing
4.3.2. トンネルマルチプレクシング
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
トンネルを堀られたパケットがトンネル出口に到着するとき、カプセル化ヘッダーからパケットのVPNを推論するのは可能であるに違いありません。 MPLSカプセル化では、パケットのラベルスタックからこれを推論しなければなりません。 IPベースのカプセル化では、カプセル化ヘッダーのIPソースアドレス、受信者IPアドレス、および「マルチプレクシング分野」の何らかの組み合わせからこれを推論できます。 マルチプレクシング
Callon & Suzuki Informational [Page 41] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[41ページ]鈴木の情報のRFC4110
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:
分野は、マルチプレクシングのために明らかに設計されたもの、または元々、これのために設計されませんでしたが、マルチプレクシング分野としてサービスに押し込むことができるものであるかもしれません。 例えば:
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アドレス、およびKey分野によってVPNに関連づけられたパケット。
o IP-in-IP: Packets associated to VPN by IP destination address in
outer header.
o IPにおける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.
与えられたPEによってサポートされたあらゆるVPNに異なった受信者IPアドレスを使用しなければならないためにIPにおけるIPトンネリングには本当のマルチプレクシング分野がないことに注意してください。 他のIPベースのカプセル化では、与えられたPEはただ一つのIPアドレスしか持ってはいけません、そして、マルチプレクシング分野は、PEによってサポートされた異なったVPNsを区別するのに使用されます。 その結果、IPにおける重要がソリューションで不都合であるそれが潜在的に大きい数の配分と課題を必要とするIP IPアドレス。それのすべてがバックボーンルーティングで届いていなければなりません。
In the following, we will use the term "multiplexing field" to refer to whichever field in the encapsulation header must is used to distinguish different VPNs at a given PE. In the IP-in-IP encapsulation, this is the destination IP address field, in the other encapsulations it is a true multiplexing field.
以下では、私たちは分野が参照されるカプセル化ヘッダーがそうしなければならない「マルチプレクシング分野」が与えられたPEで異なったVPNsを区別するのに使用される用語を使用するつもりです。 IPにおけるIPカプセル化では、これが目的地IPアドレス・フィールドである、他のカプセル化では、それは本当のマルチプレクシング分野です。
4.3.3. Tunnel Establishment
4.3.3. トンネル設立
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.
トンネルが確立されるとき、トンネル終点は特定のパケットが特にVPNsであることを示すのに使用されることであるマルチプレクシング分野値に同意しなければなりません。 VPNsの数が増加するのに従って、「よく知られている」か明らかに食糧を供給された値の使用はよく比例しないでしょう。 それで、トンネル終点がマルチプレクシング分野値に同意するある種のプロトコル相互作用を持つのが必要です。
For some tunneling protocols, setting up a tunnel requires an explicit exchange of signaling messages. Generally the multiplexing field values would be agreed upon as part of this exchange. For example, if an IPsec encapsulation is used, the SPI field plays the role of the multiplexing field, and IKE signaling is used to distribute the SPI values; if an MPLS encapsulation is used, LDP,
いくつかのトンネリングプロトコルのために、トンネルを設立するのはシグナリングメッセージの明白な交換を必要とします。 一般にマルチプレクシング分野値はこの交換の一部として同意されるでしょう。 例えば、IPsecカプセル化が使用されているなら、SPI分野はマルチプレクシング分野の役割を果たします、そして、IKEシグナリングはSPI値を分配するのに使用されます。 使用されるMPLSカプセル化、自由民主党であるなら
Callon & Suzuki Informational [Page 42] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[42ページ]鈴木の情報のRFC4110
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.
マルチプレクシング分野として使用されるMPLSラベル価値を分配するのにCR-自由民主党かRSVP-TEを使用できます。 トンネルが関連させていることになっているVPNのアイデンティティに関する情報は、シグナリングプロトコルの一部として交換される必要があります(シグナリングプロトコルで例えばVPN-IDを運ぶことができます)。 このアプローチの利点はまた、1トンネルあたりのセキュリティ、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トンネルに関して、VPNルートかVPN会員資格情報を分配するのに使用されるプロトコルでMPLSラベルを背負うことができます。 GREとIPにおけるIPにはどんな関連シグナリングプロトコルもなくて、その結果、マルチプレクシング値は、必要に迫られて、構成、制御プロトコルを通したなどある他のメカニズムで分配されるか、またはVPN会員資格プロトコルに関する何らかの方法で背負われます。
The resources used by the different tunneling establishment mechanisms may vary. With a full mesh VPN topology, and explicit signaling, each VPN edge device has to establish a tunnel to all the other VPN edge devices for in each VPN. The resources needed for this on a VPN edge device may be significant, and issues such as the time needed to recover following a device failure may need to be taken into account, as the time to recovery includes the time needed to reestablish a large number of tunnels.
異なったトンネリング設立メカニズムによる運用資金は異なるかもしれません。 VPNトポロジー、および明白なシグナリング、それぞれのVPNエッジデバイスが他のすべてのVPNエッジデバイスへのトンネルを各VPNに確立しなければならない完全なメッシュで。 VPNエッジデバイスの上でこれに必要であるリソースは重要であるかもしれません、そして、デバイスの故障に続く回復する時間が、必要があった問題は考慮に入れられる必要があるかもしれません、多くのトンネルを復職させるのが必要であることで、回復への時間が時間を含んでいるとき。
4.3.4. Scaling and Hierarchical Tunnels
4.3.4. 比例していて階層的なTunnels
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トポロジーで隣接している隣接しているデバイスの間の1VPNあたりのトンネルを設立するのは可能でないかもしれません。 これは、1VPNあたりの状態が全くネットワークのコアにないという原則に違反して、VPNsの数が増加するのに応じて、コアスケールに不十分になるでしょう。 例えば、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
また、明白なシグナリングのトンネル設立の使用に関連するスケーリング問題があります。 トンネリングプロトコルがそうしないでも、コア、トンネルの数でVPNエッジデバイスが扱う必要があるシングルが大きいかもしれないとトンネル州単位で主張してください、VPNsの数と1VPNあたりの隣人の数に応じてこれが成長するとき。 使用にはネットワークにおけるトンネルの数を減らす1つの方法があります。
Callon & Suzuki Informational [Page 43] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[43ページ]鈴木の情報のRFC4110
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エッジデバイスがまだ多くのトンネルを扱う必要があるかもしれないtopologiesを話しました。
If the core routers need to maintain any per-tunnel state at all, scaling can be greatly improved by using hierarchical tunnels. One tunnel can be established between each pair of VPN edge devices, and multiple VPN-specific tunnels can then be carried through the single "outer" tunnel. Now the amount of state is dependent only on the number of VPN edge devices, not on the number of VPNs. Scaling can be further improved by having the outer tunnels be multipoint-to-point "merging" tunnels. Now the amount of state to be maintained in the core is on the order of the number of VPN edge devices, not on the order of the square of that number. That is, the amount of tunnel state is roughly equivalent to the amount of state needed to maintain IP routes to the VPN edge devices. This is almost (if not quite) as good as using tunnels which do not require any state to be maintained in the core.
コアルータが、全くどんな1トンネルあたりの状態も維持する必要があるなら、階層的なトンネルを使用することによって、スケーリングを大いに改良できます。 それぞれの組のVPNエッジデバイスの間で1つのトンネルを確立できます、そして、次に、単一の「外側」のトンネルを通って複数のVPN特有のトンネルを運ぶことができます。 現在、状態の量はVPNsの数ではなく、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エッジデバイスで維持される状態の量は減少するかもしれません、特に外トンネルを維持するのが外トンネルの中を動く1VPNあたりのトンネルを維持するより多くの状態を必要とするなら。
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能力か異なったセキュリティの特性が異なった交通の流れ(同じくらい、または、異なったVPNsからの)に使用されるのをシングルを使用している間、そのようなトンネルには、最も良いスケーリング特性があって、1つ以上を使用するのは、許容するかもしれません。
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ラベルスタック)には階層構造のトンネルがすべてあるかもしれませんか、または異なったタイプには彼らがいるかもしれません(例えばGREトンネルはIPsecトンネルの中で運ばれました)。
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エッジデバイスの間に異なったレベルのセキュリティを提供して。 次に、別々のIPsecトンネルVPNを持っているよりむしろ適切なIPsecトンネルの上まで1VPN GREあたりのトンネルを一緒に分類して、次に、運ぶことができます。 別の例はMPLSラベルスタックの使用です。 独身のPE-PE LSPは、すべてのVPN LSPsを運ぶのに使用されます。 ラベル設立に使用されるメカニズムは通常異なっています。 PE-PE LSPは設立された使用自由民主党であるかもしれません、部分として、1VPN LSPあたりのラベルがセクション3.3.1で議論したVPNルーティング(例えば、BGPを使用する)で便乗することによって設立されている通常のバックボーン操作が、.3と4.1です。
Callon & Suzuki Informational [Page 44] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[44ページ]鈴木の情報のRFC4110
4.3.5. Tunnel Maintenance
4.3.5. トンネルメインテナンス
Once a tunnel is established it is necessary to know that the tunnel is operational. Mechanisms are needed to detect tunnel failures, and to respond appropriately to restore service.
トンネルがいったん確立されると、トンネルが操作上であることを知るのが必要です。 メカニズムが、トンネルの故障を検出して、復旧するために適切に応じるのが必要です。
There is a potential issue regarding propagation of failures when multiple tunnels are multiplexed hierarchically. Suppose that multiple VPN-specific tunnels are multiplexed inside a single PE to PE tunnel. In this case, suppose that routing for the VPN is done over the VPN-specific tunnels (as may be the case for CE-based and VR approaches). Suppose that the PE to PE tunnel fails. In this case multiple VPN-specific tunnels may fail, and layer 3 routing may simultaneously respond for each VPN using the failed tunnel. If the PE to PE tunnel is subsequently restored, there may then be multiple VPN-specific tunnels and multiple routing protocol instances which also need to recover. Each of these could potentially require some exchange of control traffic.
複数のトンネルを階層的に多重送信するとき、失敗の伝播に関する潜在的問題があります。 複数のVPN特有のトンネルが独身のPEの中でPEトンネルに多重送信されると仮定してください。 この場合、VPNのためにVPN特有のトンネルの上にルーティングすると仮定してください(CEベースとVRアプローチのためにそうであるかもしれないように)。 PEトンネルへのPEが失敗すると仮定してください。 この場合、複数のVPN特有のトンネルが失敗するかもしれません、そして、層3のルーティングは、同時に、各VPNのために失敗したトンネルを使用することで応じるかもしれません。 PEトンネルへのPEが次に返されるなら、その時、複数のVPN特有のトンネルとまた、回復する必要がある複数のルーティング・プロトコルインスタンスがあるかもしれません。それぞれのこれらは潜在的にコントロールトラフィックの何らかの交換を必要とするかもしれません。
When a tunnel fails, if the tunnel can be restored quickly, it might therefore be preferable to restore the tunnel without any response by high levels (such as other tunnels which were multiplexed inside the failed tunnels). By having high levels delay response to a lower level failed tunnel, this may limit the amount of control traffic needed to completely restore correct service. However, if the failed tunnel cannot be quickly restored, then it is necessary for the tunnels or routing instances multiplexed over the failed tunnel to respond, and preferable for them to respond quickly and without explicit action by network operators.
したがって、すぐにトンネルを修復できるならトンネルが失敗するとき、高いレベル(失敗したトンネルの中で多重送信された他のトンネルなどの)で少しも応答なしでトンネルを修復するのは望ましいかもしれません。 高いレベルに下のレベルの失敗したトンネルへの応答を遅らせさせることによって、これは正しいサービスを完全に復元するのに必要であるコントロールトラフィックの量を制限するかもしれません。 しかしながら、すぐに失敗したトンネルを修復できないなら、彼らがすぐにとネットワーク・オペレータによる明白な動作なしで応じるのは、応じるために失敗したトンネルの上に多重送信されたトンネルかルーティングインスタンスに必要であって、望ましいです。
With most layer 3 provider-provisioned CE-based VPNs and the VR scheme, a per-VPN instance of routing is running over the tunnel, thus any loss of connectivity between the tunnel endpoints will be detected by the VPN routing instance. This allows rapid detection of tunnel failure. Careful adjustment of timers might be needed to avoid failure propagation as discussed the above. With the aggregated routing scheme, there isn't a per-VPN instance of routing running over the tunnel, and therefore some other scheme to detect loss of connectivity is needed in the event that the tunnel cannot be rapidly restored.
大部分で、3プロバイダーで食糧を供給されたCEベースのVPNsとVR体系を層にしてください、とルーティングの1VPNあたり1つのインスタンスがトンネルの上で管理しています、その結果、トンネル終点の間の接続性のどんな損失もVPNルーティングインスタンスによって検出されるでしょう。 これはトンネルの故障の急速な検出を許します。 タイマの慎重な調整が、上記について議論するので失敗伝播を避けるのに必要であるかもしれません。 集められたルーティング体系と共に、トンネル中を走らせるルーティングの1VPNあたり1つのインスタンスがありません、そして、したがって、急速にトンネルを修復できないなら、接続性の損失を検出するある他の体系が必要です。
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
トンネルの接続性の失敗は確かに検出するのが非常に難しい場合があります。 失敗を検出するのに使用できるメカニズムは遠く離れた終点(例えば、「ホスティングしないIPルート全く」かどんなMPLSラベルによっても示されないように)への基本的な接続性の損失、より高い層の「こんにちは」メカニズム(IGP hellos、トンネルであるときに、例えば、隣接番組がいくらかのIGPにあります、)のタイムアウトであり、生きている生活費のタイムアウトは中のメカニズムです。
Callon & Suzuki Informational [Page 45] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[45ページ]鈴木の情報のRFC4110
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.
トンネル設立プロトコル(もしあれば)。 しかしながら、これらのテクニックのいずれもすべての故障モードの完全に信頼できる検出を提供しません。 また、追加モニター技術も必要であるかもしれません。
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つが下がっているデバイスにあるかもしれません。
4.3.6. Survey of Tunneling Techniques
4.3.6. トンネリングのテクニックの調査
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における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バイトサポートするスイッチは市販にもあります。 この場合、断片化のリスクが全くありません。
4.3.6.1. GRE [RFC2784] [RFC2890]
4.3.6.1. GRE[RFC2784][RFC2890]
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.
ジェネリックルート設定Encapsulation(GRE)は任意の配送プロトコル[RFC2784]の上で任意のペイロードプロトコルをカプセル化するのにプロトコルを指定します。 層の3VPNsでそうであるように特に、ペイロードと配送プロトコルの両方が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]で指定されます、そして、それはマルチプレクシング分野として使用されるかもしれません。
Callon & Suzuki Informational [Page 46] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[46ページ]鈴木の情報のRFC4110
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 トンネルオーバーヘッドの大きいMTUsと最小化
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カプセル化は少しの重要なセキュリティも提供しません。 misconfigurationsの検出で支援するのにクリアテキストパスワードとして任意のキーフィールドを使用できますが、それは保全か認証を提供しません。 VPNsをサポートするSPネットワークは、偽造しているパケットがVPNsに入り込むのを防ぐために境界で大規模なIPアドレスフィルタリングをしなければなりません。 マルチプロバイダーVPNsがサポートされているなら、これらのフィルタをセットアップするのは難しいかもしれません。
4.3.6.2. IP-in-IP Encapsulation [RFC2003] [RFC2473]
4.3.6.2. IPにおけるIPカプセル化[RFC2003][RFC2473]
IP-in-IP specifies the format and procedures for IP-in-IP encapsulation. This allows an IP datagram to be encapsulated within another IP datagram. That is, the resulting packet consists of an outer IP header, followed immediately by the payload packet. There is no intermediate header as in GRE. [RFC2003] and [RFC2473] specify IPv4 and IPv6 encapsulations respectively. Once the encapsulated datagram arrives at the intermediate destination (as specified in the outer IP header), it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original destination address field.
IPにおけるIPはIPにおけるIPカプセル化に形式と手順を指定します。 これは、IPデータグラムが別のIPデータグラムの中にカプセル化されるのを許容します。 すなわち、結果として起こるパケットはすぐペイロードパケットがあとに続いた外側のIPヘッダーから成ります。 どんな中間的ヘッダーもGREのようにありません。 [RFC2003]と[RFC2473]はそれぞれIPv4とIPv6カプセル化を指定します。 カプセル化されたデータグラムがいったん中間的目的地に到着すると(外側のIPヘッダーで指定されるように)、それはdecapsulatedされます、オリジナルのIPデータグラム(次に、元の目的地アドレス・フィールドによって示された送付先に提供される)をもたらして。
Callon & Suzuki Informational [Page 47] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[47ページ]鈴木の情報のRFC4110
o Multiplexing
o マルチプレクシング
The IP-in-IP specifications don't explicitly support multiplexing.
But if a different IP address is used for every VPN then the IP
address field can be used for this purpose. (See section 4.3.2 for
detail).
IPにおけるIP仕様は明らかにマルチプレクシングをサポートしません。 しかし、異なったIPアドレスがあらゆるVPNに使用されるなら、このためにIPアドレス・フィールドを使用できます。 (詳細に関してセクション4.3.2を見ます。)
o QoS/SLA
o QoS/SLA
IP-in-IP itself does not have intrinsic QoS/SLA capabilities, but
of course it inherits whatever capabilities exist for IP.
Additional mechanisms, such as RSVP extensions [RFC2764] or
DiffServ extensions [RFC2983], may be used with it.
IPにおけるIP自身には、本質的なQoS/SLA能力がありませんが、もちろん、それはIPのために存在するどんな能力も引き継ぎます。 RSVP拡張子などの追加メカニズム[RFC2764]かDiffServ拡張子[RFC2983]がそれと共に使用されるかもしれません。
o Tunnel setup and maintenance
o トンネルセットアップとメインテナンス
There is no standard setup and maintenance protocol for IP-in-IP.
IPにおけるIPのための標準のセットアップとメインテナンスプロトコルが全くありません。
o Large MTUs and minimization of tunnel overhead
o トンネルオーバーヘッドの大きいMTUsと最小化
When the delivery protocol is IPv4, IP-in-IP adds at least 20 bytes
of overhead.
配送プロトコルがIPv4であるときに、IPにおけるIPは少なくとも20バイトのオーバーヘッドを加えます。
o Security
o セキュリティ
IP-in-IP encapsulation does not provide any significant security.
An SP network which supports VPNs must do extensive IP address
filtering at its borders to prevent spoofed packets from
penetrating the VPNs. If multi-provider VPNs are being supported,
it may be difficult to set up these filters.
IPにおけるIPカプセル化は少しの重要なセキュリティも提供しません。 VPNsをサポートするSPネットワークは、偽造しているパケットがVPNsに入り込むのを防ぐために境界で大規模なIPアドレスフィルタリングをしなければなりません。 マルチプロバイダーVPNsがサポートされているなら、これらのフィルタをセットアップするのは難しいかもしれません。
4.3.6.3. IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2409]
4.3.6.3. IPsec[RFC2401][RFC2402][RFC2406][RFC2409]
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 Security(IPsec)はIP[RFC2401]層でセキュリティー・サービスを提供します。 セキュリティがペイロード(超能力)プロトコル[RFC2406]、およびインターネットの主要な交換(IKE)プロトコル[RFC2409]であるとカプセル化して、それは認証ヘッダー(AH)プロトコル[RFC2402]を包括します。 AHプロトコルはデータ保全、データ発生源認証、および反再生サービスを提供します。 超能力プロトコルはデータの機密性と限られた交通の流れ秘密性を提供します。 また、それはデータ保全、データ発生源認証、および反再生サービスを提供するかもしれません。 AHと超能力は組み合わせに使用されるかもしれません。
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
IPsecは輸送かトンネルモードのどちらかで使われるかもしれません。 交通機関に、AHか超能力ヘッダーのどちらかがペイロードパケットのIPヘッダー直後挿入されます。 トンネルモードで、IPパケットは外側のIPパケットのヘッダーと共にカプセルに入れられます。 AHか超能力ヘッダーのどちらかがそれらの間に挿入されます。 AHと超能力はaを設立します。
Callon & Suzuki Informational [Page 48] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[48ページ]鈴木の情報のRFC4110
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.
2つの終点の間の単方向の安全な通信路。(その通信路はセキュリティ協会と呼ばれます)。 トンネルモードで、PE-PEトンネル(または、CE-CEトンネル)は1組の単方向のセキュリティ協会から成ります。 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と超能力の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 トンネルオーバーヘッドの大きいMTUsと最小化
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トンネリングを使用するとき、素晴らしい認証と保全機能を提供できます。 また、任意にプライバシーを提供できます。
4.3.6.4. MPLS [RFC3031] [RFC3032] [RFC3035]
4.3.6.4. MPLS[RFC3031][RFC3032][RFC3035]
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
Multiprotocol Label Switching(MPLS)は、ネットワークを通してパケットを進めるための方法です。 ネットワークの縁のルータは簡単なラベルをパケットに適用します。 ラベルは、データ・リンクとネットワークヘッダーの間に挿入されるか、またはデータ・リンクヘッダー(例えば、ATMヘッダーのVPI/VCI分野)で運ばれるかもしれません。 ネットワークにおけるルータ
Callon & Suzuki Informational [Page 49] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[49ページ]鈴木の情報のRFC4110
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)".
ラベルに応じて、最小量のルックアップオーバーヘッドでパケットを切り換えてください。 経路、またはPPVPNのトンネルが「ラベル切り換えられた経路(LSP)」と呼ばれます。
o Multiplexing
o マルチプレクシング
LSPs may be multiplexed within other LSPs.
他のLSPsの中でLSPsを多重送信するかもしれません。
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.
帯域幅をLSPsに割り当てるかもしれません、そして、MPLSには、本質的なQoSかSLA管理メカニズムがありませんが、明らかに彼らのルーティングを制御するかもしれません。 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.
LSPsは自由民主党(ラベルDistributionプロトコル)、RSVP(リソース予約プロトコル)[RFC3209]、またはBGPによってセットアップされて、維持されます。
o Large MTUs and minimization of tunnel overhead.
o トンネルオーバーヘッドの大きいMTUsと最小化。
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カプセル化は1ラベルあたり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かGREで任意にカプセルに入れられるかもしれません、IPだけインフラストラクチャの上までMPLSパケットを運ぶのが望ましいケースのために。
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の隣接しているルータから受け入れられるのを保証するために注意するべきです。
Callon & Suzuki Informational [Page 50] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[50ページ]鈴木の情報のRFC4110
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ネットワークもひくために保証できないカプセル化技術の唯一無二です。 インターネットへの透明が要件であるときに、したがって、それは適切でないでしょう。
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を支持しない3分の1までにMPLSを支持する2つの協力関係を持っているSPネットワークを切り離すなら、彼らの間でIPにおけるMPLSかIPsecのMPLSトンネリングをするかもしれません。
4.4. PE-PE Distribution of VPN Routing Information
4.4. VPN経路情報のPE-PE分配
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に背骨(すなわち、「場内放送」)を記述します。 VPNルート設定にこの「公共のルーティング情報」(ii)に電話をしてください: 情報がCEsから得たルーティングはVPNsにある(「プライベート・アドレス」)を記述します。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.
同様に、1VPNに関連しているVPNルーティング情報の分配は、他のVPNsの操作を動揺させるべきではありませんし、またそうでなければ、妨げるべきではありません。 例えば、私設のネットワークが内部のルーティングに関する不安定性か他の問題(その私設のネットワークをサポートするのに使用されるVPNに伝播されるかもしれない)が欠点であるかもしれないことで、これらの要件は関連しています。
Callon & Suzuki Informational [Page 51] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[51ページ]鈴木の情報のRFC4110
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に起こらないことに注意してください、PE装置が場内放送しか持っていない外側のヘッダーで要約されたパケット港の後のVPNからCEベースのVPNsの、パケットを見ないとき。
4.4.1. Options for VPN Routing in the SP
4.4.1. SPのVPNルート設定のためのオプション
The following technologies can be used for exchanging VPN routing information discussed in sections 3.3.1.3 and 4.1.
セクション3.3.1.3と4.1で議論したVPNルーティング情報を交換するのに以下の技術を使用できます。
o Static routing
o スタティックルーティング
o RIP [RFC2453]
o 裂け目[RFC2453]
o OSPF [RFC2328]
o OSPF[RFC2328]
o BGP-4 [RFC1771]
o BGP-4[RFC1771]
4.4.2. VPN Forwarding Instances (VFIs)
4.4.2. VPN推進例(VFIs)
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では、単一のPE装置は同じVPNにある数台のCE装置に接続しました、そして、また、それは異なったVPNsのCE装置に接続されるかもしれません。 PEが与えられたパケットの与えられた受信者IPアドレスに選ぶルートはパケットが受け取られたVPNによるでしょう。 したがって、PE装置には、それが付けている各VPNのための別々の推進テーブルがなければなりません。 私たちは「VPN推進例」(VFIs)セクション2.1で定義されるようにこれらの推進テーブルについて言及します。
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装置まで指示されるように。
Callon & Suzuki Informational [Page 52] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[52ページ]鈴木の情報のRFC4110
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.
別の方法はPE装置がCE装置のルーティング同輩であることを持つことです、リップ、OSPF、またはBGPなどのルーティング・アルゴリズムで。 展開シナリオによって、PEが、各CE(例えばPEがCEのVPNのリモートサイトから入手したすべてのルート)に多くのルートの広告を出す必要があるかもしれませんか、またはそれは、ただただ一つのデフォルトルートのCEに広告を出す必要があるかもしれません。
A PE device uses some resources in proportion to the number of VFIs that it has, particularly if a distinct dynamic routing protocol instance is associated with each VFI. A PE device also uses some resources in proportion to the total number of routes it supports, where the total number of routes includes all the routes in all its VFIs, and all the public routes. These scaling factors will limit the number of VPNs which a single PE device can support.
PE装置はそれが持っているVFIsの数に比例していくつかのリソースを使用します、特に異なったダイナミックルーティングプロトコル例が各VFIに関連しているなら。 また、PE装置はそれが支えるルートの総数に比例していくつかのリソースを使用します。そこでは、ルートの総数がすべてのVFIsのすべてのルート、およびすべての公共のルートを含んでいます。 これらのけた移動子は単一のPE装置が支持できるVPNsの数を制限するでしょう。
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がただ一つのルーティング・プロトコル例に関連しているのは、必ず事実であるというわけではありません。 ただ一つのルーティング・プロトコル例は複数のVFIsのためのルーティング情報を提供するかもしれません、そして、複数のルーティング・プロトコル例が独身の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ルートが以下で議論するようにどうPEsの間まで運ばれるかいくつかのオプションがあります。
4.4.3. Per-VPN Routing
4.4.3. 1VPNあたりのルート設定
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つのオプションはPEsの間のルーティング・プロトコルの別々の例、各VPNあたり1つの例を操作することです。 これが完了していると、それぞれの顧客ネットワークのためのルーティング・プロトコルパケットは、PEsの間でトンネルを堀られる必要があります。 これはPEsの間の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.
1VPNあたりのルーティングで、各VPNに対応する異なったルーティング例は対応するPE装置の中に存在しています。 VPN特有のトンネルはPE装置の間でセットアップされます(セクション3と4で議論した制御機構を使用して)。 PE装置の中にあるVFIsの間には、論理的に、これらのトンネルがあります。 その時がまるでそれらが正常なルータの間の正常なリンクであるかのように使用したトンネル。 各VPNのためのルーティング・プロトコルは顧客ネットワークの中でVFIsとルータの間で作動します。
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
このアプローチは、各VPNのためにVPN背骨の向こう側に作動しながら、異なった「制御飛行機」を設立します。 どんな2VPNsも制御飛行機について共有してはいけません、そして、コントロールのどんな平面であることの共有もありません。
Callon & Suzuki Informational [Page 53] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[53ページ]鈴木の情報のRFC4110
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ルーティングと公共のルーティング。 このアプローチで、複数の独立しているルータから成るとそれぞれの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.
このアプローチは、異なったVPNsと、VPNルーティングと公共のルーティングとの明白な相互作用を最小にする傾向があります。 しかしながら、独立している論理的なルータが同じハードウェアを共有する限り、いくつかのリソースの共有があります、そして、相互作用はまだ可能です。 また、それぞれの独立制御飛行機には、関連オーバーヘッドがあります、そして、これはスケールの問題を提起できます。 例えば、PE装置は、潜在的に多くの独立しているルーティング「決定の過程」を走らせなければならなくて、また、潜在的に非常に多くのルーティング隣接番組を維持しなければなりません。
4.4.4. Aggregated Routing Model
4.4.4. ルート設定モデルに集めます。
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.
別のオプションはVPNルーティング情報をPEsの間まで運ぶのにルーティング・プロトコルの1つのただ一つの例を使用することです。 この方法で、複数の異なったVPNsのためのルーティング情報はただ一つのルーティング・プロトコルに集められます。
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.
このアプローチはPEsが維持しなければならないルーティング隣接番組の数を大いに減少させます、与えられた組のPEsの間には、そのような隣接番組の1つ以上を維持する少しの必要ももうないので。 ただ一つのルーティング・プロトコルが階層的なルート分配メカニズム(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ルートを分配するのに使用されるのと同じプロトコル例を使用させるのによるさらなる結果の改良で(.2が、これをする方法に関して4.4に.4を区分するのを見る、)
Callon & Suzuki Informational [Page 54] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[54ページ]鈴木の情報のRFC4110
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装置の間のルーティングが静的であるならPE装置によって支持されたCEsかBGP-4の数に依存しません。 しかしながら、VPNのCEとPE装置はVPNの中でBGP-4以外のルーティング・プロトコルを使用することで経由地案内を交換して、PE装置のルーティング・プロトコル実体の数はPE装置によって支持されたCEsの数に依存します。
In principle it is possible for routing to be aggregated using either BGP or on an IGP.
原則として、それはBGPを使用することで集められるために掘るか、IGPの上で可能です。
4.4.4.1. Aggregated Routing with OSPF or IS-IS
4.4.4.1. または、OSPFとのルート設定に集合である、-
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.
VPNsを支持するとき、どんな与えられたSPネットワークの中でも支持された多くのVPNsがあることができそうです。 一般に、少ない数のPE装置だけがどんなVPNの操作にも興味を持つでしょう。 したがって、様々な顧客ネットワークに関連するルーティング情報の総量は非常に大きくなるでしょうが、どんなPEも、そのような少ない数のネットワークだけに関して知る必要があります。
Generally SP networks use OSPF or IS-IS for interior routing within the SP network. There are very good reasons for this choice, which are outside of the scope of this document.
または、一般にSPネットワークがOSPFを使用する、-、SPネットワークの中の内部のルーティングのために。 この選択の非常に十分な理由があります。(理由がこのドキュメントの範囲の外にあります)。
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、-、リンク州のルーティング・プロトコルはそうです。 リンク州のルーティングで、ルーティング情報は氾濫プロトコルで分配されます。 ルーティング同輩のセットは一般に完全に網の目にかけられるというわけではありませんが、セットにおけるどんなルータからいかなる他のも経路があります。 氾濫は、どんなルータからのルーティング情報もすべての他のものに届くのを確実にします。 これは、同じルーティング情報を保守するためにセットにおけるすべてのルータを必要とします。 川下では、より遠い同輩のだれもその情報を必要としないのは知られていない場合、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.
その結果、あるものがOSPFを使用することによって集められたルーティングをしようとするなら、ルーティング同輩のセットにおけるすべてのPEsと共に、すべてのPEsが全く同じルーティング情報で終わるでしょうに。 ルーティング情報の分配をPEsの部分集合に抑制する方法が全くありません。 合計の潜在的大きさを考えて、ルーティング情報が多くのVPNsを支持するのに必要であり、これは不幸なスケーリング意味を持っているでしょう。
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.
いくつかの場合、VPNsはプロバイダーの中で複数の領域にかかっているか、または複数のプロバイダーにかかるかもしれません。 VPNルーティング情報がプロバイダーの中で使用されたIGPに集められるなら、何らかの方法が、領域とSPsの間のIGPルーティング情報の範囲を広げるのに使用される必要があるでしょうに。
Callon & Suzuki Informational [Page 55] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[55ページ]鈴木の情報のRFC4110
4.4.4.2. Aggregated Routing with BGP
4.4.4.2. BGPとのルート設定に集めます。
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かVPNsに依存する属性を運びます。
When BGP is used for carrying VPN information, the total amount of information carried in BGP (including the Internet routes and VPN routes) may be quite large. As noted above, there may be a large number of VPNs which are supported by any particular provider, and the total amount of routing information associated with all VPNs may be quite large. However, any one PE will in general only need to be aware of a small number of VPNs. This implies that where VPN routing information is aggregated into BGP, it is desirable to be able to limit which VPN information is distributed to which PEs.
BGPがVPN情報を運ぶのに使用されるとき、BGP(インターネットルートとVPNルートを含んでいる)で運ばれた情報の総量はかなり大きいかもしれません。 上で述べたように、どんな特定のプロバイダーによっても支持される多くのVPNsがあるかもしれません、そして、すべてのVPNsに関連しているルーティング情報の総量はかなり大きいかもしれません。 しかしながら、一般に、どんなPEも、VPNsの少ない数を意識している必要があるだけでしょう。 これはどのVPN情報を制限できるかがどのPEsに分配されるかが、VPNルーティング情報がBGPに集められるのが望ましいところでそれを含意します。
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
「外のBGP」(EBGP)では、ルーティング同輩はルーティング情報を互いに再配付します。 しかしながら、ルーティング情報の特定の項目の分配を抑制するのが非常に一般的であるので、「知る必要性」を持っている外の同輩に行くだけです、これは経路が確実にどのアドレスにつながるかもしれない先験的な知識を必要としますが。 VPNがVPNが協力SPsの小さいセットがそのVPNに関連しているルーティング情報が何処にも分配されないのを保証するためにそのような規制を適用できるかどうかということであるなら掘る場合では、それはそうする必要はありません。 特定のVPNが個人的なじっと見るアレンジメントがある協力SPsの少ない数によって支持されるという範囲に、これはそうです。
Callon & Suzuki Informational [Page 56] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[56ページ]鈴木の情報のRFC4110
particularly straightforward, as the set of EBGP neighbors which need to know the routing information from a particular VPN is easier to determine.
特に簡単であることで、EBGP隣人のセットとして、どれが、特定のVPNからルーティング情報を知る必要があるかはより決定しやすいです。
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個のルート反射鏡でむしろいるのは、一般的です。 これはどんなルータも支持しなければならない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ルーティング情報があると既に述べられています。 スケーラビリティには、それは、どんな単一のルート反射鏡にもすべてのVPNsのためのすべてのルーティング情報がなければならないはずであるというわけではないのを保証するために同様に重要です。 それはVPNルート(SPによって支持されたすべてのVPNsの向こう側の)の総数が単一のルート反射鏡で支持できる数を超えるのにおいてすべて可能である後です。 したがって、自分たちが仕切られて、いくつかのルート反射鏡と共に運んで、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.
外国行きのルートフィルタの使用で、どんなPEとどんなルート反射鏡もPEとルート反射鏡がともに興味を持っているそれらのVPNsだけの周りで情報交換します。 これは、各PEとそれぞれのルート反射鏡がそれが直接支持しているVPNsだけのルーティング情報を受け取るのを順番に確実にします。 したがって、多くのVPNsを支持する大きいSPsはそれらのVPNsのサポートに必要である情報を仕切ることができます。
Callon & Suzuki Informational [Page 57] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[57ページ]鈴木の情報のRFC4110
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装置は多くのVPNsに付けることができるかもしれません。
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、そして/または、ルート反射鏡の中で仕切られる方法は展開問題です。 適当な展開手順で、これらの装置の収容数の限界は支持できるVPNsの数を制限しないでしょう。
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によって役立たれたVPNsのいくつかかすべてがインターネット・アクセスを必要としますが、PEがインターネットルートを含んでいないなら、PEはSPネットワークの中でそのPEから異なったルータまですべてのインターネットトラフィックを発送するデフォルトルートを維持できて、どこその他のルータ船倉完全インターネット・ルーティングはテーブルであるか。 このアプローチで、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 PE-CEルート分配に、VPNルートのPE-PE分配に使用されるのと同じBGPインスタンスを使用できます、CE-PEルーティングが静電気かBGPであるなら。 PEsとCEsは本当に異なったAutonomous Systemsの部分です、そして、BGPは特にAutonomous Systemsの間までルーティング情報を運ぶのに十分適しています。
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ルート分配は何らかの方法で公共のインターネットルートの分配に感染しません。 以下のセクションでこの問題について議論します。
Callon & Suzuki Informational [Page 58] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[58ページ]鈴木の情報のRFC4110
4.4.5. Scalability and Stability of Routing with Layer 3 PE-based VPNs
4.4.5. 層3のPEベースのVPNsとのルート設定のスケーラビリティと安定性
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サービスに使用される同じリンクの上のアクセスであるとサポートするケースがありそうです。 したがって、PEリンクへの特定のCEは個人的なネットワークIPパケット(VPNサービスを利用する私設のネットワークのサイトの間のトランスミッションのための)と公共のインターネットトラフィック(個人的なサイトからインターネット、インターネットからの個人的なサイトおよびへの伝送のためトランスミッションのための)の両方を運ぶかもしれません。 このセクションはこの場合ルーティングのスケーラビリティと安定性を見ます。 この種類の問題が1VPNあたりのルーティングが使用されているところで適切であるかもしれないことに注意するルーティングが集められるところで使用されているのと同じくらい十分価値があります。
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がVPNsと公共のインターネットの両方のためにルーティングに完全に参加するのは、望ましくないかもしれません。 例えば、複数のVPNsの向こう側に1PEによって支えられたルートとルーティングインスタンスの全容積が非常に大きいと仮定してください。 その上、私設のネットワークの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が維持する必要があるルーティングインスタンスの総数が非常に大きいかもしれないなら、多くのVPNsをサポートしているか、または大きいVPNsをサポートしているそれらのPEsのためにインターネット・ルーティングへの参加を制限するのも望ましいかもしれません。
Callon & Suzuki Informational [Page 59] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[59ページ]鈴木の情報のRFC4110
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がそれの或るものが多くのサイトを持っている多くのVPNsをサポートしているケースを考えてください。 非常に大きい例を選ぶために、それぞれ平均100のサイトがある1000VPNs、および1サイトあたり10の接頭語を平均的に思いましょう。 また、PEが、一般に、インターネットにトラフィックを発送できる必要であると考えてください。 この例では、PEはVPNsのためにおよそ100万の接頭語をサポートして、10万以上の接頭語をインターネットにサポートする必要があるかもしれません。 増大して、集められるならルーティングが使用されている、そして、これはただ一つのルーティング・プロトコル(たぶんBGP)の広告に掲載されるかもしれない多くのルートを含意します。 また、VRアプローチが使用されているなら、1VPNあたりの様々なルーティング・プロトコルインスタンスには10万の隣人隣接番組があります。 いくつかの場合この数のルーティング接頭語、そして/または、この数の隣接番組は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があって、CEデバイスがこれらのMであるなら合計Nグローバルにアドレス可能なインターネット・アドレス接頭語のための次のホップであるなら、PEデバイスはインターネット・アドレスをグローバルに発送可能するように対応しているのにN+1ルートを維持するでしょう。
In this example, those PE devices which provide VPN service run routing to compute routes for the VPNs, but don't operate Internet routing, and instead use only a default route to route traffic to all Internet destinations (not counting the addresses which are reachable via directly attached CE devices). The P routers need to maintain Internet routes, and therefore take part in Internet routing protocols. However, the P routers don't know anything about the VPN routes.
この例では、サービスをVPNに供給するそれらのPEデバイスはVPNsのためにルートを計算するためにルーティングを実行します、インターネット・ルーティングを操作して、すべてのインターネットの目的地にトラフィックを発送するのに代わりにデフォルトルートだけを使用しませんが(直接付属している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がサポートすることができるVPNsの数を制限するかもしれません。 例えば、いくつかの場合、これは、2台の異なったPEデバイスが複数のCEsの1セットのためにVPNにサービスをサポートするのに使用されるのを必要とするかもしれません、1PEにCEsのフルセットからのデータ通信量を扱うことができるくらいのスループットがあったかもしれないとしても。 同様に、どんなVPNも独身のPEで使用することが許可されているリソースの量は制限されるかもしれません。
Callon & Suzuki Informational [Page 60] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[60ページ]鈴木の情報のRFC4110
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.
確かに、この可能性は理論上存在しています。 別のもののその可能性、それのサポート複数のアドレスファミリーが1つのアドレスファミリーの処理と分配が処理に影響する度合いを最小にするために組織化されているべきであるBGP実装、および分配を最小にするために。 例えば、リソースの適当な仕切りでこれができるでしょう。 この仕切りは、VPNルーティングからインターネット・ルーティングをともに保護して、「誤の振る舞い」VPNsからよく振る舞っているVPN顧客を保護するために役立っているかもしれません。 または、ものは、VPNルーティングシステムから優先をインターネット・ルーティングに与えることによって、インターネット・ルーティングシステムを保護しようとするかもしれません。 このドキュメントの範囲の外にそのような導入問題があります。 1つに実装における不十分な信用があるなら、展開手順を用いることができます、VPNルーティングとインターネット・ルーティングを切り離すために上で説明されるように。
4.5. Quality of Service, SLAs, and IP Differentiated Services
4.5. サービスの質、SLA、およびIPはサービスを差別化しました。
The following technologies for QoS/SLA may be applicable to PPVPNs.
QoS/SLAのための以下の技術はPPVPNsに適切であるかもしれません。
4.5.1. IntServ/RSVP [RFC2205] [RFC2208] [RFC2210] [RFC2211] [RFC2212]
4.5.1. IntServ/RSVP[RFC2205][RFC2208][RFC2210][RFC2211][RFC2212]
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に写像されるかもしれません。
Callon & Suzuki Informational [Page 61] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[61ページ]鈴木の情報のRFC4110
4.5.2. DiffServ [RFC2474] [RFC2475]
4.5.2. DiffServ[RFC2474][RFC2475]
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ネットワークの中で等しく扱われます。 どんなユーザも彼らの配分を超えて、したがって、全体でクラスのための食糧を供給することを破るのを防ぐために入力で取り締まりをします。 ユーザがそれらのトラフィック契約を超えているなら、余分なパケットは、任意に捨てられるか、または「契約」のようにマークされるかもしれません。 ネットワーク中のルータは次に、混雑に対応して契約パケットの上で優先的に捨てられることができます、パケットが契約トラフィックで意図するサービス保証を破らないそのそのようなものを確実にするために。
4.6. Concurrent Access to VPNs and the Internet
4.6. VPNsへの同時発生のアクセスとインターネット
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アドレスは、ことによると私設のルーティング分野に属して、公共のインターネットでそういうものとして使用不可能になるでしょう。 これは、ネットワーク・アドレス翻訳機能(例えば、NAT)が、VPN顧客がPublicインターネットにアクセスするのを許容するために実装される必要を意味します。
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デバイス自体で実装されるでしょう。
Callon & Suzuki Informational [Page 62] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[62ページ]鈴木の情報のRFC4110
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ベースのVPNsの場合では、この機能が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デバイス)、あるいはまた、部分集合または1つのVPNネットワーク要素だけさえでの翻訳、そして/または、トラフィック分析機能を実装するのを選ぶことができます。 これは、インターネットからの/からどんなVPNサイトまでの/へのトラフィックも、そのただ一つのネットワーク要素を通して発送される必要を意味するでしょう(これはハブで起こって、例えばトポロジーを話したことです)。
4.7. Network and Customer Management of VPNs
4.7. VPNsのネットワークと顧客管理
4.7.1. Network and Customer Management
4.7.1. ネットワークと顧客管理
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
プロバイダーで食糧を供給されたVPNのどんなタイプにも、全体でVPNを見て、任意に対処できる1つの場所を持っているのは役に立ちます。 したがって、NMSはVPNの集合的なインスタンスがVPNを形成するために粘着性がある画像に集められる場所であるかもしれません。 to
Callon & Suzuki Informational [Page 63] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[63ページ]鈴木の情報のRFC4110
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を形成しません。 むしろ、一緒に異種のVPNサイトの収集はVPNを形成します。 VPNsが手動の構成か自動構成を通してネットワーク(すなわち、PEs)の縁で通常構成されるので、これは重要です。 これはネットワークの「コア」の中に閉じ込められない州の情報を全くもたらします。 他のPEsの情報はどんな特定のPEでもまず時々構成されません。
Support of any one VPN may span a wide range of network equipment, potentially including equipment from multiple implementors. Allowing a unified network management view of the VPN therefore is simplified through use of standard management interfaces and models. This will also facilitate customer self-managed (monitored) network devices or systems.
どんなVPNのサポートも潜在的に複数の作成者からの設備を含むさまざまなネットワーク装置にかかるかもしれません。 したがって、VPNの統一されたネットワークマネージメント視点を許容するのは標準の管理インタフェースとモデルの使用で簡素化されます。 また、これは顧客の自己によって管理された(モニターされる)ネットワークデバイスかシステムを容易にするでしょう。
In cases where significant configuration is required whenever a new service is provisioned, it is important for scalability reasons that the NMS provide a largely automated mechanism for this operation. Manual configuration of VPN services (i.e., new sites, or re-provisioning existing ones), could lead to scalability issues, and should be avoided. It is thus important for network operators to maintain visibility of the complete picture of the VPN through the NMS system. This must be achieved using standard protocols such as SNMP, XML, or LDAP. Use of proprietary command-line interfaces has the disadvantage that proprietary interfaces do not lend themselves to standard representations of managed objects.
新しいサービスに食糧を供給されるときはいつも、重要な構成が必要である場合では、スケーラビリティ理由で、NMSが主に自動化されたメカニズムをこの操作に提供するのは、重要です。 VPNの手動の構成は、(すなわち、新しいサイト、または再食糧を供給している既存のもの)を修理して、スケーラビリティ問題に通じることができて、避けられるべきです。 その結果、ネットワーク・オペレータがNMSシステムを通してVPNの完全な画像の目に見えることを維持するのは、重要です。 SNMP、XML、またはLDAPなどの標準プロトコルを使用することでこれを達成しなければなりません。 独占コマンドラインインタフェースの使用で、独占インタフェースがする不都合は管理オブジェクトの標準の表現に自分たちを与えません。
To achieve the goals outlined above for network and customer management, device implementors should employ standard management interfaces to expose the information required to manage VPNs. To this end, devices should utilize standards-based mechanisms such as SNMP, XML, or LDAP to achieve this goal.
ネットワークと顧客管理のために上に概説された目標を達成するなら、デバイス作成者は、VPNsを管理するのに必要である情報を暴露するのに標準の管理インタフェースを使うべきです。 このために、デバイスは、この目標を達成するのにSNMP、XML、またはLDAPなどの規格ベースのメカニズムを利用するはずです。
4.7.2. Segregated Access of VPN Information
4.7.2. VPN情報の隔離されたアクセス
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基礎単位で何人かの顧客(または、オペレータ)がaで特定のVPNの文脈の中でPEs、CEsまたはPデバイスにアクセスするのは、統計、構成または状態情報にアクセスするために重要です。 これは全般管理の外観、オペレータによって開始された食糧を供給すること、またはSLA検証(SP、顧客またはオペレータ)であることができます。
Callon & Suzuki Informational [Page 64] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[64ページ]鈴木の情報のRFC4110
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の検証エージェントを高度合いのセキュリティと便利に提供するために1VPNあたり1個のベースでアクセスしやすくなければなりません。
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.
セキュリティはネットワークマネージメント命令と情報の認証か暗号化を必要とするかもしれません。 情報隠蔽は、暗号化を使用するか、または1VPNあたりのアクセサリーを提供するメカニズムを通して情報を隔離するかもしれません。 デバイスの中の管理オブジェクトのための要求と応答の両方の認証か暗号化が使われるかもしれません。 どうこれを達成できるかに関する例はIPsecトンネル、SNMPを拠点とする管理のためのSNMPv3暗号化、またはCLIを拠点とする管理のための暗号化されたtelnetセッションを含んでいます。
In the case of information isolation, any one customer should only be able to view information pertaining to its own VPN or VPNs. Information isolation can also be used to partition the space of managed objects on a device in such a way as to make it more convenient for the SP to manage the device. In certain deployments, it is also important for the SP to have access to information pertaining to all VPNs, thus it may be important for the SP to create virtual VPNs within the management domain which overlap across existing VPNs.
情報分離の場合では、どんな顧客もそれ自身のVPNかVPNsに関係する情報を見ることができるだけであるべきです。 また、管理オブジェクトのスペースをデバイスにSPがデバイスを管理するのをより便利にするほどそのような方法で仕切るのに情報分離を使用できます。 また、ある展開では、SPがすべてのVPNsに関係する情報に近づく手段を持っているのも、重要である、その結果、SPが管理ドメインの中の既存のVPNsの向こう側に重なる仮想のVPNsを作成するのは、重要であるかもしれません。
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を引き起こす、誤、振る舞い これは、何が支障をきたしたかに関する決断と原因についてキャリヤーに知らせる何らかの方法を許容するために順番に監査証跡を必要とするかもしれません。
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.
また、キャリヤーのパラダイムのキャリヤーが採用しているとき、1VPNあたり1個のベースにおける情報の隔離とセキュリティアクセスも重要です。 この場合、管理する顧客(すなわち、サブキャリヤーかVPN卸売業者)と支給サービスに、それは、管理間接費をキャリヤーのSPのキャリヤーに変えるために彼らのそれぞれのデバイスでそれらのVPNsの中で望ましいかもしれません。 この場合、上で情報隠蔽、分離、および暗号化に関して詳細なガイドラインを守るのは重要です。 情報隠蔽の多くの風味とキャリヤーのSPのキャリヤーによって使われた分離があるかもしれないことに注意されるべきです。 キャリヤーSPのキャリヤーがそれらのPEsかPルータの中で管理オブジェクトのすべてへのサブキャリヤー開架を承諾したくないなら、デバイスが彼らのデバイスへの1VPNあたりの安全でスケーラブルなネットワークマネージメントアクセスをネットワーク・オペレータに提供するのが必要です。 上に概説された理由で、したがって、これらの目標を達成するのに標準のメカニズムを提供するのは望ましいです。
Callon & Suzuki Informational [Page 65] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[65ページ]鈴木の情報のRFC4110
5. Interworking Interface
5. インタフェースを織り込みます。
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ネットワークの間のインタフェースに起こるかもしれません。
5.1. Interworking Function
5.1. 織り込む機能
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.
層の3VPNsと共に、PEデバイスがそう、一般に、3つのルータを層にして、1つ以上の私設のネットワークを代表した3つのパケットが前方で層にされることができます。 例えば、層が3VPNsであるとサポートするPEデバイスに、複数の論理的なVFIsを含むのが一般的であるかもしれない、(セクション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は、層が3VPNsであるとサポートするための複数のアプローチの操作における正常な方法に参加する必要があります。 これはほかの場所で本書では議論したVPN設立やメインテナンスなどの機能、VPNsのために掘られる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によってサポートされたすべてのシステムを包括するのは織り込む機能の反対側に場所を見つけられました)。
5.2. Interworking Interface
5.2. インタフェースを織り込みます。
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つの層の3VPNアプローチの操作に参加します。 アプローチの間の織り込むのはVPNのトンネルがセットアップする使用をPEにします。 各PEsは、まるでそれが正常なPEsであるかのように作動して、それぞれのトンネルが特定のVPNに関連していると考えます。
Callon & Suzuki Informational [Page 66] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[66ページ]鈴木の情報のRFC4110
Information can then be transmitted over the interworking interface in the same manner that it is transmitted over a CE to PE interface.
そしてときに情報はそれが伝えられるのと同じ方法で織り込むインタフェースの上に伝えられて、PEへのa CEが連結するということであるかもしれません。
In some cases establishment of the interworking interfaces may require manual configuration, for example to allow each PE to determine which tunnels should be set up, and which private network is associated with each tunnel.
いくつかの場合、織り込むインタフェースの設立は、例えば各PEがどのトンネルが設立されるべきであるか、そして、どの私設のネットワークが各トンネルに関連しているかを決定するのを許容するために手動の構成を必要とするかもしれません。
5.2.1. Tunnels at the Interworking Interface
5.2.1. 織り込むことにおけるトンネルは連結します。
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.
1PPVPNのわたることをサポートするための2つのSPネットワークの間の織り込むインタフェースが両方の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に関連している)によって終えられます。 このシナリオはInterworking Interfaceによってサポートされて、複数のSPネットワークにかかるPPVPNsのためのトラフィック分離の実装をもたらします(それぞれのSPネットワークには、両側が異なった技術を採用できるようにPPVPNを提供するための応用技術に制限が全くありません)。 PEベースのVPNのためのそれぞれのトンネルの課題の方法はPEデバイスのトンネルとインタコネクトされるSPネットワークによって使用された実装技術に特定です。
The identifier of layer 3 PE-based VPN at each end is meaningful only in the context of the specific technology of an SP network and need not be understood by another SP network interworking through the tunnel.
各端の層3のPEベースのVPNに関する識別子は、SPネットワークの独自技術の文脈だけで重要であり、トンネルを通って別のSPネットワークの織り込むのに解釈される必要はありません。
The following tunneling mechanisms may be used at the interworking interface. Available tunneling mechanisms include (but are not limited to): GRE, IP-in-IP, IP over ATM, IP over FR, IPsec, and MPLS.
以下のトンネリングメカニズムは織り込むインタフェースで使用されるかもしれません。 しかし、利用可能なトンネリングメカニズムが含んでいる、(制限されない、)、: GRE、IPにおけるIP、気圧でのIP、FRの上のIP、IPsec、およびMPLS。
o GRE
o GRE
The tunnels at interworking interface may be provided by GRE
[RFC2784] with key and sequence number extensions [RFC2890].
インタフェースを織り込むところのトンネルはGRE[RFC2784]によってキーと一連番号拡大[RFC2890]に提供されるかもしれません。
Callon & Suzuki Informational [Page 67] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[67ページ]鈴木の情報のRFC4110
o IP-in-IP
o IPにおけるIP
The tunnels at interworking interface may be provided by IP-in-IP
[RFC2003] [RFC2473].
インタフェースを織り込むところのトンネルはIPにおけるIP[RFC2003][RFC2473]によって提供されるかもしれません。
o IP over ATM AAL5
o 気圧AAL5の上のIP
The tunnels at interworking interface may be provided by IP over
ATM AAL5 [RFC2684] [RFC2685].
インタフェースを織り込むところのトンネルはIPによってATM AAL5[RFC2684][RFC2685]の上に提供されるかもしれません。
o IP over FR
o FRの上のIP
The tunnels at interworking interface may be provided by IP over
FR.
インタフェースを織り込むところのトンネルはIPによってFRの上に提供されるかもしれません。
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]によって提供されるかもしれません。
5.3. Support of Additional Services
5.3. 追加サービスのサポート
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.
この小区分は層3のサービスとして複数のSPネットワークにかかる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.
セクション4.3.6と4.5でGRE、IPにおけるIP、IPsec、およびMPLSトンネルへのQoS/SLA管理メカニズムについて議論しました。 詳細に関してこれらのセクションを見てください。 FRとATMはQoS保証ができます。 したがって、また、QoS/SLAは織り込むインタフェースでサポートされるかもしれません。
o Customer visible routing
o 顧客の目に見えるルーティング
As described in section 3.3, customer visible routing enables the
exchange of unicast routing information between customer sites
using a routing protocol such as OSPF, IS-IS, RIP, and BGP-4. On
the interworking interface, routing packets, such as OSPF packets,
are transmitted through a tunnel associated with a layer 3 PE-based
VPN in the same manner as that for user data packets within the
VPN.
顧客の目に見えるルーティングがセクション3.3で説明されるようにOSPFなどのルーティング・プロトコルを使用することで顧客サイトの間のユニキャストルーティング情報の交換を可能にする、-、RIP、およびBGP-4。 織り込むインタフェースでは、OSPFパケットなどのルーティングパケットはVPNの中のユーザデータ・パケットのためのそれと同じ方法で3のPEベースのVPN層に関連しているトンネルを通して送られます。
Callon & Suzuki Informational [Page 68] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[68ページ]鈴木の情報のRFC4110
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層の中でマルチキャスト木の工事を可能にします。
5.4. Scalability Discussion
5.4. スケーラビリティ議論
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ベースのVPNsは同じです。 しかしながら、PEデバイスの層の3のPEベースのVPNsの数は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は暗号化/復号化のためのコンピュータの要件を置きます。
6. Security Considerations
6. セキュリティ問題
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.
セキュリティはVPNsに関する主要な要件の1つです。 ネットワーク環境で、用語セキュリティは現在、まもなく今後議論する中でそれでネットワーク見解からのもの最も重要である多くの異なった局面をカバーします。
Note that the Provider-Provisioned VPN requirements document explains the different security requirements for Provider-Provisioned VPNs in more detail.
Providerによって食糧を供給されたVPN要件ドキュメントでさらに詳細にProviderによって食糧を供給されたVPNsのための異なったセキュリティ要件がわかることに注意してください。
Callon & Suzuki Informational [Page 69] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[69ページ]鈴木の情報のRFC4110
6.1. System Security
6.1. システムセキュリティ
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はそのネットワーク要素とマネージメントシステムのシステムセキュリティを確実にしなければなりません。
6.2. Access Control
6.2. アクセス制御
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ベースのVPNsの文脈では、VPNへのアクセスポイントをSPによって知られているインタフェースに制限しなければなりません。
6.3. Endpoint Authentication
6.3. 終点認証
When one receives data from a certain entity, one would like to be sure of the identity of the sending party. One would like to be sure that the sending entity is indeed whom he or she claims to be, and that the sending entity is authorized to reach a particular destination.
人が、ある実体からデータを受け取るとき、1つは送付パーティーのアイデンティティが確かになりたがっています。 1つは送付実体が本当に、その人が、だれを主張するかということであり、送付実体が特定の目的地に達するのが認可されるのを確信するようになりたがっています。
In the context of layer 3 PE-based VPNs, both the data received by the PEs from the customer sites via the SP network and destined for a customer site should be authenticated.
層の3のPEベースのVPNsの文脈では、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
層の3のPEベースのVPNsにおいて、VPNトラフィックはPEからPEまでトンネルを堀られます、そして、VPNトンネル終点は伝えられたパケットの発生源をチェックするでしょう。 MPLSがVPNトンネリング、トンネル終点に使用されるとき
Callon & Suzuki Informational [Page 70] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[70ページ]鈴木の情報のRFC4110
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.
正しいラベルが使用されているかどうかチェックします。 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デバイスによって励行されます。
6.4. Data Integrity
6.4. データの保全
When information is exchanged over a certain part of a network, one would like to be sure that the information that is received by the receiving party of the exchange is identical to the information that was sent by the sending party of the exchange.
情報をネットワークのある部分の上交換するとき、1つは交換の受領者によって受け取られる情報が交換の送付パーティーによって送られた情報と同じであることを確信するようになりたがっています。
In the context of layer 3 PE-based VPNs, the SP assures the data integrity by ensuring the system security of every network element. Alternatively, explicit mechanisms may be implemented in the used tunneling technique (e.g., IPsec).
層の3のPEベースの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ベースのVPNsの文脈では、カプセル化されたパケットにトンネルを堀る基本的なネットワークはいつも自然に信じられてなるというわけではないでしょう、そして、また、トンネリングに原因となるCEデバイスはデータ保全を確実にするでしょう、例えば、IPsecアーキテクチャを利用することによって。
6.5. Confidentiality
6.5. 秘密性
One would like that the information that is being sent from one party to another is not received and not readable by other parties. With traffic flow confidentiality one would like that even the characteristics of the information sent is hidden from third parties. Data privacy is the confidentiality of the user data.
あるパーティーから別のものに送られる情報は同類ですが、1は相手で受け取られていて読み込み可能でない状態でそうするでしょう。 1つが必要とする交通の流れ秘密性で、第三者情報の特性さえ発信したのを隠されます。 データプライバシーは利用者データの秘密性です。
In the context of PPVPNs, confidentiality is often seen as the basic service offered, as the functionalities of a private network are offered over a shared infrastructure.
PPVPNsの文脈では、秘密性はしばしば私設のネットワークの機能性を共有されたインフラストラクチャの上に提供するので提供された基本サービスと考えられます。
In the context of layer 3 PE-based VPNs, as the SP network (and more precisely the PE devices) participates in the routing and forwarding of the customer VPN data, it is the SP's responsibility to ensure confidentiality. The technique used in PE-based VPN solutions is the ensuring of PE to PE data separation. By implementing VFI's in the PE devices and by tunneling VPN packets through the shared network infrastructure between PE devices, the VPN data is always kept in a separate context and thus separated from the other data.
層の3のPEベースのVPNsの文脈では、SPネットワーク(そして、より正確にPEデバイス)が顧客VPNデータのルーティングと推進に参加するとき、秘密性を確実にするのは、SPの責任です。 PEベースのVPNソリューションに使用されるテクニックはPEデータ分離へのPEを確実にすることです。 PEデバイスでVFIを実装して、PEデバイスの間の共用回線網インフラストラクチャを通してVPNパケットにトンネルを堀ることによって、VPNデータは、別々の関係にいつも保たれて、他のデータとこのようにして切り離されます。
Callon & Suzuki Informational [Page 71] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[71ページ]鈴木の情報のRFC4110
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ベースのVPNsのために、SPネットワークは秘密性保証への責任を剥き出しません、SPがただIPの接続性を提供するとき。 秘密性は、次に、CEで実施されて、CEデバイスでトンネリング(データ分離)か暗号の暗号化(例えば、IPsecを使用する)で横たわるでしょう。
Note that for very sensitive user data (e.g., used in banking operations) the VPN customer may not outsource his data privacy enforcement to a trusted SP. In those situations, PE-to-PE confidentiality will not be sufficient and end-to-end cryptographic encryption will be implemented by the VPN customer on its own private equipment (e.g., using CE-based VPN technologies or cryptographic encryption over the provided VPN connectivity).
非常に機密の利用者データ(例えば、銀行業務に使用される)に関して、VPN顧客が彼のデータプライバシー実施を信じられたSPに社外調達しないかもしれないことに注意してください。 それらの状況で、PEからPEへの秘密性は十分ではありません、そして、終わりから終わりへの暗号の暗号化はそれ自身の個人的な設備(例えば、提供されたVPNの接続性の上のCEベースのVPN技術か暗号の暗号化を使用する)の上でVPN顧客によって実装されるでしょう。
6.6. User Data and Control Data
6.6. 利用者データと制御データ
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デバイスを構成するのに使用される(層の3のプロバイダーで食糧を供給されたCEベースのVPNsの文脈で)VPNトンネルを設立していた)が、プロバイダーで食糧を供給されたVPNsの慎重なmisconfigurationを防ぐためにSPによって確保されるでしょう。
6.7. Security Considerations for Inter-SP VPNs
6.7. 相互SP VPNsのためのセキュリティ問題
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.
もう1ポイントはかかわったSPsが異なったSPsに接続されたVPNネットワーク要素(VFIs、PEs、CEデバイスなどの)に関する闘争設定情報を避けるために密接に相互作用しなければならないということです。
Callon & Suzuki Informational [Page 72] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[72ページ]鈴木の情報のRFC4110
Appendix A: Optimizations for Tunnel Forwarding
付録A: トンネル推進のための最適化
A.1. Header Lookups in the VFIs
A.1。 VFIsのヘッダールックアップ
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ベースのVPNsが最も正直な態度で実装されるなら、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の中のVFIsの間でセットアップされるかもしれません。 パケットが出口PEに到着するとき、PEは、パケットがどのVFIに属すかを決定するために外側のヘッダーでルックアップをする必要があるかもしれません。 次に、PEは、VPNトンネルの向こう側にカプセルに入れられたパケットで2番目のルックアップをする必要があるかもしれません、そのVPNに特定の推進テーブルを使用して、パケットを進める前に。
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.
これは、最も簡単な実装threeヘッダールックアップにおけるそれが単一のPEデバイスで必要であるかもしれないことを含意します: 1つのルックアップが、これがVPNトンネルの端であることを特定するかもしれません(関連ヘッダーを全部はぎ取る必要性を含意して)。 2番目のルックアップは、これがVPN特有のトンネルの端であることを特定するかもしれません。 このルックアップは、2番目の要約のヘッダーを全部はぎ取るようになって、最終的なルックアップのためにVFI文脈を特定するでしょう。 最後のルックアップは、VPNに関連しているIPアドレス空間を利用して、正しいVPNの中の正しいCEに送られるパケットをもたらすでしょう。
A.2. Penultimate Hop Popping for MPLS
A.2。 MPLSのために飛び出す終わりから二番目のホップ
Penultimate hop popping is an optimization which is described in the MPLS architecture document [RFC3031].
終わりから二番目のホップの飛び出しはMPLSアーキテクチャドキュメント[RFC3031]で説明される最適化です。
Consider the egress node of any MPLS LSP. The node looks at the label, and discovers that it is the last node. It then strips off the label header, and looks at the next header in the packet (which may be an IP header, or which may have another MPLS header in the case that hierarchical nesting of LSPs is used). For the last node on the LSP, the outer MPLS header doesn't actually convey any useful information (except for one situation discussed below).
どんなMPLS LSPの出口ノードも考えてください。 ノードは、ラベルを見て、それが最後のノードであると発見します。 それは、次に、ラベルヘッダーを全部はぎ取って、パケットの次のヘッダーを見ます(IPヘッダーであるかもしれないかLSPsの階層的な巣篭もりが使用されていて、別のMPLSヘッダーがあるかもしれません)。 LSPの上の最後のノードに関しては、外側のMPLSヘッダーは実際に、少しの役に立つ情報(以下で議論した1つの状況を除いた)も伝えません。
Callon & Suzuki Informational [Page 73] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[73ページ]鈴木の情報のRFC4110
For this reason, the MPLS standards allow the egress node to request that the penultimate node strip the MPLS header. If requested, this implies that the penultimate node does not have a valid label for the LSP, and must strip the MPLS header. In this case, the egress node receives the packet with the corresponding MPLS header already stripped, and can forward the packet properly without needing to strip the header for the LSP which ends at that egress node.
この理由で、MPLS規格で、出口ノードは、終わりから二番目のノードがMPLSヘッダーを裸にするよう要求できます。 要求されるなら、これは、終わりから二番目のノードがLSPに、有効なラベルを持たないで、MPLSヘッダーを裸にしなければならないのを含意します。 この場合、その出口ノードで終わるLSPのためにヘッダーを裸にする必要はなくて、出口ノードは、既に対応するMPLSヘッダーを裸にしていてパケットを受けて、適切にパケットを進めることができます。
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ヘッダーが役に立つ情報を伝えるある場合があります: VPN特有のLSPがPEデバイスで終わる場合にはこれがあります。 この場合、ラベルの値は、パケットがどの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特有のLSPsが1PEからPE LSPの中で多重送信されるケースを考えてください。 また、この場合出口PEがそのPEの文脈で特有になるように、すべての入って来るラベル(すべてのLSPsのための)を選んだと思いましょう。 これは、PEからPE LSPに関連しているラベルが出口ノードによって必要とされないのを含意します。 むしろ、それは、VPN特有のLSPに基づいてどのVFIを使用したらよいかを決定できます。 この場合、出口PEは、終わりから二番目のLSRがPEからPE LSPのために飛び出す終わりから二番目のラベルを実行するよう要求できます。 これは出口LSRの1つのヘッダールックアップを排除します。
Note that penultimate node label popping is only applicable for VPN standards which use multiple levels of LSPs. Even in this case penultimate node label popping is only done when the egress node specifically requests it from the penultimate node.
LSPsの複数のレベルを使用するVPN規格だけに、終わりから二番目のノードラベルの飛び出しが適切であることに注意してください。 この場合さえ、出口ノードが終わりから二番目のノードからそれを明確に要求すると、終わりから二番目のノードラベルの飛び出しをするだけです。
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup
A.3。 トンネル出口VFIルックアップを排除する逆多重化
Consider a VPN standard which makes use of MPLS as the tunneling mechanism. Any standard for encapsulating VPN traffic inside LSPs needs to specify what degree of granularity is available in terms of the manner in which user data traffic is assigned to LSPs. In other words, for any given LSP, the ingress or egress PE device needs to know which LSPs need to be set up, and the ingress PE needs to know which set of VPN packets are allowed to be mapped to any particular LSP.
トンネリングメカニズムとしてMPLSを利用するVPN規格を考えてください。 LSPsの中でVPNがトラフィックであるとカプセル化するどんな規格も、どの度合いの粒状がユーザデータ通信量がLSPsに割り当てられる方法で利用可能であるかを指定する必要があります。 言い換えれば、どんな与えられたLSPにも、イングレスか出口PEデバイスが、どのLSPsが、セットアップされる必要であるかを知る必要があります、そして、イングレス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規格がパケットのマッピングに関して何らかの柔軟性をLSPsに許容すると仮定してください、そして、出口ノードが規格で粒状を決定できると仮定してください。 この場合、出口ノードはイングレスノードに粒状を示す何らかの方法を必要とするでしょう、イングレスノードが、どのパケットを各LSPに写像できるかを知るように。
Callon & Suzuki Informational [Page 74] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[74ページ]鈴木の情報のRFC4110
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).
この場合、出口ノードは、パケットをLSPsに出口ノードにおけるヘッダールックアップ機能を簡素化する方法で写像させると決めるかもしれません。 例えば、出口ノードは、それが特定の隣人CEデバイスにどのセットのパケットを送るかを決定するかもしれません。 そして、出口ノードは、特定のLSPを使用することになっているIPパケットのセットがその特定のセットのパケットに対応すると指定できます。 指定されたLSPで到着するパケットのために、出口ノードはVPNの顧客アドレス空間でヘッダールックアップをする必要はありません: それは、MPLSヘッダーをただ飛び出させて、適切なCEデバイスにパケットを送ることができます。 すべてのLSPsがそれに従って、セットアップされるなら、出口ノードはLSPsで他のPEsから到着するVPNトラフィックのためにどんなルックアップもする必要はありません(言い換えれば、PEデバイスは出口ノードとして役割における2番目のルックアップをする必要はないでしょう)。
Note that PE devices will most likely also be an ingress routers for traffic going in the other direction. The PE device will need to do an address lookup in the customer network's address space in its role as an ingress node. However, in this direction the PE still needs to do only a single header lookup.
また、PEデバイスがもう片方の方向を調べるトラフィックのためにたぶんイングレスルータになることに注意してください。 PEデバイスは、イングレスノードとして役割における顧客ネットワークのアドレス空間におけるアドレスルックアップをする必要があるでしょう。 しかしながら、この方向に、PEは、まだただ一つのヘッダールックアップだけをする必要があります。
When used with MPLS tunnels, this optional optimization reduces the need for header lookups, at the cost of possibly increasing the number of label values which need to be assigned (since one label would need to be assigned for each next-hop CE device, rather than just one label for every VFI).
MPLSトンネルと共に使用されると、この任意の最適化はヘッダールックアップの必要性を減少させます、ことによると割り当てられる必要があるラベル値の数を増強する費用で(1個のラベルが、各VFIあたりちょうど1個のラベルよりむしろそれぞれの次のホップCEデバイスのために割り当てられる必要があるでしょう、したがって)。
The same approach is also possible when other encapsulations are used, such as GRE [RFC2784] [RFC2890], IP-in-IP [RFC2003] [RFC2473], or IPsec [RFC2401] [RFC2402]. This requires that distinct values are used for the multiplexing field in the tunneling protocol. See section 4.3.2 for detail.
また、他のカプセル化がGRE[RFC2784][RFC2890]、IPにおけるIP[RFC2003][RFC2473]、またはIPsec[RFC2401][RFC2402]などのように使用されるとき、同じアプローチも可能です。 これは、異なった値がトンネリングプロトコルのマルチプレクシング分野に使用されるのを必要とします。 詳細に関してセクション4.3.2を見てください。
Acknowledgments
承認
This document is output of the framework document design team of the PPVPN WG. The members of the design team are listed in the "contributors" and "author's addresses" sections below.
このドキュメントはPPVPN WGのフレームワークドキュメントデザインチームの出力です。 デザインチームのメンバーは下の「貢献者」と「作者のアドレス」セクションで記載されています。
However, sources of this document are based on various inputs from colleagues of authors and contributors. We would like to thank Junichi Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano, Naoto Makinae, Kenichi Kitami, Rajesh Balay, Anoop Ghanwani, Harpreet Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and Abbie Matthews.
しかしながら、このドキュメントの源は作者の同僚からの様々な入力と貢献者に基づいています。 Junichi Sumimoto、鈴木湖西、Hiroshi Kurakami、浜野岳文、Naoto Makinae、北見健一、ラジェッシュBalay、Harpreet Chadhaの、そして、Samirジャイナ教のAnoop Ghanwani、Lianghwa Jou、ビジェイ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.
また、彼らの貴重なコメントと提案についてヤコフRekhter、スコット・ブラドナー、デーヴMcDysan、マルコCarugi、Pascalメネゼス、トーマス・ナドー、およびアレックス・ジニンに感謝申し上げます。
Callon & Suzuki Informational [Page 75] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[75ページ]鈴木の情報のRFC4110
Normative References
引用規格
[PPVPN-REQ] Nagarajan, A., Ed., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
[PPVPN-REQ] Nagarajan、A.、エド、「プロバイダーの食糧を供給された仮想私設網(PPVPN)のためのジェネリック要件」、RFC3809、6月2004日
[L3VPN-REQ] Carugi, M., Ed. and D. McDysan, Ed., "Service
Requirements for Layer 3 Provider Provisioned Virtual
Private Networks (PPVPNs)", RFC 4031, April 2005.
エド[L3VPN-REQ]Carugi、M.、D.McDysan、エド、「層3のプロバイダーのためのサービス要件は仮想私設網(PPVPNs)に食糧を供給しました」、RFC4031、4月2005
Informative References
有益な参照
[BGP-COM] Sangli, S., et al., "BGP Extended Communities
Attribute", Work In Progress, February 2005.
[BGP-COM] サーングリ、S.、他、「BGPは共同体属性を広げた」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.、エド、「サポートのための拡大について議定書の中で述べる、Differentiatedサービス意識する、MPLS Traffic Engineering、」、Work In Progress、12月2004日
[VPN-2547BIS] Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.
[VPN-2547BIS]ローゼン、E.、他、「BGP/MPLS VPNs」Work In Progress。
[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] 2005年5月のローゼン、E.、他、「BGP/MPLS IP VPNsのためのプロバイダー/顧客縁のプロトコルとしてのOSPF」Work In Progress。
[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.、他、「IPsecを使用することでプロバイダーのためのアーキテクチャはCeベースの仮想私設網に食糧を供給した」Work In Progress。
[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]オールド-Brahim、H.、他、「層-3と層-2VPNsに自動発見メカニズムとしてBGPを使用します」、Work In Progress。
[VPN-L2] Andersson, L. and E. Rosen, Eds., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", Work In
Progress.
[VPN-L2] アンデションとL.とE.ローゼン、Eds、「層2の仮想私設網(L2VPNs)のためのフレームワーク」、処理中の作業。
[VPN-VR] Knight, P., et al., "Network based IP VPN Architecture
Using Virtual Routers", Work In Progress, July 2002.
[VPN-VR] 2002年7月のナイト、P.、他、「ネットワークのベースのIP VPN Architecture Using Virtual Routers」Work In Progress。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP
and Dual Environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「OSIの使用、-、TCP/IPにおけるルート設定と二元的な環境、」、RFC1195、12月1990日
Callon & Suzuki Informational [Page 76] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[76ページ]鈴木の情報のRFC4110
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC1966] Bates, T., "BGP Route Reflection: An alternative to
full mesh IBGP", RFC 1966, June 1996.
[RFC1966]ベイツ、T.、「BGPは反射を発送します」。 「完全なメッシュIBGPへの代替手段」、RFC1966、1996年6月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, February 2001.
[RFC1997] チャンドラとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、2001年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S.,
O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
"Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on
Deployment", RFC 2208, September 1997.
[RFC2208]マンキン、A.(エド)、ベイカー、F.、ブレーデン、B.、ブラドナー、S.、オデル、M.、Romanow、A.、Weinrib、A.、およびL.チャン、「資源予約がバージョン1つの(RSVP)適用性証明についていくつか議定書の中で述べる、展開に関するガイドライン、」、RFC2208(1997年9月)
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
1997年9月の[RFC2212]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC2207] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
Callon & Suzuki Informational [Page 77] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1フレームワークあたり[77ページ]鈴木の情報のRFC4110
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1994.
[RFC2453] マルキン、G.は「1994年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2473] コンタとA.とS.デアリング、「IPv6仕様によるジェネリックパケットトンネリング」、RFC2473、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475]ブレークとS.とBlackとD.とカールソンとM.とデイヴィースとE.とワング、Z.とW.ウィス、「Differentiated Servicesのための構造」RFC2475(1998年12月)。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] HeinanenとJ.とベイカーとF.とウィス、W.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
'L2TP'", RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル'L2TP'にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation Over ATM Adaptation Layer 5", RFC 2684,
September 1999.
[RFC2684] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[RFC2685] Fox B. and B. Gleeson, "Virtual Private Networks
Identifier," RFC 2685, September 1999.
[RFC2685] フォックスB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
2000年1月の[RFC2746]TerzisとA.とKrawczykとJ.とWroclawski、J.とL.チャン、「IP Tunnelsの上のRSVP操作」RFC2746。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
A. Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000.
[RFC2764] グリーソン、B.、リン、A.、Heinanen、J.、アーミテージ、G.、およびA.Malis、「IPのための枠組みは仮想私設網を基礎づけました」、RFC2764、2000年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
Callon & Suzuki Informational [Page 78] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[78ページ]鈴木の情報のRFC4110
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to
GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年9月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3032] Rosen E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼンE.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using
LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035] デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、G.、Rekhter、Y.、およびP.Doolan、「自由民主党と気圧VCの切り換えを使用するMPLS」、RFC3035(2001年1月)。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, June 1996.
1996年6月の[RFC3065]TrainaとP.とマクファーソン、D.とJ.Scudder、「BGPのための自律システム同盟者」RFC3065。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V.,
and D. Stiliadis, "An Expedited Forwarding PHB (Per-
Hop Behavior)", RFC 3246, March 2002.
[RFC3246] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.R.、ベンソン、K.、Le Boudec、J.Y.、コートニー、W.、Davari、S.、Firoiu、V.、およびD.Stiliadis、「完全優先転送PHB、(-、ホップの振舞い)、」、RFC3246(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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory
Access Protocol (v3): Technical Specification", RFC
3377, September 2002.
[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。
Callon & Suzuki Informational [Page 79] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[79ページ]鈴木の情報のRFC4110
Contributors' Addresses
貢献者のアドレス
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium
ジェレミーDe ClercqアルカテルFr。 Wellesplein1、2018アントウェルペン(ベルギー)
EMail: jeremy.de_clercq@alcatel.be
メール: jeremy.de_clercq@alcatel.be
Bryan Gleeson Nokia 313 Fairchild Drive, Mountain View, CA 94043 USA.
ブライアングリーソンノキア313フェアチャイルドDrive、マウンテンビュー、カリフォルニア94043米国。
EMail: bryan.gleeson@nokia.com
メール: bryan.gleeson@nokia.com
Andrew G. Malis Tellabs 90 Rio Robles Drive San Jose, CA 95134 USA
アンドリューG.Malis Tellabs90リオロブレス・Driveカリフォルニア95134サンノゼ(米国)
EMail: andy.malis@tellabs.com
メール: andy.malis@tellabs.com
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886, USA
Karthik Muthukrishnanルーセントテクノロジーズ1ロビンス・Roadウェストフォード、MA 01886、米国
EMail: mkarthik@lucent.com
メール: mkarthik@lucent.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719, USA
Boxborough、MA 01719、エリックC.ローゼンシスコシステムズInc.1414米国マサチューセッツ通り
EMail: erosen@cisco.com
メール: erosen@cisco.com
Chandru Sargor Redback Networks 300 Holger Way San Jose, CA 95134, USA
オルガーWayサンノゼ(カリフォルニア)95134、Chandru Sargor20ドル紙幣ネットワーク300米国
EMail: apricot+l3vpn@redback.com
メール: アプリコット+ l3vpn@redback.com
Callon & Suzuki Informational [Page 80] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[80ページ]鈴木の情報のRFC4110
Jieyun Jessica Yu University of California, Irvine 5201 California Ave., Suite 150, Irvine, CA, 92697 USA
Jieyunジェシカユーカリフォルニア大学アーバイン校5201カリフォルニアAve、スイート150、アーバイン、カリフォルニア92697米国
EMail: jyy@uci.edu
メール: jyy@uci.edu
Authors' Addresses
作者のアドレス
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146, USA
技術公園Driveウェストフォード、ロスCallon杜松ネットワーク10MA01886-3146(米国)
EMail: rcallon@juniper.net
メール: rcallon@juniper.net
Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
プラットホーム研究室を共有するMuneyoshi鈴木NTT情報。 3 9-11テロ、美土里町、武蔵野市、東京180-8585(日本)
EMail: suzuki.muneyoshi@lab.ntt.co.jp
メール: suzuki.muneyoshi@lab.ntt.co.jp
Callon & Suzuki Informational [Page 81] RFC 4110 A Framework for L3 PPVPNs July 2005
L3 PPVPNs2005年7月のためのCallonと1枠組みあたり[81ページ]鈴木の情報のRFC4110
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet gement
RFC Editor機能のための基金は現在、インターネットgementによって提供されます。
Callon & Suzuki Informational [Page 82]
Callonと鈴木Informationalです。[82ページ]
一覧
スポンサーリンク
