rfc2917.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

Network Working Group                                    K. Muthukrishnan
Request for Comments: 2917                            Lucent Technologies
Category: Informational                                          A. Malis
                                                    Vivace Networks, Inc.
                                                           September 2000


                    A Core MPLS IP VPN Architecture

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 (2000).  All Rights Reserved.

Abstract

   This memo presents an approach for building core Virtual Private
   Network (VPN) services in a service provider's MPLS backbone.  This
   approach uses Multiprotocol Label Switching (MPLS) running in the
   backbone to provide premium services in addition to best effort
   services. The central vision is for the service provider to provide a
   virtual router service to their customers. The keystones of this
   architecture are ease of configuration, user security, network
   security, dynamic neighbor discovery, scaling and the use of existing
   routing protocols as they exist today without any modifications.

1. Acronyms

        ARP     Address Resolution Protocol
        CE      Customer Edge router
        LSP     Label Switched Path
        PNA     Private Network Administrator
        SLA     Service Level Agreement
        SP      Service Provider
        SPED    Service Provider Edge Device
        SPNA    SP Network Administrator
        VMA     VPN Multicast Address
        VPNID   VPN Identifier
        VR      Virtual Router
        VRC     Virtual Router Console






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


2. Introduction

   This memo describes an approach for building IP VPN services out of
   the backbone of the SP's network. Broadly speaking, two possible
   approaches present themselves: the overlay model and the virtual
   router approach. The overlay model is based on overloading some
   semantic(s) of existing routing protocols to carry reachability
   information.  In this document, we focus on the virtual router
   service.

   The approach presented here does not depend on any modifications of
   any existing routing protocols. Neighbor discovery is aided by the
   use of  an emulated LAN and is achieved by the use of ARP. This memo
   makes a concerted effort to draw the line between the SP and the PNA:
   the SP owns and manages layer 1 and layer 2 services while layer 3
   services belong to and are manageable by the PNA. By the provisioning
   of fully logically independent routing domains, the PNA has been
   given the flexibility to use private and unregistered addresses. Due
   to the use of private LSPs and the use of VPNID encapsulation using
   label stacks over shared LSPs, data security is not an issue.

   The approach espoused in this memo differs from that described in RFC
   2547 [Rosen1] in that no specific routing protocol has been
   overloaded to carry VPN routes.  RFC 2547 specifies a way to modify
   BGP to carry VPN unicast routes across the SP's backbone. To carry
   multicast routes, further architectural work will be necessary.

3. Virtual Routers

   A virtual router is a collection of threads, either static or
   dynamic, in a routing device, that provides routing and forwarding
   services much like physical routers. A virtual router need not be a
   separate operating system process (although it could be); it simply
   has to provide the illusion that a dedicated router is available to
   satisfy the needs of the network(s) to which it is connected. A
   virtual router, like its physical counterpart, is an element in a
   routing domain. The other routers in this domain could be physical or
   virtual routers themselves. Given that the virtual router connects to
   a specific (logically discrete) routing domain and that a physical
   router can support multiple virtual routers, it follows that a
   physical router supports multiple (logically discreet) routing
   domains.

   From the user (VPN customer) standpoint, it is imperative that the
   virtual router be as equivalent to a physical router as possible. In
   other words, with very minor and very few exceptions, the virtual
   router should appear for all purposes (configuration, management,
   monitoring and troubleshooting) like a dedicated physical router. The



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


   main motivation behind this requirement is to avoid upgrading or re-
   configuring the large installed base of routers and to avoid
   retraining of network administrators.

   The aspects of a router that a virtual router needs to emulate are:

   1. Configuration of any combination of routing protocols

   2. Monitoring of the network

   3. Troubleshooting.

   Every VPN has a logically independent routing domain. This enhances
   the SP's ability to offer a fully flexible virtual router service
   that can fully serve the SP's customer without requiring physical
   per-VPN routers. This means that the SP's "hardware" investments,
   namely routers and links between them, can be re-used by multiple
   customers.

4. Objectives

   1. Easy, scalable configuration of VPN endpoints in the service
      provider network. At most, one piece of configuration should be
      necessary when a CE is added.

   2. No use of SP resources that are globally unique and hard to get
      such as IP addresses and subnets.

   3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. This
      is an optional, but extremely valuable "keep it simple" goal.

   4. Virtual Routers should be fully configurable and monitorable by
      the VPN network administrator. This provides the PNA with the
      flexibility to either configure the VPN themselves or outsource
      configuration tasks to the SP.

   5. Quality of data forwarding should be configurable on a VPN-by-VPN
      basis.  This should translate to continuous (but perhaps discrete)
      grades of service.  Some examples include best effort, dedicated
      bandwidth, QOS, and policy based forwarding services.

   6. Differentiated services should be configurable on a VPN-by-VPN
      basis, perhaps based on LSPs set up for exclusive use for
      forwarding data traffic in the VPN.







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


   7. Security of internet routers extended to virtual routers. This
      means that the virtual router's data forwarding and routing
      functions should be as secure as a dedicated, private physical
      router.  There should be no unintended leak of information (user
      data and reachability information) from one routing domain to
      another.

   8. Specific routing protocols should not be mandated between virtual
      routers. This is critical to ensuring the VPN customer can setup
      the network and policies as the customer sees fit. For example,
      some protocols are strong in filtering, while others are strong in
      traffic engineering. The VPN customer might want to exploit both
      to achieve "best of breed" network quality.

   9. No special extensions to existing routing protocols such as BGP,
      RIP, OSPF, ISIS etc. This is critical to allowing the future
      addition of other services such as NHRP and multicast. In
      addition, as advances and addenda are made to existing protocols
      (such as traffic engineering extensions to ISIS and OSPF), they
      can be easily incorporated into the VPN implementation.

5. Architectural Requirements

   The service provider network must run some form of multicast routing
   to all nodes that will have VPN connections and to nodes that must
   forward multicast datagrams for virtual router discovery. A specific
   multicast routing protocol is not mandated. An SP may run MOSPF or
   DVMRP or any other protocol.

6. Architectural Outline

   1.  Every VPN is assigned a VPNID which is unique within the SP's
       network.  This identifier unambiguously identifies the VPN with
       which a packet or connection is associated. The VPNID of zero is
       reserved; it is associated with and represents the public
       internet.  It is recommended, but not required that these VPN
       identifiers will be compliant with RFC 2685 [Fox].

   2.  The VPN service is offered in the form of a Virtual Router
       service.  These VRs reside in the SPED and are as such confined
       to the edge of the SP's cloud. The VRs will use the SP's network
       for data and control packet forwarding but are otherwise
       invisible outside the SPEDs.

   3.  The "size" of the VR contracted to the VPN in a given SPED is
       expressed by the quantity of IP resources such as routing
       interfaces, route filters, routing entries etc. This is entirely
       under the control of the SP and provides the fine granularity



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


       that the SP requires to offer virtually infinite grades of VR
       service on a per-SPED level. [Example: one SPED may be the
       aggregating point (say headquarters of the corporation) for a
       given VPN and a number of other SPEDs may be access points
       (branch offices). In this case, the SPED connected to the
       headquarters may be contracted to provide a large VR while the
       SPEDs connected to the branch offices may house small, perhaps
       stub VRs]. This provision also allows the SP to design the
       network with an end goal of distributing the load among the
       routers in the network.

   4.  One indicator of the VPN size is the number of SPEDs in the SP's
       network that have connections to CPE routers in that VPN.  In
       this respect, a VPN with many sites that need to be connected is
       a "large" VPN whereas one with a few sites is a "small" VPN.
       Also, it is conceivable that a VPN grows or shrinks in size over
       time. VPNs may even merge due to corporate mergers, acquisitions
       and partnering agreements. These changes are easy to accommodate
       in this architecture, as globally unique IP resources do not have
       to be dedicated or assigned to VPNs. The number of SPEDs is not
       limited by any artificial configuration limits.

   5.  The SP owns and manages Layer 1 and Layer 2 entities. To be
       specific, the SP controls physical switches or routers, physical
       links, logical layer 2 connections (such as DLCI in Frame Relay
       and VPI/VCI in ATM) and LSPs (and their assignment to specific
       VPNs).  In the context of VPNs, it is the SP's responsibility to
       contract and assign layer 2 entities to specific VPNs.

   6.  Layer 3 entities belong to and are manageable by the PNA.
       Examples of these entities include IP interfaces, choice of
       dynamic routing protocols or static routes, and routing
       interfaces. Note that although Layer 3 configuration logically
       falls under the PNA's area of responsibility, it is not necessary
       for the PNA to execute it.  It is quite viable for the PNA to
       outsource the IP administration of the virtual routers to the
       Service Provider.  Regardless of who assumes responsibility for
       configuration and monitoring, this approach provides a full
       routing domain view to the PNA and empowers the PNA to design the
       network to achieve intranet, extranet and traffic engineering
       goals.

   7.  The VPNs can be managed as if physical routers rather than VRs
       were deployed.  Therefore, management may be performed using SNMP
       or other similar methods or directly at the VR console (VRC).






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


   8.  Industry-standard troubleshooting tools such as 'ping,'
       'traceroute,' in a routing domain domain comprised exclusively of
       dedicated physical routers.  Therefore, monitoring and .bp
       troubleshooting may be performed using SNMP or similar methods,
       but may also include the use of these standard tools. Again, the
       VRC may be used for these purposes just like any physical router.

   9.  Since the VRC is visible to the user, router specific security
       checks need to be put in place to make sure the VPN user is
       allowed access to Layer 3 resources in that VPN only and is
       disallowed from accessing physical resources in the router.  Most
       routers achieve this through the use of database views.

   10. The VRC is available to the SP as well. If configuration and