Network Working Group R. Callon
Request for Comments: 4110 Juniper Networks
Category: Informational M. Suzuki
NTT Corporation
July 2005
Network Working Group R. Callon
Request for Comments: 4110 Juniper Networks
Category: Informational M. Suzuki
NTT Corporation
July 2005
A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
第三层提供商提供的虚拟专用网络（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 a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.
本文档为第3层提供商提供的虚拟专用网络（PPVPN）提供了一个框架。该框架旨在帮助标准化协议和机制，以支持第3层PPVPN。本文件旨在对第3层PPVPN解决方案设计中重要的重要技术问题进行连贯的描述。具体方法的选择、工程权衡的选择以及详细的协议规范超出了本框架文件的范围。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives of the Document . . . . . . . . . . . . . . . 3
1.2. Overview of Virtual Private Networks . . . . . . . . . . 4
1.3. Types of VPNs. . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. CE- vs PE-based VPNs . . . . . . . . . . . . . . 8
1.3.2. Types of PE-based VPNs . . . . . . . . . . . . . 9
1.3.3. Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
1.4. Scope of the Document. . . . . . . . . . . . . . . . . . 10
1.5. Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
2.1.1. Entities in the Reference Model. . . . . . . . . 16
2.1.2. Relationship Between CE and PE . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives of the Document . . . . . . . . . . . . . . . 3
1.2. Overview of Virtual Private Networks . . . . . . . . . . 4
1.3. Types of VPNs. . . . . . . . . . . . . . . . . . . . . . 7
1.3.1. CE- vs PE-based VPNs . . . . . . . . . . . . . . 8
1.3.2. Types of PE-based VPNs . . . . . . . . . . . . . 9
1.3.3. Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
1.4. Scope of the Document. . . . . . . . . . . . . . . . . . 10
1.5. Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
2.1.1. Entities in the Reference Model. . . . . . . . . 16
2.1.2. Relationship Between CE and PE . . . . . . . . . 18
2.1.3. Interworking Model . . . . . . . . . . . . . . . 19
2.2. Reference Model for Layer 3 Provider-Provisioned
CE-based VPN . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1. Entities in the Reference Model. . . . . . . . . 22
3. Customer Interface . . . . . . . . . . . . . . . . . . . . . . 23
3.1. VPN Establishment at the Customer Interface. . . . . . . 23
3.1.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 23
3.1.1.1. Static Binding . . . . . . . . . . . . 24
3.1.1.2. Dynamic Binding. . . . . . . . . . . . 24
3.1.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 25
3.2. Data Exchange at the Customer Interface. . . . . . . . . 25
3.2.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 25
3.2.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 26
3.3. Customer Visible Routing . . . . . . . . . . . . . . . . 26
3.3.1. Customer View of Routing for Layer 3 PE-based
VPNs . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1.1. Routing for Intranets . . . . . . . . 27
3.3.1.2. Routing for Extranets . . . . . . . . 28
3.3.1.3. CE and PE Devices for Layer 3
PE-based VPNs. . . . . . . . . . . . . 29
3.3.2. Customer View of Routing for Layer 3 Provider-
Provisioned CE-based VPNs. . . . . . . . . . . . 29
3.3.3. Options for Customer Visible Routing . . . . . . 30
4. Network Interface and SP Support of VPNs . . . . . . . . . . . 32
4.1. Functional Components of a VPN . . . . . . . . . . . . . 32
4.2. VPN Establishment and Maintenance. . . . . . . . . . . . 34
4.2.1. VPN Discovery . . . . . . . . . . . . . . . . . 35
4.2.1.1. Network Management for Membership
Information. . . . . . . . . . . . . . 35
4.2.1.2. Directory Servers. . . . . . . . . . . 36
4.2.1.3. Augmented Routing for Membership
Information. . . . . . . . . . . . . . 36
4.2.1.4. VPN Discovery for Inter-SP VPNs. . . . 37
4.2.2. Constraining Distribution of VPN Routing
Information . . . . . . . . . . . . . . . . . . 38
4.2.3. Controlling VPN Topology . . . . . . . . . . . . 38
4.3. VPN Tunneling . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Tunnel Encapsulations. . . . . . . . . . . . . . 40
4.3.2. Tunnel Multiplexing. . . . . . . . . . . . . . . 41
4.3.3. Tunnel Establishment . . . . . . . . . . . . . . 42
4.3.4. Scaling and Hierarchical Tunnels . . . . . . . . 43
4.3.5. Tunnel Maintenance . . . . . . . . . . . . . . . 45
4.3.6. Survey of Tunneling Techniques . . . . . . . . . 46
4.3.6.1. GRE . . . . . . . . . . . . . . . . . 46
4.3.6.2. IP-in-IP Encapsulation . . . . . . . . 47
4.3.6.3. IPsec. . . . . . . . . . . . . . . . . 48
4.3.6.4. MPLS . . . . . . . . . . . . . . . . . 49
4.4. PE-PE Distribution of VPN Routing Information. . . . . . 51
2.1.3. Interworking Model . . . . . . . . . . . . . . . 19
2.2. Reference Model for Layer 3 Provider-Provisioned
CE-based VPN . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1. Entities in the Reference Model. . . . . . . . . 22
3. Customer Interface . . . . . . . . . . . . . . . . . . . . . . 23
3.1. VPN Establishment at the Customer Interface. . . . . . . 23
3.1.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 23
3.1.1.1. Static Binding . . . . . . . . . . . . 24
3.1.1.2. Dynamic Binding. . . . . . . . . . . . 24
3.1.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 25
3.2. Data Exchange at the Customer Interface. . . . . . . . . 25
3.2.1. Layer 3 PE-based VPN . . . . . . . . . . . . . . 25
3.2.2. Layer 3 Provider-Provisioned CE-based VPN. . . . 26
3.3. Customer Visible Routing . . . . . . . . . . . . . . . . 26
3.3.1. Customer View of Routing for Layer 3 PE-based
VPNs . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1.1. Routing for Intranets . . . . . . . . 27
3.3.1.2. Routing for Extranets . . . . . . . . 28
3.3.1.3. CE and PE Devices for Layer 3
PE-based VPNs. . . . . . . . . . . . . 29
3.3.2. Customer View of Routing for Layer 3 Provider-
Provisioned CE-based VPNs. . . . . . . . . . . . 29
3.3.3. Options for Customer Visible Routing . . . . . . 30
4. Network Interface and SP Support of VPNs . . . . . . . . . . . 32
4.1. Functional Components of a VPN . . . . . . . . . . . . . 32
4.2. VPN Establishment and Maintenance. . . . . . . . . . . . 34
4.2.1. VPN Discovery . . . . . . . . . . . . . . . . . 35
4.2.1.1. Network Management for Membership
Information. . . . . . . . . . . . . . 35
4.2.1.2. Directory Servers. . . . . . . . . . . 36
4.2.1.3. Augmented Routing for Membership
Information. . . . . . . . . . . . . . 36
4.2.1.4. VPN Discovery for Inter-SP VPNs. . . . 37
4.2.2. Constraining Distribution of VPN Routing
Information . . . . . . . . . . . . . . . . . . 38
4.2.3. Controlling VPN Topology . . . . . . . . . . . . 38
4.3. VPN Tunneling . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Tunnel Encapsulations. . . . . . . . . . . . . . 40
4.3.2. Tunnel Multiplexing. . . . . . . . . . . . . . . 41
4.3.3. Tunnel Establishment . . . . . . . . . . . . . . 42
4.3.4. Scaling and Hierarchical Tunnels . . . . . . . . 43
4.3.5. Tunnel Maintenance . . . . . . . . . . . . . . . 45
4.3.6. Survey of Tunneling Techniques . . . . . . . . . 46
4.3.6.1. GRE . . . . . . . . . . . . . . . . . 46
4.3.6.2. IP-in-IP Encapsulation . . . . . . . . 47
4.3.6.3. IPsec. . . . . . . . . . . . . . . . . 48
4.3.6.4. MPLS . . . . . . . . . . . . . . . . . 49
4.4. PE-PE Distribution of VPN Routing Information. . . . . . 51
4.4.1. Options for VPN Routing in the SP. . . . . . . . 52
4.4.2. VPN Forwarding Instances . . . . . . . . . . . . 52
4.4.3. Per-VPN Routing . . . . . . . . . . . . . . . . 53
4.4.4. Aggregated Routing Model . . . . . . . . . . . . 54
4.4.4.1. Aggregated Routing with OSPF or IS-IS. 55
4.4.4.2. Aggregated Routing with BGP. . . . . . 56
4.4.5. Scalability and Stability of Routing with Layer
3 PE-based VPNs. . . . . . . . . . . . . . . . . 59
4.5. Quality of Service, SLAs, and IP Differentiated Services 61
4.5.1. IntServ/RSVP . . . . . . . . . . . . . . . . . . 61
4.5.2. DiffServ . . . . . . . . . . . . . . . . . . . . 62
4.6. Concurrent Access to VPNs and the Internet . . . . . . . 62
4.7. Network and Customer Management of VPNs. . . . . . . . . 63
4.7.1. Network and Customer Management. . . . . . . . . 63
4.7.2. Segregated Access of VPN Information . . . . . . 64
5. Interworking Interface . . . . . . . . . . . . . . . . . . . . 66
5.1. Interworking Function. . . . . . . . . . . . . . . . . . 66
5.2. Interworking Interface . . . . . . . . . . . . . . . . . 66
5.2.1. Tunnels at the Interworking Interface. . . . . . 67
5.3. Support of Additional Services . . . . . . . . . . . . . 68
5.4. Scalability Discussion . . . . . . . . . . . . . . . . . 69
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 69
6.1. System Security. . . . . . . . . . . . . . . . . . . . . 70
6.2. Access Control . . . . . . . . . . . . . . . . . . . . . 70
6.3. Endpoint Authentication . . . . . . . . . . . . . . . . 70
6.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . 71
6.5. Confidentiality. . . . . . . . . . . . . . . . . . . . . 71
6.6. User Data and Control Data . . . . . . . . . . . . . . . 72
6.7. Security Considerations for Inter-SP VPNs . . . . . . . 72
Appendix A: Optimizations for Tunnel Forwarding. . . . . . . . . . 73
A.1. Header Lookups in the VFIs . . . . . . . . . . . . . . . 73
A.2. Penultimate Hop Popping for MPLS . . . . . . . . . . . . 73
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 74
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 75
Normative References . . . . . . . . . . . . . . . . . . . . . . . 76
Informative References . . . . . . . . . . . . . . . . . . . . . . 76
Contributors' Addresses. . . . . . . . . . . . . . . . . . . . . . 80
4.4.1. Options for VPN Routing in the SP. . . . . . . . 52
4.4.2. VPN Forwarding Instances . . . . . . . . . . . . 52
4.4.3. Per-VPN Routing . . . . . . . . . . . . . . . . 53
4.4.4. Aggregated Routing Model . . . . . . . . . . . . 54
4.4.4.1. Aggregated Routing with OSPF or IS-IS. 55
4.4.4.2. Aggregated Routing with BGP. . . . . . 56
4.4.5. Scalability and Stability of Routing with Layer
3 PE-based VPNs. . . . . . . . . . . . . . . . . 59
4.5. Quality of Service, SLAs, and IP Differentiated Services 61
4.5.1. IntServ/RSVP . . . . . . . . . . . . . . . . . . 61
4.5.2. DiffServ . . . . . . . . . . . . . . . . . . . . 62
4.6. Concurrent Access to VPNs and the Internet . . . . . . . 62
4.7. Network and Customer Management of VPNs. . . . . . . . . 63
4.7.1. Network and Customer Management. . . . . . . . . 63
4.7.2. Segregated Access of VPN Information . . . . . . 64
5. Interworking Interface . . . . . . . . . . . . . . . . . . . . 66
5.1. Interworking Function. . . . . . . . . . . . . . . . . . 66
5.2. Interworking Interface . . . . . . . . . . . . . . . . . 66
5.2.1. Tunnels at the Interworking Interface. . . . . . 67
5.3. Support of Additional Services . . . . . . . . . . . . . 68
5.4. Scalability Discussion . . . . . . . . . . . . . . . . . 69
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 69
6.1. System Security. . . . . . . . . . . . . . . . . . . . . 70
6.2. Access Control . . . . . . . . . . . . . . . . . . . . . 70
6.3. Endpoint Authentication . . . . . . . . . . . . . . . . 70
6.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . 71
6.5. Confidentiality. . . . . . . . . . . . . . . . . . . . . 71
6.6. User Data and Control Data . . . . . . . . . . . . . . . 72
6.7. Security Considerations for Inter-SP VPNs . . . . . . . 72
Appendix A: Optimizations for Tunnel Forwarding. . . . . . . . . . 73
A.1. Header Lookups in the VFIs . . . . . . . . . . . . . . . 73
A.2. Penultimate Hop Popping for MPLS . . . . . . . . . . . . 73
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 74
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 75
Normative References . . . . . . . . . . . . . . . . . . . . . . . 76
Informative References . . . . . . . . . . . . . . . . . . . . . . 76
Contributors' Addresses. . . . . . . . . . . . . . . . . . . . . . 80
This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable layer 3 PPVPNs.
本文档为第3层提供商提供的虚拟专用网络（PPVPN）提供了一个框架。该框架旨在帮助标准化协议和机制，以支持可互操作的第3层PPVPN。
The term "provider-provisioned VPNs" refers to Virtual Private Networks (VPNs) for which the Service Provider (SP) participates in management and provisioning of the VPN, as defined in section 1.3. There are multiple ways in which a provider can participate in managing and provisioning a VPN; therefore, there are multiple different types of PPVPNs. The framework document discusses layer 3 VPNs (as defined in section 1.3).
术语“提供商提供的VPN”是指服务提供商（SP）参与VPN管理和提供的虚拟专用网络（VPN），如第1.3节所定义。提供商可以通过多种方式参与VPN的管理和配置；因此，存在多种不同类型的PPVPN。框架文件讨论了第3层VPN（定义见第1.3节）。
First, this document provides a reference model for layer 3 PPVPNs. Then technical aspects of layer 3 PPVPN operation are discussed, first from the customer's point of view, then from the providers point of view. Specifically, this includes discussion of the technical issues which are important in the design of standards and mechanisms for the operation and support of layer 3 PPVPNs. Furthermore, technical aspects of layer 3 PPVPN interworking are clarified. Finally, security issues as they apply to layer 3 PPVPNs are addressed.
首先，本文档提供了第3层PPVPN的参考模型。然后讨论了第3层PPVPN操作的技术方面，首先从客户的角度，然后从提供商的角度。具体而言，这包括对技术问题的讨论，这些问题在设计第3层PPVPN运行和支持的标准和机制时非常重要。此外，还阐明了第3层PPVPN互通的技术方面。最后，解决了应用于第3层PPVPN的安全问题。
This document takes a "horizontal description" approach. For each technical issue, it describes multiple approaches. To specify a particular PPVPN strategy, one must choose a particular way of solving each problem, but this document does not make choices, and does not select any particular approach to support VPNs.
本文件采用“横向描述”方法。对于每个技术问题，它描述了多种方法。要指定特定的PPVPN策略，必须选择解决每个问题的特定方法，但本文档不作选择，也不选择任何支持VPN的特定方法。
The "vertical description" approach is taken in other documents, viz., in the documents that describe particular PPVPN solutions. Note that any specific solution will need to make choices based on SP requirements, customer needs, implementation cost, and engineering tradeoffs. Solutions will need to chose between flexibility (supporting multiple options) and conciseness (selection of specific options in order to simplify implementation and deployment). While a framework document can discuss issues and criteria which are used as input to these choices, the specific selection of a solution is outside of the scope of a framework document.
其他文档中采用了“垂直描述”方法，即在描述特定PPVPN解决方案的文档中。请注意，任何特定的解决方案都需要根据SP需求、客户需求、实施成本和工程权衡做出选择。解决方案需要在灵活性（支持多个选项）和简洁性（选择特定选项以简化实施和部署）之间进行选择。虽然框架文档可以讨论作为这些选择输入的问题和标准，但解决方案的具体选择不在框架文档的范围之内。
The term "Virtual Private Network" (VPN) refers to a set of communicating sites, where (a) communication between sites outside the set and sites inside the set is restricted, but (b) communication between sites in the VPN takes place over a network infrastructure that is also used by sites which are not in the VPN. The fact that the network infrastructure is shared by multiple VPNs (and possibly also by non-VPN traffic) is what distinguishes a VPN from a private network. We will refer to this shared network infrastructure as the "VPN Backbone".
术语“虚拟专用网络”（VPN）是指一组通信站点，其中（a）该组外部站点和该组内部站点之间的通信受到限制，但（b）VPN中站点之间的通信通过网络基础设施进行，该网络基础设施也由不在VPN中的站点使用。网络基础设施由多个VPN共享（也可能由非VPN流量共享）这一事实是VPN与专用网络的区别。我们将此共享网络基础设施称为“VPN主干网”。
The logical structure of the VPN, such as addressing, topology, connectivity, reachability, and access control, is equivalent to part of or all of a conventional private network using private facilities [RFC2764] [VPN-2547BIS].
VPN的逻辑结构，如寻址、拓扑、连接、可达性和访问控制，相当于使用专用设施的传统专用网络的一部分或全部[RFC2764][VPN-2547BIS]。
In this document, we are concerned only with the case where the shared network infrastructure (VPN backbone) is an IP and/or MPLS network. Further, we are concerned only with the case where the Service Provider's edge devices, whether at the provider edge (PE) or at the Customer Edge (CE), determine how to route VPN traffic by looking at the IP and/or MPLS headers of the packets they receive from the customer's edge devices; this is the distinguishing feature of Layer 3 VPNs.
在本文档中，我们只关注共享网络基础设施（VPN主干）是IP和/或MPLS网络的情况。此外，我们只关注服务提供商的边缘设备，无论是在提供商边缘（PE）还是在客户边缘（CE），通过查看从客户边缘设备接收的数据包的IP和/或MPLS报头来确定如何路由VPN流量的情况；这是第3层VPN的显著特征。
In some cases, one SP may offer VPN services to another SP. The former SP is known as a carrier of carriers, and the service it offers is known as "carrier of carriers" service. In this document, in cases where the customer could be either an enterprise or SP network, we will make use of the term "customer" to refer to the user of the VPN services. Similarly we will use the term "customer network" to refer to the user's network.
在某些情况下，一个SP可能会向另一个SP提供VPN服务。前一个SP被称为运营商的运营商，它提供的服务被称为“运营商的运营商”服务。在本文档中，如果客户可能是企业或SP网络，我们将使用术语“客户”来指代VPN服务的用户。同样，我们将使用术语“客户网络”来指代用户的网络。
VPNs may be intranets, in which the multiple sites are under the control of a single customer administration, such as multiple sites of a single company. Alternatively, VPNs may be extranets, in which the multiple sites are controlled by administrations of different customers, such as sites corresponding to a company, its suppliers, and its customers.
VPN可以是内部网，其中多个站点在单个客户管理的控制下，例如单个公司的多个站点。或者，VPN可以是外网，其中多个站点由不同客户的管理机构控制，例如对应于公司、其供应商和客户的站点。
Figure 1.1. illustrates an example network, which will be used in the discussions below. PE1 and PE2 are Provider Edge devices within an SP network. CE1, CE2, and CE3 are Customer Edge devices within a customer network. Routers r3, r4, r5, and r6 are IP routers internal to the customer sites.
图1.1。说明了一个示例网络，将在下面的讨论中使用。PE1和PE2是SP网络中的提供商边缘设备。CE1、CE2和CE3是客户网络中的客户边缘设备。路由器r3、r4、r5和r6是客户站点内部的IP路由器。
............ ................. ............
. . . . . .
. +---+ +-------+ +-------+ +---+ .
. r3---| | | | | |----|CE2|---r5 .
. | | | | | | +---+ .
. |CE1|----| PE1 | | PE2 | : .
. | | | | | | +---+ .
. r4---| | | | | |----|CE3|---r6 .
. +---+ +-------+ +-------+ +---+ .
. Customer . . Service . . Customer .
. site 1 . . provider(s) . . site 2 .
............ ................. ............
............ ................. ............
. . . . . .
. +---+ +-------+ +-------+ +---+ .
. r3---| | | | | |----|CE2|---r5 .
. | | | | | | +---+ .
. |CE1|----| PE1 | | PE2 | : .
. | | | | | | +---+ .
. r4---| | | | | |----|CE3|---r6 .
. +---+ +-------+ +-------+ +---+ .
. Customer . . Service . . Customer .
. site 1 . . provider(s) . . site 2 .
............ ................. ............
Figure 1.1.: VPN interconnecting two sites.
图1.1：连接两个站点的VPN。
In many cases, Provider Edge (PE) and Customer Edge (CE) devices may be either routers or LSRs.
在许多情况下，提供商边缘（PE）和客户边缘（CE）设备可以是路由器或LSR。
In this document, the Service Providers' network is an IP or MPLS network. It is desired to interconnect the customer network sites via the Service Providers' network. Some VPN solutions require that the VPN service be provided either over a single SP network, or over a small set of closely cooperating SP networks. Other VPN solutions are intended to allow VPN service to be provided over an arbitrary set of minimally cooperating SP networks (i.e., over the public Internet).
在本文档中，服务提供商的网络是IP或MPLS网络。希望通过服务提供商的网络互连客户网络站点。一些VPN解决方案要求通过单个SP网络或通过一小部分密切合作的SP网络提供VPN服务。其他VPN解决方案旨在允许通过任意一组最少协作的SP网络（即，通过公共互联网）提供VPN服务。
In many cases, customer networks will make use of private IP addresses [RFC1918] or other non-unique IP address (i.e., unregistered addresses); there is no guarantee that the IP addresses used in the customer network are globally unique. The addresses used in one customer's network may overlap the addresses used in others. However, a single PE device can be used to provide VPN service to multiple customer networks, even if those customer networks have overlapping addresses. In PE-based layer 3 VPNs, the PE devices may route the VPN traffic based on the customer addresses found in the IP headers; this implies that the PE devices need to maintain a level of isolation between the packets from different customer networks. In CE-based layer 3 VPNs, the PEs do not make routing decisions based on the customer's private addresses, so this issue does not arise. For either PE or CE-based VPNs, the fact that the VPNs do not necessarily use globally unique address spaces also implies that IP packets from a customer network cannot be transmitted over the SP network in their native form. Instead, some form of encapsulation/tunneling must be used.
在许多情况下，客户网络将使用专用IP地址[RFC1918]或其他非唯一IP地址（即未注册地址）；无法保证客户网络中使用的IP地址是全局唯一的。一个客户网络中使用的地址可能与其他客户网络中使用的地址重叠。然而，单个PE设备可用于向多个客户网络提供VPN服务，即使这些客户网络具有重叠的地址。在基于PE的第3层VPN中，PE设备可以基于在IP报头中找到的客户地址路由VPN流量；这意味着PE设备需要在来自不同客户网络的数据包之间保持一定程度的隔离。在基于CE的第3层VPN中，PEs不会根据客户的专用地址做出路由决策，因此不会出现此问题。对于基于PE或CE的VPN，VPN不一定使用全局唯一地址空间这一事实也意味着来自客户网络的IP数据包不能以其本机形式通过SP网络传输。相反，必须使用某种形式的封装/隧道。
Tunneling is also important for other reasons, such as providing isolation between different customer networks, allowing a wide range of protocols to be carried over an SP network, etc. Different QoS and security characteristics may be associated with different tunnels.
隧道对于其他原因也很重要，例如在不同的客户网络之间提供隔离，允许在SP网络上承载各种协议等。不同的QoS和安全特性可能与不同的隧道相关。
This section describes multiple types of VPNs, and some of the engineering tradeoffs between different types. It is not up to this document to decide between different types of VPNs. Different types of VPNs may be appropriate in different situations.
本节介绍多种类型的VPN，以及不同类型之间的一些工程权衡。不同类型的VPN之间的选择不取决于本文档。不同类型的VPN可能适用于不同的情况。
There is a wide spectrum of types of possible VPNs, and it is difficult to split the types of VPNs into clearly distinguished categories.
可能的虚拟专用网络种类繁多，很难将虚拟专用网络的类型划分为明确区分的类别。
As an example, consider a company making use of a private network, with several sites interconnected via leased lines. All routing is done via routers which are internal to the private network.
作为一个例子，考虑使用私有网络的公司，通过租用线路互连多个站点。所有路由都是通过专用网络内部的路由器完成的。
At some point, the administrator of the private network might decide to replace the leased lines by ATM links (using an ATM service from an SP). Here again all IP-level routing is done between customer premises routers, and managed by the private network administrator.
在某个时候，专用网络的管理员可能会决定用ATM链路（使用来自SP的ATM服务）替换租用线路。在这里，所有IP级别的路由都在客户场所路由器之间完成，并由专用网络管理员管理。
In order to reduce the network management burden on the private network, the company may decide to make use of a provider-provisioned CE devices [VPN-CE]. Here the operation of the network might be unchanged, except that the CE devices would be provided by and managed by an SP.
为了减少专用网络上的网络管理负担，公司可以决定使用提供商提供的CE设备[VPN-CE]。在这里，网络的操作可能不会改变，但CE设备将由SP提供和管理。
The SP might decide that it is too difficult to manually configure each CE-CE link. This might lead the SP to replace the ATM links with a layer 2 VPN service between CE devices [VPN-L2]. Auto-discovery might be used to simplify configuration of links between CE devices, and an MPLS service might be used between CE devices instead of an ATM service (for example, to take advantage of the provider's high speed IP or MPLS backbone).
SP可能会认为手动配置每个CE-CE链路太困难。这可能导致SP用CE设备之间的第2层VPN服务取代ATM链路[VPN-L2]。自动发现可用于简化CE设备之间链路的配置，并且可以在CE设备之间使用MPLS服务而不是ATM服务（例如，利用提供商的高速IP或MPLS主干网）。
After a while the SP might decide that it is too much trouble to be managing a large number of devices at the customers' premises, and might instead physically move these routers to be on the provider premises. Each edge router at the provider premises might nonetheless be dedicated to a single VPN. The operation might remain unchanged (except that links from the edge routers to other routers in the private network become MAN links instead of LAN links, and the link from the edge routers to provider core routers become LAN links
过了一段时间，SP可能会认为在客户场所管理大量设备太麻烦，而可能会将这些路由器移动到提供商场所。尽管如此，提供商场所的每个边缘路由器可能专用于单个VPN。操作可能保持不变（除了从边缘路由器到专用网络中其他路由器的链路变为MAN链路而不是LAN链路，并且从边缘路由器到提供商核心路由器的链路变为LAN链路
instead of MAN links). The routers in question can now be considered to be provider edge routers, and the service provided by the SP has now become essentially a layer 3 VPN service.
而不是人链接）。所讨论的路由器现在可以被视为提供商边缘路由器，SP提供的服务现在基本上已成为第3层VPN服务。
In order to minimize the cost of equipment, the provider might decide to replace several dedicated PE devices with a single physical router with the capability of running virtual routers (VR) [VPN-VR]. Protocol operation may remain unchanged. In this case the provider is offering a layer 3 VPN service making use of a VR capability. Note that autodiscovery might be used in a manner which is very similar to how it had been done in the layer 2 VPN case described above (for example, BGP might be used between VRs for discovery of other VRs supporting the same VPN).
为了最大限度地降低设备成本，提供商可能会决定用一个能够运行虚拟路由器（VR）[VPN-VR]的物理路由器替换多个专用PE设备。协议操作可能保持不变。在这种情况下，提供商利用VR功能提供第3层VPN服务。请注意，自动发现的使用方式可能与上述第2层VPN案例中的使用方式非常相似（例如，可以在VRs之间使用BGP来发现支持相同VPN的其他VRs）。
Finally, in order to simplify operation of routing protocols for the private network over the SP network, the provider might decide to aggregate multiple instances of routing into a single instance of BGP [VPN-2547BIS].
最后，为了简化SP网络上专用网络路由协议的操作，提供商可能决定将多个路由实例聚合到BGP[VPN-2547BIS]的单个实例中。
In practice it is highly unlikely that any one network would actually evolve through all of these approaches at different points in time. However, this example illustrates that there is a continuum of possible approaches, and each approach is relatively similar to at least some of the other possible approaches for supporting VPN services. Some techniques (such as auto-discovery of VPN sites) may be common between multiple approaches.
在实践中，任何一个网络都不太可能在不同的时间点通过所有这些方法演变。然而，该示例说明了存在一系列可能的方法，并且每种方法都相对类似于支持VPN服务的至少一些其他可能的方法。一些技术（如VPN站点的自动发现）可能在多种方法之间是通用的。
The term "CE-based VPN" (or Customer Edge-based Virtual Private Network) refers to an approach in which the PE devices do not know anything about the routing or the addressing of the customer networks. The PE devices offer a simple IP service, and expect to receive IP packets whose headers contain only globally unique IP addresses. What makes a CE-based VPN into a Provider-Provisioned VPN is that the SP takes on the task of managing and provisioning the CE devices [VPN-CE].
术语“基于CE的VPN”（或基于客户边缘的虚拟专用网络）指的是PE设备对客户网络的路由或寻址一无所知的方法。PE设备提供一个简单的IP服务，并期望接收其标头仅包含全局唯一IP地址的IP数据包。基于CE的VPN之所以成为提供商配置的VPN，是因为SP承担了管理和配置CE设备的任务[VPN-CE]。
In CE-based VPNs, the backbone of the customer network is a set of tunnels whose endpoints are the CE devices. Various kinds of tunnels may be used (e.g., GRE, IP-in-IP, IPsec, L2TP, MPLS), the only overall requirement being that sending a packet through the tunnel requires encapsulating it with a new IP header whose addresses are globally unique.
在基于CE的VPN中，客户网络的主干是一组隧道，其端点是CE设备。可以使用各种类型的隧道（例如，GRE、IP中的IP、IPsec、L2TP、MPLS），唯一的总体要求是通过隧道发送数据包需要使用地址全局唯一的新IP报头对其进行封装。
For customer provisioned CE-based VPNs, provisioning and management of the tunnels is the responsibility of the customer network administration. Typically, this makes use of manual configuration of
对于客户提供的基于CE的VPN，隧道的提供和管理由客户网络管理部门负责。通常，这会使用手动配置
the tunnels. In this case the customer is also responsible for operation of the routing protocol between CE devices. (Note that discussion of customer provisioned CE-based VPNs is out of scope of the document).
隧道。在这种情况下，客户还负责CE设备之间路由协议的操作。（请注意，关于客户提供的基于CE的VPN的讨论超出了本文档的范围）。
For provider-provisioned CE-based VPNs, provisioning and management of the tunnels is the responsibility of the SP. In this case the provider may also configure routing protocols on the CE devices. This implies that routing in the private network is partially under the control of the customer, and partially under the control of the SP.
对于提供商提供的基于CE的VPN，隧道的提供和管理由SP负责。在这种情况下，提供商还可以在CE设备上配置路由协议。这意味着专用网络中的路由部分由客户控制，部分由SP控制。
For CE-based VPNs (whether customer or provider-provisioned) routing in the customer network treats the tunnels as layer 2 links.
对于基于CE的VPN（无论是客户还是提供商提供的），客户网络中的路由将隧道视为第2层链路。
In a PE-based VPN (or Provider Edge-based Virtual Private Network), customer packets are carried through the SP networks in tunnels, just as they are in CE-based VPNs. However, in a PE-based VPN, the tunnel endpoints are the PE devices, and the PE devices must know how to route the customer packets, based on the IP addresses that they carry. In this case, the CE devices themselves do not have to have any special VPN capabilities, and do not even have to know that they are part of a VPN.
在基于PE的VPN（或基于提供商边缘的虚拟专用网络）中，客户数据包通过隧道中的SP网络传输，就像它们在基于CE的VPN中一样。但是，在基于PE的VPN中，隧道端点是PE设备，并且PE设备必须知道如何根据其携带的IP地址路由客户数据包。在这种情况下，CE设备本身不必具有任何特殊的VPN功能，甚至不必知道它们是VPN的一部分。
In this document we will use the generic term "VPN Edge Device" to refer to the device, attached to both the customer network and the VPN backbone, that performs the VPN-specific functions. In the case of CE-based VPNs, the VPN Edge Device is a CE device. In the case of PE-based VPNs, the VPN Edge Device is a PE device.
在本文档中，我们将使用通用术语“VPN边缘设备”来指连接到客户网络和VPN主干的设备，该设备执行VPN特定功能。在基于CE的VPN的情况下，VPN边缘设备是CE设备。在基于PE的VPN的情况下，VPN边缘设备是PE设备。
Different types of PE-based VPNs may be distinguished by the service offered.
不同类型的基于PE的VPN可以根据提供的服务进行区分。
o Layer 3 service
o 第三层服务
When a PE receives a packet from a CE, it determines how to forward the packet by considering both the packet's incoming link, and the layer 3 information in the packet's header.
当PE从CE接收到分组时，它通过考虑分组的传入链路和分组报头中的第3层信息来确定如何转发分组。
o Layer 2 service
o 第二层服务
When a PE receives a frame from a CE, it determines how to forward the packet by considering both the packet's incoming link, and the layer 2 information in the frame header (such as FR, ATM, or MAC header). (Note that discussion of layer 2 service is out of scope of the document).
当PE从CE接收到帧时，它通过考虑分组的传入链路和帧报头（例如FR、ATM或MAC报头）中的第2层信息来确定如何转发分组。（请注意，对第2层服务的讨论超出了本文档的范围）。
A layer 3 PE-based VPN is one in which the SP takes part in IP level forwarding based on the customer network's IP address space. In general, the customer network is likely to make use of private and/or non-unique IP addresses. This implies that at least some devices in the provider network needs to understand the IP address space as used in the customer network. Typically this knowledge is limited to the PE devices which are directly attached to the customer.
基于第3层PE的VPN是SP根据客户网络的IP地址空间参与IP级转发的VPN。通常，客户网络可能会使用专用和/或非唯一的IP地址。这意味着提供商网络中的至少一些设备需要了解客户网络中使用的IP地址空间。通常，这种知识仅限于直接连接到客户的PE设备。
In a layer 3 PE-based VPN, the provider will need to participate in some aspects of management and provisioning of the VPNs, such as ensuring that the PE devices are configured to support the correct VPNs. This implies that layer 3 PE-based VPNs are by definition provider-provisioned VPNs.
在基于第3层PE的VPN中，提供商需要参与VPN管理和供应的某些方面，例如确保PE设备配置为支持正确的VPN。这意味着基于第3层PE的VPN根据定义是由提供商提供的VPN。
Layer 3 PE-based VPNs have the advantage that they offload some aspects of VPN management from the customer network. From the perspective of the customer network, it looks as if there is just a normal network; specific VPN functionality is hidden from the customer network. Scaling of the customer network's routing might also be improved, since some layer 3 PE-based VPN approaches avoid the need for the customer's routing algorithm to see "N squared" (actually N*(N-1)/2) point to point duplex links between N customer sites.
基于第3层PE的VPN的优点是，它们可以从客户网络中卸载VPN管理的某些方面。从客户网络的角度来看，似乎只有一个正常的网络；特定VPN功能对客户网络隐藏。客户网络路由的扩展也可能得到改进，因为一些基于第3层PE的VPN方法避免了客户的路由算法需要看到N个客户站点之间的“N平方”（实际上是N*（N-1）/2）点对点双工链路。
However, these advantages come along with other consequences. Specifically, the PE devices must have some knowledge of the routing, addressing, and layer 3 protocols of the customer networks to which they attach. One consequence is that the set of layer 3 protocols which can be supported by the VPN is limited to those supported by the PE (which in practice means, limited to IP). Another consequence is that the PE devices have more to do, and the SP has more per-customer management to do.
然而，这些优势伴随着其他后果。具体而言，PE设备必须对其所连接的客户网络的路由、寻址和第3层协议有一定的了解。一个结果是，VPN支持的第3层协议集仅限于PE支持的协议（实际上，这意味着仅限于IP）。另一个结果是PE设备有更多的工作要做，而SP有更多的客户管理要做。
An SP may offer a range of layer 3 PE-based VPN services. At one end of the range is a service limited to simply providing connectivity (optionally including QoS support) between specific customer network sites. This is referred to as "Network Connectivity Service". There is a spectrum of other possible services, such as firewalls, user or site of origin authentication, and address assignment (e.g., using Radius or DHCP).
SP可以提供一系列基于第3层PE的VPN服务。范围的一端是一项服务，仅限于提供特定客户网络站点之间的连接（可选包括QoS支持）。这称为“网络连接服务”。还有一系列其他可能的服务，例如防火墙、用户或源站点身份验证和地址分配（例如，使用Radius或DHCP）。
This framework document will discuss methods for providing layer 3 PE-based VPNs and layer 3 provider-provisioned CE-based VPNs. This may include mechanisms which will can be used to constrain
本框架文件将讨论提供第3层基于PE的VPN和第3层提供商提供的基于CE的VPN的方法。这可能包括可用于约束的机制
connectivity between sites, including the use and placement of firewalls, based on administrative requirements [PPVPN-REQ] [L3VPN-REQ]. Similarly the use and placement of NAT functionality is discussed. However, this framework document will not discuss methods for additional services such as firewall administration and address assignment. A discussion of specific firewall mechanisms and policies, and detailed discussion of NAT functionality, are outside of the scope of this document.
基于管理要求的站点之间的连接，包括防火墙的使用和放置[PPVPN-REQ][L3VPN-REQ]。同样，还讨论了NAT功能的使用和放置。但是，本框架文档不会讨论其他服务的方法，如防火墙管理和地址分配。对特定防火墙机制和策略的讨论以及对NAT功能的详细讨论超出了本文档的范围。
This document does not discuss those forms of VPNs that are outside of the scope of the IETF Provider-Provisioned VPN working group. Specifically, this document excludes discussion of PPVPNs using VPN native (non-IP, non-MPLS) protocols as the base technology used to provide the VPN service (e.g., native ATM service provided using ATM switches with ATM signaling). However, this does not mean to exclude multiprotocol access to the PPVPN by customers.
本文档不讨论IETF提供商提供的VPN工作组范围之外的VPN形式。具体而言，本文件不讨论使用VPN本机（非IP、非MPLS）协议作为用于提供VPN服务的基本技术的PPVPN（例如，使用ATM交换机和ATM信令提供的本机ATM服务）。但是，这并不意味着排除客户对PPVPN的多协议访问。
Backdoor Links: Links between CE devices that are provided by the end customer rather than the SP; may be used to interconnect CE devices in multiple-homing arrangements.
后门链接：终端客户而非SP提供的CE设备之间的链接；可用于在多个归巢布置中互连CE设备。
CE-based VPN: An approach in which all the VPN-specific procedures are performed in the CE devices, and the PE devices are not aware in any way that some of the traffic they are processing is VPN traffic.
基于CE的VPN：一种在CE设备中执行所有特定于VPN的过程的方法，并且PE设备以任何方式都不知道它们正在处理的某些流量是VPN流量。
Customer: A single organization, corporation, or enterprise that administratively controls a set of sites belonging to a VPN.
客户：管理控制属于VPN的一组站点的单个组织、公司或企业。
Customer Edge (CE) Device: The equipment on the customer side of the SP-customer boundary (the customer interface).
客户边缘（CE）设备：SP客户边界（客户接口）客户侧的设备。
IP Router: A device which forwards IP packets, and runs associated IP routing protocols (such as OSPF, IS-IS, RIP, BGP, or similar protocols). An IP router might optionally also be an LSR. The term "IP router" is often abbreviated as "router".
IP路由器：转发IP数据包并运行相关IP路由协议（如OSPF、IS-IS、RIP、BGP或类似协议）的设备。IP路由器也可以是LSR。术语“IP路由器”通常缩写为“路由器”。
Label Switching Router: A device which forwards MPLS packets and runs associated IP routing and signaling protocols (such as LDP, RSVP-TE, CR-LDP, OSPF, IS-IS, or similar protocols). A label switching router is also an IP router.
标签交换路由器：转发MPLS数据包并运行相关IP路由和信令协议（如LDP、RSVP-TE、CR-LDP、OSPF、IS-IS或类似协议）的设备。标签交换路由器也是IP路由器。
PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet, and optionally on based on other information in the IP header of the packet. The PE devices are
基于PE的VPN：PE设备知道某些流量是VPN流量。它们基于数据包的目的地IP地址转发通信量（通过隧道），并且可选地基于数据包的IP报头中的其他信息转发通信量。PE设备是
themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
它们自己是隧道端点。隧道可利用各种封装在SP网络上发送通信量（例如但不限于GRE、IP中的IP、IPsec或MPLS隧道）。
Private Network: A network which allows communication between a restricted set of sites, over an IP backbone that is used only to carry traffic to and from those sites.
专用网络：一种允许在一组受限制的站点之间通过IP主干网进行通信的网络，该主干网仅用于承载进出这些站点的流量。
Provider Edge (PE) Device: The equipment on the SP side of the SP-customer boundary (the customer interface).
提供商边缘（PE）设备：SP客户边界（客户接口）SP侧的设备。
Provider-Provisioned VPNs (PPVPNs): VPNs, whether CE-based or PE-based, that are actively managed by the SP rather than by the end customer.
提供商提供的VPN（PPVPN）：由SP而非最终客户主动管理的VPN，无论是基于CE还是基于PE。
Route Reflectors: An SP-owned network element that is used to distribute BGP routes to the SP's BGP-enabled routers.
路由反射器：SP拥有的网元，用于将BGP路由分发到SP的启用BGP的路由器。
Virtual Private Network (VPN): Restricted communication between a set of sites, making use of an IP backbone which is shared by traffic that is not going to or coming from those sites.
虚拟专用网（VPN）：一组站点之间的受限通信，利用IP主干网，该主干网由不进出这些站点的流量共享。
Virtual Router (VR): An instance of one of a number of logical routers located within a single physical router. Each logical router emulates a physical router using existing mechanisms and tools for configuration, operation, accounting, and maintenance.
虚拟路由器（VR）：位于单个物理路由器内的多个逻辑路由器之一的实例。每个逻辑路由器使用现有的配置、操作、记帐和维护机制和工具模拟物理路由器。
VPN Forwarding Instance (VFI): A logical entity that resides in a PE that includes the router information base and forwarding information base for a VPN.
VPN转发实例（VFI）：驻留在PE中的逻辑实体，包括VPN的路由器信息库和转发信息库。
VPN Backbone: IP and/or MPLS network which is used to carry VPN traffic between the customer sites of a particular VPN.
VPN主干网：IP和/或MPLS网络，用于在特定VPN的客户站点之间传输VPN流量。
VPN Edge Device: Device, attached to both the VPN backbone and the customer network, which performs VPN-specific functions. For PE-based VPNs, this is the PE device; for CE-based VPNs, this is the CE device.
VPN边缘设备：连接到VPN主干网和客户网络的设备，执行VPN特定功能。对于基于PE的VPN，这是PE设备；对于基于CE的VPN，这是CE设备。
VPN Routing: Routing that is specific to a particular VPN.
VPN路由：特定于特定VPN的路由。
VPN Tunnel: A logical link between two PE or two CE entities, used to carry VPN traffic, and implemented by encapsulating packets that are transmitted between those two entities.
VPN隧道：两个PE或两个CE实体之间的逻辑链路，用于承载VPN流量，并通过封装在这两个实体之间传输的数据包来实现。
ATM Asynchronous Transfer Mode BGP Border Gateway Protocol CE Customer Edge CLI Command Line Interface CR-LDP Constraint-based Routing Label Distribution Protocol EBGP External Border Gateway Protocol FR Frame Relay GRE Generic Routing Encapsulation IBGP Internal Border Gateway Protocol IKE Internet Key Exchange IGP Interior Gateway Protocol (e.g., RIP, IS-IS and OSPF are all IGPs) IP Internet Protocol (same as IPv4) IPsec Internet Protocol Security protocol IPv4 Internet Protocol version 4 (same as IP) IPv6 Internet Protocol version 6 IS-IS Intermediate System to Intermediate System routing protocol L2TP Layer 2 Tunneling Protocol LAN Local Area Network LDAP Lightweight Directory Access Protocol LDP Label Distribution Protocol LSP Label Switched Path LSR Label Switching Router MIB Management Information Base MPLS Multi Protocol Label Switching NBMA Non-Broadcast Multi-Access NMS Network Management System OSPF Open Shortest Path First routing protocol P Provider equipment PE Provider Edge PPVPN Provider-Provisioned VPN QoS Quality of Service RFC Request For Comments RIP Routing Information Protocol RSVP Resource Reservation Protocol RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SNMP Simple Network Management Protocol SP Service Provider VFI VPN Forwarding Instance VPN Virtual Private Network VR Virtual Router
ATM异步传输模式BGP边界网关协议CE客户边缘CLI命令行接口基于CR-LDP约束的路由标签分发协议EBGP外部边界网关协议FR帧中继GRE通用路由封装IBGP内部边界网关协议IKE Internet密钥交换IGP内部网关协议（例如，RIP、IS-IS和OSPF都是IGP）IP互联网协议（与IPv4相同）IPsec互联网协议安全协议IPv4互联网协议版本4（与IP相同）IPv6 Internet协议版本6 IS-IS中间系统到中间系统路由协议L2TP第2层隧道协议LAN局域网LDAP轻型目录访问协议LDP标签分发协议LSP标签交换路径LSR标签交换路由器MIB管理信息库MPLS多协议标签交换NBMA非广播多址NMS网络管理系统OSPF开放最短路径优先路由协议P提供商设备PE提供商边缘PPVPN提供商提供的VPN QoS服务质量RFC征求意见RIP路由信息协议RSVP资源预留协议RSVP-TE资源预留协议带流量工程师neering Extensions SNMP简单网络管理协议SP服务提供商VFI VPN转发实例VPN虚拟专用网VR虚拟路由器
This section describes PPVPN reference models. The purpose of discussing reference models is to clarify the common components and pieces that are needed to build and deploy a PPVPN. Two types of VPNs, layer 3 PE-based VPN and layer 3 provider-provisioned CE-based VPN are covered in separated sections below.
本节介绍PPVPN参考模型。讨论参考模型的目的是阐明构建和部署PPVPN所需的通用组件和部件。两种类型的VPN，第3层基于PE的VPN和第3层提供商提供的基于CE的VPN将在下面的单独部分中介绍。
This subsection describes functional components and their relationship for implementing layer 3 PE-based VPN.
本小节描述用于实现基于第3层PE的VPN的功能组件及其关系。
Figure 2.1 shows the reference model for layer 3 PE-based VPNs and Figures 2.2 and 2.3 show relationship between entities in the reference model.
图2.1显示了基于第3层PE的VPN的参考模型，图2.2和2.3显示了参考模型中实体之间的关系。
As shown in Figure 2.1, the customer interface is defined as the interface which exists between CE and PE devices, and the network interface is defined as the interface which exists between a pair of PE devices.
如图2.1所示，客户接口定义为CE和PE设备之间的接口，网络接口定义为一对PE设备之间的接口。
Figure 2.2 illustrates a single logical tunnel between each pair of VFIs supporting the same VPN. Other options are possible. For example, a single tunnel might occur between two PEs, with multiple per-VFI tunnels multiplexed over the PE to PE tunnel. Similarly, there may be multiple tunnels between two VFIs, for example to optimize forwarding within the VFI. Other possibilities will be discussed later in this framework document.
图2.2显示了支持同一VPN的每对VFI之间的单个逻辑隧道。其他选择也是可能的。例如，两个PE之间可能出现一个隧道，通过PE到PE隧道多路复用多个每VFI隧道。类似地，两个VFI之间可能存在多个隧道，例如用于优化VFI内的转发。本框架文件稍后将讨论其他可能性。
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel : |router| |device| : | of |
| of |-:--| |================:===============| |--:-|VPN A|
|VPN A| : | | : +------+ +------+ : +------+
+------+ : | PE | : | | : |
+------+ : |device| Network interface | | : |
| CE | : | | : +------+ : +------+
|device|-:--| |================:===============| |--:-| CE |
| of | : +------+ : VPN tunnel | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | single or multiple SP domains | | network |
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel : |router| |device| : | of |
| of |-:--| |================:===============| |--:-|VPN A|
|VPN A| : | | : +------+ +------+ : +------+
+------+ : | PE | : | | : |
+------+ : |device| Network interface | | : |
| CE | : | | : +------+ : +------+
|device|-:--| |================:===============| |--:-| CE |
| of | : +------+ : VPN tunnel | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | single or multiple SP domains | | network |
Figure 2.1: Reference model for layer 3 PE-based VPN.
图2.1：基于第3层PE的VPN参考模型。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
| CE | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | of |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+ | +------+ | | +------+ | +-----+
| | | |
+-----+ Access | +------+ | | +------+ | Access +-----+
| CE | conn. | |VFI of| | VPN tunnel | |VFI of| | conn. | CE |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.2: Relationship between entities in reference model (1).
图2.2：参考模型（1）中实体之间的关系。
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==================< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
+----------+ +----------+
+-----+ |PE device | |PE device | +-----+
| CE | | | | | | CE |
| dev | Access | +------+ | | +------+ | Access | dev |
| of | conn. | |VFI of| | | |VFI of| | conn. | of |
|VPN A|----------|VPN A | | | |VPN A |----------|VPN A|
+-----+ | +------+\| Tunnel |/+------+ | +-----+
| >==================< |
+-----+ Access | +------+/| |\+------+ | Access +-----+
| CE | conn. | |VFI of| | | |VFI of| | conn. | CE |
| dev |----------|VPN B | | | |VPN B |----------| dev |
| of | | +------+ | | +------+ | | of |
|VPN B| | | | | |VPN B|
+-----+ +----------+ +----------+ +-----+
Figure 2.3: Relationship between entities in reference model (2).
图2.3：参考模型（2）中实体之间的关系。
The entities in the reference model are described below.
参考模型中的实体描述如下。
o Customer edge (CE) device
o 客户边缘（CE）设备
In the context of layer 3 provider-provisioned PE-based VPNs, a CE device may be a router, LSR, or host that has no VPN-specific functionality. It is attached via an access connection to a PE device.
在第3层提供商提供的基于PE的VPN的上下文中，CE设备可以是没有VPN特定功能的路由器、LSR或主机。它通过接入连接连接到PE设备。
o P router
o P路由器
A router within a provider network which is used to interconnect PE devices, but which does not have any VPN state and does not have any direct attachment to CE devices.
提供商网络中的一种路由器，用于互连PE设备，但不具有任何VPN状态，也不直接连接到CE设备。
o Provider edge (PE) device
o 提供商边缘（PE）设备
In the context of layer 3 provider-provisioned PE-based VPNs, a PE device implements one or more VFIs and maintains per-VPN state for the support of one or more VPNs. It may be a router, LSR, or other device that includes VFIs and provider edge VPN functionality such as provisioning, management, and traffic classification and separation. (Note that access connections are terminated by VFIs from the functional point of view). A PE device is attached via an access connection to one or more CE devices.
在第3层提供商提供的基于PE的VPN的上下文中，PE设备实现一个或多个VFI并维护每个VPN状态以支持一个或多个VPN。它可以是路由器、LSR或其他设备，包括VFI和提供商边缘VPN功能，如供应、管理和流量分类和分离。（请注意，从功能角度来看，访问连接由VFIs终止）。PE设备通过接入连接连接到一个或多个CE设备。
o Customer site
o 客户站点
A customer site is a set of users that have mutual IP reachability without use of a VPN backbone that goes beyond the site.
客户站点是一组具有相互IP可达性的用户，无需使用超出站点范围的VPN主干网。
o SP networks
o SP网络
An SP network is an IP or MPLS network administered by a single service provider.
SP网络是由单个服务提供商管理的IP或MPLS网络。
o Access connection
o 接入连接
An access connection represents an isolated layer 2 connectivity between a CE device and a PE device. Access connections can be, e.g., dedicated physical circuits, logical circuits (such as FR, ATM, and MAC), or IP tunnels (e.g., using IPsec, L2TP, or MPLS).
接入连接表示CE设备和PE设备之间的隔离第2层连接。接入连接可以是专用物理电路、逻辑电路（如FR、ATM和MAC）或IP隧道（如使用IPsec、L2TP或MPLS）。
o Access network
o 接入网
An access network provides access connections between CE and PE devices. It may be a TDM network, layer 2 network (e.g., FR, ATM, and Ethernet), or IP network over which access is tunneled (e.g., using L2TP [RFC2661] or MPLS).
接入网络提供CE和PE设备之间的接入连接。它可以是TDM网络、第2层网络（例如，FR、ATM和以太网）或通过隧道进行访问的IP网络（例如，使用L2TP[RFC2661]或MPLS）。
o VPN tunnel
o VPN隧道
A VPN tunnel is a logical link between two VPN edge devices. A VPN packet is carried on a tunnel by encapsulating it before transmitting it over the VPN backbone.
VPN隧道是两个VPN边缘设备之间的逻辑链路。VPN数据包在通过VPN主干传输之前通过封装在隧道中进行传输。
Multiple VPN tunnels at one level may be hierarchically multiplexed into a single tunnel at another level. For example, multiple per-VPN tunnels may be multiplexed into a single PE to PE tunnel (e.g., GRE, IP-in-IP, IPsec, or MPLS tunnel). This is illustrated in Figure 2.3. See section 4.3 for details.
一个级别的多个VPN隧道可以分层复用到另一个级别的单个隧道中。例如，多个每VPN隧道可以被多路复用到单个PE-to-PE隧道（例如，GRE、IP-in-IP、IPsec或MPLS隧道）中。如图2.3所示。详见第4.3节。
o VPN forwarding instance (VFI)
o VPN转发实例（VFI）
A single PE device is likely to be connected to a number of CE devices. The CE devices are unlikely to all be in the same VPN. The PE device must therefore maintain a separate forwarding instances for each VPN to which it is connected. A VFI is a logical entity, residing in a PE, that contains the router information base and forwarding information base for a VPN. The interaction between routing and VFIs is discussed in section 4.4.2.
单个PE设备可能连接到多个CE设备。CE设备不可能全部位于同一VPN中。因此，PE设备必须为其连接的每个VPN维护单独的转发实例。VFI是驻留在PE中的逻辑实体，包含VPN的路由器信息库和转发信息库。第4.4.2节讨论了布线和VFIs之间的相互作用。
o Customer management function
o 客户管理职能
The customer management function supports the provisioning of customer specific attributes, such as customer ID, personal information (e.g., name, address, phone number, credit card number, and etc.), subscription services and parameters, access control policy information, billing and statistical information, and etc.
客户管理功能支持提供特定于客户的属性，如客户ID、个人信息（如姓名、地址、电话号码、信用卡号码等）、订阅服务和参数、访问控制策略信息、账单和统计信息等。
The customer management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
客户管理功能可以使用SNMP管理器、目录服务（例如LDAP[RFC3377]）或专有网络管理系统的组合。
o Network management function
o 网络管理功能
The network management function supports the provisioning and monitoring of PE or CE device attributes and their relationships.
网络管理功能支持PE或CE设备属性及其关系的设置和监控。
The network management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
网络管理功能可以使用SNMP管理器、目录服务（例如LDAP[RFC3377]）或专有网络管理系统的组合。
For robustness, a CE device may be connected to more than one PE device, resulting in a multi-homing arrangement. Four distinct types of multi-homing arrangements, shown in Figure 2.4, may be supported.
为了健壮性，CE设备可以连接到多个PE设备，从而形成多归宿布置。可支持图2.4所示的四种不同类型的多归宿安排。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
This type includes a CE device connected
to a PE device via two access connections.
(a) (b)
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
This type includes a CE device connected
to a PE device via two access connections.
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
(c) （d）
Figure 2.4: Four types of double-homing arrangements.
图2.4：四种类型的双归航安排。
It is quite natural to assume that multiple different layer 3 VPN approaches may be implemented, particularly if the VPN backbone includes more than one SP network. For example, (1) each SP chooses one or more layer 3 PE-based VPN approaches out of multiple vendor's implementations, implying that different SPs may choose different
假设可以实现多个不同的第3层VPN方法是很自然的，特别是当VPN主干包括多个SP网络时。例如，（1）每个SP从多个供应商的实施中选择一个或多个基于第3层PE的VPN方法，这意味着不同的SP可能会选择不同的方法
approaches; and (2) an SP may deploy multiple networks of layer 3 PE-based VPNs (e.g., an old network and a new network). Thus it is important to allow interworking of layer 3 PE-based VPNs making use of multiple different layer 3 VPN approaches.
方法；和（2）SP可以部署基于第3层PE的VPN的多个网络（例如，旧网络和新网络）。因此，使用多种不同的第3层VPN方法，允许基于第3层PE的VPN互通非常重要。
There are three scenarios that enable layer 3 PE-based VPN interworking among different approaches.
有三种方案支持不同方法之间基于第3层PE的VPN互通。
o Interworking function
o 互通功能
This scenario enables interworking using a PE that is located at one or more points which are logically located between VPNs based on different layer 3 VPN approaches. For example, this PE may be located on the boundary between SP networks which make use of different layer 3 VPN approaches [VPN-DISC]. A PE at one of these points is called an interworking function (IWF), and an example configuration is shown in Figure 2.5.
此场景支持使用位于一个或多个点的PE进行互通，这些点基于不同的第3层VPN方法在逻辑上位于VPN之间。例如，此PE可能位于SP网络之间的边界上，SP网络使用不同的第3层VPN方法[VPN-DISC]。其中一个点上的PE称为互通功能（IWF），图2.5显示了一个示例配置。
+------------------+ +------------------+
| | | |
+------+ VPN tunnel +------+ VPN tunnel +------+
| |==============| |==============| |
| | | | | |
| PE | | PE | | PE |
| | |device| | |
|device| |(IWF) | |device|
| | VPN tunnel | | VPN tunnel | |
| |==============| |==============| |
+------+ +------+ +------+
| | | |
+------------------+ +------------------+
|<-VPN approach 1->| |<-VPN approach 2->|
+------------------+ +------------------+
| | | |
+------+ VPN tunnel +------+ VPN tunnel +------+
| |==============| |==============| |
| | | | | |
| PE | | PE | | PE |
| | |device| | |
|device| |(IWF) | |device|
| | VPN tunnel | | VPN tunnel | |
| |==============| |==============| |
+------+ +------+ +------+
| | | |
+------------------+ +------------------+
|<-VPN approach 1->| |<-VPN approach 2->|
Figure 2.5: Interworking function.
图2.5：互通功能。
o Interworking interface
o 互通接口
This scenario enables interworking using tunnels between PEs supporting by different layer 3 VPN approaches. As shown in Figure 2.6, interworking interface is defined as the interface which exists between a pair of PEs and connects two SP networks implemented with different approaches. This interface is similar to the customer interface located between PE and CE, but the interface is supported by tunnels to identify VPNs, while the customer interface is supported by access connections.
此场景支持通过不同的第3层VPN方法支持的PE之间使用隧道进行互通。如图2.6所示，互通接口定义为存在于一对PEs之间并连接两个采用不同方法实现的SP网络的接口。此接口类似于位于PE和CE之间的客户接口，但该接口由隧道支持以识别VPN，而客户接口由访问连接支持。
+------------------+ +------------------+
| | : | |
+------+ VPN tunnel +------+Tunnel: +------+ VPN tunnel +------+
| |============| |======:======| |============| |
| | | | : | | | |
| PE | | PE | : | PE | | PE |
| | | | : | | | |
|device| |device| : |device| |device|
| | VPN tunnel | |Tunnel: | | VPN tunnel | |
| |============| |======:======| |============| |
+------+ +------+ : +------+ +------+
| | : | |
+------------------+ Interworking +------------------+
|<-VPN approach 1->| interface |<-VPN approach 2->|
+------------------+ +------------------+
| | : | |
+------+ VPN tunnel +------+Tunnel: +------+ VPN tunnel +------+
| |============| |======:======| |============| |
| | | | : | | | |
| PE | | PE | : | PE | | PE |
| | | | : | | | |
|device| |device| : |device| |device|
| | VPN tunnel | |Tunnel: | | VPN tunnel | |
| |============| |======:======| |============| |
+------+ +------+ : +------+ +------+
| | : | |
+------------------+ Interworking +------------------+
|<-VPN approach 1->| interface |<-VPN approach 2->|
Figure 2.6: Interworking interface.
图2.6：互通接口。
o Customer-based interworking
o 基于客户的互通
If some customer site has a CE attached to one kind of VPN, and a CE attached to another kind, communication between the two kinds of VPN occurs automatically.
如果某个客户站点将CE连接到一种VPN，而将CE连接到另一种VPN，则两种VPN之间会自动进行通信。
This subsection describes functional components and their relationship for implementing layer 3 provider-provisioned CE-based VPN.
本小节描述用于实现第3层提供商提供的基于CE的VPN的功能组件及其关系。
Figure 2.7 shows the reference model for layer 3 provider-provisioned CE-based VPN. As shown in Figure 2.7, the customer interface is defined as the interface which exists between CE and PE devices.
图2.7显示了第3层提供商提供的基于CE的VPN的参考模型。如图2.7所示，客户接口定义为CE和PE设备之间的接口。
In this model, a CE device maintains one or more VPN tunnel endpoints, and a PE device has no VPN-specific functionality. As a result, the interworking issues of section 2.1.3 do not arise.
在此模型中，CE设备维护一个或多个VPN隧道端点，而PE设备没有特定于VPN的功能。因此，不会出现第2.1.3节中的互通问题。
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |device| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | VPN tunnel +------+ : +------+
|device|=:====================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | | | network |
+---------+ +------------------------------------+ +---------+
| | | | | |
| | | +------+ +------+ : +------+
+------+ : | | | | | | : | CE |
| CE | : | | | P | | PE | : |device|
|device| : +------+ VPN tunnel |router| |device| : | of |
| of |=:====================================================:=|VPN A|
|VPN A| : | | +------+ +------+ : +------+
+------+ : | PE | | | : |
+------+ : |device| | | : |
| CE | : | | VPN tunnel +------+ : +------+
|device|=:====================================================:=| CE |
| of | : +------+ | PE | : |device|
|VPN B| : | | |device| : | of |
+------+ : | | +------------+ +------------+ | | : |VPN B|
| : | | | Customer | | Network | +------+ : +------+
|Customer | | | management | | management | | | : |
|interface| | | function | | function | | |Customer |
| | | +------------+ +------------+ | |interface|
| | | | | |
+---------+ +------------------------------------+ +---------+
| Access | |<---------- SP network(s) --------->| | Access |
| network | | | | network |
Figure 2.7: Reference model for layer 3 provider-provisioned CE-based VPN.
图2.7：第3层提供商提供的基于CE的VPN的参考模型。
The entities in the reference model are described below.
参考模型中的实体描述如下。
o Customer edge (CE) device
o 客户边缘（CE）设备
In the context of layer 3 provider-provisioned CE-based VPNs, a CE device provides layer 3 connectivity to the customer site. It may be a router, LSR, or host that maintains one or more VPN tunnel endpoints. A CE device is attached via an access connection to a PE device and usually located at the edge of a customer site or co-located on an SP premises.
在第3层提供商提供的基于CE的VPN环境中，CE设备提供到客户站点的第3层连接。它可以是维护一个或多个VPN隧道端点的路由器、LSR或主机。CE设备通过接入连接连接到PE设备，通常位于客户站点的边缘或位于SP场所的同一位置。
o P router (see section 2.1.1)
o P路由器（见第2.1.1节）
o Provider edge (PE) device
o 提供商边缘（PE）设备
In the context of layer 3 provider-provisioned CE-based VPNs, a PE device may be a router, LSR, or other device that has no VPN-specific functionality. It is attached via an access connection to one or more CE devices.
在第3层提供商提供的基于CE的VPN的上下文中，PE设备可以是路由器、LSR或没有VPN特定功能的其他设备。它通过接入连接连接到一个或多个CE设备。
o Customer Site (see section 2.1.1)
o 客户现场（见第2.1.1节）
o SP networks
o SP网络
An SP network is a network administrated by a single service provider. It is an IP or MPLS network. In the context of layer 3 provider-provisioned CE-based VPNs, the SP network consists of the SP's network and the SP's management functions that manage both its own network and the customer's VPN functions on the CE device.
SP网络是由单个服务提供商管理的网络。它是一个IP或MPLS网络。在第3层提供商提供的基于CE的VPN环境中，SP网络由SP的网络和SP的管理功能组成，SP的管理功能管理其自身的网络和客户在CE设备上的VPN功能。
o Access connection (see section 2.1.1)
o 接入连接（见第2.1.1节）
o Access network (see section 2.1.1)
o 接入网络（见第2.1.1节）
o VPN tunnel
o VPN隧道
A VPN tunnel is a logical link between two entities which is created by encapsulating packets within an encapsulating header for purpose of transmission between those two entities for support of VPNs. In the context of layer 3 provider-provisioned CE-based VPNs, a VPN tunnel is an IP tunnel (e.g., using GRE, IP-in-IP, IPsec, or L2TP) or an MPLS tunnel between two CE devices over the SP's network.
VPN隧道是两个实体之间的逻辑链路，它是通过将数据包封装在封装头中创建的，用于在这两个实体之间传输以支持VPN。在第3层提供商提供的基于CE的VPN的上下文中，VPN隧道是IP隧道（例如，使用GRE、IP中的IP、IPsec或L2TP）或SP网络上两个CE设备之间的MPLS隧道。
o Customer management function (see section 2.1.1)
o 客户管理职能（见第2.1.1节）
o Network management function
o 网络管理功能
The network management function supports the provisioning and monitoring of PE or CE device attributes and their relationships, covering PE and CE devices that define the VPN connectivity of the customer VPNs.
网络管理功能支持PE或CE设备属性及其关系的配置和监控，涵盖定义客户VPN VPN连接的PE和CE设备。
The network management function may use a combination of SNMP manager, directory service (e.g., LDAP [RFC3377]), or proprietary network management system.
网络管理功能可以使用SNMP管理器、目录服务（例如LDAP[RFC3377]）或专有网络管理系统的组合。
It is necessary for each PE device to know which CEs it is attached to, and what VPNs each CE is associated with.
每个PE设备都需要知道它连接到哪些CE，以及每个CE与哪些VPN关联。
VPN membership refers to the association of VPNs, CEs, and PEs. A given CE belongs to one or more VPNs. Each PE is therefore
VPN成员资格是指VPN、CE和PE之间的关联。给定的CE属于一个或多个VPN。因此，每个PE都是
associated with a set of VPNs, and a given VPN has a set of associated PEs which are supporting that VPN. If a PE has at least one attached CE belonging to a given VPN, then state information for that VPN (e.g., the VPN routes) must exist on that PE. The set of VPNs that exist on a PE may change over time as customer sites are added to or removed from the VPNs.
与一组VPN关联，并且给定VPN具有一组支持该VPN的关联PE。如果PE至少有一个属于给定VPN的附加CE，则该VPN的状态信息（例如VPN路由）必须存在于该PE上。随着客户站点添加到VPN或从VPN中删除，PE上存在的VPN集可能会随着时间的推移而变化。
In some layer 3 PE-based PPVPN schemes, VPN membership information (i.e., information about which PEs are attached to which VPNs) is explicitly distributed. In others, the membership information is inferred from other information that is distributed. Different schemes use the membership information in different ways, e.g., some to determine what set of tunnels to set up, some to constrain the distribution of VPN routing information.
在某些基于第3层PE的PPVPN方案中，VPN成员信息（即关于哪个PE连接到哪个VPN的信息）是显式分发的。在其他情况下，成员资格信息是从分布的其他信息推断出来的。不同的方案以不同的方式使用成员信息，例如，一些用于确定要设置的隧道集，一些用于约束VPN路由信息的分布。
A VPN site may be added or deleted as a result of a provisioning operation carried out by the network administrator, or may be dynamically added or deleted as a result of a subscriber initiated operation; thus VPN membership information may be either static or dynamic, as discussed below.
VPN站点可以作为网络管理员执行的供应操作的结果而添加或删除，或者可以作为订户发起的操作的结果而动态添加或删除；因此，VPN成员信息可以是静态的，也可以是动态的，如下所述。
Static binding occurs when a provisioning action binds a particular PE-CE access link to a particular VPN. For example, a network administrator may set up a dedicated link layer connection, such as an ATM VCC or a FR DLCI, between a PE device and a CE device. In this case the binding between a PE-CE access connection and a particular VPN to fixed at provisioning time, and remains the same until another provisioning action changes the binding.
当设置操作将特定PE-CE访问链接绑定到特定VPN时，会发生静态绑定。例如，网络管理员可以在PE设备和CE设备之间建立专用链路层连接，例如ATM VCC或FR DLCI。在这种情况下，PE-CE访问连接和特定VPN之间的绑定将在设置时固定，并保持不变，直到另一个设置操作更改绑定。
Dynamic binding occurs when some real-time protocol interaction causes a particular PE-CE access link to be temporarily bound to a particular VPN. For example, a mobile user may dial up the provider network and carry out user authentication and VPN selection procedures. Then the PE to which the user is attached is not one permanently associated with the user, but rather one that is typically geographically close to where the mobile user happens to be. Another example of dynamic binding is that of a permanent access connection between a PE and a CE at a public facility such as a hotel or conference center, where the link may be accessed by multiple users in turn, each of which may wish to connect to a different VPN.
当某些实时协议交互导致特定PE-CE访问链路临时绑定到特定VPN时，会发生动态绑定。例如，移动用户可以拨打提供商网络并执行用户认证和VPN选择过程。然后，用户所连接到的PE不是与用户永久关联的PE，而是通常在地理位置上靠近移动用户恰好所在的PE。动态绑定的另一个示例是诸如酒店或会议中心等公共设施中的PE和CE之间的永久接入连接，其中该链路可由多个用户依次接入，其中每个用户可能希望连接到不同的VPN。
To support dynamically connected users, PPP and RADIUS are commonly used, as these protocols provide for user identification, authentication and VPN selection. Other mechanisms are also
为了支持动态连接的用户，通常使用PPP和RADIUS，因为这些协议提供了用户标识、身份验证和VPN选择。其他机制也在发挥作用
possible. For example a user's HTTP traffic may be initially intercepted by a PE and diverted to a provider hosted web server. After a dialogue that includes user authentication and VPN selection, the user can then be connected to the required VPN. This is sometimes referred to as a "captive portal".
可能的例如，用户的HTTP流量最初可能被PE截获并转移到提供商托管的web服务器。在包括用户身份验证和VPN选择的对话之后，用户可以连接到所需的VPN。这有时被称为“捕获门户”。
Independent of the particular mechanisms used for user authentication and VPN selection, an implication of dynamic binding is that a user for a given VPN may appear at any PE at any time. Thus VPN membership may change at any time as a result of user initiated actions, rather than as a result of network provisioning actions. This suggests that there needs to be a way to distribute membership information rapidly and reliably when these user-initiated actions take place.
与用于用户身份验证和VPN选择的特定机制无关，动态绑定的含义是，给定VPN的用户可以在任何时间出现在任何PE。因此，VPN成员身份可能随时因用户发起的操作而改变，而不是因网络配置操作而改变。这表明，当这些用户发起的操作发生时，需要有一种快速可靠地分发成员信息的方法。
In layer 3 provider-provisioned CE-based VPNs, the PE devices have no knowledge of the VPNs. A PE device attached to a particular VPN has no knowledge of the addressing or routing information of that specific VPN.
在第3层提供商提供的基于CE的VPN中，PE设备不知道VPN。连接到特定VPN的PE设备不知道该特定VPN的寻址或路由信息。
CE devices have IP or MPLS connectivity via a connection to a PE device, which just provides ordinary connectivity to the global IP address space or to an address space which is unique in a particular SPs network. The IP connectivity may be via a static binding, or via some kind of dynamic binding.
CE设备通过与PE设备的连接具有IP或MPLS连接，PE设备仅提供与全局IP地址空间或特定SPs网络中唯一的地址空间的普通连接。IP连接可以通过静态绑定，也可以通过某种动态绑定。
The establishment of the VPNs is done at each CE device, making use of the IP or MPLS connectivity to the others. Therefore, it is necessary for a given CE device to know which other CE devices belong to the same VPN. In this context, VPN membership refers to the association of VPNs and CE devices.
VPN的建立在每个CE设备上完成，利用与其他设备的IP或MPLS连接。因此，对于给定的CE设备，有必要知道哪些其他CE设备属于同一VPN。在此上下文中，VPN成员资格指VPN和CE设备的关联。
For layer 3 PE-based VPNs, the exchange is normal IP packets, transmitted in the same form which is available for interconnecting routers in general. For example, IP packets may be exchanged over Ethernet, SONET, T1, T3, dial-up lines, and any other link layer available to the router. It is important to note that those link layers are strictly local to the interface for the purpose of carrying IP packets, and are terminated at each end of the customer interface. The IP packets may contain addresses which, while unique within the VPN, are not unique on the VPN backbone. Optionally, the data exchange may use MPLS to carry the IP packets.
对于基于第3层PE的VPN，交换是正常的IP数据包，传输的形式与互连路由器的形式相同。例如，IP分组可以通过以太网、SONET、T1、T3、拨号线路和路由器可用的任何其他链路层进行交换。需要注意的是，为了承载IP数据包，这些链路层严格地位于接口的本地，并且在客户接口的每一端终止。IP数据包可能包含的地址虽然在VPN中是唯一的，但在VPN主干上不是唯一的。可选地，数据交换可以使用MPLS来承载IP分组。
The data exchanged at the customer interface are always normal IP packets that are routable on the VPN backbone, and whose addresses are unique on the VPN backbone. Optionally, MPLS frames can be used, if the appropriate label-switched paths exist across the VPN backbone. The PE device does not know whether these packets are VPN packets or not. At the current time, MPLS is not commonly offered as a customer-visible service, so that CE-based VPNs most commonly make use of IP services.
在客户接口上交换的数据始终是可在VPN主干上路由的正常IP数据包，并且其地址在VPN主干上是唯一的。或者，如果VPN主干上存在适当的标签交换路径，则可以使用MPLS帧。PE设备不知道这些数据包是否为VPN数据包。目前，MPLS通常不作为客户可见的服务提供，因此基于CE的VPN通常使用IP服务。
Once VPN tunnels are set up between pairs of VPN edge devices, it is necessary to set up mechanisms which ensure that packets from the customer network get sent through the proper tunnels. This routing function must be performed by the VPN edge device.
一旦在成对的VPN边缘设备之间建立了VPN隧道，就有必要建立机制，确保来自客户网络的数据包通过适当的隧道发送。此路由功能必须由VPN边缘设备执行。
There is a PE-CE routing interaction which enables a PE to obtain those addresses, from the customer network, that are reachable via the CE. The PE-CE routing interaction also enables a CE device to obtain those addresses, from the customer network, which are reachable via the PE; these will generally be addresses that are at other sites in the customer network.
PE-CE路由交互使PE能够从客户网络获得可通过CE访问的地址。PE-CE路由交互还使得CE设备能够从客户网络获得可通过PE访问的那些地址；这些地址通常位于客户网络中的其他站点。
The PE-CE routing interaction can make use of static routing, an IGP (such as RIP, OSPF, IS-IS, etc.), or BGP.
PE-CE路由交互可以使用静态路由、IGP（如RIP、OSPF、IS-IS等）或BGP。
If the PE-CE interaction is done via an IGP, the PE will generally maintain at least several independent IGP instances; one for the backbone routing, and one for each VPN. Thus the PE participates in the IGP of the customer VPNs, but the CE does not participate in the backbone's IGP.
如果PE-CE交互通过IGP完成，则PE通常将保持至少几个独立的IGP实例；一个用于主干路由，一个用于每个VPN。因此，PE参与客户VPN的IGP，但CE不参与主干网的IGP。
If the PE-CE interaction is done via BGP, the PE MAY support one instance of BGP for each VPN, as well as an additional instance of BGP for the public Internet routes. Alternatively, the PE might support a single instance of BGP, using, e.g., different BGP Address Families to distinguish the public Internet routes from the VPN routes.
如果PE-CE交互通过BGP完成，则PE可以为每个VPN支持一个BGP实例，以及为公共互联网路由支持一个额外的BGP实例。或者，PE可以支持BGP的单个实例，例如使用不同的BGP地址族来区分公共因特网路由和VPN路由。
Routing information which a PE learns from a CE in a particular VPN must be forwarded to the other PEs that are attached to the same VPN. Those other PEs must then forward the information in turn to the other CEs of that VPN.
PE从特定VPN中的CE学习的路由信息必须转发到连接到同一VPN的其他PE。然后，这些其他PE必须将信息依次转发给该VPN的其他CE。
The PE-PE routing distribution can be done as part of the same routing instance to which the PE-CE interface belongs. Alternatively, it can be done via a different routing instance, possibly using a different routing algorithm. In this case, the PE must redistribute VPN routes from one routing instance to another.
PE-PE路由分发可以作为PE-CE接口所属的同一路由实例的一部分来完成。或者，可以通过不同的路由实例来完成，可能使用不同的路由算法。在这种情况下，PE必须将VPN路由从一个路由实例重新分配到另一个路由实例。
Note that VPN routing information is never distributed to the P routers. VPN routing information is known at the edge of the VPN backbone, but not in the core.
请注意，VPN路由信息从未分发到P路由器。VPN路由信息在VPN主干的边缘是已知的，但在核心是未知的。
If the VPN's IGP is different than the routing algorithm running on the CE-PE link, then the CE must support two routing instances, and must redistribute the VPN's routes from one instance to the other (e.g., [VPN-BGP-OSPF]).
如果VPN的IGP不同于CE-PE链路上运行的路由算法，则CE必须支持两个路由实例，并且必须将VPN的路由从一个实例重新分配到另一个实例（例如，[VPN-BGP-OSPF]）。
In the case of layer 3 PE-based VPNs a single PE device is likely to provide service for several different VPNs. Since different VPNs may have address spaces which are not mutually unique, a PE device must have several forwarding tables, in general one for each VPN to which it is attached. These will be referred to as VPN Forwarding Instances (VFIs). Each VFI is a logical entity internal to the PE device. VFIs are defined in section 2.1.1, and discussed in more detail in section 4.4.2.
在基于第3层PE的VPN的情况下，单个PE设备可能为多个不同的VPN提供服务。由于不同的VPN可能具有互不唯一的地址空间，因此一个PE设备必须具有多个转发表，通常每个VPN连接一个转发表。这些将被称为VPN转发实例（VFI）。每个VFI都是PE设备内部的逻辑实体。VFI在第2.1.1节中有定义，并在第4.4.2节中有更详细的讨论。
The scaling and management of the customer network (as well as the operation of the VPN) will depend upon the implementation approach and the manner in which routing is done.
客户网络的扩展和管理（以及VPN的运行）将取决于实施方法和路由选择的方式。
In the intranet case all of the sites to be interconnected belong to the same administration (for example, the same company). The options for routing within a single customer network include:
在内部网的情况下，所有要互连的站点都属于同一个管理部门（例如，同一家公司）。单个客户网络中的路由选项包括：
o A single IGP area (using OSPF, IS-IS, or RIP)
o 单个IGP区域（使用OSPF、IS-IS或RIP）
o Multiple areas within a single IGP
o 单个IGP内的多个区域
o A separate IGP within each site, with routes redistributed from each site to backbone routing (i.e., to a backbone as seen by the customer network).
o 每个站点内的独立IGP，路由从每个站点重新分配到主干路由（即，到客户网络看到的主干）。
Note that these options look at routing from the perspective of the overall routing in the customer network. This list does not specify whether PE device is considered to be in a site or not. This issue is discussed below.
请注意，这些选项从客户网络中的总体路由的角度来看路由。此列表未指定PE设备是否被视为位于站点中。下面讨论这个问题。
A single IGP area (such as a single OSPF area, a single IS-IS area, or a single instance of RIP between routers) may be used. One could have, all routers within the customer network (including the PEs, or more precisely, including a VFI within each PE) appear within a single area. Tunnels between the PEs could also appear as normal links.
可以使用单个IGP区域（例如单个OSPF区域、单个IS-IS区域或路由器之间RIP的单个实例）。可以将客户网络中的所有路由器（包括PEs，或者更准确地说，包括每个PE中的VFI）显示在单个区域内。PEs之间的隧道也可以显示为正常链路。
In some cases the multi-level hierarchy of OSPF or IS-IS may be used. One way to apply this to VPNs would be to have each site be a single OSPF or IS-IS area. The VFIs will participate in routing within each site as part of that area. The VFIs may then be interconnected as the backbone (OSPF area 0 or IS-IS level 2). If OSPF is used, the VFIs therefore appear to the customer network as area border routers. If IS-IS is used, the VFIs therefore participate in level 1 routing within the local area, and appear to the customer network as if they are level 2 routers in the backbone.
在某些情况下，可以使用OSPF或IS-IS的多级层次结构。将此应用于VPN的一种方法是使每个站点成为单个OSPF或IS-IS区域。VFI将作为该区域的一部分参与每个站点内的路由。然后，VFI可以作为主干网互连（OSPF区域0或IS-IS级别2）。如果使用OSPF，则VFI在客户网络中显示为区域边界路由器。如果使用IS-IS，VFI因此参与局域网内的1级路由，并在客户网络中显示为主干网中的2级路由器。
Where an IGP is used across the entire network, it is straightforward for VPN tunnels, access connections, and backdoor links to be mixed in a network. Given that OSPF or IS-IS metrics will be assigned to all links, paths via alternate links can be compared and the shortest cost path will be used regardless of whether it is via VPN tunnels, access connections, or backdoor links. If multiple sites of a VPN do not use a common IGP, or if the backbone does not use the same common IGP as the sites, then special procedures may be needed to ensure that routes to/from other sites are treated as intra-area routes, rather than as external routes (depending upon the VPN approach taken).
如果在整个网络中使用IGP，则VPN隧道、访问连接和后门链接可以直接混合在网络中。考虑到OSPF或IS-IS指标将分配给所有链路，可以比较通过备用链路的路径，并将使用最短成本路径，无论是通过VPN隧道、访问连接还是后门链路。如果VPN的多个站点不使用公共IGP，或者主干网不使用与站点相同的公共IGP，则可能需要特殊程序来确保与其他站点之间的路由被视为区域内路由，而不是外部路由（取决于所采用的VPN方法）。
Another option is to operate each site as a separate routing domain. For example each site could operate as a single OSPF area, a single IS-IS area, or a RIP domain. In this case the per-site routing domains will need to redistribute routes into a backbone routing domain (Note: in this context the "backbone routing domain" refers to a backbone as viewed by the customer network). In this case it is optional whether or not the VFIs participate in the routing within each site.
另一种选择是将每个站点作为单独的路由域进行操作。例如，每个站点可以作为单个OSPF区域、单个IS-IS区域或RIP域运行。在这种情况下，每个站点路由域将需要将路由重新分配到主干路由域（注意：在这种情况下，“主干路由域”指的是客户网络查看的主干）。在这种情况下，VFI是否参与每个站点内的路由是可选的。
In the extranet case the sites to be interconnected belong to multiple different administrations. In this case IGPs (such as OSPF, IS-IS, or RIP) are normally not used across the interface between organizations. Either static routes or BGP may be used between sites. If the customer network administration wishes to maintain control of routing between its site and other networks, then either
在外联网的情况下，要互连的站点属于多个不同的管理部门。在这种情况下，IGP（如OSPF、IS-IS或RIP）通常不在组织之间的接口中使用。站点之间可以使用静态路由或BGP。如果客户网络管理部门希望保持对其站点和其他网络之间路由的控制，则
static routing or BGP may be used across the customer interface. If the customer wants to outsource all such control to the provider, then an IGP or static routes may be used at this interface.
静态路由或BGP可跨客户接口使用。如果客户希望将所有此类控制外包给供应商，则可在此接口处使用IGP或静态路由。
The use of BGP between sites allows for policy based routing between sites. This is particularly useful in the extranet case. Note that private IP addresses or non-unique IP address (e.g., unregistered addresses) should not be used for extranet communication.
在站点之间使用BGP允许站点之间基于策略的路由。这在外联网的情况下特别有用。请注意，专用IP地址或非唯一IP地址（例如，未注册的地址）不应用于外联网通信。
When using a single IGP area across an intranet, the entire customer network participates in a single area of an IGP. In this case, for layer 3 PE-based VPNs both CE and PE devices participate as normal routers within the area.
当跨intranet使用单个IGP区域时，整个客户网络参与IGP的单个区域。在这种情况下，对于基于第3层PE的VPN，CE和PE设备都作为区域内的普通路由器参与。
The other options make a distinction between routing within a site, and routing between sites. In this case, a CE device would normally be considered as part of the site where it is located. However, there is an option regarding how the PE devices should be considered.
其他选项区分站点内的路由和站点之间的路由。在这种情况下，CE设备通常被视为其所在站点的一部分。然而，关于如何考虑PE设备，存在一个选项。
In some cases, from the perspective of routing within the customer network, a PE device (or more precisely a VFI within a PE device) may be considered to be internal to the same area or routing domain as the site to which it is attached. This simplifies the management responsibilities of the customer network administration, since inter-area routing would be handled by the provider.
在某些情况下，从客户网络内路由的角度来看，PE设备（或者更准确地说，PE设备内的VFI）可以被认为是与其所连接的站点相同的区域或路由域的内部。这简化了客户网络管理的管理职责，因为区域间路由将由提供商处理。
For example, from the perspective of routing within the customer network, the CE devices may be the area border or AS boundary routers of the IGP area. In this case, static routing, BGP, or whatever routing is used in the backbone, may be used across the customer interface.
例如，从客户网络内路由的角度来看，CE设备可以是区域边界或作为IGP区域的边界路由器。在这种情况下，可以跨客户接口使用静态路由、BGP或主干中使用的任何路由。
3.3.2. Customer View of Routing for Layer 3 Provider-Provisioned CE-based VPNs
3.3.2. 第3层提供商提供的基于CE的VPN路由的客户视图
For layer 3 provider-provisioned CE-based VPNs, the PE devices are not aware of the set of addresses which are reachable at particular customer sites. The CE and PE devices do not exchange the customer's routing information.
对于第3层提供商提供的基于CE的VPN，PE设备不知道可在特定客户站点访问的地址集。CE和PE设备不交换客户的路由信息。
Customer sites that belong to the same VPN may exchange routing information through the CE-CE VPN tunnels that appear, to the customers IGP, as router adjacencies. Alternatively, instead of
属于同一VPN的客户站点可以通过CE-CE VPN隧道交换路由信息，对于客户IGP来说，CE-CE VPN隧道作为路由器邻接出现。或者，代替
exchanging routing information through the VPN tunnels, the SP's management system may take care of the configuration of the static route information of one site towards the other sites in the VPN.
通过VPN隧道交换路由信息，SP的管理系统可以负责VPN中一个站点到其他站点的静态路由信息的配置。
Routing within the customer site may be done in any possible way, using any kind of routing protocols (see section 3.3.3).
客户站点内的路由可采用任何可能的方式，使用任何类型的路由协议（见第3.3.3节）。
As the CE device receives an IP or MPLS service from the SP, the CE and PE devices may exchange routing information that is meaningful within the SP routing realm.
当CE设备从SP接收IP或MPLS服务时，CE和PE设备可以交换在SP路由领域内有意义的路由信息。
Moreover, as the forwarding of tunneled customer packets in the SP network will be based on global IP forwarding, the routes to the various CE devices must be known in the entire SP's network.
此外，由于SP网络中隧道客户数据包的转发将基于全局IP转发，因此到各种CE设备的路由必须在整个SP网络中已知。
This means that a CE device may need to participate in two different routing processes:
这意味着CE设备可能需要参与两个不同的路由过程：
o routing in its own private network (VPN routing), within its own site and with the other VPN sites through the VPN tunnels, possibly using private addresses.
o 在自己的专用网络（VPN路由）中、在自己的站点内以及通过VPN隧道与其他VPN站点进行路由，可能使用专用地址。
o routing in the SP network (global routing), as such peering with its PE.
o SP网络中的路由（全局路由），例如与其PE的对等。
However, in many scenarios, the use of static/default routes at the CE-PE interface might be all the global routing that is required.
然而，在许多情况下，在CE-PE接口上使用静态/默认路由可能是所有需要的全局路由。
The following technologies are available for the exchange of routing information.
以下技术可用于交换路由信息。
o Static routing
o 静态路由
Routing tables may be configured through a management system.
路由表可以通过管理系统进行配置。
o RIP (Routing Information Protocol) [RFC2453]
o RIP（路由信息协议）[RFC2453]
RIP is an interior gateway protocol and is used within an autonomous system. It sends out routing updates at regular intervals and whenever the network topology changes. Routing information is then propagated by the adjacent routers to their neighbors and thus to the entire network. A route from a source to a destination is the path with the least number of routers. This number is called the "hop count" and its maximum value is 15. This implies that RIP is suitable for a small- or medium-sized networks.
RIP是一种内部网关协议，在自治系统中使用。每当网络拓扑发生变化时，它会定期发送路由更新。路由信息随后由相邻路由器传播到其邻居，从而传播到整个网络。从源到目标的路由是路由器数量最少的路径。这个数字称为“跳数”，其最大值为15。这意味着RIP适用于中小型网络。
o OSPF (Open Shortest Path First) [RFC2328]
o OSPF（开放最短路径优先）[RFC2328]
OSPF is an interior gateway protocol and is applied to a single autonomous system. Each router distributes the state of its interfaces and neighboring routers as a link state advertisement, and maintains a database describing the autonomous system's topology. A link state is advertised every 30 minutes or when the topology is reconfigured.
OSPF是一种内部网关协议，适用于单个自治系统。每个路由器将其接口和相邻路由器的状态作为链路状态公告分发，并维护一个描述自治系统拓扑的数据库。链路状态每30分钟公布一次，或者在重新配置拓扑时公布一次。
Each router maintains an identical topological database, from which it constructs a tree of shortest paths with itself as the root. The algorithm is known as the Shortest Path First or SPF. The router generates a routing table from the tree of shortest paths. OSPF supports a variable length subnet mask, which enables effective use of the IP address space.
每个路由器维护一个相同的拓扑数据库，从中它构建一个以自身为根的最短路径树。该算法称为最短路径优先（SPF）。路由器根据最短路径树生成路由表。OSPF支持可变长度的子网掩码，可有效利用IP地址空间。
OSPF allows sets of networks to be grouped together into an area. Each area has its own topological database. The topology of the area is invisible from outside its area. The areas are interconnected via a "backbone" network. The backbone network distributes routing information between the areas. The area routing scheme can reduce the routing traffic and compute the shortest path trees and is indispensable for larger scale networks.
OSPF允许将多组网络分组到一个区域中。每个区域都有自己的拓扑数据库。该区域的拓扑从其区域外部不可见。这些区域通过“主干”网络互连。主干网在区域之间分发路由信息。区域路由方案可以减少路由流量，计算最短路径树，是大规模网络中不可缺少的。
Each multi-access network with multiple routers attached has a designated router. The designated router generates a link state advertisement for the multi-access network and synchronizes the topological database with other adjacent routers in the area. The concept of designated router can thus reduce the routing traffic and compute shortest path trees. To achieve high availability, a backup designated router is used.
每个连接有多个路由器的多址网络都有一个指定的路由器。指定的路由器为多址网络生成链路状态公告，并将拓扑数据库与该区域中的其他相邻路由器同步。因此，指定路由器的概念可以减少路由流量并计算最短路径树。为了实现高可用性，使用了备份指定路由器。
o IS-IS (intermediate system to intermediate system) [RFC1195]
o IS-IS（中间系统至中间系统）[RFC1195]
IS-IS is a routing protocol designed for the OSI (Open Systems Interconnection) protocol suites. Integrated IS-IS is derived from IS-IS in order to support the IP protocol. In the Internet community, IS-IS means integrated IS-IS. In this, a link state is advertised over a connectionless network service. IS-IS has the same basic features as OSPF. They include: link state advertisement and maintenance of a topological database within an area, calculation of a tree of shortest paths, generation of a routing table from a tree of shortest paths, the area routing scheme, a designated router, and a variable length subnet mask.
IS-IS是为OSI（开放系统互连）协议套件设计的路由协议。集成IS-IS源于IS-IS，以支持IP协议。在互联网社区中，IS-IS意味着集成了IS-IS。在这种情况下，链路状态通过无连接网络服务进行广告。IS-IS具有与OSPF相同的基本特性。它们包括：区域内拓扑数据库的链路状态公布和维护、最短路径树的计算、从最短路径树生成路由表、区域路由方案、指定路由器和可变长度子网掩码。
o BGP-4 (Border Gateway Protocol version 4) [RFC1771]
o BGP-4（边界网关协议版本4）[RFC1771]
BGP-4 is an exterior gateway protocol and is applied to the routing of inter-autonomous systems. A BGP speaker establishes a session with other BGP speakers and advertises routing information to them. A session may be an External BGP (EBGP) that connects two BGP speakers within different autonomous systems, or an internal BGP (IBGP) that connects two BGP speakers within a single autonomous system. Routing information is qualified with path attributes, which differentiate routes for the purpose of selecting an appropriate one from possible routes. Also, routes are grouped by the community attribute [RFC1997] [BGP-COM].
BGP-4是一种外部网关协议，用于自治系统间的路由。BGP演讲者与其他BGP演讲者建立会话，并向他们播发路由信息。会话可以是连接不同自治系统内两个BGP扬声器的外部BGP（EBGP），也可以是连接单个自治系统内两个BGP扬声器的内部BGP（IBGP）。路由信息由路径属性限定，路径属性用于区分路由，以便从可能的路由中选择合适的路由。此外，路由按社区属性[RFC1997][BGP-COM]分组。
The IBGP mesh size tends to increase dramatically with the number of BGP speakers in an autonomous system. BGP can reduce the number of IBGP sessions by dividing the autonomous system into smaller autonomous systems and grouping them into a single confederation [RFC3065]. Route reflection is another way to reduce the number of IBGP sessions [RFC1966]. BGP divides the autonomous system into clusters. Each cluster establishes the IBGP full mesh within itself, and designates one or more BGP speakers as "route reflectors," which communicate with other clusters via their route reflectors. Route reflectors in each cluster maintain path and attribute information across the autonomous system. The autonomous system still functions like a fully meshed autonomous system. On the other hand, confederations provide finer control of routing within the autonomous system by allowing for policy changes across confederation boundaries, while route reflection requires the use of identical policies.
在一个自治系统中，随着BGP扬声器的数量增加，IBGP的网格大小会急剧增加。BGP可以通过将自治系统划分为更小的自治系统并将其分组为单个联盟来减少IBGP会话的数量[RFC3065]。路由反射是减少IBGP会话数量的另一种方法[RFC1966]。BGP将自治系统划分为多个集群。每个集群在其内部建立IBGP全网，并将一个或多个BGP扬声器指定为“路由反射器”，通过其路由反射器与其他集群通信。每个集群中的路由反射器维护自治系统中的路径和属性信息。自治系统仍然像一个完全网状的自治系统一样工作。另一方面，联盟通过允许跨联盟边界的策略更改，提供自治系统内路由的更精细控制，而路由反射需要使用相同的策略。
BGP-4 has been extended to support IPv6, IPX, and others as well as IPv4 [RFC2858]. Multiprotocol BGP-4 carries routes from multiple "address families".
BGP-4已经扩展到支持IPv6、IPX和其他协议以及IPv4[RFC2858]。多协议BGP-4承载来自多个“地址族”的路由。
The basic functional components of an implementation of a VPN are:
VPN实现的基本功能组件包括：
o A mechanism to acquire VPN membership/capability information
o 获取VPN成员资格/能力信息的机制
o A mechanism to tunnel traffic between VPN sites
o VPN站点之间的隧道通信机制
o For layer 3 PE-based VPNs, a means to learn customer routes, distribute them between the PEs, and to advertise reachable destinations to customer sites.
o 对于基于第3层PE的VPN，这是一种了解客户路线、在PEs之间分发路线以及向客户站点宣传可到达目的地的方法。
Based on the actual implementation, these functions could be implemented on a per-VPN basis or could be accomplished via a common mechanism shared by all VPNs. For instance, a single process could handle the routing information for all the VPNs or a separate process may be created for each VPN.
根据实际实现，这些功能可以在每个VPN的基础上实现，也可以通过所有VPN共享的公共机制实现。例如，单个进程可以处理所有VPN的路由信息，或者可以为每个VPN创建单独的进程。
Logically, the establishment of a VPN can be thought of as composed of the following three stages. In the first stage, the VPN edge devices learn of each other. In the second stage, they establish tunnels to each other. In the third stage, they exchange routing information with each other. However, not all VPN solutions need be decomposed into these three stages. For example, in some VPN solutions, tunnels are not established after learning membership information; rather, pre-existing tunnels are selected and used. Also, in some VPN solutions, the membership information and the routing information are combined.
从逻辑上讲，VPN的建立可以被认为由以下三个阶段组成。在第一阶段，VPN边缘设备相互学习。在第二阶段，他们建立了相互连接的隧道。在第三阶段，它们相互交换路由信息。然而，并非所有VPN解决方案都需要分解为这三个阶段。例如，在一些VPN解决方案中，在学习成员信息后不建立隧道；而是选择和使用既有隧道。此外，在一些VPN解决方案中，成员信息和路由信息是组合在一起的。
In the membership/capability discovery stage, membership and capability information needs to be acquired to determine whether two particular VPN edge devices support any VPNs in common. This can be accomplished, for instance, by exchanging VPN identifiers of the configured VPNs at each VPN edge device. The capabilities of the VPN edge devices need to be determined, in order to be able to agree on a common mechanism for tunneling and/or routing. For instance, if site A supports both IPsec and MPLS as tunneling mechanisms and site B supports only MPLS, they can both agree to use MPLS for tunneling. In some cases the capability information may be determined implicitly, for example some SPs may implement a single VPN solution. Likewise, the routing information for VPNs can be distributed using the methods discussed in section 4.4.
在成员资格/能力发现阶段，需要获取成员资格和能力信息，以确定两个特定VPN边缘设备是否共同支持任何VPN。例如，这可以通过在每个VPN边缘设备上交换已配置VPN的VPN标识符来实现。需要确定VPN边缘设备的能力，以便能够就隧道和/或路由的通用机制达成一致。例如，如果站点A同时支持IPsec和MPLS作为隧道机制，而站点B仅支持MPLS，则它们都可以同意使用MPLS进行隧道。在某些情况下，可以隐式地确定能力信息，例如，一些SP可以实现单个VPN解决方案。同样，VPN的路由信息可以使用第4.4节中讨论的方法分发。
In the tunnel establishment stage, mechanisms may need to be invoked to actually set up the tunnels. With IPsec, for instance, this could involve the use of IKE to exchange keys and policies for securing the data traffic. However, if IP tunneling, e.g., is used, there may not be any need to explicitly set up tunnels; if MPLS tunnels are used, they may be pre-established as part of normal MPLS functioning.
在隧道建立阶段，可能需要调用机制来实际建立隧道。例如，对于IPsec，这可能涉及使用IKE交换密钥和策略以保护数据流量。然而，如果使用IP隧道，例如，可能不需要明确设置隧道；如果使用MPLS隧道，它们可以作为正常MPLS功能的一部分预先建立。
In the VPN routing stage, routing information for the VPN sites must be exchanged before data transfer between the sites can take place. Based on the VPN model, this could involve the use of static routes, IGPs such as OSPF/ISIS/RIP, or an EGP such as BGP.
在VPN路由阶段，必须先交换VPN站点的路由信息，然后才能在站点之间进行数据传输。基于VPN模型，这可能涉及使用静态路由、IGP（如OSPF/ISIS/RIP）或EGP（如BGP）。
VPN membership and capability information can be distributed from a central management system, using protocols such as, e.g., LDAP. Alternatively, it can be distributed manually. However, as manual configuration does not scale and is error prone, its use is discouraged. As a third alternative, VPN information can be
VPN成员资格和能力信息可以使用诸如LDAP之类的协议从中央管理系统分发。或者，可以手动分发。但是，由于手动配置不可扩展且容易出错，因此不鼓励使用它。作为第三种选择，VPN信息可以
distributed via protocols that ensure automatic and consistent distribution of information in a timely manner, much as routing protocols do for routing information. This may suggest that the information be carried in routing protocols themselves, though only if this can be done without negatively impacting the essential routing functions.
通过协议进行分发，以确保信息的自动一致性及时分发，就像路由协议对路由信息所做的那样。这可能意味着信息应该在路由协议本身中携带，但前提是这样做不会对基本路由功能产生负面影响。
It can be seen that quite a lot of information needs to be exchanged in order to establish and maintain a VPN. The scaling and stability consequences need to be analyzed for any VPN approach.
可以看出，为了建立和维护VPN，需要交换相当多的信息。对于任何VPN方法，都需要分析扩展性和稳定性后果。
While every VPN solution must address the functionality of all three components, the combinations of mechanisms used to provide the needed functionality, and the order in which different pieces of functionality are carried out, may differ.
虽然每个VPN解决方案都必须解决所有三个组件的功能，但用于提供所需功能的机制组合以及不同功能的执行顺序可能有所不同。
For layer 3 provider-provisioned CE-based VPNs, the VPN service is offering tunnels between CE devices. IP routing for the VPN is done by the customer network. With these solutions, the SP is involved in the operation of the membership/capability discovery stage and the tunnel establishment stage. The IP routing functional component may be entirely up to the customer network, or alternatively, the SP's management system may be responsible for the distribution of the reachability information of the VPN sites to the other sites of the same VPN.
对于第3层提供商提供的基于CE的VPN，VPN服务提供CE设备之间的隧道。VPN的IP路由由客户网络完成。通过这些解决方案，SP参与成员资格/能力发现阶段和隧道建立阶段的操作。IP路由功能组件可以完全取决于客户网络，或者，SP的管理系统可以负责将VPN站点的可达性信息分发到同一VPN的其他站点。
For a layer 3 provider-provisioned VPN the SP is responsible for the establishment and maintenance of the VPNs. Many different approaches and schemes are possible in order to provide layer 3 PPVPNs, however there are some generic problems that any VPN solution must address, including:
对于第3层提供商提供的VPN，SP负责VPN的建立和维护。为了提供第3层PPVPN，有许多不同的方法和方案是可能的，但是任何VPN解决方案都必须解决一些通用问题，包括：
o For PE-based VPNs, when a new site is added to a PE, how do the other PEs find out about it? When a PE first gets attached to a given VPN, how does it determine which other PEs are attached to the same VPN. For CE-based VPNs, when a new site is added, how does its CE find out about all the other CEs at other sites of the same VPN?
o 对于基于PE的VPN，当一个新站点添加到PE时，其他PE如何了解它？当PE第一次连接到给定VPN时，它如何确定哪些其他PE连接到同一VPN。对于基于CE的VPN，当添加新站点时，其CE如何了解同一VPN的其他站点上的所有其他CE？
o In order for layer 3 PE-based VPNs to scale, all routes for all VPNs cannot reside on all PEs. How is the distribution of VPN routing information constrained so that it is distributed to only those devices that need it?
o 为了扩展基于第3层PE的VPN，所有VPN的所有路由不能驻留在所有PE上。如何限制VPN路由信息的分发，以便仅将其分发给需要的设备？
o An administrator may wish to provision different topologies for different VPNs (e.g., a full mesh or a hub & spoke topology). How is this achieved?
o 管理员可能希望为不同的VPN提供不同的拓扑（例如，全网拓扑或中心辐射拓扑）。这是如何实现的？
This section looks at some of these generic problems and at some of the mechanisms that can be used to solve them.
本节将介绍其中一些常见问题以及可用于解决这些问题的一些机制。
Mechanisms are needed to acquire information that allows the establishment and maintenance of VPNs. This may include, for example, information on VPN membership, topology, and VPN device capabilities. This information may be statically configured, or distributed by an automated protocol. As a result of the operation of these mechanisms and protocols, a device is able to determine where to set up tunnels, and where to advertise the VPN routes for each VPN.
需要各种机制来获取信息，以便建立和维护VPN。例如，这可能包括关于VPN成员资格、拓扑和VPN设备功能的信息。此信息可以静态配置，也可以通过自动协议分发。由于这些机制和协议的运行，设备能够确定在何处设置隧道，以及在何处为每个VPN公布VPN路由。
With a physical network, the equivalent problem can by solved by the control of the physical interconnection of links, and by having a router run a discovery/hello protocol over its locally connected links. With VPNs both the routers and the links (tunnels) may be logical entities, and thus some other mechanisms are needed.
对于物理网络，通过控制链路的物理互连，并让路由器在其本地连接的链路上运行发现/hello协议，可以解决等效问题。使用VPN时，路由器和链路（隧道）都可能是逻辑实体，因此需要一些其他机制。
A number of different approaches are possible for VPN discovery. One scheme uses the network management system to configure and provision the VPN edge devices. This approach can also be used to distribute VPN discovery information, either using proprietary protocols or using standard management protocols and MIBs. Another approach is where the VPN edge devices act as clients of a centralized directory or database server that contains VPN discovery information. Another possibility is where VPN discovery information is piggybacked onto a routing protocol running between the VPN edge devices [VPN-DISC].
VPN发现有许多不同的方法。一种方案使用网络管理系统来配置和配置VPN边缘设备。这种方法还可以用于分发VPN发现信息，可以使用专有协议，也可以使用标准管理协议和MIB。另一种方法是，VPN边缘设备充当包含VPN发现信息的集中目录或数据库服务器的客户端。另一种可能性是，VPN发现信息被承载到在VPN边缘设备[VPN-DISC]之间运行的路由协议上。
SPs use network management extensively to configure and monitor the various devices that are spread throughout their networks. This approach could be also used for distributing VPN related information. A network management system (either centralized or distributed) could be used by the SP to configure and provision VPNs on the VPN edge devices at various locations. VPN configuration information could be entered into a network management application and distributed to the remote sites via the same means used to distribute other network management information. This approach is most natural when all the devices that must be provisioned are within a single SP's network,
SP广泛使用网络管理来配置和监控遍布其网络的各种设备。这种方法也可用于分发VPN相关信息。SP可以使用网络管理系统（集中式或分布式）在不同位置的VPN边缘设备上配置和配置VPN。VPN配置信息可以输入网络管理应用程序，并通过用于分发其他网络管理信息的相同方式分发到远程站点。当必须配置的所有设备都位于单个SP的网络中时，这种方法最为自然，
since the SP has access to all VPN edge devices in its domain. Security and access control are important, and could be achieved for example using SNMPv3, SSH, or IPsec tunnels.
因为SP可以访问其域中的所有VPN边缘设备。安全性和访问控制非常重要，例如可以使用SNMPv3、SSH或IPsec隧道来实现。
An SP typically needs to maintain a database of VPN configuration/membership information, regardless of the mechanisms used to distribute it. LDAPv3 [RFC3377] is a standard directory protocol which makes it possible to use a common mechanism for both storing such information and distributing it.
SP通常需要维护VPN配置/成员资格信息的数据库，而不考虑用于分发该信息的机制。LDAPv3[RFC3377]是一种标准目录协议，它可以使用一种公共机制来存储和分发此类信息。
To facilitate interoperability between different implementations, as well as between the management systems of different SPs, a standard schema for representing VPN membership and configuration information would have to be developed.
为了促进不同实施之间以及不同SP的管理系统之间的互操作性，必须开发用于表示VPN成员资格和配置信息的标准模式。
LDAPv3 supports authentication of messages and associated access control, which can be used to limit access to VPN information to authorized entities.
LDAPv3支持消息身份验证和相关访问控制，可用于限制授权实体对VPN信息的访问。
Extensions to the use of existing BGP mechanisms, for distribution of VPN membership information, are proposed in [VPN-2547BIS]. In that scheme, BGP is used to distribute VPN routes, and each route carries a set of attributes which indicate the VPN (or VPNs) to which the route belongs. This allows the VPN discovery information and routing information to be combined in a single protocol. Information needed to establish per-VPN tunnels can also be carried as attributes of the routes. This makes use of the BGP protocol's ability to effectively carry large amounts of routing information.
[VPN-2547BIS]中提出了对现有BGP机制的扩展，用于分发VPN成员信息。在该方案中，BGP用于分发VPN路由，每个路由都带有一组属性，这些属性指示路由所属的VPN（或VPN）。这允许VPN发现信息和路由信息组合在一个协议中。建立每VPN隧道所需的信息也可以作为路由的属性携带。这利用了BGP协议有效承载大量路由信息的能力。
It is also possible to use BGP to distribute just the membership/capability information, while using a different technique to distribute the routing. BGP's update message would be used to indicate that a PE is attached to a particular VPN; BGP's withdraw message would be used to indicate that a PE has ceased to be attached to a particular VPN. This makes use of the BGP protocol's ability to dynamically distribute real-time changes in a reliable and fairly rapid manner. In addition, if a BGP route reflector is used, PEs never have to be provisioned with each other's IP addresses at all. Both cases make use of BGP's mechanisms, such as route filters, for constraining the distribution of information.
也可以使用BGP仅分发成员资格/能力信息，同时使用不同的技术分发路由。BGP的更新消息将用于指示PE连接到特定VPN；BGP的撤销消息将用于指示PE已停止连接到特定VPN。这利用了BGP协议以可靠且相当快速的方式动态分发实时更改的能力。此外，如果使用BGP路由反射器，则PEs根本不必为彼此提供IP地址。这两种情况都利用BGP的机制（如路由过滤器）来约束信息的分发。
Augmented routing may be done in combination with aggregated routing, as discussed in section 4.4.4. Of course, when using BGP for distributing any kind of VPN-specific information, one must ensure
如第4.4.4节所述，扩充路由可与聚合路由结合使用。当然，当使用BGP分发任何类型的VPN特定信息时，必须确保
that one is not disrupting the classical use of BGP for distributing public Internet routing information. For further discussion of this, see the discussion of aggregated routing, section 4.4.4.
这并没有破坏BGP用于分发公共互联网路由信息的传统用途。有关这方面的进一步讨论，请参阅第4.4.4节聚合路由的讨论。
When two sites of a VPN are connected to different SP networks, the SPs must support a common mechanism for exchanging membership/capability information. This might make use of manual configuration or automated exchange of information between the SPs. Automated exchange may be facilitated if one or more mechanisms for VPN discovery are standardized and supported across the multiple SPs. Inter-SP trust relationships will need to be established, for example to determine which information and how much information about the VPNs may be exchanged between SPs.
当VPN的两个站点连接到不同的SP网络时，SP必须支持交换成员资格/能力信息的通用机制。这可能需要在SP之间使用手动配置或自动交换信息。如果跨多个SP标准化并支持一个或多个VPN发现机制，则可以促进自动交换。需要建立SP间的信任关系，例如，确定SP之间可以交换哪些信息以及有关VPN的信息量。
In some cases different service providers may deploy different approaches for VPN discovery. Where this occurs, this implies that for multi-SP VPNs, some manual coordination and configuration may be necessary.
在某些情况下，不同的服务提供商可能会部署不同的VPN发现方法。如果出现这种情况，这意味着对于多SP VPN，可能需要进行一些手动协调和配置。
The amount of information which needs to be shared between SPs may vary greatly depending upon the number of size of the multi-SP VPNs. The SPs will therefore need to determine and agree upon the expected amount of membership information to be exchanged, and the dynamic nature of this information. Mechanisms may also be needed to authenticate the VPN membership information.
SP之间需要共享的信息量可能会因多SP VPN的大小而大不相同。因此，SPs将需要确定并商定要交换的预期会员信息量以及该信息的动态性质。可能还需要机制来验证VPN成员身份信息。
VPN information should be distributed only to places where it needs to go, whether that is intra-provider or inter-provider. In this way, the distribution of VPN information is unlike the distribution of inter-provider routing information, as the latter needs to be distributed throughout the Internet. In addition, the joint support of a VPN by two SPs should not require any third SP to maintain state for that VPN. Again, notice the difference with respect to inter-provider routing; in inter-provider routing: sending traffic from one SP to another may indeed require routing state in a third SP.
VPN信息应仅分发到需要访问的地方，无论是提供商内部还是提供商之间。通过这种方式，VPN信息的分发不同于提供商间路由信息的分发，因为后者需要在整个互联网上分发。此外，两个SP对VPN的联合支持不应要求任何第三个SP维护该VPN的状态。再次，请注意关于提供者间路由的差异；在提供程序间路由中：从一个SP向另一个SP发送流量可能确实需要第三个SP中的路由状态。
As one possible example: Suppose that there are two SPs A and C, which want to support a common VPN. Suppose that A and C are interconnected via SP B. In this case B will need to know how to route traffic between A and C, and therefore will need to know something about A and C (such as enough routing information to forward IP traffic and/or connect MPLS LSPs between PEs or route reflectors in A and C). However, for scaling purposes it is desirable that B not need to know VPN-specific information about the VPNs which are supported by A and C.
举一个可能的例子：假设有两个SP A和C，它们希望支持公共VPN。假设A和C通过SP B互连。在这种情况下，B需要知道如何在A和C之间路由流量，因此需要了解关于A和C的一些信息（例如足够的路由信息来转发IP流量和/或连接PE之间的MPLS LSP或A和C中的路由反射器）。然而，出于扩展目的，B不需要知道关于A和C支持的VPN的VPN特定信息是可取的。
In layer 3 provider-provisioned CE-based VPNs, the VPN tunnels connect CE devices. In this case, distribution of IP routing information occurs between CE devices on the customer sites. No additional constraints on the distribution of VPN routing information are necessary.
在第3层提供商提供的基于CE的VPN中，VPN隧道连接CE设备。在这种情况下，IP路由信息在客户站点上的CE设备之间进行分发。不需要对VPN路由信息的分发施加额外的限制。
In layer 3 PE-based VPNs, however, the PE devices must be aware of VPN routing information (for the VPNs to which they are attached). For scalability reasons, one does not want a scheme in which all PEs contain all routes for all VPNs. Rather, only the PEs that are attached to sites in a given VPN should contain the routing information for that VPN. This means that the distribution of VPN routing information between PE devices must be constrained.
然而，在基于第3层PE的VPN中，PE设备必须知道VPN路由信息（对于它们所连接的VPN）。出于可扩展性的原因，不希望所有PE都包含所有VPN的所有路由的方案。相反，只有连接到给定VPN中站点的PE才应该包含该VPN的路由信息。这意味着必须限制PE设备之间VPN路由信息的分布。
As VPN membership may change dynamically, it is necessary to have a mechanism that allows VPN route information to be distributed to any PE where there is an attached user for that VPN, and allows for the removal of this information when it is no longer needed.
由于VPN成员资格可能会动态变化，因此有必要建立一种机制，允许VPN路由信息分发到任何有VPN连接用户的PE，并允许在不再需要该信息时删除该信息。
In the Virtual Router scheme, per-VPN tunnels must be established before any routes for a VPN are distributed, and the routes are then distributed through those tunnels. Thus by establishing the proper set of tunnels, one implicitly constrains and controls the distribution of per-VPN routing information. In this scheme, the distribution of membership information consists of the set of VPNs that exists on each PE, as well as information about the desired topology. This enables a PE to determine the set of remote PEs to which it must establish tunnels for a particular VPN.
在虚拟路由器方案中，在分配VPN的任何路由之前，必须建立每个VPN隧道，然后通过这些隧道分配路由。因此，通过建立适当的隧道集，可以隐式地约束和控制每个VPN路由信息的分布。在该方案中，成员资格信息的分布包括存在于每个PE上的VPN集以及关于所需拓扑的信息。这使PE能够确定必须为特定VPN建立隧道的远程PE集。
In the aggregated routing scheme (see section 4.4.4), the distribution of VPN routing information is constrained by means of route filtering. As VPN membership changes on a PE, the route filters in use between the PE and its peers can be adjusted. Each peer may then adjust the filters in use with each of its peers in turn, and thus the changes propagate across the network. When BGP is used, this filtering may take place at route reflectors as discussed in section 4.4.4.
在聚合路由方案（见第4.4.4节）中，VPN路由信息的分布通过路由过滤进行约束。随着PE上VPN成员身份的更改，可以调整PE与其对等方之间使用的路由筛选器。然后，每个对等方可以依次调整与其每个对等方一起使用的过滤器，因此这些更改会在网络中传播。使用BGP时，如第4.4.4节所述，可在路线反射器处进行过滤。
The topology for a VPN consists of a set of nodes interconnected via tunnels. The topology may be a full mesh, a hub and spoke topology, or an arbitrary topology. For a VPN the set of nodes will include all VPN edge devices that have attached sites for that VPN. Naturally, whatever the topology, all VPN sites are reachable from each other; the topology simply constrains the way traffic is routed
VPN的拓扑由一组通过隧道互连的节点组成。拓扑可以是全网格拓扑、中心辐射拓扑或任意拓扑。对于VPN，节点集将包括具有该VPN连接站点的所有VPN边缘设备。当然，无论拓扑结构如何，所有VPN站点都可以相互访问；拓扑仅限制流量的路由方式
among the sites. For example, in one topology traffic between site A and site B goes from one to the other directly over the VPN backbone; in another topology, traffic from site A to site B must traverse site C before reaching site B.
在这些网站中。例如，在一种拓扑中，站点A和站点B之间的流量直接通过VPN主干从一个站点传输到另一个站点；在另一种拓扑中，从站点A到站点B的流量必须在到达站点B之前穿过站点C。
The simplest topology is a full mesh, where a tunnel exists between every pair of VPN edge devices. If we assume the use of point-to-point tunnels (rather than multipoint-to-point), then with a full mesh topology there are N*(N-1)/2 duplex tunnels or N*(N-1) simplex tunnels for N VPN edge devices. Each tunnel consumes some resources at a VPN edge device, and depending on the type of tunnel, may or may not consume resources in intermediate routers or LSRs. One reason for using a partial mesh topology is to reduce the number of tunnels a VPN edge device, and/or the network, needs to support. Another reason is to support the scenario where an administrator requires all traffic from certain sites to traverse some particular site for policy or control reasons, such as to force traffic through a firewall, or for monitoring or accounting purposes. Note that the topologies used for each VPN are separate, and thus the same VPN edge device may be part of a full mesh topology for one VPN, and of a partial mesh topology for another VPN.
最简单的拓扑是全网拓扑，其中每对VPN边缘设备之间都存在一个隧道。如果我们假设使用点到点隧道（而不是多点到点），那么在全网状拓扑中，N个VPN边缘设备有N*（N-1）/2个双工隧道或N*（N-1）个单工隧道。每个隧道在VPN边缘设备上消耗一些资源，并且根据隧道的类型，可能消耗也可能不消耗中间路由器或LSR中的资源。使用部分网状拓扑的一个原因是减少VPN边缘设备和/或网络需要支持的隧道数量。另一个原因是为了支持这样的场景：管理员出于策略或控制原因（如强制流量通过防火墙，或出于监控或记帐目的），要求来自特定站点的所有流量遍历特定站点。请注意，用于每个VPN的拓扑是独立的，因此，相同的VPN边缘设备可能是一个VPN的全网状拓扑的一部分，也可能是另一个VPN的部分网状拓扑的一部分。
An example of where a partial mesh topology could be suitable is for a VPN that supports a large number of telecommuters and a small number of corporate sites. Most traffic will be between telecommuters and the corporate sites, not between pairs of telecommuters. A hub and spoke topology for the VPN would thus map onto the underlying traffic flow, with the telecommuters attached to spoke VPN edge devices and the corporate sites attached to hub VPN edge devices. Traffic between telecommuters is still supported, but this traffic traverses a hub VPN edge device.
部分网状拓扑可能适用于支持大量远程工作者和少量公司站点的VPN。大多数流量将在远程办公者和公司网站之间，而不是在成对的远程办公者之间。因此，VPN的集线器和分支拓扑将映射到底层流量，远程工作者连接到分支VPN边缘设备，公司站点连接到集线器VPN边缘设备。远程办公者之间的通信仍然受支持，但该通信通过集线器VPN边缘设备。
The selection of a topology for a VPN is an administrative choice, but it is useful to examine protocol mechanisms that can be used to automate the construction of the desired topology, and thus reduce the amount of configuration needed. To this end it is useful for a VPN edge device to be able to advertise per-VPN topology information to other VPN edge devices. It may be simplest to advertise this at the same time as the membership information is advertised, using the same mechanisms.
VPN拓扑的选择是一种管理选择，但检查可用于自动构建所需拓扑的协议机制非常有用，从而减少所需的配置量。为此，VPN边缘设备能够向其他VPN边缘设备播发每个VPN拓扑信息非常有用。使用相同的机制，在发布成员信息的同时发布此信息可能是最简单的。
A simple scheme is where a VPN edge device advertises itself either as a hub or as a spoke, for each VPN that it has. When received by other VPN edge devices this information can be used when determining whether to establish a tunnel. A more comprehensive scheme allows a VPN edge device to advertise a set of topology groups, with tunnels established between a pair of VPN edge devices if they have a group in common.
一个简单的方案是，VPN边缘设备为其拥有的每个VPN作为集线器或分支进行自我宣传。当其他VPN边缘设备接收到此信息时，可在确定是否建立隧道时使用此信息。更全面的方案允许VPN边缘设备公布一组拓扑组，如果两个VPN边缘设备有一个共同的组，则在它们之间建立隧道。
VPN solutions use tunneling in order to transport VPN packets across the VPN backbone, from one VPN edge device to another. There are different types of tunneling protocols, different ways of establishing and maintaining tunnels, and different ways to associate tunnels with VPNs (e.g., shared versus dedicated per-VPN tunnels). Sections 4.3.1 through 4.3.5 discusses some common characteristics shared by all forms of tunneling, and some common problems to which tunnels provide a solution. Section 4.3.6 provides a survey of available tunneling techniques. Note that tunneling protocol issues are generally independent of the mechanisms used for VPN membership and VPN routing.
VPN解决方案使用隧道来跨VPN主干传输VPN数据包，从一个VPN边缘设备传输到另一个VPN边缘设备。有不同类型的隧道协议，建立和维护隧道的不同方式，以及将隧道与VPN关联的不同方式（例如，每VPN共享隧道与专用隧道）。第4.3.1节至第4.3.5节讨论了所有隧道形式的一些共同特征，以及隧道提供解决方案的一些共同问题。第4.3.6节提供了可用隧道技术的调查。请注意，隧道协议问题通常独立于用于VPN成员身份和VPN路由的机制。
One motivation for the use of tunneling is that the packet addressing used in a VPN may have no relation to the packet addressing used between the VPN edge devices. For example the customer VPN traffic could use non-unique or private IP addressing [RFC1918]. Also an IPv6 VPN could be implemented across an IPv4 provider backbone. As such the packet forwarding between the VPN edge devices must use information other than that contained in the VPN packets themselves. A tunneling protocol adds additional information, such an extra header or label, to a VPN packet, and this additional information is then used for forwarding the packet between the VPN edge devices.
使用隧道的一个动机是VPN中使用的分组寻址可能与VPN边缘设备之间使用的分组寻址没有关系。例如，客户VPN流量可以使用非唯一或专用IP地址[RFC1918]。此外，还可以跨IPv4提供商主干网实现IPv6 VPN。因此，VPN边缘设备之间的分组转发必须使用VPN分组本身中包含的信息以外的信息。隧道协议向VPN分组添加额外的信息，例如额外的报头或标签，并且该额外信息随后用于在VPN边缘设备之间转发分组。
Another capability optionally provided by tunneling is that of isolation between different VPN traffic flows. The QoS and security requirements for these traffic flows may differ, and can be met by using different tunnels with the appropriate characteristics. This allows a provider to offer different service characteristics for traffic in different VPNs, or to subsets of traffic flows within a single VPN.
隧道可选地提供的另一个功能是不同VPN流量之间的隔离。这些业务流的QoS和安全要求可能不同，并且可以通过使用具有适当特征的不同隧道来满足。这允许提供商为不同VPN中的流量或单个VPN中的流量子集提供不同的服务特性。
The specific tunneling protocols considered in this section are GRE, IP-in-IP, IPsec, and MPLS, as these are the most suitable for carrying VPN traffic across the VPN backbone. Other tunneling protocols, such as L2TP [RFC2661], may be used as access tunnels, carrying traffic between a PE and a CE. As backbone tunneling is independent of and orthogonal to access tunneling, protocols for the latter are not discussed here.
本节中考虑的特定隧道协议是GRE、IP-in-IP、IPsec和MPLS，因为它们最适合在VPN主干上承载VPN流量。其他隧道协议，例如L2TP[RFC2661]，可以用作接入隧道，在PE和CE之间承载业务。由于主干隧道独立于接入隧道，且与接入隧道正交，因此本文不讨论后者的协议。
All tunneling protocols use an encapsulation that adds additional information to the encapsulated packet; this information is used for forwarding across the VPN backbone. Examples are provided in section 4.3.6.
所有隧道协议都使用一种封装，向封装的数据包添加额外的信息；此信息用于跨VPN主干进行转发。第4.3.6节提供了示例。
One characteristic of a tunneling protocol is whether per-tunnel state is needed in the SP network in order to forward the encapsulated packets. For IP tunneling schemes (GRE, IP-in-IP, and IPsec) per-tunnel state is completely confined to the VPN edge devices. Other routers are unaware of the tunnels, and forward according to the IP header. For MPLS, per-tunnel state is needed, since the top label in the label stack must be examined and swapped by intermediate LSRs. The amount of state required can be minimized by hierarchical multiplexing, and by use of multi-point to point tunnels, as discussed below.
隧道协议的一个特征是SP网络中是否需要每个隧道状态才能转发封装的数据包。对于IP隧道方案（GRE、IP中的IP和IPsec），每个隧道状态完全限于VPN边缘设备。其他路由器不知道隧道，并根据IP报头转发。对于MPLS，需要每个隧道状态，因为标签堆栈中的顶部标签必须由中间LSR检查和交换。所需的状态量可以通过分层复用和使用多点对点隧道来最小化，如下所述。
Another characteristic is the tunneling overhead introduced. With IPsec the overhead may be considerable as it may include, for example, an ESP header, ESP trailer and an additional IP header. The other mechanisms listed use less overhead, with MPLS being the most lightweight. The overhead inherent in any tunneling mechanism may result in additional IP packet fragmentation, if the resulting packet is too large to be carried by the underlying link layer. As such it is important to report any reduced MTU sizes via mechanisms such as path MTU discovery in order to avoid fragmentation wherever possible.
另一个特点是引入了隧道开销。对于IPsec，开销可能相当大，因为它可能包括例如ESP头、ESP尾和附加IP头。列出的其他机制使用较少的开销，其中MPLS是最轻量级的。任何隧道机制中固有的开销可能导致额外的IP分组碎片，如果产生的分组太大而不能由底层链路层承载。因此，重要的是通过路径MTU发现等机制报告任何减少的MTU大小，以尽可能避免碎片。
Yet another characteristic is something we might call "transparency to the Internet". IP-based encapsulation can carry be used to carry a packet anywhere in the Internet. MPLS encapsulation can only be used to carry a packet on IP networks that support MPLS. If an MPLS-encapsulated packet must cross the networks of multiple SPs, the adjacent SPs must bilateral agreements to accept MPLS packets from each other. If only a portion of the path across the backbone lacks MPLS support, then an MPLS-in-IP encapsulation can be used to move the MPLS packets across that part of the backbone. However, this does add complexity. On the other hand, MPLS has efficiency advantages, particularly in environments where encapsulations may need to be nested.
另一个特点是我们可以称之为“互联网透明度”。基于IP的封装可用于在Internet上的任何位置传输数据包。MPLS封装只能用于在支持MPLS的IP网络上承载数据包。如果MPLS封装的数据包必须跨越多个SP的网络，则相邻SP必须签订双边协议以接受彼此的MPLS数据包。如果主干上只有一部分路径缺少MPLS支持，则可以使用MPLS-in-IP封装在主干的该部分上移动MPLS数据包。然而，这确实增加了复杂性。另一方面，MPLS具有效率优势，特别是在可能需要嵌套封装的环境中。
Transparency to the Internet is sometimes a requirement, but sometimes not. This depends on the sort of service which a SP is offering to its customer.
互联网的透明度有时是一项要求，但有时不是。这取决于SP向其客户提供的服务种类。
When a tunneled packet arrives at the tunnel egress, it must be possible to infer the packet's VPN from its encapsulation header. In MPLS encapsulations, this must be inferred from the packet's label stack. In IP-based encapsulations, this can be inferred from some combination of the IP source address, the IP destination address, and a "multiplexing field" in the encapsulation header. The multiplexing
当隧道数据包到达隧道出口时，必须能够从其封装头推断数据包的VPN。在MPLS封装中，这必须从数据包的标签堆栈推断出来。在基于IP的封装中，这可以从IP源地址、IP目标地址和封装头中的“多路复用字段”的某些组合中推断出来。多路复用
field might be one which was explicitly designed for multiplexing, or one that wasn't originally designed for this but can be pushed into service as a multiplexing field. For example:
字段可能是一个明确设计用于多路复用的字段，也可能是一个最初并非设计用于多路复用的字段，但可以作为多路复用字段投入使用。例如：
o GRE: Packets associated to VPN by source IP address, destination IP address, and Key field, although the key field was originally intended for authentication.
o GRE：按源IP地址、目标IP地址和密钥字段与VPN关联的数据包，尽管密钥字段最初用于身份验证。
o IP-in-IP: Packets associated to VPN by IP destination address in outer header.
o IP中的IP：通过外部报头中的IP目标地址与VPN关联的数据包。
o IPsec: Packets associated to VPN by IP source address, IP destination address, and SPI field.
o IPsec：按IP源地址、IP目标地址和SPI字段与VPN关联的数据包。
o MPLS: Packets associated to VPN by label stack.
o MPLS：通过标签堆栈与VPN关联的数据包。
Note that IP-in-IP tunneling does not have a real multiplexing field, so a different IP destination address must be used for every VPN supported by a given PE. In the other IP-based encapsulations, a given PE need have only a single IP address, and the multiplexing field is used to distinguish the different VPNs supported by a PE. Thus the IP-in-IP solution has the significant disadvantage that it requires the allocation and assignment of a potentially large number of IP addresses, all of which have to be reachable via backbone routing.
请注意，IP隧道中的IP没有真正的多路复用字段，因此必须为给定PE支持的每个VPN使用不同的IP目标地址。在其他基于IP的封装中，给定的PE只需要一个IP地址，并且复用字段用于区分PE支持的不同VPN。因此，IP-in-IP解决方案有一个显著的缺点，即它需要分配和分配潜在的大量IP地址，所有这些地址都必须通过主干路由进行访问。
In the following, we will use the term "multiplexing field" to refer to whichever field in the encapsulation header must is used to distinguish different VPNs at a given PE. In the IP-in-IP encapsulation, this is the destination IP address field, in the other encapsulations it is a true multiplexing field.
在下文中，我们将使用术语“多路复用字段”来指封装报头中必须用于区分给定PE上不同VPN的字段。在IP-In-IP封装中，这是目标IP地址字段，在其他封装中，这是真正的多路复用字段。
When tunnels are established, the tunnel endpoints must agree on the multiplexing field values which are to be used to indicate that particular packets are in particular VPNs. The use of "well known" or explicitly provisioned values would not scale well as the number of VPNs increases. So it is necessary to have some sort of protocol interaction in which the tunnel endpoints agree on the multiplexing field values.
当建立隧道时，隧道端点必须在复用字段值上达成一致，该值将用于指示特定数据包在特定VPN中。随着VPN数量的增加，使用“已知”或显式配置的值将无法很好地扩展。因此，有必要进行某种协议交互，其中隧道端点在复用字段值上达成一致。
For some tunneling protocols, setting up a tunnel requires an explicit exchange of signaling messages. Generally the multiplexing field values would be agreed upon as part of this exchange. For example, if an IPsec encapsulation is used, the SPI field plays the role of the multiplexing field, and IKE signaling is used to distribute the SPI values; if an MPLS encapsulation is used, LDP,
对于某些隧道协议，建立隧道需要显式交换信令消息。通常，多路复用字段值将作为交换的一部分达成一致。例如，如果使用IPsec封装，则SPI字段扮演多路复用字段的角色，并且IKE信令用于分发SPI值；如果使用MPLS封装，LDP，
CR-LDP or RSVP-TE can be used to distribute the MPLS label value used as the multiplexing field. Information about the identity of the VPN with which the tunnel is to be associated needs to be exchanged as part of the signaling protocol (e.g., a VPN-ID can be carried in the signaling protocol). An advantage of this approach is that per-tunnel security, QoS and other characteristics may also be negotiable via the signaling protocol. A disadvantage is that the signaling imposes overhead, which may then lead to scalability considerations, discussed further below.
CR-LDP或RSVP-TE可用于分发用作复用字段的MPLS标签值。关于与隧道相关联的VPN的标识的信息需要作为信令协议的一部分进行交换（例如，可以在信令协议中携带VPN-ID）。这种方法的优点是，每个隧道的安全性、QoS和其他特性也可以通过信令协议协商。一个缺点是信令带来了开销，这可能导致可伸缩性方面的考虑，下面将进一步讨论。
For some tunneling protocols, there is no explicit protocol interaction that sets up the tunnel, and the multiplexing field values must be exchanged in some other way. For example, for MPLS tunnels, MPLS labels can be piggybacked on the protocols used to distribute VPN routes or VPN membership information. GRE and IP-in-IP have no associated signaling protocol, and thus by necessity the multiplexing values are distributed via some other mechanism, such as via configuration, control protocol, or piggybacked in some manner on a VPN membership protocol.
对于某些隧道协议，没有建立隧道的显式协议交互，必须以其他方式交换多路复用字段值。例如，对于MPLS隧道，MPLS标签可以搭载在用于分发VPN路由或VPN成员信息的协议上。GRE和IP-in-IP没有相关联的信令协议，因此，必要时，复用值通过一些其他机制分布，例如通过配置、控制协议或以某种方式在VPN成员协议上搭载。
The resources used by the different tunneling establishment mechanisms may vary. With a full mesh VPN topology, and explicit signaling, each VPN edge device has to establish a tunnel to all the other VPN edge devices for in each VPN. The resources needed for this on a VPN edge device may be significant, and issues such as the time needed to recover following a device failure may need to be taken into account, as the time to recovery includes the time needed to reestablish a large number of tunnels.
不同隧道建立机制使用的资源可能不同。使用全网状VPN拓扑和显式信令，每个VPN边缘设备必须为每个VPN中的所有其他VPN边缘设备建立一个隧道。在VPN边缘设备上执行此操作所需的资源可能非常重要，并且可能需要考虑设备故障后恢复所需的时间等问题，因为恢复时间包括重新建立大量隧道所需的时间。
If tunnels require state to be maintained in the core of the network, it may not be feasible to set up per-VPN tunnels between all adjacent devices that are adjacent in some VPN topology. This would violate the principle that there is no per-VPN state in the core of the network, and would make the core scale poorly as the number of VPNs increases. For example, MPLS tunnels require that core network devices maintain state for the topmost label in the label stack. If every core router had to maintain one or more labels for every VPN, scaling would be very poor.
如果隧道要求在网络核心中维护状态，则在某些VPN拓扑中相邻的所有相邻设备之间设置每个VPN隧道可能是不可行的。这将违反网络核心中不存在每个VPN状态的原则，并且随着VPN数量的增加，核心的扩展将变得很差。例如，MPLS隧道要求核心网络设备维护标签堆栈中最顶层标签的状态。如果每个核心路由器必须为每个VPN维护一个或多个标签，那么扩展性将非常差。
There are also scaling considerations related to the use of explicit signaling for tunnel establishment. Even if the tunneling protocol does not maintain per tunnel state in the core, the number of tunnels that a single VPN edge device needs to handle may be large, as this grows according to the number of VPNs and the number of neighbors per VPN. One way to reduce the number of tunnels in a network is to use
此外，还存在与隧道建设中使用显式信号相关的扩展考虑。即使隧道协议没有在核心中保持每个隧道的状态，单个VPN边缘设备需要处理的隧道数量也可能很大，因为这会随着VPN数量和每个VPN的邻居数量的增加而增加。减少网络中隧道数量的一种方法是使用
a VPN topology other than a full mesh. However this may not always be desirable, and even with hub and spoke topologies the hubs VPN edge devices may still need to handle large numbers of tunnels.
VPN拓扑，而不是完整网格。然而，这可能并不总是可取的，即使使用中心辐射拓扑，中心VPN边缘设备也可能需要处理大量隧道。
If the core routers need to maintain any per-tunnel state at all, scaling can be greatly improved by using hierarchical tunnels. One tunnel can be established between each pair of VPN edge devices, and multiple VPN-specific tunnels can then be carried through the single "outer" tunnel. Now the amount of state is dependent only on the number of VPN edge devices, not on the number of VPNs. Scaling can be further improved by having the outer tunnels be multipoint-to-point "merging" tunnels. Now the amount of state to be maintained in the core is on the order of the number of VPN edge devices, not on the order of the square of that number. That is, the amount of tunnel state is roughly equivalent to the amount of state needed to maintain IP routes to the VPN edge devices. This is almost (if not quite) as good as using tunnels which do not require any state to be maintained in the core.
如果核心路由器需要保持任何每通道状态，那么通过使用分层通道可以极大地提高可伸缩性。可以在每对VPN边缘设备之间建立一个隧道，然后可以通过单个“外部”隧道承载多个特定于VPN的隧道。现在，状态量仅取决于VPN边缘设备的数量，而不取决于VPN的数量。通过将外部隧道设置为多点对点“合并”隧道，可进一步改善缩放效果。现在，要在核心中维护的状态量取决于VPN边缘设备的数量，而不是该数量的平方。也就是说，隧道状态的量大致相当于维护到VPN边缘设备的IP路由所需的状态量。这几乎（如果不是完全）等同于使用不需要在堆芯中保持任何状态的隧道。
Using hierarchical tunnels may also reduce the amount of state to be maintained in the VPN edge devices, particularly if maintaining the outer tunnels requires more state than maintaining the per-VPN tunnels that run inside the outer tunnels.
使用分层隧道还可以减少VPN边缘设备中要维护的状态量，特别是如果维护外部隧道需要比维护在外部隧道内运行的每VPN隧道更多的状态。
There are other factors relevant to determining the number of VPN edge to VPN edge "outer" tunnels to use. While using a single such tunnel has the best scaling properties, using more than one may allow different QoS capabilities or different security characteristics to be used for different traffic flows (from the same or from different VPNs).
确定要使用的VPN边缘到VPN边缘“外部”隧道的数量还有其他相关因素。虽然使用单个这样的隧道具有最佳的扩展特性，但使用多个隧道可能会允许对不同的流量（来自相同或不同的VPN）使用不同的QoS能力或不同的安全特性。
When tunnels are used hierarchically, the tunnels in the hierarchy may all be of the same type (e.g., an MPLS label stack) or they may be of different types (e.g., a GRE tunnel carried inside an IPsec tunnel).
当分层使用隧道时，分层中的隧道可能都是相同类型的（例如，MPLS标签堆栈），也可能是不同类型的（例如，在IPsec隧道中携带的GRE隧道）。
One example using hierarchical tunnels is the establishment of a number of different IPsec security associations, providing different levels of security between a given pair of VPN edge devices. Per-VPN GRE tunnels can then be grouped together and then carried over the appropriate IPsec tunnel, rather than having a separate IPsec tunnel per-VPN. Another example is the use of an MPLS label stack. A single PE-PE LSP is used to carry all the per-VPN LSPs. The mechanisms used for label establishment are typically different. The PE-PE LSP could be established using LDP, as part or normal backbone operation, with the per-VPN LSP labels established by piggybacking on VPN routing (e.g., using BGP) discussed in sections 3.3.1.3 and 4.1.
使用分层隧道的一个示例是建立多个不同的IPsec安全关联，在给定的一对VPN边缘设备之间提供不同级别的安全性。然后，每个VPN GRE隧道可以组合在一起，然后通过适当的IPsec隧道进行传输，而不是每个VPN有一个单独的IPsec隧道。另一个例子是使用MPLS标签堆栈。单个PE-PE LSP用于承载所有每VPN LSP。用于建立标签的机制通常是不同的。PE-PE LSP可以使用LDP建立，作为部分或正常主干网操作，每VPN LSP标签通过第3.3.1.3节和第4.1节中讨论的VPN路由（例如，使用BGP）建立。
Once a tunnel is established it is necessary to know that the tunnel is operational. Mechanisms are needed to detect tunnel failures, and to respond appropriately to restore service.
一旦隧道建成，就有必要知道隧道正在运行。需要一些机制来检测隧道故障，并适当地响应恢复服务。
There is a potential issue regarding propagation of failures when multiple tunnels are multiplexed hierarchically. Suppose that multiple VPN-specific tunnels are multiplexed inside a single PE to PE tunnel. In this case, suppose that routing for the VPN is done over the VPN-specific tunnels (as may be the case for CE-based and VR approaches). Suppose that the PE to PE tunnel fails. In this case multiple VPN-specific tunnels may fail, and layer 3 routing may simultaneously respond for each VPN using the failed tunnel. If the PE to PE tunnel is subsequently restored, there may then be multiple VPN-specific tunnels and multiple routing protocol instances which also need to recover. Each of these could potentially require some exchange of control traffic.
当多个隧道分层复用时，存在一个关于故障传播的潜在问题。假设多个VPN特定隧道在单个PE-to-PE隧道内多路复用。在这种情况下，假设VPN的路由通过VPN特定的隧道完成（对于基于CE和VR的方法可能是这样）。假设PE-to-PE隧道失败。在这种情况下，多个特定于VPN的隧道可能会失败，第3层路由可能会使用失败的隧道同时对每个VPN做出响应。如果随后恢复PE到PE隧道，则可能有多个VPN特定隧道和多个路由协议实例也需要恢复。其中每一个都可能需要一些控制流量的交换。
When a tunnel fails, if the tunnel can be restored quickly, it might therefore be preferable to restore the tunnel without any response by high levels (such as other tunnels which were multiplexed inside the failed tunnels). By having high levels delay response to a lower level failed tunnel, this may limit the amount of control traffic needed to completely restore correct service. However, if the failed tunnel cannot be quickly restored, then it is necessary for the tunnels or routing instances multiplexed over the failed tunnel to respond, and preferable for them to respond quickly and without explicit action by network operators.
当隧道发生故障时，如果可以快速恢复隧道，则最好在没有高层响应的情况下恢复隧道（例如在故障隧道内多路复用的其他隧道）。通过对较低级别的故障隧道进行高级别延迟响应，这可能会限制完全恢复正确服务所需的控制通信量。然而，如果无法快速恢复故障隧道，则必须对通过故障隧道多路复用的隧道或路由实例进行响应，并且优选地，它们能够快速响应，而无需网络运营商的明确操作。
With most layer 3 provider-provisioned CE-based VPNs and the VR scheme, a per-VPN instance of routing is running over the tunnel, thus any loss of connectivity between the tunnel endpoints will be detected by the VPN routing instance. This allows rapid detection of tunnel failure. Careful adjustment of timers might be needed to avoid failure propagation as discussed the above. With the aggregated routing scheme, there isn't a per-VPN instance of routing running over the tunnel, and therefore some other scheme to detect loss of connectivity is needed in the event that the tunnel cannot be rapidly restored.
对于大多数第3层提供商提供的基于CE的VPN和VR方案，每个VPN路由实例都在隧道上运行，因此VPN路由实例将检测隧道端点之间的任何连接丢失。这允许快速检测隧道故障。如上文所述，可能需要仔细调整计时器以避免故障传播。使用聚合路由方案时，隧道上不存在每个VPN路由实例，因此，如果无法快速恢复隧道，则需要一些其他方案来检测连接丢失。
Failure of connectivity in a tunnel can be very difficult to detect reliably. Among the mechanisms that can be used to detect failure are loss of the underlying connectivity to the remote endpoint (as indicated, e.g., by "no IP route to host" or no MPLS label), timeout of higher layer "hello" mechanisms (e.g., IGP hellos, when the tunnel is an adjacency in some IGP), and timeout of keep alive mechanisms in
隧道中的连接故障可能很难可靠检测。可用于检测故障的机制包括与远程端点的底层连接丢失（如图所示，如“无主机IP路由”或无MPLS标签所示）、高层“hello”机制超时（如IGP hellos，当隧道是某些IGP中的邻接时），以及中保持活动机制超时
the tunnel establishment protocols (if any). However, none of these techniques provides completely reliable detection of all failure modes. Additional monitoring techniques may also be necessary.
隧道建立协议（如有）。然而，这些技术都不能完全可靠地检测所有故障模式。可能还需要其他监测技术。
With hierarchical tunnels it may suffice to only monitor the outermost tunnel for loss of connectivity. However there may be failure modes in a device where the outermost tunnel is up but one of the inner tunnels is down.
对于分层隧道，仅监控最外层隧道的连通性损失就足够了。然而，当最外层通道向上但其中一个内部通道向下时，设备中可能存在故障模式。
Tunneling mechanisms provide isolated communication between two CE-PE devices. Available tunneling mechanisms include (but are not limited to): GRE [RFC2784] [RFC2890], IP-in-IP encapsulation [RFC2003] [RFC2473], IPsec [RFC2401] [RFC2402], and MPLS [RFC3031] [RFC3035].
隧道机制在两个CE-PE设备之间提供隔离通信。可用的隧道机制包括（但不限于）：GRE[RFC2784][RFC2890]、IP-in-IP封装[RFC2003][RFC2473]、IPsec[RFC2401][RFC2402]和MPLS[RFC3031][RFC3035]。
Note that the following subsections address tunnel overhead to clarify the risk of fragmentation. Some SP networks contain layer 2 switches that enforce the standard/default MTU of 1500 bytes. In this case, any encapsulation whatsoever creates a significant risk of fragmentation. However, layer 2 switch vendors are in general aware of IP tunneling as well as stacked VLAN overhead, thus many switches practically allow an MTU of approximately 1512 bytes now. In this case, up to 12 bytes of encapsulation can be used before there is any risk of fragmentation. Furthermore, to improve TCP and NFS performance, switches that support 9K bytes "jumbo frames" are also on the market. In this case, there is no risk of fragmentation.
请注意，以下小节讨论了隧道开销，以澄清碎片风险。某些SP网络包含第2层交换机，这些交换机强制执行1500字节的标准/默认MTU。在这种情况下，任何封装都会产生严重的碎片风险。然而，第2层交换机供应商通常知道IP隧道和堆叠的VLAN开销，因此许多交换机现在实际上允许大约1512字节的MTU。在这种情况下，在出现碎片风险之前，最多可以使用12字节的封装。此外，为了提高TCP和NFS性能，市场上也有支持9K字节“巨型帧”的交换机。在这种情况下，不存在碎片化的风险。
Generic Routing Encapsulation (GRE) specifies a protocol for encapsulating an arbitrary payload protocol over an arbitrary delivery protocol [RFC2784]. In particular, it can be used where both the payload and the delivery protocol are IP as is the case in layer 3 VPNs. A GRE tunnel is a tunnel whose packets are encapsulated by GRE.
通用路由封装（GRE）指定一种协议，用于在任意传递协议上封装任意有效负载协议[RFC2784]。特别是，它可以在有效负载和传送协议都是IP的情况下使用，就像在第3层VPN中一样。GRE隧道是其数据包由GRE封装的隧道。
o Multiplexing
o 多路复用
The GRE specification [RFC2784] does not explicitly support multiplexing. But the key field extension to GRE is specified in [RFC2890] and it may be used as a multiplexing field.
GRE规范[RFC2784]不明确支持多路复用。但是[RFC2890]中指定了GRE的密钥字段扩展，它可以用作多路复用字段。
o QoS/SLA
o 服务质量/服务级别协议
GRE itself does not have intrinsic QoS/SLA capabilities, but it inherits whatever capabilities exist in the delivery protocol (IP). Additional mechanisms, such as Diffserv or RSVP extensions [RFC2746], can be applied.
GRE本身没有内在的QoS/SLA功能，但它继承了交付协议（IP）中存在的任何功能。可以应用其他机制，例如Diffserv或RSVP扩展[RFC2746]。
o Tunnel setup and maintenance
o 隧道设置和维护
There is no standard signaling protocol for setting up and maintaining GRE tunnels.
没有用于建立和维护GRE隧道的标准信令协议。
o Large MTUs and minimization of tunnel overhead
o 大MTU和隧道架空的最小化
When GRE encapsulation is used, the resulting packet consists of a delivery protocol header, followed by a GRE header, followed by the payload packet. When the delivery protocol is IPv4, and if the key field is not present, GRE encapsulation adds at least 28 bytes of overhead (36 bytes if key field extension is used.)
当使用GRE封装时，生成的数据包由一个传递协议报头、一个GRE报头和一个有效负载数据包组成。当传递协议为IPv4且密钥字段不存在时，GRE封装会增加至少28字节的开销（如果使用密钥字段扩展，则为36字节）
o Security
o 安全
GRE encapsulation does not provide any significant security. The optional key field can be used as a clear text password to aid in the detection of misconfigurations, but it does not provide integrity or authentication. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. If multi-provider VPNs are being supported, it may be difficult to set up these filters.
GRE封装不提供任何重要的安全性。可选密钥字段可用作明文密码，以帮助检测错误配置，但它不提供完整性或身份验证。支持VPN的SP网络必须在其边界进行广泛的IP地址过滤，以防止伪造的数据包穿透VPN。如果支持多提供商VPN，则可能很难设置这些筛选器。
IP-in-IP specifies the format and procedures for IP-in-IP encapsulation. This allows an IP datagram to be encapsulated within another IP datagram. That is, the resulting packet consists of an outer IP header, followed immediately by the payload packet. There is no intermediate header as in GRE. [RFC2003] and [RFC2473] specify IPv4 and IPv6 encapsulations respectively. Once the encapsulated datagram arrives at the intermediate destination (as specified in the outer IP header), it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original destination address field.
IP-in-IP指定IP-in-IP封装的格式和过程。这允许将一个IP数据报封装在另一个IP数据报中。也就是说，生成的数据包由外部IP报头组成，紧接着是有效负载数据包。没有GRE中的中间标题。[RFC2003]和[RFC2473]分别指定IPv4和IPv6封装。一旦封装的数据报到达中间目的地（如外部IP报头中所指定），它将被解除封装，产生原始IP数据报，然后将其传送到原始目的地地址字段所指示的目的地。
o Multiplexing
o 多路复用
The IP-in-IP specifications don't explicitly support multiplexing. But if a different IP address is used for every VPN then the IP address field can be used for this purpose. (See section 4.3.2 for detail).
IP中的IP规范不明确支持多路复用。但如果每个VPN使用不同的IP地址，则IP地址字段可用于此目的。（详见第4.3.2节）。
o QoS/SLA
o 服务质量/服务级别协议
IP-in-IP itself does not have intrinsic QoS/SLA capabilities, but of course it inherits whatever capabilities exist for IP. Additional mechanisms, such as RSVP extensions [RFC2764] or DiffServ extensions [RFC2983], may be used with it.
IP中的IP本身没有固有的QoS/SLA功能，但它当然继承了IP的所有功能。附加机制，例如RSVP扩展[RFC2764]或DiffServ扩展[RFC2983]可以与之一起使用。
o Tunnel setup and maintenance
o 隧道设置和维护
There is no standard setup and maintenance protocol for IP-in-IP.
IP中没有标准的IP设置和维护协议。
o Large MTUs and minimization of tunnel overhead
o 大MTU和隧道架空的最小化
When the delivery protocol is IPv4, IP-in-IP adds at least 20 bytes of overhead.
当传送协议为IPv4时，IP中的IP会增加至少20字节的开销。
o Security
o 安全
IP-in-IP encapsulation does not provide any significant security. An SP network which supports VPNs must do extensive IP address filtering at its borders to prevent spoofed packets from penetrating the VPNs. If multi-provider VPNs are being supported, it may be difficult to set up these filters.
IP-in-IP封装不提供任何重要的安全性。支持VPN的SP网络必须在其边界进行广泛的IP地址过滤，以防止伪造的数据包穿透VPN。如果支持多提供商VPN，则可能很难设置这些筛选器。
IP Security (IPsec) provides security services at the IP layer [RFC2401]. It comprises authentication header (AH) protocol [RFC2402], encapsulating security payload (ESP) protocol [RFC2406], and Internet key exchange (IKE) protocol [RFC2409]. AH protocol provides data integrity, data origin authentication, and an anti-replay service. ESP protocol provides data confidentiality and limited traffic flow confidentiality. It may also provide data integrity, data origin authentication, and an anti-replay service. AH and ESP may be used in combination.
IP安全（IPsec）在IP层提供安全服务[RFC2401]。它包括身份验证头（AH）协议[RFC2402]、封装安全有效负载（ESP）协议[RFC2406]和互联网密钥交换（IKE）协议[RFC2409]。AH协议提供数据完整性、数据源身份验证和反重放服务。ESP协议提供数据机密性和有限的流量机密性。它还可以提供数据完整性、数据源身份验证和反重播服务。AH和ESP可结合使用。
IPsec may be employed in either transport or tunnel mode. In transport mode, either an AH or ESP header is inserted immediately after the payload packet's IP header. In tunnel mode, an IP packet is encapsulated with an outer IP packet header. Either an AH or ESP header is inserted between them. AH and ESP establish a
IPsec可以在传输或隧道模式中使用。在传输模式下，AH或ESP报头在有效负载数据包的IP报头之后立即插入。在隧道模式下，IP数据包用外部IP数据包头封装。在它们之间插入AH或ESP标头。啊和ESP建立一个
unidirectional secure communication path between two endpoints, which is called a security association. In tunnel mode, PE-PE tunnel (or a CE-CE tunnel) consists of a pair of unidirectional security associations. The IPsec and IKE protocols are used for setting up IPsec tunnels.
两个端点之间的单向安全通信路径，称为安全关联。在隧道模式下，PE-PE隧道（或CE-CE隧道）由一对单向安全关联组成。IPsec和IKE协议用于设置IPsec隧道。
o Multiplexing
o 多路复用
The SPI field of AH and ESP is used to multiplex security associations (or tunnels) between two peer devices.
AH和ESP的SPI字段用于在两个对等设备之间多路传输安全关联（或隧道）。
o QoS/SLA
o 服务质量/服务级别协议
IPsec itself does not have intrinsic QoS/SLA capabilities, but it inherits whatever mechanisms exist for IP. Other mechanisms such as "RSVP Extensions for IPsec Data Flows" [RFC2207] or DiffServ extensions [RFC2983] may be used with it.
IPsec本身没有内在的QoS/SLA功能，但它继承了IP现有的任何机制。其他机制，如“IPsec数据流的RSVP扩展”[RFC2207]或DiffServ扩展[RFC2983]可与之一起使用。
o Tunnel setup and maintenance
o 隧道设置和维护
The IPsec and IKE protocols are used for the setup and maintenance of tunnels.
IPsec和IKE协议用于隧道的设置和维护。
o Large MTUs and minimization of tunnel overhead
o 大MTU和隧道架空的最小化
IPsec transport mode adds at least 8 bytes of overhead. IPsec tunnel mode adds at least 28 bytes of overhead. IPsec transport mode adds minimal overhead. In PE-based PPVPNs, the processing overhead of IPsec (due to its cryptography) may limit the PE's performance, especially if privacy is being provided; this is not generally an issue in CE-based PPVPNs.
IPsec传输模式至少会增加8字节的开销。IPsec隧道模式至少会增加28字节的开销。IPsec传输模式增加了最小的开销。在基于PE的PPVPN中，IPsec的处理开销（由于其加密）可能会限制PE的性能，特别是在提供隐私的情况下；这在基于CE的PPVPN中通常不是一个问题。
o Security
o 安全
When IPsec tunneling is used in conjunction with IPsec's cryptographic capabilities, excellent authentication and integrity functions can be provided. Privacy can also be optionally provided.
当IPsec隧道与IPsec的加密功能结合使用时，可以提供出色的身份验证和完整性功能。还可以选择提供隐私。
Multiprotocol Label Switching (MPLS) is a method for forwarding packets through a network. Routers at the edge of a network apply simple labels to packets. A label may be inserted between the data link and network headers, or may be carried in the data link header (e.g., the VPI/VCI field in an ATM header). Routers in the network
多协议标签交换（MPLS）是一种通过网络转发数据包的方法。网络边缘的路由器将简单的标签应用于数据包。标签可插入数据链路和网络报头之间，或可携带在数据链路报头中（例如，ATM报头中的VPI/VCI字段）。网络中的路由器
switch packets according to the labels, with minimal lookup overhead. A path, or a tunnel in the PPVPN, is called a "label switched path (LSP)".
根据标签交换数据包，查找开销最小。PPVPN中的路径或隧道称为“标签交换路径（LSP）”。
o Multiplexing
o 多路复用
LSPs may be multiplexed within other LSPs.
lsp可以在其他lsp内复用。
o QoS/SLA
o 服务质量/服务级别协议
MPLS does not have intrinsic QoS or SLA management mechanisms, but bandwidth may be allocated to LSPs, and their routing may be explicitly controlled. Additional techniques such as DiffServ and DiffServ aware traffic engineering may be used with it [RFC3270] [MPLS-DIFF-TE]. QoS capabilities from IP may be inherited.
MPLS没有内在的QoS或SLA管理机制，但是带宽可以分配给LSP，并且可以显式地控制它们的路由。其他技术，如区分服务和区分服务感知流量工程可与之一起使用[RFC3270][MPLS-DIFF-TE]。可以继承来自IP的QoS功能。
o Tunnel setup and maintenance
o 隧道设置和维护
LSPs are set up and maintained by LDP (Label Distribution Protocol), RSVP (Resource Reservation Protocol) [RFC3209], or BGP.
LSP由LDP（标签分发协议）、RSVP（资源保留协议）[RFC3209]或BGP设置和维护。
o Large MTUs and minimization of tunnel overhead.
o 大MTU和最小化隧道开销。
MPLS encapsulation adds four bytes per label. VPN-2547BIS's [VPN-2547BIS] approach uses at least two labels for encapsulation and adds minimal overhead.
MPLS封装为每个标签添加四个字节。VPN-2547BIS的[VPN-2547BIS]方法使用至少两个标签进行封装，并增加最小的开销。
o Encapsulation
o 封装
MPLS packets may optionally be encapsulated in IP or GRE, for cases where it is desirable to carry MPLS packets over an IP-only infrastructure.
MPLS分组可以可选地封装在IP或GRE中，用于希望通过仅IP的基础设施来携带MPLS分组的情况。
o Security
o 安全
MPLS encapsulation does not provide any significant security. An SP which is providing VPN service can refuse to accept MPLS packets from outside its borders. This provides the same level of assurance as would be obtained via IP address filtering when IP-based encapsulations are used. If a VPN is jointly provided by multiple SPs, care should be taken to ensure that a labeled packet is accepted from a neighboring router in another SP only if its top label is one which was actually distributed to that router.
MPLS封装不提供任何重要的安全性。提供VPN服务的SP可以拒绝接受来自其边界之外的MPLS数据包。这提供了与使用基于IP的封装时通过IP地址过滤获得的相同级别的保证。如果VPN是由多个SP联合提供的，则应注意确保只有当另一SP中的相邻路由器的顶部标签是实际分发给该路由器的标签时，才接受该标签数据包。
o Applicability
o 适用性
MPLS is the only one of the encapsulation techniques that cannot be guaranteed to run over any IP network. Hence it would not be applicable when transparency to the Internet is a requirement.
MPLS是唯一一种不能保证在任何IP网络上运行的封装技术。因此，当互联网的透明度是一项要求时，它将不适用。
If the VPN backbone consists of several cooperating SP networks which support MPLS, then the adjacent networks may support MPLS at their interconnects. If two cooperating SP networks which support MPLS are separated by a third which does not support MPLS, then MPLS-in-IP or MPLS-in-IPsec tunneling may be done between them.
如果VPN主干网由多个支持MPLS的协作SP网络组成，则相邻网络可在其互连处支持MPLS。如果支持MPLS的两个协作SP网络被不支持MPLS的第三个SP网络隔开，则可以在它们之间执行IP中的MPLS或IPsec隧道中的MPLS。
In layer 3 PE-based VPNs, PE devices examine the IP headers of packets they receive from the customer networks. Forwarding is based on routing information received from the customer network. This implies that the PE devices need to participate in some manner in routing for the customer network. Section 3.3 discussed how routing would be done in the customer network, including the customer interface. In this section, we discuss ways in which the routing information from a particular VPN may be passed, over the shared VPN backbone, among the set of PEs attaching to that VPN.
在基于第3层PE的VPN中，PE设备检查从客户网络接收的数据包的IP报头。转发基于从客户网络接收的路由信息。这意味着PE设备需要以某种方式参与客户网络的路由。第3.3节讨论了如何在客户网络中进行路由，包括客户接口。在本节中，我们将讨论通过共享VPN主干在连接到该VPN的一组PE之间传递来自特定VPN的路由信息的方式。
The PEs needs to distribute two types of routing information to each other: (i) Public Routing: routing information which specifies how to reach addresses on the VPN backbone (i.e., "public addresses"); call this "public routing information" (ii) VPN Routing: routing information obtained from the CEs, which specifies how to reach addresses ("private addresses") that are in the VPNs.
PEs需要相互分发两种类型的路由信息：（i）公共路由：指定如何到达VPN主干上地址的路由信息（即“公共地址”）；称之为“公共路由信息”（ii）VPN路由：从CEs获得的路由信息，它指定如何到达VPN中的地址（“专用地址”）。
The way in which routing information in the first category is distributed is outside the scope of this document; we discuss only the distribution of routing information in the second category. Of course, one of the requirements for distributing VPN routing information is that it be kept separate and distinct from the public information. Another requirement is that the distribution of VPN routing information not destabilize or otherwise interfere with the distribution of public routing information.
第一类路由信息的分发方式不在本文件范围内；我们只讨论第二类路由信息的分布。当然，分发VPN路由信息的要求之一是将其与公共信息分开。另一个要求是VPN路由信息的分发不能破坏或干扰公共路由信息的分发。
Similarly, distribution of VPN routing information associated with one VPN should not destabilize or otherwise interfere with the operation of other VPNs. These requirements are, for example, relevant in the case that a private network might be suffering from instability or other problems with its internal routing, which might be propagated to the VPN used to support that private network.
类似地，与一个VPN相关联的VPN路由信息的分发不应破坏或干扰其他VPN的运行。例如，在专用网络可能因其内部路由不稳定或其他问题而受到影响的情况下，这些要求是相关的，这些问题可能会传播到用于支持该专用网络的VPN。
Note that this issue does not arise in CE-based VPNs, as in CE-based VPNs, the PE devices do not see packets from the VPN until after the packets haven been encapsulated in an outer header that has only public addresses.
请注意，此问题在基于CE的VPN中不会出现，因为在基于CE的VPN中，PE设备在数据包被封装在只有公共地址的外部报头中之前不会看到来自VPN的数据包。
The following technologies can be used for exchanging VPN routing information discussed in sections 3.3.1.3 and 4.1.
以下技术可用于交换第3.3.1.3节和第4.1节中讨论的VPN路由信息。
o Static routing
o 静态路由
o RIP [RFC2453]
o RIP[RFC2453]
o OSPF [RFC2328]
o OSPF[RFC2328]
o BGP-4 [RFC1771]
o BGP-4[RFC1771]
In layer 3 PE-based VPNs, the PE devices receive unencapsulated IP packets from the CE devices, and the PE devices use the IP destination addresses in these packets to help make their forwarding decisions. In order to do this properly, the PE devices must obtain routing information from the customer networks. This implies that the PE device participates in some manner in the customer network's routing.
在基于第3层PE的VPN中，PE设备从CE设备接收未封装的IP数据包，并且PE设备使用这些数据包中的IP目的地地址来帮助做出转发决策。为了正确地执行此操作，PE设备必须从客户网络获取路由信息。这意味着PE设备以某种方式参与客户网络的路由。
In layer 3 PE-based VPNs, a single PE device connected to several CE devices that are in the same VPN, and it may also be connected to CE devices of different VPNs. The route which the PE chooses for a given IP destination address in a given packet will depend on the VPN from which the packet was received. A PE device must therefore have a separate forwarding table for each VPN to which it is attached. We refer to these forwarding tables as "VPN Forwarding Instances" (VFIs), as defined in section 2.1.
在基于第3层PE的VPN中，单个PE设备连接到同一VPN中的多个CE设备，也可以连接到不同VPN的CE设备。PE为给定数据包中的给定IP目的地地址选择的路由将取决于从中接收数据包的VPN。因此，PE设备必须为其所连接的每个VPN具有单独的转发表。我们将这些转发表称为“VPN转发实例”（VFI），定义见第2.1节。
A VFI contains routes to locally attached VPN sites, as well as routes to remote VPN sites. Section 4.4 discusses the way in which routes to remote sites are obtained.
VFI包含到本地连接的VPN站点的路由，以及到远程VPN站点的路由。第4.4节讨论了获取远程站点路由的方式。
Routes to local sites may be obtained in several ways. One way is to explicitly configure static routes into the VFI. This can be useful in simple deployments, but it requires that one or more devices in the customer's network be configured with static routes (perhaps just a default route), so that traffic will be directed from the site to the PE device.
可通过多种方式获得通往当地现场的路线。一种方法是显式配置进入VFI的静态路由。这在简单部署中很有用，但它要求客户网络中的一个或多个设备配置静态路由（可能只是默认路由），以便将流量从站点定向到PE设备。
Another way is to have the PE device be a routing peer of the CE device, in a routing algorithm such as RIP, OSPF, or BGP. Depending on the deployment scenario, the PE might need to advertise a large number of routes to each CE (e.g., all the routes which the PE obtained from remote sites in the CE's VPN), or it might just need to advertise a single default route to the CE.
另一种方法是，在诸如RIP、OSPF或BGP的路由算法中，使PE设备成为CE设备的路由对等方。根据部署场景，PE可能需要向每个CE公布大量路由（例如，PE从CE的VPN中的远程站点获得的所有路由），或者可能只需要向CE公布单个默认路由。
A PE device uses some resources in proportion to the number of VFIs that it has, particularly if a distinct dynamic routing protocol instance is associated with each VFI. A PE device also uses some resources in proportion to the total number of routes it supports, where the total number of routes includes all the routes in all its VFIs, and all the public routes. These scaling factors will limit the number of VPNs which a single PE device can support.
PE设备使用的某些资源与其拥有的VFI数量成比例，特别是当不同的动态路由协议实例与每个VFI关联时。PE设备还按照其支持的路由总数的比例使用一些资源，其中路由总数包括其所有VFI中的所有路由以及所有公共路由。这些比例因子将限制单个PE设备可以支持的VPN数量。
When dynamic routing is used between a PE and a CE, it is not necessarily the case that each VFI is associated with a single routing protocol instance. A single routing protocol instance may provide routing information for multiple VFIs, and/or multiple routing protocol instances might provide information for a single VFI. See sections 4.4.3, 4.4.4, 3.3.1, and 3.3.1.3 for details.
当在PE和CE之间使用动态路由时，不一定每个VFI都与单个路由协议实例相关联。单个路由协议实例可为多个VFI提供路由信息，和/或多个路由协议实例可为单个VFI提供信息。详见第4.4.3节、第4.4.4节、第3.3.1节和第3.3.1.3节。
There are several options for how VPN routes are carried between the PEs, as discussed below.
关于如何在PEs之间传输VPN路由，有几种选择，如下所述。
One option is to operate separate instances of routing protocols between the PEs, one instance for each VPN. When this is done, routing protocol packets for each customer network need to be tunneled between PEs. This uses the same tunneling method, and optionally the same tunnels, as is used for transporting VPN user data traffic between PEs.
一个选项是在PEs之间操作路由协议的单独实例，每个VPN一个实例。完成此操作后，每个客户网络的路由协议包需要在PEs之间进行隧道传输。这使用了与在PEs之间传输VPN用户数据流量相同的隧道方法，也可以选择使用相同的隧道。
With per-VPN routing, a distinct routing instance corresponding to each VPN exists within the corresponding PE device. VPN-specific tunnels are set up between PE devices (using the control mechanisms that were discussed in sections 3 and 4). Logically these tunnels are between the VFIs which are within the PE devices. The tunnels then used as if they were normal links between normal routers. Routing protocols for each VPN operate between VFIs and the routers within the customer network.
对于每VPN路由，对应于每个VPN的不同路由实例存在于对应的PE设备中。在PE设备之间建立特定于VPN的隧道（使用第3节和第4节讨论的控制机制）。逻辑上，这些隧道位于PE设备内的VFI之间。然后，这些隧道就像普通路由器之间的普通链路一样使用。每个VPN的路由协议在VFI和客户网络内的路由器之间运行。
This approach establishes, for each VPN, a distinct "control plane" operating across the VPN backbone. There is no sharing of control plane by any two VPNs, nor is there any sharing of control plane by
这种方法为每个VPN建立一个不同的“控制平面”，在VPN主干上运行。任何两个VPN都不共享控制平面，每个VPN也不共享控制平面
the VPN routing and the public routing. With this approach each PE device can logically be thought of as consisting of multiple independent routers.
VPN路由和公共路由。通过这种方法，每个PE设备在逻辑上可以被认为是由多个独立的路由器组成的。
The multiple routing instances within the PE device may be separate processes, or may be in the same process with different data structures. Similarly, there may be mechanisms internal to the PE devices to partition memory and other resources between routing instances. The mechanisms for implementing multiple routing instances within a single physical PE are outside of the scope of this framework document, and are also outside of the scope of other standards documents.
PE设备内的多个路由实例可以是单独的进程，或者可以在具有不同数据结构的同一进程中。类似地，PE设备内部可能存在在路由实例之间划分内存和其他资源的机制。在单个物理PE中实现多个路由实例的机制不在本框架文档的范围内，也不在其他标准文档的范围内。
This approach tends to minimize the explicit interactions between different VPNs, as well as between VPN routing and public routing. However, as long as the independent logical routers share the same hardware, there is some sharing of resources, and interactions are still possible. Also, each independent control plane has its associated overheads, and this can raise issues of scale. For example, the PE device must run a potentially large number of independent routing "decision processes," and must also maintain a potentially very large number of routing adjacencies.
这种方法倾向于最小化不同VPN之间以及VPN路由和公共路由之间的显式交互。然而，只要独立的逻辑路由器共享相同的硬件，就存在一些资源共享，并且交互仍然是可能的。此外，每个独立的控制平面都有其相关的开销，这可能会引起规模问题。例如，PE设备必须运行可能大量的独立路由“决策过程”，并且还必须保持可能大量的路由邻接。
Another option is to use one single instance of a routing protocol for carrying VPN routing information between the PEs. In this method, the routing information for multiple different VPNs is aggregated into a single routing protocol.
另一种选择是使用路由协议的一个实例在PEs之间传输VPN路由信息。在该方法中，多个不同VPN的路由信息被聚合为一个路由协议。
This approach greatly reduces the number of routing adjacencies which the PEs must maintain, since there is no longer any need to maintain more than one such adjacency between a given pair of PEs. If the single routing protocol supports a hierarchical route distribution mechanism (such as BGP's "route reflectors"), the PE-PE adjacencies can be completely eliminated, and the number of backbone adjacencies can be made into a small constant which is independent of the number of PE devices. This improves the scaling properties.
这种方法大大减少了PEs必须保持的路由邻接的数量，因为在给定的PEs对之间不再需要保持多个这样的邻接。如果单一路由协议支持分层路由分配机制（如BGP的“路由反射器”），则PE-PE邻接可以完全消除，并且主干邻接的数量可以成为一个小常数，该常数与PE设备的数量无关。这将改进缩放特性。
Additional routing instances may still be needed to support the exchange of routing information between the PE and its locally attached CEs. These can be eliminated, with a consequent further improvement in scalability, by using static routing on the PE-CE interfaces, or possibly by having the PE-CE routing interaction use the same protocol instance that is used to distribute VPN routes across the VPN backbone (see section 4.4.4.2 for a way to do this).
可能仍然需要额外的路由实例来支持PE与其本地连接的CE之间的路由信息交换。通过在PE-CE接口上使用静态路由，或者可能通过让PE-CE路由交互使用用于在VPN主干上分布VPN路由的相同协议实例，可以消除这些问题，从而进一步提高可伸缩性（有关实现方法，请参阅第4.4.4.2节）。
With this approach, the number of routing protocol instances in a PE device does not depend on the number of CEs supported by the PE device, if the routing between PE and CE devices is static or BGP-4. However, CE and PE devices in a VPN exchange route information inside a VPN using a routing protocol except for BGP-4, the number of routing protocol entities in a PE device depends on the number of CEs supported by the PE device.
通过这种方法，如果PE和CE设备之间的路由是静态的或BGP-4，则PE设备中路由协议实例的数量不取决于PE设备支持的CE数量。然而，VPN中的CE和PE设备使用路由协议（BGP-4除外）在VPN内交换路由信息，PE设备中路由协议实体的数量取决于PE设备支持的CE数量。
In principle it is possible for routing to be aggregated using either BGP or on an IGP.
原则上，可以使用BGP或IGP聚合路由。
When supporting VPNs, it is likely that there can be a large number of VPNs supported within any given SP network. In general only a small number of PE devices will be interested in the operation of any one VPN. Thus while the total amount of routing information related to the various customer networks will be very large, any one PE needs to know about only a small number of such networks.
在支持VPN时，任何给定SP网络中都可能支持大量VPN。一般来说，只有少数PE设备对任何一个VPN的操作感兴趣。因此，尽管与各种客户网络相关的路由信息总量将非常大，但任何一个PE只需要知道少量此类网络。
Generally SP networks use OSPF or IS-IS for interior routing within the SP network. There are very good reasons for this choice, which are outside of the scope of this document.
通常，SP网络使用OSPF或IS-IS在SP网络内进行内部路由。这一选择有很好的理由，超出了本文件的范围。
Both OSPF and IS-IS are link state routing protocols. In link state routing, routing information is distributed via a flooding protocol. The set of routing peers is in general not fully meshed, but there is a path from any router in the set to any other. Flooding ensures that routing information from any one router reaches all the others. This requires all routers in the set to maintain the same routing information. One couldn't withhold any routing information from a particular peer unless it is known that none of the peers further downstream will need that information, and in general this cannot be known.
OSPF和IS-IS都是链路状态路由协议。在链路状态路由中，路由信息通过泛洪协议分发。路由对等点集通常不是完全网格化的，但存在从该集的任何路由器到任何其他路由器的路径。泛洪确保来自任何一个路由器的路由信息到达所有其他路由器。这要求集合中的所有路由器维护相同的路由信息。一个人不能从一个特定的对等点保留任何路由信息，除非知道下游的任何对等点都不需要该信息，通常这是未知的。
As a result, if one tried to do aggregated routing by using OSPF, with all the PEs in the set of routing peers, all the PEs would end up with the exact same routing information; there is no way to constrain the distribution of routing information to a subset of the PEs. Given the potential magnitude of the total routing information required for supporting a large number of VPNs, this would have unfortunate scaling implications.
因此，如果一个人试图使用OSPF进行聚合路由，那么在路由对等点集中的所有PE中，所有PE最终都会得到完全相同的路由信息；无法将路由信息的分布限制到PEs的子集。考虑到支持大量VPN所需的总路由信息的潜在数量，这将带来不幸的扩展影响。
In some cases VPNs may span multiple areas within a provider, or span multiple providers. If VPN routing information were aggregated into the IGP used within the provider, then some method would need to be used to extend the reach of IGP routing information between areas and between SPs.
在某些情况下，VPN可能跨越一个提供商内的多个区域，或跨越多个提供商。如果VPN路由信息聚合到提供商内部使用的IGP中，则需要使用某种方法来扩展区域之间和SP之间IGP路由信息的覆盖范围。
In order to use BGP for aggregated routing, the VPN routing information must be clearly distinguished from the public Internet routing information. This is typically done by making use of BGP's capability of handling multiple address families, and treating the VPN routes as being in a different address family than the public Internet routes. Typically a VPN route also carries attributes which depend on the particular VPN or VPNs to which that route belongs.
为了使用BGP进行聚合路由，VPN路由信息必须与公共Internet路由信息明确区分。这通常是通过利用BGP处理多个地址族的能力来实现的，并将VPN路由视为与公共互联网路由不同的地址族。通常，VPN路由还携带依赖于该路由所属的特定VPN或VPN的属性。
When BGP is used for carrying VPN information, the total amount of information carried in BGP (including the Internet routes and VPN routes) may be quite large. As noted above, there may be a large number of VPNs which are supported by any particular provider, and the total amount of routing information associated with all VPNs may be quite large. However, any one PE will in general only need to be aware of a small number of VPNs. This implies that where VPN routing information is aggregated into BGP, it is desirable to be able to limit which VPN information is distributed to which PEs.
当BGP用于承载VPN信息时，BGP中承载的信息总量（包括互联网路由和VPN路由）可能相当大。如上所述，可能存在由任何特定提供商支持的大量VPN，并且与所有VPN相关联的路由信息总量可能相当大。但是，任何一个PE通常只需要知道少量VPN。这意味着，当VPN路由信息聚合到BGP中时，需要能够限制将哪些VPN信息分发给哪些PE。
In "Interior BGP" (IBGP), routing information is not flooded; it is sent directly, over a TCP connection, to the peer routers (or to a route reflector). These peer routers (unless they are route reflectors) are then not even allowed to redistribute the information to each other. BGP also has a comprehensive set of mechanisms for constraining the routing information that any one peer sends to another, based on policies established by the network administration. Thus IBGP satisfies one of the requirements for aggregated routing within a single SP network - it makes it possible to ensure that routing information relevant to a particular VPN is processed only by the PE devices that attach to that VPN. All that is necessary is that each VPN route be distributed with one or more attributes which identify the distribution policies. Then distribution can be constrained by filtering against these attributes.
在“内部BGP”（IBGP）中，路由信息不会被淹没；它通过TCP连接直接发送到对等路由器（或路由反射器）。这些对等路由器（除非它们是路由反射器）甚至不允许相互重新分发信息。BGP还有一套全面的机制，用于根据网络管理部门制定的策略约束任何一个对等方发送给另一个对等方的路由信息。因此，IBGP满足了单个SP网络中聚合路由的一个要求—它可以确保与特定VPN相关的路由信息仅由连接到该VPN的PE设备处理。所有必要的是，每个VPN路由都要分配一个或多个标识分配策略的属性。然后，可以通过过滤这些属性来约束分布。
In "Exterior BGP" (EBGP), routing peers do redistribute routing information to each other. However, it is very common to constrain the distribution of particular items of routing information so that they only go to those exterior peers who have a "need to know," although this does require a priori knowledge of which paths may validly lead to which addresses. In the case of VPN routing, if a VPN is provided by a small set of cooperating SPs, such constraints can be applied to ensure that the routing information relevant to that VPN does not get distributed anywhere it doesn't need to be. To the extent that a particular VPN is supported by a small number of cooperating SPs with private peering arrangements, this is
在“外部BGP”（EBGP）中，路由对等方相互重新分配路由信息。然而，限制路由信息的特定项的分布是非常常见的，这样它们只会到达那些“需要知道”的外部对等点，尽管这确实需要先验知识，知道哪些路径可以有效地指向哪些地址。在VPN路由的情况下，如果VPN是由一小部分合作SP提供的，则可以应用此类约束以确保与该VPN相关的路由信息不会分布在不需要的任何地方。如果一个特定的VPN由少数具有专用对等安排的合作SP支持，则这是一个简单的解决方案
particularly straightforward, as the set of EBGP neighbors which need to know the routing information from a particular VPN is easier to determine.
特别简单，因为需要知道来自特定VPN的路由信息的EBGP邻居集更容易确定。
BGP also has mechanisms (such as "Outbound Route Filtering," ORF) which enable the proper set of VPN routing distribution constraints to be dynamically distributed. This reduces the management burden of setting up the constraints, and hence improves scalability.
BGP还有一些机制（如“出站路由过滤”，ORF），可以动态地分发一组适当的VPN路由分发约束。这减少了设置约束的管理负担，从而提高了可伸缩性。
Within a single routing domain (in the layer 3 VPN context, this typically means within a single SP's network), it is common to have the IBGP routers peer directly with one or two route reflectors, rather than having them peer directly with each other. This greatly reduces the number of IBGP adjacencies which any one router must support. Further, a route reflector does not merely redistribute routing information, it "digests" the information first, by running its own decision processes. Only routes which survive the decision process are redistributed.
在单个路由域中（在第3层VPN上下文中，这通常意味着在单个SP的网络中），通常让IBGP路由器直接与一个或两个路由反射器对等，而不是让它们直接彼此对等。这大大减少了任何一个路由器必须支持的IBGP邻接的数量。此外，路由反射器不仅重新分配路由信息，它还通过运行自己的决策过程，首先“消化”信息。只有在决策过程中幸存下来的路由才会重新分配。
As a result, when route reflectors are used, the amount of routing information carried around the network, and in particular, the amount of routing information which any given router must receive and process, is greatly reduced. This greatly increases the scalability of the routing distribution system.
结果，当使用路由反射器时，网络中携带的路由信息量，特别是任何给定路由器必须接收和处理的路由信息量，大大减少。这大大提高了路由分发系统的可伸缩性。
It has already been stated that a given PE has VPN routing information only for those PEs to which it is directly attached. It is similarly important, for scalability, to ensure that no single route reflector should have to have all the routing information for all VPNs. It is after all possible for the total number of VPN routes (across all VPNs supported by an SP) to exceed the number which can be supported by a single route reflector. Therefore, the VPN routes may themselves be partitioned, with some route reflectors carrying one subset of the VPN routes and other route reflectors carrying a different subset. The route reflectors which carry the public Internet routes can also be completely separate from the route reflectors that carry the VPN routes.
已经指出，给定的PE仅具有其直接连接到的PE的VPN路由信息。同样重要的是，为了可扩展性，确保没有一个路由反射器必须拥有所有VPN的所有路由信息。毕竟，VPN路由的总数（跨越SP支持的所有VPN）可能会超过单个路由所支持的数目。因此，VPN路由本身可以被划分，一些路由反射器携带VPN路由的一个子集，而其他路由反射器携带不同的子集。承载公共互联网路由的路由反射器也可以与承载VPN路由的路由反射器完全分离。
The use of outbound route filters allows any one PE and any one route reflector to exchange information about only those VPNs which the PE and route reflector are both interested in. This in turn ensures that each PE and each route reflector receives routing information only about the VPNs which it is directly supporting. Large SPs which support a large number of VPNs therefore can partition the information which is required for support of those VPNs.
出站路由过滤器的使用允许任何一个PE和任何一个路由反射器仅交换关于PE和路由反射器都感兴趣的VPN的信息。这进而确保每个PE和每个路由反射器仅接收有关其直接支持的VPN的路由信息。因此，支持大量VPN的大型SP可以对支持这些VPN所需的信息进行分区。
Generally a PE device will be restricted in the total number of routes it can support, whether those are public Internet routes or VPN routes. As a result, a PE device may be able to be attached to a larger number of VPNs if it does not also need to support Internet routes.
一般而言，PE设备将限制其可支持的路由总数，无论这些路由是公共Internet路由还是VPN路由。因此，如果PE设备不需要支持Internet路由，则可以将其连接到更多的VPN。
The way in which VPN routes are partitioned among PEs and/or route reflectors is a deployment issue. With suitable deployment procedures, the limited capacity of these devices will not limit the number of VPNs that can be supported.
在PEs和/或路由反射器之间划分VPN路由的方式是一个部署问题。通过适当的部署程序，这些设备的有限容量将不会限制可支持的VPN数量。
Similarly, whether a given PE and/or route reflector contains Internet routes as well as VPN routes is a deployment issue. If the customer networks served by a particular PE do not need the Internet access, then that PE does not need to be aware of the Internet routes. If some or all of the VPNs served by a particular PE do need the Internet access, but the PE does not contain Internet routes, then the PE can maintain a default route that routes all the Internet traffic from that PE to a different router within the SP network, where that other router holds the full the Internet routing table. With this approach the PE device needs only a single default route for all the Internet routes.
同样，给定的PE和/或路由反射器是否包含Internet路由以及VPN路由也是一个部署问题。如果特定PE服务的客户网络不需要互联网接入，则该PE不需要知道互联网路由。如果特定PE所服务的部分或所有VPN确实需要Internet访问，但该PE不包含Internet路由，则该PE可以维护一条默认路由，将所有Internet流量从该PE路由到SP网络内的另一个路由器，而该另一个路由器持有Internet路由表中的完整数据。使用这种方法，PE设备只需要为所有Internet路由提供一个默认路由。
For the reasons given above, the BGP protocol seems to be a reasonable protocol to use for distributing VPN routing information. Additional reasons for the use of BGP are:
基于上述原因，BGP协议似乎是用于分发VPN路由信息的合理协议。使用BGP的其他原因包括：
o BGP has been proven to be useful for distributing very large amounts of routing information; there isn't any routing distribution protocol which is known to scale any better.
o BGP已被证明对分发大量路由信息非常有用；目前还没有任何已知的可扩展性更好的路由分发协议。
o The same BGP instance that is used for PE-PE distribution of VPN routes can be used for PE-CE route distribution, if CE-PE routing is static or BGP. PEs and CEs are really parts of distinct Autonomous Systems, and BGP is particularly well-suited for carrying routing information between Autonomous Systems.
o 如果CE-PE路由为静态或BGP，则用于VPN路由的PE-PE分发的同一BGP实例可用于PE-CE路由分发。PEs和CEs实际上是不同自治系统的一部分，BGP特别适合在自治系统之间传输路由信息。
On the other hand, BGP is also used for distributing public Internet routes, and it is crucially important that VPN route distributing not compromise the distribution of public Internet routes in any way. This issue is discussed in the following section.
另一方面，BGP也用于分发公共Internet路由，至关重要的是，VPN路由分发不能以任何方式损害公共Internet路由的分发。下一节将讨论此问题。
For layer 3 PE-based VPNs, there are likely to be cases where a service provider supports Internet access over the same link that is used for VPN service. Thus, a particular CE to PE link may carry both private network IP packets (for transmission between sites of the private network using VPN services) as well as public Internet traffic (for transmission from the private site to the Internet, and for transmission to the private site from the Internet). This section looks at the scalability and stability of routing in this case. It is worth noting that this sort of issue may be applicable where per-VPN routing is used, as well as where aggregated routing is used.
对于基于第3层PE的VPN，可能存在服务提供商支持通过用于VPN服务的同一链路进行Internet访问的情况。因此，特定CE-to-PE链路可以携带私有网络IP分组（用于使用VPN服务在私有网络的站点之间传输）以及公共因特网流量（用于从私有站点传输到因特网，以及用于从因特网传输到私有站点）。本节将介绍这种情况下路由的可伸缩性和稳定性。值得注意的是，这类问题可能适用于使用每VPN路由以及使用聚合路由的情况。
For layer 3 PE-based VPNs, it is necessary for the PE devices to be able to forward IP packets using the addresses spaces of the supported private networks, as well as using the full Internet address space. This implies that PE devices might in some cases participate in routing for the private networks, as well as for the public Internet.
对于基于第3层PE的VPN，PE设备必须能够使用受支持的专用网络的地址空间以及完整的Internet地址空间转发IP数据包。这意味着PE设备在某些情况下可能参与专用网络以及公共互联网的路由。
In some cases the routing demand on the PE might be low enough, and the capabilities of the PE, might be great enough, that it is reasonable for the PE to participate fully in routing for both private networks and the public Internet. For example, the PE device might participate in normal operation of BGP as part of the global Internet. The PE device might also operate routing protocols (or in some cases use static routing) to exchange routes with CE devices.
在某些情况下，对PE的路由需求可能足够低，并且PE的能力可能足够大，因此PE完全参与私有网络和公共互联网的路由是合理的。例如，PE设备可以作为全球互联网的一部分参与BGP的正常操作。PE设备还可以操作路由协议（或在某些情况下使用静态路由）与CE设备交换路由。
For large installations, or where PE capabilities are more limited, it may be undesirable for the PE to fully participate in routing for both VPNs as well as the public Internet. For example, suppose that the total volume of routes and routing instances supported by one PE across multiple VPNs is very large. Suppose furthermore that one or more of the private networks suffers from routing instabilities, for example resulting in a large number of routing updates being transmitted to the PE device. In this case it is important to prevent such routing from causing any instability in the routing used in the global Internet.
对于大型安装，或PE能力更有限的地方，PE可能不希望完全参与VPN和公共互联网的路由。例如，假设一个PE跨多个VPN支持的路由和路由实例的总量非常大。此外，假设一个或多个专用网络遭受路由不稳定性，例如导致大量路由更新被发送到PE设备。在这种情况下，重要的是防止此类路由在全球互联网中使用的路由中造成任何不稳定。
In these cases it may be necessary to partition routing, so that the PE does not need to maintain as large a collection of routes, and so that the PE is not able to adversely effect Internet routing. Also, given that the total number of route prefixes and the total number of routing instances which the PE needs to maintain might be very large, it may be desirable to limit the participation in Internet routing for those PEs which are supporting a large number of VPNs or which are supporting large VPNs.
在这些情况下，可能需要对路由进行分区，以便PE不需要维护尽可能多的路由集合，并且使得PE不能对Internet路由产生不利影响。此外，考虑到PE需要维护的路由前缀总数和路由实例总数可能非常大，可能需要限制支持大量VPN或支持大型VPN的PE在Internet路由中的参与。
Consider a case where a PE is supporting a very large number of VPNs, some of which have a large number of sites. To pick a VERY large example, let's suppose 1000 VPNs, with an average of 100 sites each, plus 10 prefixes per site on average. Consider that the PE also needs to be able to route traffic to the Internet in general. In this example the PE might need to support approximately 1,000,000 prefixes for the VPNs, plus more than 100,000 prefixes for the Internet. If augmented and aggregated routing is used, then this implies a large number of routes which may be advertised in a single routing protocol (most likely BGP). If the VR approach is used, then there are also 100,000 neighbor adjacencies in the various per-VPN routing protocol instances. In some cases this number of routing prefixes and/or this number of adjacencies might be difficult to support in one device.
考虑一个PE支持大量VPN的情况，其中一些有大量的站点。举一个非常大的例子，让我们假设1000个VPN，每个VPN平均有100个站点，每个站点平均加上10个前缀。考虑到PE还需要能够将流量路由到因特网上。在此示例中，PE可能需要为VPN支持大约1000000个前缀，再加上为Internet支持100000多个前缀。如果使用增强和聚合路由，则这意味着大量路由可能会在单个路由协议（最有可能是BGP）中公布。如果使用VR方法，则在各种每VPN路由协议实例中也有100000个邻居邻接。在某些情况下，在一个设备中可能难以支持这种数量的路由前缀和/或这种数量的邻接。
In this case, an alternate approach is to limit the PE's participation in Internet routing to the absolute minimum required: Specifically the PE will need to know which Internet address prefixes are reachable via directly attached CE devices. All other Internet routes may be summarized into a single default route pointing to one or more P routers. In many cases the P routers to which the default routes are directed may be the P routers to which the PE device is directly attached (which are the ones which it needs to use for forwarding most Internet traffic). Thus if there are M CE devices directly connected to the PE, and if these M CE devices are the next hop for a total of N globally addressable Internet address prefixes, then the PE device would maintain N+1 routes corresponding to globally routable Internet addresses.
在这种情况下，另一种方法是将PE在Internet路由中的参与限制在所需的绝对最小值：具体而言，PE需要知道哪些Internet地址前缀可通过直接连接的CE设备访问。所有其他互联网路由可归纳为指向一个或多个P路由器的单一默认路由。在许多情况下，默认路由所指向的P路由器可以是PE设备直接连接到的P路由器（它们是它需要用于转发大多数因特网流量的路由器）。因此，如果有M个CE设备直接连接到PE，并且如果这些M个CE设备是总共N个全局可寻址因特网地址前缀的下一跳，则PE设备将保持与全局可路由因特网地址对应的N+1个路由。
In this example, those PE devices which provide VPN service run routing to compute routes for the VPNs, but don't operate Internet routing, and instead use only a default route to route traffic to all Internet destinations (not counting the addresses which are reachable via directly attached CE devices). The P routers need to maintain Internet routes, and therefore take part in Internet routing protocols. However, the P routers don't know anything about the VPN routes.
在此示例中，那些提供VPN服务的PE设备运行路由以计算VPN的路由，但不运行Internet路由，而是仅使用默认路由将流量路由到所有Internet目的地（不计算可通过直接连接的CE设备访问的地址）。P路由器需要维护Internet路由，因此参与Internet路由协议。然而，P路由器对VPN路由一无所知。
In some cases the maximum number of routes and/or routing instances supportable via a single PE device may limit the number of VPNs which can be supported by that PE. For example, in some cases this might require that two different PE devices be used to support VPN services for a set of multiple CEs, even if one PE might have had sufficient throughput to handle the data traffic from the full set of CEs. Similarly, the amount of resources which any one VPN is permitted to use in a single PE might be restricted.
在某些情况下，可通过单个PE设备支持的最大路由数和/或路由实例数可能会限制该PE可支持的VPN数。例如，在某些情况下，这可能需要使用两个不同的PE设备来支持一组多个CE的VPN服务，即使一个PE可能有足够的吞吐量来处理来自全组CE的数据流量。类似地，任何一个VPN允许在单个PE中使用的资源量可能会受到限制。
There will be cases where it is not necessary to partition the routing, since the PEs will be able to maintain all VPN routes and all Internet routes without a problem. However, it is important that VPN approaches allow partitioning to be used where needed in order to prevent future scaling problems. Again, making the system scalable is a matter of proper deployment.
在某些情况下，不需要对路由进行分区，因为PEs将能够维护所有VPN路由和所有互联网路由而不会出现问题。然而，重要的是VPN方法允许在需要的地方使用分区，以防止将来的扩展问题。同样，使系统具有可伸缩性是正确部署的问题。
It may be wondered whether it is ever desirable to have both Internet routing and VPN routing running in a single PE device or route reflector. In fact, if there is even a single system running both Internet routing and VPN routing, doesn't that raise the possibility that a disruption within the VPN routing system will cause a disruption within the Internet routing system?
人们可能想知道，在单个PE设备或路由反射器中同时运行Internet路由和VPN路由是否是可取的。事实上，如果有一个系统同时运行Internet路由和VPN路由，这难道不增加VPN路由系统内的中断将导致Internet路由系统内的中断的可能性吗？
Certainly this possibility exists in theory. To minimize that possibility, BGP implementations which support multiple address families should be organized so as to minimize the degree to which the processing and distribution of one address family affects the processing and distribution of another. This could be done, for example, by suitable partitioning of resources. This partitioning may be helpful both to protect Internet routing from VPN routing, and to protect well behaved VPN customers from "mis-behaving" VPNs. Or one could try to protect the Internet routing system from the VPN routing system by giving preference to the Internet routing. Such implementation issues are outside the scope of this document. If one has inadequate confidence in an implementation, deployment procedures can be used, as explained above, to separate the Internet routing from the VPN routing.
当然，这种可能性在理论上是存在的。为了最大限度地减少这种可能性，应该组织支持多个地址族的BGP实现，以便最大程度地减少一个地址族的处理和分发对另一个地址族的处理和分发的影响。例如，这可以通过适当的资源分区来实现。这种分区可能有助于保护Internet路由不受VPN路由的影响，也有助于保护行为良好的VPN客户不受“行为不当”的VPN的影响。或者可以通过优先选择Internet路由来保护Internet路由系统不受VPN路由系统的影响。此类实施问题不在本文件范围内。如果对实现信心不足，可以使用部署过程（如上所述）将Internet路由与VPN路由分离。
The following technologies for QoS/SLA may be applicable to PPVPNs.
以下QoS/SLA技术可能适用于PPVPN。
Integrated services, or IntServ for short, is a mechanism for providing QoS/SLA by admission control. RSVP is used to reserve network resources. The network needs to maintain a state for each reservation. The number of states in the network increases in proportion to the number of concurrent reservations.
综合服务，简称IntServ，是一种通过准入控制提供QoS/SLA的机制。RSVP用于保留网络资源。网络需要为每个预订维护一个状态。网络中的状态数与同时保留的数量成比例增加。
In some cases, IntServ on the edge of a network (e.g., over the customer interface) may be mapped to DiffServ in the SP network.
在某些情况下，网络边缘上的IntServ（例如，通过客户接口）可以映射到SP网络中的DiffServ。
IP differentiated service, or DiffServ for short, is a mechanism for providing QoS/SLA by differentiating traffic. Traffic entering a network is classified into several behavior aggregates at the network edge and each is assigned a corresponding DiffServ codepoint. Within the network, traffic is treated according to its DiffServ codepoint. Some behavior aggregates have already been defined. Expedited forwarding behavior [RFC3246] guarantees the QoS, whereas assured forwarding behavior [RFC2597] differentiates traffic packet precedence values.
IP区分服务，简称DiffServ，是一种通过区分流量来提供QoS/SLA的机制。进入网络的流量在网络边缘被划分为几个行为集合，每个行为集合被分配一个相应的DiffServ码点。在网络中，流量根据其DiffServ码点进行处理。已经定义了一些行为聚合。加速转发行为[RFC3246]保证QoS，而保证转发行为[RFC2597]区分流量包优先级值。
When DiffServ is used, network provisioning is done on a per-traffic-class basis. This ensures a specific class of service can be achieved for a class (assuming that the traffic load is controlled). All packets within a class are then treated equally within an SP network. Policing is done at input to prevent any one user from exceeding their allocation and therefore defeating the provisioning for the class as a whole. If a user exceeds their traffic contract, then the excess packets may optionally be discarded, or may be marked as "over contract". Routers throughout the network can then preferentially discard over contract packets in response to congestion, in order to ensure that such packets do not defeat the service guarantees intended for in contract traffic.
当使用DiffServ时，网络配置是基于每个流量类别进行的。这确保了可以为一个类实现特定的服务类（假设流量负载得到控制）。然后，一个类中的所有数据包在SP网络中被同等对待。在输入时执行监控，以防止任何一个用户超过其分配，从而破坏整个类的资源调配。如果用户超过了他们的流量契约，那么多余的分组可以选择性地被丢弃，或者可以被标记为“过度契约”。然后，网络中的路由器可以优先丢弃超过合约的分组以响应拥塞，以确保此类分组不会破坏针对合约内业务的服务保证。
In some scenarios, customers will need to concurrently have access to their VPN network and to the public Internet.
在某些情况下，客户需要同时访问其VPN网络和公共互联网。
Two potential problems are identified in this scenario: the use of private addresses and the potential security threads.
在这个场景中发现了两个潜在的问题：私有地址的使用和潜在的安全线程。
o The use of private addresses
o 私人地址的使用
The IP addresses used in the customer's sites will possibly belong to a private routing realm, and as such be unusable in the public Internet. This means that a network address translation function (e.g., NAT) will need to be implemented to allow VPN customers to access the Public Internet.
客户站点中使用的IP地址可能属于私有路由领域，因此在公共Internet中无法使用。这意味着需要实现网络地址转换功能（例如NAT），以允许VPN客户访问公共互联网。
In the case of layer 3 PE-based VPNs, this translation function will be implemented in the PE to which the CE device is connected. In the case of layer 3 provider-provisioned CE-based VPNs, this translation function will be implemented on the CE device itself.
对于基于第3层PE的VPN，此转换功能将在CE设备连接的PE中实现。对于第3层提供商提供的基于CE的VPN，此转换功能将在CE设备本身上实现。
o Potential security threat
o 潜在安全威胁
As portions of the traffic that flow to and from the public Internet are not necessarily under the SP's nor the customer's control, some traffic analyzing function (e.g., a firewall function) will be implemented to control the traffic entering and leaving the VPN.
由于进出公共互联网的部分流量不一定受SP或客户的控制，因此将实施一些流量分析功能（例如防火墙功能）来控制进出VPN的流量。
In the case of layer 3 PE-based VPNs, this traffic analyzing function will be implemented in the PE device (or in the VFI supporting a specific VPN), while in the case of layer 3 provider provisioned CE-based VPNs, this function will be implemented in the CE device.
对于基于第3层PE的VPN，此流量分析功能将在PE设备（或支持特定VPN的VFI）中实现，而对于基于第3层提供商的CE VPN，此功能将在CE设备中实现。
o Handling of a customer IP packet destined for the Internet
o 处理发往Internet的客户IP数据包
In the case of layer 3 PE-based VPNs, an IP packet coming from a customer site will be handled in the corresponding VFI. If the IP destination address in the packet's IP header belongs to the Internet, multiple scenarios are possible, based on the adapted policy. As a first possibility, when Internet access is not allowed, the packet will be dropped. As a second possibility, when (controlled) Internet access is allowed, the IP packet will go through the translation function and eventually through the traffic analyzing function before further processing in the PE's global Internet forwarding table.
对于基于第3层PE的VPN，来自客户站点的IP数据包将在相应的VFI中处理。如果包的IP报头中的IP目的地地址属于因特网，则基于所适应的策略，可能出现多种情况。作为第一种可能性，当不允许访问Internet时，数据包将被丢弃。作为第二种可能性，当允许（受控）互联网访问时，IP数据包将通过翻译功能，最终通过流量分析功能，然后在PE的全局互联网转发表中进行进一步处理。
Note that different implementation choices are possible. One can choose to implement the translation and/or the traffic analyzing function in every VFI (or CE device in the context of layer 3 provider-provisioned CE-based VPNs), or alternatively in a subset or even in only one VPN network element. This would mean that the traffic to/from the Internet from/to any VPN site needs to be routed through that single network element (this is what happens in a hub and spoke topology for example).
请注意，不同的实现选择是可能的。可以选择在每个VFI（或在第3层提供商提供的基于CE的VPN的上下文中的CE设备）中实现转换和/或流量分析功能，或者在子集中或者甚至仅在一个VPN网元中实现。这意味着从Internet到任何VPN站点的流量都需要通过单个网元进行路由（例如，在中心辐射拓扑中就是这样）。
Network and customer management systems responsible for managing VPN networks have several challenges depending on the type of VPN network or networks they are required to manage.
负责管理VPN网络的网络和客户管理系统有几个难题，具体取决于VPN网络的类型或它们需要管理的网络。
For any type of provider-provisioned VPN it is useful to have one place where the VPN can be viewed and optionally managed as a whole. The NMS may therefore be a place where the collective instances of a VPN are brought together into a cohesive picture to form a VPN. To
对于任何类型的提供商提供的VPN，有一个地方可以查看VPN并作为一个整体进行管理是非常有用的。因此，NMS可以是VPN的集合实例聚集在一起形成一个内聚图以形成VPN的地方。到
be more precise, the instances of a VPN on their own do not form the VPN; rather, the collection of disparate VPN sites together forms the VPN. This is important because VPNs are typically configured at the edges of the network (i.e., PEs) either through manual configuration or auto-configuration. This results in no state information being kept in within the "core" of the network. Sometimes little or no information about other PEs is configured at any particular PE.
更准确地说，VPN实例本身并不构成VPN；相反，不同VPN站点的集合一起形成VPN。这一点很重要，因为VPN通常通过手动配置或自动配置在网络边缘（即PEs）进行配置。这导致网络的“核心”中没有状态信息。有时，在任何特定PE上配置的其他PE信息很少或没有。
Support of any one VPN may span a wide range of network equipment, potentially including equipment from multiple implementors. Allowing a unified network management view of the VPN therefore is simplified through use of standard management interfaces and models. This will also facilitate customer self-managed (monitored) network devices or systems.
对任何一个VPN的支持都可能跨越广泛的网络设备，可能包括来自多个实施者的设备。因此，通过使用标准管理接口和模型，可以简化VPN的统一网络管理视图。这也将有助于客户自行管理（监控）网络设备或系统。
In cases where significant configuration is required whenever a new service is provisioned, it is important for scalability reasons that the NMS provide a largely automated mechanism for this operation. Manual configuration of VPN services (i.e., new sites, or re-provisioning existing ones), could lead to scalability issues, and should be avoided. It is thus important for network operators to maintain visibility of the complete picture of the VPN through the NMS system. This must be achieved using standard protocols such as SNMP, XML, or LDAP. Use of proprietary command-line interfaces has the disadvantage that proprietary interfaces do not lend themselves to standard representations of managed objects.
在每当提供新服务时都需要进行重要配置的情况下，出于可扩展性的原因，NMS为该操作提供一个基本上自动化的机制是很重要的。手动配置VPN服务（即新站点或重新配置现有站点）可能会导致可伸缩性问题，应避免。因此，对于网络运营商来说，通过NMS系统保持VPN全貌的可见性非常重要。这必须使用标准协议（如SNMP、XML或LDAP）来实现。使用专用命令行接口的缺点是，专用接口不适用于托管对象的标准表示。
To achieve the goals outlined above for network and customer management, device implementors should employ standard management interfaces to expose the information required to manage VPNs. To this end, devices should utilize standards-based mechanisms such as SNMP, XML, or LDAP to achieve this goal.
为实现上述网络和客户管理目标，设备实施者应使用标准管理接口公开管理VPN所需的信息。为此，设备应利用基于标准的机制（如SNMP、XML或LDAP）来实现这一目标。
Segregated access of VPNs information is important in that customers sometimes require access to information in several ways. First, it is important for some customers (or operators) to access PEs, CEs or P devices within the context of a particular VPN on a per-VPN-basis in order to access statistics, configuration or status information. This can either be under the guise of general management, operator-initiated provisioning, or SLA verification (SP, customer or operator).
VPN信息的隔离访问非常重要，因为客户有时需要以多种方式访问信息。首先，对于一些客户（或运营商）来说，重要的是在每个VPN的基础上访问特定VPN上下文中的PEs、CEs或P设备，以便访问统计数据、配置或状态信息。这可以以一般管理、运营商发起的供应或SLA验证（SP、客户或运营商）的名义进行。
Where users outside of the SP have access to information from PE or P devices, managed objects within the managed devices must be accessible on a per-VPN basis in order to provide the customer, the SP or the third party SLA verification agent with a high degree of security and convenience.
如果SP之外的用户可以访问PE或P设备中的信息，则受管设备中的受管对象必须基于每个VPN进行访问，以便为客户、SP或第三方SLA验证代理提供高度的安全性和便利性。
Security may require authentication or encryption of network management commands and information. Information hiding may use encryption or may isolate information through a mechanism that provides per-VPN access. Authentication or encryption of both requests and responses for managed objects within a device may be employed. Examples of how this can be achieved include IPsec tunnels, SNMPv3 encryption for SNMP-based management, or encrypted telnet sessions for CLI-based management.
安全性可能需要对网络管理命令和信息进行身份验证或加密。信息隐藏可以使用加密，也可以通过提供每VPN访问的机制隔离信息。可以采用对设备内的托管对象的请求和响应的认证或加密。实现这一点的示例包括IPsec隧道、用于基于SNMP的管理的SNMPv3加密，或用于基于CLI的管理的加密telnet会话。
In the case of information isolation, any one customer should only be able to view information pertaining to its own VPN or VPNs. Information isolation can also be used to partition the space of managed objects on a device in such a way as to make it more convenient for the SP to manage the device. In certain deployments, it is also important for the SP to have access to information pertaining to all VPNs, thus it may be important for the SP to create virtual VPNs within the management domain which overlap across existing VPNs.
在信息隔离的情况下，任何一个客户都只能查看与其自己的VPN或VPN相关的信息。信息隔离还可用于划分设备上受管对象的空间，从而使SP更方便地管理设备。在某些部署中，SP访问与所有VPN相关的信息也很重要，因此SP在管理域中创建虚拟VPN可能很重要，虚拟VPN与现有VPN重叠。
If the user is allowed to change the configuration of their VPN, then in some cases customers may make unanticipated changes or even mistakes, thereby causing their VPN to mis-behave. This in turn may require an audit trail to allow determination of what went wrong and some way to inform the carrier of the cause.
如果允许用户更改其VPN的配置，则在某些情况下，客户可能会做出意外的更改甚至错误，从而导致其VPN出现错误行为。这反过来可能需要一个审计跟踪，以确定出什么地方出了问题，并以某种方式通知承运人原因。
The segregation and security access of information on a per-VPN basis is also important when the carrier of carrier's paradigm is employed. In this case it may be desirable for customers (i.e., sub-carriers or VPN wholesalers) to manage and provision services within their VPNs on their respective devices in order to reduce the management overhead cost to the carrier of carrier's SP. In this case, it is important to observe the guidelines detailed above with regard to information hiding, isolation and encryption. It should be noted that there may be many flavors of information hiding and isolation employed by the carrier of carrier's SP. If the carrier of carriers SP does not want to grant the sub-carrier open access to all of the managed objects within their PEs or P routers, it is necessary for devices to provide network operators with secure and scalable per-VPN network management access to their devices. For the reasons outlined above, it therefore is desirable to provide standard mechanisms for achieving these goals.
当采用运营商的模式时，基于每个VPN的信息隔离和安全访问也很重要。在这种情况下，客户（即子运营商或VPN批发商）可能希望在其各自设备上的VPN内管理和提供服务，以降低运营商SP运营商的管理开销成本。在这种情况下，必须遵守上述有关信息隐藏、隔离和加密的指导原则。应注意的是，运营商SP的运营商可能采用多种信息隐藏和隔离方式。如果运营商SP的运营商不想授予子运营商对其PEs或P路由器内所有受管对象的开放访问权，设备必须为网络运营商提供对其设备的安全且可扩展的每VPN网络管理访问。因此，出于上述原因，最好提供实现这些目标的标准机制。
This section describes interworking between different layer 3 VPN approaches. This may occur either within a single SP network, or at an interface between SP networks.
本节介绍不同的第3层VPN方法之间的互通。这可能发生在单个SP网络内，也可能发生在SP网络之间的接口上。
Figure 2.5 (see section 2.1.3) illustrates a case where one or more PE devices sits at the logical interface between two different layer 3 VPN approaches. With this approach the interworking function occurs at a PE device which participates in two or more layer 3 VPN approaches. This might be physically located at the boundary between service providers, or might occur at the logical interface between different approaches within a service provider.
图2.5（见第2.1.3节）说明了一种情况，其中一个或多个PE设备位于两个不同的第3层VPN方法之间的逻辑接口处。通过这种方法，互通功能发生在参与两个或更多第3层VPN方法的PE设备上。这可能在物理上位于服务提供者之间的边界上，或者可能发生在服务提供者内不同方法之间的逻辑接口上。
With layer 3 VPNs, the PE devices are in general layer 3 routers, and are able to forward layer 3 packets on behalf of one or more private networks. For example, it may be common for a PE device supporting layer 3 VPNs to contain multiple logical VFIs (sections 1, 2, 3.3.1, 4.4.2) each of which supports forwarding and routing for a private network.
对于第3层VPN，PE设备通常是第3层路由器，并且能够代表一个或多个专用网络转发第3层数据包。例如，支持第3层VPN的PE设备通常包含多个逻辑VFI（第1、2、3.3.1、4.4.2节），每个逻辑VFI都支持专用网络的转发和路由。
The PE which implements an interworking function needs to participate in the normal manner in the operation of multiple approaches for supporting layer 3 VPNs. This involves the functions discussed elsewhere in this document, such as VPN establishment and maintenance, VPN tunneling, routing for the VPNs, and QoS maintenance.
实现互通功能的PE需要以正常方式参与支持第3层VPN的多种方式的操作。这涉及本文档其他地方讨论的功能，如VPN建立和维护、VPN隧道、VPN路由和QoS维护。
VPN establishment and maintenance information, as well as VPN routing information will need to be passed between VPN approaches. This might involve passing of information between approaches as part of the interworking function. Optionally this might involve manual configuration so that, for example, all of the participants in the VPN on one side of the interworking function considers the PE performing the interworking function to be the point to use to contact a large number of systems (comprising all systems supported by the VPN located on the other side of the interworking function).
VPN建立和维护信息以及VPN路由信息需要在VPN方法之间传递。这可能涉及在方法之间传递信息，作为互通功能的一部分。可选地，这可能涉及手动配置，以便例如，在互通功能一侧的VPN中的所有参与者将执行互通功能的PE视为用于联系大量系统的点（包括位于互通功能另一侧的VPN支持的所有系统）。
Figure 2.6 (see section 2.1.3) illustrates a case where interworking is performed by use of tunnels between PE devices. In this case each PE device participates in the operation of one layer 3 VPN approach. Interworking between approaches makes use of per-VPN tunnels set up between PE. Each PEs operates as if it is a normal PEs, and considers each tunnel to be associated with a particular VPN.
图2.6（见第2.1.3节）说明了通过使用PE设备之间的隧道进行互通的情况。在这种情况下，每个PE设备都参与一个第3层VPN方法的操作。方法之间的互通利用PE之间建立的每VPN隧道。每个PEs都像正常PEs一样运行，并将每个隧道视为与特定VPN关联。
Information can then be transmitted over the interworking interface in the same manner that it is transmitted over a CE to PE interface.
然后，信息可以通过互通接口进行传输，传输方式与通过CE-to-PE接口进行传输的方式相同。
In some cases establishment of the interworking interfaces may require manual configuration, for example to allow each PE to determine which tunnels should be set up, and which private network is associated with each tunnel.
在某些情况下，建立互通接口可能需要手动配置，例如允许每个PE确定应设置哪些隧道，以及哪个专用网络与每个隧道相关联。
In order to implement an interworking interface between two SP networks for supporting one or more PPVPN spanning both SP networks, a mechanism for exchanging customer data as well as associated control data (e.g., routing data) should be provided.
为了实现两个SP网络之间的互通接口，以支持跨越两个SP网络的一个或多个PPVPN，应提供交换客户数据以及相关控制数据（例如路由数据）的机制。
Since PEs of SP networks to be interworked may only communicate over a network cloud, an appropriate tunnel established through the network cloud will be used for exchanging data associated with the PPVPN realized by interworked SP networks.
由于要互通的SP网络的PE只能通过网络云进行通信，因此通过网络云建立的适当隧道将用于交换与互通SP网络实现的PPVPN相关的数据。
In this way, each interworking tunnel is assigned to an associated layer 3 PE-based VPN; in other words, a tunnel is terminated by a VFI (associated with the PPVPN) in a PE device. This scenario results in implementation of traffic isolation for PPVPNs supported by an Interworking Interface and spanning multiple SP networks (in each SP network, there is no restriction in applied technology for providing PPVPN so that both sides may adopt different technologies). The way of the assignment of each tunnel for a PE-based VPN is specific to implementation technology used by the SP network that is inter-connected to the tunnel at the PE device.
这样，每个互通隧道被分配给相关联的基于第3层PE的VPN；换句话说，隧道由PE设备中的VFI（与PPVPN关联）终止。该场景导致由互通接口支持并跨越多个SP网络的PPVPN实现流量隔离（在每个SP网络中，提供PPVPN的应用技术没有限制，因此双方可以采用不同的技术）。为基于PE的VPN分配每个隧道的方式特定于SP网络使用的实现技术，该SP网络在PE设备处与隧道互连。
The identifier of layer 3 PE-based VPN at each end is meaningful only in the context of the specific technology of an SP network and need not be understood by another SP network interworking through the tunnel.
每端基于第3层PE的VPN的标识符仅在SP网络的特定技术上下文中有意义，并且不需要被通过隧道互通的另一SP网络理解。
The following tunneling mechanisms may be used at the interworking interface. Available tunneling mechanisms include (but are not limited to): GRE, IP-in-IP, IP over ATM, IP over FR, IPsec, and MPLS.
以下隧道机制可用于互通接口。可用的隧道机制包括（但不限于）：GRE、IP中的IP、ATM上的IP、FR上的IP、IPsec和MPLS。
o GRE
o GRE
The tunnels at interworking interface may be provided by GRE [RFC2784] with key and sequence number extensions [RFC2890].
互通接口处的隧道可由GRE[RFC2784]提供，带有密钥和序列号扩展[RFC2890]。
o IP-in-IP
o IP中的IP
The tunnels at interworking interface may be provided by IP-in-IP [RFC2003] [RFC2473].
互通接口处的隧道可由IP[RFC2003][RFC2473]中的IP提供。
o IP over ATM AAL5
o ATM AAL5上的IP
The tunnels at interworking interface may be provided by IP over ATM AAL5 [RFC2684] [RFC2685].
互通接口处的隧道可由ATM AAL5[RFC2684][RFC2685]上的IP提供。
o IP over FR
o IP over FR
The tunnels at interworking interface may be provided by IP over FR.
互通接口处的隧道可由IP over FR提供。
o IPsec
o IPsec
The tunnels at interworking interface may be provided by IPsec [RFC2401] [RFC2402].
互通接口处的隧道可由IPsec[RFC2401][RFC2402]提供。
o MPLS
o MPLS
The tunnels at interworking interface may be provided by MPLS [RFC3031] [RFC3035].
互通接口处的隧道可由MPLS[RFC3031][RFC3035]提供。
This subsection describes additional usages for supporting QoS/SLA, customer visible routing, and customer visible multicast routing, as services of layer 3 PE-based VPNs spanning multiple SP networks.
本小节描述了支持QoS/SLA、客户可见路由和客户可见多播路由的其他用途，作为跨越多个SP网络的基于第3层PE的VPN的服务。
o QoS/SLA
o 服务质量/服务级别协议
QoS/SLA management mechanisms for GRE, IP-in-IP, IPsec, and MPLS tunnels were discussed in sections 4.3.6 and 4.5. See these sections for details. FR and ATM are capable of QoS guarantee. Thus, QoS/SLA may also be supported at the interworking interface.
第4.3.6和4.5节讨论了GRE、IP中的IP、IPsec和MPLS隧道的QoS/SLA管理机制。有关详细信息，请参见这些部分。FR和ATM具有QoS保证能力。因此，也可以在互通接口处支持QoS/SLA。
o Customer visible routing
o 客户可见路由
As described in section 3.3, customer visible routing enables the exchange of unicast routing information between customer sites using a routing protocol such as OSPF, IS-IS, RIP, and BGP-4. On the interworking interface, routing packets, such as OSPF packets, are transmitted through a tunnel associated with a layer 3 PE-based VPN in the same manner as that for user data packets within the VPN.
如第3.3节所述，客户可见路由允许使用路由协议（如OSPF、IS-IS、RIP和BGP-4）在客户站点之间交换单播路由信息。在互通接口上，诸如OSPF分组之类的路由分组以与VPN内的用户数据分组相同的方式通过与基于第3层PE的VPN相关联的隧道传输。
o Customer visible multicast routing
o 客户可见多播路由
Customer visible multicast routing enables the exchange of multicast routing information between customer sites using a routing protocol such as DVMRP and PIM. On the interworking interface, multicast routing packets are transmitted through a tunnel associated with a layer 3 PE-based VPN in the same manner as that for user data packets within the VPN. This enables a multicast tree construction within the layer 3 PE-based VPN.
客户可见多播路由允许使用路由协议（如DVMRP和PIM）在客户站点之间交换多播路由信息。在互通接口上，以与VPN内的用户数据分组相同的方式，通过与基于第3层PE的VPN相关联的隧道传输多播路由分组。这使得在基于第3层PE的VPN中能够构建多播树。
This subsection discusses scalability aspect of the interworking scenario.
本小节讨论互通场景的可伸缩性方面。
o Number of routing protocol instances
o 路由协议实例数
In the interworking scenario discussed in this section, the number of routing protocol instances and that of layer 3 PE-based VPNs are the same. However, the number of layer 3 PE-based VPNs in a PE device is limited due to resource amount and performance of the PE device. Furthermore, each tunnel is expected to require some bandwidth, but total of the bandwidth is limited by the capacity of a PE device; thus, the number of the tunnels is limited by the capabilities of the PE. This limit is not a critical drawback.
在本节讨论的互通场景中，路由协议实例的数量与基于第3层PE的VPN的数量相同。然而，由于PE设备的资源量和性能，PE设备中基于第3层PE的VPN的数量受到限制。此外，每个隧道预期需要一些带宽，但总带宽受到PE设备容量的限制；因此，隧道的数量受到PE能力的限制。这一限制不是一个严重的缺点。
o Performance of packet transmission
o 分组传输性能
The interworking scenario discussed in this section does not place any additional burden on tunneling technologies used at interworking interface. Since performance of packet transmission depends on a tunneling technology applied, it should be carefully selected when provisioning interworking. For example, IPsec places computational requirements for encryption/decryption.
本节讨论的互通场景不会对互通接口处使用的隧道技术造成任何额外负担。由于数据包传输的性能取决于应用的隧道技术，所以在提供互通时应仔细选择。例如，IPsec对加密/解密提出了计算要求。
Security is one of the key requirements concerning VPNs. In network environments, the term security currently covers many different aspects of which the most important from a networking perspective are shortly discussed hereafter.
安全性是VPN的关键要求之一。在网络环境中，术语安全性目前涵盖了许多不同的方面，下文将从网络的角度简要讨论其中最重要的方面。
Note that the Provider-Provisioned VPN requirements document explains the different security requirements for Provider-Provisioned VPNs in more detail.
请注意，提供商提供的VPN要求文档更详细地解释了提供商提供的VPN的不同安全要求。
Like in every network environment, system security is the most important security aspect that must be enforced. Care must be taken that no unauthorized party can gain access to the network elements that control the VPN functionality (e.g., PE and CE devices).
与所有网络环境一样，系统安全是必须实施的最重要的安全方面。必须注意，未经授权的一方不能访问控制VPN功能的网络元件（如PE和CE设备）。
As the VPN customers are making use of the shared SP's backbone, the SP must ensure the system security of its network elements and management systems.
由于VPN客户正在使用共享SP的主干网，SP必须确保其网元和管理系统的系统安全。
When a network or parts of a network are private, one of the requirements is that access to that network (part) must be restricted to a limited number of well-defined customers. To accomplish this requirement, the responsible authority must control every possible access to the network.
当一个网络或网络的一部分是私有的时，其中一个要求是对该网络（部分）的访问必须限于有限数量的定义明确的客户。为了实现这一要求，责任机构必须控制对网络的所有可能访问。
In the context of PE-based VPNs, the access points to a VPN must be limited to the interfaces that are known by the SP.
在基于PE的VPN环境中，VPN的接入点必须限于SP已知的接口。
When one receives data from a certain entity, one would like to be sure of the identity of the sending party. One would like to be sure that the sending entity is indeed whom he or she claims to be, and that the sending entity is authorized to reach a particular destination.
当一个人从某个实体接收数据时，他希望确定发送方的身份。人们希望确保发送实体确实是他或她声称的人，并且发送实体被授权到达特定目的地。
In the context of layer 3 PE-based VPNs, both the data received by the PEs from the customer sites via the SP network and destined for a customer site should be authenticated.
在基于第3层PE的VPN环境中，PEs通过SP网络从客户站点接收并发送到客户站点的数据都应经过身份验证。
Note that different methods for authentication exist. In certain circumstances, identifying incoming packets with specific customer interfaces might be sufficient. In other circumstances, (e.g., in temporary access (dial-in) scenarios), a preliminary authentication phase might be requested. For example, when PPP is used. Or alternatively, an authentication process might need to be present in every data packet transmitted (e.g., in remote access via IPsec).
请注意，存在不同的身份验证方法。在某些情况下，识别具有特定客户接口的传入数据包可能就足够了。在其他情况下（例如，在临时访问（拨入）场景中），可能会请求初步身份验证阶段。例如，当使用PPP时。或者，认证过程可能需要存在于传输的每个数据包中（例如，在通过IPsec的远程访问中）。
For layer 3 PE-based VPNs, VPN traffic is tunneled from PE to PE and the VPN tunnel endpoint will check the origin of the transmitted packet. When MPLS is used for VPN tunneling, the tunnel endpoint
对于基于第3层PE的VPN，VPN流量通过隧道从PE传输到PE，VPN隧道端点将检查传输数据包的来源。当MPLS用于VPN隧道时，隧道端点
checks whether the correct labels are used. When IPsec is used for VPN tunneling, the tunnel endpoint can make use of the IPsec authentication mechanisms.
检查是否使用了正确的标签。当IPsec用于VPN隧道时，隧道端点可以利用IPsec身份验证机制。
In the context of layer 3 provider-provisioned CE-based VPNs, the endpoint authentication is enforced by the CE devices.
在第3层提供商提供的基于CE的VPN环境中，端点身份验证由CE设备实施。
When information is exchanged over a certain part of a network, one would like to be sure that the information that is received by the receiving party of the exchange is identical to the information that was sent by the sending party of the exchange.
当通过网络的某个部分交换信息时，希望确保交换的接收方接收的信息与交换的发送方发送的信息相同。
In the context of layer 3 PE-based VPNs, the SP assures the data integrity by ensuring the system security of every network element. Alternatively, explicit mechanisms may be implemented in the used tunneling technique (e.g., IPsec).
在基于第3层PE的VPN环境中，SP通过确保每个网元的系统安全来确保数据完整性。或者，可以在所使用的隧道技术（例如，IPsec）中实现显式机制。
In the context of layer 3 provider-provisioned CE-based VPNs, the underlying network that will tunnel the encapsulated packets will not always be of a trusted nature, and the CE devices that are responsible for the tunneling will also ensure the data integrity, e.g., by making use of the IPsec architecture.
在第3层提供商提供的基于CE的vpn的上下文中，将对封装的分组进行隧道传输的底层网络并不总是具有受信任的性质，并且负责隧道传输的CE设备也将确保数据完整性，例如，通过使用IPsec架构。
One would like that the information that is being sent from one party to another is not received and not readable by other parties. With traffic flow confidentiality one would like that even the characteristics of the information sent is hidden from third parties. Data privacy is the confidentiality of the user data.
人们希望，从一方发送到另一方的信息不会被其他方接收，也不会被其他方读取。对于流量保密性，人们希望即使发送的信息的特征也对第三方隐藏。数据隐私是用户数据的机密性。
In the context of PPVPNs, confidentiality is often seen as the basic service offered, as the functionalities of a private network are offered over a shared infrastructure.
在PPVPN的上下文中，保密性通常被视为提供的基本服务，因为专用网络的功能是通过共享基础设施提供的。
In the context of layer 3 PE-based VPNs, as the SP network (and more precisely the PE devices) participates in the routing and forwarding of the customer VPN data, it is the SP's responsibility to ensure confidentiality. The technique used in PE-based VPN solutions is the ensuring of PE to PE data separation. By implementing VFI's in the PE devices and by tunneling VPN packets through the shared network infrastructure between PE devices, the VPN data is always kept in a separate context and thus separated from the other data.
在基于第3层PE的VPN中，由于SP网络（更准确地说是PE设备）参与客户VPN数据的路由和转发，因此SP有责任确保机密性。基于PE的VPN解决方案中使用的技术是PE-to-PE数据分离的保证。通过在PE设备中实现VFI以及通过PE设备之间共享网络基础设施的隧道VPN数据包，VPN数据始终保持在单独的上下文中，从而与其他数据分离。
In some situations, this data separation might not be sufficient. Circumstances where the VPN tunnel traverses other than only trusted and SP controlled network parts require stronger confidentiality measures such as cryptographic data encryption. This is the case in certain inter-SP VPN scenarios or when the considered SP is on itself a client of a third party network provider.
在某些情况下，这种数据分离可能不够。VPN隧道穿越受信任和SP控制的网络部件之外的情况需要更强的保密措施，如加密数据加密。在某些SP间VPN场景中，或者当所考虑的SP本身是第三方网络提供商的客户端时，就会出现这种情况。
For layer 3 provider-provisioned CE-based VPNs, the SP network does not bare responsibility for confidentiality assurance, as the SP just offers IP connectivity. The confidentiality will then be enforced at the CE and will lie in the tunneling (data separation) or in the cryptographic encryption (e.g., using IPsec) by the CE device.
对于第3层提供商提供的基于CE的VPN，SP网络不承担保密性保证的责任，因为SP只提供IP连接。然后，保密性将在CE强制执行，并将存在于CE设备的隧道（数据分离）或加密（例如，使用IPsec）中。
Note that for very sensitive user data (e.g., used in banking operations) the VPN customer may not outsource his data privacy enforcement to a trusted SP. In those situations, PE-to-PE confidentiality will not be sufficient and end-to-end cryptographic encryption will be implemented by the VPN customer on its own private equipment (e.g., using CE-based VPN technologies or cryptographic encryption over the provided VPN connectivity).
请注意，对于非常敏感的用户数据（例如，用于银行业务），VPN客户可能不会将其数据隐私实施外包给受信任的SP。在这些情况下，PE-to-PE保密性将不充分，VPN客户将在其自己的专用设备上实施端到端加密（例如，在提供的VPN连接上使用基于CE的VPN技术或加密）。
An important remark is the fact that both the user data and the VPN control data must be protected.
一个重要的注意事项是，用户数据和VPN控制数据都必须受到保护。
Previous subsections were focused on the protection of the user data, but all the control data (e.g., used to set up the VPN tunnels, used to configure the VFI's or the CE devices (in the context of layer 3 provider-provisioned CE-based VPNs)) will also be secured by the SP to prevent deliberate misconfiguration of provider-provisioned VPNs.
前面的小节侧重于用户数据的保护，但所有控制数据（例如，用于设置VPN隧道、用于配置VFI或CE设备（在第3层提供商提供的基于CE的VPN环境中））也将由SP进行保护，以防止提供商提供的VPN的故意错误配置。
In certain scenarios, a single VPN will need to cross multiple SPs.
在某些情况下，单个VPN需要跨多个SP。
The fact that the edge-to-edge part of the data path does not fall under the control of the same entity can have security implications, for example with regards to endpoint authentication.
数据路径的边到边部分不在同一实体的控制之下这一事实可能会产生安全影响，例如关于端点身份验证。
Another point is that the SPs involved must closely interact to avoid conflicting configuration information on VPN network elements (such as VFIs, PEs, CE devices) connected to the different SPs.
另一点是，涉及的SP必须密切交互，以避免连接到不同SP的VPN网络元素（如VFI、PEs、CE设备）上的配置信息冲突。
Appendix A: Optimizations for Tunnel Forwarding
附录A：隧道转发的优化
If layer 3 PE-based VPNs are implemented in the most straightforward manner, then it may be necessary for PE devices to perform multiple header lookups in order to forward a single data packet. This section discusses an example of how multiple lookups might be needed with the most straightforward implementation. Optimizations which might optionally be used to reduce the number of lookups are discussed in the following sections.
如果以最直接的方式实现基于第3层PE的VPN，则PE设备可能需要执行多个报头查找以转发单个数据包。本节讨论一个示例，说明在最简单的实现中可能需要多个查找。下面几节将讨论可用于减少查找次数的优化。
As an example, in many cases a tunnel may be set up between VFIs within PEs for support of a given VPN. When a packet arrives at the egress PE, the PE may need to do a lookup on the outer header to determine which VFI the packet belongs to. The PE may then need to do a second lookup on the packet that was encapsulated across the VPN tunnel, using the forwarding table specific to that VPN, before forwarding the packet.
例如，在许多情况下，可以在PEs内的VFI之间建立隧道，以支持给定的VPN。当分组到达出口PE时，PE可能需要在外部报头上进行查找以确定分组属于哪个VFI。然后，在转发分组之前，PE可能需要使用特定于该VPN的转发表对通过VPN隧道封装的分组进行第二次查找。
For scaling reasons it may be desired in some cases to set up VPN tunnels, and then multiplex multiple VPN-specific tunnels within the VPN tunnels.
出于扩展原因，在某些情况下可能需要设置VPN隧道，然后在VPN隧道内多路传输多个VPN特定隧道。
This implies that in the most straightforward implementation three header lookups might be necessary in a single PE device: One lookup may identify that this is the end of the VPN tunnel (implying the need to strip off the associated header). A second lookup may identify that this is the end of the VPN-specific tunnel. This lookup will result in stripping off the second encapsulating header, and will identify the VFI context for the final lookup. The last lookup will make use of the IP address space associated with the VPN, and will result in the packet being forwarded to the correct CE within the correct VPN.
这意味着在最直接的实现中，在单个PE设备中可能需要三个报头查找：一个查找可能会确定这是VPN隧道的终点（意味着需要剥离相关的报头）。第二次查找可能会确定这是VPN特定隧道的结束。此查找将导致剥离第二个封装头，并为最终查找标识VFI上下文。最后一次查找将使用与VPN关联的IP地址空间，并将导致数据包转发到正确VPN内的正确CE。
Penultimate hop popping is an optimization which is described in the MPLS architecture document [RFC3031].
倒数第二跳弹出是MPLS体系结构文档[RFC3031]中描述的一种优化。
Consider the egress node of any MPLS LSP. The node looks at the label, and discovers that it is the last node. It then strips off the label header, and looks at the next header in the packet (which may be an IP header, or which may have another MPLS header in the case that hierarchical nesting of LSPs is used). For the last node on the LSP, the outer MPLS header doesn't actually convey any useful information (except for one situation discussed below).
考虑任何MPLS LSP的出口节点。节点查看标签，发现它是最后一个节点。然后，它剥离标签头，并查看数据包中的下一个头（可能是IP头，或者在使用LSP分层嵌套的情况下，可能有另一个MPLS头）。对于LSP上的最后一个节点，外部MPLS报头实际上并不传递任何有用的信息（下面讨论的一种情况除外）。
For this reason, the MPLS standards allow the egress node to request that the penultimate node strip the MPLS header. If requested, this implies that the penultimate node does not have a valid label for the LSP, and must strip the MPLS header. In this case, the egress node receives the packet with the corresponding MPLS header already stripped, and can forward the packet properly without needing to strip the header for the LSP which ends at that egress node.
因此，MPLS标准允许出口节点请求倒数第二个节点剥离MPLS报头。如果请求，这意味着倒数第二个节点没有LSP的有效标签，必须剥离MPLS头。在这种情况下，出口节点接收具有已剥离的相应MPLS报头的分组，并且可以正确地转发分组，而无需剥离在该出口节点处结束的LSP的报头。
There is one case in which the MPLS header conveys useful information: This is in the case of a VPN-specific LSP terminating at a PE device. In this case, the value of the label tells the PE which LSP the packet is arriving on, which in turn is used to determine which VFI is used for the packet (i.e., which VPN-specific forwarding table needs to be used to forward the packet).
有一种情况下，MPLS报头传递有用的信息：这是在特定于VPN的LSP终止于PE设备的情况下。在这种情况下，标签的值告诉PE分组到达哪个LSP，而该LSP又用于确定哪个VFI用于分组（即，需要使用哪个VPN特定的转发表来转发分组）。
However, consider the case where multiple VPN-specific LSPs are multiplexed inside one PE-to-PE LSP. Also, let's suppose that in this case the egress PE has chosen all incoming labels (for all LSPs) to be unique in the context of that PE. This implies that the label associated with the PE-to-PE LSP is not needed by the egress node. Rather, it can determine which VFI to use based on the VPN-specific LSP. In this case, the egress PE can request that the penultimate LSR performs penultimate label popping for the PE-to-PE LSP. This eliminates one header lookup in the egress LSR.
然而，考虑多个VPN特定LSP在一个PE内复用到PE LSP的情况。另外，我们假设在这种情况下，出口PE选择了所有传入标签（对于所有LSP）在该PE的上下文中是唯一的。这意味着出口节点不需要与PE-to-PE LSP关联的标签。相反，它可以根据特定于VPN的LSP确定使用哪个VFI。在这种情况下，出口PE可以请求倒数第二LSR为PE到PE LSP执行倒数第二标签弹出。这消除了出口LSR中的一个报头查找。
Note that penultimate node label popping is only applicable for VPN standards which use multiple levels of LSPs. Even in this case penultimate node label popping is only done when the egress node specifically requests it from the penultimate node.
请注意，倒数第二个节点标签弹出仅适用于使用多级LSP的VPN标准。即使在这种情况下，倒数第二个节点标签弹出也仅在出口节点从倒数第二个节点明确请求时进行。
Consider a VPN standard which makes use of MPLS as the tunneling mechanism. Any standard for encapsulating VPN traffic inside LSPs needs to specify what degree of granularity is available in terms of the manner in which user data traffic is assigned to LSPs. In other words, for any given LSP, the ingress or egress PE device needs to know which LSPs need to be set up, and the ingress PE needs to know which set of VPN packets are allowed to be mapped to any particular LSP.
考虑采用MPLS作为隧道机制的VPN标准。在LSP中封装VPN流量的任何标准都需要指定在用户数据流量分配给LSP的方式方面可用的粒度。换句话说，对于任何给定的LSP，入口或出口PE设备需要知道需要设置哪些LSP，并且入口PE需要知道允许哪组VPN分组映射到任何特定LSP。
Suppose that a VPN standard allows some flexibility in terms of the mapping of packets to LSPs, and suppose that the standard allows the egress node to determine the granularity. In this case the egress node would need to have some way to indicate the granularity to the ingress node, so that the ingress node will know which packets can be mapped to each LSP.
假设VPN标准允许在包到LSP的映射方面具有一定的灵活性，并且假设该标准允许出口节点确定粒度。在这种情况下，出口节点需要有某种方式来指示入口节点的粒度，以便入口节点将知道哪些分组可以映射到每个LSP。
In this case, the egress node might decide to have packets mapped to LSPs in a manner which simplifies the header lookup function at the egress node. For example, the egress node could determine which set of packets it will forward to a particular neighbor CE device. The egress node can then specify that the set of IP packets which are to use a particular LSP correspond to that specific set of packets. For packets which arrive on the specified LSP, the egress node does not need to do a header lookup on the VPN's customer address space: It can just pop the MPLS header and forward the packet to the appropriate CE device. If all LSPs are set up accordingly, then the egress node does not need to do any lookup for VPN traffic which arrives on LSPs from other PEs (in other words, the PE device will not need to do a second lookup in its role as an egress node).
在这种情况下，出口节点可以决定以简化出口节点处的报头查找功能的方式将分组映射到lsp。例如，出口节点可以确定它将转发给特定邻居CE设备的分组集。出口节点然后可以指定要使用特定LSP的IP分组集合对应于该特定分组集合。对于到达指定LSP的数据包，出口节点不需要在VPN的客户地址空间上执行报头查找：它只需弹出MPLS报头并将数据包转发到适当的CE设备。如果所有LSP都被相应地设置，则出口节点不需要对从其他PE到达LSP的VPN流量进行任何查找（换句话说，PE设备将不需要在其作为出口节点的角色中进行第二次查找）。
Note that PE devices will most likely also be an ingress routers for traffic going in the other direction. The PE device will need to do an address lookup in the customer network's address space in its role as an ingress node. However, in this direction the PE still needs to do only a single header lookup.
请注意，PE设备也很可能是另一个方向流量的入口路由器。作为入口节点，PE设备需要在客户网络的地址空间中进行地址查找。然而，在这个方向上，PE仍然只需要执行一个标头查找。
When used with MPLS tunnels, this optional optimization reduces the need for header lookups, at the cost of possibly increasing the number of label values which need to be assigned (since one label would need to be assigned for each next-hop CE device, rather than just one label for every VFI).
当与MPLS隧道一起使用时，这种可选的优化减少了报头查找的需要，代价是可能增加需要分配的标签值的数量（因为需要为每个下一跳CE设备分配一个标签，而不是为每个VFI分配一个标签）。
The same approach is also possible when other encapsulations are used, such as GRE [RFC2784] [RFC2890], IP-in-IP [RFC2003] [RFC2473], or IPsec [RFC2401] [RFC2402]. This requires that distinct values are used for the multiplexing field in the tunneling protocol. See section 4.3.2 for detail.
当使用其他封装时，例如GRE[RFC2784][RFC2890]、IP-in-IP[rfc203][RFC2473]或IPsec[RFC2401][RFC2402]，也可以使用相同的方法。这要求隧道协议中的多路复用字段使用不同的值。详见第4.3.2节。
Acknowledgments
致谢
This document is output of the framework document design team of the PPVPN WG. The members of the design team are listed in the "contributors" and "author's addresses" sections below.
本文档是PPVPN工作组框架文档设计团队的输出。下面的“贡献者”和“作者地址”部分列出了设计团队的成员。
However, sources of this document are based on various inputs from colleagues of authors and contributors. We would like to thank Junichi Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano, Naoto Makinae, Kenichi Kitami, Rajesh Balay, Anoop Ghanwani, Harpreet Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and Abbie Matthews.
然而，本文件的来源基于作者和贡献者同事的各种输入。我们要感谢住本纯一、铃木康生、黑水博、滨野高文、马金奈直藤、北部贤一、拉杰什·巴拉伊、阿努普·甘瓦尼、哈普里特·查达、萨米尔·贾因、梁和茹、维杰·斯里尼瓦桑和艾比·马修斯。
We would also like to thank Yakov Rekhter, Scott Bradner, Dave McDysan, Marco Carugi, Pascal Menezes, Thomas Nadeau, and Alex Zinin for their valuable comments and suggestions.
我们还要感谢亚科夫·雷克特、斯科特·布拉德纳、戴夫·麦克迪桑、马可·卡鲁吉、帕斯卡·梅内泽斯、托马斯·纳多和亚历克斯·齐宁提出的宝贵意见和建议。
Normative References
规范性引用文件
[PPVPN-REQ] Nagarajan, A., Ed., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[PPVPN-REQ]Nagarajan，A.，编辑，“提供商提供的虚拟专用网络（PPVPN）的一般要求”，RFC 3809，2004年6月。
[L3VPN-REQ] Carugi, M., Ed. and D. McDysan, Ed., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[L3VPN-REQ]Carugi，M.，Ed.和D.McDysan，Ed.，“第3层提供商提供的虚拟专用网络（PPVPN）的服务要求”，RFC 4031，2005年4月。
Informative References
资料性引用
[BGP-COM] Sangli, S., et al., "BGP Extended Communities Attribute", Work In Progress, February 2005.
[BGP-COM]Sangli，S.等人，“BGP扩展社区属性”，正在进行的工作，2005年2月。
[MPLS-DIFF-TE] Le Faucheur, F., Ed., "Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering", Work In Progress, December 2004.
[MPLS-DIFF-TE]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，正在进行的工作，2004年12月。
[VPN-2547BIS] Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.
[VPN-2547BIS]Rosen，E.等人，“BGP/MPLS VPN”，正在进行中。
[VPN-BGP-OSPF] Rosen, E., et al., "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs", Work In Progress, May 2005.
[VPN-BGP-OSPF]Rosen，E.等人，“OSPF作为BGP/MPLS IP VPN的提供商/客户边缘协议”，正在进行的工作，2005年5月。
[VPN-CE] De Clercq, J., et al., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work In Progress.
[VPN-CE]De Clercq，J.等人，“使用IPsec的基于提供商提供的CE的虚拟专用网络的体系结构”，正在进行中。
[VPN-DISC] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs," Work In Progress.
[VPN-DISC]Ould Brahim，H.等人，“使用BGP作为第3层和第2层VPN的自动发现机制”，工作正在进行中。
[VPN-L2] Andersson, L. and E. Rosen, Eds., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Work In Progress.
[VPN-L2]Andersson，L.和E.Rosen，编辑，“第二层虚拟专用网络（L2VPN）框架”，正在进行中。
[VPN-VR] Knight, P., et al., "Network based IP VPN Architecture Using Virtual Routers", Work In Progress, July 2002.
[VPN-VR]Knight，P.等人，“使用虚拟路由器的基于网络的IP VPN体系结构”，正在进行的工作，2002年7月。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年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月。
[RFC1966] Bates, T., "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC1966]Bates，T.，“BGP路由反射：全网格IBGP的替代方案”，RFC 1966，1996年6月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, February 2001.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，2001年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]Mankin，A.，Ed.，Baker，F.，Braden，B.，Bradner，S.，O'Dell，M.，Romanow，A.，Weinrib，A.，和L.Zhang，“资源保留协议（RSVP）第1版适用性声明—部署的一些指南”，RFC 2208，1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1994.
[RFC2453]Malkin，G.“RIP版本2”，STD 56，RFC 2453，1994年11月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 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月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation Over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[RFC2685] Fox B. and B. Gleeson, "Virtual Private Networks Identifier," RFC 2685, September 1999.
[RFC2685]Fox B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764]Gleeson，B.，Lin，A.，Heinanen，J.，Armitage，G.，和A.Malis，“基于IP的虚拟专用网络框架”，RFC 2764，2000年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858]Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 2858，2000年6月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 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月。
[RFC3032] Rosen E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]Davie，B.，Lawrence，J.，McCloghrie，K.，Rosen，E.，Swallow，G.，Rekhter，Y.，和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, June 1996.
[RFC3065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 3065，1996年6月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.R.，Benson，K.，Le Boudec，J.Y.，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月。
[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月。
Contributors' Addresses
投稿人地址
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium
Jeremy De Clercq Alcatel Fr.Welleslein 2018年1月1日比利时安特卫普
EMail: jeremy.de_clercq@alcatel.be
EMail: jeremy.de_clercq@alcatel.be
Bryan Gleeson Nokia 313 Fairchild Drive, Mountain View, CA 94043 USA.
布莱恩·格雷森诺基亚313飞兆半导体大道，美国加利福尼亚州山景城，邮编94043。
EMail: bryan.gleeson@nokia.com
EMail: bryan.gleeson@nokia.com
Andrew G. Malis Tellabs 90 Rio Robles Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市里约热内卢·罗伯斯大道90号安德鲁·G·马里斯·特拉伯斯，邮编95134
EMail: andy.malis@tellabs.com
EMail: andy.malis@tellabs.com
Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886, USA
美国马萨诸塞州韦斯特福德罗宾斯路1号Karthik Muthukrishnan-Lucent Technologies，邮编01886
EMail: mkarthik@lucent.com
EMail: mkarthik@lucent.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719, USA
Eric C.Rosen Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Chandru Sargor Redback Networks 300 Holger Way San Jose, CA 95134, USA
美国加利福尼亚州圣何塞霍尔格路300号Chandru Sargor Redback Networks，邮编95134
EMail: apricot+l3vpn@redback.com
EMail: apricot+l3vpn@redback.com
Jieyun Jessica Yu University of California, Irvine 5201 California Ave., Suite 150, Irvine, CA, 92697 USA
杰云杰西卡禹加利福尼亚大学，尔湾5201加利福尼亚大道，套房150，CA尔湾，美国92697
EMail: jyy@uci.edu
EMail: jyy@uci.edu
Authors' Addresses
作者地址
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146, USA
美国马萨诸塞州韦斯特福德科技园大道10号罗斯凯伦Juniper Networks 01886-3146
EMail: rcallon@juniper.net
EMail: rcallon@juniper.net
Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
Muneyoshi铃木NTT信息共享平台实验室。3-9-11，日本东京武藏野市Midori cho，180-8585
EMail: suzuki.muneyoshi@lab.ntt.co.jp
EMail: suzuki.muneyoshi@lab.ntt.co.jp
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 gement
RFC编辑器功能的资金目前由Internet gement提供