Network Working Group E. Rosen
Request for Comments: 4365 Cisco Systems, Inc.
Category: Informational February 2006
Network Working Group E. Rosen
Request for Comments: 4365 Cisco Systems, Inc.
Category: Informational February 2006
Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP虚拟专用网络（VPN）的适用性声明
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section.
本文档提供了RFC 4364中描述的虚拟专用网络（VPN）解决方案的适用性声明以及参考资料部分列出的其他文档。
Table of Contents
目录
1. Introduction ....................................................2
2. SP Provisioning Model ...........................................4
3. Supported Topologies and Traffic Types ..........................6
4. Isolated Exchange of Data and Routing Information ...............7
5. Access Control and Authentication ...............................9
6. Security Considerations .........................................9
6.1. Protection of User Data ....................................9
6.2. SP Security Measures ......................................10
6.3. Security Framework Template ...............................12
7. Addressing .....................................................18
8. Interoperability and Interworking ..............................19
9. Network Access .................................................19
9.1. Physical/Link Layer Topology ..............................19
9.2. Temporary Access ..........................................19
9.3. Access Connectivity .......................................20
10. Service Access ................................................21
10.1. Internet Access ..........................................21
10.2. Other Services ...........................................21
11. SP Routing ....................................................22
12. Migration Impact ..............................................22
13. Scalability ...................................................23
14. QoS, SLA ......................................................26
1. Introduction ....................................................2
2. SP Provisioning Model ...........................................4
3. Supported Topologies and Traffic Types ..........................6
4. Isolated Exchange of Data and Routing Information ...............7
5. Access Control and Authentication ...............................9
6. Security Considerations .........................................9
6.1. Protection of User Data ....................................9
6.2. SP Security Measures ......................................10
6.3. Security Framework Template ...............................12
7. Addressing .....................................................18
8. Interoperability and Interworking ..............................19
9. Network Access .................................................19
9.1. Physical/Link Layer Topology ..............................19
9.2. Temporary Access ..........................................19
9.3. Access Connectivity .......................................20
10. Service Access ................................................21
10.1. Internet Access ..........................................21
10.2. Other Services ...........................................21
11. SP Routing ....................................................22
12. Migration Impact ..............................................22
13. Scalability ...................................................23
14. QoS, SLA ......................................................26
15. Management ....................................................27
15.1. Management by the Provider ...............................27
15.2. Management by the Customer ...............................28
16. Acknowledgements ..............................................28
17. Normative References ..........................................29
18. Informative References ........................................29
15. Management ....................................................27
15.1. Management by the Provider ...............................27
15.2. Management by the Customer ...............................28
16. Acknowledgements ..............................................28
17. Normative References ..........................................29
18. Informative References ........................................29
This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in [BGP-MPLS-IP-VPN] and other documents listed in the References section. We refer to these as "BGP/MPLS IP VPNs", because Border Gateway Protocol (BGP) is used to distribute the routes, and Multiprotocol Label Switching (MPLS) is used to indicate that particular packets need to follow particular routes. The characteristics of BGP/MPLS IP VPNs are compared with the requirements specified in [L3VPN-REQS].
本文件提供了[BGP-MPLS-IP-VPN]中描述的虚拟专用网络（VPN）解决方案的适用性声明以及参考资料部分列出的其他文件。我们称之为“BGP/MPLS IP VPN”，因为边界网关协议（BGP）用于分发路由，而多协议标签交换（MPLS）用于指示特定数据包需要遵循特定路由。BGP/MPLS IP VPN的特性与[L3VPN-REQS]中规定的要求进行了比较。
A VPN service is provided by a Service Provider (SP) to a customer (sometimes referred to as an enterprise). BGP/MPLS IP VPNs are intended for the situation in which:
VPN服务由服务提供商（SP）向客户（有时称为企业）提供。BGP/MPLS IP VPN适用于以下情况：
- The customer:
- 客户：
* uses the VPN only for carrying IP packets.
* 仅将VPN用于承载IP数据包。
* does not want to manage a routed backbone; the customer may be using routing within his sites, but wishes to outsource the inter-site routing to the SP.
* 不希望管理路由主干网；客户可能在其站点内使用路由，但希望将站点间路由外包给SP。
* wants the SP to make the backbone and its routing completely transparent to the customer's own routing.
* 希望SP使主干网及其路由对客户自己的路由完全透明。
If the customer has a routed infrastructure at his sites, he does not want his site routing algorithms to need to be aware of any part of the SP backbone network, other than the Provider Edge (PE) routers to which the sites are attached. In particular, the customer does not want his routers to need to be aware of either the native structure of the SP backbone or an overlay topology of tunnels through the SP backbone.
如果客户在其站点上有路由基础设施，他不希望其站点路由算法需要知道SP主干网的任何部分，但站点所连接的提供商边缘（PE）路由器除外。特别是，客户不希望他的路由器需要知道SP主干的本机结构或通过SP主干的隧道的覆盖拓扑。
- The Service Provider:
- 服务供应商：
* has an IP backbone, with MPLS-enabled edge routers, and possibly (though not necessarily) with MPLS-enabled core routers.
* 具有IP主干网，支持MPLS的边缘路由器，以及可能（尽管不一定）支持MPLS的核心路由器。
* wants to provide a service that meets the customer requirements above.
* 希望提供满足上述客户要求的服务。
* does not want to maintain a distinct overlay topology of tunnels for each customer.
* 不希望为每个客户维护不同的隧道覆盖拓扑。
The basic principle is to model each VPN as a self-contained "internet", where each site makes one or more access connections to an SP, sends the SP its routing information, and then relies on the SP to distribute routing information to and from the other sites in that same VPN. The service differs from Internet service, however, in that the SP strictly controls the distribution of this routing information so that routes from within a VPN are not sent outside the VPN, unless that is explicitly authorized by the customer. In fact, even within the VPN, the distribution of routes may be controlled by the SP so as to meet some policy of the customer.
基本原则是将每个VPN建模为一个自包含的“internet”，其中每个站点与SP建立一个或多个访问连接，向SP发送其路由信息，然后依靠SP向同一VPN中的其他站点分发路由信息。但是，该服务与Internet服务的不同之处在于，SP严格控制此路由信息的分发，以便VPN内的路由不会发送到VPN外，除非客户明确授权。事实上，即使在VPN中，路由的分布也可能由SP控制，以满足客户的某些策略。
The routers at a given customer site need not be routing peers of the routers at other customer sites, and indeed need not know anything about the internal structure of other customer sites. In fact, different routing protocols may run at the different sites, with each site using whatever protocol is most appropriate for that particular site.
给定客户站点上的路由器不需要是其他客户站点上的路由器的路由对等方，并且确实不需要知道任何关于其他客户站点的内部结构的信息。事实上，不同的路由协议可能在不同的站点上运行，每个站点使用最适合该特定站点的任何协议。
If EBGP (the BGP procedures used between BGP speakers from different Autonomous Systems) is used on the access links that connect a Provider Edge router (PE router) to a Customer Edge router (CE router), then the SP and the customer do NOT peer in any Interior Gateway Protocol (IGP), i.e., intra-domain routing algorithm).
如果在将提供商边缘路由器（PE路由器）连接到客户边缘路由器（CE路由器）的接入链路上使用EBGP（来自不同自治系统的BGP扬声器之间使用的BGP过程），则SP和客户不在任何内部网关协议（IGP）（即域内路由算法）中对等。
BGP/MPLS IP VPNs are optimized for the situation in which a customer (an enterprise) expects a service provider to operate and maintain the customer's "backbone" (i.e., the customer's inter-site routing). As such, the service provider becomes a "business partner" of the enterprise. The technical mechanisms accommodate the case in which a number of closely cooperating SPs can jointly offer the VPN service to a customer, in that the BGP-based route distribution mechanisms can operate between different SPs. If a set of SPs has sufficient agreements with respect to Quality of Service (QoS), Service Level Agreement (SLA), etc., then the customer's VPN could have sites attached to different SPs from that set.
BGP/MPLS IP VPN针对客户（企业）希望服务提供商操作和维护客户的“主干”（即客户的站点间路由）的情况进行了优化。因此，服务提供商成为企业的“业务合作伙伴”。技术机制适应了许多密切合作的SP可以联合向客户提供VPN服务的情况，因为基于BGP的路由分配机制可以在不同SP之间运行。如果一组SP在服务质量（QoS）、服务级别协议（SLA）等方面有足够的协议，则客户的VPN可以将站点连接到该组不同的SP。
[BGP-MPLS-IP-VPN] specifies the inter-AS (Autonomous System) mechanisms that allow a single VPN to have sites attached to different SPs. However, the design center is not an environment where a given VPN is spread among a very large number (e.g., hundreds) of SPs.
[BGP-MPLS-IP-VPN]指定允许单个VPN将站点连接到不同SP的AS（自治系统）间机制。但是，设计中心不是一个给定VPN分布在大量SP（例如，数百个）中的环境。
In cases where remote offices, individual telecommuters, etc., must use the public Internet to access the VPN, it is possible to "tunnel" the remote traffic to a PE router, and the PE router will treat the traffic as if it had arrived over an interface connected to the PE. Remote Point-to-Point Protocol (PPP) connections can be tunneled via Layer 2 Tunneling Protocol (L2TP) to a PE router; IPsec tunnels can also be used to tunnel traffic to a PE router across the public Internet. Of course, when the public Internet is used, issues such as QoS and SLAs must be carefully considered.
在远程办公室、个人远程工作者等必须使用公共互联网访问VPN的情况下，可以将远程通信“隧道”到PE路由器，并且PE路由器会将通信视为通过连接到PE的接口到达。远程点对点协议（PPP）连接可以通过第二层隧道协议（L2TP）隧道到PE路由器；IPsec隧道还可用于通过公共Internet将流量隧道到PE路由器。当然，在使用公共互联网时，必须仔细考虑QoS和SLA等问题。
Some customers want to connect their sites over the public Internet, creating a VPN "virtual backbone", purchasing connectivity for a given site from whatever Internet Service Provider (ISP) offers the best price for connecting that site. A BGP/MPLS IP VPN is not an appropriate solution for such customers; they instead need to consider solutions (either customer-managed or provider-managed) that interconnect their sites via an overlay of secure tunnels across the Internet. (See, for example, [IPSEC-VPN].)
一些客户希望通过公共互联网连接他们的站点，创建一个VPN“虚拟主干网”，从互联网服务提供商（ISP）提供的连接该站点的最佳价格购买给定站点的连接。BGP/MPLS IP VPN不是适合此类客户的解决方案；相反，他们需要考虑解决方案（客户管理或提供者管理），通过互联网上安全隧道的覆盖来互连他们的站点。（例如，请参见[IPSEC-VPN]。）
Some customers who do not want to connect their sites via secure site-to-site tunnels across the Internet may nevertheless want to maintain complete control over the routing in their VPN backbone. These customers will not want a "managed routing service" such as is provided by BGP/MPLS IP VPNs, since that hides all details of the backbone routing and topology from the customer. Rather, they may prefer a "virtual router" service, in which the tunnels through the SP networks are visible as links to the customer's routing algorithm. (See, for example, [VR-VPN].)
一些不希望通过Internet上的安全站点到站点隧道连接其站点的客户可能仍然希望对其VPN主干中的路由保持完全控制。这些客户不会想要BGP/MPLS IP VPN提供的“托管路由服务”，因为这会对客户隐藏主干路由和拓扑的所有细节。相反，他们可能更喜欢“虚拟路由器”服务，在该服务中，通过SP网络的隧道作为指向客户路由算法的链接可见。（例如，参见[VR-VPN]。）
If a particular VPN attaches to a particular PE router, the SP must configure that PE router with a VPN Routing and Forwarding table (VRF), a routing table that is specific to the specified VPN. (This is known as a VPN Forwarding Instance (VFI) in the language of [L3VPN-REQS] and [L3VPN-FRMWRK].) Each interface or sub-interface at that PE that attaches to a site in the specified VPN (i.e., each local access link of that VPN) must be configured so as to be associated with that VRF. Each such interface may be unnumbered or may be assigned an address that is unique within the VPN's address space. In general, a routing algorithm needs to be run on each of these links (though static routing can be used instead). The routing algorithm can be EBGP, or an IGP such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). (IF OSPF is used, the procedures of [VPN-OSPF] MUST be implemented.) If an IGP is run on the access links, the IGP MUST be a separate IGP instance, different
如果特定VPN连接到特定PE路由器，SP必须使用VPN路由和转发表（VRF）配置该PE路由器，该表是特定于指定VPN的路由表。（在[L3VPN-REQS]和[L3VPN-FRMWRK]的语言中称为VPN转发实例（VFI）。该PE上连接到指定VPN中站点的每个接口或子接口（即该VPN的每个本地访问链路）必须进行配置，以便与该VRF相关联。每个这样的接口可以不编号，或者可以分配一个在VPN地址空间内唯一的地址。通常，路由算法需要在每个链路上运行（尽管可以使用静态路由）。路由算法可以是EBGP，也可以是IGP，如路由信息协议（RIP）或开放最短路径优先（OSPF）。（如果使用OSPF，则必须执行[VPN-OSPF]的过程。）如果在接入链路上运行IGP，则IGP必须是单独的IGP实例，不同
than the IGP instance running among the backbone routers, and different than the IGP instance running on the access links of any other VPN. Static routing is also allowed.
不同于在主干路由器之间运行的IGP实例，也不同于在任何其他VPN的访问链路上运行的IGP实例。也允许静态路由。
The VRF is populated automatically with routes distributed from locally attached CE routers via whatever routing algorithm is run on the PE/CE links. It is also populated automatically with routes distributed from other VRFs via BGP. Standard routing decision processes are used to automatically select the proper routes. Static configuration of routes in the VRF is optional.
VRF通过PE/CE链路上运行的任何路由算法自动填充从本地连接的CE路由器分发的路由。它还自动填充通过BGP从其他VRF分发的路由。标准路由决策过程用于自动选择合适的路由。VRF中路由的静态配置是可选的。
Each PE router must run BGP, and must be pre-configured with the identities of a small set of BGP Route Reflectors, with which it is to peer via IBGP. ("IBGP" refers to the BGP procedures used between BGP speakers from the same Autonomous System.)
每个PE路由器必须运行BGP，并且必须预先配置一小组BGP路由反射器的标识，以便通过IBGP进行对等。（“IBGP”指来自同一自治系统的BGP扬声器之间使用的BGP程序。）
In lieu of using Route Reflectors, one could configure each PE with the identities of all the other PEs, and set up a full mesh of IBGP connections. While this might be adequate for small networks, it would not scale well to large networks; the use of Route Reflectors is necessary to achieve scalability. See section 4.3.3 of [BGP-MPLS-IP-VPN] for a more complete discussion of the use of Route Reflectors, and related scalability mechanisms such as Outbound Route Filtering.
代替使用路由反射器，可以使用所有其他PE的标识配置每个PE，并设置IBGP连接的完整网格。虽然这对于小型网络可能是足够的，但它不能很好地扩展到大型网络；为了实现可伸缩性，必须使用路由反射器。请参阅[BGP-MPLS-IP-VPN]的第4.3.3节，了解有关路由反射器的使用以及出站路由过滤等相关可扩展性机制的更完整讨论。
Each VRF must be configured with three parameters:
每个VRF必须配置三个参数：
- A Route Distinguisher. This is a globally unique 8-byte value. Each VRF may have a unique Route Distinguisher (RD), or there may be a single unique RD for an entire VPN. When BGP is used to distribute VPN routing information across the SP backbone, this value is prepended to the VPN's IPv4 address prefixes, creating a new address family, the VPN-IPv4 address family. Thus, even when two VPNs have overlapping IPv4 address spaces, they have unique VPN-IPv4 address spaces.
- 路线识别器。这是一个全局唯一的8字节值。每个VRF可能有一个唯一的路由识别器（RD），或者整个VPN可能有一个唯一的RD。当使用BGP在SP主干网上分发VPN路由信息时，此值将被添加到VPN的IPv4地址前缀中，从而创建一个新的地址族，即VPN-IPv4地址族。因此，即使两个VPN具有重叠的IPv4地址空间，它们也具有唯一的VPN-IPv4地址空间。
- One or more Export Route Targets. A Route Target (RT) is a globally unique 8-byte value that BGP carries, as the Extended Communities Route Target attribute, along with routes that are exported form the VRF.
- 一个或多个导出路由目标。路由目标（RT）是全局唯一的8字节值，BGP携带该值作为扩展社区路由目标属性，以及从VRF导出的路由。
- One or more Import Route Targets. This RT is used to select routes to be imported from other VRFs into this VRF.
- 一个或多个导入路由目标。此RT用于选择要从其他VRF导入此VRF的路线。
In the simplest cases and most common cases, the Export RT, Import RT, and RD can be identical, and all VRFs in the same VPN will distribute routes to each other (a typical intranet). In more complex cases, they can be set differently, allowing a very fine
在最简单和最常见的情况下，导出RT、导入RT和RD可以是相同的，同一VPN中的所有VRF将相互分配路由（典型的intranet）。在更复杂的情况下，它们可以进行不同的设置，从而允许非常精细的
degree of control over the distribution of routes among VRFs. This can be used to create extranets or to enforce various customer policies. In complicated cases, particular Export RTs can be assigned to particular routes using router management mechanisms. One advantage to not requiring the RD to be the same as any RT is that this may allow an RD value to be automatically determined for each VRF; RT values, on the other hand, must always be configured.
对VRF之间路线分布的控制程度。这可用于创建外联网或强制执行各种客户策略。在复杂的情况下，可以使用路由器管理机制将特定的导出RTs分配给特定的路由。不要求RD与任何RT相同的一个优点是，这可以允许为每个VRF自动确定RD值；另一方面，必须始终配置RT值。
Adding a new site to a VPN is a matter of attaching the site's CE router to a PE router, configuring the interface, and, if a VRF for that VPN already exists in the PE router, associating that interface with the VRF. If a VRF for that VPN does not already exist in the PE, then one must be configured as specified above. Changes to the configuration of a PE are automatically reflected via BGP to the other PEs.
向VPN添加新站点需要将站点的CE路由器连接到PE路由器，配置接口，如果PE路由器中已经存在该VPN的VRF，则将该接口与VRF关联。如果PE中不存在该VPN的VRF，则必须按照上述规定配置一个VRF。PE配置的更改通过BGP自动反映到其他PE。
The RTs and RDs are made unique by being structured as an SP identifier followed by a number which is assigned by the identified SP. SPs may be identified by their AS numbers, or by a registered IP address owned by that SP.
RTs和RDs被构造为一个SP标识符，后跟一个由已识别SP分配的号码，从而使其具有唯一性。SP可以通过其as号码或该SP拥有的注册IP地址来识别。
Although RTs are encoded as BGP Extended Communities, the encoding itself distinguishes them from any other kind of BGP Extended Community.
尽管RTs被编码为BGP扩展社区，但编码本身将其与任何其他类型的BGP扩展社区区分开来。
The scheme is optimized for full inter-site connectivity, in the sense that this is what the simplest configurations provide.
该方案针对完全站点间连接进行了优化，因为这是最简单的配置所提供的。
However, the SP has full control, through the mechanism of Route Targets, of the distribution of routing information among the set of VRFs. This enables the SP to provide hub-and-spoke or partial mesh connectivity as well as full mesh connectivity.
然而，SP通过路由目标机制完全控制路由信息在VRF集合中的分布。这使SP能够提供中心辐射或部分网状连接以及全网状连接。
Note that, strictly speaking, the scheme does not create a topology, as it does not create layer 2 connections among the sites. It does, however, allow for control over the IP connectivity among the sites. It is also possible to constrain the distribution of routing in arbitrary ways, e.g., so that data from site A to site B must travel through a third site C. (In fact, if it is desired to do so, this level of control can be specified at the granularity of a single route.)
请注意，严格来说，该方案不会创建拓扑，因为它不会在站点之间创建第2层连接。但是，它允许控制站点之间的IP连接。还可以以任意方式限制路由的分布，例如，使从站点A到站点B的数据必须经过第三站点C。（事实上，如果需要这样做，可以在单个路由的粒度上指定此控制级别。）
It is possible for some of the routes from a particular customer site A to be distributed to one set of remote sites, while other routes from site A are distributed to a different set of remote sites. This is done with the Route Target mechanism previously described.
可以将来自特定客户站点a的一些路由分配到一组远程站点，而将来自站点a的其他路由分配到另一组远程站点。这是通过前面描述的路由目标机制完成的。
Unicast IP traffic is fully supported. Customer IP packets are passed transparently.
完全支持单播IP通信。客户IP数据包的传递是透明的。
Multicast IP traffic is optionally supported, if the SP provides the optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are, however, scaling implications to the use of these mechanisms. Discussion of these implications is deferred.
如果SP提供[BGP-MPLS-MCAST-VPN]的可选机制，则可以选择支持多播IP通信。然而，这些机制的使用存在着规模效应。对这些影响的讨论被推迟。
Non-IP traffic is not supported. If support for non-IP traffic is necessary, either the SP must additionally provide a layer 2 tunneling service or the customer must use IP tunneling.
不支持非IP通信。如果需要支持非IP流量，SP必须另外提供第2层隧道服务，或者客户必须使用IP隧道。
In general, customer routers at different sites do not become routing peers. However, a customer may, if he so desires, allow routers at different sites to be routing peers over a link that is NOT part of the VPN service. Such peering relationships are known as "IGP backdoors". To ensure the proper operation of routing when IGP backdoors are present, each VPN route that is distributed by the SP is distributed along with a corresponding routing metric. This enables the customer's IGP to compare the "backdoor routes" properly with the routes that use the SP backbone. In the particular case where a customer running OSPF within his sites wishes to have IGP backdoors, he should run OSPF on the PE/CE link, and the PEs should run the procedures of [VPN-OSPF]. (The CEs do NOT require any special OSPF procedures.)
通常，不同站点的客户路由器不会成为路由对等点。但是，如果客户愿意，可以允许不同站点的路由器通过不属于VPN服务的链路路由对等点。这种对等关系被称为“IGP后门”。为确保存在IGP后门时路由的正确操作，SP分发的每个VPN路由都会与相应的路由度量一起分发。这使客户的IGP能够正确比较“后门路由”与使用SP主干网的路由。在特定情况下，如果在其站点内运行OSPF的客户希望有IGP后门，则应在PE/CE链路上运行OSPF，PEs应运行[VPN-OSPF]的程序。（CEs不需要任何特殊的OSPF程序。）
The Route Target mechanism is used to control the distribution of routing information, so that routes from one VPN do not get sent to another. VPN routes are treated by BGP as a different address family than general Internet routes. Routes from a VRF do not get leaked to the Internet unless the VRF has been explicitly configured to allow it (and this is NOT the default).
路由目标机制用于控制路由信息的分布，以便不会将来自一个VPN的路由发送到另一个VPN。BGP将VPN路由视为与一般Internet路由不同的地址族。来自VRF的路由不会泄漏到Internet，除非VRF已明确配置为允许（这不是默认设置）。
The way in which a particular VPN is divided into sites, or the topology of any particular VPN site, is hidden from the Internet and from other VPNs. (Of course, if a particular site can receive Internet traffic, and if it responds to traceroute probes from the Internet, then any user of the Internet can learn something about the site topology. The fact that the site is in a VPN does not make this any easier or any harder.)
将特定VPN划分为站点的方式，或任何特定VPN站点的拓扑，对Internet和其他VPN隐藏。（当然，如果某个特定站点可以接收Internet流量，并且它响应来自Internet的跟踪路由探测，则Internet的任何用户都可以了解有关站点拓扑的信息。该站点位于VPN中的事实并不会使这一点变得更容易或更困难。）
Similarly, Internet routes do not get leaked into the VPN, unless a VRF of that VPN is explicitly configured to import the Internet routes.
类似地，互联网路由不会泄漏到VPN中，除非该VPN的VRF被明确配置为导入互联网路由。
Proper configuration is essential to maintaining the isolation. In particular, each access link must be associated with the proper VRF for that access link, and each VRF must be configured with the proper set of RTs.
正确的配置对于保持隔离至关重要。特别是，每个接入链路必须与该接入链路的适当VRF相关联，并且每个VRF必须配置适当的RTs集。
A number of means for exchanging reachability information between the PE and CE devices are supported: static routing, EBGP, and RIP are supported by the procedures of [BGP-MPLS-IP-VPN]. If the procedures of [VPN-OSPF] and [OSPF-2547-DNBIT] are implemented, OSPF may be used. If OSPF is used between two VPN sites that are in the same OSPF area, and if it is desired for routes over the VPN backbone to be preferred to the OSPF intra-site routes, then the "sham link" procedures of [VPN-OSPF] must be used.
支持在PE和CE设备之间交换可达性信息的多种方式：静态路由、EBGP和RIP由[BGP-MPLS-IP-VPN]的过程支持。如果执行了[VPN-OSPF]和[OSPF-2547-DNBIT]的程序，则可以使用OSPF。如果在同一OSPF区域内的两个VPN站点之间使用OSPF，并且如果希望VPN主干上的路由优先于OSPF站点内路由，则必须使用[VPN-OSPF]的“假链接”过程。
The routing protocols used among the customer routers are not in any way restricted by the VPN scheme, as whatever IGP is used within the VPN, the PE/CE access links may run EBGP, or may otherwise be in a different routing domain than the site's internal links.
客户路由器之间使用的路由协议不受VPN方案的任何限制，因为无论VPN中使用何种IGP，PE/CE访问链路都可能运行EBGP，或者可能位于与站点内部链路不同的路由域中。
BGP is used for passing routing information among SPs. BGP may be authenticated by use of the TCP MD5 option, or by operating through an IPsec tunnel.
BGP用于在SP之间传递路由信息。BGP可以通过使用TCP MD5选项或通过IPsec隧道进行身份验证。
Data traveling between two customer sites is encapsulated while in transit through the backbone. The encapsulation contains sufficient information to ensure that the packet is sent to the proper PE router, and then, in conjunction with the VRF and related information at that PE, to the proper CE routers.
在两个客户站点之间传输的数据在通过主干传输时被封装。封装包含足够的信息，以确保包被发送到适当的PE路由器，然后与该PE上的VRF和相关信息一起发送到适当的CE路由器。
If two VPNs attach to the same PE, there is strict separation of forwarding at that PE, as well as strict separation of the routing information.
如果两个VPN连接到同一个PE，则该PE上的转发将严格分离，路由信息也将严格分离。
Isolation of traffic is similar to that provided by classical L2 VPNs which are based on Frame Relay or Asynchronous Transfer Mode (ATM). As in classical L2 VPNs, the customer must rely on the SP to properly configure the backbone network to ensure proper isolation and to maintain the security of his communications gear.
流量隔离类似于基于帧中继或异步传输模式（ATM）的经典L2 VPN提供的隔离。与传统的L2 VPN一样，客户必须依靠SP来正确配置主干网络，以确保适当的隔离并维护其通信设备的安全性。
No particular means of PE/CE authentication is specified for BGP/MPLS IP VPNs. PE/CE mutual authentication may be done via any mechanism supported by the routing protocol in which the CE and PE are peers (e.g., use of the TCP MD5 authentication when the PE/CE protocol is BGP), or by any other mechanism that may be desired. With such mechanisms in place, a CE may not join a VPN until the CE authenticates itself to the Service Provider.
没有为BGP/MPLS IP VPN指定特定的PE/CE身份验证方式。PE/CE相互认证可以通过CE和PE是对等方的路由协议支持的任何机制（例如，当PE/CE协议是BGP时使用TCP MD5认证）或者通过可能需要的任何其他机制来完成。有了这样的机制，CE可能不会加入VPN，直到CE向服务提供商认证自己。
There is, however, no standardized method that requires a CE to authenticate itself to the customer network (rather than to the SP) before the CE is allowed to join the VPN. This is for further study.
但是，在允许CE加入VPN之前，没有标准化方法要求CE向客户网络（而不是SP）进行身份验证。这是为了进一步研究。
No particular means is specified for controlling which user data packets can be forwarded by BGP/MPLS IP VPNs. BGP/MPLS IP VPNs are compatible with Access Control Lists (ACLs) and any other filtering features that are supported on the PE routers. Routing can be set up so that extranet traffic is directly through a firewall, if that is desired.
没有指定特定的方法来控制BGP/MPLS IP VPN可以转发哪些用户数据包。BGP/MPLS IP VPN与访问控制列表（ACL）以及PE路由器上支持的任何其他过滤功能兼容。如果需要的话，可以设置路由，使外联网流量直接通过防火墙。
It is possible for various sorts of "tunnel interfaces" to be associated with a VRF. In this case, whatever authentication is natively used in the establishment of the tunnel interface may be used. For example, an IPsec tunnel can be used as an "access link" to attach a remote user or site to a VRF. The authentication procedure in this case is part of IPsec, not part of the VPN scheme.
各种类型的“隧道接口”可能与VRF相关联。在这种情况下，可以使用在隧道接口的建立中本机使用的任何认证。例如，IPsec隧道可以用作将远程用户或站点连接到VRF的“访问链路”。本例中的身份验证过程是IPsec的一部分，而不是VPN方案的一部分。
Where L2TP is used, each PPP session carried in an L2TP tunnel can be associated with a VRF. The SP's Authentication, Authorization, and Accounting (AAA) server can be used to determine the VPN to which the PPP session belongs, and then the customer's AAA server can be given the opportunity to authenticate that session as well.
在使用L2TP的情况下，L2TP隧道中承载的每个PPP会话都可以与VRF相关联。SP的身份验证、授权和计费（AAA）服务器可用于确定PPP会话所属的VPN，然后客户的AAA服务器也可获得对该会话进行身份验证的机会。
No particular means of ensuring user data security is specified for BGP/MPLS IP VPNs.
没有为BGP/MPLS IP VPN指定确保用户数据安全的特定方法。
The optional procedures of [MPLS/BGP-IPsec] may be used to provide authentication and/or encryption of user data as it travels from the ingress PE to the egress PE. However, the data is exposed at those two PEs, as well as on the PE/CE access links.
[MPLS/BGP IPsec]的可选过程可用于在用户数据从入口PE传输到出口PE时提供用户数据的认证和/或加密。但是，数据在这两个PE以及PE/CE访问链路上公开。
The customer may provide his own user data security by using IPsec tunnels that terminate within the customer sites. Such tunnels are transparent to the VPN scheme. Schemes that discover the remote tunnel endpoints automatically and then set up the tunnels automatically as needed are the best fit with this VPN technology. Note that there is no requirement in general that IPsec tunnels between customer sites terminate at CE routers.
客户可以通过使用在客户站点内终止的IPsec隧道来提供自己的用户数据安全。这样的隧道对VPN方案是透明的。自动发现远程隧道端点，然后根据需要自动设置隧道的方案最适合此VPN技术。请注意，一般不要求客户站点之间的IPsec隧道终止于CE路由器。
The use of end-to-end transport mode IPsec by the customer is also transparent to the VPN scheme. In fact, the VPN scheme is compatible with any use of security by the customer, as long as a cleartext IP header is passed from CE to PE.
客户使用端到端传输模式IPsec对VPN方案也是透明的。事实上，只要将明文IP头从CE传递到PE，VPN方案就与客户的任何安全使用兼容。
When data must cross the Internet to reach the ingress PE router, IPsec tunnels between the end user and the PE router can be used; the PE router must then associate each IPsec tunnel with the proper VRF. This association would have to be based on user-specific information provided by the Internet Key Exchange (IKE) protocol, such as a VPN-id.
当数据必须通过Internet到达入口PE路由器时，可以使用终端用户和PE路由器之间的IPsec隧道；PE路由器必须将每个IPsec隧道与适当的VRF相关联。这种关联必须基于Internet密钥交换（IKE）协议提供的用户特定信息，如VPN-id。
If data is going from one SP network to another, and must cross the public Internet to get between those two networks, IPsec tunnels can be used to secure the data. This would require bilateral agreement between the two SPs. BGP connections can also be passed through an IPsec tunnel if this is deemed necessary, in order to protect user data, by a pair of SPs. QoS/SLA factors would have to be carefully considered in this case.
如果数据从一个SP网络传输到另一个SP网络，并且必须通过公共Internet才能在这两个网络之间传输，则可以使用IPsec隧道来保护数据。这需要两个SP之间达成双边协议。为了保护用户数据，如果一对SP认为有必要，BGP连接也可以通过IPsec隧道传递。在这种情况下，必须仔细考虑QoS/SLA因素。
The SP is responsible for preventing illegitimate traffic from entering a VPN. VPN traffic is always encapsulated while traveling on the backbone, so preventing illegitimate traffic is a matter of ensuring that the PE routers to the encapsulation/decapsulation correctly and that encapsulations have not been "spoofed", i.e., that the encapsulated packets were actually encapsulated by PE routers.
SP负责防止非法流量进入VPN。VPN流量始终在主干上传输时被封装，因此防止非法流量是一个确保PE路由器正确地封装/解除封装以及封装没有被“欺骗”的问题，即，封装的数据包实际上是由PE路由器封装的。
This requires the SP to take various security measures. The PE and P routers must themselves be secure against break-ins (either from someone physically present or from the Internet), and neither P nor PE routers should form routing adjacencies to other P or PE routers without benefit of some kind of security. This may be authentication in the IGP, or physical security.
这要求SP采取各种安全措施。PE和P路由器本身必须能够防止入侵（无论是来自实际存在的人还是来自互联网），并且在没有某种安全性的情况下，P和PE路由器都不应与其他P或PE路由器形成路由邻接。这可能是IGP中的身份验证，也可能是物理安全性。
The PE/CE access link should be secured in some manner, though the provider may make it the responsibility of the customer to ensure that the CE is secure from compromise. If the PE/CE access link is a tunnel over the Internet, then of course some sort of authentication protocol should always be used.
PE/CE接入链路应以某种方式进行保护，尽管提供商可能会让客户负责确保CE安全不受损害。如果PE/CE访问链路是Internet上的隧道，那么当然应该始终使用某种身份验证协议。
Label Distribution Protocol (LDP) sessions and BGP sessions between PE and/or P routers should be authenticated. This can be done via the TCP MD5 option or by use of IPsec.
PE和/或P路由器之间的标签分发协议（LDP）会话和BGP会话应经过身份验证。这可以通过TCP MD5选项或使用IPsec来完成。
If the SP is providing the VPN service over an MPLS backbone, it should not accept MPLS packets from its external interfaces (i.e., interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system from which the packet is being received. If the packet's incoming interface leads to a different SP (rather than to a customer), an appropriate trust relationship must also be present, including the trust that the other SP also provides appropriate security measures.
如果SP通过MPLS主干网提供VPN服务，则不应接受来自其外部接口（即与CE设备或其他提供商网络的接口）的MPLS数据包，除非数据包的顶部标签被合法地分发到接收数据包的系统。如果数据包的传入接口指向不同的SP（而不是客户），则还必须存在适当的信任关系，包括信任其他SP也提供适当的安全措施。
If the SP is providing the VPN service by using an IP (rather than an MPLS) encapsulation, or if it accepts IP-encapsulated VPN packets from other SPs, it should apply filtering at its borders so that it does not accept from other SPs or from customers any IP packets that are addressed to the PE routers, unless appropriate trust relationships are in place.
如果SP通过使用IP（而不是MPLS）封装提供VPN服务，或者如果SP接受来自其他SP的IP封装VPN数据包，则应在其边界处应用过滤，以使其不接受来自其他SP或来自客户的任何发往PE路由器的IP数据包，除非有适当的信任关系。
Cryptographic authentication of the encapsulated data packets is certainly advantageous when there are multiple SPs providing a single VPN.
当有多个SP提供单个VPN时，封装数据包的加密身份验证无疑是有利的。
When a dynamic routing protocol is run on the link between a CE router and a PE router, routing instability in the private network may have an effect on the PE router. For example, an unusually large number of routing updates could be sent from the CE router to the PE router, placing an unusually large processing load on the PE router. This can potentially be used as a Denial-of-Service (DoS) attack on the PE router.
当在CE路由器和PE路由器之间的链路上运行动态路由协议时，专用网络中的路由不稳定性可能会对PE路由器产生影响。例如，可能会从CE路由器向PE路由器发送异常大量的路由更新，从而给PE路由器带来异常大的处理负载。这可能被用作PE路由器上的拒绝服务（DoS）攻击。
This issue can be mitigated via resource partitioning in the PE, in order to limit the amount of resources (e.g., CPU and memory) that any one VPN is permitted to use in PE routers. Also, rate limits may be applied to the routing traffic sent from the CE to the PE. Alternately, when this problem is detected, the CE-to-PE interface may be shut down.
这个问题可以通过PE中的资源分区来缓解，以限制允许任何一个VPN在PE路由器中使用的资源量（例如CPU和内存）。此外，速率限制可应用于从CE发送到PE的路由业务。或者，当检测到此问题时，CE至PE接口可能会关闭。
Network management traffic from the CE to the PE may be rate limited (for example, to prevent network management traffic from CE to PE to be used in a DoS attack).
从CE到PE的网络管理流量可能受到速率限制（例如，防止在DoS攻击中使用从CE到PE的网络管理流量）。
Section 9 of [L2VPN-SEC-FRMWRK] provides "a brief template that may be used to evaluate and summarize how a given PPVPN [Provider-Provisioned Virtual Private Network] approach (solution) measures up against the PPVPN Security Framework". It further states "an evaluation using this template should appear in the applicability statement for each PPVPN approach". The purpose of this subsection is to provide the information in the form required by this template. Security requirements that are relevant only to L2VPNs are not applicable and are not further discussed.
[L2VPN-SEC-FRMWRK]第9节提供了“可用于评估和总结给定PPVPN[提供商提供的虚拟专用网络]方法（解决方案）如何与PPVPN安全框架相匹配的简要模板”。它进一步声明“使用该模板的评估应出现在每个PPVPN方法的适用性声明中”。本小节的目的是以本模板要求的形式提供信息。仅与L2VPN相关的安全要求不适用，因此不会进一步讨论。
- Does the approach provides complete IP address space separation for each L3VPN?
- 该方法是否为每个L3VPN提供完整的IP地址空间分离？
Yes.
对
The IP address prefixes from a particular VPN appear in their native form only in routing tables that are specific to the particular VPN. They are distributed in their native form only by routing instances that are specific to the particular VPN. When address prefixes from different VPNs are combined into a common table, or distributed by a common mechanism, the address prefixes are first prepended with a Route Distinguisher (RD). The RD is a 64-bit quantity, structured so that globally unique RD values can easily be created by an SP. As long as no two VPNs are assigned the same RD value, complete IP address space separation is provided. It is however possible for an SP to misconfigure the RD assignments.
来自特定VPN的IP地址前缀仅以其本机形式出现在特定VPN的路由表中。它们仅通过特定于特定VPN的路由实例以其本机形式分发。当来自不同VPN的地址前缀组合到一个公共表中，或通过一个公共机制分发时，地址前缀首先用路由识别器（RD）作为前缀。RD是一个64位数量，其结构使得SP可以轻松创建全局唯一的RD值。只要没有两个VPN分配相同的RD值，就可以提供完整的IP地址空间分离。但是，SP可能会错误配置RD分配。
- Does the approach provide complete IP route separation for each L3VPN?
- 该方法是否为每个L3VPN提供完整的IP路由分离？
Yes.
对
The distribution of routes is controlled by assigning import and export Route Targets (RTs). A route that is exported from a VRF carries an RT specified by the SP as an export RT for that VRF. The route can be imported into other VRFs only if the RT that it carries has been configured by the SP as an import RT for those other VRFS. Thus, the SP has complete control over the set of VRFs to which a route will be distributed. It is of course possible for the SP to misconfigure the RT assignments.
路由的分布通过分配导入和导出路由目标（RTs）来控制。从VRF导出的路由携带SP指定的RT作为该VRF的导出RT。只有当SP已将路由所承载的RT配置为其他VRF的导入RT时，才能将路由导入其他VRF。因此，SP可以完全控制路由将分发到的VRF集。当然，SP可能会错误配置RT分配。
- Does the approach provide a means to prevent improper cross-connection of sites in separate VPNs?
- 该方法是否提供了一种方法来防止单独VPN中站点的不正确交叉连接？
This requirement is addressed in a way that is beyond the scope of the VPN mechanisms.
此要求的解决方式超出了VPN机制的范围。
In BGP/MPLS IP VPNs, an SP makes a particular site part of a particular VPN by configuring the PE router's interface to that site to be associated with a particular VRF in that PE. The VRF is configured with import and export RTs, and it is the way in which VRFs are configured with RTs in the various PEs that results in a particular set of sites being connected as a VPN.
在BGP/MPLS IP VPN中，SP通过将PE路由器与该站点的接口配置为与该PE中的特定VRF关联，使特定站点成为特定VPN的一部分。VRF配置有导入和导出RTs，在各种PEs中，VRF配置有RTs的方式导致一组特定的站点连接为VPN。
Connecting the sites properly in this way is regarded as a network management function, and the VPN scheme itself does not provide a means to prevent misconfiguration.
以这种方式正确连接站点被视为一种网络管理功能，VPN方案本身不提供防止错误配置的方法。
The VPN scheme does not provide any particular method for ensuring that a given interface from a PE leads to the CE that is expected to be there. If a routing algorithm is run on a particular PE/CE interface, any security procedures that the routing algorithm provides (e.g., MD5 authentication of BGP sessions) can be used; this is outside the scope of the VPN scheme. Also, a CE can attach to a PE via an IPsec tunnel, if this is desired, for a greater degree of security.
VPN方案不提供任何特定方法来确保来自PE的给定接口连接到预期存在的CE。如果路由算法在特定PE/CE接口上运行，则可以使用路由算法提供的任何安全过程（例如，BGP会话的MD5认证）；这超出了VPN方案的范围。此外，如果需要，CE可以通过IPsec隧道连接到PE，以获得更高程度的安全性。
- Does the approach provide a means to detect improper cross-connection of sites in separate VPNs?
- 该方法是否提供了一种方法来检测单独VPN中站点的不正确交叉连接？
The base specifications for BGP/MPLS IP VPNs do not provide a means for detecting that a site has been connected to the wrong VPN. However, the optional procedure specified in [CE-VERIF] does provide such a means. Basically, each PE obtains, via protocol, a secret from each CE to which it is directly attached. When the routes from a given CE are distributed, the secret from that CE is attached as an attribute of the route. This secret will ultimately be distributed to any other CE that receives any route from the given CE. A CE that is not supposed to be part of a given VPN will not know the right secret, and if it is connected to the given VPN the other CEs in that VPN will realize that a CE that doesn't know the proper secret has been connected to the VPN.
BGP/MPLS IP VPN的基本规范没有提供检测站点连接到错误VPN的方法。然而，[CE-VERIF]中规定的可选程序确实提供了这种方法。基本上，每个PE通过协议从其直接连接的每个CE获得一个秘密。当来自给定CE的路由被分发时，来自该CE的秘密被附加为路由的属性。该秘密最终将分发给从给定CE接收任何路由的任何其他CE。不属于给定VPN的CE将不知道正确的秘密，如果它连接到给定VPN，该VPN中的其他CE将意识到不知道正确秘密的CE已连接到VPN。
- Does the approach protect against the introduction of unauthorized packets into each VPN?
- 该方法是否可以防止未经授权的数据包引入每个VPN？
We must look separately at the various points at which one might attempt to introduce unauthorized packets.
我们必须分别研究可能引入未经授权数据包的各个点。
* Packets arriving at a PE over a PE/CE interface
* 通过PE/CE接口到达PE的数据包
If a given PE is directly connected to a given CE, the PE will accept any packets that the CE sends it. The VPN scheme has no special procedures for determining that these packets actually came from the CE. However, various means of securing the PE/CE connection can be used (for instance, the PE and CE can be connected by an IPsec tunnel) if desired. That is, this aspect of the requirement can be addressed by means that are outside the scope of the VPN specification.
如果给定的PE直接连接到给定的CE，则PE将接受CE发送给它的任何数据包。VPN方案没有确定这些数据包实际上来自CE的特殊程序。然而，如果需要，可以使用各种保护PE/CE连接的方法（例如，PE和CE可以通过IPsec隧道连接）。也就是说，需求的这一方面可以通过VPN规范范围之外的方法来解决。
Once a packet has been accepted from a CE by a PE, the packet is routed according to the VRF associated with that PE's interface to that CE. Such packets can only be sent along routes that are in that VRF. There is no way a packet from a CE can be routed to an arbitrary VPN. In particular, there is nothing a VPN user can do to cause any particular packet to be sent to the wrong VPN. So this aspect of the requirement is fully addressed.
一旦PE从CE接收到数据包，则根据与该PE与该CE的接口相关联的VRF路由该数据包。此类数据包只能沿该VRF中的路由发送。来自CE的数据包无法路由到任意VPN。特别是，VPN用户无法将任何特定数据包发送到错误的VPN。因此，需求的这一方面得到了充分的解决。
* Packets arriving at a PE over an interface from the backbone
* 通过接口从主干到达PE的数据包
The optional procedures of [MPLS/BGP-IPsec] can be used to ensure that a packet that is received by a PE from the backbone will not be recognized as a VPN packet unless it actually is one. Those procedures also ensure that a received VPN packet came from a particular PE and that it carries the MPLS label that that PE put on it. These procedures protect the packet from ingress PE to egress PE, but do not protect the PE/CE interfaces.
[MPLS/BGP IPsec]的可选过程可用于确保PE从主干接收的数据包不会被识别为VPN数据包，除非它实际上是一个VPN数据包。这些过程还确保接收到的VPN数据包来自特定的PE，并且它携带该PE贴在其上的MPLS标签。这些程序保护数据包从入口PE到出口PE，但不保护PE/CE接口。
If the optional procedures of [MPLS/BGP-IPsec] are not used, then the following considerations apply.
如果未使用[MPLS/BGP IPsec]的可选过程，则以下注意事项适用。
Undetected corruption of the routing information carried in a packet's VPN encapsulation can result in misdelivery of the packet, possibly to the wrong VPN.
包的VPN封装中携带的路由信息未被检测到的损坏可能会导致包的错误交付，可能是错误的VPN。
If a packet enters an SP's network on an interface other than a PE/CE interface, the SP should ensure that the packet either does not look like a VPN packet or else is not routed to a PE router. This can be done in a variety of ways that are outside the scope of the VPN scheme. For example, IP packets addressed to the PE routers can be filtered, MPLS packets (or, e.g., MPLS-in-IP) from outside the SP network can be refused, etc.
如果数据包通过PE/CE接口以外的接口进入SP的网络，SP应确保该数据包看起来不像VPN数据包，或者没有路由到PE路由器。这可以通过VPN方案范围之外的多种方式实现。例如，可以过滤发往PE路由器的IP分组，可以拒绝来自SP网络外部的MPLS分组（或者，例如，IP中的MPLS），等等。
In the case of a multi-provider L3VPN backbone, the SP will have to know which interfaces lead to SPs that are VPN partners, so that VPN packets can be allowed to flow on those interfaces.
对于多提供商L3VPN主干网，SP必须知道哪些接口通向作为VPN伙伴的SP，以便允许VPN数据包在这些接口上流动。
If the public Internet is used as the L3VPN backbone, protection against unauthorized packets cannot be achieved by the above measures. IPsec tunnels should always be used to carry VPN traffic across the public Internet.
如果使用公共互联网作为L3VPN主干网，则无法通过上述措施实现对未经授权数据包的保护。IPsec隧道应始终用于在公共Internet上传输VPN流量。
- Does the approach provide confidentiality (secrecy) protection, sender authentication, integrity protection, or protection against replay attacks for PPVPN user data?
- 该方法是否为PPVPN用户数据提供保密（保密）保护、发送方身份验证、完整性保护或防止重播攻击？
If these are desired, they must be provided by mechanisms that are outside the scope of the VPN mechanisms. For instance, the users can use secure protocols on an end-to-end basis, e.g., IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.
如果需要，则必须由VPN机制范围之外的机制提供。例如，用户可以在端到端的基础上使用安全协议，例如IPsec、安全Shell（SSH）、安全套接字层（SSL）等。
- Does the approach provide protection against unauthorized traffic pattern analysis for PPVPN user data?
- 该方法是否针对PPVPN用户数据的未授权流量模式分析提供保护？
Preventing an observer from obtaining traffic pattern analysis from the SP network is beyond the scope of the VPN mechanisms.
阻止观察者从SP网络获取流量模式分析超出VPN机制的范围。
- Do the control protocol(s) used for each of the following functions provide for message integrity and peer authentication?
- 用于以下每个功能的控制协议是否提供消息完整性和对等身份验证？
* VPN membership discovery
* VPN成员身份发现
This requirement is fully satisfied. Membership discovery is done by means of BGP. Control message integrity and peer authentication in BGP may be achieved by use of the TCP MD5 option.
这一要求完全得到满足。成员身份发现是通过BGP完成的。BGP中的控制消息完整性和对等身份验证可以通过使用TCP MD5选项来实现。
* Tunnel establishment
* 隧道设施
The answer to this question depends of course on the tunnel protocol and tunnel establishment protocol; a variety of different tunneling schemes can be used in BGP/MPLS IP VPNs. Thus, this question is out of scope.
这个问题的答案当然取决于隧道协议和隧道建立协议；BGP/MPLS IP VPN中可以使用多种不同的隧道方案。因此，这个问题超出了范围。
In the common case where the tunnels are MPLS Label Switching Routers (LSRs) established by LDP, then control message integrity and peer authentication may be achieved by use of the TCP MD5 option.
在隧道是由LDP建立的MPLS标签交换路由器（lsr）的常见情况下，则可以通过使用TCP MD5选项来实现控制消息完整性和对等认证。
* VPN topology and reachability advertisement
* VPN拓扑与可达性广告
With respect to PE-PE interactions, the relevant control protocol is BGP, so control message integrity and peer authentication can be achieved by use of the TCP MD5 option.
对于PE-PE交互，相关的控制协议是BGP，因此可以使用TCP MD5选项实现控制消息完整性和对等身份验证。
With respect to CE-PE interactions, the answer depends on the protocol used for exchanging information between PE and CE, as the security mechanisms (if any) of those protocols would need to be used. In the common case where the PE/CE protocol is BGP, the TCP MD5 option can be used.
关于CE-PE交互，答案取决于PE和CE之间用于交换信息的协议，因为需要使用这些协议的安全机制（如果有）。在PE/CE协议为BGP的常见情况下，可以使用TCP MD5选项。
* VPN provisioning and management
* VPN配置和管理
The protocols procedures for provisioning VPNs and managing the PE routers are outside the scope of the VPN scheme.
提供VPN和管理PE路由器的协议程序不在VPN方案的范围内。
* VPN monitoring and attack detection and reporting
* VPN监控、攻击检测和报告
The protocols and procedures for monitoring the VPNs are outside the scope of the VPN scheme.
监控VPN的协议和程序不在VPN方案的范围内。
- What protection does the approach provide against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks)?
- 该方法针对特定于PPVPN的DoS攻击（即受信任区域间的DoS攻击）提供了什么保护？
* Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms.
* 保护服务提供商基础设施免受源自专用（PPVPN用户）网络并针对PPVPN机制的数据平面或控制平面DoS攻击。
The PE/CE interfaces of a given VPN will generally be addressable from within that VPN. Apart from that, a user within an L3VPN has no more access to the service provider infrastructure than does any user of the Internet. Therefore, we will focus in this section on possible DoS attacks against a PE router that may occur when traffic from within a VPN is addressed to a PE router.
给定VPN的PE/CE接口通常可从该VPN内寻址。除此之外，L3VPN内的用户对服务提供商基础设施的访问权限不超过任何互联网用户。因此，在本节中，我们将重点讨论当VPN内的流量被发送到PE路由器时可能发生的针对PE路由器的DoS攻击。
A user within the VPN may address traffic to a PE router and may attempt to send an excessive amount of traffic to it. Presumably, the PE routers will not accept unauthorized TCP connections or Simple Network Management Protocol (SNMP) commands, so such traffic will be thrown away; the danger is that the PE may need to use a significant proportion of its capacity to discard such traffic. However, this case is no different than the case of any SP access router that attaches to subscriber equipment. The presence of the VPN mechanisms does not make the PE any more or less vulnerable to DoS attacks from arbitrary end users.
VPN内的用户可以向PE路由器寻址流量，并可能试图向其发送过多的流量。据推测，PE路由器不会接受未经授权的TCP连接或简单网络管理协议（SNMP）命令，因此此类流量将被丢弃；危险在于PE可能需要使用其容量的很大一部分来丢弃此类流量。但是，这种情况与连接到用户设备的任何SP访问路由器的情况没有什么不同。VPN机制的存在不会使PE或多或少受到来自任意最终用户的DoS攻击。
* Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
* 保护服务提供商基础设施免受源于Internet并针对PPVPN机制的数据平面或控制平面DoS攻击。
DoS attacks of this sort can be prevented if the PE routers are not addressable from the Internet. Alternatively, an SP can apply address filtering at its boundaries so that packets from the Internet are filtered if they are addressed to a PE router.
如果PE路由器无法从Internet寻址，则可以防止此类DoS攻击。或者，SP可以在其边界处应用地址过滤，以便在将来自Internet的数据包寻址到PE路由器时对其进行过滤。
* Protection of PPVPN users against Data Plane or Control Plane DoS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms.
* 保护PPVPN用户免受来自Internet或其他PPVPN用户并针对PPVPN机制的数据平面或控制平面DoS攻击。
Mechanisms already discussed prevent users in a VPN from receiving packets from the Internet, unless this is specifically allowed. In the case where it is specifically allowed, it is no different than any other situation in which a network is connected to the Internet, and there is no special vulnerability to DoS attacks due to the L3VPN mechanisms.
已经讨论过的机制防止VPN中的用户从Internet接收数据包，除非这是特别允许的。在特别允许的情况下，它与网络连接到Internet的任何其他情况没有区别，并且由于L3VPN机制，不存在DoS攻击的特殊漏洞。
There is nothing to prevent a user in a VPN from mounting a DoS attack against other users in the VPN. However, the L3VPN mechanisms make this neither more nor less likely.
无法阻止VPN中的用户对VPN中的其他用户发起DoS攻击。然而，L3VPN机制使这种可能性既不增加也不减少。
- Does the approach provide protection against unstable or malicious operation of a PPVPN user network?
- 该方法是否能够防止PPVPN用户网络的不稳定或恶意操作？
* Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network.
* 针对从PPVPN用户网络到服务提供商网络的路由流量的高级别或恶意设计提供保护。
If a dynamic routing algorithm is running on the PE/CE interface, it can be used to mount an attack on the PE router, by having the CE present the PE with an excessive number of routing events. If an end user within a VPN successfully attacks the routing algorithm of the VPN, that might also result in an excessive number of routing events being seen by the PE router. This sort of attack can be ameliorated by having the PE limit the amount of its resources that can be expended processing routing events from a particular VPN. If the PE/CE routing algorithm is BGP, then such mechanisms as route flap damping may be appropriate as well.
如果在PE/CE接口上运行动态路由算法，则可通过让CE向PE呈现过多的路由事件，利用该算法在PE路由器上发起攻击。如果VPN内的最终用户成功攻击VPN的路由算法，则也可能导致PE路由器看到过多的路由事件。通过让PE限制其可用于处理来自特定VPN的路由事件的资源量，可以改进此类攻击。如果PE/CE路由算法是BGP，那么路由襟翼阻尼等机制也可能是合适的。
* Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
* 针对从PPVPN用户网络到服务提供商网络的高级别或恶意设计的网络管理流量提供保护。
A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send management traffic to the service provider network.
BGP/MPLS IP VPN中的用户与任何Internet用户一样，没有能力向服务提供商网络发送管理流量。
* Protection against worms and probes originated in the PPVPN user networks, sent towards the service provider network.
* 针对源自PPVPN用户网络、发送至服务提供商网络的蠕虫和探测的保护。
A user in a BGP/MPLS IP VPN has no more ability than any Internet user to send worms or probes to the service provider network.
BGP/MPLS IP VPN中的用户与任何Internet用户一样，没有能力向服务提供商网络发送蠕虫或探测。
Overlapping customer addresses are supported. There is no requirement that such addresses be in conformance with [RFC1918]. There is no requirement that customer VPN addresses be distinct from addresses in the SP network.
支持重叠的客户地址。不要求此类地址符合[RFC1918]。不要求客户VPN地址与SP网络中的地址不同。
Any set of addresses used in the VPN can be supported, irrespective of how they are assigned, how well they aggregate, and whether they are public or private. However, the set of addresses that are reachable from a given site must be unique.
VPN中使用的任何地址集都可以得到支持，无论它们是如何分配的，聚合的如何，以及它们是公共的还是私有的。但是，从给定站点可以访问的地址集必须是唯一的。
Network address translation for packets leaving/entering a VPN is possible and is transparent to the VPN scheme.
对于离开/进入VPN的数据包，可以进行网络地址转换，并且对VPN方案是透明的。
There is nothing in the architecture to preclude the mechanisms from being extended to support IPv6, provided that the appropriate IPv6- capable routing algorithms are in place. That is, PE/CE routing must support IPv6, and the PE-PE BGP must support the labeled IPv6 address family. The latter has not been specified, but its specification is obvious from the specification of the labeled IPv4 address family. The IGP used in the SP backbone need not be IPv6 capable in order to support customer IPv6 networks.
如果适当的支持IPv6的路由算法已经到位，那么架构中没有任何东西可以阻止机制扩展以支持IPv6。也就是说，PE/CE路由必须支持IPv6，并且PE-PE BGP必须支持标记的IPv6地址族。后者尚未指定，但其规范从标记的IPv4地址系列的规范中可以明显看出。SP主干网中使用的IGP无需支持IPv6，即可支持客户IPv6网络。
In theory, the same could be said of other network layers, but in practice a customer who has non-IP traffic to carry must expect to carry it either in site-to-site IP tunnels or using some additional service (such as a layer 2 service) from the SP.
理论上，其他网络层也是如此，但在实践中，拥有非IP流量的客户必须期望在站点到站点的IP隧道中或使用来自SP的某些附加服务（如第2层服务）来承载流量。
Layer 2 addresses and identifiers are never carried across the SP backbone.
第2层地址和标识符永远不会在SP主干上传输。
No restrictions are placed on the customer's addressing schemes or policies. Note though that the SP may place restrictions on the number of routes from a given customer site, or may charge differentially depending on the number of such routes, and such restrictions may have implications for the customer's addressing scheme. In particular, addressing schemes that facilitate route aggregation on a per-site basis will result in the most efficient use of the SP's resources, and this may be reflected in SP charging policies.
对客户的寻址方案或策略没有任何限制。请注意，SP可能会限制来自给定客户站点的路由数量，或者根据此类路由的数量收取不同的费用，并且此类限制可能会影响客户的寻址方案。特别是，促进每个站点的路由聚合的寻址方案将最有效地利用SP的资源，这可能反映在SP的收费政策中。
Interoperability should be ensured by proper implementation of the published standards.
应通过适当实施已发布的标准来确保互操作性。
Direct PE-PE interworking over the SP backbone with other VPN solutions is not supported.
不支持通过SP主干网与其他VPN解决方案直接进行PE-PE互通。
As all the different types of L3VPNs are IP networks, they can of course interwork in the same way that any two IP networks can interwork. For example, a single site can contain a CE router of one VPN scheme and a CE router of another VPN scheme, and these CE routers could be IGP peers, or they might even be the same CE router. This would result in the redistribution of routes from one type of VPN to the other, providing the necessary interworking.
由于所有不同类型的L3VPN都是IP网络，它们当然可以像任何两个IP网络一样互通。例如，单个站点可以包含一个VPN方案的CE路由器和另一个VPN方案的CE路由器，并且这些CE路由器可以是IGP对等方，或者甚至可能是同一个CE路由器。这将导致从一种类型的VPN到另一种类型的VPN的路由重新分配，从而提供必要的互通。
The architecture and protocols do not restrict the link layer or the physical layer in any manner.
体系结构和协议不以任何方式限制链路层或物理层。
Temporary access via PPP is possible, using industry standard PPP-based authentication mechanisms. For example:
使用基于PPP的行业标准认证机制，可以通过PPP进行临时访问。例如：
- A dial-up user (or other PPP user) is authenticated by the PE, using the SP's AAA server, based on a login string or on the number dialed.
- 拨号用户（或其他PPP用户）由PE根据登录字符串或拨打的号码，使用SP的AAA服务器进行身份验证。
- The SP's AAA server returns a VPN-id to PE.
- SP的AAA服务器将VPN id返回给PE。
- The PE assigns the user to a VRF, based on that VPN-id.
- PE根据该VPN-id将用户分配给VRF。
- The user is then authenticated by a AAA server within the VPN (i.e., managed by the customer rather than by the SP). This AAA server would typically be addressed through the VRF (i.e., may be in VPN's private address space).
- 然后，用户由VPN内的AAA服务器进行身份验证（即，由客户而不是SP管理）。该AAA服务器通常通过VRF寻址（即，可能位于VPN的专用地址空间中）。
- The user gets disconnected if either authentication step is unsuccessful.
- 如果其中一个身份验证步骤不成功，则用户将断开连接。
IPsec access to a VRF is also possible. In this case, the security association is between the end user and the SP.
也可以通过IPsec访问VRF。在这种情况下，安全关联位于最终用户和SP之间。
In these ways, a user can access a BGP/MPLS IP VPN via the public Internet.
通过这些方式，用户可以通过公共互联网访问BGP/MPLS IP VPN。
There is no explicit support for mobility, other than what is stated above.
除上述内容外，没有明确支持流动性。
Homing of a CE to two or more PEs is fully supported, whether or not the PEs are on the same SP network.
无论PEs是否在同一SP网络上，都完全支持将CE归零到两个或多个PEs。
If a CE is connected to two or more PEs, all its PE/CE links can be used to carry traffic in both directions. In particular, traffic from different ingress PEs to a particular CE may arrive at that CE over different PE/CE links. This depends on the backbone network routing between the CE and the various ingress PEs.
如果一个CE连接到两个或多个PE，则其所有PE/CE链路可用于承载双向流量。特别地，从不同入口PEs到特定CE的业务可以通过不同的PE/CE链路到达该CE。这取决于CE和各种入口PE之间的主干网络路由。
If a VRF on a particular ingress PE contains several routes to a particular destination, then traffic from that ingress PE can be split among these routes. If these routes end with different PE/CE links, then traffic from that ingress PE will be split among those links.
如果特定入口PE上的VRF包含到特定目的地的多条路由，则来自该入口PE的流量可以在这些路由之间分割。如果这些路由以不同的PE/CE链路结束，则来自该入口PE的流量将在这些链路之间分配。
BGP contains a multitude of knobs that allow an SP to control the traffic sent on one PE/CE link as opposed to the other. One can also make use of the Link Bandwidth extended community [BGP-EXT-COMM] to control how traffic is distributed among multiple egress PE/CE links.
BGP包含多个旋钮，允许SP控制一条PE/CE链路上发送的流量，而不是另一条。还可以利用链路带宽扩展社区[BGP-EXT-COMM]来控制流量如何分布在多个出口PE/CE链路之间。
The VPN scheme is of course compatible with the use of traffic engineering techniques, Resource Reservation Protocol - Traffic Engineering (RSVP-TE) based or otherwise, in the backbone network.
VPN方案当然与主干网中基于或其他方式的流量工程技术、资源预留协议-流量工程（RSVP-TE）的使用兼容。
Internet access and VPN access are possible from the same site. This is even possible over the same interface, as long as the VPN's internal addresses are distinct from the addresses of the systems that must be reached via the Internet. This requires only that Internet routes as well as VPN routes be imported into the VRF associated with that interface. This may be as simple as putting a default route to the Internet into that VRF.
可以从同一站点访问Internet和VPN。这甚至可以通过相同的接口实现，只要VPN的内部地址与必须通过Internet访问的系统地址不同。这只需要将Internet路由和VPN路由导入与该接口关联的VRF。这可能很简单，只需将到Internet的默认路由放入该VRF即可。
The "route to the Internet" that is in a particular VRF need not lead directly to the Internet; it may lead to a firewall or other security device at another site of the VPN. The VPN customer can cause this to happen simply by exporting a default route from the site with the firewall. Generally, a site with a firewall will use a different virtual interface for Internet access than for VPN access, since the firewall needs to distinguish the "clean interface" from the "dirty interface".
特定VRF中的“互联网路线”无需直接通向互联网；它可能导致VPN的另一个站点出现防火墙或其他安全设备。VPN客户只需从带有防火墙的站点导出默认路由，就可以实现这一点。通常，带有防火墙的站点将使用不同于VPN访问的虚拟接口进行Internet访问，因为防火墙需要区分“干净接口”和“脏接口”。
In such a configuration, the customer would export his routes to the Internet via the firewall's dirty interface, but would export the same routes to the VPN via the clean interface. Thus, all traffic from the Internet would come through the dirty interface, then through the firewall, and possibly go to another VPN site though the clean interface. This also allows any necessary Network Address Translation (NAT) functionality to be done in the firewall.
在这种配置中，客户将通过防火墙的脏接口将其路由导出到Internet，但将通过干净接口将相同的路由导出到VPN。因此，来自互联网的所有流量都将通过肮脏的接口，然后通过防火墙，并可能通过干净的接口进入另一个VPN站点。这还允许在防火墙中执行任何必要的网络地址转换（NAT）功能。
Any externally provided service can be accessed from the VPN, provided that it can be addressed with an address that is not otherwise in use within the VPN. Access can be firewalled or non-firewalled. If the client accessing the service does not have a globally unique IP address, and a single server provides a service to multiple VPNs, NAT will have to be applied to the client's packets before they reach the server. This can be done at a customer site, or by a VRF-specific NAT function in a PE router.
任何外部提供的服务都可以从VPN访问，前提是可以使用VPN中未使用的地址对其进行寻址。访问可以是防火墙或非防火墙。如果访问服务的客户端没有全局唯一的IP地址，并且单个服务器向多个VPN提供服务，则必须在客户端的数据包到达服务器之前对其应用NAT。这可以在客户站点完成，也可以通过PE路由器中特定于VRF的NAT功能完成。
Routing through the backbone is independent of the VPN scheme and is unaffected by the presence or absence of VPNs. The only impact is that the backbone routing must carry routes to the PE routers.
通过主干网的路由独立于VPN方案，不受VPN存在与否的影响。唯一的影响是主干路由必须携带路由到PE路由器。
The VPN routes themselves are carried in BGP as a distinct address family, different than the address family that is used to carry "ordinary" IP routes. These routes are passed from PE router to Route Reflector to PE router, and are never seen by the P routers. The Route Reflectors that carry the VPN routes can be entirely separate from the Route Reflectors that carry the "ordinary" IP routes.
VPN路由本身在BGP中作为一个不同的地址族进行传输，不同于用于传输“普通”IP路由的地址族。这些路由从PE路由器传递到路由反射器再到PE路由器，P路由器永远看不到这些路由。承载VPN路由的路由反射器可以与承载“普通”IP路由的路由反射器完全分离。
The fact that two PE routers support a common VPN does not require those PE routers to form an IGP routing adjacency between themselves. The number of adjacencies in the backbone IGP is independent of and unrelated to the number of VPNs supported by any set of PE routers.
两个PE路由器支持一个公共VPN的事实并不要求这些PE路由器在它们之间形成IGP路由邻接。主干IGP中的邻接数独立于任何一组PE路由器支持的VPN数，且与之无关。
No VPN-specific protection and restoration mechanisms are needed; these are general routing considerations, and the VPN scheme is compatible with any protection and restoration mechanisms that may be available.
不需要特定于VPN的保护和恢复机制；这些是一般路由考虑事项，VPN方案与任何可用的保护和恢复机制兼容。
The SP does not manage the customer's IGP in any way, and routes are never leaked between the SP's IGP and any customer's IGP.
SP不以任何方式管理客户的IGP，SP的IGP和任何客户的IGP之间的路由从不泄漏。
If the PE/CE protocol is EBGP, the SP and the customer do not ever participate in a common IGP.
如果PE/CE协议为EBGP，则SP和客户永远不会参与公共IGP。
Generally, this means replacement of an existing legacy backbone with VPN backbone. The general migration mechanism would be to hook up the sites one at a time to the VPN backbone, and to start giving the routes via the VPN backbone preference to routes via the legacy backbone. Details depend on the legacy backbone's IGP. In general, one would have to manipulate the IGP metrics to provide the proper route preference.
通常，这意味着用VPN主干替换现有的传统主干。一般的迁移机制是一次将一个站点连接到VPN主干网，并开始将通过VPN主干网的路由优先于通过传统主干网的路由。详细信息取决于传统主干网的IGP。一般来说，必须操纵IGP度量以提供适当的路由偏好。
If the legacy backbone routing protocol is OSPF, then migration is best done with OSPF as the PE/CE protocol and the PE supporting the [VPN-OSPF] procedures, OR with BGP as the PE/CE protocol, and the CE supporting the BGP/OSPF interaction specified in [VPN-OSPF].
如果传统主干路由协议是OSPF，那么迁移最好使用OSPF作为PE/CE协议，PE支持[VPN-OSPF]过程，或者使用BGP作为PE/CE协议，CE支持[VPN-OSPF]中指定的BGP/OSPF交互。
With other legacy backbone routing protocols, the proper metrics must be set at the point (PE or CE) where the BGP routes from the SP network are being redistributed into the legacy IGP.
对于其他传统主干路由协议，必须在SP网络的BGP路由重新分配到传统IGP的点（PE或CE）设置适当的度量。
There is no upper limit on the number of VPNs per SP network, as there is no one box in the SP network that needs to know of all VPNs. Knowledge of a particular VPN is confined to the PE routers that attach to sites in that VPN, and to the BGP Route Reflectors that receive routing data from those PEs; other systems maintain no state at all for the VPN. Note though that there is no need for any one Route Reflector to know of all VPNs.
每个SP网络的VPN数量没有上限，因为SP网络中没有一个框需要知道所有VPN。特定VPN的知识仅限于连接到该VPN中站点的PE路由器，以及从这些PE接收路由数据的BGP路由反射器；其他系统根本不维护VPN的状态。但请注意，任何一个路由反射器都不需要知道所有VPN。
If the SP is providing the VPN service over an MPLS backbone, then the backbone IGP must carry a host route for every Label Switched Path (LSP) egress node within the routing domain. Every PE router in the routing domain is an LSP egress node. If there are VPNs attached to PE routers that are within the routing domain, as well as PE routers that are in some second routing domain, then the border routers leading towards the second routing domain will also be LSP egress nodes. Thus, the sum of the number of PE routers plus number of border routers within a routing domain is limited by the number of routes that can be carried within the domain's IGP. This does not seem to create any practical scalability issue.
如果SP通过MPLS主干提供VPN服务，则主干IGP必须为路由域内的每个标签交换路径（LSP）出口节点携带主机路由。路由域中的每个PE路由器都是LSP出口节点。如果存在连接到路由域内的PE路由器的VPN，以及在某个第二路由域中的PE路由器，则通向第二路由域的边界路由器也将是LSP出口节点。因此，路由域内的PE路由器的数量加上边界路由器的数量之和受到可在域的IGP内承载的路由的数量的限制。这似乎不会产生任何实际的可伸缩性问题。
There is no upper limit on the number of site interfaces per VPN, as state for a particular interface is maintained only at the PE router to which that interface attaches. The number of site interfaces per VPN at a given PE router is limited only by the number of interfaces that that PE router can support.
每个VPN的站点接口数量没有上限，因为特定接口的状态仅在该接口所连接的PE路由器上维护。给定PE路由器上每个VPN的站点接口数量仅受该PE路由器可支持的接口数量的限制。
The number of routes per VPN is constrained only by the number of routes that can be supported in BGP, the number of routes that can be maintained in the PEs that attach to that VPN, and the number of routes that can be maintained in the BGP Route Reflectors that hold the routes of that VPN.
每个VPN的路由数仅受BGP中可支持的路由数、连接到该VPN的PEs中可维护的路由数以及持有该VPN路由的BGP路由反射器中可维护的路由数的限制。
The major constraint in considering scalability is the number of routes that a given PE can support. In general, a given PE can support as many VPNs as it has interfaces (including virtual interfaces or "sub-interfaces", not just physical interfaces), but it is constrained in the total number of routes it can handle. The number of routes a given PE must handle depends on the particular set of VPNs it attaches to, and the number of routes in each such VPN, and the number of "non-VPN" Internet routes (if any) that it must also handle.
考虑可伸缩性的主要限制是给定PE可以支持的路由数量。一般来说，一个给定的PE可以支持尽可能多的VPN，因为它有接口（包括虚拟接口或“子接口”，而不仅仅是物理接口），但它可以处理的路由总数受到限制。给定PE必须处理的路由数取决于其连接到的特定VPN集、每个此类VPN中的路由数以及它还必须处理的“非VPN”Internet路由数（如果有）。
The SP may need to engage in significant planning to ensure that these limits are not often reached. If these limits are reached, it may be necessary either to replace the PE with one of larger capacity or to reorganize the way in which access links lead from CEs to PEs,
SP可能需要进行重大规划，以确保不经常达到这些限制。如果达到这些限制，可能需要用更大容量的PE替换PE，或者重新组织从CE到PE的接入链路的方式，
in order to better concentrate the set of access links from sites that are in the same VPN. Rehoming a site to a different PE may not involve actual rewiring; if the access technology is switched, this is a matter of provisioning, but may still be a significant undertaking. If it is necessary to have downtime while performing the rehoming, the customer is impacted as well. Rehoming can also be done "virtually", by creating a layer 2 tunnel from a CE's "old" PE to its "new" PE.
为了更好地集中同一VPN中站点的访问链接集。将现场重新安置到不同的PE可能不涉及实际的重新布线；如果接入技术被切换，这是一个供应问题，但可能仍然是一项重大任务。如果在执行重新定位时需要停机，客户也会受到影响。通过创建一个从CE的“旧”PE到其“新”PE的第2层隧道，还可以“虚拟”地进行再命名。
An important consideration to remember is that one may have any number of INDEPENDENT BGP systems carrying VPN routes. This is unlike the case of the Internet, where the Internet BGP system must carry all the Internet routes. The difference stems from the fact that all Internet addresses must be reachable from each other, but a given VPN address is only supposed to be reachable from other addresses in the same VPN.
需要记住的一个重要因素是，可以有任意数量的独立BGP系统承载VPN路由。这与互联网不同，互联网BGP系统必须承载所有互联网路由。这种差异源于这样一个事实，即所有Internet地址都必须可以相互访问，但给定的VPN地址只能从同一VPN中的其他地址访问。
Scalability is also affected by the rate of changes in the reachability advertisements from CE to PE, as changes reported by a CE to its attached PE may be propagated to the other PEs. BGP mechanisms to control the rate of reported changes should be used by the SP.
可伸缩性还受到从CE到PE的可达性广告中的变化率的影响，因为CE向其连接的PE报告的变化可能会传播到其他PE。SP应使用BGP机制来控制报告的更改速率。
Another constraint on the number of VPNs that can be supported by a particular PE router is based on the number of routing instances that the PE router can support. If the PE/CE routing is static, or is done by BGP, the number of routing protocol instances in a PE device does not depend on the number of CEs supported by the PE device. In the case of BGP, a single BGP protocol instance can support all CEs that exchange routing information using BGP. If the PE/CE router is done via RIP or OSPF, then the PE must maintain one RIP or OSPF instance per VRF. Note that the number of routing instances that can be supported may be different for different routing protocols.
对特定PE路由器可支持的VPN数量的另一个限制是基于PE路由器可支持的路由实例数量。如果PE/CE路由是静态的，或由BGP完成，则PE设备中路由协议实例的数量不取决于PE设备支持的CE数量。对于BGP，单个BGP协议实例可以支持使用BGP交换路由信息的所有CE。如果PE/CE路由器通过RIP或OSPF完成，则PE必须为每个VRF维护一个RIP或OSPF实例。请注意，对于不同的路由协议，可以支持的路由实例的数量可能不同。
Inter-AS scenarios constructed according to option (b) of section 10 of [BGP-MPLS-IP-VPN] require BGP "border routers" to hold the routes for a set of VPNs. If two SPs share in a small number of VPNs, a single border router between them provides adequate capacity. As the number of shared VPNs increases, additional border routers may be needed to handle the increased number of routes. Again, no single border router would handle all the routes from all the VPNs, so an increase in the number of VPNs can always be supported by adding more border routers.
根据[BGP-MPLS-IP-VPN]第10节选项（b）构建的AS间场景要求BGP“边界路由器”保留一组VPN的路由。如果两个SP共享少量VPN，则它们之间的单个边界路由器可提供足够的容量。随着共享VPN数量的增加，可能需要额外的边界路由器来处理增加的路由数量。同样，没有一个单独的边界路由器可以处理来自所有VPN的所有路由，因此，通过添加更多边界路由器始终可以支持VPN数量的增加。
Inter-AS scenarios constructed according to option (c) of section 10 of [BGP-MPLS-IP-VPN] eliminate the need for border routers to contain VPN routes (thus improving scalability in that dimension), but at the cost of requiring that each AS have a route to the PEs in the others.
根据[BGP-MPLS-IP-VPN]第10节选项（c）构建的AS间场景消除了边界路由器包含VPN路由的需要（从而提高了该维度的可扩展性），但代价是要求每个AS都有一条到其他AS中PE的路由。
(Inter-AS scenarios constructed according to option (a) of section 10 of [BGP-MPLS-IP-VPN] do not scale well.)
（根据[BGP-MPLS-IP-VPN]第10节选项（a）构建的AS间场景无法很好地扩展。）
The solution of [BGP-MPLS-IP-VPN] is intended to simplify CE and site operations, by hiding the structure of the rest of the VPN from a site, and by hiding the structure of the backbone. Thus, CEs need have only a single sub-interface to the backbone, CEs at one site need not even be aware of the existence of CEs at another, and CEs at one site need not be routing peers of CEs at another. CEs are never routing peers of P routers. These factors help to scale the customer's network, but limiting the number of adjacencies each CE must see, and by limiting the total number of links that the customer's IGP must handle.
[BGP-MPLS-IP-VPN]的解决方案旨在通过对站点隐藏VPN其余部分的结构以及隐藏主干结构来简化CE和站点操作。因此，CE只需要有一个到主干的子接口，一个站点的CE甚至不需要知道另一个站点的CE的存在，并且一个站点的CE不需要是另一个站点的CE的路由对等方。CE从来不是P路由器的路由对等方。这些因素有助于扩展客户的网络，但限制每个CE必须看到的邻接数，并限制客户的IGP必须处理的链路总数。
The solution of [BGP-MPLS-IP-VPN] is also intended to simplify the SP's VPN provisioning, so that potentially the SP will have to do little more than say which sites belong to which VPNs. However, as the system scales up, planning is needed to determine which PEs should home which VPNs, and which BGP RRs should take which VPNs' routing information.
[BGP-MPLS-IP-VPN]的解决方案还旨在简化SP的VPN配置，因此SP可能只需说出哪些站点属于哪些VPN即可。但是，随着系统规模的扩大，需要进行规划，以确定哪些PEs应驻留哪些VPN，哪些BGP RRs应获取哪些VPN的路由信息。
P routers maintain NO per-VPN state at all; the only requirement on them is to maintain routes to the PE routers. When MPLS is used, a P router must also maintain one multipoint-to-point LSP for each such route.
P路由器根本不维护每个VPN状态；对它们的唯一要求是维护到PE路由器的路由。当使用MPLS时，P路由器还必须为每个这样的路由维护一个多点对点LSP。
However, certain VPN multicast schemes require per-multicast-group state in the P routers, summed over all VPNs. Others require only no state in the P routers at all, but will result in sending more unnecessary traffic. The complete set of tradeoffs for multicast is not that well understood yet.
然而，某些VPN多播方案要求P路由器中的每个多播组状态在所有VPN上求和。另一些只需要在P路由器中根本不需要状态，但会导致发送更多不必要的流量。对于多播的一整套折衷方案还不是很清楚。
Note that as the scaling of a particular PE is primarily a matter of the total number of routes that it must maintain, scalability is facilitated if the addresses are assigned in a way that permits them to be aggregated (i.e., if the customers have a sensible addressing plan).
请注意，由于特定PE的扩展主要是其必须维护的路由总数的问题，因此，如果以允许聚合地址的方式分配地址（即，如果客户有合理的寻址计划），则可促进可扩展性。
When a dynamic routing protocol is run on the link between a CE router and a PE router, routing instability in the private network may have an effect on the PE router. For example, an unusually large number of routing updates could be sent from the CE router to the PE router, placing an unusually large processing load on the PE router.
当在CE路由器和PE路由器之间的链路上运行动态路由协议时，专用网络中的路由不稳定性可能会对PE路由器产生影响。例如，可能会从CE路由器向PE路由器发送异常大量的路由更新，从而给PE路由器带来异常大的处理负载。
This issue can be mitigated via resource partitioning in the PE, in order to limit the amount of resources (e.g., CPU and memory) that any one VPN is permitted to use in PE routers. Also, rate limits may be applied to the routing traffic sent from the CE to the PE.
这个问题可以通过PE中的资源分区来缓解，以限制允许任何一个VPN在PE路由器中使用的资源量（例如CPU和内存）。此外，速率限制可应用于从CE发送到PE的路由业务。
Alternately, when this problem is detected, the CE-to-PE interface may be shut down.
或者，当检测到此问题时，CE至PE接口可能会关闭。
The provision of appropriate QoS capabilities may require any combination of the following:
提供适当的QoS能力可能需要以下任意组合：
- QoS in the access network.
- 接入网的QoS。
- Admission control (policing) by the PE router on the ingress access links.
- PE路由器在入口访问链路上进行准入控制（监管）。
- Traffic conditioning (shaping) by the PE router on the ingress access links.
- PE路由器在入口接入链路上进行流量调节（整形）。
- Traffic engineering in the backbone.
- 主干网中的交通工程。
- Intserv/diffserv classification by the PE, for traffic arriving from the CE. Once the PE classifies the user packets, this classification needs to be preserved in the encapsulation (MPLS or IP) used to send the packet across the backbone.
- PE对来自CE的流量进行的Intserv/diffserv分类。一旦PE对用户数据包进行分类，就需要在用于跨主干发送数据包的封装（MPLS或IP）中保留该分类。
- Differentiated Services Codepoint (DSCP) mapping.
- 区分服务代码点（DSCP）映射。
- DSCP transparency.
- DSCP透明度。
- Random Early Discard in the backbone.
- 主干中的随机早期丢弃。
None of these features are VPN-specific. The ability to support them depends on whether the features are available on the edge and core platforms, rather than on any particular VPN scheme.
这些功能都不是特定于VPN的。支持它们的能力取决于边缘和核心平台上是否有这些功能，而不是取决于任何特定的VPN方案。
MPLS support for differentiated services is detailed in RFC 3270 [MPLS-DIFFSERV]. DSCP mapping and transparency are covered in section 2.6 of that document.
RFC 3270[MPLS-DIFFSERV]中详细介绍了MPLS对区分服务的支持。该文件第2.6节介绍了DSCP映射和透明度。
It is possible to use traffic engineering to provide, e.g., guaranteed bandwidth between two PEs for the traffic of a given VPN. The VRF entries for that VPN in each PE need to be modified so that the traffic to the other PE is directed onto the traffic-engineered path. How this is done is a local matter.
例如，可以使用流量工程为给定VPN的流量在两个PE之间提供有保证的带宽。需要修改每个PE中该VPN的VRF条目，以便将到另一个PE的流量定向到流量工程路径上。如何做到这一点是当地的事情。
BGP/MPLS IP VPNs can support both the "hose model" and the "pipe model" of QoS. In the "pipe model", a particular quality of service (e.g., a guaranteed amount of bandwidth) would be applied to all or some of the packets traveling between a given pair of CEs. In the "hose model", a particular quality of service (e.g., a guaranteed
BGP/MPLS IP VPN可以支持QoS的“软管模型”和“管道模型”。在“管道模型”中，特定的服务质量（例如，保证的带宽量）将应用于在给定的一对ce之间传输的所有或部分分组。在“软管型号”中，特定的服务质量（例如，有保证的
amount of bandwidth) would be applied to all traffic to or from a particular CE, irrespective of which other CE the traffic is going to or coming from. Since BGP/MPLS IP VPNs do not usually make use of CE-CE tunnels, the hose model is the more natural fit. Providing the pipe model would require the use of traffic engineering to explicitly create the necessary tunnels.
带宽量）将应用于到或来自特定CE的所有通信量，而不管该通信量将去往或来自哪个其他CE。由于BGP/MPLS IP VPN通常不使用CE-CE隧道，因此软管模型更适合使用。提供管道模型需要使用交通工程来明确创建必要的隧道。
Many of the requirements specified in [L3VPN-REQS] stipulate that the Network Monitoring System (NMS) should support SLA monitoring and verification between the SP and the various customers by measurement of the indicators defined within the context of the SLA. The measurement of these indicators (i.e., counters) can be achieved when BGP/MPLS IP VPNs are used by employing a combination of the Management Information Base (MIB) module designed for BGP/MPLS IP VPNs [L3VPN-MIB] as well as other standard MIB modules such as the IF-MIB [IF-MIB]. Devices supporting these MIB modules can calculate SLAs based on real-time performance measurements using indicators and threshold crossing alerts. Devices can make these thresholds configurable either via a management interface such as SNMP.
[L3VPN-REQS]中规定的许多要求规定，网络监控系统（NMS）应通过测量SLA上下文中定义的指标，支持SP和各种客户之间的SLA监控和验证。当使用为BGP/MPLS IP VPN[L3VPN-MIB]设计的管理信息库（MIB）模块以及其他标准MIB模块（如IF-MIB[IF-MIB]）的组合来使用BGP/MPLS IP VPN时，可以实现这些指标（即计数器）的测量。支持这些MIB模块的设备可以基于使用指示器和阈值交叉警报的实时性能测量来计算SLA。设备可以通过管理接口（如SNMP）配置这些阈值。
The L3VPN Requirements document [L3VPN-REQS] stipulates that the term "Provider Provisioned VPN" refers to VPNs for which the service provider participates in management and provisioning of the VPN. RFC BGP/MPLS IP VPNs can be provisioned and managed to meet these requirements. The following subsections will outline how devices supporting BGP/MPLS IP VPNs can satisfy these requirements.
L3VPN要求文件[L3VPN-REQS]规定，“提供商提供的VPN”一词是指服务提供商参与VPN管理和提供的VPN。可以配置和管理RFC BGP/MPLS IP VPN以满足这些要求。以下小节将概述支持BGP/MPLS IP VPN的设备如何满足这些要求。
The SP manages all the VPN-specific information in the PE device. This can be done using the MIB designed for BGP/MPLS IP VPNs [L3VPN-MIB], in combination with other standard MIB modules such as IF-MIB [IF-MIB], and other MPLS MIB modules [LSRMIB], [LDPMIB], [TEMIB], [FTNMIB].
SP管理PE设备中所有特定于VPN的信息。这可以通过使用为BGP/MPLS IP VPN[L3VPN-MIB]设计的MIB，结合其他标准MIB模块（如IF-MIB[IF-MIB]）和其他MPLS MIB模块[LSRMIB]、[LDPMIB]、[TEMIB]、[FTNMIB]来实现。
Devices supporting BGP/MPLS IP VPNs that employ the management interface characteristics described above will also support the ITU-T Telecommunications Management Network Model "FCAPS" functionalities as required in the L3VPN Requirements document. These include Fault, Configuration, Accounting, Provisioning, and Security.
支持采用上述管理接口特征的BGP/MPLS IP VPN的设备也将支持L3VPN要求文件中要求的ITU-T电信管理网络模型“FCAPS”功能。这些包括故障、配置、记帐、资源调配和安全性。
In BGP/MPLS IP VPNs, the SP is not required to manage the CE devices. However, if it is desired for the SP to do so, the SP may manage CE devices from a central site, provided that a route to the central site is exported into the CE's VPN, and the central site is in a VPN into which the routes to the managed CE devices have been imported.
在BGP/MPLS IP VPN中，SP不需要管理CE设备。但是，如果希望SP这样做，SP可以从中心站点管理CE设备，前提是将到中心站点的路由导出到CE的VPN中，并且中心站点位于已导入到受管CE设备的路由的VPN中。
This is a form of extranet.
这是外联网的一种形式。
If the central site is managing CE devices from several VPNs, those CE devices must have mutually unique addresses. Note that this does not enable the CE devices from different VPNs to reach each other.
如果中心站点正在管理来自多个VPN的CE设备，则这些CE设备必须具有相互唯一的地址。请注意，这不允许来自不同VPN的CE设备相互连接。
The CE devices have no VPN-specific information in them. Hence the fact that they are connected together into a VPN does not require them to have any VPN-specific management MIB modules or capabilities.
CE设备中没有特定于VPN的信息。因此，它们连接在一起形成VPN的事实并不要求它们具有任何特定于VPN的管理MIB模块或功能。
CE devices may be managed from within the VPN, transparently to the SP. The CE devices have no VPN-specific information in them, and the fact that they are tied together into a VPN does not impact the customer's management of them.
CE设备可以从VPN内部对SP透明地进行管理。CE设备中没有特定于VPN的信息，并且它们被绑定到VPN中这一事实不会影响客户对它们的管理。
Customer access to a PE device is totally at the discretion of the SP, but is not required by the solution. The PE device is a routing peer of a CE device, and can be pinged, etc.
客户对PE设备的访问完全由SP决定，但解决方案并不要求客户访问PE设备。PE设备是CE设备的路由对等方，可以ping等。
If a customer is permitted to access the PE router for management purposes, the functions available to any particular customer need to be strictly controlled, and the use of resource partitioning may be appropriate.
如果允许客户出于管理目的访问PE路由器，则需要严格控制任何特定客户可用的功能，并且可以适当使用资源分区。
Network management traffic from the CE to the PE may be rate limited (for example, to prevent network management traffic from CE to PE to be used in a DoS attack).
从CE到PE的网络管理流量可能受到速率限制（例如，防止在DoS攻击中使用从CE到PE的网络管理流量）。
Many thanks to Jeremy De Clercq, Luyuan Fang, Dave McDysan, Ananth Nagarajan, Yakov Rekhter, and Muneyoshi Suzuki, for their comments, criticisms, and help in preparing this document. Thanks also to Thomas Nadeau for his help with the section on management, to Francois LeFaucheur for his help with the section on QoS, and to Ross Callon for his review of the document.
非常感谢Jeremy De Clercq、方卢元、戴夫·麦克迪桑、阿南·纳加拉扬、雅科夫·雷克特和铃木木木义吉在编写本文件过程中的评论、批评和帮助。还要感谢Thomas Nadeau对管理部分的帮助，感谢Francois LeFaucheur对QoS部分的帮助，感谢Ross Callon对文档的审阅。
[BGP-EXT-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-EXT-COMM]Sangli，S.，Tappan，D.，和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[BGP-MPLS-IP-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[BGP-MPLS-IP-VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[L3VPN-FRMWRK] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[L3VPN-FRMWRK]Callon，R.和M.Suzuki，“第三层提供商提供的虚拟专用网络（PPVPN）框架”，RFC 4110，2005年7月。
[L3VPN-REQS] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[L3VPN-REQS]Carugi，M.和D.McDysan，“第3层提供商提供的虚拟专用网络（PPVPN）的服务要求”，RFC 4031，2005年4月。
[L2VPN-SEC-FRMWRK] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[L2VPN-SEC-FRMWRK]方，L.“提供商提供的虚拟专用网络（PPVPN）的安全框架”，RFC 4111，2005年7月。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", Work in Progress, February 2004.
[VPN-OSPF]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“OSPF作为BGP/MPLS VPN中的PE/CE协议”，正在进行的工作，2004年2月。
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", Work in Progress, March 2004.
[OSPF-2547-DNBIT]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“使用LSA选项位防止BGP/MPLS IP VPN中的循环”，正在进行的工作，2004年3月。
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., and C. Sargor, "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in Progress, March 2004.
[MPLS/BGP IPsec]Rosen，E.，De Clercq，J.，Paridaens，O.，T'Joens，Y.，和C.Sargor，“在BGP/MPLS IP VPN中使用PE-PE IPsec隧道的体系结构”，正在进行的工作，2004年3月。
[BGP-MPLS-MCAST-VPN] Rosen, E., Cai, Y., and IJ. Wijsnands, "Multicast in MPLS/BGP VPNs", Work in Progress, May 2004.
[BGP-MPLS-MCAST-VPN]Rosen，E.，Cai，Y.，和IJ。Wijsnands，“MPLS/BGP VPN中的多播”，正在进行的工作，2004年5月。
[CE-VERIF] Bonica, R., Rekhter, Y., Raszuk, R., Rosen, E., and D. Tappan, "CE-to-CE Member Verification for Layer 3 VPNs", Work in Progress, September 2003.
[CE-VERIF]Bonica，R.，Rekhter，Y.，Raszuk，R.，Rosen，E.，和D.Tappan，“第3层VPN的CE到CE成员验证”，正在进行的工作，2003年9月。
[FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
[FTNMIB]Nadeau，T.，Srinivasan，C.，和A.Viswanathan，“多协议标签交换（MPLS）转发等价类到下一跳标签转发条目（FEC到NHLFE）管理信息库（MIB）”，RFC 3814，2004年6月。
[IPSEC-VPN] De Clercq, J., Paridaens, O., Krywaniuk, A., and C. Wang, "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress, February 2004.
[IPSEC-VPN]De Clercq，J.，Paridaens，O.，Krywaniuk，A.，和C.Wang，“使用IPSEC的基于提供商提供的CE的虚拟专用网络的体系结构”，正在进行的工作，2004年2月。
[LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[LDPMIB]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
[LSRMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[LSRMIB]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。
[MPLS-DIFFSERV] 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.
[MPLS-DIFFSERV]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[L3VPN-MIB] Nadeau, T. and H. Van Der Linde, "MPLS/BGP Virtual Private Network Management Information Base Using SMIv2", Work in Progress, August 2004.
[L3VPN-MIB]Nadeau，T.和H.Van Der Linde，“使用SMIv2的MPLS/BGP虚拟专用网络管理信息库”，正在进行的工作，2004年8月。
[IF-MIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[IF-MIB]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[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月。
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[TEMIB]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[VR-VPN] Knight, P., Ould-Brahim, H., and B. Gleeson, "Network Based IP VPN Architecture using Virtual Routers", Work in Progress, April 2004.
[VR-VPN]Knight，P.，Ould Brahim，H.，和B.Gleeson，“使用虚拟路由器的基于网络的IP VPN体系结构”，正在进行的工作，2004年4月。
Author's Address
作者地址
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。