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]