Internet Draft




Internet Engineering Task Force                            Juha Heinanen
INTERNET DRAFT                                       Telia Finland, Inc.
Expires September 1998                                        Eric Rosen
                                                           cisco Systems


                         VPN support with MPLS
                    <draft-heinanen-mpls-vpn-01.txt>




1. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and=

   its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


2. Abstract

   This document provides a high-level description of how Virtual
   Private Networks can be supported by using MPLS.














Heinanen                 VPN Support with MPLS                  [Page 1]





INTERNET DRAFT                                               March, 1998


3. Introduction

   Intranets are one of the fast growing ways to deploy the TCP/IP
   protocol suite.  In order to provide Intranet services to its
   customers, Service Providers must be able to address the problems of
   data privacy and addressing privacy (the use of non-unique, private
   IP addresses [2]).  It turns out that Multiprotocol Label Switching
   (MPLS) [1], due to its ability to decouple packet forwarding from the
   context of a packet's IP header, provides a simple and effective
   solution to these important problems.

   The following sections discuss various ways to support VPNs over a
   Service Provider network that implements MPLS. They cover both the
   case where the customer VPN site participates and the case where the
   customer site does not participate in MPLS with the Service Provider
   network.  In the latter case, the customer site need not implement
   MPLS at all.

   It is assumed that the customer sites exchange reachability
   information with the Service Provider network either using static
   routing or BGP; the customer sites do not need to directly exchange
   routing information with each other. Within the Service Provider
   network the assumption is that either OSPF and Label Distribution
   Protocol (LDP) [3] or BGP is used to distribute reachability and
   label binding information.


4. Virtual Private Networks (VPNs)

   To form a VPN over a set of customer sites connected to a Service
   Provider network, each such site advertises to the Service Provider a
   set of destinations reachable within the site, and the Service
   Provider network redistributes this information to all other sites in
   the set.

   Since a Service Provider network needs to support multiple VPNs, and
   since these VPNs could use private address spaces [2], the routing
   system within the Service Provider network needs to disambiguate
   between reachability information associated with different VPNs. To
   accomplish this, the Service Provider assigns each VPN its own VPN
   Identifier; the routing system uses a combination of this VPN
   Identifier and normal reachability information for disambiguating
   reachability information associated with different VPNs.  Use of VPN
   Identifiers allows a single routing system to support multiple VPNs
   whose address spaces overlap with each other.

   A VPN Identifier can be constructed, for example, by appending an
   integer that uniquely identifies a VPN within a Service Provider



Heinanen                 VPN Support with MPLS                  [Page 2]





INTERNET DRAFT                                               March, 1998


   network to an Autonomous System (AS) number of that network.

   A site can at the same time be a member of more than one VPN.

   A VPN could be connected to the Internet. Exchange of routing
   information in support of the connectivity to the Internet could be
   accomplished by precisely the same means as it is accomplished in the
   absence of VPNs and MPLS.


5. Distribution of routing information between a customer site and the
   Service Provider network

   The customer router that connects the customer site to the Service
   Provider network can either participate or not participate in MPLS
   with the Service Provider network.  In either case, the Service
   Provider LSR that connects the site to the Service Provider network
   is configured with the list of VPN Identifiers of the VPNs that the
   customer site belong to.


5.1. Customer router participates in MPLS with the Service Provider LSR

   When the customer router participates in MPLS with the Service
   Provider LSR, BGP is used to distribute both IP reachability
   information and label bindings between the customer site and the
   Service Provider network. Distribution of label bindings with BGP is
   described in [4].  This allows the customer LSR and the Service
   Provider LSR to inform each other about the routes that are available
   for each VPN and what labels have been bound to them.

   When the Service Provider LSR receives an advertisement from the
   customer LSR, the Service Provider LSR identifies the VPN that the
   customer LSR belongs to, and uses a combination of the VPN Identifier
   of that VPN and the reachability information received via this
   advertisement to distribute this combination within the Provider's
   network.  Correspondingly, the Provider's LSR forwards to the
   customer site only those advertisements that belong to the VPN(s)
   that the site belongs to.

   If a customer site belongs to multiple VPNs, it may want to
   dynamically exchange information with the Service Provider network
   regarding which routes belong to which VPNs. This could be
   accomplished either by requiring the site to maintain multiple
   routing peerings with the Service Provider (one peering per VPN), or
   by requiring that the routing advertisements carry not just the
   reachability information, but a combination of VPN Identifier and the
   reachability information. This combination would allow the Service



Heinanen                 VPN Support with MPLS                  [Page 3]





INTERNET DRAFT                                               March, 1998


   Provider LSR to unambiguously determine how this information has to
   be distributed.

   If the customer site and the Service Provider network don't want to
   exchange reachability information using a routing protocol, it is
   still possible for them to dynamically inform each other which
   address prefixes belong to which VPNs by extending LDP to carry not
   just address prefixes, but a combination of VPN Identifiers and
   address prefixes. In this context one may consider treating LDP as a
   protocol that advertises not just label binding, but the reachability
   information as well. The details of doing this are left for further
   study.


5.2. Customer router does not participate in MPLS with the Service
   Provider LSR

   When the customer router does not participate in MPLS with the
   Service Provider LSR, it is assumed that reachability information
   between the customer router and the Service Provider LSR is
   distributed either via static routing or using BGP.

   In the case of static routing, the Service Provider LSR connected to
   a customer router controls (based on its configuration information)
   how the reachability information for the site that the customer
   router belongs to gets combined with the VPN Identifier(s) that the
   site belongs to.

   When BGP is used to exchange routing information between a customer
   router and a Service Provider router, procedures for doing this are
   similar to the ones described in the previous section, except that
   BGP doesn't carry label binding information.

   The most important difference between this case and the case
   described in the previous section is that when a customer router
   doesn't participate in MPLS with the Service Provider LSR, the
   Service Provider LSR must have unambiguous procedures by which it can
   classify packets arrived from directly connected customer routers
   into VPNs. If a site belongs to multiple VPNs, this requires that the
   address spaces of these VPNs do not overlap.











Heinanen                 VPN Support with MPLS                  [Page 4]





INTERNET DRAFT                                               March, 1998


6. Distribution of VPN bindings within the Service Provider network

   When a Service Provider LSR learns a combination of VPN Identifier
   and reachability information (and possibly also a label binding) from
   a customer site, it must somehow make this combined information known
   to the other customer sites that are members of the same VPN.  This
   section covers the cases where either OSPF and LDP or BGP is used to
   distribute reachability information and label bindings within the
   Service Provider network.

   If the Service Provider network is using OSPF to distribute
   reachability information, the Service Provider LSR that receives
   reachability information from a customer site injects this
   information together with the corresponding VPN identifier in its
   OSPF process. The VPN identifier allows the OSPF process to
   disambiguate among (potentially) overlapping addresses of multiple
   VPNs.  One possibility is to use the Opaque LSA option [5].  Details
   of carrying the VPN Identifier in OSPF is left for further study.

   In addition to injecting the stream to its OSPF process, the Service
   Provider's LSR also advertises the corresponding label to its peers
   within the Provider's network using LDP.  This advertisement is
   otherwise a normal LDP advertisement except that, as in above, the
   VPN Identifier is included in the LDP messages.  The VPN identifier
   is used by the receiving LSR to disambiguate among (potentially)
   ambiguous routes.

   If the Service Provider network is using BGP to distribute
   reachability information, then also the corresponding labels can be
   piggybacked into BGP advertisements in the same way as was done above
   between the customer router and the Service Provider LSR.  For VPN
   support, the advertisements must include the VPN identifier.  Use of
   LSP hierarchy and two levels of labels [3] could be used to improved
   scaling properties.

   If the customer router does not participate in MPLS with the Service
   Provider LSR then the Service Provider's LSR that advertises a route
   reachable via the customer site also terminates the corresponding
   Label Switched Path (LSP) [1].  When terminating the LSP, the LSR
   uses the label carried by packets to map the enclosed (IP or MPLS)
   packets to the correct customer site.










Heinanen                 VPN Support with MPLS                  [Page 5]





INTERNET DRAFT                                               March, 1998


7. Use of BGP

   VPN Identifiers could be carried in BGP as part of NLRI using the BGP
   Multiprotocol Extensions attribute [6]. The associated label binding
   information could be carried as part of this attribute as well,
   similar to [7].

   In addition, VPN Identifiers could be carried in the BGP Community
   Attribute [8], if needed.


8. Security considerations

   As shown in this document, MPLS can be used to implement VPNs over a
   Service Provider network, where the VPNs are fully isolated from each
   other in terms of both visibility and packet forwarding.  The data
   privacy is accomplished by manually associating a set of unique VPN
   Identifiers to the customer interfaces of the Service Provider's
   LSRs.

   The VPN Identifiers are used to limit the distribution of both
   reachability and label information.  If a customer site has not
   received a label for a particular destination, it has no means to
   send labeled packets to that destination provided that the LSRs
   assign the labels so that they are unique per interface.  Similarly,
   in the case of a non-MPLS customer site, the Service Provider network
   would not forward IP packets to destinations that are not advertised
   by the other members of the VPN.

   Manual configuration of the VPN Identifiers is always subject to
   human error.  However, configuration of a single VPN Identifier once
   per customer interface is a much simpler process than configuration
   of a list of IP address prefixes, since the latter need to be
   modified each time a new customer site is added to or removed from
   the VPN.
















Heinanen                 VPN Support with MPLS                  [Page 6]





INTERNET DRAFT                                               March, 1998


9. Intellectual Property Considerations

   Cisco Systems may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Cisco Systems, Cisco
   intends to disclose those patents and license them on reasonable and
   non-discriminatory terms.


10. References

   [1] Callon, R., et al, "A Framework for Multiprotocol Label
   Switching", draft-ietf-mpls-framework-02.txt.

   [2] Rekhter, Y., et al., "Address Allocation for Private Internets",
   RFC1918, Feb 1996.

   [3]  Rosen, Eric et al, "A Proposed Architecture for MPLS", draft-
   ietf-mpls-arch-00.txt.

   [4] Rekhter, Yakov and Rosen, Eric, "Carrying Label Information in
   BGP-4", draft-rekhter-bgp4-mpls-00.txt.

   [5] Coltun, Rob, "The OSPF Opaque LSA Option", draft-ietf-ospf-
   opaque-02.txt.

   [6] Bates, Tony, et al, "Multiprotocol Extensions for BGP-4",
   RFC2283, Feb 1998

   [7] Rekhter, Yakov, Rosen, Eric, "Carrying Label Information in BGP-
   4", draft-rekhter-bgp4-mpls-00.txt.

   [8] Chandra, Ravi, et al, "BGP Communities Attribute", RFC1997,
   August 1996

11. Author Information














Heinanen                 VPN Support with MPLS                  [Page 7]





INTERNET DRAFT                                               March, 1998



   Juha Heinanen
   Telia Finland, Inc.
   Myyrmaentie 2
   01600 VANTAA
   Finland

   Phone +358 303 944 808
   Email: jh@telia.fi

   Eric Rosen
   cisco Systems. Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Email: erosen@cisco.com