rfc2917.txt

RFC规范的翻译稿

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: [phone]
   EMail: [e-mail]


   Andrew Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134

   Phone: [phone]
   EMail: [e-mail]

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文档中文翻译计划