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