RFC 2917 (rfc2917) - Page 2 of 16
A Core MPLS IP VPN Architecture
Alternative Format: Original Text Document
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