组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：孟魁（maggiee maggiee@etang.com） 译文发布时间：2001-5-11 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 Network Working Group K. Muthukrishnan Request for Comments: 2917 Lucent Technologies Category: Informational A. Malis Vivace Networks, Inc. September 2000 核心 MPLS IP VPN 体系结构 (RFC2917--A Core MPLS IP VPN Architecture) 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建 议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程 度和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (2000). All Rights Reserved. 摘要 本备忘录描述了一种在服务提供商的MPLS主干网上建立核心VPN服务的方法。该方法在主干 网中使用MPLS，以提供除“尽力而为”外的“优先服务”。其核心思想是，服务提供商为客 户提供一个虚拟路由器服务。该体系结构的基本原则是便于配置、用户安全、网络安全、动 态邻居发现、可扩展性和对现有路由协议的不加修改的使用。 目录 1． 缩略语 2. 概述 3. 虚拟路由器 4. 目标 5. 结构要求 6. 结构框架 7. 可扩展的配置 8. 动态邻居发现 9. VPN 的IP域配置 10．邻居发现举例 11. 转发 11.1专用LSP 11.2尽力而为的公开LSP 12．区分服务 13．安全问题 13.1路由安全 13.2数据安全 13.3配置安全 13.4物理网络安全 14．虚拟路由器的检测 15．性能问题 16. 致谢 17. 参考文献 18. 作者地址 19. 版权声明 1．缩略语 ARP 地址解析协议 CE 客户边缘路由器 LSP 标签交换路径 PNA 专用网管理员 SLA 服务等级协议 SP 服务提供商 SPED SP边缘设备 SPNA SP网络管理员 VMA VPN 组播地址 VPNID VPN 标识 VR 虚拟路由器 VRC 虚拟路由控制台 2. 概述 本备忘录描述了一种以服务提供商网络为主干网，提供IP VPN服务的方法。一般而言， 有两种实现方法：叠加模式和虚拟路由器方法。前者是在现有路由协议的基础上叠加一些语 义，以携带一些地址可达信息。在本文中，我们着重于介绍虚拟路由器的方法。 本文描述的方法并不需要对现有的路由协议进行修改。邻居发现是通过仿真局域网及地 址解析协议来实现的。本文力图对SP和PNA做如下分工：SP拥有和管理第一层、第二层的 服务，而PNA负责第三层的服务。因为有逻辑独立的路由域，PNA可以灵活地使用私有地址 和未经注册的地址。而在共享LSP上利用标签堆栈对专用LSP和VPN标识进行了封装，数据 安全性也得到了保证。 本备忘录描述的方法与RFC2547[Rosen1]中不同之处在于：并没有指定路由协议来携带 VPN路由信息。在RFC2547中描述了一种方法，可以通过修改BGP协议来携带VPN在SP主干 网上的单播路由。如果要携带多播路由，还必须进行进一步的工作。 3. 虚拟路由器 一个虚拟路由器是一个路由设备中静态或动态线程的集合，提供类似物理路由器的路由 和转发服务。一个虚拟路由器不须单独的操作系统处理（当然也可以有），它只是给人一种错 觉，好象有一个专用的路由器为它所连接的网络提供服务。一个虚拟路由器与它相应的物理 设备一样，是路由域的一个元素。这个路由域中的其它路由器可以是物理的，也可以是虚拟 的。如果虚拟路由器与一个特定的（逻辑离散的）路由域相连，而一个物理路由器又可以承 载多个虚拟路由器的话，那么，一个物理路由器就能支持多个（逻辑离散的）路由空间了。 从VPN用户的角度来看，虚拟路由器应该与物理路由器尽可能地相同。换言之，除了极 个别情况外，虚拟路由应该在各方面（配置、管理、检测、查错）都象一个专用的物理路由 器。这样，就无须对大量已安装的路由器进行升级或重新配置，也不需对网络管理员重新培 训。 虚拟 路由器的任务在于： 1. 对任意路由协议组合的配置 2. 对网络的检测 3. 查错 每个VPN都有一个逻辑上独立的路由域，这样SP就可以更好地为用户提供相当灵活的虚拟 路由器服务，而无需为每一个VPN准备一个物理路由器。这也就是说，SP的硬件投资--路由 器和它们之间的连接--可以被多个用户复用。 4. 目标 1. SP网络上的VPN终节点扩展性好、易于配置。添加一个CE时，最多只需要加一条配 置信息。 2. 无需使用SP的唯一而且难得到的资源，如IP地址和子网等。 3. 在SP云中对虚拟路由器的动态发现。这是个可选，但可以保持网络尽可能简单的相当 有价值的目标。 4. 虚拟路由器应能由VPN网络管理员完全配置和检测。这样，PNA在VPN配置问题上就 有足够的灵活性，可以自己配置，也可以交由SP完成。 5. 各VPN的数据转发质量应该是可配置的。这种质量要求可解释为连续（或离散）级别 的服务，例如，尽力而为，专用带宽，QOS以及基于策略的转发服务等。 6. 可以通过在VPN中建立专用的数据转发LSP的方法将各VPN配置为区别服务模式。 7. Internet路由器的安全也包括虚拟路由器。这就意味着虚拟路由器的数据转发和选路 应该与专用的物理路由器一样安全，用户数据及可达性信息不会从一个路由域无意地泄露出 去。 8. 不指定在虚拟路由器之间使用的路由协议。这对于VPN用户自主地按各自的方式建立 网络及设置策略相当重要。例如，一些协议适于进行包过滤，而另一些则适于进行流量工程。 而VPN用户有时可能希望同时应用这两类服务来获得最优的网络服务质量。 9. 对现有的路由协议，如BGP，RIP，OSPF，ISIS不进行特别的修改和扩充。这对于将来 在其上叠加其它如NHRP和组播服务是很重要的。此外，对现有协议的改进和增强（如对ISIS 和OSPF在流量工程方面的扩展等）也可以方便地结合进VPN应用中。 5. 结构要求 服务提供商的网络必须支持到所有节点的多播路由，以提供VPN连接和转发虚拟路由器 发现的多播数据。不须指定某个多播路由协议。一个服务提供商SP可以运行MOSPF或DVMRP 或其它协议。 6. 结构框架 1. 每个VPN都指定了一个在SP网络中唯一的VPNID。这个标识明确地表明了与一个包 或一个连接有关的VPN。VPNID为0的标识被保留，用于表示公共Internet。VPN标识最好与 RFC2685[Fox]兼容，但并非必须如此。 2. VPN服务由虚拟路由器提供。这些虚拟路由器位于SPED上，因而限于在SP云的边缘。 虚拟路由器通过SP网络来转发数据包和控制包，但在SPED外并不可见。 3. 与某VPN相关的一给定SPED上的VR的“大小”可以用其所占用的IP资源数量表示， 如路由接口、路由过滤器、路由入口等。这些完全由SP控制，并可以提供SPED级别的精细 的控制粒度，使SP得以提供虚拟的无限等级的VR服务。（例：一个SPED可能是一个给定VPN 的聚集点，如公司总部，其它的SPED可能是接入点，如分公司办公室。在这种情况下，与公 司总部相连的SPED可能需要一个比较大的VR，而其它与分公司相连的只需要小的VR，甚至 是stub VR就行了。）这样，SP在设计网络的时候还可以考虑把负载分布在网络中的各路由 器上。 4. 从SP网络中与某VPN的CPE路由器相连的SPED数目上可以看出该VPN的大小。从这 一点上看，一个连接有许多结点的VPN是一个“大”VPN，否则，就是“小”VPN。而且，一 个VPN可能扩大也可能变小。VPN可能因公司的合并或达成合作协议而合并。这种体系结构 可以很简单地处理这些变化，因为唯一的IP资源并不为某一VPN专用或指定给某一VPN。SPED 的数量也不受任何人工配置条件的限制。 5. SP拥有和管理第一、第二层网络实体。尤其是，SP控制物理的交换机或路由器、物 理连接、第二层逻辑连接（如帧中继的DLCI，ATM的VPI/VCI）以及LSP（和它们对于指定 VPN的任务）等。在VPN中，为其指定和分配第二层实体是SP的责任。 6. PNA拥有和管理第三层实体，包括IP接口、动态路由协议或静态路由表的选择、路 由接口等。注意：虽然逻辑上第三层的配置由PNA负责，但并非必须由PNA执行。由SP负责 VR的IP管理对PNA来说是个更好的选择。不过，无论谁负责配置和检测，PNA所见的都是整 个路由域，这样，PNA便于设计网络实现intranet, extranet及流量工程。 7. 在管理VPN时，就好象使用的是物理路由器，而不是虚拟路由器。因此，可以用SNMP 或其它类似的方法，甚至直接在VRC上来进行网络管理。 8. 在一个路由域内，工业标准的查错工具如PING，traceroute，完全由专用的物理路 由器组成。因此，检测和查错可以用SNMP或类似的方法完成，但也可以使用这些标准工具， 当然也可以使用VRC。 9. 因为VRC对用户是可见的，路由器的特别安全检查应该确保VPN用户只可以使用该VPN 的第三层资源，而不能访问该路由器中的物理资源。许多路由器利用数据库视图来实现这一 功能。 10. SP也可以使用VRC。如果配置和监控都交由SP负责，那么，SP可以象PNA一样用VRC 来完成这些任务。 11. SPED中的VR组成了SP网络中的VPN。同时，它们也代表一个虚拟路由域。它们通过 SP网络内的一个仿真LAN，动态地发现对方。 SP网络中的每个VPN都被且仅被指定一个多播地址。这个地址从可管理范围 （239.192/14）[Meyer]中选取，唯一的要求就是必须与VPN一一对应。只要把一个VPN标识 明确地对应于一个多播地址，就可以通过路由器自动完成这一功能。对多播地址的预约可以 让一个VR发现其它VR或被其它VR发现。要注意的是，多播地址并非是必须配置的。 12. 数据可用下列方法转发： 1. 适用于所有VPN的进行“尽力而为”传送的LSP。 2. 为某一VPN专用，并为VPN用户提供流量工程的LSP。 3. 可提供区分服务的专用LSP。 4. 在专用的第二层虚电路上的基于策略的转发。 对于转发方法的选择，SP和VPN用户可以相互协商，还可以将之作为服务水平协议的一 部分。这样SP可以为不同的VPN用户提供不同等级的服务。 当然，在LSP建立或建立失败期间，也采用逐跳转发的方法转发路由信息包和用户数据 包。 13. 这种方法并不要求SPED上的每个VR上为每个路由协议运行一个单独的操作系统任 务。对使用中的特定的SPED可能要定制一些特别的操作。为每一个VR维护一个独立的路由 数据库和转发表可以使一个给定的SPED获得最好的性能。 7. 可扩展的配置 痛在SP云中，一个典型的VPN一般有100-1000个终端。因此，配置工作与终端节点数是线 性相关的。当一个新用户结点加入某VPN的VR时，管理员必须添加一些配置项。如果情况变 坏，大量的配置工作会让SP感到相当头疼。在这种结构里，SP所要分配和配置的就是出/入 口物理连接（如帧中继DLCI或ATM的VPI/VCI），以及VR与仿真LAN之间的虚连接。 8. 动态邻居发现 给定一VPN的VR都驻留在网络中的一系列SPED中。这些VR应该互相了解，并且连接在一 起。 一种方法就是对邻居进行手工配置。例如，当一个新结点加入到VPN中时，所有其它相 邻的VR都需进行相应的配置。显然这种方法可扩展性相当差。 因此，VR要能进行动态地邻居发现。这可以通过为每一VPN提供一个仿真LAN来实现。 仿真LAN可以有下列作用： 1. 利用该LAN进行与其它VR相关的下一跳IP地址的解析。 2. RIP、OSPF等路由协议可以利用该LAN发现邻居并发送路由更新信息。 每个VPN 的VPN仿真都基于一个IP多播地址。因为要保护公开地址空间，而且多播地址只 能在SP网络空间内可见，我们将使用[Meyer]描述的组织范围的多播地址（239.192/14）。每 个VPN都分配了这样的一个地址。为了减少相应的配置工作，这个地址是根据VPN标识计算 得到的。 9. VPN 的IP域配置 151.0.0.1 ################ # # # 路由器 A # # # ################ # # # # # # # # ############# ############### # # # # # 路由器 B # # 路由器C # # # # # # # # # ############# ############### 152.0.0.2 153.0.0.3 Figure 1：物理路由域 SP网络中的物理路由域如上图所示。在这个网络中，物理路由器A，B，C彼此互联。每个路 由器都有一个指定的公开IP地址。根据这些地址可以唯一地识别每个在SP网络中的路由器。 172.150.0/18 172.150.128/18 ----------------------- ---------------------------| | | | | | 172.150.128.1 | 路由器A (151.0.0.1) | |----------| | ############# | |备件数据库| | ---#-----------# | /---------/ | OSPF | # # ISIS | /----------/ ------------|# VR - A #|-------------- #-------|---#-| #############10.0.0.1/24 |----|------------#-#---------------|-----| |10.0.0.2/24# # |10.0.0.3/24 |------|-------| # # ---------|-------| | ############### # |############### | | # VR - B |# # # VR - C # | |#-------------# 路由器B ##|------------#---- (152.0.0.2)############### ############### (153.0.0.3) ------------------------- 路由器C | Extranet 172.150.64/18 设备商 Figure 2：虚拟路由域 每个虚拟路由器都可被PNA配置，如同一个私有的物理路由器。当然，SP限制虚拟路由 器对资源的使用。每个VPN都有若干与CPE路由器的物理连接，以及若干与仿真LAN的逻辑 连接。每个连接都是支持IP且可配置的，以使用任意的标准路由协议和路由策略的组合连接 到指定的目的公司网络。 如在图2中，VPN1中的3个SPED上有3个VR。VR-A、VR-B、VR-C分别在路由器A、B、 C上，VR-C和VR-B与CPE设备有一个物理连接，而VR-A有两个。每个VR与仿真LAN都有一 个支持IP的逻辑连接。VR-A与公司总部之间的物理连接上运行的是OSPF。因此，它可以转 发到172.150.0/18和172.150.128/18的包。VR-B与分公司的物理连接上运行的是RIP。通 过与VR-A的逻辑连接，VR-B可以用RIP向VR-A发送来自172.150.64/18的包。通过该逻辑 连接，VR-A向VR-B广告一个缺省路由。VR-C作为设备商的外联网连接，与172.150.128.1 上的备件数据库相连。因此，VR-C通过逻辑连接向VR-A广告一个缺省路径，VR-A只向VR-C 传递来自172.150.128.1的包。这样，保证了公司网络其余部分的安全性。 网络管理员将做如下配置： 1． VR-A到172.150.0/18 和 172.150.128/18子网的OSPF连接。 2． VR-A到VR-B和VR-C的RIP连接。 3． VR-A上仅向VR-B广告缺省路径的路由策略； 4． VR-A上向VR-C广告172.159.128.1路由的路由策略； 5． VR-B上与VR-A连接的RIP协议 6． VR-C上向VR-A广告缺省路径的RIP协议 10．邻居发现举例 在图1中，VR-A所在的SPED-A使用的公开IP地址是150.0.0.1/24，SPED-B的是 150.0.0.2/24，SPED-C的是150.0.0.3/24。注意，VR之间的连接是通过仿真LAN实现的。 在仿真LAN连接上的接口地址分别是VR-A：10.0.0.1/24，VR-B：10.0.0.2/24，VR-C： 10.0.0.3/24。 以VR-A向VR-B传送一个数据包为例。要得到VR-B的地址（SPED-B的地址），VR-A发送一个 以VR-B(10.0.0.2)为逻辑地址的ARP请求包。包的源逻辑地址为10.0.0.1，硬件地址为 151.0.0.1。这个ARP请求封装在该VPN的组播地址中发送出去。SPED B和SPED C都收到了 该包的副本。SPED B认出自己的地址，以152.0.0.2为硬件地址给予应答。这个应答被发送 到该VPN的组播地址，以促进无目的ARP的使用和网络流量的减少。 如果没有使用邻居发现策略，就必须进行手工配置。在本例中，VR-A与VR-B逻辑地址 (10.0.0.2)的连接将被配置为一个到硬件地址152.0.0.2的静态ARP入口。 11. 转发 上面已经提到，数据的转发可以有不同的方法。除了逐跳转发路由信息/控制包外，其它的方 法都是可配置的。一方面可用基于策略的转发实现快速服务，另一方面可以用公开LSP实现 尽力而为的转发。转发优先权顺序如下： 1． 基于策略的转发； 2． 可选择性配置的专用LSP； 3． 尽力而为的公开LSP。 11.1专用LSP 这种LSP可以在VPN的基础上进行选择性配置。一般，该LSP都与带宽预留、区分服务或QoS 有关。它可以用于转发用户数据或VPN的专用控制数据。 11.2尽力而为的公开LSP 当不能配置或无法使用具有指定带宽或QoS特性的专用LSP时，VPN的数据包就用公开LSP 进行转发。该LSP的一端是VPN 0的出口路由器。shim 头中的VPN标识用来对出口路由器中 来自不同VPN的数据包进行解复用。 12．区分服务 为VPN配置专用LSP使得SP得以向付费用户提供区分服务。这些专用LSP与可用的第二层 QoS等级或区分服务编码点有关。在一个VPN中，具有不同服务级别的专用LSP不能按流的 包分类属性进行配置。因为这一点以及对虚拟路由器大小的把握，SP得以为VPN用户提供真 正的区分服务。 13．安全问题 13.1路由安全 未经修改的标准路由协议如OSPF、BGP的使用意味着所有的加密和安全方法（如MD5邻 机鉴定）在VR中都可以使用。重要的是，要确保VPN路由信息不会被无意地泄露给其它VPN。 一种实现方法就是保持路由和转发数据库的隔离性。 13.2数据安全 SP可以向VPN用户保证，一个VPN中的数据包不会进入另一个VPN。从路由的角度来看，只 要保证每个虚拟路由器的路由数据库的相互隔离就可以实现了。从数据转发的角度来看，在 共享LSP中使用标签栈[Rosen2] [Callon]，或使用专用LSP也可以保证数据的私有性了。设 置包过滤可以使本问题的解决更为简单。 13.3配置安全 在PNA看来，虚拟路由器就好象是个物理路由器。这意味着PNA可以对它们进行配置，以实 现公司办公室间的连接。显然，SP必须保证只有PNA和PNA的设计者才能进入与专用网相连 的SPED上的虚拟路由器。因为虚拟路由器的控制器VRC与物理路由器在功能上是相同的，所 以一切在物理路由器控制器上可以进行的认证方法，如密码、RADIUS等，PNA都可以实现。 13.4物理网络安全 当一个PNA登录进入一个SPED对VPN进行配置或检测时，实际上PNA进入的是VPN的那个虚 拟路由器。PNA只有对VR进行第三层配置和检测的权限，并不能对物理网络进行配置。这样， 就保证了一个VPN管理人员不会因为疏忽或故意而影响SP的网络。 14．虚拟路由器的检测 物理路由器的所有路由检测功能虚拟路由器都有，包括“ping","traceroute"应用。此外， VR还可以显示专用路由表，连接状态数据库。 15．性能问题 出于性能和可扩展性的考虑，现在的路由器分为两个平面：路由（控制）平面和转发平面。 在路由平面上，许多目前的路由协议使用优化算法计算到终点的最短路径。如，OSPD和ISIS 用Djikstra算法，BGP用“决定过程”。这些算法都是基于对路由数据库的分析和到终点的 最优路径的计算。这些算法的性能特性均取决于其拓扑特点（ISIS和OSPF）或到终点路径上 AS的数目（BGP）。但重要的是，对现在大多数路由器而言，建立和进行这些计算的开销都很 小。因为路由计算时使用的数据库是驻留在内存中的。 因此，我们可以得出下列结论： 1. 对一个路由域进行路由计算并不比建立一些指向数据库对象的寄存器开销更大； 2. 一个给定的算法的性能不会因为建立时的开销而显著降低； 3. 当一个物理路由器要为若干虚拟路由器进行路由计算时，其计算复杂性并不比单个虚 拟路由器的路由计算复杂性之和更高。 4. 无论是使用叠加模式还是虚拟路由器模式，一个路由器的性能特点都只取决于它的硬 件能力、数据结构和算法的选择。 为了进一步说明，让我们看一个有N个VPN的物理路由器，其上运行的是被称为RP的路由协 议。假设RP路由计算算法的平均性能是f(X,Y)，X和Y是决定路由协议算法性能的参数。例 如，对使用Djikstra算法的如OSPF，X可能是区域中的节点数，而Y是连接数。任一VPN n 的性能是f (Xn, Yn)。（物理）路由器的性能是f(Xi, Yi)之和（0<=i<= N）。这个结论与VPN 实现方法（虚拟路由器模式或叠加模式）的选择无关。 一般情况下，转发平面有两项输入：转发表和包头。主要的性能参数是查询算法。最好能将 IP路由表组织成树状结构，用二分法进行查找。该算法的性能是O(log n)。 因此，只要虚拟路由器的路由表彼此不同，查询路由表的开销就是固定的，O(log n)就可以 找到入口。这与采用叠加模式的VPN并没什么不同。在叠加模式中，叠加路由器使用的是多 个VPN路由表的集成，其性能为O(log m*n)，m表示该路由表中VPN的数目。 16. 致谢 The authors wish to thank Dave Ryan, Lucent Technologies for his invaluable in-depth review of this version of this memo. 17. 参考文献 [Callon] Callon R., et al., "A Framework for Multiprotocol Label Switching", Work in Progress. [Fox] Fox, B. and B. Gleeson,"Virtual Private Networks Identifier", RFC 2685, September 1999. [Meyer] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [Rosen1] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", Work in Progress. 18. 作者地址 Karthik Muthukrishnan Lucent Technologies 1 Robbins Road Westford, MA 01886 Phone: (978) 952-1368 EMail: mkarthik@lucent.com Andrew Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Phone: (408) 383-7223 EMail: Andy.Malis@vivacenetworks.com 19. 版权声明 Copyright (C) The Internet Society (2000). All Rights Reserved. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Muthukrishnan & Malis Informational [Page 16] RFC2917--A Core MPLS IP VPN Architecture 核心 MPLS IP VPN 体系结构 1 RFC文档中文翻译计划