Network Working Group A. Nagarajan, Ed.
Request for Comments: 3809 Juniper Networks
Category: Informational June 2004
Network Working Group A. Nagarajan, Ed.
Request for Comments: 3809 Juniper Networks
Category: Informational June 2004
Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)
提供商提供的虚拟专用网络（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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.
本文档描述了提供商提供的虚拟专用网络（PPVPN）的一般要求。需求分为服务需求、供应商需求和工程需求。这些要求并不特定于任何特定类型的PPVPN技术，而是适用于所有PPVPN技术。所有PPVPN技术均应满足本文件所述的总体要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Scenarios. . . . . . . . . . . . . . . . . . . 4
1.3. Outline of this document. . . . . . . . . . . . . . . . . 5
2. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . 7
4. Service Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.1. Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Data Isolation. . . . . . . . . . . . . . . . . . . . . . 9
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. User data security . . . . . . . . . . . . . . . . 10
4.5.2. Access Control . . . . . . . . . . . . . . . . . . 10
4.5.3. Site authentication and authorization. . . . . . . 10
4.5.4. Inter domain security. . . . . . . . . . . . . . . 10
4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Quality of Service . . . . . . . . . . . . . . . . . . . 11
4.9. Service Level Agreement and Service Level Specification
Monitoring and Reporting. . . . . . . . . . . . . . . . . 13
4.10.Network Resource Partitioning and Sharing between VPNs. . 14
5. Provider requirements. . . . . . . . . . . . . . . . . . . . . 14
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Provider Capacity Sizing Projections . . . 15
5.1.2. VPN Scalability aspects. . . . . . . . . . . . . . 15
5.1.3. Solution-Specific Metrics. . . . . . . . . . . . . 17
5.2. Management . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Customer Management of a VPN . . . . . . . . . . . 18
6. Engineering requirements . . . . . . . . . . . . . . . . . . . 19
6.1. Forwarding plane requirements . . . . . . . . . . . . . . 19
6.2. Control plane requirements. . . . . . . . . . . . . . . . 20
6.3. Control Plane Containment . . . . . . . . . . . . . . . . 20
6.4. Requirements related to commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms. . . 21
6.5. Interoperability . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References. . . . . . . . . . . . . . . . . . . 23
8.2. Informative References. . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 24
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Scenarios. . . . . . . . . . . . . . . . . . . 4
1.3. Outline of this document. . . . . . . . . . . . . . . . . 5
2. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . 7
4. Service Requirements . . . . . . . . . . . . . . . . . . . . . 7
4.1. Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Data Isolation. . . . . . . . . . . . . . . . . . . . . . 9
4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. User data security . . . . . . . . . . . . . . . . 10
4.5.2. Access Control . . . . . . . . . . . . . . . . . . 10
4.5.3. Site authentication and authorization. . . . . . . 10
4.5.4. Inter domain security. . . . . . . . . . . . . . . 10
4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Quality of Service . . . . . . . . . . . . . . . . . . . 11
4.9. Service Level Agreement and Service Level Specification
Monitoring and Reporting. . . . . . . . . . . . . . . . . 13
4.10.Network Resource Partitioning and Sharing between VPNs. . 14
5. Provider requirements. . . . . . . . . . . . . . . . . . . . . 14
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Provider Capacity Sizing Projections . . . 15
5.1.2. VPN Scalability aspects. . . . . . . . . . . . . . 15
5.1.3. Solution-Specific Metrics. . . . . . . . . . . . . 17
5.2. Management . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Customer Management of a VPN . . . . . . . . . . . 18
6. Engineering requirements . . . . . . . . . . . . . . . . . . . 19
6.1. Forwarding plane requirements . . . . . . . . . . . . . . 19
6.2. Control plane requirements. . . . . . . . . . . . . . . . 20
6.3. Control Plane Containment . . . . . . . . . . . . . . . . 20
6.4. Requirements related to commonality of PPVPN mechanisms
with each other and with generic Internet mechanisms. . . 21
6.5. Interoperability . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References. . . . . . . . . . . . . . . . . . . 23
8.2. Informative References. . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 24
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
This document is an output of the design team formed to develop requirements for PPVPNs in the Provider Provisioned Virtual Private Networks (PPVPN) working group and provides requirements that are generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3 Virtual Private Networks (L3VPN). This document discusses generic PPVPN requirements categorized as service, provider and engineering requirements. These are independent of any particular type of PPVPN technology. In other words, all PPVPN technologies are expected to meet the umbrella set of requirements described in this document. PPVPNs may be constructed across single or multiple provider networks and/or Autonomous Systems (ASes). In most cases the generic requirements described in this document are independent of the deployment scenario. However, specific requirements that differ based on whether the PPVPN is deployed across single or multiple providers (and/or ASes) will be pointed out in the document. Specific requirements related to Layer 3 PPVPNs are described in [L3REQTS]. Similarly, requirements that are specific to layer 2 PPVPNs are described in [L2REQTS].
本文件是为在提供商提供的虚拟专用网络（PPVPN）工作组中开发PPVPN需求而成立的设计团队的输出，并提供了第2层虚拟专用网络（L2VPN）和第3层虚拟专用网络（L3VPN）的通用需求。本文件讨论了PPVPN的一般要求，分为服务、提供商和工程要求。这些独立于任何特定类型的PPVPN技术。换句话说，所有PPVPN技术都应满足本文档中描述的一系列要求。PPVPN可以跨单个或多个提供商网络和/或自治系统（ASE）构建。在大多数情况下，本文档中描述的通用需求独立于部署场景。但是，根据PPVPN是跨单个提供商还是跨多个提供商（和/或ASE）部署而有所不同的具体要求将在文件中指出。[L3REQTS]中描述了与第3层PPVPN相关的具体要求。类似地，第2层PPVPN的特定要求见[L2REQTS]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Corporations and other organizations have become increasingly dependent on their networks for telecommunications and data communication. The data communication networks were originally built as Local Area Networks (LAN). Over time the possibility to interconnect the networks on different sites has become more and more important. The connectivity for corporate networks has been supplied by service providers, mainly as Frame Relay (FR) or Asynchronous Transfer Mode (ATM) connections, and more recently as Ethernet and IP-based tunnels. This type of network, interconnecting a number of sites over a shared network infrastructure is called Virtual Private Network (VPN). If the sites belong to the same organization, the VPN is called an Intranet. If the sites belong to different organizations that share a common interest, the VPN is called an Extranet.
公司和其他组织越来越依赖其网络进行电信和数据通信。数据通信网络最初构建为局域网（LAN）。随着时间的推移，在不同站点上互连网络的可能性变得越来越重要。公司网络的连接由服务提供商提供，主要是帧中继（FR）或异步传输模式（ATM）连接，最近是以太网和基于IP的隧道。这种通过共享网络基础设施互连多个站点的网络称为虚拟专用网（VPN）。如果这些站点属于同一组织，则VPN称为Intranet。如果这些站点属于具有共同兴趣的不同组织，则VPN称为外联网。
Customers are looking for service providers to deliver data and telecom connectivity over one or more shared networks, with service level assurances in the form of security, QoS and other parameters.
客户正在寻找服务提供商通过一个或多个共享网络提供数据和电信连接，并以安全、QoS和其他参数的形式提供服务级别保证。
In order to provide isolation between the traffic belonging to different customers, mechanisms such as Layer 2 connections or Layer 2/3 tunnels are necessary. When the shared infrastructure is an IP network, the tunneling technologies that are typically used are IPsec, MPLS, L2TP, GRE, IP-in-IP etc.
为了在属于不同客户的流量之间提供隔离，需要诸如第2层连接或第2/3层隧道之类的机制。当共享基础设施是IP网络时，通常使用的隧道技术有IPsec、MPLS、L2TP、GRE、IP中的IP等。
Traditional Internet VPNs have been based on IPsec to provide security over the Internet. Service providers are now beginning to deploy enhanced VPN services that provide features such as service differentiation, traffic management, Layer 2 and Layer 3 connectivity, etc. in addition to security. Newer tunneling mechanisms have certain features that allow the service providers to provide these enhanced VPN services.
传统的Internet VPN基于IPsec来提供Internet上的安全性。服务提供商现在开始部署增强的VPN服务，除了安全性之外，还提供服务差异化、流量管理、第2层和第3层连接等功能。较新的隧道机制具有某些特性，允许服务提供商提供这些增强的VPN服务。
The VPN solutions we define now MUST be able to accommodate the traditional types of VPNs as well as the enhanced services now being deployed. They need to be able to run in a single service provider's network, as well as between a set of service providers and across the Internet. In doing so the VPNs SHOULD NOT be allowed to violate basic Internet design principles or overload the Internet core routers or accelerate the growths of the Internet routing tables. Specifically, Internet core routers SHALL NOT be required to maintain VPN-related information, regardless of whether the Internet routing protocols are used to distribute this information or not. In order to achieve this, the mechanisms used to develop various PPVPN solutions SHALL be as common as possible with generic Internet infrastructure mechanisms like discovery, signaling, routing and management. At the same time, existing Internet infrastructure mechanisms SHALL NOT be overloaded.
我们现在定义的VPN解决方案必须能够适应传统类型的VPN以及现在部署的增强服务。它们需要能够在单个服务提供商的网络中运行，以及在一组服务提供商之间和通过互联网运行。在这样做时，不应允许VPN违反基本互联网设计原则，或使互联网核心路由器过载，或加速互联网路由表的增长。具体而言，无论是否使用互联网路由协议分发该信息，互联网核心路由器都不需要维护VPN相关信息。为了实现这一点，用于开发各种PPVPN解决方案的机制应尽可能与通用互联网基础设施机制（如发现、信令、路由和管理）共用。同时，现有的互联网基础设施机制不应过载。
Another generic requirement from a standardization perspective is to limit the number of different solution approaches. For example, for service providers that need to support multiple types of VPN services, it may be undesirable to require a completely different solution approach for each type of VPN service.
从标准化的角度来看，另一个通用要求是限制不同解决方案方法的数量。例如，对于需要支持多种类型VPN服务的服务提供商，可能不希望为每种类型的VPN服务要求完全不同的解决方案方法。
There are three different deployment scenarios that need to be considered for PPVPN services:
PPVPN服务需要考虑三种不同的部署方案：
1. Single-provider, single-AS: This is the least complex scenario, where the PPVPN service is offered across a single service provider network spanning a single Autonomous System.
1. 单一提供商，单一AS：这是最不复杂的场景，PPVPN服务通过跨越单一自治系统的单一服务提供商网络提供。
2. Single-provider, multi-AS: In this scenario, a single provider may have multiple Autonomous Systems (for e.g., a global Tier-1 ISP with different ASes depending on the global location, or an ISP
2. 单个提供商，多AS：在这种情况下，单个提供商可能有多个自治系统（例如，根据全球位置，具有不同ASE的全球一级ISP或ISP）
that has been created by mergers and acquisitions of multiple networks). This scenario involves the constrained distribution of routing information across multiple Autonomous Systems.
这是由多个网络的合并和收购造成的）。此场景涉及路由信息在多个自治系统之间的受限分布。
3. Multi-provider: This scenario is the most complex, wherein trust negotiations need to be made across multiple service provider backbones in order to meet the security and service level agreements for the PPVPN customer. This scenario can be generalized to cover the Internet, which comprises of multiple service provider networks. It should be noted that customers can construct their own VPNs across multiple providers. However such VPNs are not considered here as they would not be "Provider-provisioned".
3. 多提供商：此场景最为复杂，需要跨多个服务提供商主干网进行信任协商，以满足PPVPN客户的安全和服务级别协议。这种情况可以推广到包括由多个服务提供商网络组成的互联网。应该注意的是，客户可以跨多个提供商构建自己的VPN。但是，此处不考虑此类VPN，因为它们不是“提供商配置的”。
A fourth scenario, "Carrier's carrier" VPN may also be considered. In this scenario, a service provider (for example, a Tier 1 service provider) provides VPN service to another service provider (for example, a Tier 2 service provider), which in turn provides VPN service on its VPN to its customers. In the example given above, the Tier 2 provider's customers are contained within the Tier 2 provider's network, and the Tier 2 provider itself is a customer of the Tier 1 provider's network. Thus, this scenario is not treated separately in the document, because all of the single provider requirements would apply equally to this case.
第四种情况下，也可以考虑“运营商的运营商”VPN。在这种情况下，服务提供商（例如，第1层服务提供商）向另一个服务提供商（例如，第2层服务提供商）提供VPN服务，而另一个服务提供商又在其VPN上向其客户提供VPN服务。在上面给出的示例中，第2层提供商的客户包含在第2层提供商的网络中，而第2层提供商本身是第1层提供商网络的客户。因此，本文档中不会单独处理此场景，因为所有单个提供者的要求都将同样适用于此情况。
It is expected that many of the generic requirements described in this document are independent of the three deployment scenarios listed above. However, specific requirements that are indeed dependent on the deployment scenario will be pointed out in this document.
预计本文档中描述的许多通用需求独立于上面列出的三种部署场景。但是，本文件将指出确实依赖于部署场景的具体需求。
This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The document contains several sections, with each set representing a significant aspect of PPVPN requirements.
本文档描述了提供商提供的虚拟专用网络（PPVPN）的一般要求。本文档包含几个部分，每一部分代表PPVPN需求的一个重要方面。
Section 2 lists authors who contributed to this document. Section 3 defines terminology and presents a taxonomy of PPVPN technologies. The taxonomy contains two broad classes, representing Layer 2 and Layer 3 VPNs. Each top level VPN class contains subordinate classes. For example, the Layer 3 VPN class contains a subordinate class of PE-based Layer 3 VPNs.
第2节列出了对本文件作出贡献的作者。第3节定义了术语并介绍了PPVPN技术的分类。该分类法包含两大类，分别代表第2层和第3层VPN。每个顶级VPN类都包含下级类。例如，第3层VPN类包含一个基于PE的第3层VPN的从属类。
Sections 4, 5, 6 describe generic PPVPN requirements.
第4、5、6节描述了PPVPN的一般要求。
The requirements are broadly classified under the following categories:
这些要求大致分为以下几类：
1) Service requirements - Service attributes that the customer can observe or measure. For example, does the service forward frames or route datagrams? What security guarantees does the service provide? Availability and stability are key requirements in this category.
1) 服务要求-客户可以观察或测量的服务属性。例如，服务是否转发帧或路由数据报？该服务提供哪些安全保证？可用性和稳定性是该类别的关键要求。
2) Provider requirements - Characteristics that Service Providers use to determine the cost-effectiveness of a PPVPN service. Scaling and management are examples of Provider requirements.
2) 提供商要求-服务提供商用于确定PPVPN服务成本效益的特征。扩展和管理是提供者需求的示例。
3) Engineering requirements - Implementation characteristics that make service and provider requirements achievable. These can be further classified as:
3) 工程需求-使服务和提供商需求可实现的实施特征。这些可进一步分类为：
3a) Forwarding plane requirements - e.g., requirements related to router forwarding behavior.
3a）转发平面要求-例如，与路由器转发行为相关的要求。
3b) Control plane requirements - e.g., requirements related to reachability and distribution of reachability information.
3b）控制平面要求-例如，与可达性和可达性信息分布相关的要求。
3c) Requirements related to the commonality of PPVPN mechanisms with each other and with generic Internet mechanisms.
3c）与PPVPN机制之间以及与通用互联网机制之间的通用性相关的要求。
This document was the combined effort of several individuals that were part of the Service Provider focus group whose intentions were to present Service Provider view on the general requirements for PPVPN. A significant set of requirements were directly taken from previous work by the PPVPN WG to develop requirements for Layer 3 PPVPN [L3REQTS]. The existing work in the L2 requirements area has also influenced the contents of this document [L2REQTS].
本文件是服务提供商焦点小组的几个成员共同努力的结果，他们的目的是展示服务提供商对PPVPN一般要求的看法。PPVPN工作组直接从先前的工作中获取了一组重要的需求，以开发第3层PPVPN[L3REQTS]的需求。L2需求领域的现有工作也影响了本文件的内容[L2REQTS]。
Besides the editor, the following are the authors that contributed to this document:
除编辑外，以下是对本文件作出贡献的作者：
Loa Andersson (loa@pi.se) Ron Bonica (ronald.p.bonica@mci.com) Dave McDysan (dave.mcdysan@mci.com) Junichi Sumimoto (j.sumimoto@ntt.com) Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp) David Meyer (dmm@1-4-5.net) Marco Carugi (marco.carugi@nortelnetworks.com)
安徒生酒店(loa@pi.se)罗恩·博尼卡（罗纳德·p。bonica@mci.com)戴夫·麦克迪桑（戴夫。mcdysan@mci.com)住本纯一（j。sumimoto@ntt.com)铃木（铃木）。muneyoshi@lab.ntt.co.jp)大卫·迈耶(dmm@1-4-5.net）马可·卡鲁吉。carugi@nortelnetworks.com)
Yetik Serbest (yetik_serbest@labs.sbc.com) Luyuan Fang (luyuanfang@att.com) Javier Achirica (achirica@telefonica.net)
耶提克塞族（耶提克塞族）_serbest@labs.sbc.com)方禄源(luyuanfang@att.com)哈维尔·阿奇里卡(achirica@telefonica.net)
The terminology used in this document is defined in [TERMINOLOGY]. In addition the following terminology is used:
本文件中使用的术语定义见[术语]。此外，还使用了以下术语：
Site: a geographical location with one or more users or one or more servers or a combination of servers and users.
站点：具有一个或多个用户、一个或多个服务器或服务器与用户组合的地理位置。
User: the end user equipment (hosts), e.g., a workstation.
用户：终端用户设备（主机），例如工作站。
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|__________|
______|_____
| |
P2P P2MP
PPVPN
________________|__________________
| |
Layer 2 (L2) Layer 3 (L3)
______|_____ ______|________
| | | |
PE-based CE-based PE-based CE-based
|__________|
______|_____
| |
P2P P2MP
The figure above presents a taxonomy of PPVPN technologies. PE-based and CE-based Layer 2 VPNs may also be further classified as point-to-point (P2P) or point-to-multipoint (P2MP). It is also the intention of the working group to have a limited number of solutions, and this goal must be kept in mind when proposing solutions that meet the requirements specified in this document. Definitions for CE-based and PE-based PPVPNs can be obtained from [L3FRAMEWORK]. Layer 2 specific definitions can be obtained from [L2FRAMEWORK].
上图显示了PPVPN技术的分类。基于PE和基于CE的第2层VPN也可进一步分类为点对点（P2P）或点对多点（P2MP）。工作组还打算制定数量有限的解决方案，在提出满足本文件规定要求的解决方案时，必须牢记这一目标。基于CE和基于PE的PPVPN的定义可从[L3FRAMEWORK]获得。第2层的具体定义可从[L2框架]获得。
These are the requirements that a customer can observe or measure, in order to verify if the PPVPN service that the Service Provider (SP) provides is satisfactory. As mentioned before, each of these requirements apply equally across each of the three deployment scenarios unless stated otherwise.
这些是客户可以观察或测量的要求，以验证服务提供商（SP）提供的PPVPN服务是否令人满意。如前所述，除非另有说明，否则这些要求中的每一项都平等地适用于三种部署场景中的每一种。
VPN services MUST have high availability. VPNs that are distributed over several sites require connectivity to be maintained even in the event of network failures or degraded service.
VPN服务必须具有高可用性。分布在多个站点上的VPN需要保持连接，即使在网络故障或服务降级的情况下也是如此。
This can be achieved via various redundancy techniques such as:
这可以通过各种冗余技术实现，例如：
1. Physical Diversity
1. 物理多样性
A single site connected to multiple CEs (for CE-based PPVPNs) or PEs (for PE-based PPVPNs), or different POPs, or even different service providers.
单个站点连接到多个CE（基于CE的PPVPN）或PE（基于PE的PPVPN），或不同的POP，甚至不同的服务提供商。
2. Tunnel redundancy
2. 隧道冗余
Redundant tunnels may be set up between the PEs (in a PE-based PPVPN) or the CEs (in a CE-based PPVPN) so that if one tunnel fails, VPN traffic can continue to flow across the other tunnel that has already been set-up in advance.
可以在PEs（在基于PE的PPVPN中）或CEs（在基于CE的PPVPN中）之间设置冗余隧道，这样，如果一个隧道发生故障，VPN流量可以继续流经已经预先设置的另一个隧道。
Tunnel redundancy may be provided over and above physical diversity. For example, a single site may be connected to two CEs (for CE-based PPVPNs) or two PEs (for PE-based PPVPNs). Tunnels may be set up between each of the CEs (or PEs as the case may be) across different sites.
除了物理分集之外，还可以提供隧道冗余。例如，一个站点可以连接到两个CE（用于基于CE的PPVPN）或两个PE（用于基于PE的PPVPN）。可在不同现场的每个CE（或PE，视情况而定）之间设置隧道。
Of course, redundancy means additional resources being used, and consequently, management of additional resources, which would impact the overall scaling of the service.
当然，冗余意味着使用额外的资源，因此也意味着管理额外的资源，这将影响服务的总体扩展。
It should be noted that it is difficult to guarantee high availability when the VPN service is across multiple providers, unless there is a negotiation between the different service providers to maintain the service level agreement for the VPN customer.
应该注意的是，当VPN服务跨多个提供商时，很难保证高可用性，除非不同的服务提供商之间进行协商，以维护VPN客户的服务级别协议。
In addition to availability, VPN services MUST also be stable. Stability is a function of several components such as VPN routing, signaling and discovery mechanisms, in addition to tunnel stability. For example, in the case of routing, route flapping or routing loops MUST be avoided in order to ensure stability. Stability of the VPN service is directly related to the stability of the mechanisms and protocols used to establish the service. It SHOULD also be possible to allow network upgrades and maintenance procedures without impacting the VPN service.
除了可用性，VPN服务还必须稳定。除了隧道稳定性之外，稳定性还取决于几个组件，如VPN路由、信令和发现机制。例如，在路由的情况下，必须避免路由抖动或路由循环，以确保稳定性。VPN服务的稳定性直接关系到用于建立服务的机制和协议的稳定性。还应允许在不影响VPN服务的情况下进行网络升级和维护程序。
VPN services MUST support unicast (or point to point) traffic and SHOULD support any-to-any or point-to-multipoint traffic including multicast and broadcast traffic. In the broadcast model, the network
VPN服务必须支持单播（或点对点）流量，并应支持任何对任何或点对多点流量，包括多播和广播流量。在广播模式中，网络
delivers a stream to all members of a subnetwork, regardless of their interest in that stream. In the multicast model, the network delivers a stream to a set of destinations that have registered interest in the stream. All destinations need not belong to the same subnetwork. Multicast is more applicable to L3 VPNs while broadcast is more applicable to L2VPNs. It is desirable to support multicast limited in scope to an intranet or extranet. The solution SHOULD be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner.
将流传递给子网的所有成员，而不管他们对该流感兴趣。在多播模型中，网络将流传送到一组对该流感兴趣的目的地。所有目的地不必属于同一子网。组播更适用于L3 VPN，而广播更适用于L2VPN。希望支持范围限于内联网或外联网的多播。该解决方案应该能够以可伸缩的方式支持大量此类特定于内联网或外联网的多播组。
All PPVPN approaches SHALL support both IPv4 and IPv6 traffic. Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) SHALL be supported via encapsulation in IP or MPLS tunnels in the case of L2VPNs.
所有PPVPN方法均应支持IPv4和IPv6流量。对于L2VPN，应通过IP或MPLS隧道中的封装来支持特定的L2通信类型（如ATM、帧中继和以太网）。
The PPVPN MUST support forwarding plane isolation. The network MUST never deliver user data across VPN boundaries unless the two VPNs participate in an intranet or extranet.
PPVPN必须支持转发平面隔离。除非两个VPN参与内部网或外部网，否则网络决不能跨VPN边界传送用户数据。
Furthermore, if the provider network receives signaling or routing information from one VPN, it MUST NOT reveal that information to another VPN unless the two VPNs participate in an intranet or extranet. It should be noted that the disclosure of any signaling/routing information across an extranet MUST be filtered per the extranet agreement between the organizations participating in the extranet.
此外，如果提供商网络从一个VPN接收到信令或路由信息，则不得将该信息透露给另一个VPN，除非这两个VPN参与intranet或extranet。应该注意的是，必须根据参与外联网的组织之间的外联网协议对外联网中任何信令/路由信息的披露进行过滤。
A range of security features SHOULD be supported by the suite of PPVPN solutions in the form of securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a PPVPN. These security features SHOULD be implemented based on the framework outlined in [VPN-SEC]. Each PPVPN solution SHOULD state which security features it supports and how such features can be configured on a per customer basis. Protection against Denial of Service (DoS) attacks is a key component of security mechanisms. Examples of DoS attacks include attacks to the PE or CE CPUs, access connection congestion, TCP SYN attacks and ping attacks.
PPVPN解决方案套件应支持一系列安全功能，包括保护客户流，为临时、远程或移动用户提供身份验证服务，以及保护支持PPVPN所涉及的服务提供商资源的需要。这些安全功能应基于[VPN-SEC]中概述的框架实施。每个PPVPN解决方案应说明其支持哪些安全功能，以及如何根据每个客户配置这些功能。防止拒绝服务（DoS）攻击是安全机制的关键组成部分。DoS攻击的示例包括对PE或CE CPU的攻击、访问连接拥塞、TCP SYN攻击和ping攻击。
Some security mechanisms (such as use of IPsec on a CE-to-CE basis) may be equally useful regardless of the scope of the VPN. Other mechanisms may be more applicable in some scopes than in others. For example, in some cases of single-provider single-AS VPNs, the VPN service may be isolated from some forms of attack by isolating the
无论VPN的范围如何，某些安全机制（例如在CE到CE的基础上使用IPsec）可能同样有用。其他机制可能在某些领域比在其他领域更适用。例如，在单个提供商作为VPN的某些情况下，VPN服务可以通过隔离
infrastructure used for supporting VPNs from the infrastructure used for other services. However, the requirements for security are common regardless of the scope of the VPN service.
用于从用于其他服务的基础架构支持VPN的基础架构。但是，无论VPN服务的范围如何，安全性要求都是常见的。
PPVPN solutions that support user data security SHOULD use standard methods (e.g., IPsec) to achieve confidentiality, integrity, authentication and replay attack prevention. 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. User data security using encryption is especially desirable in the multi-provider scenario.
支持用户数据安全的PPVPN解决方案应使用标准方法（如IPsec）来实现机密性、完整性、身份验证和重放攻击预防。此类安全方法必须可在不同的端点（如CE-CE、PE-PE和CE-PE）之间配置。还希望在每个路由或每个VPN的基础上配置安全性。在多提供商场景中，使用加密的用户数据安全性尤其可取。
A PPVPN solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers, cryptographic mechanisms or similar mechanisms to apply policy-based access control. Access control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such access control mechanisms are desirable in the multi-provider scenario.
PPVPN解决方案还可以根据客户的请求激活适当的过滤功能。过滤器提供了一种机制，以便可以在外联网中涉及的不同组织之间的通信点调用访问控制。访问控制可以通过防火墙、路由器上的访问控制列表、加密机制或类似机制来实现，以应用基于策略的访问控制。访问控制也必须适用于CE-CE、PE-PE和CE-PE之间。这种访问控制机制在多提供商场景中是可取的。
A PPVPN solution requires authentication and authorization of the following:
PPVPN解决方案需要对以下各项进行身份验证和授权：
- temporary and permanent access for users connecting to sites (authentication and authorization BY the site)
- 连接到站点的用户的临时和永久访问（站点的身份验证和授权）
- the site itself (authentication and authorization FOR the site)
- 站点本身（站点的身份验证和授权）
The VPN solution MUST have appropriate security mechanisms to prevent the different kinds of Distributed Denial of Service (DDoS) attacks mentioned earlier, misconfiguration or unauthorized accesses in inter domain PPVPN connections. This is particularly important for multi-service provider deployment scenarios. However, this will also be important in single-provider multi-AS scenarios.
VPN解决方案必须具有适当的安全机制，以防止前面提到的各种分布式拒绝服务（DDoS）攻击、域间PPVPN连接中的错误配置或未经授权的访问。这对于多服务提供商部署场景尤其重要。但是，这在单提供商多AS场景中也很重要。
A VPN SHOULD support arbitrary, customer-defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. These can actually be different from the topology used by the service provider. To the extent possible, a PPVPN service SHOULD be independent of the geographic extent of the deployment.
VPN应支持任意的、客户定义的站点间连接，例如，从中心辐射、部分网格到全网格拓扑。这些实际上可能与服务提供商使用的拓扑不同。PPVPN服务应尽可能独立于部署的地理范围。
Multiple VPNs per customer site SHOULD be supported without requiring additional hardware resources per VPN. This SHOULD also include a free mix of L2 and L3 VPNs.
每个客户站点应支持多个VPN，而不需要每个VPN额外的硬件资源。这还应包括L2和L3 VPN的免费混合。
To the extent possible, the PPVPN services SHOULD be independent of access network technology.
PPVPN服务应尽可能独立于接入网技术。
Each customer resource MUST be identified by an address that is unique within its VPN. It need not be identified by a globally unique address.
每个客户资源必须由其VPN内唯一的地址标识。它不需要由全局唯一地址标识。
Support for private addresses as described in [RFC1918], as well as overlapping customer addresses SHALL be supported. One or more VPNs for each customer can be built over the same infrastructure without requiring any of them to renumber. The solution MUST NOT use NAT on the customer traffic to achieve that goal. Interconnection of two networks with overlapping IP addresses is outside the scope of this document.
应支持[RFC1918]中所述的专用地址以及重叠的客户地址。可以在相同的基础设施上为每个客户构建一个或多个VPN，而无需对其中任何一个进行重新编号。解决方案不得在客户流量上使用NAT来实现该目标。具有重叠IP地址的两个网络的互连不在本文件的范围内。
A VPN service SHALL be capable of supporting non-IP customer addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses may be desirable in some cases, but is beyond the scope of VPN solutions developed in the IETF, and therefore, this document.
如果VPN服务是第2层VPN（例如帧中继、ATM、以太网），则VPN服务应能够通过封装技术支持非IP客户地址。在某些情况下，支持非IP第3层地址可能是可取的，但超出了IETF中开发的VPN解决方案的范围，因此也超出了本文档的范围。
A technical approach for supporting VPNs SHALL be able to support QoS via IETF standardized mechanisms such as Diffserv. Support for best-effort traffic SHALL be mandatory for all PPVPN types. The extent to which any specific VPN service will support QoS is up to the service provider. In many cases single-provider single-AS VPNs will offer QoS guarantees. Support of QoS guarantees in the multi-service-provider case will require cooperation between the various service providers involved in offering the service.
支持VPN的技术方法应能够通过IETF标准化机制（如Diffserv）支持QoS。所有PPVPN类型都必须支持尽力而为的流量。任何特定VPN服务支持QoS的程度取决于服务提供商。在许多情况下，作为VPN的单一提供商将提供QoS保证。在多服务提供商的情况下，支持QoS保证将需要提供服务的各个服务提供商之间的合作。
It should be noted that QoS mechanisms in the multi-provider scenario REQUIRES each of the participating providers to support the mechanisms being used, and as such, this is difficult to achieve.
应当注意，多提供商场景中的QoS机制要求每个参与提供商支持正在使用的机制，因此，这是很难实现的。
Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing.
注意，所有涉及QoS的情况都可能要求CE和/或PE执行成形和/或监管。
The need to provide QoS will occur primarily in the access network, since that will often be the bottleneck. This is likely to occur since the backbone effectively statistically multiplexes many users, and is traffic engineered or includes capacity for restoration and growth. Hence in most cases PE-PE QoS is not a major issue. As far as access QoS is concerned, there are two directions of QoS management that may be considered in any PPVPN service regarding QoS:
提供QoS的需求将主要发生在接入网络中，因为这通常是瓶颈。这很可能发生，因为主干网在统计上有效地多路复用了许多用户，并且是经过流量设计的，或者包括用于恢复和增长的容量。因此，在大多数情况下，PE-PE QoS不是主要问题。就访问QoS而言，在任何PPVPN服务中都可以考虑两个方向的QoS管理，即QoS：
- From the CE across the access network to the PE - From the PE across the access network to CE
- 从接入网络的CE到PE-从接入网络的PE到CE
PPVPN CE and PE devices SHOULD be capable of supporting QoS across at least the following subset of access networks, as applicable to the specific type of PPVPN (L2 or L3). However, to the extent possible, the QoS capability of a PPVPN SHOULD be independent of the access network technology:
PPVPN CE和PE设备应能够支持至少以下接入网络子集的QoS，适用于特定类型的PPVPN（L2或L3）。然而，PPVPN的QoS能力应尽可能独立于接入网络技术：
- ATM Virtual Connections (VCs) - Frame Relay Data Link Connection Identifiers (DLCIs) - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP - QoS-enabled wireless (e.g., LMDS, MMDS) - Cable modem - QoS-enabled Digital Subscriber Line (DSL)
- ATM虚拟连接（VCs）-帧中继数据链路连接标识符（DLCI）-802.1d优先以太网-基于MPLS的访问-多链路多类PPP-支持QoS的无线（如LMDS、MMDS）-电缆调制解调器-支持QoS的数字用户线（DSL）
Different service models for QoS may be supported. Examples of PPVPN QoS service models are:
可能支持不同的QoS服务模型。PPVPN QoS服务模型的示例包括：
- Managed access service: Provides QoS on the access connection between CE and the customer facing ports of the PE. No QoS support is required in the provider core network in this case.
- 托管访问服务：在CE和PE面向客户的端口之间的访问连接上提供QoS。在这种情况下，提供商核心网络不需要QoS支持。
- Edge-to-edge QoS: Provides QoS across the provider core, either between CE pairs or PE pairs, depending on the tunnel demarcation points. This scenario requires QoS support in the provider core network. As mentioned above, this is difficult to achieve in a multi-provider VPN offering.
- 边缘到边缘QoS：根据隧道分界点，跨提供程序核心在CE对或PE对之间提供QoS。此场景需要提供商核心网络中的QoS支持。如上所述，在多提供商VPN产品中很难实现这一点。
4.9. Service Level Agreement and Service Level Specification Monitoring and Reporting
4.9. 服务级别协议和服务级别规范监控和报告
A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement interval for at least the SLS using the following Service Level Objective (SLO) parameters:
可以为每个接入网络连接、每个VPN、每个VPN站点和/或每个VPN路由定义服务级别规范（SLS）。服务提供商可以使用以下服务水平目标（SLO）参数定义至少SLS的目标和测量间隔：
- QoS and traffic parameters for the Intserv flow or Diffserv class [Y.1541]
- Intserv流或Diffserv类的QoS和流量参数[Y.1541]
- Availability for the site, VPN, or access connection
- 站点、VPN或访问连接的可用性
- Duration of outage intervals per site, route or VPN
- 每个站点、路由或VPN的停机间隔持续时间
- Service activation interval (e.g., time to turn up a new site)
- 服务激活间隔（例如，打开新站点的时间）
- Trouble report response time interval
- 故障报告响应时间间隔
- Time to repair interval
- 维修间隔时间
- Total traffic offered to the site, route or VPN
- 提供给站点、路由或VPN的总流量
- Measure of non-conforming traffic for the site, route or VPN
- 站点、路由或VPN的不合格流量测量
- Delay and delay variation (jitter) bounds
- 延迟和延迟变化（抖动）界限
- Packet ordering, at least when transporting L2 services sensitive to reordering (e.g., ATM).
- 数据包排序，至少在传输对重新排序敏感的L2服务时（如ATM）。
The above list contains items from [Y.1241], as well as other items typically part of SLAs for currently deployed VPN services [FRF.13]. See [RFC3198] for generic definitions of SLS, SLA, and SLO.
上面的列表包含[Y.1241]中的项目，以及当前部署的VPN服务的SLA中通常包含的其他项目[FRF.13]。SLS、SLA和SLO的一般定义见[RFC3198]。
The provider network management system SHALL measure, and report as necessary, whether measured performance meets or fails to meet the above SLS objectives.
提供商网络管理系统应测量并在必要时报告测量的性能是否满足或未能满足上述SLS目标。
In many cases the guaranteed levels for Service Level Objective (SLO) parameters may depend upon the scope of the VPN. For example, one level of guarantee might be provided for service within a single AS. A different (generally less stringent) guarantee might be provided within multiple ASs within a single service provider. At the current time, in most cases specific guarantees are not offered for multi-provider VPNs, and if guarantees were offered they might be expected to be less stringent still.
在许多情况下，服务级别目标（SLO）参数的保证级别可能取决于VPN的范围。例如，可以为单个AS中的服务提供一个级别的保证。在单个服务提供商的多个ASs中可能会提供不同（通常不太严格）的担保。目前，在大多数情况下，没有为多提供商VPN提供特定的担保，如果提供担保，则预计担保的严格程度可能会更低。
The service provider and the customer may negotiate a contractual arrangement that includes a Service Level Agreement (SLA) regarding compensation if the provider does not meet an SLS performance objective. Details of such compensation are outside the scope of this document.
如果服务提供商未达到SLS性能目标，则服务提供商和客户可以协商一项合同安排，其中包括关于补偿的服务水平协议（SLA）。此类赔偿的详细信息不在本文件范围内。
Network resources such as memory space, FIB table, bandwidth and CPU processing SHALL be shared between VPNs and, where applicable, with non-VPN Internet traffic. Mechanisms SHOULD be provided to prevent any specific VPN from taking up available network resources and causing others to fail. SLAs to this effect SHOULD be provided to the customer.
网络资源（如内存空间、FIB表、带宽和CPU处理）应在VPN之间共享，并在适用情况下与非VPN互联网流量共享。应提供机制以防止任何特定VPN占用可用网络资源并导致其他VPN失败。应向客户提供这方面的SLA。
Similarly, resources used for control plane mechanisms are also shared. When the service provider's control plane is used to distribute VPN specific information and provide other control mechanisms for VPNs, there SHALL be mechanisms to ensure that control plane performance is not degraded below acceptable limits when scaling the VPN service, or during network events such as failure, routing instabilities etc. Since a service provider's network would also be used to provide Internet service, in addition to VPNs, mechanisms to ensure the stable operation of Internet services and other VPNs SHALL be made in order to avoid adverse effects of resource hogging by large VPN customers.
同样，用于控制平面机制的资源也共享。当服务提供商的控制平面用于分发特定于VPN的信息并为VPN提供其他控制机制时，应具有一些机制，以确保在扩展VPN服务时，或在网络事件（如故障）期间，控制平面性能不会降到可接受的限值以下，路由不稳定性等。由于服务提供商的网络也将用于提供互联网服务，除VPN外，还应制定确保互联网服务和其他VPN稳定运行的机制，以避免大型VPN客户占用资源的不利影响。
This section describes operational requirements for a cost-effective, profitable VPN service offering.
本节描述了经济高效、有利可图的VPN服务产品的运营要求。
The scalability for VPN solutions has many aspects. The list below is intended to comprise of the aspects that PPVPN solutions SHOULD address. Clearly these aspects in absolute figures are very different for different types of VPNs - i.e., a point to point service has only two sites, while a VPLS or L3VPN may have a larger number of sites. It is also important to verify that PPVPN solutions not only scales on the high end, but also on the low end - i.e., a VPN with three sites and three users should be as viable as a VPN with hundreds of sites and thousands of users.
VPN解决方案的可扩展性有很多方面。以下列表旨在包括PPVPN解决方案应解决的方面。显然，对于不同类型的VPN，绝对数字中的这些方面是非常不同的，即点对点服务只有两个站点，而VPLS或L3VPN可能有更多的站点。验证PPVPN解决方案不仅可在高端扩展，而且可在低端扩展也很重要，即，具有三个站点和三个用户的VPN应与具有数百个站点和数千个用户的VPN一样可行。
A PPVPN solution SHOULD be scalable to support a very large number of VPNs per Service Provider network. The estimate is that a large service provider will require support for O(10^4) VPNs within four years.
PPVPN解决方案应具有可扩展性，以支持每个服务提供商网络中的大量VPN。据估计，大型服务提供商将在四年内需要对O（10^4）VPN的支持。
A PPVPN solution SHOULD be scalable to support a wide range of number of site interfaces per VPN, depending on the size and/or structure of the customer organization. The number of site interfaces SHOULD range from a few site interfaces to over 50,000 site interfaces per VPN.
PPVPN解决方案应具有可扩展性，以支持每个VPN的大量站点接口，具体取决于客户组织的规模和/或结构。每个VPN的站点接口数量应从几个站点接口到超过50000个站点接口不等。
A PPVPN solution SHOULD be scalable to support of a wide range of number of routes per VPN. The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs (O(10^5)), with typical values being in the O(10^3) range. The high end number is especially true considering the fact that many large ISPs may provide VPN services to smaller ISPs or large corporations. Typically, the number of routes per VPN is at least twice the number of site interfaces.
PPVPN解决方案应具有可扩展性，以支持每个VPN的大量路由。每个VPN的路由数可能从几个到ISP之间交换的路由数（O（10^5））不等，典型值在O（10^3）范围内。考虑到许多大型ISP可能向小型ISP或大型公司提供VPN服务，高端数字尤其正确。通常，每个VPN的路由数至少是站点接口数的两倍。
A PPVPN solution SHOULD support high values of the frequency of configuration setup and change, e.g., for real-time provisioning of an on-demand videoconferencing VPN or addition/deletion of sites.
PPVPN解决方案应支持高频率的配置设置和更改，例如，实时提供按需视频会议VPN或添加/删除站点。
Approaches SHOULD articulate scaling and performance limits for more complex deployment scenarios, such as single-provider multi-AS VPNs, multi-provider VPNs and carriers' carrier. Approaches SHOULD also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management systems.
这些方法应阐明更复杂部署场景的扩展和性能限制，如单提供商多接入VPN、多提供商VPN和运营商的运营商。方法还应描述其他感兴趣的方面，如容量需求或限制、支持的互通实例数量以及对管理系统的任何可伸缩性影响。
A PPVPN solution SHOULD support a large number of customer interfaces on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with current Internet protocols.
PPVPN解决方案应支持使用当前互联网协议的单个PE（基于PE的PPVPN）或CE（基于CE的PPVPN）上的大量客户接口。
This section describes the metrics for scaling PPVPN solutions, points out some of the scaling differences between L2 and L3 VPNs. It should be noted that the scaling numbers used in this document must be treated as typical examples as seen by the authors of this document. These numbers are only representative and different service providers may have different requirements for scaling. Further discussion on service provider sizing projections is in Section 5.1.1. Please note that the terms "user" and "site" are as defined in Section 3. It should also be noted that the numbers given
本节介绍扩展PPVPN解决方案的指标，指出L2和L3 VPN之间的一些扩展差异。应注意的是，本文件中使用的标度数必须视为本文件作者看到的典型示例。这些数字仅具有代表性，不同的服务提供商可能对扩展有不同的要求。关于服务提供商规模预测的进一步讨论见第5.1.1节。请注意，术语“用户”和“站点”的定义见第3节。还应注意的是，给出的数字
below would be different depending on whether the scope of the VPN is single-provider single-AS, single-provider multi-AS, or multi-provider. Clearly, the larger the scope, the larger the numbers that may need to be supported. However, this also means more management issues. The numbers below may be treated as representative of the single-provider case.
根据VPN的范围是单提供商单AS、单提供商多AS还是多提供商，以下内容可能有所不同。显然，范围越大，可能需要支持的数字就越大。然而，这也意味着更多的管理问题。以下数字可被视为单一供应商案例的代表。
The number of users per site follows the same logic as for users per VPN. Further, it must be possible to have single user sites connected to the same VPN as very large sites are connected to.
每个站点的用户数遵循与每个VPN的用户数相同的逻辑。此外，必须能够将单用户站点连接到与非常大的站点连接到相同的VPN。
L3 VPNs SHOULD scale from 1 user per site to O(10^4) per site. L2 VPNs SHOULD scale from 1 user to O(10^3) per site for point-to-point VPNs and to O(10^4) for point-to-multipoint VPNs.
L3 VPN应从每个站点1个用户扩展到每个站点0（10^4）。对于点到点VPN，L2 VPN应从每个站点1个用户扩展到O（10^3），对于点到多点VPN，应扩展到O（10^4）。
The number of sites per VPN clearly depends on the number of users per site. VPNs SHOULD scale from 2 to O(10^3) sites per VPN. These numbers are usually limited by device memory.
每个VPN的站点数显然取决于每个站点的用户数。VPN应在每个VPN上从2个扩展到0个（10^3）站点。这些数字通常受到设备内存的限制。
The number of PEs that supports the same set of VPNs, i.e., the number of PEs that needs to directly exchange information on VPN de-multiplexing information is clearly a scaling factor in a PE-based VPN. Similarly, in a CE-based VPN, the number of CEs is a scaling factor. This number is driven by the type of VPN service, and also by whether the service is within a single AS/domain or involves a multi-SP or multi-AS network. Typically, this number SHOULD be as low as possible in order to make the VPN cost effective and manageable.
支持同一组VPN的PE数量，即需要直接交换VPN解复用信息的PE数量显然是基于PE的VPN中的一个比例因子。类似地，在基于CE的VPN中，CE的数量是一个比例因子。这个数字取决于VPN服务的类型，也取决于该服务是在单个AS/域内还是涉及多SP或多AS网络。通常，该数字应尽可能低，以使VPN经济高效且易于管理。
The number of sites per PE needs to be discussed based on several different scenarios. On the one hand there is a limitation to the number of customer facing interfaces that the PE can support. On the other hand the access network may aggregate several sites connected on comparatively low bandwidth on to one single high bandwidth interface on the PE. The scaling point here is that the PE SHOULD be able to support a few or even a single site on the low end and O(10^4) sites on the high end. This number is also limited by device memory. Implementations of PPVPN solutions may be evaluated based on this requirement, because it directly impacts cost and manageability of a VPN.
每个PE的站点数量需要根据几个不同的场景进行讨论。一方面，PE可以支持的面向客户的接口数量有限。另一方面，接入网络可以将在相对低带宽上连接的多个站点聚合到PE上的单个高带宽接口上。这里的扩展点是，PE应该能够在低端支持几个甚至单个站点，在高端支持O（10^4）站点。这个数字也受到设备内存的限制。PPVPN解决方案的实施可以基于此需求进行评估，因为它直接影响VPN的成本和可管理性。
The number of VPNs SHOULD scale linearly with the size of the access network and with the number of PEs. As mentioned in Section 5.1.1, the number of VPNs in the network SHOULD be O(10^4). This requirement also effectively places a requirement on the number of tunnels that SHOULD be supported in the network. For a PE-based VPN, the number of tunnels is of the same order as the number of VPNs. For a CE-based VPN, the number of tunnels in the core network may be fewer, because of the possibility of tunnel aggregation or multiplexing across the core.
VPN的数量应与接入网络的大小和PE的数量成线性比例。如第5.1.1节所述，网络中的VPN数量应为O（10^4）。该要求还有效地对网络中应支持的隧道数量提出了要求。对于基于PE的VPN，隧道的数量与VPN的数量顺序相同。对于基于CE的VPN，核心网络中的隧道数量可能会更少，因为可能会跨核心进行隧道聚合或多路复用。
In some cases a service provider may support multiple VPNs for the same customer of that service provider. For example, this may occur due to differences in services offered per VPN (e.g., different QoS, security levels, or reachability) as well as due to the presence of multiple workgroups per customer. It is possible that one customer will run up to O(100) VPNs.
在某些情况下，服务提供商可能为该服务提供商的同一客户支持多个VPN。例如，这可能是由于每个VPN提供的服务不同（例如，不同的QoS、安全级别或可达性）以及每个客户存在多个工作组造成的。一个客户可能运行多达O（100）个VPN。
Since any VPN solution SHALL support private customer addresses, the number of addresses and address prefixes are important in evaluating the scaling requirements. The number of address prefixes used in routing protocols and in forwarding tables specific to the VPN needs to scale from very few (for smaller customers) to very large numbers seen in typical Service Provider backbones. The high end is especially true considering that many Tier 1 SPs may provide VPN services to Tier 2 SPs or to large corporations. For a L2 VPN this number would be on the order of addresses supported in typical native Layer 2 backbones.
由于任何VPN解决方案都应支持私有客户地址，因此地址数量和地址前缀在评估扩展需求时非常重要。在路由协议和专用于VPN的转发表中使用的地址前缀的数量需要从很少（对于较小的客户）扩展到非常大的数量，这在典型的服务提供商主干网中可以看到。考虑到许多第1层SP可能向第2层SP或大公司提供VPN服务，高端尤其如此。对于L2 VPN，此数字将按照典型的本机第2层主干中支持的地址顺序排列。
Each PPVPN solution SHALL document its scalability characteristics in quantitative terms. A VPN solution SHOULD quantify the amount of state that a PE and P device has to support. This SHOULD be stated in terms of the order of magnitude of the number of VPNs and site interfaces supported by the service provider. Ideally, all VPN-specific state SHOULD be contained in the PE device for a PE-based VPN. Similarly, all VPN-specific state SHOULD be contained in the CE device for a CE-based VPN. In all cases, the backbone routers (P devices) SHALL NOT maintain VPN-specific state as far as possible.
每个PPVPN解决方案应以定量方式记录其可扩展性特征。VPN解决方案应量化PE和P设备必须支持的状态量。这应该按照服务提供商支持的VPN和站点接口数量的数量级来说明。理想情况下，对于基于PE的VPN，所有特定于VPN的状态都应包含在PE设备中。类似地，对于基于CE的VPN，所有特定于VPN的状态都应包含在CE设备中。在所有情况下，主干路由器（P设备）应尽可能不保持VPN特定状态。
Another metric is that of complexity. In a PE-based solution the PE is more complex in that it has to maintain tunnel-specific information for each VPN, but the CE is simpler since it does not need to support tunnels. On the other hand, in a CE-based solution, the CE is more complex since it has to implement routing across a number of tunnels to other CEs in the VPN, but the PE is simpler since it has only one routing and forwarding instance. Thus, the complexity of the PE or CE SHOULD be noted in terms of their processing and management functions.
另一个指标是复杂性。在基于PE的解决方案中，PE更复杂，因为它必须为每个VPN维护特定于隧道的信息，但CE更简单，因为它不需要支持隧道。另一方面，在基于CE的解决方案中，CE更复杂，因为它必须实现跨多个隧道到VPN中其他CE的路由，但是PE更简单，因为它只有一个路由和转发实例。因此，应注意PE或CE在处理和管理功能方面的复杂性。
A service provider MUST have a means to view the topology, operational state, service order status, and other parameters associated with each customer's VPN. Furthermore, the service provider 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相关的其他参数。此外，服务提供商必须能够查看底层逻辑和物理拓扑、操作状态、供应状态以及与向其客户提供VPN服务的设备相关的其他参数。
In the multi-provider scenario, it is unlikely that participating providers would provide each other a view to the network topology and other parameters mentioned above. However, each provider MUST ensure via management of their own networks that the overall VPN service offered to the customers are properly managed. In general the support of a single VPN spanning multiple service providers requires close cooperation between the service providers. One aspect of this cooperation involves agreement on what information about the VPN will be visible across providers, and what network management protocols will be used between providers.
在多提供商场景中，参与提供商不太可能相互提供网络拓扑和上述其他参数的视图。但是，每个提供商必须通过管理自己的网络来确保向客户提供的整个VPN服务得到适当管理。通常，支持跨多个服务提供商的单个VPN需要服务提供商之间的密切合作。这种合作的一个方面涉及就VPN的哪些信息将在提供商之间可见以及提供商之间将使用哪些网络管理协议达成协议。
VPN devices SHOULD provide standards-based management interfaces wherever feasible.
VPN设备应尽可能提供基于标准的管理接口。
A customer SHOULD have a means to view the topology, operational state, service order status, and other parameters associated with his or her VPN.
客户应该能够查看拓扑、操作状态、服务订单状态以及与其VPN相关的其他参数。
All aspects of management information about CE devices and customer attributes of a PPVPN manageable by an SP SHOULD be capable of being configured and maintained by the customer after being authenticated and authorized.
SP可管理的PPVPN中有关CE设备和客户属性的管理信息的所有方面应能够在经过身份验证和授权后由客户进行配置和维护。
A customer 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
客户应该能够动态请求更改流量参数。客户应该能够收到SP网络对这些请求的实时响应。一
example of such as service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their VPN(s). A possible outcome of giving customers such capabilities is Denial of Service attacks on other VPN customers or Internet users. This possibility is documented in the Security Considerations section.
例如，服务的示例是“动态带宽管理”功能，该功能允许实时响应客户请求更改分配给其VPN的分配带宽。为客户提供此类功能的一个可能结果是对其他VPN客户或Internet用户的拒绝服务攻击。安全注意事项部分记录了这种可能性。
These requirements are driven by implementation characteristics that make service and provider requirements achievable.
这些需求由实现特性驱动，这些特性使服务和提供者需求可以实现。
VPN solutions SHOULD NOT pre-suppose or preclude the use of IETF developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or IPsec. The separation of VPN solution and tunnels will facilitate adaptability with extensions to current tunneling techniques or development of new tunneling techniques. It should be noted that the choice of the tunneling techniques may impact the service and scaling capabilities of the VPN solution.
VPN解决方案不应预先假定或排除使用IETF开发的隧道技术，如IP中的IP、L2TP、GRE、MPLS或IPsec。VPN解决方案和隧道的分离将促进对当前隧道技术的扩展或新隧道技术的开发的适应性。应该注意，隧道技术的选择可能会影响VPN解决方案的服务和扩展能力。
It should also be noted that specific tunneling techniques may not be feasible depending on the deployment scenario. In particular, there is currently very little use of MPLS in the inter-provider scenario. Thus, native MPLS support may be needed between the service providers, or it would be necessary to run MPLS over IP or GRE. It should be noted that if MPLS is run over IP or GRE, some of the other capabilities of MPLS, such as Traffic Engineering, would be impacted. Also note that a service provider MAY optionally choose to use a different encapsulation for multi-AS VPNs than is used for single AS VPNs. Similarly, a group of service providers may choose to use a different encapsulation for multi-service provider VPNs than for VPNs within a single service provider.
还应注意，根据部署场景，特定的隧道技术可能不可行。特别是，目前在提供商间场景中很少使用MPLS。因此，服务提供商之间可能需要本机MPLS支持，或者需要在IP或GRE上运行MPLS。应该注意的是，如果MPLS在IP或GRE上运行，MPLS的一些其他功能（如流量工程）将受到影响。还请注意，服务提供商可以选择对多AS VPN使用不同于单AS VPN的封装。类似地，一组服务提供商可以选择对多个服务提供商VPN使用与对单个服务提供商内的VPN不同的封装。
For Layer 2 VPNs, solutions SHOULD utilize the encapsulation techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3) Working Group, and SHOULD NOT impose any new requirements on these techniques.
对于第2层VPN，解决方案应利用伪线仿真边到边（PWE3）工作组定义的封装技术，并且不应对这些技术提出任何新要求。
PPVPN solutions MUST NOT impose any restrictions on the backbone traffic engineering and management techniques. Conversely, backbone engineering and management techniques MUST NOT affect the basic operation of a PPVPN, apart from influencing the SLA/SLS guarantees associated with the service. The SP SHOULD, however, be REQUIRED to provide per-VPN management, tunnel maintenance and other maintenance required in order to meet the SLA/SLS.
PPVPN解决方案不得对主干网流量工程和管理技术施加任何限制。相反，主干网工程和管理技术除了影响与服务相关的SLA/SLS保证外，不得影响PPVPN的基本操作。但是，SP应提供每VPN管理、隧道维护和其他维护，以满足SLA/SLS的要求。
By definition, VPN traffic SHOULD be segregated from each other, and from non-VPN traffic in the network. After all, VPNs are a means of dividing a physical network into several logical (virtual) networks. VPN traffic separation SHOULD be done in a scalable fashion. However, safeguards SHOULD be made available against misbehaving VPNs to not affect the network and other VPNs.
根据定义，VPN流量应相互隔离，并与网络中的非VPN流量隔离。毕竟，VPN是将物理网络划分为若干逻辑（虚拟）网络的一种手段。VPN流量分离应以可扩展的方式进行。但是，应针对行为不当的VPN提供保护措施，以免影响网络和其他VPN。
A VPN solution SHOULD NOT impose any hard limit on the number of VPNs provided in the network.
VPN解决方案不应对网络中提供的VPN数量施加任何硬限制。
The plug and play feature of a VPN solution with minimum configuration requirements is an important consideration. The VPN solutions SHOULD have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services or impact general Internet traffic handling in any way.
具有最低配置要求的VPN解决方案的即插即用功能是一个重要的考虑因素。VPN解决方案应具有针对客户接口和/或路由不稳定性的保护机制，以便它们不会影响其他客户的服务或以任何方式影响一般互联网流量处理。
A VPN SHOULD be provisioned with minimum number of steps. For instance, a VPN need not be configured in every PE. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which SHOULD be as common as possible to all VPN solutions, SHOULD be defined. However, these mechanisms SHOULD NOT adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack.
VPN应设置最少的步骤数。例如，不需要在每个PE中配置VPN。为了实现这一点，应该定义自动配置和自动发现协议，这对于所有VPN解决方案来说应该尽可能通用。但是，这些机制不应因过于复杂或增加协议栈中的层而对服务的成本、可伸缩性或稳定性产生不利影响。
Mechanisms to protect the SP network from effects of misconfiguration of VPNs SHOULD be provided. This is especially of importance in the multi-provider case, where misconfiguration could possibly impact more than one network.
应提供保护SP网络免受VPN错误配置影响的机制。这在多提供商情况下尤其重要，因为错误配置可能会影响多个网络。
The PPVPN control plane MUST include a mechanism through which the service provider can filter PPVPN related control plane information as it passes between Autonomous Systems. For example, if a service provider supports a PPVPN offering, but the service provider's neighbors do not participate in that offering, the service provider SHOULD NOT leak PPVPN control information into neighboring networks. Neighboring networks MUST be equipped with mechanisms that filter this information should the service provider leak it. This is important in the case of multi-provider VPNs as well as single-provider multi-AS VPNs.
PPVPN控制平面必须包括一种机制，通过该机制，服务提供商可以在PPVPN相关控制平面信息在自治系统之间传递时对其进行过滤。例如，如果服务提供商支持PPVPN产品，但服务提供商的邻居不参与该产品，则服务提供商不应将PPVPN控制信息泄漏到相邻网络中。相邻网络必须配备过滤机制，以便在服务提供商泄漏信息时过滤这些信息。这在多提供商VPN以及单提供商多VPN的情况下非常重要。
6.4. Requirements related to commonality of PPVPN mechanisms with each other and with generic Internet mechanisms
6.4. 与PPVPN机制之间以及与通用互联网机制之间的通用性相关的要求
As far as possible, the mechanisms used to establish a VPN service SHOULD re-use well-known IETF protocols, limiting the need to define new protocols from scratch. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based VPN service, SHALL NOT affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms SHOULD NOT conflict with the architectural principles of the Internet, nor SHOULD it put at risk the existing Internet systems. For example, IETF-developed routing protocols SHOULD be used for routing of L3 PPVPN traffic, without adding VPN-specific state to the Internet core routers. Similarly, well-known L2 technologies SHOULD be used in VPNs offering L2 services, without imposing risks to the Internet routers. A solution MUST be implementable without requiring additional functionality to the P devices in a network, and minimal functionality to the PE in a PE-based VPN and CE in a CE-based VPN.
用于建立VPN服务的机制应尽可能重复使用众所周知的IETF协议，从而限制从头定义新协议的需要。但是，应注意，使用互联网机制建立和运行基于互联网的VPN服务，不得影响互联网或互联网服务的稳定性、健壮性和可扩展性。换句话说，这些机制不应与互联网的架构原则相冲突，也不应使现有的互联网系统处于危险之中。例如，IETF开发的路由协议应用于L3 PPVPN流量的路由，而不向Internet核心路由器添加VPN特定状态。类似地，在提供L2服务的VPN中应使用众所周知的L2技术，而不会给Internet路由器带来风险。解决方案必须是可实施的，而不需要网络中的P设备的附加功能，以及基于PE的VPN中的PE和基于CE的VPN中的CE的最小功能。
In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different PPVPN solutions (both L2 and L3), e.g., discovery, signaling, routing and management, SHOULD be as common as possible.
除了与通用互联网机制的通用性外，不同PPVPN解决方案（L2和L3）中使用的基础设施机制，如发现、信令、路由和管理，应尽可能通用。
Each technical solution is expected to be based on interoperable Internet standards.
每个技术解决方案都将基于可互操作的互联网标准。
Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution SHOULD be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers.
应确保同一技术解决方案的不同实施之间在网元、网络和服务级别的多供应商互操作性（这可能取决于相应标准的完整性）。这是SP和客户的核心要求。
The technical solution MUST be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service.
该技术解决方案不仅在SP网络基础设施内，而且在使用PPVPN服务的客户网络设备和服务中，必须具有多供应商互操作性。
Customer access connections to a PPVPN solution may be different at different sites (e.g., Frame Relay on one site and Ethernet on another).
PPVPN解决方案的客户访问连接在不同站点可能不同（例如，一个站点上的帧中继和另一个站点上的以太网）。
Interconnection of a L2VPN over an L3VPN as if it were a customer site SHALL be supported. However, interworking of Layer 2 technologies is not required, and is outside the scope of the working group, and therefore, of this document.
应支持L2VPN在L3VPN上的互连，就像它是客户站点一样。但是，第2层技术的互通不是必需的，不在工作组的范围内，因此也不在本文件的范围内。
Inter-domain interoperability - It SHOULD be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet.
域间互操作性—应该可以跨域、自治系统或Internet部署PPVPN解决方案。
Security requirements for Provider Provisioned VPNs have been described in Section 4.5. In addition, the following considerations need to be kept in mind when a provider provisioned VPN service is provided across a public network infrastructure that is also used to provide Internet connectivity. In general, the security framework described in [VPN-SEC] SHOULD be used as far as it is applicable to the given type of PPVPN service.
第4.5节描述了提供商提供的VPN的安全要求。此外，当跨公共网络基础设施（也用于提供Internet连接）提供提供商提供的VPN服务时，需要记住以下注意事项。一般而言，[VPN-SEC]中描述的安全框架应尽可能适用于给定类型的PPVPN服务。
The PE device has a lot of functionality required for the successful operation of the VPN service. The PE device is frequently also part of the backbone providing Internet services, and is therefore susceptible to security and denial of service attacks. The PE control plane CPU is vulnerable from this point of view, and it may impact not only VPN services but also general Internet services if not adequately protected. In addition to VPN configuration, if mechanisms such as QoS are provisioned on the PE, it is possible for attackers to recognize the highest priority traffic or customers and launch directed attacks. Care SHOULD be taken to prevent such attacks whenever any value added services such as QoS are offered.
PE设备具有成功运行VPN服务所需的许多功能。PE设备通常也是提供Internet服务的主干网的一部分，因此容易受到安全和拒绝服务攻击。从这个角度来看，PE控制平面CPU是易受攻击的，如果没有充分保护，它不仅可能影响VPN服务，而且可能会影响一般互联网服务。除了VPN配置之外，如果PE上提供了QoS等机制，则攻击者有可能识别最高优先级的流量或客户，并发起定向攻击。在提供任何增值服务（如QoS）时，应注意防止此类攻击。
When a service such as "Dynamic Bandwidth Management" as described in Section 5.2.1 is provided, it allows customers to dynamically request for changes to their bandwidth allocation. The provider MUST take care to authenticate such requests and detect and prevent possible Denial-of-Service attacks. These DoS attacks are possible when a customer maliciously or accidentally may cause a change in bandwidth allocation that may impact the bandwidth allocated to other VPN customers or Internet users.
当提供第5.2.1节所述的“动态带宽管理”等服务时，它允许客户动态请求更改其带宽分配。提供商必须注意对此类请求进行身份验证，并检测和防止可能的拒绝服务攻击。当客户恶意或意外地导致带宽分配发生变化，从而影响分配给其他VPN客户或Internet用户的带宽时，这些DoS攻击是可能的。
Different choices of VPN technology have different assurance levels of the privacy of a customer's network. For example, CE-based solutions may enjoy more privacy than PE-based VPNs by virtue of tunnels extending from CE to CE, even if the tunnels are not encrypted. In a PE-based VPN, a PE has many more sites than those attached to a CE in a CE-based VPN. A large number of these sites may use [RFC1918] addresses. Provisioning mistakes and PE software bugs may make traffic more prone to being misdirected as opposed to a CE-based VPN. Care MUST be taken to prevent misconfiguration in all kinds of PPVPNs, but more care MUST be taken in the case of PE-based VPNs, as this could impact other customers and Internet services. Similarly, there SHOULD be mechanisms to prevent the flooding of
不同的VPN技术选择对客户网络的隐私有不同的保证级别。例如，通过从CE延伸到CE的隧道，基于CE的解决方案可能比基于PE的VPN享有更多隐私，即使隧道未加密。在基于PE的VPN中，PE的站点比基于CE的VPN中连接到CE的站点多得多。许多此类站点可能使用[RFC1918]地址。与基于CE的VPN相比，配置错误和PE软件错误可能使流量更容易被误导。必须注意防止各种PPVPN中的错误配置，但对于基于PE的VPN，必须更加小心，因为这可能会影响其他客户和互联网服务。同样，应该有防止洪水泛滥的机制
Internet routing tables whenever there is a misconfiguration or failure of PPVPN control mechanisms that use Internet routing protocols for relay of VPN-specific information.
当使用Internet路由协议中继VPN特定信息的PPVPN控制机制出现错误配置或故障时，使用Internet路由表。
Different deployment scenarios also dictate the level of security that may be needed for a VPN. For example, it is easier to control security in a single provider, single AS VPN and therefore, expensive encryption techniques may not be used in this case, as long as VPN traffic is isolated from the Internet. There is a reasonable amount of control possible in the single provider, multi AS case, although care SHOULD be taken to ensure the constrained distribution of VPN route information across the ASes. Security is more of a challenge in the multi-provider case, where it may be necessary to adopt encryption techniques in order to provide the highest level of security.
不同的部署场景还决定了VPN可能需要的安全级别。例如，在单个提供商（如VPN）中更容易控制安全性，因此，在这种情况下，只要VPN流量与Internet隔离，就可能不会使用昂贵的加密技术。虽然应注意确保VPN路由信息在整个ASE中的受限分布，但在单个提供商（如多个）中可能存在合理数量的控制。在多提供商的情况下，安全性更具挑战性，在这种情况下，可能需要采用加密技术以提供最高级别的安全性。
[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月。
[TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider Provisioned Virtual Private Networks", Work in Progress.
[术语]Andersson，L.，Madsen，T.，“提供商提供的虚拟专用网络术语”，正在进行中。
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, March 2003.
[L3FRAMEWORK]Callon，R.，Suzuki，M.，等人，“第3层提供商提供的虚拟专用网络框架”，正在进行的工作，2003年3月。
[L2FRAMEWORK] Andersson, L., et al. "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work in Progress, March 2004.
[L2框架]Andersson，L.等人，“第二层虚拟专用网络（L2VPN）框架”，正在进行的工作，2004年3月。
[L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress, April 2003.
[L3REQTS]Carugi，M.，McDysan，D.等人，“第3层提供商提供的虚拟专用网络的服务要求”，正在进行的工作，2003年4月。
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", Work in Progress, April 2003.
[L2REQTS]Augustyn，W.，Serbest，Y.，等人，“第2层提供商提供的虚拟专用网络的服务要求”，正在进行的工作，2003年4月。
[Y.1241] "IP Transfer Capability for the support of IP based Services", Y.1241 ITU-T Draft Recommendation, March 2000.
[Y.1241]“支持基于IP的服务的IP传输能力”，Y.1241 ITU-T建议草案，2000年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198]Westerinen，A.，Schnizlein，J.，Strassner，J.，Scherling，M.，Quinn，B.，Herzog，S.，Huynh，A.，Carlson，M.，Perry，J.和S.Waldbusser，“基于政策的管理术语”，RFC 3198，2001年11月。
[VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress, February 2004.
[VPN-SEC]Fang，L.等人，“提供商提供的虚拟专用网络的安全框架”，正在进行的工作，2004年2月。
[FRF.13] Frame Relay Forum, "Service Level Definitions Implementation Agreement", August 1998.
[FRF.13]帧中继论坛，“服务级别定义实施协议”，1998年8月。
[Y.1541] "Network Performance Objectives for IP-based Services", Y.1541, ITU-T Recommendation.
[Y.1541]“基于IP的服务的网络性能目标”，Y.1541，ITU-T建议。
This work was done in consultation with the entire design team for PPVPN requirements. A lot of the text was adapted from the Layer 3 requirements document produced by the Layer 3 requirements design team. The authors would also like to acknowledge the constructive feedback from Scott Bradner, Alex Zinin, Steve Bellovin, Thomas Narten and other IESG members, and the detailed comments from Ross Callon.
这项工作是在与整个设计团队协商PPVPN要求后完成的。很多文本都是从第三层需求设计团队制作的第三层需求文档中改编而来的。作者还要感谢Scott Bradner、Alex Zinin、Steve Bellovin、Thomas Narten和IESG其他成员的建设性反馈，以及Ross Callon的详细评论。
Ananth Nagarajan Juniper Networks
Ananth Nagarajan Juniper网络
EMail: ananth@juniper.net
EMail: ananth@juniper.net
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。