Network Working Group M. Carugi, Ed.
Request for Comments: 4031 Nortel Networks
Category: Informational D. McDysan, Ed.
MCI
April 2005
Network Working Group M. Carugi, Ed.
Request for Comments: 4031 Nortel Networks
Category: Informational D. McDysan, Ed.
MCI
April 2005
Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
第3层提供商提供的虚拟专用网络（PPVPN）的服务要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.
本文件提供了第3层虚拟专用网络（L3VPN）的要求。它确定了适用于服务提供商可用于提供虚拟专用网络（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. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document. . . . . . . . . . . . . . . . . 4
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Contributing Authors. . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Virtual Private Network . . . . . . . . . . . . . . . . 6
3.2. Users, Sites, Customers, and Agents . . . . . . . . . . 6
3.3. Intranets, Extranets, and VPNs. . . . . . . . . . . . . 6
3.4. Networks of Customer and Provider Devices . . . . . . . 7
3.5. Access Networks, Tunnels, and Hierarchical Tunnels. . . 7
3.6. Use of Tunnels and Roles of CE and PE in L3VPNs . . . . 8
3.6.1. PE-Based L3VPNs and Virtual Forwarding
Instances . . . . . . . . . . . . . . . . . . . 8
3.6.2. CE-Based L3VPN Tunnel Endpoints and Functions . 10
3.7. Customer and Provider Network Management. . . . . . . . 10
4. Service Requirements Common to Customers and Service
Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Isolated Exchange of Data and Routing Information . . . 11
4.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Quality of Service. . . . . . . . . . . . . . . . . . . 12
4.3.1. QoS Standards . . . . . . . . . . . . . . . . . 12
4.3.2. Service Models. . . . . . . . . . . . . . . . . 13
4.4. Service Level Specification and Agreements. . . . . . . 14
4.5. Management. . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Interworking. . . . . . . . . . . . . . . . . . . . . . 15
5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 15
5.1. VPN Membership (Intranet/Extranet). . . . . . . . . . . 15
5.2. Service Provider Independence . . . . . . . . . . . . . 16
5.3. Addressing. . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Routing Protocol Support. . . . . . . . . . . . . . . . 16
5.5. Quality of Service and Traffic Parameters . . . . . . . 16
5.5.1. Application Level QoS Objectives. . . . . . . . 17
5.5.2. DSCP Transparency . . . . . . . . . . . . . . . 17
5.6. Service Level Specification/Agreement . . . . . . . . . 18
5.7. Customer Management of a VPN. . . . . . . . . . . . . . 18
5.8. Isolation . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. Migration Impact. . . . . . . . . . . . . . . . . . . . 19
5.11. Network Access. . . . . . . . . . . . . . . . . . . . . 19
5.11.1. Physical/Link Layer Technology. . . . . . . . . 20
5.11.2. Temporary Access. . . . . . . . . . . . . . . . 20
5.11.3. Sharing of the Access Network . . . . . . . . . 20
5.11.4. Access Connectivity . . . . . . . . . . . . . . 20
5.12. Service Access. . . . . . . . . . . . . . . . . . . . . 23
5.12.1. Internet Access . . . . . . . . . . . . . . . . 23
5.12.2. Hosting, Application Service Provider . . . . . 24
5.12.3. Other Services. . . . . . . . . . . . . . . . . 24
5.13. Hybrid VPN Service Scenarios. . . . . . . . . . . . . . 24
6. Service Provider Network Requirements . . . . . . . . . . . . 24
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Discovering VPN Related Information . . . . . . . . . . 26
6.5. SLA and SLS Support . . . . . . . . . . . . . . . . . . 26
6.6. Quality of Service (QoS) and Traffic Engineering. . . . 27
6.7. Routing . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Isolation of Traffic and Routing. . . . . . . . . . . . 28
6.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 28
6.9.1. Support for Securing Customer Flows . . . . . . 28
6.9.2. Authentication Services . . . . . . . . . . . . 29
6.9.3. Resource Protection . . . . . . . . . . . . . . 30
6.10. Inter-AS (SP)VPNs . . . . . . . . . . . . . . . . . . . 30
3.7. Customer and Provider Network Management. . . . . . . . 10
4. Service Requirements Common to Customers and Service
Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Isolated Exchange of Data and Routing Information . . . 11
4.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Quality of Service. . . . . . . . . . . . . . . . . . . 12
4.3.1. QoS Standards . . . . . . . . . . . . . . . . . 12
4.3.2. Service Models. . . . . . . . . . . . . . . . . 13
4.4. Service Level Specification and Agreements. . . . . . . 14
4.5. Management. . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Interworking. . . . . . . . . . . . . . . . . . . . . . 15
5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 15
5.1. VPN Membership (Intranet/Extranet). . . . . . . . . . . 15
5.2. Service Provider Independence . . . . . . . . . . . . . 16
5.3. Addressing. . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Routing Protocol Support. . . . . . . . . . . . . . . . 16
5.5. Quality of Service and Traffic Parameters . . . . . . . 16
5.5.1. Application Level QoS Objectives. . . . . . . . 17
5.5.2. DSCP Transparency . . . . . . . . . . . . . . . 17
5.6. Service Level Specification/Agreement . . . . . . . . . 18
5.7. Customer Management of a VPN. . . . . . . . . . . . . . 18
5.8. Isolation . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. Migration Impact. . . . . . . . . . . . . . . . . . . . 19
5.11. Network Access. . . . . . . . . . . . . . . . . . . . . 19
5.11.1. Physical/Link Layer Technology. . . . . . . . . 20
5.11.2. Temporary Access. . . . . . . . . . . . . . . . 20
5.11.3. Sharing of the Access Network . . . . . . . . . 20
5.11.4. Access Connectivity . . . . . . . . . . . . . . 20
5.12. Service Access. . . . . . . . . . . . . . . . . . . . . 23
5.12.1. Internet Access . . . . . . . . . . . . . . . . 23
5.12.2. Hosting, Application Service Provider . . . . . 24
5.12.3. Other Services. . . . . . . . . . . . . . . . . 24
5.13. Hybrid VPN Service Scenarios. . . . . . . . . . . . . . 24
6. Service Provider Network Requirements . . . . . . . . . . . . 24
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Addressing. . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Discovering VPN Related Information . . . . . . . . . . 26
6.5. SLA and SLS Support . . . . . . . . . . . . . . . . . . 26
6.6. Quality of Service (QoS) and Traffic Engineering. . . . 27
6.7. Routing . . . . . . . . . . . . . . . . . . . . . . . . 27
6.8. Isolation of Traffic and Routing. . . . . . . . . . . . 28
6.9. Security. . . . . . . . . . . . . . . . . . . . . . . . 28
6.9.1. Support for Securing Customer Flows . . . . . . 28
6.9.2. Authentication Services . . . . . . . . . . . . 29
6.9.3. Resource Protection . . . . . . . . . . . . . . 30
6.10. Inter-AS (SP)VPNs . . . . . . . . . . . . . . . . . . . 30
6.10.1. Routing Protocols . . . . . . . . . . . . . . . 31
6.10.2. Management. . . . . . . . . . . . . . . . . . . 31
6.10.3. Bandwidth and QoS Brokering . . . . . . . . . . 31
6.10.4. Security Considerations . . . . . . . . . . . . 32
6.11. L3VPN Wholesale . . . . . . . . . . . . . . . . . . . . 32
6.12. Tunneling Requirements. . . . . . . . . . . . . . . . . 33
6.13. Support for Access and Backbone Technologies. . . . . . 33
6.13.1. Dedicated Access Networks . . . . . . . . . . . 34
6.13.2. On-Demand Access Networks . . . . . . . . . . . 34
6.13.3. Backbone Networks . . . . . . . . . . . . . . . 35
6.14. Protection, Restoration . . . . . . . . . . . . . . . . 35
6.15. Interoperability. . . . . . . . . . . . . . . . . . . . 35
6.16. Migration Support . . . . . . . . . . . . . . . . . . . 36
7. Service Provider Management Requirements. . . . . . . . . . . 36
7.1. Fault Management. . . . . . . . . . . . . . . . . . . . 37
7.2. Configuration Management. . . . . . . . . . . . . . . . 37
7.2.1. Configuration Management for PE-Based VPNs. . . 38
7.2.2. Configuration Management for CE-Based VPNs. . . 39
7.2.3. Provisioning Routing. . . . . . . . . . . . . . 39
7.2.4. Provisioning Network Access . . . . . . . . . . 39
7.2.5. Provisioning Security Services. . . . . . . . . 40
7.2.6. Provisioning VPN Resource Parameters. . . . . . 40
7.2.7. Provisioning Value-Added Service Access . . . . 40
7.2.8. Provisioning Hybrid VPN Services. . . . . . . . 41
7.3. Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Performance Management. . . . . . . . . . . . . . . . . 42
7.4.1. Performance Monitoring. . . . . . . . . . . . . 42
7.4.2. SLA and QoS Management Features . . . . . . . . 42
7.5. Security Management . . . . . . . . . . . . . . . . . . 43
7.5.1. Resource Access Control . . . . . . . . . . . . 43
7.5.2. Authentication. . . . . . . . . . . . . . . . . 43
7.6. Network Management Techniques . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References. . . . . . . . . . . . . . . . . . 45
10.2. Informative References. . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50
6.10.1. Routing Protocols . . . . . . . . . . . . . . . 31
6.10.2. Management. . . . . . . . . . . . . . . . . . . 31
6.10.3. Bandwidth and QoS Brokering . . . . . . . . . . 31
6.10.4. Security Considerations . . . . . . . . . . . . 32
6.11. L3VPN Wholesale . . . . . . . . . . . . . . . . . . . . 32
6.12. Tunneling Requirements. . . . . . . . . . . . . . . . . 33
6.13. Support for Access and Backbone Technologies. . . . . . 33
6.13.1. Dedicated Access Networks . . . . . . . . . . . 34
6.13.2. On-Demand Access Networks . . . . . . . . . . . 34
6.13.3. Backbone Networks . . . . . . . . . . . . . . . 35
6.14. Protection, Restoration . . . . . . . . . . . . . . . . 35
6.15. Interoperability. . . . . . . . . . . . . . . . . . . . 35
6.16. Migration Support . . . . . . . . . . . . . . . . . . . 36
7. Service Provider Management Requirements. . . . . . . . . . . 36
7.1. Fault Management. . . . . . . . . . . . . . . . . . . . 37
7.2. Configuration Management. . . . . . . . . . . . . . . . 37
7.2.1. Configuration Management for PE-Based VPNs. . . 38
7.2.2. Configuration Management for CE-Based VPNs. . . 39
7.2.3. Provisioning Routing. . . . . . . . . . . . . . 39
7.2.4. Provisioning Network Access . . . . . . . . . . 39
7.2.5. Provisioning Security Services. . . . . . . . . 40
7.2.6. Provisioning VPN Resource Parameters. . . . . . 40
7.2.7. Provisioning Value-Added Service Access . . . . 40
7.2.8. Provisioning Hybrid VPN Services. . . . . . . . 41
7.3. Accounting. . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Performance Management. . . . . . . . . . . . . . . . . 42
7.4.1. Performance Monitoring. . . . . . . . . . . . . 42
7.4.2. SLA and QoS Management Features . . . . . . . . 42
7.5. Security Management . . . . . . . . . . . . . . . . . . 43
7.5.1. Resource Access Control . . . . . . . . . . . . 43
7.5.2. Authentication. . . . . . . . . . . . . . . . . 43
7.6. Network Management Techniques . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References. . . . . . . . . . . . . . . . . . 45
10.2. Informative References. . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50
This section describes the scope and outline of the document.
本节介绍了本文件的范围和概要。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 ([RFC2119]).
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119（[RFC2119]）中所述进行解释。
This document provides requirements specific to Layer 3 Virtual Private Networks (L3VPN). (Requirements that are generic to L2 and L3 VPNs are contained in [RFC3809].)
本文档提供了第3层虚拟专用网络（L3VPN）的特定要求。（L2和L3 VPN的通用要求包含在[RFC3809]中。）
This document identifies requirements that may apply to one or more individual approaches that a Service Provider may use to provision a Layer 3 (e.g., IP) VPN service. It makes use of the terminology and common components for Layer 3 VPNs as defined in [L3VPN-FR] and of the generic VPN terminology defined in [PPVPN-TERM].
本文件确定了可能适用于服务提供商用于提供第3层（如IP）VPN服务的一个或多个单独方法的要求。它使用了[L3VPN-FR]中定义的第3层VPN的术语和通用组件，以及[PPVPN-TERM]中定义的通用VPN术语。
The specification of technical means to provide L3VPN services is outside the scope of this document. Other documents are intended to cover this aspect, such as the L3 VPN framework document [L3VPN-FR] and several sets of documents, one for each technical approach for providing L3VPN services.
提供L3VPN服务的技术手段规范不在本文件范围内。其他文件旨在涵盖这一方面，如L3 VPN框架文件[L3VPN-FR]和多套文件，每种技术方法一套用于提供L3VPN服务。
Technical approaches targeted by this document include the network-based (PE-based) L3VPN category (aggregated routing VPNs [2547bis] and virtual routers [PPVPN-VR]) and the CE-based L3VPNs category [CE-PPVPN][IPSEC-PPVPN]. The document distinguishes L3VPN categories as to where the endpoints of tunnels exist, as detailed in the L3VPN framework document [L3VPN-FR]. Terminology describing whether equipment faces a customer or the service provider network is used to define the various types of L3VPN solutions.
本文件针对的技术方法包括基于网络（基于PE）的L3VPN类别（聚合路由VPN[2547bis]和虚拟路由器[PPVPN-VR]）和基于CE的L3VPN类别[CE-PPVPN][IPSEC-PPVPN]。本文件根据隧道端点的位置区分L3VPN类别，详见L3VPN框架文件[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.
本文件旨在作为需求的“检查表”，提供一致的方法来评估和记录每种方法满足特定需求的程度。每种方法的适用性声明文件应显示该评估的结果。本文件无意将一种方法与另一种方法进行比较。
This document provides requirements from several points of view. It begins with some considerations from a point of view common to customers and service providers not covered in the generic provider provisioned VPN requirement document [RFC3809], continues with a customer perspective, and concludes with specific needs of a Service Provider (SP).
本文件从多个角度提供了要求。本文首先从客户和服务提供商的共同观点出发，考虑了通用提供商提供的VPN需求文档[RFC3809]中未涉及的一些问题，接着从客户的角度出发，最后讨论了服务提供商（SP）的特定需求。
The following L3VPN deployment scenarios are considered within this document:
本文档中考虑了以下L3VPN部署场景：
1. Internet-wide: VPN sites attached to arbitrary points in the Internet.
1. Internet范围：连接到Internet上任意点的VPN站点。
2. Single SP/single AS: VPN sites attached to the network of a single provider within the scope of a single AS.
2. 单SP/单AS：连接到单个AS范围内的单个提供商网络的VPN站点。
3. Single SP/multiple ASes: VPN sites attached to the network of a single provider consisting of multiple ASes.
3. 单SP/多个ASE：连接到由多个ASE组成的单个提供商网络的VPN站点。
4. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide the VPN service.
4. 合作SP：连接到不同提供商网络的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对安全性、隐私性、可管理性、互操作性和可扩展性的要求，包括服务提供商对未来几年客户VPN数量、复杂性和变化率的预测。当需求应用于特定部署场景时，上述术语用于说明这些特定需求的上下文。
The outline of the rest of the document is as follows: Section 2 lists the contributing authors. Section 3 provides definitions of terms and concepts. Section 4 provides requirements common to both customers and service providers that are not covered in the generic provider provisioned VPN requirement document [RFC3809]. Section 5 states requirements from a customer perspective. Section 6 states network requirements from a service provider perspective. Section 7 states service provider management requirements. Section 8 describes security considerations. Section 9 lists acknowledgments. Section 10 provides a list of references cited herein. Section 11 lists the authors' addresses.
本文件其余部分概述如下：第2节列出了撰稿人。第3节提供了术语和概念的定义。第4节提供了通用提供商提供的VPN需求文件[RFC3809]中未涵盖的客户和服务提供商的通用需求。第5节从客户的角度阐述了要求。第6节从服务提供商的角度阐述了网络要求。第7节说明了服务提供商的管理要求。第8节介绍了安全注意事项。第9节列出了确认。第10节提供了本文引用的参考文献列表。第11节列出了作者的地址。
This document is the combined effort of the two co-editors and the following contributing authors:
本文件是两位联合编辑和以下撰稿人的共同努力：
Luyuan Fang Ananth Nagarajan Junichi Sumimoto Rick Wilder
卢元芳安南长垣纯一住本里克怀尔德
This section provides the definition of terms and concepts used throughout the document. Terminology used herein is taken from [PPVPN-TERM] and [L3VPN-FR].
本节提供了整个文档中使用的术语和概念的定义。此处使用的术语取自[PPVPN-TERM]和[L3VPN-FR]。
"L3 Virtual Private Network" (L3VPN) refers to the L3 communication between a set of sites making use of a shared network infrastructure.
“L3虚拟专用网络”（L3VPN）是指一组站点之间利用共享网络基础设施进行的L3通信。
"Provider Provisioned VPN" (PPVPN) refers to VPNs for which the service provider participates in management and provisioning of the VPN.
“提供商配置的VPN”（PPVPN）是指服务提供商参与VPN管理和配置的VPN。
User: A user is an entity (e.g., a human being using a host, a server, or a system) authorized to use a VPN service.
用户：用户是授权使用VPN服务的实体（例如，使用主机、服务器或系统的人）。
Site: A site is a set of users that have mutual L3 (i.e., IP) reachability without use of a specific service provider network. A site may consist of a set of users that are in geographic proximity. Note that a topological definition of a site (e.g., all users at a specific geographic location) may not always conform to this definition. For example, two geographic locations connected via another provider's network would also constitute a single site as communication between the two locations does not involve the use of the service provider offering the L3 VPN service.
站点：站点是一组具有相互L3（即IP）可达性的用户，无需使用特定的服务提供商网络。一个站点可能由地理位置相近的一组用户组成。请注意，站点的拓扑定义（例如，特定地理位置的所有用户）可能并不总是符合此定义。例如，通过另一提供商的网络连接的两个地理位置也将构成一个站点，因为两个位置之间的通信不涉及使用提供L3 VPN服务的服务提供商。
Customer: A single organization, corporation, or enterprise that administratively controls a set of sites.
客户：管理控制一组站点的单个组织、公司或企业。
Agent: A set of users designated by a customer who has the authorization to manage a customer's VPN service offering.
代理：由客户指定的一组用户，他们有权管理客户的VPN服务。
Intranet: An intranet restricts communication to a set of sites that belong to one customer. An example is branch offices at different sites that require communication with a headquarters site.
内部网：内部网将通信限制在属于一个客户的一组站点上。例如，不同地点的分支机构需要与总部地点进行通信。
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.
外联网：外联网允许在属于不同客户的一组站点之间进行通信。换句话说，两个或多个组织可以访问彼此指定的一组站点。外部网的例子包括多家公司合作进行联合软件开发，服务提供商可以从供应商的公司网站、不同的公司或参与联合体的大学访问信息。外联网通常对可达性有进一步的限制，例如，在主机和单个传输级别。
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.
请注意，内联网或外联网可以跨具有一个或多个ASE的单个服务提供商网络存在，也可以跨多个服务提供商网络存在。
L3 Virtual Private Network (L3VPN): An alternative definition of VPN refers to a specific set of sites that have been configured to allow communication as either an intranet or an extranet. Note that a site is a member of at least one VPN and may be a member of many VPNs.
L3虚拟专用网（L3VPN）：VPN的另一种定义是指一组特定的站点，这些站点已配置为允许作为内部网或外部网进行通信。请注意，站点是至少一个VPN的成员，并且可能是多个VPN的成员。
L3VPNs are composed of the following types of devices.
L3VPN由以下类型的设备组成。
Customer Edge (CE) device: A CE device faces the users at a customer site. The CE has an access connection to a PE device. It may be a router or a switch that allows users at a customer site to communicate over the access network with other sites in the VPN. In a CE-based L3VPN, as intended in this document (provider-provisioned CE-based VPN), the service provider manages (at least partially) the CE device.
客户边缘（CE）设备：CE设备在客户站点面向用户。CE具有到PE设备的访问连接。它可以是路由器或交换机，允许客户站点的用户通过接入网络与VPN中的其他站点通信。在基于CE的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.
提供商边缘（PE）设备：PE设备在一侧面向提供商网络，并通过一个或多个接入网络上的接入连接连接到一个或多个CE设备。它参与分组交换网络（PSN）执行路由和转发功能。
Note that the definitions of Customer Edge and Provider Edge do not necessarily describe the physical deployment of equipment on customer premises or a provider point of presence.
请注意，客户边缘和提供商边缘的定义不一定描述设备在客户场所或提供商存在点的物理部署。
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.
服务提供商（SP）网络：SP网络是由一个或多个ASE中的单个服务提供商管理的一组互连PE和P设备。
VPNs are built between CEs by using access networks, tunnels, and hierarchical tunnels across a PSN.
VPN通过使用接入网络、隧道和跨越PSN的分层隧道在CEs之间构建。
Access connection: An access connection provides connectivity between a CE and a PE. This includes dedicated physical circuits, virtual circuits (such as Frame Relay), ATM, Ethernet (V)LAN, or IP tunnels (e.g., IPsec, L2TP [RFC2661]).
接入连接：接入连接提供CE和PE之间的连接。这包括专用物理电路、虚拟电路（如帧中继）、ATM、以太网（V）LAN或IP隧道（如IPsec、L2TP[RFC2661]）。
Access network: An access network provides access connections between CE and PE devices. It may be a TDM network, an L2 network (e.g., FR, ATM, and Ethernet), or an IP network over which access is tunneled (e.g., by using L2TP).
接入网络：接入网络提供CE和PE设备之间的接入连接。它可以是TDM网络、L2网络（例如，FR、ATM和以太网）或通过隧道（例如，通过使用L2TP）进行访问的IP网络。
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.
隧道：两个实体之间的隧道是通过将数据包封装在另一个封装头中形成的，用于在这两个实体之间传输以支持VPN应用程序。隧道常用的协议示例有GRE、IPsec、IP隧道中的IP和MPLS。
Hierarchical Tunnel: Encapsulating one tunnel within another forms a hierarchical tunnel. The innermost tunnel protocol header defines a logical association between two entities (e.g., between CEs or PEs) [VPNTUNNEL]. Note that the tunneling protocols need not be the same at different levels in a hierarchical tunnel.
层次隧道：将一个隧道封装在另一个隧道中形成层次隧道。最里面的隧道协议头定义了两个实体之间的逻辑关联（例如，CEs或PEs之间）[VPNTUNNEL]。请注意，在分层隧道中的不同级别上，隧道协议不必相同。
This section summarizes the points where tunnels terminate and the functions implemented in the CE and PE devices that differentiate the two major categories of L3VPNs for which requirements are stated, namely PE-based and CE-based L3VPNs. See the L3VPN framework document for more detail [L3VPN-FR].
本节总结了隧道终止点以及CE和PE设备中实现的功能，这些功能区分了两大类L3VPN，并说明了要求，即基于PE和基于CE的L3VPN。有关更多详细信息，请参阅L3VPN框架文档[L3VPN-FR]。
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通过接入连接连接到一个或多个CE。PE根据IP层报头中的信息（如IPv4或IPv6目标地址）转发用户数据包。CE将PE视为第3层设备，如IPv4或IPv6路由器。
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为其服务的每个L3VPN包含一个VFI。VFI终止隧道以与其他VFI互连，还终止接入连接以容纳CE。VFI包含有关如何将通过CE-PE访问连接接收的数据转发到支持相同L3VPN的其他PE中的VFI的信息。VFI包括L3VPN的路由器信息库和转发信息库[L3VPN-FR]。VFI支持专用于服务特定VPN的路由器功能，例如
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设备中的VFI之间提供通信。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | Tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |==================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
|CE | conn. | |VFI of| | Tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |==================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.1. PE Usage of Separate Tunnels to Support VPNs
图1.1。PE使用单独的隧道来支持VPN
Figure 1.2 illustrates the case where a single hierarchical tunnel is used between PE devices to support communication for VPNs. The innermost encapsulating protocol header provides the means for the PE to determine the VPN for which the packet is directed.
图1.2说明了在PE设备之间使用单个分层隧道来支持VPN通信的情况。最里面的封装协议报头为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 device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | Hierarchical | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==============< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 1.2. PE Usage of Shared Hierarchical Tunnels to Support VPNs
图1.2。PE使用共享分层隧道来支持VPN
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）在成对的ce处终止。通常，CE服务于单个客户站点，因此转发和路由在物理上与所有其他客户分离。此外，PE不知道特定CE设备对特定VPN的成员身份。因此，VPN功能通过CE设备上的配置实现，共享PE和P网络仅用于提供支持CE设备之间隧道端点的路由和转发。连接CE设备的隧道拓扑可以是全网或部分网，具体取决于VPN客户需求和流量模式。
+---------+ +--------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +----------+ +----------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | |management| |management| | | : |
|interface| | | function | | function | | |Customer |
| | | +----------+ +----------+ | |interface|
| | | | | |
+---------+ +--------------------------------+ +---------+
| Access | |<-------- SP network(s) ------->| | Access |
| network | | | | network |
+---------+ +--------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ Tunnel |router| |device| : | of |
| of |=:================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | Tunnel +------+ : +------+
|device|=:================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +----------+ +----------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | |management| |management| | | : |
|interface| | | function | | function | | |Customer |
| | | +----------+ +----------+ | |interface|
| | | | | |
+---------+ +--------------------------------+ +---------+
| Access | |<-------- SP network(s) ------->| | Access |
| network | | | | network |
Figure 1.3. CE-Based L3VPN
图1.3。基于CE的L3VPN
Customer Network Management Function: A customer network management function provides the means for a customer agent to query or configure customer-specific information, or to receive alarms regarding his or her VPN. Customer-specific information includes data related to contact, billing, site, access network, IP address,
客户网络管理功能：客户网络管理功能为客户代理提供查询或配置客户特定信息或接收有关其VPN的警报的方法。客户特定信息包括与联系人、账单、站点、接入网络、IP地址、，
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]）。
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.
[RFC3809]中描述了许多既适用于客户又适用于提供商的一般性要求，或同时适用于L2和L3VPN的要求。本节包含[RFC3809]中未涵盖且特定于L3VPN的要求。
A mechanism must be provided for isolating the distribution of reachability information to only those sites associated with a VPN.
必须提供一种机制，用于将可达性信息的分发隔离到仅与VPN关联的那些站点。
L3VPN solutions shall define means that prevent routers in a VPN from interacting with unauthorized entities and that avoid introducing undesired routing information that could corrupt the VPN routing information base [VPN-CRIT].
L3VPN解决方案应定义防止VPN中的路由器与未经授权的实体交互的方法，并避免引入可能损坏VPN路由信息库的不需要的路由信息[VPN-CRIT]。
A means must be provided to constrain or isolate the distribution of addressed data to only those VPN sites determined by either routing data and/or configuration.
必须提供一种方法，将寻址数据的分发限制或隔离到仅由路由数据和/或配置确定的VPN站点。
A single site shall be capable of being in multiple VPNs. The VPN solution must ensure that traffic is exchanged only with sites in the same VPN.
单个站点应能够在多个VPN中。VPN解决方案必须确保仅与同一VPN中的站点交换流量。
The internal structure of a VPN should not be advertised or discoverable from outside that VPN.
VPN的内部结构不应在该VPN外部公布或发现。
Note that isolation of forwarded data or exchange of reachability information to only those sites that are part of a VPN may be viewed as a form of security - for example, [Y.1311.1], [MPLSSEC].
请注意，将转发数据隔离或仅向属于VPN一部分的站点交换可达性信息可被视为一种安全形式，例如，[Y.1311.1]，[MPLSSEC]。
IP addresses must be unique within the set of sites reachable from the VPNs of which a particular site is a member.
IP地址在可从特定站点所属的VPN访问的一组站点中必须是唯一的。
A VPN solution must support IPv4 and IPv6 as both the encapsulating and encapsulated protocol.
VPN解决方案必须支持IPv4和IPv6作为封装和封装协议。
If a customer has private or non-unique IP addresses, then a VPN service SHOULD be capable of translating such customer private or non-unique IP addresses for communicating with IP systems having public addresses.
如果客户具有私有或非唯一IP地址，则VPN服务应能够转换此类客户私有或非唯一IP地址，以便与具有公共地址的IP系统通信。
To the extent possible, L3VPN QoS should be independent of the access network technology.
L3VPN QoS应尽可能独立于接入网技术。
A non-goal of the L3VPN WG effort (as chartered) is the development of new protocols or extension of existing ones. An L3VPN shall be able to support QoS in one or more of the following already defined modes:
L3VPN工作组的一个非目标（如特许的）是开发新协议或扩展现有协议。L3VPN应能够在以下一种或多种已定义模式下支持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
- 尽力而为（所有L3VPN类型的强制支持）-聚合CE接口级QoS（“软管”级QoS）-站点到站点（“管道”级QoS）-发送信号的Intserv（即RSVP）-标记区分服务-跨分组交换接入网络
Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing.
注意，所有涉及QoS的情况都可能要求CE和/或PE执行成形和/或监管。
L3VPN CEs should be capable of supporting integrated services (Intserv) for certain customers in support of session applications, such as switched voice or video. Intserv-capable CE devices shall support the following Internet standards:
L3VPN CEs应能够支持特定客户的集成服务（Intserv），以支持会话应用程序，如交换语音或视频。支持Intserv的CE设备应支持以下互联网标准：
- Resource reSerVation Protocol (RSVP) [RFC2205] - Guaranteed Quality of Service providing a strict delay bound [RFC2212] - Controlled Load Service providing performance equivalent to that of an unloaded network [RFC2211]
- 资源预留协议（RSVP）[RFC2205]-保证服务质量，提供严格的延迟限制[RFC2212]-受控负载服务，提供与无负载网络相当的性能[RFC2211]
L3VPN CE and PE should be capable of supporting differentiated service (Diffserv). Diffserv-capable L3VPN CE and PE shall support the following per hop behavior (PHB) [RFC2475] types:
L3VPN CE和PE应能够支持区分服务（Diffserv）。支持区分服务的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].
- 加速转发（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].
- 保证转发（AF）-提供商区分服务（DS）域为从客户DS域接收的IP数据包提供不同级别的转发保证的一种方式。定义了四个AF类，其中每个AF类意味着在每个DS节点中分配一定数量的转发资源（例如，缓冲区空间和带宽）[RFC2597]。
A CE or PE device supporting an L3VPN service may classify a packet for a particular Intserv or Diffserv service based on one or more of the following IP header fields: protocol ID, source port number, destination port number, destination address, or source address.
支持L3VPN服务的CE或PE设备可以基于以下一个或多个IP报头字段对特定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.
对于一组可指定的Internet流量，L3VPN设备应支持随机早期检测（RED），以在网络拥塞时提供良好的降级。
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]。下面提供了L3VPN的更多详细信息。
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执行数据包分类和区分服务标记时。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，这取决于提供商和客户之间的服务分界点。这种服务可以跨一个或多个提供商主干网提供。
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网络的一个边缘到另一个边缘提供QoS。
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:
[RFC3809]中提供了对SLA的一般讨论。此外，基于DiffServ方案的SLS质量测量应基于以下分类：
- A Point-to-Point SLS [Y.1311.1], sometimes also referred to as the "Pipe" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a pair of VPN sites (i.e., points). A Point-to-Point SLS is analogous to the SLS typically supported over point-to-point Frame Relay or ATM PVCs or an edge-to-edge MPLS tunnel. The set of SLS specifications to all other reachable VPN sites would define the overall Point-to-Point SLS for a specific site.
- 点对点SLS[Y.1311.1]，有时也称为“管道”模型，结合一对VPN站点（即点）之间交换的流量的QoS目标定义流量参数。点到点SLS类似于通常通过点到点帧中继或ATM PVCs或边到边MPLS隧道支持的SLS。所有其他可访问VPN站点的SLS规范集将定义特定站点的整体点到点SLS。
- A Point-to-Cloud SLS [Y.1311.1], sometimes also referred to as the "Hose" model, defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a CE and a PE for traffic destined to a set (either all or a subset) of other sites in the VPN (i.e., the cloud), as applicable. In other words, a point-to-cloud SLS defines compliance in terms of all packets transmitted from a given VPN site toward the SP network on an aggregate basis (i.e., regardless of the destination VPN site of each packet).
- 点到云SLS[Y.1311.1]，有时也称为“软管”模型，结合CE和PE之间交换的流量的QoS目标，为目的地为VPN（即，云）中其他站点的一组（全部或子集）的流量定义流量参数（如适用）。换句话说，点对云SLS根据从给定VPN站点向SP网络传输的所有数据包（即，不管每个数据包的目的VPN站点如何）来定义合规性。
- A Cloud-to-Point SLS (a case not covered by this SLS is where flows originating from multiple sources may congest the interface toward a specific site).
- 云到点SLS（本SLS未涵盖的情况是，来自多个来源的流量可能会阻塞通向特定站点的接口）。
Traffic parameters and actions SHOULD be defined for packets to and from the demarcation between the service provider and the site. For example, policing may be defined on ingress, and shaping on egress.
应为进出服务提供商和站点之间的分界线的数据包定义流量参数和操作。例如，可以在入口定义监管，在出口定义成型。
An SP and its customers MUST be able to manage the capabilities and characteristics of their VPN services. To the extent possible, automated operations and interoperability with standard management platforms SHOULD be supported.
SP及其客户必须能够管理其VPN服务的功能和特征。应尽可能支持自动化操作和与标准管理平台的互操作性。
The ITU-T Telecommunications Management Network (TMN) model has the following generic requirements structure:
ITU-T电信管理网络（TMN）模型具有以下通用需求结构：
O Engineer, deploy, and manage the switching, routing, and transmission resources supporting the service, from a network perspective (network element management).
O从网络角度（网元管理）设计、部署和管理支持服务的交换、路由和传输资源。
O Manage the VPN networks deployed over these resources (network management).
O管理通过这些资源部署的VPN网络（网络管理）。
o Manage the VPN service (service management). o Manage the VPN business, mainly provisioning administrative and accounting information related to the VPN service customers (business management).
o 管理VPN服务（服务管理）。o管理VPN业务，主要提供与VPN服务客户相关的管理和会计信息（业务管理）。
Service management should include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Provisioning, and Security, as detailed in section 7.
服务管理应包括TMN“FCAPS”功能，如下所示：故障、配置、记帐、供应和安全，详见第7节。
Interworking scenarios among different solutions providing L3VPN services is highly desirable. See the L3VPN framework document for more details on interworking scenarios [L3VPN-FR]. Interworking SHOULD be supported in a scalable manner.
提供L3VPN服务的不同解决方案之间的互通场景非常理想。有关互通场景的更多详细信息，请参阅L3VPN框架文档[L3VPN-FR]。应以可扩展的方式支持互通。
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、访问和管理方面。这一要求对于网络迁移至关重要，以确保属于网络不同部分的站点之间的服务连续性。
This section captures additional requirements from a customer perspective.
本节从客户的角度捕获其他需求。
When an extranet is formed, a customer agent from each of the organizations first approves addition of a site to an extranet VPN as a business decision between the parties involved. The solution SHOULD provide a means for these organizations to control extranet communication involving the L3VPN exchange of traffic and routing information.
当外部网形成时，每个组织的客户代理首先批准将站点添加到外部网VPN，作为相关各方之间的业务决策。该解决方案应为这些组织提供一种控制涉及L3VPN流量和路由信息交换的外联网通信的方法。
Customers MAY require VPN service that spans multiple administrative domains or service provider networks. Therefore, a VPN service MUST be able to span multiple AS and SP networks, but still act and appear as a single, homogeneous VPN from a customer point of view.
客户可能需要跨多个管理域或服务提供商网络的VPN服务。因此，VPN服务必须能够跨越多个AS和SP网络，但从客户的角度来看，它仍然是一个单一的、同质的VPN。
A customer might also start with a VPN provided in a single AS with a certain SLA but then ask for an expansion of the service, spanning multiple ASes/SPs. In this case, as well as for all kinds of multi-AS/SP VPNs, VPN service SHOULD be able to deliver the same SLA to all sites in a VPN regardless of the AS/SP to which it homes.
客户也可以从一个单独的服务级别协议中提供的VPN开始，然后要求扩展服务，跨越多个ASE/SP。在这种情况下，对于所有类型的多as/SP VPN，VPN服务应该能够向VPN中的所有站点提供相同的SLA，而不管其所在的as/SP是什么。
A customer requires support from an L3VPN for the following addressing IP assignment schemes:
客户需要L3VPN支持以下寻址IP分配方案：
o Customer-assigned, non-unique, or [RFC1918] private addresses o Globally unique addresses obtained by the customer o Globally unique addresses statically assigned by the L3VPN service provider o On-demand, dynamically assigned IP addresses (e.g., DHCP), irrespective of whether the access is temporary (e.g., remote) or permanent (e.g., dedicated)
o 客户分配、非唯一或[RFC1918]专用地址o客户获得的全局唯一地址o L3VPN服务提供商静态分配的全局唯一地址o按需动态分配的IP地址（如DHCP），无论访问是临时（如远程）还是永久（如专用）
In the case of combined L3VPN service with non-unique or private addresses and Internet access, mechanisms that permit the exchange of traffic between the customer's address space and the global unique Internet address space MAY be supported. For example, NAT is employed by many customers and by some service providers today to meet this need. A preferred solution would be to assign unique addresses, either IPv4 or IPv6; however, some customers do not want to renumber their networks.
在具有非唯一或专用地址和互联网接入的组合L3VPN服务的情况下，可以支持允许在客户地址空间和全局唯一互联网地址空间之间交换流量的机制。例如，现在许多客户和一些服务提供商都使用NAT来满足这一需求。首选的解决方案是分配唯一的地址，IPv4或IPv6；但是，有些客户不想重新编号他们的网络。
There SHOULD be no restriction on the routing protocols used between CE and PE routers, or between CE routers. At least the following protocols MUST be supported: static routing, IGP protocols such as RIP, OSPF, IS-IS, and BGP [L3VPN-FR].
CE和PE路由器之间或CE路由器之间使用的路由协议不应受到限制。至少必须支持以下协议：静态路由、IGP协议，如RIP、OSPF、IS-IS和BGP[L3VPN-FR]。
QoS is expected to be an important aspect of an L3VPN service for some customers. QoS requirements cover scenarios involving an intranet, an extranet, and shared access between a VPN site and the Internet.
对于某些客户来说，QoS将是L3VPN服务的一个重要方面。QoS要求包括涉及内部网、外部网和VPN站点与Internet之间的共享访问的场景。
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。这些实时应用程序对延迟、延迟变化、丢失、可用性和/或可靠性非常敏感。另一组应用程序，包括一些多媒体和交互式视频应用程序、高性能web浏览和文件传输密集型应用程序，需要接近实时的性能。最后，尽力而为的应用程序对降级不敏感，即它们具有弹性，可以适应性能降级的条件。
The selection of appropriate QoS and service type to meet specific application requirements is particularly important to deal with periods of congestion in an SP network. Sensitive applications will likely select per-flow Integrated service (Intserv) with precise SLA guarantees measured on a per-flow basis. On the other hand, non-sensitive applications will likely rely on a Diffserv class-based QoS.
选择适当的QoS和服务类型以满足特定的应用程序需求对于处理SP网络中的拥塞周期尤为重要。敏感应用程序可能会选择每流集成服务（Intserv），并在每流的基础上测量精确的SLA保证。另一方面，非敏感应用程序可能依赖于基于区分服务类的QoS。
The fundamental customer application requirement is that an L3VPN solution MUST support both the Intserv QoS model for selected individual flows and Diffserv for aggregated flows.
客户应用程序的基本要求是，L3VPN解决方案必须同时支持选定单个流的Intserv QoS模型和聚合流的Diffserv。
A customer application SHOULD experience consistent QoS independent of the access network technology used at different sites connected to the same VPN.
客户应用程序应体验到与连接到同一VPN的不同站点使用的接入网络技术无关的一致QoS。
The Diffserv Code Point (DSCP) set by a user as received by the ingress CE SHOULD be capable of being relayed transparently to the egress CE (see section 2.6.2 of [RFC3270] and [Y.1311.1]). Although RFC 2475 states that interior or boundary nodes within a DS domain can change the DSCP, customer VPNs MAY have other requirements, such as
用户设置的由入口CE接收的区分服务码点（DSCP）应能够透明地中继到出口CE（见[RFC3270]和[Y.1311.1]第2.6.2节）。尽管RFC 2475规定DS域内的内部或边界节点可以更改DSCP，但客户VPN可能有其他要求，例如
o applications that use the DSCP in a manner differently from the DSCP solution supported by the SP network(s), o customers using more DSCPs within their sites than the SP network(s) supports, o support for a carrier's carrier service in which one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to his or her VPN customers independently of the DSCP mapping solution supported by the carrier's carrier SP.
o 以不同于SP网络支持的DSCP解决方案的方式使用DSCP的应用程序，o客户在其站点内使用的DSCP数量超过SP网络支持的数量，o支持运营商的运营商服务，其中一个SP是另一个L3VPN SP的客户。此类SP应能够独立于运营商的运营商SP支持的DSCP映射解决方案，将VPN服务转售给其VPN客户。
Note that support for DSCP transparency has no implication on the QoS or SLA requirements. If an SP supports DSCP transparency, then that SP needs to carry only the DSCP values across its domain but MAY map the received DSCP to some other value for QoS support across its domain.
请注意，对DSCP透明性的支持并不影响QoS或SLA要求。如果SP支持DSCP透明性，则该SP只需在其域中携带DSCP值，但可以将接收到的DSCP映射到其他值，以便在其域中提供QoS支持。
Most customers simply want their applications to perform well. An SLA is a vehicle for customer recourse in the event that SP(s) do not perform or manage a VPN service well in a measurable sense. Therefore, when purchasing service under an SLA, a customer agent
大多数客户只是希望他们的应用程序性能良好。SLA是当SP在可测量的意义上不能很好地执行或管理VPN服务时，客户求助的工具。因此，当根据SLA购买服务时，客户代理
MUST have access to the measures from the SP(s) that support the SLA.
必须能够从支持SLA的SP访问度量值。
A customer MUST have a means to view the topology, operational state, order status, and other parameters associated with his or her VPN.
客户必须能够查看拓扑、操作状态、订单状态以及与其VPN相关的其他参数。
Most aspects of management information about CE devices and customer attributes of an L3VPN manageable by an SP SHOULD be capable of being configured and maintained by an authenticated, authorized customer agent. However, some aspects, such as encryption keys, SHALL NOT be readable nor writable by management systems.
SP可管理的L3VPN的CE设备和客户属性的管理信息的大多数方面都应该能够由经过身份验证的授权客户代理进行配置和维护。但是，某些方面，如加密密钥，管理系统不应可读写。
A customer agent SHOULD be able to make dynamic requests for changes to traffic parameters. A customer SHOULD be able to receive real-time response from the SP network in response to these requests. One example of such service is a "Dynamic Bandwidth management" capability that enables real-time response to customer requests for changes of allocated bandwidth allocated to his or her VPN [Y.1311.1].
客户代理应该能够动态请求更改流量参数。客户应该能够收到SP网络对这些请求的实时响应。此类服务的一个示例是“动态带宽管理”功能，该功能能够实时响应客户请求更改分配给其VPN的分配带宽[Y.1311.1]。
A customer who may not be able to afford the resources to manage his own sites SHOULD be able to outsource the management of the entire VPN to the SP(s) supporting the VPN network.
如果客户可能负担不起管理自己站点的资源，则应能够将整个VPN的管理外包给支持VPN网络的SP。
These features include traffic and routing information exchange isolation, similar to that obtained in VPNs based on Layer 1 and Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC].
这些特性包括流量和路由信息交换隔离，类似于在基于第1层和第2层的VPN中获得的隔离（例如，专用线路、FR或ATM）[MPLSSEC]。
The suite of L3VPN solutions SHOULD support a range of security related features. Higher levels of security services, such as edge-to-edge encryption, authentication, or replay attack, should be supported. More details on customer requirements for security are described in [VPNSEC].
L3VPN解决方案套件应支持一系列安全相关功能。应支持更高级别的安全服务，如边到边加密、身份验证或重播攻击。有关客户安全要求的更多详细信息，请参见[VPNSEC]。
Security in an L3VPN service SHOULD be as transparent as possible to the customer, with the obvious exception of support for remote or temporary user access, as detailed in section 5.11.2.
L3VPN服务的安全性应尽可能对客户透明，但支持远程或临时用户访问的明显例外，详见第5.11.2节。
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。例如，应用程序可以发送支持Intserv的RSVP消息，可以是明文，也可以是使用与SP协商的密钥加密的。另一种情况是，使用IPsec隧道的应用程序可以将DSCP从加密的IP头复制到隧道IP头的头。
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.
通常，客户正在从已部署的专用网络迁移到一个或多个L3VPN解决方案。典型的专用网络场景是通过真实或虚拟电路连接的CE路由器。理想情况下，迁移期间的增量成本应该最小。此外，如有必要，还应尽量减少服务中断。
A range of scenarios of customer migration MUST be supported. Full migration of all sites MUST be supported. Support for cases of partial migration is highly desirable [Y.1311.1] - that is, legacy private network sites that belong to the L3VPN service SHOULD still have L3 reachability to the sites that migrate to the L3VPN service.
必须支持一系列客户迁移场景。必须支持所有站点的完全迁移。对部分迁移情况的支持是非常理想的[Y.1311.1]-也就是说，属于L3VPN服务的传统专用网络站点应该仍然具有迁移到L3VPN服务的站点的L3可达性。
Every L3 packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L3VPN.
客户和SP之间通过接入连接交换的每个L3数据包必须显示在专用网络上，提供与L3VPN相同的服务。
L3VPNs SHOULD support a broad range of physical and link-layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, and mobile radio access. The capacity and QoS achievable may be dependent on the specific access technology in use.
L3VPN应支持广泛的物理和链路层接入技术，如PSTN、ISDN、xDSL、电缆调制解调器、专线、以太网、以太网VLAN、ATM、帧中继、无线本地环路和移动无线电接入。可实现的容量和QoS可能取决于所使用的特定接入技术。
The VPN service offering SHOULD allow both permanent and temporary access to one or more L3VPNs for authenticated users across a broad range of access technologies. Support for remote or temporary VPN access SHOULD include ISDN, PSTN dial-in, xDSL, or access via another SP network. The customer SHOULD be able to choose from alternatives for authentication of temporary access users. Choices for access authentication are SP-provided, third-party, or customer-provided authentication.
VPN服务产品应允许经过身份验证的用户通过广泛的访问技术对一个或多个L3VPN进行永久和临时访问。对远程或临时VPN访问的支持应包括ISDN、PSTN拨入、xDSL或通过另一个SP网络的访问。客户应该能够从备选方案中选择临时访问用户的身份验证。访问身份验证的选择包括SP提供的、第三方的或客户提供的身份验证。
A significant number of VPN users may not be permanently attached to one VPN site: in order to limit access to a VPN to authorized users, it is first necessary to authenticate them. Authentication SHALL apply as configured by the customer agent and/or SP where a specific user may be part of one or more VPNs. The authentication function SHOULD be used to invoke all actions necessary to join a user to the VPN automatically.
大量VPN用户可能不会永久连接到一个VPN站点：为了限制授权用户访问VPN，首先需要对他们进行身份验证。当特定用户可能是一个或多个VPN的一部分时，应按照客户代理和/或SP的配置进行认证。身份验证功能应用于调用自动将用户加入VPN所需的所有操作。
A user SHOULD be able to access an L3VPN via a network having generic Internet access.
用户应该能够通过具有通用Internet访问的网络访问L3VPN。
Mobile users may move within an L3VPN site. Mobile users may also have temporary connections to different L3VPN sites within the same VPN. Authentication SHOULD be provided in both of these cases.
移动用户可以在L3VPN站点内移动。移动用户还可以临时连接到同一VPN内的不同L3VPN站点。在这两种情况下都应提供身份验证。
In a PE-based L3VPN, if the site shares the access network with other traffic (e.g., access to the Internet), then data security in the access network is the responsibility of the L3VPN customer.
在基于PE的L3VPN中，如果站点与其他流量（例如访问互联网）共享接入网络，则接入网络中的数据安全由L3VPN客户负责。
Various types of physical connectivity scenarios MUST be supported, such as multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks. L3VPN solutions SHOULD support at least the types of physical or link-layer connectivity arrangements shown in Figure 2.1. Support for other physical connectivity scenarios with arbitrary topology is desirable.
必须支持各种类型的物理连接方案，例如多主站点、客户站点之间的后门链接以及驻留到两个或多个SP网络的设备。L3VPN解决方案应至少支持图2.1所示的物理或链路层连接安排类型。支持具有任意拓扑的其他物理连接方案是可取的。
Access arrangements with multiple physical or logical paths from a CE to other CEs and PEs MUST support redundancy and SHOULD support load balancing. Resiliency uses redundancy to provide connectivity between a CE site and other CE sites and, optionally, other services. Load balancing provides a means to perform traffic engineering so that capacity on redundant links is used to achieve improved performance during periods when the redundant component(s) are available.
具有从CE到其他CE和PE的多条物理或逻辑路径的访问安排必须支持冗余，并应支持负载平衡。弹性使用冗余来提供CE站点和其他CE站点以及（可选）其他服务之间的连接。负载平衡提供了一种执行流量工程的方法，以便在冗余组件可用期间，使用冗余链路上的容量来提高性能。
For multi-homing to a single SP, load balancing capability SHOULD be supported by the PE across the CE to PE links. For example, in case (a), load balancing SHOULD be provided by the two PEs over the two links connecting to the single CE. In case (c), load balancing SHOULD be provided by the two PEs over the two links connecting to the two CEs.
对于单SP的多主，PE应跨CE到PE链路支持负载平衡功能。例如，在案例（a）中，两个PE应通过连接到单个CE的两条链路提供负载平衡。在（c）种情况下，两个PE应通过连接到两个CE的两条链路提供负载平衡。
In addition, the load-balancing parameters (e.g., the ratio of traffic on the multiple load-balanced links, or the preferred link) SHOULD be provisionable based on customer's requirements. The load-balancing capability may also be used to achieve resiliency in the event of access connectivity failures. For example, in case (b) a CE may connect to two different SPs via diverse access networks. Resiliency MAY be further enhanced as shown in case (d), where CEs connected via a "back door" connection connect to different SPs. Furthermore, arbitrary combinations of the above methods, with a few examples shown in cases (e) and (f), should be supportable by any L3VPN approach.
此外，负载平衡参数（例如，多个负载平衡链路或首选链路上的流量比率）应可根据客户的要求进行设置。负载平衡功能还可用于在访问连接失败时实现恢复能力。例如，在情况（b）中，CE可以通过不同的接入网络连接到两个不同的SPs。弹性可以进一步增强，如案例（d）所示，其中通过“后门”连接连接的CE连接到不同的SP。此外，上述方法的任意组合，以及案例（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).
对于多主多SP，不同SP中的PEs也可能支持负载平衡功能（显然，这是一种更复杂的负载平衡类型，需要SP之间的策略和服务协议才能实现互操作）。
+---------------- +---------------
| |
+------+ +------+
+---------| 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 |
| |router| | |router| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|router| +---------|router| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
+---------------
|door \\ | SP network |door \\
+---------------
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
+---------------
|door \\ | SP network |door \\
+---------------
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
Figure 2.1. Representative types of access arrangements
图2.1。有代表性的出入安排类型
Customers MAY also require access to other services, as described in this section.
如本节所述，客户可能还需要访问其他服务。
Customers SHOULD be able to have L3VPN and Internet access across the same access network for one or more of the customer's sites.
客户应能够通过同一接入网络为客户的一个或多个站点提供L3VPN和Internet访问。
Customers SHOULD be able to direct Internet traffic from the set of sites in the L3VPN to one or more customer sites that have firewalls, other security-oriented devices, and/or NATs that process all traffic between the Internet and the customer's VPN.
客户应能够将互联网流量从L3VPN中的一组站点定向到一个或多个具有防火墙、其他面向安全的设备和/或NAT的客户站点，这些站点处理互联网和客户VPN之间的所有流量。
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客户应该能够接收来自Internet的流量，该流量发送到不属于VPN的公共可访问资源，例如企业的公共web服务器。
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必须提供网络地址转换（NAT）或类似机制，以便允许与客户L3VPN以外的设备进行流量交换。
A customer SHOULD be able to access hosting, other application services, or other Application Service Providers (ASP) over an L3 L3VPN service. This MAY require that an ASP participate in one or more VPNs with the customers that use such a service.
客户应该能够通过L3 L3VPN服务访问主机、其他应用程序服务或其他应用程序服务提供商（ASP）。这可能需要ASP与使用此类服务的客户一起参与一个或多个VPN。
In conjunction with a VPN service, a customer MAY also wish to have access to other services, such as DNS, FTP, HTTP, NNTP, SMTP, LDAP, VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business, Streaming, E-commerce, Directory, Firewall, etc. The resources that implement these services could be physically dedicated to each VPN. If the resources are logically shared, then they MUST have access separated and isolated between VPNs in a manner consistent with the L3VPN solution to meet this requirement.
结合VPN服务，客户还可能希望能够访问其他服务，例如DNS、FTP、HTTP、NNTP、SMTP、LDAP、VoIP、NAT、LDAP、视频会议、应用程序共享、电子商务、流媒体、电子商务、目录、防火墙等。实现这些服务的资源可以物理上专用于每个VPN。如果资源在逻辑上是共享的，那么它们必须以与L3VPN解决方案一致的方式在VPN之间分离和隔离访问，以满足此要求。
Intranet or extranet customers have a number of reasons for wanting hybrid networks that involve more than one VPN solution type. These include migration, mergers, extranet customers with different VPN types, the need for different capabilities between different sets of sites, temporary access, and different availability of VPN solutions as provided by different service providers.
Intranet或extranet客户有许多理由希望使用涉及多种VPN解决方案类型的混合网络。其中包括迁移、合并、具有不同VPN类型的外部网客户、不同站点集之间对不同功能的需求、临时访问以及不同服务提供商提供的VPN解决方案的不同可用性。
The framework and solution approaches SHOULD include provisions for interworking, interconnection, and/or reachability between different
框架和解决方案方法应包括不同系统之间互通、互连和/或可达性的规定
L3VPN solutions in a way that does not overly complicate provisioning, management, scalability, or performance.
L3VPN解决方案不会使资源调配、管理、可扩展性或性能过于复杂。
This section describes requirements from a service provider perspective.
本节从服务提供商的角度描述需求。
[RFC3809] lists projections of L3VPN sizing and scalability requirements and metrics related to specific solutions.
[RFC3809]列出了L3VPN规模和可扩展性需求的预测，以及与特定解决方案相关的指标。
As described in section 4.2, SPs MUST have support for public and private IP addresses, IPv4 and IPv6, for both unicast and multicast. In order to support this range of addressing schemes, SPs require the following support from L3VPN solutions.
如第4.2节所述，SP必须支持单播和多播的公用和专用IP地址IPv4和IPv6。为了支持这一系列寻址方案，SP需要L3VPN解决方案提供以下支持。
An L3VPN solution MUST be able to assign blocks of addresses from its own public IP address space to L3VPN customer sites so that advertisement of routes to other SPs and other sites aggregates efficiently.
L3VPN解决方案必须能够将其自身公共IP地址空间中的地址块分配给L3VPN客户站点，以便有效聚合到其他SP和其他站点的路由广告。
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提供一种方法，将此类地址转换为公共IP地址，以便通过使用重叠地址或Internet与其他VPN通信。
A number of identifiers MAY be necessary for SP use in management, control, and routing protocols. Requirements for at least the following identifiers are known.
SP在管理、控制和路由协议中的使用可能需要许多标识符。已知至少以下标识符的要求。
An SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting a VPN that spans multiple SPs. Ideally, this identifier should be globally unique (e.g., an AS number).
支持跨多个SP的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的标识符应是唯一的，至少在每个SP的网络中是唯一的。理想情况下，VPN标识符应该是全局唯一的，以支持VPN跨越多个SP的情况（例如，[RFC2685]）。
A CE device SHOULD have a unique identifier, at least within each SP's network.
CE设备应至少在每个SP的网络中具有唯一标识符。
A PE device SHOULD have a unique identifier, at least within each SP's network.
PE设备应至少在每个SP的网络中具有唯一标识符。
The identifier of a device interconnecting SP networks MUST be unique within the set of aforementioned networks.
与SP网络互连的设备的标识符在上述网络集合中必须是唯一的。
Each site interface SHOULD have a unique identifier, at least within each PE router supporting such an interface.
每个站点接口应具有唯一标识符，至少在支持此类接口的每个PE路由器内。
Each tunnel SHOULD have a unique identifier, at least within each router supporting the tunnel.
每个隧道都应该有一个唯一的标识符，至少在支持隧道的每个路由器内。
Configuration of CE and PE devices is a significant task for a service provider. Solutions SHOULD strive to contain methods that dynamically allow VPN information to be discovered (or learned) by the PE and/or CE to reduce configuration complexity. The following specific requirements apply to intra- and inter-provider VPNs [VPNDISC].
配置CE和PE设备是服务提供商的一项重要任务。解决方案应努力包含允许PE和/或CE动态发现（或学习）VPN信息的方法，以降低配置复杂性。以下具体要求适用于提供商内部和提供商之间的VPN[VPNDISC]。
Every device involved in a VPN SHALL be able to identify and authenticate itself to other devices in the VPN. After learning the VPN membership, the devices SHOULD be able to exchange configuration information securely. The VPN information MUST include at least the IP address of the PE and may be extensible to provide additional information.
VPN中涉及的每个设备应能够向VPN中的其他设备识别和验证自身。学习VPN成员资格后，设备应能够安全地交换配置信息。VPN信息必须至少包括PE的IP地址，并且可以扩展以提供附加信息。
Each device in a VPN SHOULD be able to determine which other devices belong to the same VPN. Such a membership discovery scheme MUST prevent unauthorized access and allow authentication of the source.
VPN中的每个设备都应该能够确定哪些其他设备属于同一VPN。这种成员身份发现方案必须防止未经授权的访问，并允许对源进行身份验证。
Distribution of VPN information SHOULD be limited to those devices involved in that VPN.
VPN信息的分发应限于该VPN中涉及的设备。
In the case of a PE-based VPN, a solution SHOULD support the means for attached CEs to authenticate each other and verify that the SP's VPN network is correctly configured.
对于基于PE的VPN，解决方案应支持连接的CE相互验证并验证SP的VPN网络是否正确配置的方法。
The mechanism SHOULD respond to VPN membership changes in a timely manner. This is no longer than the provisioning timeframe, typically on the order of minutes, and could be as short as the timeframe required for "rerouting", typically on the order of seconds.
该机制应及时响应VPN成员资格的变化。这不会超过资源调配时间段（通常以分钟为单位），也可能与“重新路由”所需的时间段（通常以秒为单位）一样短。
Dynamically creating, changing, and managing multiple VPN assignments to sites and/or customers is another aspect of membership that MUST be addressed in an L3VPN solution.
动态创建、更改和管理站点和/或客户的多个VPN分配是L3VPN解决方案中必须解决的成员身份的另一个方面。
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服务的服务提供商承诺遵守特定的服务级别规范（SLS），作为与客户签订合同的一部分，如第4.4节和[RFC3809]所述。这样的服务级别协议（SLA）意味着SP需要测量特定服务级别规范（SLS）的质量、可用性、响应时间和配置间隔。
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设备中的参数配置，因此ONU位于SP上，以提供第4.3.2节中定义的托管QoS访问服务或边到边QoS服务。
Each L3VPN approach MUST describe the traffic engineering techniques available for an SP to meet the QoS objectives. These descriptions of traffic engineering techniques SHOULD quantify scalability and achievable efficiency. Traffic engineering support MAY be on an aggregate or per-VPN basis.
每个L3VPN方法必须描述SP可用于满足QoS目标的流量工程技术。这些交通工程技术的描述应该量化可伸缩性和可实现的效率。流量工程支持可以是聚合的，也可以是每个VPN。
QoS policies MUST not be impacted by security mechanisms. For example, Diffserv policies MUST not be impacted by the use of IPSec tunnels using the mechanisms explained in RFC 2983 [RFC2983].
QoS策略不得受到安全机制的影响。例如，使用RFC 2983[RFC2983]中解释的机制的IPSec隧道的使用不得影响区分服务策略。
As stated in RFC 2475, a mapping function from customer provided Diffserv marking to marking used in an SP network should be provided for L3 VPN services.
如RFC 2475所述，应为L3 VPN服务提供从客户提供的Diffserv标记到SP网络中使用的标记的映射功能。
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.
如果客户需要DSCP透明度，如第5.5.2节所述，L3VPN服务必须将从客户接收的IP报头中的DSCP字段值传递到目的地的出口分界。
The distribution of reachability and routing policy SHOULD be constrained to the sites that are members of the VPN.
可达性和路由策略的分布应限制在作为VPN成员的站点上。
Optionally, the exchange of such information MAY use some form of authentication (e.g., MD5).
可选地，此类信息的交换可以使用某种形式的认证（例如，MD5）。
Functions to isolate the SP network and customer VPNs from anomalous routing behavior from a specific set of customer sites SHOULD be provided. Examples of such functions are controls for route flap dampening, filters that accept only prefixes configured for a specific CE, a maximum number of routes accepted for each CE, or a maximum rate at which route updates can be received from a CE.
应提供将SP网络和客户VPN与一组特定客户站点的异常路由行为隔离开来的功能。此类功能的示例包括路由抖动阻尼控制、仅接受为特定CE配置的前缀的过滤器、为每个CE接受的最大路由数或可从CE接收路由更新的最大速率。
When VPN customers use overlapping non-unique IP addresses, the solution MUST define a means to distinguish between such overlapping addresses on a per-VPN basis.
当VPN客户使用重叠的非唯一IP地址时，解决方案必须定义一种方法来区分每个VPN的重叠地址。
Furthermore, the solution SHOULD provide an option that either allows or prevents advertisement of VPN routes to the Internet.
此外，解决方案应提供一个选项，允许或防止向Internet公布VPN路由。
Ideally, the choice of an SP's IGP SHOULD not depend on the routing protocol(s) used between PE and CE routers in a PE-based VPN.
理想情况下，SP IGP的选择不应取决于基于PE的VPN中PE和CE路由器之间使用的路由协议。
Furthermore, it is desirable that an SP SHOULD have a choice regarding the IGP routing protocol.
此外，希望SP应当具有关于IGP路由协议的选择。
The additional routing burden that an SP must carry should be articulated in each specific L3VPN solution.
SP必须承担的额外路由负担应在每个特定的L3VPN解决方案中明确说明。
The internal structure of an L3VPN network SHOULD not be visible to outside networks (e.g., the Internet or any connected VPN).
L3VPN网络的内部结构不应对外部网络可见（例如，互联网或任何连接的VPN）。
From a high-level SP perspective, a PE-based L3VPN MUST isolate the exchange of traffic and routing information to only those sites that are authenticated and authorized members of a VPN.
从高级SP的角度来看，基于PE的L3VPN必须将流量和路由信息的交换隔离到只有经过身份验证和授权的VPN成员的站点。
In a CE-based VPN, the tunnels that connect the sites effectively meet this isolation requirement if both traffic and routing information flow over the tunnels.
在基于CE的VPN中，如果流量和路由信息都流经隧道，则连接站点的隧道可以有效地满足此隔离要求。
An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA requirements that isolates VPN traffic from the effects of traffic offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a means to isolate the effects that traffic congestion produced by sites as part of one VPN can have on another VPN.
L3VPN解决方案应提供满足L3VPN QoS SLA要求的方法，将VPN流量与非VPN客户提供的流量隔离开来。此外，L3VPN解决方案应提供一种方法，以隔离作为一个VPN的一部分的站点产生的流量拥塞可能对另一个VPN产生的影响。
This section contains requirements related to securing customer flows; providing authentication services for temporary, remote, or mobile users; and protecting service provider resources involved in supporting an L3VPN. More detailed security requirements are provided in [VPNSEC].
本节包含与确保客户流安全相关的要求；为临时、远程或移动用户提供身份验证服务；以及保护支持L3VPN所涉及的服务提供商资源。[VPNSEC]中提供了更详细的安全要求。
In order to meet the general requirement for providing a range of security options to a customer, each L3VPN solution MUST clearly spell out the configuration options that can work together and how they can do so.
为了满足向客户提供一系列安全选项的一般要求，每个L3VPN解决方案必须明确说明可以协同工作的配置选项以及它们如何协同工作。
When a VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a flow for a specified subset of a customer's VPN traffic:
当VPN解决方案在Internet的一部分上运行时，它应支持一个可配置选项，以支持以下一个或多个标准IPsec方法，用于保护客户VPN流量的指定子集的流量：
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 保密性，以便只有授权设备才能对其进行解密o完整性，以确保数据未被更改o身份验证，以确保发送者确实是他或她声称的人o防止重播攻击。
The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites between temporary users and sites, and even between temporary users. It SHOULD also be possible to apply these functions to "control traffic", such as routing protocol exchanges, that are not necessarily perceived by the customer but are nevertheless essential to maintain his or her VPN.
上述功能应适用于客户的“数据流量”，包括临时用户和站点之间，甚至临时用户之间的站点间交换流量。还可以将这些功能应用于“控制流量”，例如路由协议交换，这些功能不一定被客户感知，但对于维护其VPN来说是必不可少的。
Furthermore, such security methods MUST be configurable between different end points, such as CE-CE, PE-PE, and CE-PE. It is also desirable to configure security on a per-route or per-VPN basis [VPNSEC].
此外，这些安全方法必须在不同的端点之间进行配置，例如CE-CE、PE-PE和CE-PE。还希望在每个路由或每个VPN的基础上配置安全性[VPNSEC]。
A VPN solution MAY support one or more encryption schemes, including AES, and 3DES. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system.
VPN解决方案可以支持一个或多个加密方案，包括AES和3DE。加密、解密和密钥管理应作为安全管理系统的一部分包含在配置文件中。
A service provider MUST provide authentication services in support of temporary user access requirements, as described in section 5.11.2.
如第5.11.2节所述，服务提供商必须提供认证服务，以支持临时用户访问要求。
Furthermore, traffic exchanged within the scope of VPN MAY involve several categories of equipment that must cooperate to provide the service [Y.1311.1]. These network elements can be CE, PE, firewalls, backbone routers, servers, management stations, etc. These network elements learn about each other's identity, either via manual configuration or via discovery protocols, as described in section 6.4. When network elements must cooperate, these network elements SHALL authenticate peers before providing the requested service. This authentication function MAY also be used to control access to network resources.
此外，在VPN范围内交换的流量可能涉及必须合作提供服务的几类设备[Y.1311.1]。这些网元可以是CE、PE、防火墙、主干路由器、服务器、管理站等。这些网元通过手动配置或发现协议（如第6.4节所述）了解彼此的身份。当网络元件必须协作时，这些网络元件应在提供请求的服务之前对对等方进行身份验证。此身份验证功能还可用于控制对网络资源的访问。
The peer identification and authentication function described above applies only to network elements participating in the VPN. Examples include:
上述对等识别和认证功能仅适用于参与VPN的网络元件。例子包括：
- traffic between a CE and a PE, - traffic between CEs belonging to the same VPN, - CE or PE routers dealing with route announcements for a VPN, - policy decision point [RFC3198] and a network element, and - management station and an SNMP agent.
- CE和PE之间的通信量，-属于同一VPN的CE之间的通信量，-处理VPN路由公告的CE或PE路由器，-策略决策点[RFC3198]和网元，以及-管理站和SNMP代理。
For a peer authentication function, each L3VPN solution SHOULD describe where necessary, how it shall be implemented, how secure it must be, and the way to deploy and maintain identification and authentication information necessary to operate the service.
对于对等身份验证功能，每个L3VPN解决方案应在必要时说明，应如何实施，其安全性必须如何，以及部署和维护运营服务所需的标识和身份验证信息的方式。
Recall from the definitions in section 3.3 that a site can be part of an intranet with sites from the only same organization, can be part of an extranet involving sites from other organizations, can have access to the Internet, or can have any combination of these scopes of communication. Within these contexts, a site might be subject to various attacks coming from different sources. Potential sources of attack include:
回顾第3.3节中的定义，站点可以是内部网的一部分，其中包含来自同一组织的站点，可以是涉及其他组织站点的外部网的一部分，可以访问Internet，或者可以具有这些通信范围的任意组合。在这些情况下，站点可能会受到来自不同来源的各种攻击。潜在攻击源包括：
- 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主干网的用户、来自Internet的用户和来自属于该站点所属intranet和/或extranet VPN的临时站点的用户。
Security threats and risks that a site may encounter include the following:
站点可能遇到的安全威胁和风险包括：
- Denial of service, for example mail spamming, access connection congestion, TCP SYN attacks, and ping attacks - Intrusion attempts, which may eventually lead to denial of service (e.g., a Trojan horse attack).
- 拒绝服务，例如邮件垃圾邮件、访问连接拥塞、TCP SYN攻击和ping攻击-入侵企图，最终可能导致拒绝服务（例如特洛伊木马攻击）。
Additional threat scenarios are defined in [VPNSEC]. An L3VPN solution MUST state how it addresses each potential threat scenario.
[VPNSEC]中定义了其他威胁场景。L3VPN解决方案必须说明如何解决每个潜在威胁场景。
The devices in the L3VPN network must provide some means of reporting intrusion attempts to the service provider resources.
L3VPN网络中的设备必须提供某种向服务提供商资源报告入侵企图的方法。
The scenario for VPNs spanning multiple Autonomous Systems (AS) or Service Providers (SP) requires standard solutions. The scenario where multiple ASes are involved is the most general case and is therefore the one described here. The scenarios of concern are the CE-based and PE-based L3VPNs defined in section 3.
跨多个自治系统（AS）或服务提供商（SP）的VPN场景需要标准解决方案。涉及多个ASE的场景是最常见的情况，因此这里描述的就是这种情况。关注的场景是第3节中定义的基于CE和基于PE的L3VPN。
In each scenario, all applicable SP requirements, such as traffic and routing isolation, SLAs, management, security, and provisioning. MUST be preserved across adjacent ASes. The solutions MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters [VPNIW].
在每个场景中，所有适用的SP要求，如流量和路由隔离、SLA、管理、安全性和资源调配。必须跨相邻的ASE进行保存。解决方案必须描述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的一个基本先决条件是相关ASE之间的协议，该协议至少规定了信任、经济和管理责任。
The overall scalability of the VPN service MUST allow the L3VPN service to be offered across potentially hundreds of SPs, with the overall scaling parameters per SP given in [RFC3809].
VPN服务的总体可扩展性必须允许跨数百个SP提供L3VPN服务，每个SP的总体可扩展参数在[RFC3809]中给出。
If the link between ASes is not trusted, routing protocols running between those ASes MUST support some form of authentication. For example, the TCP option for carrying an MD5 digest may be used to enhance security for BGP [RFC2385].
如果ASE之间的链路不受信任，那么在这些ASE之间运行的路由协议必须支持某种形式的身份验证。例如，用于携带MD5摘要的TCP选项可用于增强BGP[RFC2385]的安全性。
BGP MUST be supported as the standard inter-AS routing protocol to control the path taken by L3VPN traffic.
必须支持BGP作为标准as间路由协议，以控制L3VPN流量所采用的路径。
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities as follows:
管理单个AS的一般要求适用于ASE的串联。此类能力的最小子集如下所示：
- Diagnostic tools (e.g., ping, traceroute) - Secured access to one AS management system by another - Configuration request and status query tools - Fault notification and trouble-tracking tools
- 诊断工具（如ping、traceroute）-由另一个AS管理系统安全访问一个AS管理系统-配置请求和状态查询工具-故障通知和故障跟踪工具
When a VPN spans multiple ASes, a brokering mechanism is desired that requests certain SLA parameters, such as bandwidth and QoS, from the other domains and/or networks involved in transferring traffic to various sites. Although bandwidth and QoS brokering across multiple ASes is not common in today's networks, these may be desirable for maintaining SLAs in inter-AS VPNs. This section describes requirements for features that would facilitate these mechanisms. The objective is that a solution SHOULD be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of an L3VPN.
当VPN跨越多个ASE时，需要一种代理机制，从涉及将流量传输到各个站点的其他域和/或网络请求某些SLA参数，例如带宽和QoS。虽然在当今的网络中，跨多个ASE的带宽和QoS代理并不常见，但这些可能是在跨AS VPN中维护SLA所需要的。本节描述了促进这些机制的功能的需求。目标是解决方案应该能够确定一组ASE是否能够建立并保证支持L3VPN的统一QoS。
The brokering mechanism can be a manual one, for example, in which one provider requests from another a specific set of bandwidth and QoS parameters for traffic going to and from a specific set of sites. The mechanism could also be an automated one where a device dynamically requests and receives certain bandwidth and SLA/QoS parameters. For instance, in the case of an L3VPN over MPLS, a PE may negotiate the label for different traffic classes to reach a PE residing in a neighboring AS. Or, it might be a combination of both. For additional detailed requirements on the automated approach, see [TE-INTERAS].
代理机制可以是手动机制，例如，其中一个提供商向另一个提供商请求特定的带宽和QoS参数集，以用于进出特定站点集的流量。该机制也可以是自动机制，其中设备动态请求并接收特定带宽和SLA/QoS参数。例如，在MPLS上的L3VPN的情况下，PE可以协商不同业务类别的标签以到达驻留在相邻AS中的PE。或者，这可能是两者的结合。有关自动进近的其他详细要求，请参见[TE-INTERAS]。
Brokering on a per VPN basis is not desirable as this approach would not scale. A solution MUST provide some means to aggregate QoS and bandwidth brokering requests between ASes. One method could be for SPs to make an agreement specifying the maximum amount of bandwidth for specific QoS parameters for all VPN customers using the SP network. Alternatively, such aggregation might be on a per hierarchical tunnel basis between PE routers in different ASes supporting an L3VPN service [TE-INTERAS].
基于每个VPN的代理是不可取的，因为这种方法无法扩展。解决方案必须提供某种方法来聚合ASE之间的QoS和带宽代理请求。一种方法是SP签订协议，为使用SP网络的所有VPN客户指定特定QoS参数的最大带宽量。或者，这种聚合可以基于支持L3VPN服务[TE-INTERAS]的不同ASE中的PE路由器之间的分层隧道。
If a tunnel traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. These security mechanisms include encryption, authentication, and resource protection, as described in section 6.9, and security management, as covered in section 7.5. For example, a provider should consider using both authentication and encryption for a tunnel used as part of an L3VPN that traverses another service provider's network.
如果隧道穿越多个SP网络并通过不安全的SP、POP、NAP或IX，则必须采用安全机制。这些安全机制包括第6.9节所述的加密、身份验证和资源保护，以及第7.5节所述的安全管理。例如，提供商应该考虑使用作为跨L3VPN的一部分的隧道的认证和加密，该隧道遍历另一服务提供商的网络。
The architecture MUST support the possibility of one service provider offering VPN service to another service provider. Another example is when one service provider sells L3VPN service at wholesale to another service provider, who then resells that VPN service to his or her customers.
该体系结构必须支持一个服务提供商向另一个服务提供商提供VPN服务的可能性。另一个例子是，一家服务提供商将L3VPN服务批发给另一家服务提供商，后者随后将该VPN服务转售给其客户。
The wholesaler's VPN MUST be transparent to the addressing and routing used by the reseller.
批发商的VPN必须对经销商使用的地址和路由透明。
Support for additional levels of hierarchy (for example, three levels at which a reseller can again resell the VPN service to yet another VPN provider) SHOULD be provided.
应提供对其他层次结构级别的支持（例如，转销商可以再次将VPN服务转销给另一个VPN提供商的三个级别）。
The Carrier's Carrier scenario is the term used in this document for this category of L3VPN wholesale (although some scenarios of Inter-
运营商的运营商场景是本文件中用于这类L3VPN批发的术语（尽管有些场景-
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/供应商间VPN也可能属于此类别）。应支持各种运营商的运营商场景，例如
- the customer carriers do not operate L3VPN services for their clients; - the customer carriers operate L3VPN services for their clients, but these services are not linked with the L3VPN service offered by the Carrier's Carrier and - the customer carriers operate L3VPN services for their clients, and these services are linked with the L3VPN service offered by the Carrier's Carrier ("Hierarchical VPNs" scenario).
- 客户运营商不为其客户提供L3VPN服务；-客户运营商为其客户提供L3VPN服务，但这些服务不与运营商的运营商提供的L3VPN服务相链接，并且-客户运营商为其客户提供L3VPN服务，这些服务与运营商的运营商提供的L3VPN服务相链接（“分层VPN”场景）。
Connectivity between CE sites or PE devices in the backbone SHOULD use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-in-IP, and MPLS.
主干网中CE站点或PE设备之间的连接应使用一系列隧道技术，如L2TP、IPSEC、GRE、IP中的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:
为了在路由器之间建立隧道，每个路由器必须支持隧道的静态配置，并且可以支持隧道设置协议。如果采用，隧道建立协议应能够传输以下信息：
- Relevant identifiers - QoS/SLA parameters - Restoration parameters - Multiplexing identifiers - Security parameters
- 相关标识符-QoS/SLA参数-恢复参数-多路复用标识符-安全参数
There MUST be a means to monitor the following aspects of tunnels:
必须有一种方法来监控隧道的以下方面：
- Statistics, such as amount of time spent in the up and down state. - Count of transitions between the up and down state. - Events, such as transitions between the up and down states.
- 统计数据，例如在上升和下降状态下花费的时间量。-向上和向下状态之间的转换计数。-事件，例如向上和向下状态之间的转换。
The tunneling technology used by the VPN Service Provider and its associated mechanisms for tunnel establishment, multiplexing, and maintenance MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc.
VPN服务提供商使用的隧道技术及其用于隧道建立、多路复用和维护的相关机制必须满足扩展、隔离、安全、QoS、可管理性等方面的要求。
This section describes requirements for aspects of access and backbone network technologies from an SP point of view.
本节从SP的角度描述接入和骨干网络技术方面的要求。
Some SPs MAY desire that a single network infrastructure suffices for all services, public IP, VPNs, traffic engineering, and differentiated services [L2VPN].
一些SP可能希望单个网络基础设施足以满足所有服务、公共IP、VPN、流量工程和差异化服务[L2VPN]。
Ideally, the L3VPN service SHOULD be independent of physical, link layer, or even network technology of the access network. However, the characteristics of access networks MUST be accounted for when the QoS aspects of SLAs for VPN service offerings are specified.
理想情况下，L3VPN服务应独立于接入网络的物理、链路层甚至网络技术。但是，在指定VPN服务产品的SLA的QoS方面时，必须考虑接入网络的特性。
Service providers SHOULD be able to support temporary user access, as described in section 5.11.2, by using dedicated or dial-in access network technology.
如第5.11.2节所述，服务提供商应能够通过使用专用或拨号接入网络技术支持临时用户访问。
L3VPN solutions MUST support the case where a VPN user directly accesses the VPN service through an access network connected to the service provider. They MUST also describe how they can support the case where one or more other service provider networks are used for access to the service provider supporting the L3VPN service.
L3VPN解决方案必须支持VPN用户通过连接到服务提供商的接入网络直接访问VPN服务的情况。他们还必须描述如何支持使用一个或多个其他服务提供商网络访问支持L3VPN服务的服务提供商的情况。
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.
理想情况下，识别和验证内部网用户所需的所有信息应由客户存储和维护。在外联网中，一个客户应该能够维护身份验证服务器，或者外联网中涉及的客户可以选择将该功能外包给服务提供商。
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.
标识和身份验证信息可供服务提供商用于控制访问，或者服务提供商可查询客户维护的服务器。此外，一个SP可以充当提供VPN服务的SP的访问。如果访问SP代表VPN SP执行标识和身份验证，则必须就通用规范达成协议。
Support for at least the following authentication protocols SHALL be supported: PAP, CHAP, and EAP, as they are currently used in a wide range of equipment and services.
应至少支持以下认证协议：PAP、CHAP和EAP，因为它们目前在广泛的设备和服务中使用。
Ideally, the backbone interconnecting SP, PE, and P devices SHOULD be independent of physical and link layer technology. Nevertheless, the characteristics of backbone technology MUST be taken into account when specifying the QoS aspects of SLAs for VPN service offerings.
理想情况下，主干互连SP、PE和P设备应独立于物理层和链路层技术。然而，在为VPN服务产品指定SLA的QoS方面时，必须考虑主干网技术的特点。
When primary and secondary access connections are available, an L3VPN solution MUST provide restoration of access connectivity whenever the primary access link from a CE site to a PE fails. This capability SHOULD be as automatic as possible, that is, the traffic should be directed over the secondary link soon after failure of the primary access link is detected. Furthermore, reversion to the primary link SHOULD be dynamic, if configured to do so [VPN-NEEDS].
当主访问连接和辅助访问连接可用时，L3VPN解决方案必须在从CE站点到PE的主访问链接出现故障时提供访问连接恢复。该功能应尽可能自动，即，在检测到主接入链路故障后，应立即通过辅助链路引导流量。此外，如果配置为动态恢复到主链路[VPN-NEEDS]。
As mentioned in section 5.11.4, in the case of multi-homing, the load balancing capability MAY be used to achieve a degree of redundancy in the network. In the case of failure of one or more (but not all) of the multi-homed links, the load balancing parameters MAY be dynamically adjusted to redirect the traffic rapidly from the failed link(s) to the surviving links. Once the failed link(s) is (are) restored, the original provisioned load balancing ratio SHOULD be restored to its value prior to the failure.
如第5.11.4节所述，在多主的情况下，负载平衡能力可用于实现网络中的冗余度。在多宿链路中的一个或多个（但不是全部）发生故障的情况下，可以动态调整负载平衡参数以将业务从故障链路快速重定向到幸存链路。故障链路恢复后，应将原始配置的负载平衡比率恢复到故障前的值。
An SP SHOULD be able to deploy protection and restoration mechanisms within his or her backbone infrastructure to increase reliability and fault tolerance of the VPN service offering. These techniques SHOULD be scalable, and therefore should strive not to perform such function in the backbone on a per-VPN basis.
SP应该能够在其主干基础设施中部署保护和恢复机制，以提高VPN服务的可靠性和容错性。这些技术应具有可扩展性，因此应尽量避免在每个VPN的基础上在主干网中执行此类功能。
Appropriate measurements and alarms that indicate how well network protection and restoration mechanisms are performing MUST be supported.
必须支持指示网络保护和恢复机制执行情况的适当测量和警报。
Service providers are interested in interoperability in at least the following scenarios:
服务提供商至少对以下场景中的互操作性感兴趣：
- Facilitating use of PE and managed CE devices within a single SP network. - Implementing L3VPN services across two or more interconnected SP networks.
- 促进在单个SP网络中使用PE和受管CE设备。-跨两个或多个互连的SP网络实施L3VPN服务。
- Achieving interworking or interconnection between customer sites using different L3VPN approaches or different implementations of the same approach.
- 使用不同的L3VPN方法或相同方法的不同实现在客户站点之间实现互通或互连。
Each approach MUST describe whether any of the above objectives can be met. If an objective can be met, the approach MUST describe how such interoperability could be achieved. In particular, the approach MUST describe the inter-solution network interface, encapsulation method(s), routing protocol(s), security, isolation, management, and all other applicable aspects of the overall VPN solution provided [VPNIW].
每种方法必须说明是否能够实现上述任何目标。如果能够实现一个目标，该方法必须描述如何实现这种互操作性。特别是，该方法必须描述解决方案间网络接口、封装方法、路由协议、安全性、隔离、管理以及提供的整个VPN解决方案的所有其他适用方面[VPNIW]。
Service providers MUST have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis to an L3VPN approach.
服务提供商必须有一种优雅的方式，以最小的服务中断将客户逐站点迁移到L3VPN方法。
If L3VPN approaches can interwork or interconnect, then service providers MUST have a graceful means to migrate a customer with minimal service disruption on a site-by-site basis whenever interworking or interconnection is changed.
如果L3VPN方法可以互通或互连，那么无论何时互通或互连发生变化，服务提供商都必须有一种优雅的方法，在每个站点的基础上以最小的服务中断迁移客户。
A service provider MUST have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. Furthermore, an SP MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers.
服务提供商必须能够查看拓扑、操作状态、订单状态以及与每个客户的VPN相关的其他参数。此外，SP必须能够查看底层逻辑和物理拓扑、操作状态、配置状态以及与向其客户提供VPN服务的设备相关的其他参数。
Currently, proprietary methods are often used to manage VPNs. The additional expense associated with operators using multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. Therefore, devices SHOULD provide standards-based interfaces wherever feasible.
目前，专有方法通常用于管理VPN。操作员使用多种专有管理方法（如命令行界面（CLI）语言）访问此类系统所产生的额外费用是不可取的。因此，设备应尽可能提供基于标准的接口。
The remainder of this section presents detailed SP management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. Much of this text was adapted from ITU-T Y.1311.1.
本节的其余部分介绍了网络管理系统（NMS）在传统故障、配置、记帐、性能和安全（FCAPS）管理类别中的详细SP管理要求。本文大部分内容改编自ITU-T Y.1311.1。
Support for fault management includes:
对故障管理的支持包括：
- indication of customers impacted by failure, - fault detection (incidents reports, alarms and failure visualization), - fault localization (analysis of alarms reports and diagnostics), - incident recording or logs (creation and follow-through of trouble tickets), and - corrective actions (traffic, routing, and resource allocation).
- 指示受故障影响的客户，-故障检测（事件报告、警报和故障可视化），-故障定位（警报报告和诊断分析），-事件记录或日志（创建和跟踪故障单），以及-纠正措施（流量、路由和资源分配）。
As PE-based VPNs rely on a common network infrastructure, the NMS MUST provide a means to inform the provider of the VPN customers impacted by a failure in the infrastructure. The NMS SHOULD provide pointers to the related customer configuration information to aid in fault isolation and determining corrective action.
由于基于PE的VPN依赖于公共网络基础设施，因此NMS必须提供一种方法，告知提供商受基础设施故障影响的VPN客户。NMS应提供指向相关客户配置信息的指针，以帮助进行故障隔离和确定纠正措施。
Detecting faults caused by configuration errors is desirable, because these may cause VPN service failure or may disrupt other requirements (e.g., traffic and routing isolation). This is a likely case of compromised security [VPNSEC]. Detection of such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. One approach could be a protocol that systematically checks whether all constraints and consistency checks hold among tunnel configuration parameters at the various end points.
检测由配置错误引起的故障是可取的，因为这些可能会导致VPN服务失败或中断其他要求（例如，流量和路由隔离）。这可能是安全性受损[VPNSEC]的情况。检测此类错误本质上是困难的，因为该问题涉及多个节点，并且可能跨越全局。一种方法可以是一种协议，该协议系统地检查在不同端点的隧道配置参数之间是否存在所有约束和一致性检查。
A capability to verify L3 reachability within a VPN MUST be provided for diagnostic purposes.
为了进行诊断，必须提供验证VPN内L3可达性的功能。
A capability to verify the parameter configuration of a device supporting an L3VPN MUST be provided for diagnostic purposes.
出于诊断目的，必须提供验证支持L3VPN的设备的参数配置的功能。
Overall, the NMS must support a configuration necessary to realize the desired L3-reachability of an L3VPN. Toward this end, an NMS MUST provide configuration management to provision at least the following L3VPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option MUST also be configurable.
总的来说，NMS必须支持实现L3VPN所需的L3可达性所需的配置。为此，NMS必须提供配置管理，以提供至少以下L3VPN组件：PE、CE、分层隧道、访问连接、路由和QoS，如本节所述。如果提供对Internet的共享访问，则此选项也必须是可配置的。
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必须确保
these devices and protocols are provisioned consistently and correctly.
这些设备和协议的供应一致且正确。
Provisioning for adding or removing sites SHOULD be as localized and automated as possible.
添加或删除站点的资源调配应尽可能本地化和自动化。
Configuration management for VPNs, according to service templates defined by the provider MUST be supported. A service template contains fields that, when used, yield a definite service requirement or policy. For example, a template for an IPSec tunnel would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, pre-shared keys (if any), and traffic filters. An SLA template would contain fields such as delay, jitter, and throughput and packet loss thresholds, as well as end points over which the SLA has to be satisfied. In general, a customer's service order can be regarded as a set of instantiated service templates. This set can, in turn, be regarded as the logical service architecture of the customer's VPN.
必须支持根据提供商定义的服务模板对VPN进行配置管理。服务模板包含的字段在使用时会产生明确的服务需求或策略。例如，IPSec隧道的模板将包含诸如隧道端点、身份验证模式、加密和身份验证算法、预共享密钥（如果有）和流量过滤器等字段。SLA模板将包含延迟、抖动、吞吐量和丢包阈值等字段，以及必须满足SLA的端点。通常，客户的服务订单可以被视为一组实例化的服务模板。反过来，该集合可以被视为客户VPN的逻辑服务架构。
Service templates can also be used by the provider to define the service architecture of the provider's own network. For example, OSPF templates could contain fields such as the subnets that form a particular area, the area identifier, and the area type. BGP service template could contain fields that, when used, would yield a BGP policy, such as for expressing a preference about an exit router for a particular destination.
服务模板也可由提供商用于定义提供商自己网络的服务体系结构。例如，OSPF模板可以包含诸如形成特定区域的子网、区域标识符和区域类型等字段。BGP服务模板可以包含一些字段，这些字段在使用时会产生BGP策略，例如用于表示特定目的地的出口路由器的首选项。
The set of service templates SHOULD be comprehensive in that it can capture all service orders in some meaningful sense.
服务模板集应该是全面的，因为它可以在某种意义上捕获所有服务订单。
The provider SHOULD provide means to translate service templates into device configurations so that associated services can be provisioned.
提供商应提供将服务模板转换为设备配置的方法，以便提供相关服务。
Finally, the approach SHOULD provide means to check whether a service order is correctly provisioned. This would represent one method of diagnosing configuration errors. Configuration errors can arise due to a variety of reasons: manual configuration, intruder attacks, and conflicting service requirements.
最后，该方法应提供检查服务订单是否正确供应的方法。这将代表一种诊断配置错误的方法。配置错误可能由多种原因引起：手动配置、入侵者攻击和服务需求冲突。
Requirements for configuration management unique to a PE-based VPN are as follows:
基于PE的VPN特有的配置管理要求如下：
o The NMS MUST support configuration of at least the following aspects of L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, and tunnels.
o NMS必须至少支持L3 PE路由器以下方面的配置：内部网和外部网成员资格、每个访问连接的CE路由协议、路由度量和隧道。
o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs, hierarchical tunnels, and access connections, as described in section 6.3.
o 如第6.3节所述，NMS应使用SP、L3VPN、PE、CE、分层隧道和接入连接的标识符。
o Tunnels MUST be configured between PE and P devices. This requires coordination of identifiers of tunnels, hierarchical tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
o 必须在PE和P设备之间配置通道。这需要协调隧道、分层隧道、VPN和任何相关服务信息（例如，QoS/SLA服务）的标识符。
o Routing protocols running between PE routers and CE devices MUST be configured per VPN.
o PE路由器和CE设备之间运行的路由协议必须按照VPN进行配置。
o For multicast service, multicast routing protocols MUST also be configurable.
o 对于多播服务，多播路由协议也必须是可配置的。
o Routing protocols running between PE routers and between PE and P routers MUST also be configured.
o 还必须配置PE路由器之间以及PE和P路由器之间运行的路由协议。
o The configuration of a PE-based L3VPN MUST be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks interconnecting components of an L3VPN.
o 基于PE的L3VPN的配置必须与底层基础设施的配置相协调，包括连接L3VPN组件的第1层和第2层网络。
Requirements for configuration management unique to a CE-based VPN are as follows:
基于CE的VPN特有的配置管理要求如下：
o Tunnels MUST be configured between CE devices. This requires coordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service.
o 必须在CE设备之间配置通道。这需要协调隧道、VPN和任何相关服务信息（例如，QoS/SLA服务）的标识符。
o Routing protocols running between PE routers and CE devices MUST be configured. For multicast service, multicast routing protocols MUST also be configurable.
o 必须配置在PE路由器和CE设备之间运行的路由协议。对于多播服务，多播路由协议也必须是可配置的。
A means for a service provider to provision parameters for the IGP for an L3VPN MUST be provided. This includes link level metrics, capacity, QoS capability, and restoration parameters.
必须提供服务提供商为L3VPN的IGP提供参数的方法。这包括链路级指标、容量、QoS能力和恢复参数。
A service provider MUST have the means to provision network access between SP-managed PE and CE, as well as the case where the customer manages the CE.
服务提供商必须能够在SP管理的PE和CE之间以及在客户管理CE的情况下提供网络访问。
When a security service is requested, an SP MUST have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE or the PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis.
当请求安全服务时，SP必须能够提供与服务相关的实体和相关参数。例如，对于IPsec服务，必须在CE或PE上设置隧道、选项、密钥和其他参数。对于入侵检测服务，必须在VPN基础上提供过滤和检测规则。
A service provider MUST have a means to provision resources associated with VPN services dynamically. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable.
服务提供商必须具有动态提供与VPN服务关联的资源的方法。例如，在基于PE的服务中，虚拟交换和转发表实例的数量和大小必须是可设置的。
Dynamic VPN resource assignment is crucial for coping with the frequent change requests from customers (e.g., sites joining or leaving a VPN), as well as for achieving scalability. The PEs SHOULD be able to dynamically assign the VPN resources dynamically. This capability is especially important for dial and wireless VPN services.
动态VPN资源分配对于处理来自客户的频繁更改请求（例如，加入或离开VPN的站点）以及实现可伸缩性至关重要。PEs应该能够动态地分配VPN资源。此功能对于拨号和无线VPN服务尤为重要。
If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system MUST be able to make requested changes within the ranges and bounds specified in the SLA. Examples of SLA parameters are response time and probability of being able to service such a request.
如果SP支持“动态带宽管理”服务，则调配系统必须能够在SLA中指定的范围和界限内进行请求的更改。SLA参数的示例包括响应时间和能够为此类请求提供服务的概率。
An L3VPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services. (for example, Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, and backup). It is outside of the scope of this document to define whether and how these different services interact with the VPN to solve issues such as addressing, integrity, and security. However, the VPN service MUST be able to provide access to these various types of value-added services.
L3VPN服务通过公共主干网在一组站点之间提供受控访问。然而，许多服务提供商也提供一系列增值服务。（例如，Internet访问、防火墙服务、入侵保护、IP电话和IP Centrex、应用程序托管和备份）。定义这些不同的服务是否以及如何与VPN交互以解决寻址、完整性和安全性等问题超出了本文档的范围。但是，VPN服务必须能够提供对这些不同类型增值服务的访问。
A VPN service SHOULD allow the SP to supply the customer with different kinds of standard IP services, such as DNS, NTP, and RADIUS, that are needed for ordinary network operation and management. The provider SHOULD be able to provide IP services to multiple VPN customers.
VPN服务应允许SP向客户提供普通网络运营和管理所需的各种标准IP服务，如DNS、NTP和RADIUS。提供商应该能够向多个VPN客户提供IP服务。
A firewall function MAY be required to restrict access to the L3VPN from the Internet [Y.1311].
可能需要防火墙功能来限制从Internet访问L3VPN[Y.1311]。
A managed firewall service MUST be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Managed firewall services that may be provided include dropping specified protocol types, intrusion protection, and traffic-rate limiting against malicious attacks.
托管防火墙服务必须为运营商级别。对于冗余和故障恢复，应提供防火墙故障转移的方法。可提供的托管防火墙服务包括删除指定的协议类型、入侵保护和针对恶意攻击的流量限制。
Managed firewalls MUST be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device (e.g., in a PE-based solution). Managed firewalls SHOULD be provided at the major access point(s) for the L3VPN. Managed firewall services may be embedded in CE or PE device or implemented in standalone devices.
必须基于每个VPN支持托管防火墙，尽管同一物理设备可能支持多个VPN（例如，在基于PE的解决方案中）。应在L3VPN的主要接入点提供托管防火墙。托管防火墙服务可以嵌入CE或PE设备中，也可以在独立设备中实现。
The NMS SHOULD allow a customer to outsource the management of an IP networking service to the SP providing the VPN or to a third party.
NMS应允许客户将IP网络服务的管理外包给提供VPN的SP或第三方。
The NMS SHOULD support collection of information necessary for optimal allocation of IP services in response to customer orders.
NMS应支持为响应客户订单而优化IP服务分配所需的信息收集。
Reachability to and from the Internet to sites within a VPN MUST be configurable by an SP. This could be controlled by configuring routing policy to control distribution of VPN routes advertised to the Internet.
SP必须能够配置从Internet到VPN内站点的可达性。这可以通过配置路由策略来控制向Internet公布的VPN路由的分布。
Configuration of interworking or interconnection between L3VPN solutions SHOULD be also supported. Ensuring that security and end-to-end QoS issues are provided consistently SHOULD be addressed.
还应支持L3VPN解决方案之间的互通或互连配置。应解决确保始终如一地提供安全性和端到端QoS问题。
Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS MAY need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time when the SLS is not met.
许多服务提供商需要收集有关资源使用情况的度量数据，以便进行会计核算。NMS可能需要将会计信息与性能和故障管理信息关联起来，以产生在不满足SLS的时间段内考虑SLA规定的计费。
An L3VPN solution MUST describe how the following accounting functions can be provided:
L3VPN解决方案必须说明如何提供以下记帐功能：
- Measurements of resource utilization. - collection of accounting information. - storage and administration of measurements.
- 资源利用率的测量会计信息的收集测量的存储和管理。
Some providers may require near - real time reporting of measurement information and may offer this as part of a customer network management service.
一些提供商可能需要测量信息的近实时报告，并可能将其作为客户网络管理服务的一部分提供。
If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts, and interval required to perform requested bandwidth allocation change(s) MUST be traceable for monitoring and accounting purposes.
如果SP支持“动态带宽管理”服务，则执行请求的带宽分配更改所需的日期、时间、金额和间隔必须可跟踪，以便进行监视和记帐。
Solutions should state compliance with accounting requirements, as described in section 1.7 of RFC 2975 [RFC2975].
解决方案应说明符合RFC 2975[RFC2975]第1.7节所述的会计要求。
Performance management MUST support functions involved with monitoring and collecting performance data for devices, facilities, and services, as well as determining conformance to SLS, such as QoS and availability measurements.
性能管理必须支持与监视和收集设备、设施和服务的性能数据有关的功能，以及确定与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.
性能管理还应支持对L3VPN的重要方面的分析，例如带宽利用率、响应时间、可用性、QoS统计数据以及基于收集的数据的趋势。
The NMS MUST monitor device behavior to evaluate performance metrics associated with an SLA. Different measurement techniques may be necessary depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques MAY be either intrusive or non-intrusive depending on the parameters being monitored.
NMS必须监控设备行为，以评估与SLA相关的性能指标。根据为其提供SLA的服务，可能需要不同的测量技术。示例服务包括QoS、安全性、多播和临时访问。这些技术可以是侵入式的，也可以是非侵入式的，具体取决于所监测的参数。
The NMS MUST also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization, state of devices, and transmission facilities, as well as control of monitoring resources such as probes and remote agents at network access points used by customers and mobile users.
NMS还必须监控与SLA不直接相关的VPN方面，如资源利用率、设备状态和传输设施，以及监控资源（如客户和移动用户使用的网络接入点处的探测器和远程代理）。
The NMS SHOULD support SLAs between an SP and the various VPN customers according to the corresponding SLSes by measurement of the indicators defined within the context of the SLA, on a regular basis.
NMS应根据相应的SLSE，通过定期测量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.
NMS应使用IETF IP性能度量（IPPM）工作组为延迟、丢失和延迟变化定义的QoS参数测量定义、技术和方法。
The NMS SHOULD support allocation and measurement of end-to-end QoS requirements to QoS parameters for one or more VPN network(s).
NMS应支持为一个或多个VPN网络的QoS参数分配和测量端到端QoS要求。
Devices supporting L3VPN SLAs SHOULD have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable.
支持L3VPN SLA的设备应具有实时性能测量，该测量具有指示器和阈值交叉警报。这些阈值应该是可配置的。
The security management function of the NMS MUST include management features to guarantee the security of devices, access connections, and protocols within the L3VPN network(s), as well as the security of customer data and control as described in section 6.9.
NMS的安全管理功能必须包括管理功能，以保证L3VPN网络内设备、访问连接和协议的安全，以及第6.9节所述的客户数据和控制的安全。
Resource access control determines the privileges that a user has to access particular applications and VPN network resources. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the L3VPN network unprotected. Access control capabilities protect these devices to ensure that users have access only to the resources and applications they are authorized to use.
资源访问控制确定用户访问特定应用程序和VPN网络资源的权限。如果没有这种控制，只有数据和控制流量的安全性受到保护，而提供L3VPN网络的设备则不受保护。访问控制功能保护这些设备，以确保用户只能访问其授权使用的资源和应用程序。
In particular, access to the routing and switching resources managed by the SP MUST be tightly controlled to prevent and/or effectively mitigate a malicious attack. More detailed requirements in this area are described in [VPNSEC].
特别是，必须严格控制对SP管理的路由和交换资源的访问，以防止和/或有效缓解恶意攻击。[VPNSEC]中描述了该领域更详细的要求。
Authentication is the process of verifying that the sender is actually who he or she claims to be. The NMS MUST support standard methods for authenticating users attempting to access management services.
身份验证是验证发件人是否是他或她自称的人的过程。NMS必须支持对试图访问管理服务的用户进行身份验证的标准方法。
Scalability is critical, as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments MUST be manageable for large numbers of users and VPN access points.
可扩展性至关重要，因为游牧/移动客户端的数量正在迅速增加。为此类部署实施的身份验证方案必须对大量用户和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,
应支持强身份验证方案，以确保VPN接入点到VPN接入点（例如，基于PE的情况下，PE到PE）和客户端到VPN接入点（例如，基于PE的情况下，CE到PE）通信的安全性。这对于防止VPN接入点欺骗尤其重要，在这种情况下，攻击者试图使PE或CE相信攻击者就是VPN接入点。如果攻击者能够使PE或CE设备相信这一点，
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可能会受到中间人攻击的欺骗，因为端点从不相互验证。弱身份验证的VPN AP可能会受到此类攻击。强身份验证的VPN AP不会受到此类攻击，因为由于强身份验证算法，中间的人无法作为真实的AP进行身份验证。
Each L3VPN solution approach MUST specify the management information bases (MIB) modules for the network elements involved in L3VPN services. This is an essential requirement in network provisioning. The approach SHOULD identify any information not contained in a standard MIB related to FCAPS that is necessary to meet a generic requirement.
每个L3VPN解决方案方法必须为L3VPN服务中涉及的网络元素指定管理信息库（MIB）模块。这是网络资源调配的基本要求。该方法应识别与FCAP相关的标准MIB中未包含的任何信息，这些信息是满足一般要求所必需的。
An IP VPN (Policy) Information model, when available, SHOULD reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ]. This includes the QoS Policy Information Model [QPIM] and the IPSEC Configuration Policy Model [IPSECIM]. The IP VPN Information model SHOULD provide the OSS with adequate "hooks" to correlate service level specifications with traffic data collected from network elements. The use of policies includes rules that control corrective actions taken by OSS components responsible for monitoring the network and ensuring that it meets service requirements.
IP VPN（策略）信息模型（如果可用）应重用针对特定IP网络功能并行开发的策略信息模型[IM-REQ]。这包括QoS策略信息模型[QPIM]和IPSEC配置策略模型[IPSECIM]。IP VPN信息模型应为OSS提供足够的“挂钩”，使服务级别规范与从网络元素收集的流量数据相关联。策略的使用包括控制OSS组件采取纠正措施的规则，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场景。
Some service providers MAY require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers.
一些服务提供商可能要求系统以视觉、听觉或逻辑方式向内部运营商和/或客户呈现FCAPS信息。
Security considerations occur at several levels and dimensions within L3VPNs, as detailed within this document. This section provides a summary with references to detailed supporting information [L3VPN-SEC] [VPNSEC].
如本文档所述，L3VPN中存在多个级别和维度的安全注意事项。本节概述了详细的支持信息[L3VPN-SEC][VPNSEC]。
The requirements in this document separate traditional notions of security requirements, such as integrity, confidentiality, and authentication, from issues such as isolating (or separating) the exchange of VPN data and control traffic between specific sets of sites (as defined in sections 3.3 and 4.1). Further detail on security requirements is given from the customer and service provider perspectives in sections 5.9 and 6.9, respectively. Further detail on data and control traffic isolation requirements are given from the customer and service provider perspectives in sections 5.1 and 6.8, respectively.
本文件中的要求将安全要求的传统概念（如完整性、保密性和身份验证）与隔离（或分离）VPN数据交换和控制特定站点之间的流量（如第3.3节和第4.1节所定义）等问题分开。第5.9节和第6.9节分别从客户和服务提供商的角度给出了有关安全要求的更多详细信息。第5.1节和第6.8节分别从客户和服务提供商的角度给出了数据和控制流量隔离要求的进一步详细信息。
Furthermore, requirements regarding management of security from a service provider perspective are described in section 7.5.
此外，第7.5节描述了从服务提供商角度对安全性进行管理的要求。
The authors of this document would like to acknowledge the contributions from the people who launched the work on VPN requirements inside ITU-T SG13 and the authors of the original IP VPN requirements and framework document [RFC2764], as well as Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Garrec. The authors are also grateful to the helpful suggestions and direction provided by the technical advisors, Alex Zinin, Scott Bradner, Bert Wijnen, and Rob Coltun. Finally, the authors wish to acknowledge the insights and requirements gleaned from the many documents listed in the references section. Citations to these documents were made only where the authors believed that additional insight could be obtained from reading the source document.
本文件的作者要感谢ITU-T SG13内部启动VPN需求工作的人员、原始IP VPN需求和框架文件[RFC2764]的作者以及Tom Worster、Ron Bonica、Sanjai Narain、Muneyoshi Suzuki、Tom Nadeau、Nail Akar、Derek Atkins、，布莱恩·格雷森、格雷格·伯恩斯和弗雷德里克·勒·加勒克。作者还感谢技术顾问Alex Zinin、Scott Bradner、Bert Wijnen和Rob Coltun提供的有益建议和指导。最后，作者希望确认从参考资料部分列出的许多文件中收集到的见解和要求。只有在作者认为可以通过阅读源文件获得更多见解的情况下，才引用这些文件。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC 3377，2002年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年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]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685]Fox，B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809]Nagarajan，A.，“提供商提供的虚拟专用网络（PPVPN）的一般要求”，RFC 3809，2004年6月。
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in Progress.
[2547bis]Rosen，E.，Rekhter，Y.等人，“BGP/MPLS VPN”，正在进行的工作。
[IM-PPVPN] Lago, P., et al., "An Information Model for Provider Provisioned Virtual Private Networks", Work in Progress.
[IM-PPVPN]Lago，P.等人，“提供商提供的虚拟专用网络的信息模型”，正在进行中。
[IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy Information Model", Work in Progress.
[IM-REQ]Iyer，M.等人，“IP VPN策略信息模型的要求”，正在进行中。
[IPSECIM] Jason, J., "IPsec Configuration Policy Model", Work in Progress.
[IPSECIM]Jason，J.，“IPsec配置策略模型”，正在进行中。
[CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress.
[CE-PPVPN]De Clercq，J.，Paridaens，O.，Krywaniuk，A.，Wang，C.，“使用IPsec的基于提供商提供的CE的虚拟专用网络的体系结构”，正在进行中。
[IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned VPNs", Work in Progress.
[IPSEC-PPVPN]Gleeson，B.，“IPSEC与提供商提供的VPN的使用”，正在进行中。
[L2VPN] Rosen, E., et al., "An Architecture for L2VPNs", Work in Progress.
[L2VPN]Rosen，E.等人，“L2VPN的体系结构”，正在进行中。
[MPLSSEC] Behringer, M., "Analysis of the Security of the MPLS Architecture", Work in Progress.
[MPLSSEC]Behringer，M.，“MPLS体系结构的安全性分析”，正在进行中。
[PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology", Work in Progress.
[PPVPN-TERM]Andersson，L.，Madsen，T.，“PPVPN术语”，正在进行的工作。
[L3VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress.
[L3VPN-SEC]Fang，L.等人，“提供商提供的虚拟专用网络的安全框架”，正在进行中。
[L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress.
[L3VPN-FR]Callon，R.，Suzuki，M.，等，“第3层提供商提供的虚拟专用网络框架”，正在进行中。
[PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network based IP VPN Architecture using Virtual Routers", Work in Progress.
[PPVPN-VR]Knight，P.，Ould Brahim，H.，Gleeson，B.，“使用虚拟路由器的基于网络的IP VPN架构”，正在进行中。
[QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS Information Model", Work in Progress.
[QPIM]Snir、Ramberg、Strassner、Cohen和Moore，“策略QoS信息模型”，正在进行中。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764]Gleeson，B.，Lin，A.，Heinanen，J.，Armitage，G.，和A.Malis，“基于IP的虚拟专用网络框架”，RFC 2764，2000年2月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975]Aboba，B.，Arkko，J.，和D.Harrington，“会计管理导论”，RFC 29752000年10月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年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]威斯特林，A.，施尼兹莱因，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[TE-INTERAS] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering requirements", Work in Progress.
[TE-INTERAS]Zhang，R.，Vasseur，J.P.，“MPLS-INTERAS流量工程要求”，正在进行的工作。
[VPNDISC] Squire, M. et al., "VPN Discovery Discussions and Options", Work in Progress.
[VPNDISC]Squire，M.等人，“VPN发现讨论和选项”，正在进行中。
[VPNIW] Kurakami, H., et al., "Provider-Provisioned VPNs Interworking", Work in Progress.
[VPNIW]Kurakami，H.等人，“提供商提供的VPN互通”，正在进行中。
[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可能的安全扩展的考虑”，正在进行中。
[VPNTUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN Tunnels and Core Connectivity", Work in Progress.
[VPNTUNNEL]Worster，T.等人，“PPVPN层分离：VPN隧道和核心连接”，正在进行中。
[VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., "Criteria for Evaluating VPN Implementation Mechanisms", Work in Progress.
[VPN-CRIT]Yu，J.，Jou，L.，Matthews，A.，Srinivasan，V.，“评估VPN实施机制的标准”，正在进行的工作。
[VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of an IP VPN service offering : a service provider perspective", Work in Progress.
[VPN-NEEDS]Jacquenet，C.“IP VPN服务产品部署的功能需求：服务提供商视角”，正在进行中。
[Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture", Y.1311.1 ITU-T Recommendation, July 2001.
[Y.1311.1]Carugi，M.（编辑），“基于MPLS架构的网络IP VPN”，Y.1311.1 ITU-T建议，2001年7月。
[Y.1311] Knightson, K. (editor), "Network based VPNs - Generic Architecture and Service Requirements", Y.1311 ITU-T Recommendation, March 2002.
[Y.1311]Knightson，K.（编辑），“基于网络的VPN-通用架构和服务要求”，Y.1311 ITU-T建议，2002年3月。
Authors' Addresses
作者地址
Marco Carugi (co-editor) Nortel Networks Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE
Marco Carugi（联合编辑）北电网络玛格尼酒庄Les Jeunes Bois活动公园-MS CTF 32B5-酒庄78928 YVELINES Cedex 9-法国
EMail: marco.carugi@nortel.com
EMail: marco.carugi@nortel.com
Dave McDysan (co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA
Dave McDysan（合编）MCI 22001美国弗吉尼亚州阿什本市劳顿县公园路，邮编20147
EMail: dave.mcdysan@mci.com
EMail: dave.mcdysan@mci.com
Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA
美国新泽西州米德尔敦市劳雷尔大道200号C2-3B35室陆源房AT&T 07748
EMail: Luyuanfang@att.com
EMail: Luyuanfang@att.com
Ananth Nagarajan Juniper Networks
Ananth Nagarajan Juniper网络
EMail: ananth@juniper.net
EMail: ananth@juniper.net
Junichi Sumimoto NTT Communications Corporation 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan
日本东京新宿市西新宿3-20-2号日本新宿通信公司
EMail: j.sumimoto@ntt.com
EMail: j.sumimoto@ntt.com
Rick Wilder Alcatel
里克·怀尔德·阿尔卡特
EMail: rick.wilder@alcatel.com
EMail: rick.wilder@alcatel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。