Network Working Group E. Rosen
Request for Comments: 2547 Y. Rekhter
Category: Informational Cisco Systems, Inc.
March 1999
Network Working Group E. Rosen
Request for Comments: 2547 Y. Rekhter
Category: Informational Cisco Systems, Inc.
March 1999
BGP/MPLS VPNs
BGP/MPLS 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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.
本文档描述了一种方法，通过该方法，具有IP主干的服务提供商可以为其客户提供VPN（虚拟专用网络）。MPLS（多协议标签交换）用于在主干上转发数据包，BGP（边界网关协议）用于在主干上分发路由。此方法的主要目标是支持企业网络IP主干服务的外包。它以一种对企业来说很简单的方式实现，同时对服务提供商来说仍然是可伸缩和灵活的，同时允许服务提供商增加价值。这些技术还可用于提供VPN，VPN本身向客户提供IP服务。
Table of Contents
目录
1 Introduction ....................................... 2
1.1 Virtual Private Networks ........................... 2
1.2 Edge Devices ....................................... 3
1.3 VPNs with Overlapping Address Spaces ............... 4
1.4 VPNs with Different Routes to the Same System ...... 4
1.5 Multiple Forwarding Tables in PEs .................. 5
1.6 SP Backbone Routers ................................ 5
1.7 Security ........................................... 5
2 Sites and CEs ...................................... 6
3 Per-Site Forwarding Tables in the PEs .............. 6
3.1 Virtual Sites ...................................... 8
4 VPN Route Distribution via BGP ..................... 8
4.1 The VPN-IPv4 Address Family ........................ 9
4.2 Controlling Route Distribution ..................... 10
1 Introduction ....................................... 2
1.1 Virtual Private Networks ........................... 2
1.2 Edge Devices ....................................... 3
1.3 VPNs with Overlapping Address Spaces ............... 4
1.4 VPNs with Different Routes to the Same System ...... 4
1.5 Multiple Forwarding Tables in PEs .................. 5
1.6 SP Backbone Routers ................................ 5
1.7 Security ........................................... 5
2 Sites and CEs ...................................... 6
3 Per-Site Forwarding Tables in the PEs .............. 6
3.1 Virtual Sites ...................................... 8
4 VPN Route Distribution via BGP ..................... 8
4.1 The VPN-IPv4 Address Family ........................ 9
4.2 Controlling Route Distribution ..................... 10
4.2.1 The Target VPN Attribute ........................... 10
4.2.2 Route Distribution Among PEs by BGP ................ 12
4.2.3 The VPN of Origin Attribute ........................ 13
4.2.4 Building VPNs using Target and Origin Attributes ... 14
5 Forwarding Across the Backbone ..................... 15
6 How PEs Learn Routes from CEs ...................... 16
7 How CEs learn Routes from PEs ...................... 19
8 What if the CE Supports MPLS? ...................... 19
8.1 Virtual Sites ...................................... 19
8.2 Representing an ISP VPN as a Stub VPN .............. 20
9 Security ........................................... 20
9.1 Point-to-Point Security Tunnels between CE Routers . 21
9.2 Multi-Party Security Associations .................. 21
10 Quality of Service ................................. 22
11 Scalability ........................................ 22
12 Intellectual Property Considerations ............... 23
13 Security Considerations ............................ 23
14 Acknowledgments .................................... 23
15 Authors' Addresses ................................. 24
16 References ......................................... 24
17 Full Copyright Statement............................. 25
4.2.1 The Target VPN Attribute ........................... 10
4.2.2 Route Distribution Among PEs by BGP ................ 12
4.2.3 The VPN of Origin Attribute ........................ 13
4.2.4 Building VPNs using Target and Origin Attributes ... 14
5 Forwarding Across the Backbone ..................... 15
6 How PEs Learn Routes from CEs ...................... 16
7 How CEs learn Routes from PEs ...................... 19
8 What if the CE Supports MPLS? ...................... 19
8.1 Virtual Sites ...................................... 19
8.2 Representing an ISP VPN as a Stub VPN .............. 20
9 Security ........................................... 20
9.1 Point-to-Point Security Tunnels between CE Routers . 21
9.2 Multi-Party Security Associations .................. 21
10 Quality of Service ................................. 22
11 Scalability ........................................ 22
12 Intellectual Property Considerations ............... 23
13 Security Considerations ............................ 23
14 Acknowledgments .................................... 23
15 Authors' Addresses ................................. 24
16 References ......................................... 24
17 Full Copyright Statement............................. 25
Consider a set of "sites" which are attached to a common network which we may call the "backbone". Let's apply some policy to create a number of subsets of that set, and let's impose the following rule: two sites may have IP interconnectivity over that backbone only if at least one of these subsets contains them both.
考虑一组连接到公共网络的“站点”，我们称之为“骨干”。让我们应用一些策略来创建该集合的多个子集，并实施以下规则：只有当至少一个子集同时包含两个站点时，两个站点才能在该主干上具有IP互连。
The subsets we have created are "Virtual Private Networks" (VPNs). Two sites have IP connectivity over the common backbone only if there is some VPN which contains them both. Two sites which have no VPN in common have no connectivity over that backbone.
我们创建的子集是“虚拟专用网络”（VPN）。只有当存在包含这两个站点的VPN时，这两个站点才能通过公共主干网进行IP连接。两个没有共同VPN的站点在该主干上没有连接。
If all the sites in a VPN are owned by the same enterprise, the VPN is a corporate "intranet". If the various sites in a VPN are owned by different enterprises, the VPN is an "extranet". A site can be in more than one VPN; e.g., in an intranet and several extranets. We regard both intranets and extranets as VPNs. In general, when we use the term VPN we will not be distinguishing between intranets and extranets.
如果VPN中的所有站点都属于同一企业，则VPN是企业“内部网”。如果VPN中的各个站点属于不同的企业，则VPN是一个“外联网”。一个站点可以位于多个VPN中；e、 例如，在一个内部网和几个外部网中。我们将内部网和外部网都视为VPN。一般来说，当我们使用术语VPN时，我们不会区分内部网和外部网。
We wish to consider the case in which the backbone is owned and operated by one or more Service Providers (SPs). The owners of the sites are the "customers" of the SPs. The policies that determine
我们希望考虑骨干由一个或多个服务提供商（SPS）拥有和操作的情况。这些站点的所有者是SPs的“客户”。决定
whether a particular collection of sites is a VPN are the policies of the customers. Some customers will want the implementation of these policies to be entirely the responsibility of the SP. Other customers may want to implement these policies themselves, or to share with the SP the responsibility for implementing these policies. In this document, we are primarily discussing mechanisms that may be used to implement these policies. The mechanisms we describe are general enough to allow these policies to be implemented either by the SP alone, or by a VPN customer together with the SP. Most of the discussion is focused on the former case, however.
特定的站点集合是否为VPN是客户的策略。一些客户希望这些政策的实施完全由SP负责。其他客户可能希望自己实施这些政策，或与SP共同承担实施这些政策的责任。在本文件中，我们主要讨论可用于实施这些政策的机制。我们描述的机制非常通用，可以让这些策略由SP单独实施，也可以由VPN客户与SP一起实施。不过，大多数讨论都集中在前一种情况。
The mechanisms discussed in this document allow the implementation of a wide range of policies. For example, within a given VPN, we can allow every site to have a direct route to every other site ("full mesh"), or we can restrict certain pairs of sites from having direct routes to each other ("partial mesh").
本文件中讨论的机制允许执行广泛的政策。例如，在给定的VPN中，我们可以允许每个站点都有到其他站点的直接路由（“完全网格”），或者我们可以限制某些站点对彼此有直接路由（“部分网格”）。
In this document, we are particularly interested in the case where the common backbone offers an IP service. We are primarily concerned with the case in which an enterprise is outsourcing its backbone to a service provider, or perhaps to a set of service providers, with which it maintains contractual relationships. We are not focused on providing VPNs over the public Internet.
在本文中，我们对公共主干网提供IP服务的情况特别感兴趣。我们主要关注的是一个企业将其主干网外包给一个服务提供商，或者外包给一组服务提供商，并与之保持合同关系。我们并不专注于通过公共互联网提供VPN。
In the rest of this introduction, we specify some properties which VPNs should have. The remainder of this document outlines a VPN model which has all these properties. The VPN Model of this document appears to be an instance of the framework described in [4].
在本简介的其余部分中，我们将指定VPN应该具有的一些属性。本文档的其余部分概述了具有所有这些属性的VPN模型。本文档的VPN模型似乎是[4]中描述的框架的一个实例。
We suppose that at each site, there are one or more Customer Edge (CE) devices, each of which is attached via some sort of data link (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers.
我们假设在每个站点上有一个或多个客户边缘（CE）设备，每个设备通过某种数据链路（例如PPP、ATM、以太网、帧中继、GRE隧道等）连接到一个或多个提供商边缘（PE）路由器。
If a particular site has a single host, that host may be the CE device. If a particular site has a single subnet, that the CE device may be a switch. In general, the CE device can be expected to be a router, which we call the CE router.
如果特定站点具有单个主机，则该主机可能是CE设备。如果特定站点具有单个子网，则CE设备可能是交换机。一般来说，CE设备可以预期为路由器，我们称之为CE路由器。
We will say that a PE router is attached to a particular VPN if it is attached to a CE device which is in that VPN. Similarly, we will say that a PE router is attached to a particular site if it is attached to a CE device which is in that site.
我们会说，如果PE路由器连接到某个VPN中的CE设备，则它连接到该VPN。类似地，我们会说，如果PE路由器连接到某个站点中的CE设备，则它连接到该站点。
When the CE device is a router, it is a routing peer of the PE(s) to which it is attached, but is not a routing peer of CE routers at
当CE设备是路由器时，它是其所连接的PE的路由对等方，但不是CE路由器的路由对等方
other sites. Routers at different sites do not directly exchange routing information with each other; in fact, they do not even need to know of each other at all (except in the case where this is necessary for security purposes, see section 9). As a consequence, very large VPNs (i.e., VPNs with a very large number of sites) are easily supported, while the routing strategy for each individual site is greatly simplified.
其他网站。不同站点的路由器之间不直接交换路由信息；事实上，他们甚至根本不需要相互了解（除非出于安全目的需要了解，见第9节）。因此，很容易支持非常大的VPN（即具有非常多站点的VPN），同时大大简化了每个站点的路由策略。
It is important to maintain clear administrative boundaries between the SP and its customers (cf. [4]). The PE and P routers should be administered solely by the SP, and the SP's customers should not have any management access to it. The CE devices should be administered solely by the customer (unless the customer has contracted the management services out to the SP).
在SP及其客户之间保持清晰的管理边界非常重要（参见[4]）。PE和P路由器应由SP单独管理，SP的客户不应具有任何管理权限。CE设备应由客户单独管理（除非客户已将管理服务外包给SP）。
We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs.
我们假设任何两个不相交的VPN（即没有共同站点的VPN）可能有重叠的地址空间；对于不同的系统，相同的地址可以在不同的VPN中重复使用。只要给定的终端系统在其所属的VPN范围内具有唯一的地址，终端系统本身就不需要了解任何有关VPN的信息。
In this model, the VPN owners do not have a backbone to administer, not even a "virtual backbone". Nor do the SPs have to administer a separate backbone or "virtual backbone" for each VPN. Site-to-site routing in the backbone is optimal (within the constraints of the policies used to form the VPNs), and is not constrained in any way by an artificial "virtual topology" of tunnels.
在此模型中，VPN所有者没有要管理的主干网，甚至没有“虚拟主干网”。SP也不必为每个VPN管理单独的主干网或“虚拟主干网”。主干网中的站点到站点路由是最优的（在用于形成VPN的策略的约束范围内），并且不以任何方式受到隧道的人工“虚拟拓扑”的约束。
Although a site may be in multiple VPNs, it is not necessarily the case that the route to a given system at that site should be the same in all the VPNs. Suppose, for example, we have an intranet consisting of sites A, B, and C, and an extranet consisting of A, B, C, and the "foreign" site D. Suppose that at site A there is a server, and we want clients from B, C, or D to be able to use that server. Suppose also that at site B there is a firewall. We want all the traffic from site D to the server to pass through the firewall, so that traffic from the extranet can be access controlled. However, we don't want traffic from C to pass through the firewall on the way to the server, since this is intranet traffic.
虽然一个站点可能位于多个VPN中，但在所有VPN中，到该站点的给定系统的路由不一定相同。例如，假设我们有一个由站点A、B和C组成的内部网，以及一个由A、B、C和“外部”站点D组成的外部网。假设站点A有一台服务器，我们希望来自B、C或D的客户端能够使用该服务器。还假设站点B有一个防火墙。我们希望从站点D到服务器的所有流量都通过防火墙，这样来自外部网的流量就可以被访问控制。但是，我们不希望来自C的流量在到达服务器的过程中通过防火墙，因为这是内部网流量。
This means that it needs to be possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic
这意味着需要能够设置到服务器的两条路由。站点B和C使用的一条路线将交通直接带到站点A。站点D使用的第二条路线将交通带到站点A
instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A.
而是到站点B的防火墙。如果防火墙允许流量通过，那么它似乎是来自站点B的流量，并遵循到站点A的路径。
Each PE router needs to maintain a number of separate forwarding tables. Every site to which the PE is attached must be mapped to one of those forwarding tables. When a packet is received from a particular site, the forwarding table associated with that site is consulted in order to determine how to route the packet. The forwarding table associated with a particular site S is populated only with routes that lead to other sites which have at least one VPN in common with S. This prevents communication between sites which have no VPN in common, and it allows two VPNs with no site in common to use address spaces that overlap with each other.
每个PE路由器需要维护多个单独的转发表。PE连接到的每个站点都必须映射到其中一个转发表。当从特定站点接收到数据包时，将参考与该站点相关联的转发表以确定如何路由该数据包。与特定站点S关联的转发表仅填充指向至少有一个与S共用VPN的其他站点的路由。这会阻止没有共用VPN的站点之间的通信，并允许两个没有共用站点的VPN使用彼此重叠的地址空间。
The SP's backbone consists of the PE routers, as well as other routers (P routers) which do not attach to CE devices.
SP的主干网由PE路由器以及其他不连接到CE设备的路由器（P路由器）组成。
If every router in an SP's backbone had to maintain routing information for all the VPNs supported by the SP, this model would have severe scalability problems; the number of sites that could be supported would be limited by the amount of routing information that could be held in a single router. It is important to require therefore that the routing information about a particular VPN be present ONLY in those PE routers which attach to that VPN. In particular, the P routers should not need to have ANY per-VPN routing information whatsoever.
如果SP主干网中的每个路由器都必须维护SP支持的所有VPN的路由信息，那么该模型将存在严重的可扩展性问题；可支持的站点数量将受到单个路由器中可保存的路由信息量的限制。因此，重要的是要求有关特定VPN的路由信息仅存在于连接到该VPN的PE路由器中。特别是，P路由器不需要任何每VPN路由信息。
VPNs may span multiple service providers. We assume though that when the path between PE routers crosses a boundary between SP networks, it does so via a private peering arrangement, at which there exists mutual trust between the two providers. In particular, each provider must trust the other to pass it only correct routing information, and to pass it labeled (in the sense of MPLS [9]) packets only if those packets have been labeled by trusted sources. We also assume that it is possible for label switched paths to cross the boundary between service providers.
VPN可以跨越多个服务提供商。不过，我们假设，当PE路由器之间的路径跨越SP网络之间的边界时，它是通过私有对等安排实现的，在这种情况下，两个提供商之间存在相互信任。特别是，每个提供者必须信任另一个提供者仅传递正确的路由信息，并且仅当这些数据包已由受信任的源标记时，才传递已标记（在MPLS[9]的意义上）的数据包。我们还假设标签交换路径可能跨越服务提供者之间的边界。
A VPN model should, even without the use of cryptographic security measures, provide a level of security equivalent to that obtainable when a level 2 backbone (e.g., Frame Relay) is used. That is, in the absence of misconfiguration or deliberate interconnection of
即使不使用加密安全措施，VPN模型也应提供与使用2级主干（如帧中继）时可获得的安全级别相当的安全级别。也就是说，在没有错误配置或故意互连的情况下
different VPNs, it should not be possible for systems in one VPN to gain access to systems in another VPN.
不同的VPN，一个VPN中的系统不可能访问另一个VPN中的系统。
It should also be possible to deploy standard security procedures.
还应该能够部署标准的安全程序。
From the perspective of a particular backbone network, a set of IP systems constitutes a site if those systems have mutual IP interconnectivity, and communication between them occurs without use of the backbone. In general, a site will consist of a set of systems which are in geographic proximity. However, this is not universally true; two geographic locations connected via a leased line, over which OSPF is running, will constitute a single site, because communication between the two locations does not involve the use of the backbone.
从特定主干网的角度来看，如果一组IP系统具有相互IP互连性，并且它们之间的通信在不使用主干网的情况下发生，则这些IP系统构成一个站点。一般来说，一个站点将由一组地理位置相近的系统组成。然而，这并非普遍正确；通过OSPF运行的租用线路连接的两个地理位置将构成一个站点，因为两个位置之间的通信不涉及主干网的使用。
A CE device is always regarded as being in a single site (though as we shall see, a site may consist of multiple "virtual sites"). A site, however, may belong to multiple VPNs.
CE设备始终被视为位于单个站点中（尽管我们将看到，一个站点可能由多个“虚拟站点”组成）。但是，一个站点可能属于多个VPN。
A PE router may attach to CE devices in any number of different sites, whether those CE devices are in the same or in different VPNs. A CE device may, for robustness, attach to multiple PE routers, of the same or of different service providers. If the CE device is a router, the PE router and the CE router will appear as router adjacencies to each other.
PE路由器可以连接到任意数量的不同站点中的CE设备，无论这些CE设备位于相同或不同的VPN中。为了健壮性，CE设备可以连接到相同或不同服务提供商的多个PE路由器。如果CE设备是路由器，则PE路由器和CE路由器将显示为彼此相邻的路由器。
While the basic unit of interconnection is the site, the architecture described herein allows a finer degree of granularity in the control of interconnectivity. For example, certain systems at a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only.
虽然互连的基本单元是站点，但本文描述的体系结构允许在互连控制中具有更精细的粒度。例如，一个站点上的某些系统可能是内联网的成员以及一个或多个外联网的成员，而同一站点上的其他系统可能仅限于内联网的成员。
Each PE router maintains one or more "per-site forwarding tables". Every site to which the PE router is attached is associated with one of these tables. A particular packet's IP destination address is looked up in a particular per-site forwarding table only if that packet has arrived directly from a site which is associated with that table.
每个PE路由器维护一个或多个“每个站点转发表”。PE路由器连接到的每个站点都与这些表中的一个相关联。仅当特定数据包直接从与该表关联的站点到达时，才会在特定的每个站点转发表中查找该数据包的IP目的地地址。
How are the per-site forwarding tables populated?
如何填充每个站点的转发表？
As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes which are reachable at CE1's site. If PE2 and PE3 are attached respectively to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes which it has learned from CE1. PE2 and PE3 use these routes to populate the forwarding tables which they associate respectively with the sites of CE2 and CE3. Routes from sites which are not in VPN V do not appear in these forwarding tables, which means that packets from CE2 or CE3 cannot be sent to sites which are not in VPN V.
例如，假设PE1、PE2和PE3是三个PE路由器，假设CE1、CE2和CE3是三个CE路由器。假设PE1从CE1学习到在CE1的站点上可以到达的路由。如果PE2和PE3分别连接到CE2和CE3，并且存在包含CE1、CE2和CE3的VPN V，则PE1使用BGP将从CE1学到的路由分发给PE2和PE3。PE2和PE3使用这些路由填充转发表，它们分别与CE2和CE3的站点关联。来自不在VPN V中的站点的路由不会出现在这些转发表中，这意味着来自CE2或CE3的数据包无法发送到不在VPN V中的站点。
If a site is in multiple VPNs, the forwarding table associated with that site can contain routes from the full set of VPNs of which the site is a member.
如果一个站点位于多个VPN中，则与该站点关联的转发表可以包含来自该站点所属的全套VPN的路由。
A PE generally maintains only one forwarding table per site, even if it is multiply connected to that site. Also, different sites can share the same forwarding table if they are meant to use exactly the same set of routes.
PE通常只维护每个站点的一个转发表，即使它与该站点多连接。此外，如果不同站点打算使用完全相同的路由集，则它们可以共享相同的转发表。
Suppose a packet is received by a PE router from a particular directly attached site, but the packet's destination address does not match any entry in the forwarding table associated with that site. If the SP is not providing Internet access for that site, then the packet is discarded as undeliverable. If the SP is providing Internet access for that site, then the PE's Internet forwarding table will be consulted. This means that in general, only one forwarding table per PE need ever contain routes from the Internet, even if Internet access is provided.
假设PE路由器从特定的直接连接站点接收到一个数据包，但该数据包的目的地地址与转发表中与该站点关联的任何条目都不匹配。如果SP不为该站点提供Internet访问，则该数据包将被丢弃为无法送达。如果SP为该站点提供Internet访问，则将咨询PE的Internet转发表。这意味着，一般来说，每个PE只有一个转发表需要包含来自Internet的路由，即使提供了Internet访问。
To maintain proper isolation of one VPN from another, it is important that no router in the backbone accept a labeled packet from any adjacent non-backbone device unless (a) the label at the top of the label stack was actually distributed by the backbone router to the non-backbone device, and (b) the backbone router can determine that use of that label will cause the packet to leave the backbone before any labels lower in the stack will be inspected, and before the IP header will be inspected. These restrictions are necessary in order to prevent packets from entering a VPN where they do not belong.
为了保持一个VPN与另一个VPN的适当隔离，骨干网中的路由器不接受来自任何相邻非骨干网设备的标记数据包是很重要的，除非（a）标签堆栈顶部的标签实际上是由骨干网路由器分发给非骨干网设备的，以及（b）主干路由器可以确定，在检查堆栈中较低的任何标签之前，以及在检查IP报头之前，使用该标签将导致数据包离开主干。这些限制是必要的，以防止数据包进入它们不属于的VPN。
The per-site forwarding tables in a PE are ONLY used for packets which arrive from a site which is directly attached to the PE. They are not used for routing packets which arrive from other routers that belong to the SP backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. E.g., one may have one route to a given system for
PE中的每个站点转发表仅用于从直接连接到PE的站点到达的数据包。它们不用于路由来自属于SP主干网的其他路由器的数据包。结果，可能存在到同一系统的多个不同路由，其中给定分组后面的路由由分组进入主干的站点确定。例如，一个人可能有一条到给定系统的路线，用于
packets from the extranet (where the route leads to a firewall), and a different route to the same system for packets from the intranet (including packets that have already passed through the firewall).
来自外部网的数据包（路由通向防火墙），以及来自内部网的数据包（包括已经通过防火墙的数据包）到同一系统的不同路由。
In some cases, a particular site may be divided by the customer into several virtual sites, perhaps by the use of VLANs. Each virtual site may be a member of a different set of VPNs. The PE then needs to contain a separate forwarding table for each virtual site. For example, if a CE supports VLANs, and wants each VLAN mapped to a separate VPN, the packets sent between CE and PE could be contained in the site's VLAN encapsulation, and this could be used by the PE, along with the interface over which the packet is received, to assign the packet to a particular virtual site.
在某些情况下，客户可能会使用VLAN将特定站点划分为多个虚拟站点。每个虚拟站点都可能是一组不同VPN的成员。然后，PE需要为每个虚拟站点包含一个单独的转发表。例如，如果CE支持VLAN，并且希望将每个VLAN映射到单独的VPN，则CE和PE之间发送的数据包可以包含在站点的VLAN封装中，并且这可以由PE与接收数据包的接口一起用于将数据包分配到特定的虚拟站点。
Alternatively, one could divide the interface into multiple "sub-interfaces" (particularly if the interface is Frame Relay or ATM), and assign the packet to a VPN based on the sub-interface over which it arrives. Or one could simply use a different interface for each virtual site. In any case, only one CE router is ever needed per site, even if there are multiple virtual sites. Of course, a different CE router could be used for each virtual site, if that is desired.
或者，可以将接口划分为多个“子接口”（特别是当接口是帧中继或ATM时），并基于数据包到达的子接口将数据包分配给VPN。或者，可以简单地为每个虚拟站点使用不同的接口。在任何情况下，每个站点只需要一个CE路由器，即使有多个虚拟站点。当然，如果需要的话，每个虚拟站点可以使用不同的CE路由器。
Note that in all these cases, the mechanisms, as well as the policy, for controlling which traffic is in which VPN are in the hand of the customer.
请注意，在所有这些情况下，用于控制哪个VPN中的流量的机制以及策略都在客户手中。
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, our out different network interfaces.
如果希望特定主机位于多个虚拟站点中，则该主机必须为每个数据包确定与该数据包关联的虚拟站点。它可以做到这一点，例如，通过从不同VLAN上的不同虚拟站点发送数据包，我们可以输出不同的网络接口。
These schemes do NOT require the CE to support MPLS. Section 8 contains a brief discussion of how the CE might support multiple virtual sites if it does support MPLS.
这些方案不要求CE支持MPLS。第8节简要讨论了CE在支持MPLS的情况下如何支持多个虚拟站点。
PE routers use BGP to distribute VPN routes to each other (more accurately, to cause VPN routes to be distributed to each other).
PE路由器使用BGP相互分配VPN路由（更准确地说，是使VPN路由相互分配）。
A BGP speaker can only install and distribute one route to a given address prefix. Yet we allow each VPN to have its own address space, which means that the same address can be used in any number of VPNs, where in each VPN the address denotes a different system. It follows
BGP扬声器只能安装和分发一条路由到给定的地址前缀。然而，我们允许每个VPN都有自己的地址空间，这意味着相同的地址可以在任意数量的VPN中使用，其中每个VPN中的地址表示不同的系统。接下来
that we need to allow BGP to install and distribute multiple routes to a single IP address prefix. Further, we must ensure that POLICY is used to determine which sites can be use which routes; given that several such routes are installed by BGP, only one such must appear in any particular per-site forwarding table.
我们需要允许BGP将多条路由安装并分发到单个IP地址前缀。此外，我们必须确保使用政策来确定哪些地点可以使用哪些路线；考虑到BGP安装了多条这样的路由，在任何特定的每个站点转发表中只能出现一条这样的路由。
We meet these goals by the use of a new address family, as specified below.
我们通过使用一个新的地址族来实现这些目标，如下所述。
The BGP Multiprotocol Extensions [3] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. If two VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.
BGP多协议扩展[3]允许BGP承载来自多个“地址族”的路由。我们引入了“VPN-IPv4地址族”的概念。VPN-IPv4地址是一个12字节的数量，以8字节的“路由识别器（RD）”开始，以4字节的IPv4地址结束。如果两个VPN使用相同的IPv4地址前缀，PEs会将其转换为唯一的VPN-IPv4地址前缀。这确保了如果在两个不同的VPN中使用相同的地址，则可以为该地址安装两条完全不同的路由，每个VPN一条。
The RD does not by itself impose any semantics; it contains no information about the origin of the route or about the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine where to redistribute the route (see section 4.2).
RD本身没有强加任何语义；它不包含有关路由来源或路由要分发到的VPN集的信息。RD的目的仅仅是允许创建到公共IPv4地址前缀的不同路由。其他方法用于确定在何处重新分配路线（见第4.2节）。
The RD can also be used to create multiple different routes to the very same system. In section 3, we gave an example where the route to a particular server had to be different for intranet traffic than for extranet traffic. This can be achieved by creating two different VPN-IPv4 routes that have the same IPv4 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used (see section 4.2.3) to decide which packets use which route.
RD还可用于创建到同一系统的多条不同路由。在第3节中，我们给出了一个示例，其中内联网流量与外联网流量到特定服务器的路由必须不同。这可以通过创建两个具有相同IPv4部分但不同RDs的不同VPN-IPv4路由来实现。这允许BGP将多个不同的路由安装到同一系统，并允许使用策略（参见第4.2.3节）来决定哪些数据包使用哪个路由。
The RDs are structured so that every service provider can administer its own "numbering space" (i.e., can make its own assignments of RDs), without conflicting with the RD assignments made by any other service provider. An RD consists of a two-byte type field, an administrator field, and an assigned number field. The value of the type field determines the lengths of the other two fields, as well as the semantics of the administrator field. The administrator field identifies an assigned number authority, and the assigned number field contains a number which has been assigned, by the identified authority, for a particular purpose. For example, one could have an RD whose administrator field contains an Autonomous System number
RDs的结构使得每个服务提供商都可以管理自己的“编号空间”（即，可以自己分配RDs），而不会与任何其他服务提供商的RD分配发生冲突。RD由两字节类型字段、管理员字段和分配的编号字段组成。类型字段的值决定了其他两个字段的长度，以及管理员字段的语义。“管理员”字段标识已分配的编号机构，“已分配的编号”字段包含已分配的机构为特定目的分配的编号。例如，可以有一个RD，其管理员字段包含自治系统号
(ASN), and whose (4-byte) number field contains a number assigned by the SP to whom IANA has assigned that ASN. RDs are given this structure in order to ensure that an SP which provides VPN backbone service can always create a unique RD when it needs to do so. However, the structuring provides no semantics. When BGP compares two such address prefixes, it ignores the structure entirely.
（ASN），其（4字节）编号字段包含IANA分配给该ASN的SP分配的编号。为RD提供此结构是为了确保提供VPN主干网服务的SP在需要时始终可以创建唯一的RD。但是，结构化没有提供语义。当BGP比较两个这样的地址前缀时，它完全忽略了结构。
If the Administrator subfield and the Assigned Number subfield of a VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is considered to have exactly the same meaning as the corresponding globally unique IPv4 address. In particular, this VPN-IPv4 address and the corresponding globally unique IPv4 address will be considered comparable by BGP. In all other cases, a VPN-IPv4 address and its corresponding globally unique IPv4 address will be considered noncomparable by BGP.
如果VPN-IPv4地址的Administrator子字段和Assigned Number子字段均设置为全零，则认为VPN-IPv4地址与相应的全局唯一IPv4地址具有完全相同的含义。特别是，BGP将认为该VPN-IPv4地址和相应的全局唯一IPv4地址具有可比性。在所有其他情况下，BGP将认为VPN-IPv4地址及其对应的全局唯一IPv4地址不可比较。
A given per-site forwarding table will only have one VPN-IPv4 route for any given IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched.
对于任何给定的IPv4地址前缀，给定的每个站点转发表将只有一个VPN-IPv4路由。当数据包的目标地址与VPN-IPv4路由匹配时，只有IPv4部分实际匹配。
A PE needs to be configured to associate routes which lead to particular CE with a particular RD. The PE may be configured to associate all routes leading to the same CE with the same RD, or it may be configured to associate different routes with different RDs, even if they lead to the same CE.
PE需要配置为将通向特定CE的路由与特定RD相关联。PE可以配置为将通向相同CE的所有路由与相同RD相关联，也可以配置为将不同路由与不同RD相关联，即使它们通向相同CE。
In this section, we discuss the way in which the distribution of the VPN-IPv4 routes is controlled.
在本节中，我们将讨论控制VPN-IPv4路由分布的方式。
Every per-site forwarding table is associated with one or more "Target VPN" attributes.
每个站点转发表都与一个或多个“目标VPN”属性相关联。
When a VPN-IPv4 route is created by a PE router, it is associated with one or more "Target VPN" attributes. These are carried in BGP as attributes of the route.
当PE路由器创建VPN-IPv4路由时，它与一个或多个“目标VPN”属性相关联。这些在BGP中作为路由属性携带。
Any route associated with Target VPN T must be distributed to every PE router that has a forwarding table associated with Target VPN T. When such a route is received by a PE router, it is eligible to be installed in each of the PE's per-site forwarding tables that is associated with Target VPN T. (Whether it actually gets installed depends on the outcome of the BGP decision process.)
与目标VPN T关联的任何路由都必须分配给具有与目标VPN T关联的转发表的每个PE路由器。当PE路由器接收到此类路由时，它有资格安装在与目标VPN T关联的每个PE的每个站点转发表中。（是否实际安装取决于BGP决策过程的结果。）
In essence, a Target VPN attribute identifies a set of sites. Associating a particular Target VPN attribute with a route allows that route to be placed in the per-site forwarding tables that are used for routing traffic which is received from the corresponding sites.
本质上，目标VPN属性标识一组站点。将特定的目标VPN属性与路由相关联，可以将该路由放置在用于路由从相应站点接收的流量的每个站点转发表中。
There is a set of Target VPNs that a PE router attaches to a route received from site S. And there is a set of Target VPNs that a PE router uses to determine whether a route received from another PE router could be placed in the forwarding table associated with site S. The two sets are distinct, and need not be the same.
有一组目标VPN，PE路由器连接到从站点S接收的路由。有一组目标VPN，PE路由器用于确定从另一个PE路由器接收的路由是否可以放置在与站点S关联的转发表中。这两组VPN是不同的，不必相同。
The function performed by the Target VPN attribute is similar to that performed by the BGP Communities Attribute. However, the format of the latter is inadequate, since it allows only a two-byte numbering space. It would be fairly straightforward to extend the BGP Communities Attribute to provide a larger numbering space. It should also be possible to structure the format, similar to what we have described for RDs (see section 4.1), so that a type field defines the length of an administrator field, and the remainder of the attribute is a number from the specified administrator's numbering space.
目标VPN属性执行的功能与BGP Communities属性执行的功能类似。但是，后者的格式不充分，因为它只允许两字节的编号空间。扩展BGP Communities属性以提供更大的编号空间是相当简单的。还可以构造格式，类似于我们为RDs描述的格式（参见第4.1节），以便类型字段定义管理员字段的长度，属性的其余部分是指定管理员编号空间中的数字。
When a BGP speaker has received two routes to the same VPN-IPv4 prefix, it chooses one, according to the BGP rules for route preference.
当BGP扬声器接收到两条指向同一VPN-IPv4前缀的路由时，它会根据BGP路由首选规则选择一条路由。
Note that a route can only have one RD, but it can have multiple Target VPNs. In BGP, scalability is improved if one has a single route with multiple attributes, as opposed to multiple routes. One could eliminate the Target VPN attribute by creating more routes (i.e., using more RDs), but the scaling properties would be less favorable.
请注意，一条路由只能有一个RD，但它可以有多个目标VPN。在BGP中，如果一个路由具有多个属性，那么相对于多个路由，可伸缩性会得到改善。可以通过创建更多路由（即，使用更多RD）来消除目标VPN属性，但缩放属性不太有利。
How does a PE determine which Target VPN attributes to associate with a given route? There are a number of different possible ways. The PE might be configured to associate all routes that lead to a particular site with a particular Target VPN. Or the PE might be configured to associate certain routes leading to a particular site with one Target VPN, and certain with another. Or the CE router, when it distributes these routes to the PE (see section 6), might specify one or more Target VPNs for each route. The latter method shifts the control of the mechanisms used to implement the VPN policies from the SP to the customer. If this method is used, it may still be desirable to have the PE eliminate any Target VPNs that, according to its own configuration, are not allowed, and/or to add in some Target VPNs that according to its own configuration are mandatory.
PE如何确定与给定路由关联的目标VPN属性？有许多不同的可能方式。PE可以配置为将通向特定站点的所有路由与特定目标VPN相关联。或者PE可能被配置为将通向特定站点的某些路由与一个目标VPN相关联，并将某些路由与另一个目标VPN相关联。或者，当CE路由器将这些路由分配给PE（参见第6节）时，可能会为每个路由指定一个或多个目标VPN。后一种方法将用于实施VPN策略的机制的控制权从SP转移到客户。如果使用此方法，可能仍希望PE消除根据其自身配置不允许的任何目标VPN，和/或添加一些根据其自身配置必须添加的目标VPN。
It might be more accurate, if less suggestive, to call this attribute the "Route Target" attribute instead of the "VPN Target" attribute. It really identifies only a set of sites which will be able to use the route, without prejudice to whether those sites constitute what might intuitively be called a VPN.
将此属性称为“路由目标”属性而不是“VPN目标”属性可能更准确（如果不那么具有启发性）。它实际上只识别一组能够使用该路由的站点，而不影响这些站点是否构成直观上可以称为VPN的站点。
If two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. Alternatively, each can have an IBGP connection to a route reflector.
如果VPN的两个站点连接到同一自治系统中的PEs，则PEs可以通过它们之间的IBGP连接将VPN-IPv4路由分发给彼此。或者，每个都可以有一个到路由反射器的IBGP连接。
If two sites of VPN are in different Autonomous Systems (e.g., because they are connected to different SPs), then a PE router will need to use IBGP to redistribute VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR will then need to use EBGP to redistribute those routes to an ASBR in another AS. This allows one to connect different VPN sites to different Service Providers. However, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet.
如果VPN的两个站点位于不同的自治系统中（例如，因为它们连接到不同的SP），则PE路由器将需要使用IBGP将VPN-IPv4路由重新分发到自治系统边界路由器（ASBR）或ASBR作为客户端的路由反射器。ASBR随后需要使用EBGP将这些路由重新分配给另一个AS中的ASBR。这允许将不同的VPN站点连接到不同的服务提供商。但是，VPN-IPv4路由只能在专用对等点的EBGP连接上接受，作为SP之间可信安排的一部分。VPN-IPv4路由既不应分发到公共Internet，也不应从公共Internet接受。
If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.
如果有多个VPN的站点连接到不同的自治系统，则在这两个ASE之间不需要有一个ASBR，它拥有所有VPN的所有路由；可以有多个ASBR，每个ASBR仅包含VPN特定子集的路由。
When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop". It also assigns and distributes an MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and send the packet directly to the site from to which the route leads. This will usually mean that it just sends the packet to the CE router from which it learned the route. The label may also determine the data link encapsulation.
当PE路由器通过BGP分发VPN-IPv4路由时，它使用自己的地址作为“BGP下一跳”。它还分配和分发MPLS标签。（本质上，PE路由器不分配VPN-IPv4路由，而是分配标记为VPN-IPv4的路由。参见[8]）当PE处理在堆栈顶部具有此标签的接收数据包时，PE将弹出堆栈，并将数据包直接发送到路由指向的站点。这通常意味着它只是将数据包发送到它从中学习路由的CE路由器。标签还可以确定数据链路封装。
In most cases, the label assigned by a PE will cause the packet to be sent directly to a CE, and the PE which receives the labeled packet will not look up the packet's destination address in any forwarding table. However, it is also possible for the PE to assign a label which implicitly identifies a particular forwarding table. In this case, the PE receiving a packet that label would look up the packet's destination address in one of its forwarding tables. While this can
在大多数情况下，PE分配的标签将导致数据包直接发送到CE，并且接收标签数据包的PE不会在任何转发表中查找数据包的目的地地址。然而，PE也可以分配一个隐式标识特定转发表的标签。在这种情况下，接收该标签的数据包的PE将在其一个转发表中查找该数据包的目的地地址。而这个可以
be very useful in certain circumstances, we do not consider it further in this paper.
在某些情况下非常有用，我们在本文中没有进一步考虑。
Note that the MPLS label that is distributed in this way is only usable if there is a label switched path between the router that installs a route and the BGP next hop of that route. We do not make any assumption about the procedure used to set up that label switched path. It may be set up on a pre-established basis, or it may be set up when a route which would need it is installed. It may be a "best effort" route, or it may be a traffic engineered route. Between a particular PE router and its BGP next hop for a particular route there may be one LSP, or there may be several, perhaps with different QoS characteristics. All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists.
请注意，以这种方式分发的MPLS标签只有在安装路由的路由器和该路由的BGP下一跳之间存在标签交换路径时才可用。对于设置标签交换路径所用的过程，我们不做任何假设。它可以在预先建立的基础上设置，也可以在安装需要它的路线时设置。这可能是一条“尽力而为”的路线，也可能是一条交通工程路线。对于特定路由，在特定PE路由器与其BGP下一跳之间可能存在一个LSP，或者可能存在多个LSP，可能具有不同的QoS特征。对于VPN架构来说，重要的是路由器与其BGP下一跳之间存在某种标签交换路径。
All the usual techniques for using route reflectors [2] to improve scalability, e.g., route reflector hierarchies, are available. If route reflectors are used, there is no need to have any one route reflector know all the VPN-IPv4 routes for all the VPNs supported by the backbone. One can have separate route reflectors, which do not communicate with each other, each of which supports a subset of the total set of VPNs.
使用路由反射器[2]来提高可伸缩性的所有常用技术，例如路由反射器层次结构，都是可用的。如果使用路由反射器，则无需让任何一个路由反射器知道主干支持的所有VPN的所有VPN-IPv4路由。一个可以有单独的路由反射器，它们彼此不通信，每个都支持整个VPN集合的一个子集。
If a given PE router is not attached to any of the Target VPNs of a particular route, it should not receive that route; the other PE or route reflector which is distributing routes to it should apply outbound filtering to avoid sending it unnecessary routes. Of course, if a PE router receives a route via BGP, and that PE is not attached to any of the route's target VPNs, the PE should apply inbound filtering to the route, neither installing nor redistributing it.
如果给定的PE路由器未连接到特定路由的任何目标VPN，则不应接收该路由；向其分配路由的其他PE或路由反射器应应用出站过滤，以避免向其发送不必要的路由。当然，如果PE路由器通过BGP接收到路由，并且该PE未连接到该路由的任何目标VPN，则PE应该对该路由应用入站筛选，既不安装也不重新分发该路由。
A router which is not attached to any VPN, i.e., a P router, never installs any VPN-IPv4 routes at all.
未连接到任何VPN的路由器（即P路由器）根本不会安装任何VPN-IPv4路由。
These distribution rules ensure that there is no one box which needs to know all the VPN-IPv4 routes that are supported over the backbone. As a result, the total number of such routes that can be supported over the backbone is not bound by the capacity of any single device, and therefore can increase virtually without bound.
这些分发规则确保没有一个盒子需要知道主干上支持的所有VPN-IPv4路由。因此，主干上可支持的此类路由的总数不受任何单个设备容量的限制，因此可以在不受限制的情况下几乎增加。
A VPN-IPv4 route may be optionally associated with a VPN of Origin attribute. This attribute uniquely identifies a set of sites, and identifies the corresponding route as having come from one of the sites in that set. Typical uses of this attribute might be to
VPN-IPv4路由可以选择性地与源VPN属性相关联。此属性唯一标识一组站点，并将相应的路由标识为来自该集合中的一个站点。此属性的典型用法可能是
identify the enterprise which owns the site where the route leads, or to identify the site's intranet. However, other uses are also possible. This attribute could be encoded as an extended BGP communities attribute.
确定拥有路由所指向站点的企业，或确定站点的内部网。然而，其他用途也是可能的。此属性可以编码为扩展BGP社区属性。
In situations in which it is necessary to identify the source of a route, it is this attribute, not the RD, which must be used. This attribute may be used when "constructing" VPNs, as described below.
在需要识别路由源的情况下，必须使用此属性，而不是RD。此属性可在“构建”VPN时使用，如下所述。
It might be more accurate, if less suggestive, to call this attribute the "Route Origin" attribute instead of the "VPN of Origin" attribute. It really identifies the route only has having come from one of a particular set of sites, without prejudice as to whether that particular set of sites really constitutes a VPN.
将此属性称为“路由来源”属性而不是“来源VPN”属性可能更准确（如果不那么具有启发性）。它真正识别的路由仅来自一组特定站点中的一个，而不影响该组特定站点是否真正构成VPN。
By setting up the Target VPN and VPN of Origin attributes properly, one can construct different kinds of VPNs.
通过正确设置目标VPN和源属性VPN，可以构建不同类型的VPN。
Suppose it is desired to create a Closed User Group (CUG) which contains a particular set of sites. This can be done by creating a particular Target VPN attribute value to represent the CUG. This value then needs to be associated with the per-site forwarding tables for each site in the CUG, and it needs to be associated with every route learned from a site in the CUG. Any route which has this Target VPN attribute will need to be redistributed so that it reaches every PE router attached to one of the sites in the CUG.
假设需要创建一个封闭用户组（CUG），其中包含一组特定的站点。这可以通过创建特定的目标VPN属性值来表示CUG来实现。然后，该值需要与CUG中每个站点的每个站点转发表相关联，并且需要与从CUG中的站点学习到的每个路由相关联。任何具有此目标VPN属性的路由都需要重新分配，以便到达连接到CUG中一个站点的每个PE路由器。
Alternatively, suppose one desired, for whatever reason, to create a "hub and spoke" kind of VPN. This could be done by the use of two Target Attribute values, one meaning "Hub" and one meaning "Spoke". Then routes from the spokes could be distributed to the hub, without causing routes from the hub to be distributed to the spokes.
或者，假设有人出于任何原因想要创建一种“中心辐射式”VPN。这可以通过使用两个目标属性值来实现，一个表示“中心”，另一个表示“辐射”。然后，辐条的路线可以分配到枢纽，而不会导致枢纽的路线分配到辐条。
Suppose one has a number of sites which are in an intranet and an extranet, as well as a number of sites which are in the intranet only. Then there may be both intranet and extranet routes which have a Target VPN identifying the entire set of sites. The sites which are to have intranet routes only can filter out all routes with the "wrong" VPN of Origin.
假设有许多站点位于内部网和外部网中，还有一些站点仅位于内部网中。然后可能有内联网和外联网路由，它们都有一个标识整个站点集的目标VPN。只有内联网路由的站点可以过滤掉所有源VPN“错误”的路由。
These two attributes allow great flexibility in allowing one to control the distribution of routing information among various sets of sites, which in turn provides great flexibility in constructing VPNs.
这两个属性在控制路由信息在不同站点集之间的分布方面具有极大的灵活性，这反过来又为构建VPN提供了极大的灵活性。
If the intermediate routes in the backbone do not have any information about the routes to the VPNs, how are packets forwarded from one VPN site to another?
如果主干网中的中间路由没有任何关于到VPN的路由的信息，那么如何将数据包从一个VPN站点转发到另一个VPN站点？
This is done by means of MPLS with a two-level label stack.
这是通过具有两级标签堆栈的MPLS实现的。
PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. (Certain procedures for setting up label switched paths in the backbone may not require the presence of the /32 address prefixes.)
PE路由器（以及重新分配VPN-IPv4地址的ASBR）需要将/32地址前缀插入主干网的IGP路由表中。这使得主干网中每个节点上的MPLS能够将与路由对应的标签分配给每个PE路由器。（在主干网中设置标签交换路径的某些过程可能不需要/32地址前缀。）
When a PE receives a packet from a CE device, it chooses a particular per-site forwarding table in which to look up the packet's destination address. Assume that a match is found.
当PE从CE设备接收到数据包时，它选择一个特定的每个站点转发表，在其中查找数据包的目的地地址。假设找到了匹配项。
If the packet is destined for a CE device attached to this same PE, the packet is sent directly to that CE device.
如果包的目的地是连接到同一PE的CE设备，则包直接发送到该CE设备。
If the packet is not destined for a CE device attached to this same PE, the packet's "BGP Next Hop" is found, as well as the label which that BGP next hop assigned for the packet's destination address. This label is pushed onto the packet's label stack, and becomes the bottom label. Then the PE looks up the IGP route to the BGP Next Hop, and thus determines the IGP next hop, as well as the label assigned to the address of the BGP next hop by the IGP next hop. This label gets pushed on as the packet's top label, and the packet is then forwarded to the IGP next hop. (If the BGP next hop is the same as the IGP next hop, the second label may not need to be pushed on, however.)
如果数据包的目的地不是连接到此同一PE的CE设备，则会找到数据包的“BGP下一跳”，以及该BGP下一跳为数据包的目的地地址分配的标签。此标签被推送到数据包的标签堆栈上，并成为底部标签。然后，PE查找到BGP下一跳的IGP路由，从而确定IGP下一跳，以及IGP下一跳分配给BGP下一跳地址的标签。这个标签作为数据包的顶部标签被推上，然后数据包被转发到下一跳的IGP。（但是，如果BGP下一跳与IGP下一跳相同，则可能不需要推送第二个标签。）
At this point, MPLS will carry the packet across the backbone and into the appropriate CE device. That is, all forwarding decisions by P routers and PE routers are now made by means of MPLS, and the packet's IP header is not looked at again until the packet reaches the CE device. The final PE router will pop the last label from the MPLS label stack before sending the packet to the CE device, thus the CE device will just see an ordinary IP packet. (Though see section 8 for some discussion of the case where the CE desires to received labeled packets.)
此时，MPLS将通过骨干网将数据包传送到适当的CE设备中。也就是说，P路由器和PE路由器的所有转发决策现在都是通过MPLS作出的，并且在分组到达CE设备之前，不再查看分组的IP报头。在将数据包发送到CE设备之前，最终的PE路由器将弹出MPLS标签堆栈中的最后一个标签，因此CE设备将只看到一个普通的IP数据包。（关于CE希望接收标记数据包的情况，请参见第8节。）
When a packet enters the backbone from a particular site via a particular PE router, the packet's route is determined by the contents of the forwarding table which that PE router associated with that site. The forwarding tables of the PE router where the packet
当数据包通过特定PE路由器从特定站点进入主干网时，数据包的路由由该PE路由器与该站点关联的转发表的内容确定。发送数据包的PE路由器的转发表
leaves the backbone are not relevant. As a result, one may have multiple routes to the same system, where the particular route chosen for a particular packet is based on the site from which the packet enters the backbone.
主干的叶子不相关。结果，一个可能具有到同一系统的多个路由，其中为特定分组选择的特定路由基于分组进入骨干网的站点。
Note that it is the two-level labeling that makes it possible to keep all the VPN routes out of the P routers, and this in turn is crucial to ensuring the scalability of the model. The backbone does not even need to have routes to the CEs, only to the PEs.
请注意，正是两级标记使所有VPN路由都不进入P路由器成为可能，这反过来又对确保模型的可伸缩性至关重要。主干甚至不需要到CEs的路由，只需要到PEs。
The PE routers which attach to a particular VPN need to know, for each of that VPN's sites, which addresses in that VPN are at each site.
附加到特定VPN的PE路由器需要知道，对于该VPN的每个站点，该VPN中的哪些地址位于每个站点。
In the case where the CE device is a host or a switch, this set of addresses will generally be configured into the PE router attaching to that device. In the case where the CE device is a router, there are a number of possible ways that a PE router can obtain this set of addresses.
在CE设备是主机或交换机的情况下，这组地址通常会配置到连接到该设备的PE路由器中。在CE设备是路由器的情况下，PE路由器可以通过多种可能的方式获得这组地址。
The PE translates these addresses into VPN-IPv4 addresses, using a configured RD. The PE then treats these VPN-IPv4 routes as input to BGP. In no case will routes from a site ever be leaked into the backbone's IGP.
PE使用配置的RD将这些地址转换为VPN-IPv4地址。然后，PE将这些VPN-IPv4路由视为BGP的输入。在任何情况下，站点的路由都不会泄漏到主干网的IGP中。
Exactly which PE/CE route distribution techniques are possible depends on whether a particular CE is in a "transit VPN" or not. A "transit VPN" is one which contains a router that receives routes from a "third party" (i.e., from a router which is not in the VPN, but is not a PE router), and that redistributes those routes to a PE router. A VPN which is not a transit VPN is a "stub VPN". The vast majority of VPNs, including just about all corporate enterprise networks, would be expected to be "stubs" in this sense.
具体哪种PE/CE路由分配技术是可能的取决于特定CE是否在“transit VPN”中。“传输VPN”是指包含从“第三方”（即，从不在VPN中但不是PE路由器的路由器）接收路由的路由器，并将这些路由重新分配到PE路由器的路由器。不是传输VPN的VPN是“存根VPN”。绝大多数VPN，包括几乎所有的企业网络，在这个意义上都是“存根”。
The possible PE/CE distribution techniques are:
可能的PE/CE分配技术包括：
1. Static routing (i.e., configuration) may be used. (This is likely to be useful only in stub VPNs.)
1. 可以使用静态路由（即配置）。（这可能仅在存根VPN中有用。）
2. PE and CE routers may be RIP peers, and the CE may use RIP to tell the PE router the set of address prefixes which are reachable at the CE router's site. When RIP is configured in the CE, care must be taken to ensure that address prefixes from other sites (i.e., address prefixes learned by the CE router from the PE router) are never advertised to the PE. More precisely: if a PE router, say PE1, receives a VPN-IPv4 route
2. PE和CE路由器可以是RIP对等体，CE可以使用RIP来告诉PE路由器在CE路由器的站点上可以访问的地址前缀集。当在CE中配置RIP时，必须注意确保从不向PE播发来自其他站点的地址前缀（即CE路由器从PE路由器学习的地址前缀）。更准确地说：如果一个PE路由器，比如PE1，接收到一个VPN-IPv4路由
R1, and as a result distributes an IPv4 route R2 to a CE, then R2 must not be distributed back from that CE's site to a PE router, say PE2, (where PE1 and PE2 may be the same router or different routers), unless PE2 maps R2 to a VPN-IPv4 route which is different than (i.e., contains a different RD than) R1.
R1，并因此将IPv4路由R2分配给CE，则R2不得从该CE的站点分配回PE路由器，例如PE2（其中PE1和PE2可能是相同的路由器或不同的路由器），除非PE2将R2映射到不同于（即，包含不同于）R1的VPN-IPv4路由。
3. The PE and CE routers may be OSPF peers. In this case, the site should be a single OSPF area, the CE should be an ABR in that area, and the PE should be an ABR which is not in that area. Also, the PE should report no router links other than those to the CEs which are at the same site. (This technique should be used only in stub VPNs.)
3. PE和CE路由器可以是OSPF对等方。在这种情况下，站点应为单个OSPF区域，CE应为该区域内的ABR，PE应为不在该区域内的ABR。此外，PE不应报告除位于同一站点的CEs外的任何路由器链路。（此技术应仅在存根VPN中使用。）
4. The PE and CE routers may be BGP peers, and the CE router may use BGP (in particular, EBGP to tell the PE router the set of address prefixes which are at the CE router's site. (This technique can be used in stub VPNs or transit VPNs.)
4. PE和CE路由器可以是BGP对等方，CE路由器可以使用BGP（特别是EBGP来告诉PE路由器位于CE路由器站点的一组地址前缀。（此技术可用于存根VPN或传输VPN。）
From a purely technical perspective, this is by far the best technique:
从纯技术角度来看，这是迄今为止最好的技术：
a) Unlike the IGP alternatives, this does not require the PE to run multiple routing algorithm instances in order to talk to multiple CEs
a) 与IGP备选方案不同，这不需要PE运行多个路由算法实例来与多个CE对话
b) BGP is explicitly designed for just this function: passing routing information between systems run by different administrations
b) BGP的明确设计就是为了实现这一功能：在由不同管理机构运行的系统之间传递路由信息
c) If the site contains "BGP backdoors", i.e., routers with BGP connections to routers other than PE routers, this procedure will work correctly in all circumstances. The other procedures may or may not work, depending on the precise circumstances.
c) 如果站点包含“BGP后门”，即与PE路由器以外的路由器具有BGP连接的路由器，则此过程将在所有情况下正常工作。根据具体情况，其他程序可能有效，也可能无效。
d) Use of BGP makes it easy for the CE to pass attributes of the routes to the PE. For example, the CE may suggest a particular Target for each route, from among the Target attributes that the PE is authorized to attach to the route.
d) BGP的使用使得CE可以轻松地将路由属性传递给PE。例如，CE可以从PE被授权附加到路由的目标属性中为每个路由建议特定目标。
On the other hand, using BGP is likely to be something new for the CE administrators, except in the case where the customer itself is already an Internet Service Provider (ISP).
另一方面，对CE管理员来说，使用BGP可能是一件新鲜事，除非客户本身已经是互联网服务提供商（ISP）。
If a site is not in a transit VPN, note that it need not have a unique Autonomous System Number (ASN). Every CE whose site which is not in a transit VPN can use the same ASN. This can be chosen from the private ASN space, and it will be stripped out by the PE. Routing loops are prevented by use of the Site of Origin Attribute (see below).
如果站点不在transit VPN中，请注意，它不需要具有唯一的自治系统号（ASN）。其站点不在transit VPN中的每个CE都可以使用相同的ASN。这可以从专用ASN空间中选择，并由PE剥离。使用“源站点”属性可以防止路由循环（请参见下文）。
If a set of sites constitute a transit VPN, it is convenient to represent them as a BGP Confederation, so that the internal structure of the VPN is hidden from any router which is not within the VPN. In this case, each site in the VPN would need two BGP connections to the backbone, one which is internal to the confederation and one which is external to it. The usual intra-confederation procedures would have to be slightly modified in order to take account for the fact that the backbone and the sites may have different policies. The backbone is a member of the confederation on one of the connections, but is not a member on the other. These techniques may be useful if the customer for the VPN service is an ISP. This technique allows a customer that is an ISP to obtain VPN backbone service from one of its ISP peers.
如果一组站点构成了一个传输VPN，则可以方便地将它们表示为BGP联盟，这样VPN的内部结构就可以对不在VPN内的任何路由器隐藏。在这种情况下，VPN中的每个站点都需要两个到主干网的BGP连接，一个在联邦内部，一个在联邦外部。为了考虑到主干网和站点可能有不同的策略这一事实，通常的联邦内部程序必须稍微修改。主干是其中一个连接上的联邦成员，但不是另一个连接上的成员。如果VPN服务的客户是ISP，则这些技术可能很有用。这种技术允许作为ISP的客户从其ISP对等方之一获得VPN主干网服务。
(However, if a VPN customer is itself an ISP, and its CE routers support MPLS, a much simpler technique can be used, wherein the ISP is regarded as a stub VPN. See section 8.)
（但是，如果VPN客户本身是ISP，并且其CE路由器支持MPLS，则可以使用更简单的技术，其中ISP被视为存根VPN。请参阅第8节。）
When we do not need to distinguish among the different ways in which a PE can be informed of the address prefixes which exist at a given site, we will simply say that the PE has "learned" the routes from that site.
当我们不需要区分PE可以被告知在给定站点上存在的地址前缀的不同方式时，我们将简单地说PE已经从该站点“学习”了路由。
Before a PE can redistribute a VPN-IPv4 route learned from a site, it must assign certain attributes to the route. There are three such attributes:
在PE可以重新分发从站点学习的VPN-IPv4路由之前，它必须为路由分配某些属性。有三个这样的属性：
- Site of Origin
- 产地
This attribute uniquely identifies the site from which the PE router learned the route. All routes learned from a particular site must be assigned the same Site of Origin attribute, even if a site is multiply connected to a single PE, or is connected to multiple PEs. Distinct Site of Origin attributes must be used for distinct sites. This attribute could be encoded as an extended BGP communities attribute (section 4.2.1).
此属性唯一标识PE路由器从中学习路由的站点。从特定站点学习的所有路由都必须分配相同的源站点属性，即使一个站点多个连接到单个PE，或连接到多个PE。不同的源站点属性必须用于不同的站点。该属性可以编码为扩展BGP社区属性（第4.2.1节）。
- VPN of Origin
- 源VPN
See section 4.2.1.
见第4.2.1节。
- Target VPN
- 目标VPN
See section 4.2.1.
见第4.2.1节。
In this section, we assume that the CE device is a router.
在本节中，我们假设CE设备是路由器。
In general, a PE may distribute to a CE any route which the PE has placed in the forwarding table which it uses to route packets from that CE. There is one exception: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site.
一般来说，PE可以将PE放置在转发表中的任何路由分发给CE，该转发表用于路由来自该CE的数据包。有一个例外：如果路由的“源站点”属性标识特定站点，则该路由决不能重新分配给该站点的任何CE。
In most cases, however, it will be sufficient for the PE to simply distribute the default route to the CE. (In some cases, it may even be sufficient for the CE to be configured with a default route pointing to the PE.) This will generally work at any site which does not itself need to distribute the default route to other sites. (E.g., if one site in a corporate VPN has the corporation's access to the Internet, that site might need to have default distributed to the other site, but one could not distribute default to that site itself.)
然而，在大多数情况下，PE只需将默认路由分配给CE即可。（在某些情况下，为CE配置指向PE的默认路由可能就足够了。）这通常适用于本身不需要将默认路由分发到其他站点的任何站点。（例如，如果公司VPN中的一个站点具有公司对Internet的访问权限，则该站点可能需要将默认值分发给另一个站点，但不能将默认值分发给该站点本身。）
Whatever procedure is used to distribute routes from CE to PE will also be used to distribute routes from PE to CE.
无论使用何种程序将路由从CE分配到PE，也将使用何种程序将路由从PE分配到CE。
In the case where the CE supports MPLS, AND is willing to import the complete set of routes from its VPNs, the PE can distribute to it a label for each such route. When the PE receives a packet from the CE with such a label, it (a) replaces that label with the corresponding label that it learned via BGP, and (b) pushes on a label corresponding to the BGP next hop for the corresponding route.
如果CE支持MPLS，并且愿意从其VPN导入完整的路由集，则PE可以向其分发每个此类路由的标签。当PE从CE接收到具有这样一个标签的分组时，它（a）将该标签替换为它通过BGP学习到的相应标签，并且（b）为相应的路由推送对应于BGP下一跳的标签。
If the CE/PE route distribution is done via BGP, the CE can use MPLS to support multiple virtual sites. The CE may itself contain a separate forwarding table for each virtual site, which it populates as indicated by the VPN of Origin and Target VPN attributes of the routes it receives from the PE. If the CE receives the full set of routes from the PE, the PE will not need to do any address lookup at all on packets received from the CE. Alternatively, the PE may in some cases be able to distribute to the CE a single (labeled) default route for each VPN. Then when the PE receives a labeled packet from
如果CE/PE路由分发通过BGP完成，则CE可以使用MPLS支持多个虚拟站点。CE本身可能包含每个虚拟站点的单独转发表，它根据从PE接收的路由的源VPN和目标VPN属性填充该表。如果CE从PE接收到全套路由，则PE将根本不需要对从CE接收的数据包执行任何地址查找。或者，在某些情况下，PE可以为每个VPN向CE分发单个（标记的）默认路由。然后，当PE从接收到带标签的数据包时
the CE, it would know which forwarding table to look in; the label placed on the packet by the CE would identify only the virtual site from which the packet is coming.
在CE中，它将知道查看哪个转发表；CE在数据包上放置的标签将仅标识数据包来自的虚拟站点。
If a particular VPN is actually an ISP, but its CE routers support MPLS, then the VPN can actually be treated as a stub VPN. The CE and PE routers need only exchange routes which are internal to the VPN. The PE router would distribute to the CE router a label for each of these routes. Routers at different sites in the VPN can then become BGP peers. When the CE router looks up a packet's destination address, the routing lookup always resolves to an internal address, usually the address of the packet's BGP next hop. The CE labels the packet appropriately and sends the packet to the PE.
如果某个特定的VPN实际上是ISP，但其CE路由器支持MPLS，那么该VPN实际上可以被视为存根VPN。CE和PE路由器只需要VPN内部的交换路由。PE路由器将向CE路由器分发每个路由的标签。VPN中不同站点的路由器可以成为BGP对等点。当CE路由器查找数据包的目标地址时，路由查找总是解析为内部地址，通常是数据包的BGP下一跳的地址。CE适当地标记分组并将分组发送到PE。
Under the following conditions:
在下列情况下：
a) labeled packets are not accepted by backbone routers from untrusted or unreliable sources, unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected, and
a) 主干路由器不接受来自不可信或不可靠来源的标记数据包，除非已知此类数据包将在检查IP报头或堆栈中较低的任何标签之前离开主干，以及
b) labeled VPN-IPv4 routes are not accepted from untrusted or unreliable sources,
b) 不接受来自不受信任或不可靠来源的标记VPN-IPv4路由，
the security provided by this architecture is virtually identical to that provided to VPNs by Frame Relay or ATM backbones.
该体系结构提供的安全性实际上与通过帧中继或ATM主干向VPN提供的安全性相同。
It is worth noting that the use of MPLS makes it much simpler to provide this level of security than would be possible if one attempted to use some form of IP-within-IP tunneling in place of MPLS. It is a simple matter to refuse to accept a labeled packet unless the first of the above conditions applies to it. It is rather more difficult to configure the a router to refuse to accept an IP packet if that packet is an IP-within-IP tunnelled packet which is going to a "wrong" place.
值得注意的是，与试图在IP隧道中使用某种形式的IP代替MPLS相比，MPLS的使用使得提供这种级别的安全性变得更加简单。除非上述第一个条件适用于贴有标签的包裹，否则拒绝接受该包裹是一件简单的事情。如果一个IP包是IP隧道包中的一个IP，而这个IP隧道包将要去一个“错误”的地方，那么将路由器配置为拒绝接受该IP包就相当困难了。
The use of MPLS also allows a VPN to span multiple SPs without depending in any way on the inter-domain distribution of IPv4 routing information.
MPLS的使用还允许VPN跨越多个SP，而不以任何方式依赖IPv4路由信息的域间分布。
It is also possible for a VPN user to provide himself with enhanced security by making use of Tunnel Mode IPSEC [5]. This is discussed in the remainder of this section.
VPN用户还可以通过使用隧道模式IPSEC为自己提供增强的安全性[5]。这将在本节的其余部分讨论。
A security-conscious VPN user might want to ensure that some or all of the packets which traverse the backbone are authenticated and/or encrypted. The standard way to obtain this functionality today would be to create a "security tunnel" between every pair of CE routers in a VPN, using IPSEC Tunnel Mode.
具有安全意识的VPN用户可能希望确保通过主干的部分或所有数据包都经过身份验证和/或加密。现在获得此功能的标准方法是使用IPSEC隧道模式在VPN中的每对CE路由器之间创建“安全隧道”。
However, the procedures described so far do not enable the CE router transmitting a packet to determine the identify of the next CE router that the packet will traverse. Yet that information is required in order to use Tunnel Mode IPSEC. So we must extend those procedures to make this information available.
然而，到目前为止描述的过程不使得发送分组的CE路由器能够确定分组将要穿越的下一个CE路由器的标识。然而，使用隧道模式IPSEC需要这些信息。因此，我们必须扩展这些程序，以提供这些信息。
A way to do this is suggested in [6]. Every VPN-IPv4 route can have an attribute which identifies the next CE router that will be traversed if that route is followed. If this information is provided to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be used.
[6]中建议了一种方法。每个VPN-IPv4路由都可以具有一个属性，该属性标识如果遵循该路由，将要穿越的下一个CE路由器。如果将此信息提供给VPN中的所有CE路由器，则可以使用标准IPSEC隧道模式。
If the CE and PE are BGP peers, it is natural to present this information as a BGP attribute.
如果CE和PE是BGP对等方，则自然会将此信息作为BGP属性呈现。
Each CE that is to use IPSEC should also be configured with a set of address prefixes, such that it is prohibited from sending insecure traffic to any of those addresses. This prevents the CE from sending insecure traffic if, for some reason, it fails to obtain the necessary information.
要使用IPSEC的每个CE还应该配置一组地址前缀，这样就可以禁止它向这些地址中的任何一个发送不安全的流量。这可防止CE在由于某种原因无法获得必要信息时发送不安全的通信量。
When MPLS is used to carry packets between the two endpoints of an IPSEC tunnel, the IPSEC outer header does not really perform any function. It might be beneficial to develop a form of IPSEC tunnel mode which allows the outer header to be omitted when MPLS is used.
当MPLS用于在IPSEC隧道的两个端点之间传输数据包时，IPSEC外部报头实际上不执行任何功能。开发一种形式的IPSEC隧道模式可能是有益的，它允许在使用MPLS时省略外部报头。
Instead of setting up a security tunnel between each pair of CE routers, it may be advantageous to set up a single, multiparty security association. In such a security association, all the CE routers which are in a particular VPN would share the same security parameters (.e.g., same secret, same algorithm, etc.). Then the ingress CE wouldn't have to know which CE is the next one to receive the data, it would only have to know which VPN the data is going to. A CE which is in multiple VPNs could use different security parameters for each one, thus protecting, e.g., intranet packets from being exposed to the extranet.
与其在每对CE路由器之间建立安全隧道，不如建立一个单一的多方安全关联。在这样的安全关联中，特定VPN中的所有CE路由器将共享相同的安全参数（例如，相同的秘密、相同的算法等）。然后，入口CE不必知道下一个接收数据的CE是哪个CE，它只需要知道数据将要发送到哪个VPN。位于多个VPN中的CE可以为每个VPN使用不同的安全参数，从而保护（例如）内联网数据包不暴露于外联网。
With such a scheme, standard Tunnel Mode IPSEC could not be used, because there is no way to fill in the IP destination address field of the "outer header". However, when MPLS is used for forwarding, there is no real need for this outer header anyway; the PE router can use MPLS to get a packet to a tunnel endpoint without even knowing the IP address of that endpoint; it only needs to see the IP destination address of the "inner header".
使用这种方案，标准隧道模式IPSEC无法使用，因为无法填写“外部标头”的IP目标地址字段。然而，当MPLS用于转发时，无论如何都不需要这个外部报头；PE路由器可以使用MPLS将数据包获取到隧道端点，甚至不知道该端点的IP地址；它只需要查看“内部标头”的IP目标地址。
A significant advantage of a scheme like this is that it makes routing changes (in particular, a change of egress CE for a particular address prefix) transparent to the security mechanism. This could be particularly important in the case of multi-provider VPNs, where the need to distribute information about such routing changes simply to support the security mechanisms could result in scalability issues.
这样的方案的一个显著优点是，它使路由更改（特别是特定地址前缀的出口更改）对安全机制透明。在多提供商VPN的情况下，这可能特别重要，在这种情况下，仅仅为了支持安全机制而需要分发有关此类路由更改的信息可能会导致可伸缩性问题。
Another advantage is that it eliminates the need for the outer IP header, since the MPLS encapsulation performs its role.
另一个优点是，它消除了对外部IP报头的需要，因为MPLS封装发挥了它的作用。
Although not the focus of this paper, Quality of Service is a key component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header [10], or, where ATM is used as the backbone, through the use of ATM QoS capabilities. The traffic engineering work discussed in [1] is also directly applicable to MPLS/BGP VPNs. Traffic engineering could even be used to establish LSPs with particular QoS characteristics between particular pairs of sites, if that is desirable. Where an MPLS/BGP VPN spans multiple SPs, the architecture described in [7] may be useful. An SP may apply either intserv or diffserv capabilities to a particular VPN, as appropriate.
虽然不是本文的重点，但服务质量是任何VPN服务的关键组成部分。在MPLS/BGP VPN中，现有的L3 QoS能力可通过使用垫片头中的“实验”位[10]应用于标记的数据包，或者，在ATM用作主干网的情况下，通过使用ATM QoS能力应用于标记的数据包。[1]中讨论的流量工程工作也直接适用于MPLS/BGP VPN。如果需要的话，流量工程甚至可以用于在特定站点对之间建立具有特定QoS特征的LSP。当MPLS/BGP VPN跨越多个SP时，[7]中描述的体系结构可能有用。SP可以对特定VPN应用intserv或diffserv功能（视情况而定）。
We have discussed scalability issues throughout this paper. In this section, we briefly summarize the main characteristics of our model with respect to scalability.
我们在本文中讨论了可伸缩性问题。在本节中，我们简要总结了模型在可伸缩性方面的主要特征。
The Service Provider backbone network consists of (a) PE routers, (b) BGP Route Reflectors, (c) P routers (which are neither PE routers nor Route Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs.
服务提供商主干网由（a）PE路由器、（b）BGP路由反射器、（c）P路由器（既不是PE路由器也不是路由反射器）和（d）多提供商VPN组成。
P routers do not maintain any VPN routes. In order to properly forward VPN traffic, the P routers need only maintain routes to the PE routers and the ASBRs. The use of two levels of labeling is what makes it possible to keep the VPN routes out of the P routers.
P路由器不维护任何VPN路由。为了正确转发VPN流量，P路由器只需要维护到PE路由器和ASBR的路由。使用两个级别的标签可以使VPN路由远离P路由器。
A PE router to maintains VPN routes, but only for those VPNs to which it is directly attached.
用于维护VPN路由的PE路由器，但仅适用于其直接连接的VPN。
Route reflectors and ASBRs can be partitioned among VPNs so that each partition carries routes for only a subset of the VPNs provided by the Service Provider. Thus no single Route Reflector or ASBR is required to maintain routes for all the VPNs.
路由反射器和ASBR可以在VPN之间进行分区，以便每个分区仅承载服务提供商提供的VPN子集的路由。因此，不需要单路由反射器或ASBR来维护所有VPN的路由。
As a result, no single component within the Service Provider network has to maintain all the routes for all the VPNs. So the total capacity of the network to support increasing numbers of VPNs is not limited by the capacity of any individual component.
因此，服务提供商网络中的任何单个组件都不必维护所有VPN的所有路由。因此，支持越来越多VPN的网络总容量不受任何单个组件容量的限制。
Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms.
Cisco Systems可能会为本文档中披露的部分技术寻求专利或其他知识产权保护。如果本文件产生的任何标准受到分配给Cisco Systems的一项或多项专利的保护，Cisco打算披露这些专利，并以合理和非歧视性的条款对其进行许可。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
Significant contributions to this work have been made by Ravi Chandra, Dan Tappan and Bob Thomas.
拉维·钱德拉、丹·塔潘和鲍勃·托马斯对这项工作做出了重大贡献。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
雅科夫·雷克特思科系统公司，地址：加利福尼亚州圣何塞塔斯曼大道170号，邮编：95134
EMail: yakov@cisco.com
EMail: yakov@cisco.com
[1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, "Extensions to RSVP for LSP Tunnels", Work in Progress.
[1] Awduche、Berger、Gan、Li、Swallow和Srinavasan，“LSP隧道RSVP的扩展”，正在进行中。
[2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996.
[2] Bates，T.和R.Chandrasekaran，“BGP路线反射：全网格IBGP的替代方案”，RFC 1966，1996年6月。
[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[3] Bates，T.，Chandra，R.，Katz，D.和Y.Rekhter，“BGP4的多协议扩展”，RFC 2283，1998年2月。
[4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based Virtual Private Networks", Work in Progress.
[4] Gleeson、Heinanen和Armitage，“基于IP的虚拟专用网络框架”，正在进行中。
[5] Kent and Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent和Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.
[6] Li，“使用MPLS的基于CPE的VPN”，1998年10月，正在进行的工作。
[7] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[7] Li，T.和Y.Rekhter，“差异化服务和流量工程的提供商架构（PASTE）”，RFC 2430，1998年10月。
[8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in Progress.
[8] Rekhter和Rosen，“在BGP4中携带标签信息”，工作正在进行中。
[9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", Work in Progress.
[9] Rosen、Viswanathan和Callon，“多协议标签交换架构”，正在进行中。
[10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", Work in Progress.
[10] Rosen、Rekhter、Tappan、Farinaci、Fedorkow、Li和Conta，“MPLS标签堆栈编码”，工作正在进行中。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。