One document matched: draft-heinanen-mpls-vpn-00.txt

Internet Engineering Task Force                            Juha Heinanen
INTERNET DRAFT                                       Telia Finland, Inc.
Expires June 1998                                          December 1997


                          VPN support for MPLS
                    <draft-heinanen-mpls-vpn-00.txt>



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).

Abstract

   This document discusses the need to include support for Virtual
   Private Networks in MPLS and gives a high-level description on how it
   can be accomplished.

1. Introduction

   The Framework for MPLS document [1] contains a long list of benefits
   that MPLS has as compared to conventional router backbones.  For some
   reason it doesn't include easy support for Virtual Private Networks
   (VPNs) as one of them.  Either VPN support is one of the best kept
   secrets of the MPLS design team or the authors of the framework
   document have not considered VPN support as an issue worth
   mentioning.

   Intranets are one of the fast growing ways to deploy the TCP/IP
   protocol suite.  In order to provide Intranet services to its (best
   paying) customers, ISPs must be able to address the problems of
   security and use of non-unique, private IP addresses [2].  It turns



Heinanen                  VPN Support for MPLS                  [Page 1]

INTERNET DRAFT                                            December, 1997


   out that MPLS, due to its Layer 2, virtual circuit nature, provides a
   simple and efficient solution to these important problems.

   In conventional router backbones, IP packets are forwarded based on
   destination IP addresses, which must be unique within the backbone.
   It would not help to have a separate forwarding table for each VPN,
   since there is no VPN identifier in the IP packet header that could
   be used to select the correct forwarding table.  MPLS backbone
   routers, on the other hand, can benefit from a separate routing table
   per VPN, since the tables are not used to forward IP packets, but to
   control label distribution.  In MPLS backbones it is enough that the
   destination addresses are unique at the ingress LSRs, which attach
   the labels to the IP packets.  This is the key observation that
   allows efficient implementation of VPNs in the MPLS environment.

   The following sections discuss various ways to support VPNs over an
   MPLS backbone.  It is assumed that customer VPN sites communicate
   with the MPLS backbone either using static routes and LDP or BGP and
   that within the MPLS backbone either OSPF and LDP or IBGP are used to
   distribute the reachability and label binding information.

2. Virtual Private Networks (VPNs)

   In this document the term VPN is used to denote a set of customer
   sites that connect to the MPLS backbone and form a Closed User Group
   (CUG).  A site may advertise a set of "streams" [3] to the other
   members of a CUG.  This allows the other CUG members (and only them)
   to send IP packets to those streams.  The advertised streams need
   only be unique within the CUG(s) to which the site belongs to.

   A site can at the same time be a member of more than one CUG and also
   be connected to the public Internet.  In the latter case, the site
   advertises (some of) its streams without associating them with any
   CUG.  The public Internet can thus be considered to be a special CUG
   that does not have any CUG identification.

   CUGs are identified within MPLS backbones using unique CUG
   identifiers.  A CUG identifier can be constructed, for example, by
   appending an integer that uniquely identifies a CUG with a single
   MPLS backbone to an IP address owned by that backbone.  Between a
   customer site and an MPLS backbone, a CUG can be identified using a
   CUG index, which is an integer that uniquely distinguishes the CUG
   among all CUGs defined over that link.

3. Distribution of VPN bindings to and from the MPLS backbone

   When a customer site is connected to an MPLS backbone, the
   corresponding interface of the backbone LSR is configured with a list



Heinanen                  VPN Support for MPLS                  [Page 2]

INTERNET DRAFT                                            December, 1997


   of CUG identifiers that correspond to the CUGs that the customer site
   belongs to and with a mapping that describes the correspondence
   between these CUG identifiers and the CUG indexes used over the link
   between the customer LSR and the backbone LSR.

   IP routing between the customer site and the MPLS backbone is assumed
   to be based either on static routes or BGP.

   If static routes are used, then the Label Distribution Protocol (LDP)
   [3] needs to be turned on between the customer LSR and the backbone
   LSR for advertisement of the label bindings.  In order to support
   VPNs, the LDP advertisement message need to be extended with the CUG
   index so that the two LSRs know which VPN an advertisement belongs
   to.  Since the LDP advertisements also carry stream information,
   manual configuration of static routes in the two LSRs would not be
   necessarily needed.

   If BGP is used between the customer site and the MPLS backbone, then
   the label bindings are included in BGP advertisements by extending
   BGP with label and CUG index attributes.  The LDP would thus not need
   to be turned on between the customer LSR and the backbone LSR.

   When the above configuration tasks have been completed, the customer
   LSR and backbone LSR use either LDP or BGP to inform each other what
   streams are available for each VPN and what labels have been bound to
   them.  The backbone LSR checks that the customer site really is a
   member of the VPN before it accepts a label binding from the customer
   LSR.  Correspondingly, before a backbone LSR distributes a label
   binding to a customer LSR, it checks to see that the customer site is
   really configured to belong to the same VPN as the advertised label
   binding.

   If the customer site belongs to only one VPN, it should not be
   bothered with the knowledge of the VPNs.  In that case, the only VPN
   is configured as the default VPN to the corresponding interface of
   the backbone LSR and the two LSRs don't include a CUG index in their
   advertisements to each other.

4. Distribution of VPN bindings within the MPLS backbone

   When a backbone LSR learns a label binding from a customer site, it
   must somehow make the stream (and a corresponding label binding)
   known to the other CUG members.  This chapter covers the cases where
   either OSPF and LDP or IBGP is used to distribute the label bindings.

   If the MPLS backbone is using OSPF and LDP to distribute the routing
   information and label bindings, the backbone LSR that learns a
   binding from a customer LSR injects the stream together with the



Heinanen                  VPN Support for MPLS                  [Page 3]

INTERNET DRAFT                                            December, 1997


   corresponding VPN identifier to its OSPF process.  The VPN identifier
   allows the OSPF process to construct for each VPN its own routing
   table.  This is needed, because the VPNs may use overlapping, private
   IP addresses.  How the VPN identifier is associated with the stream
   in the OSPF advertisement is left for further study.  One possibility
   is to use the Opaque LSA option [4].

   In addition to injecting the stream to its OSPF process, the backbone
   LSR also advertises a corresponding label binding to its peers within
   the MPLS backbone.  This advertisement is otherwise normal except
   that also the CUG identifier is included in the advertisement
   message.

   If the MPLS backbone is using IBGP to distribute the label bindings,
   then it suffices that a backbone LSR that learned a binding from a
   customer LSR injects the binding together with the CUG identifier to
   its IBGP process.  This requires that BGP is extended with two
   attributes: one for the CUG identifier and one for the label.  The
   details of these extensions are left for further study.

5. Security considerations

   As shown in this document, MPLS can be used to implement secure VPNs
   over a single MPLS backbone where the VPNs are fully isolated from
   each other in terms of both visibility and packet forwarding.  The
   security is accomplished by manually associating a set of unique CUG
   identifiers to the customer interfaces of the backbone LSRs.

   The CUG identifiers 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 packets to that
   destination provided that the LSRs assign the labels so that they are
   unique per interface, not per LSR.

   Manual configuration of the CUG identifiers is always subject to
   human error.  However, configuration of a single CUG identifier once
   per 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.

6. Summary

   This document has argued that VPN support should be an essential part
   of the MPLS protocol.  Easy and efficient support for VPNs is seen as
   the killer application for MPLS without which the whole MPLS effort
   is hard to justify.  It is therefore suggested that the MPLS working
   group incorporates VPN support in its current work plan.




Heinanen                  VPN Support for MPLS                  [Page 4]

INTERNET DRAFT                                            December, 1997


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".
   RFC 1918, Feb 1996.

   [3] Feldman, Nancy, et al, "LDP Specification".  draft-feldman-ldp-
   spec-00.txt.

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

Acknowledgements

   I would like to thank Rob Coltun for listening to my initial ideas
   and Yakov Rekhter for pointing out the importance of IBGP.

Author Information

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

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






















Heinanen                  VPN Support for MPLS                  [Page 5]