RFC 2917 (rfc2917) - Page 2 of 16

A Core MPLS IP VPN Architecture

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