A Core MPLS IP VPN Architecture
RFC 2917

Document Type RFC - Informational (September 2000; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2917 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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

   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.
Show full document text