rfc2917.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   packets among the LSPs. This feature, together with the ability to
   size the virtual routers, allows the SP to offer truly differentiated
   services to the VPN customer.

13.  Security Considerations

13.1  Routing Security

   The use of standard routing protocols such as OSPF and BGP in their
   unmodified form means that all the encryption and security methods
   (such as MD5 authentication of neighbors) are fully available in VRs.
   Making sure that routes are not accidentally leaked from one VPN to
   another is an implementation issue. One way to achieve this is to
   maintain separate routing and forwarding databases.



Muthukrishnan & Malis        Informational                     [Page 11]

RFC 2917                       Core VPNs                  September 2000


13.2  Data Security

   This allows the SP to assure the VPN customer that data packets in
   one VPN never have the opportunity to wander into another. From a
   routing standpoint, this could be achieved by maintaining separate
   routing databases for each virtual router. From a data forwarding
   standpoint, the use of label stacks in the case of shared LSPs
   [Rosen2] [Callon] or the use of private LSPs guarantees data privacy.
   Packet filters may also be configured to help ease the problem.

13.3  Configuration Security

   Virtual routers appear as physical routers to the PNA. This means
   that they may be configured by the PNA to achieve connectivity
   between offices of a corporation. Obviously, the SP has to guarantee
   that the PNA and the PNA's designees are the only ones who have
   access to the VRs on the SPEDs the private network has connections
   to. Since the virtual router console is functionally equivalent to a
   physical router, all of the authentication methods available on a
   physical console such as password, RADIUS, etc. are available to the
   PNA.

13.4 Physical Network Security

   When a PNA logs in to a SPED to configure or monitor the VPN, the PNA
   is logged into the VR for the VPN. The PNA has only layer 3
   configuration and monitoring privileges for the VR. Specifically, the
   PNA has no configuration privileges for the physical network. This
   provides the guarantee to the SP that a VPN administrator will not be
   able to inadvertently or otherwise adversely affect the SP's network.

14.  Virtual Router Monitoring

   All of the router monitoring features available on a physical router
   are available on the virtual router. This includes utilities such as
   "ping" and "traceroute". In addition, the ability to display private
   routing tables, link state databases, etc. are available.

15. Performance Considerations

   For the purposes of discussing performance and scaling issues,
   today's routers can be split into two planes: the routing (control)
   plane and the forwarding plane.

   In looking at the routing plane, most modern-day routing protocols
   use some form of optimized calculation methodologies to calculate the
   shortest path(s) to end stations. For instance, OSPF and ISIS use the
   Djikstra algorithm while BGP uses the "Decision Process". These



Muthukrishnan & Malis        Informational                     [Page 12]

RFC 2917                       Core VPNs                  September 2000


   algorithms are based on parsing the routing database and computing
   the best paths to end stations. The performance characteristics of
   any of these algorithms is based on either topological
   characteristics (ISIS and OSPF) or the number of ASs in the path to
   the destinations (BGP). But it is important to note that the overhead
   in setting up and beginning these calculations is very little for
   most any modern day router. This is because, although we refer to
   routing calculation input as "databases", these are memory resident
   data structures.

   Therefore, the following conclusions can be drawn:

   1. Beginning a routing calculation for a routing domain is nothing
      more than setting up some registers to point to the right database
      objects.

   2. Based on 1, the performance of a given algorithm is not
      significantly worsened by the overhead required to set it up.

   3. Based on 2, it follows that, when a number of routing calculations
      for a number of virtual routers has to be performed by a physical
      router, the complexity of the resulting routing calculation is
      nothing more than the sum of the complexities of the routing
      calculations of the individual virtual routers.

   4. Based on 3, it follows that whether an overlay model is used or a
      virtual routing model is employed, the performance characteristics
      of a router are dependent purely on its hardware capabilities and
      the choice of data structures and algorithms.

   To illustrate, let's say a physical router houses N VPNs, all running
   some routing protocol say RP. Let's also suppose that the average
   performance of RP's routing calculation algorithm is  f(X,Y) where x
   and y are parameters that determine performance of the algorithm for
   that routing protocol. As an example, for Djikstra algorithm users
   such as OSPF, X could be the number of nodes in the area while Y
   could be the number of links. The performance of an arbitrary VPN n
   is f (Xn, Yn). The performance of the (physical) router is the sum of
   f(Xi, Yi) for all values of i in 0 <= i <= N. This conclusion is
   independent of the chosen VPN approach (virtual router or overlay
   model).

   In the usual case, the forwarding plane has two inputs: the
   forwarding table and the packet header. The main performance
   parameter is the lookup algorithm. The very best performance one can
   get for a IP routing table lookup is by organizing the table as some
   form of a tree and use binary search methods to do the actual lookup.
   The performance of this algorithm is O(log n).



Muthukrishnan & Malis        Informational                     [Page 13]

RFC 2917                       Core VPNs                  September 2000


   Hence, as long as the virtual routers' routing tables are distinct
   from each other, the lookup cost is constant for finding the routing
   table and O(log n) to find the entry. This is no worse or different
   from any router and no different from a router that employs overlay
   techniques to deliver VPN services. However, when the overlay router
   utilizes integration of multiple VPNs' routing tables, the
   performance is O(log m*n) where 'm' is the number of VPNs that the
   routing table holds routes for.

16. Acknowledgements

   The authors wish to thank Dave Ryan, Lucent Technologies for his
   invaluable in-depth review of this version of this memo.

17.  References

   [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.





















Muthukrishnan & Malis        Informational                     [Page 14]

RFC 2917                       Core VPNs                  September 2000


18. Authors' Addresses

   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]

































Muthukrishnan & Malis        Informational                     [Page 15]

RFC 2917                       Core VPNs                  September 2000


19.  Full Copyright Statement

   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]