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