Internet Draft draft-casey-mpls-vpn-00.txt November 1998
MPLS Working Group L. Casey
Internet Draft I. Cunningham
Expiration Date: May 1999 R. Eros
Nortel Networks
November 1998
IP VPN Realization using MPLS Tunnels
<draft-casey-vpn-mpls-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 Internet Draft describes a method of using MPLS to realize
a provider IP VPN capability. The approach described here
exploits the Label Switch Path (LSP) mesh implicitly established
between all edge routers in an MPLS domain [4]. It uses 2 levels
of LSP tunneling. The outer or base level is the hop by hop LSP
tunnels that interconnect all VPN Border (Label Switch) Routers
(VBR’s). The "bottom of label stack", nested level provides
logically single hop tunnels between VBR’s. For each IP VPN,
single hop nested tunnels are established between all VBR's
serving that particular VPN. The draft outlines the components
involved in the MPLS IP VPN architecture and outlines how they
interact. The proposed realization is caste in terms of the VPN
areas introduced in [1] and is geared to take advantage of a
virtual router (VR) capability in the VBR's. This results in a
powerful and flexible method of providing an IP VPN service that
meets the requirements outlined in [3]. Also described are two
extensions: offering MPLS VPN service to the customer (rather
than IP service) and using Label Switching to traverse VPN
areas[1].
Casey, et al. [Page 1]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
Table of Contents
1. Introduction 3
1.1 IP VPN 3
1.2 VPN Areas 3
1.3 VPN Border Routers - VBR's 3
1.4 Virtual Routers - VR's 3
1.5 MPLS based IP VPN's 4
1.6 Terminology 4
2. Architectural Overview 5
2.1 Components 5
2.1.1Enterprises, VPN-ID's and Enterprise Sites 5
2.1.2Stub Links 6
2.1.3VBRs and VR's 6
2.1.4Base Network and interior LSR's 7
2.2 Operation 7
2.2.1Establishing VPN Areas 7
2.2.2Establishing a new VPN 8
2.2.3Learning Site Reachability Information: 8
2.2.4VPN member dissemination: 8
2.2.5Nested Tunnel Mesh Establishment 9
2.2.6Intra VPN reachability 9
2.2.7IP Packet Forwarding 9
3 Details 9
3.1 VPN membership discovery 9
3.1.1Label space for nested labels 11
3.2 Detailed VBR Forwarding Behavior 11
3.3 A note on QoS and diff-serv 11
4 Extending the scope of MPLS. 11
4.1 Extending MPLS into the enterprise site networks. 11
4.2 Using MPLS between two or more MPLS VPN areas 12
5 Properties of the proposed scheme 12
5.1 IP VPN attributes 13
5.1.1A Routed IP service 13
5.1.2Data privacy 13
5.1.3Address Isolation 13
5.2 Other properties 13
5.2.1Separation of state 13
5.2.2Automatic configuration of VPN's. 14
5.2.3Exploits IP's Resilience 14
5.2.4Shared Bandwidth between Enterprises 14
5.2.5Engineerable to Enterprise Requirements 15
5.2.6Tracks MPLS Improvements 15
5.3 Scaling Factors 15
5.3.1Label Space Considerations 15
5.3.2VPN membership dissemination 16
6. Security Considerations 16
6.1 User Data Privacy 16
6.2 Service Provider Security 17
7. Intellectual Property Considerations 17
8. References 18
9. Authors' Addresses 18
Casey, et al. [Page 2]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
1.Introduction
1.1 IP VPN
In [3] Heinanen, Glesson and Lin provide a definition of an IP
VPN, or VPRN (Virtual Private Routed Network), and summarize its
properties: address isolation, data privacy and intra VPN
routing. In this context, an IP VPN is provided by a service
provider as a service offering to enterprises. The IP
specificity of an IP VPN arises because the service offered
includes IP routing. (Since the underlying network technology
described here is Multi-Protocol Label Switching, schemes
similar to that proposed here could be used to offer other of
routed protocol VPNs, e.g. an IPX VPN service). [3] also
describes the procedures needed for an IP VPN to operate and
provides examples of the multiple implementation options that
exist for each procedure.
1.2 VPN Areas
In a companion Internet Draft to this one [1], the IP VPN
architecture of [3] is extended by the introduction of VPN
areas. A VPN area is a partition of the service provider's
network resources used for providing IP VPN service. A prime
goal of VPN areas is to allow an IP VPN Service Provider to
partition his base network based upon administrative domains,
and/or network technology, and/or IP VPN implementation choices.
The reader may consult [1] for the rationale and properties of
VPN areas, but for the purposes of this draft, he or she can
equate a VPN area with an MPLS domain [4].
1.3 VPN Border Routers - VBR's
All proposals for IP VPN's distinguish the first IP device in
the path between the enterprise's network and the provider's
shared network. Unfortunately, there is no common term for it.
In this Internet Draft we use the term VPN Border Router or VBR.
VBR's are located at the edge of VPN areas: they serve as tunnel
ingress and egress points for enterprise IP traffic. (In multi-
VPN area networks they also serve as the gateway device between
VPN areas. For more details see [1].)
1.4 Virtual Routers - VR's
A VBR may be dedicated to a single enterprise or it may be
shared over many enterprises. In the latter case, it has to
maintain separate forwarding tables for each VPN it serves,
since their IP address spaces may not be distinct. If the
reachability information needed to populate these forwarding
tables is configured and exchanged on a per VPN basis then we
say that the VBR supports Virtual Routers. (Virtual Routers are
Casey, et al. [Page 3]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
described further in [1] and [7]). In this Internet Draft we
assume that each VBR supports a Virtual Router (VR) per VPN that
it serves. However, in fact there would be few changes if
reachability information were acquired by other methods, such as
[2].
1.5 MPLS based IP VPN's
This Internet Draft describes an implementation for a VPN Area
that coincides with an MPLS domain (see [4]). If the entire
Service Provider network is a single MPLS domain then the
implementation provides the entire IP VPN service.
Mechanisms to implement IP VPN service over MPLS networks have
been proposed in [2], [6] and [7]. There are significant
differences between all of these proposals. This proposal is
closest to [7] in that is makes the use of Virtual Routers
explicit (which [6] supported but did not describe). It differs
from [7] in that it does not require IP multicast support in the
service provider's base network. Rather this proposal exploits
the tunnel mesh formed in an MPLS area by the topology driven
implicit LSP set-up. This proposal uses just the functionality
of MPLS that will be available in early deployments. Unlike [6]
it does not require explicit LSP set-up.
The MPLS architecture [3] and its Label Distribution Protocol
[5], when combined with architectural constructs described in
this document, provide a very flexible and powerful basis for
building IP Virtual Private Networks
1.6 Terminology
In addition to the MPLS related terminology of [4] the following
terms are introduced
Base label A label used by the base network as part of a
hop by hop LSP.
Base network The provider's IP/MPLS network
LDP Label Distribution Protocol [4]
LSP Label Switched Path [4]
LSR Label Switching Router [4]
MPLS Domain A set of MPLS enabled nodes that are contiguous
at the outermost label stack level. (A
clarification of the definition in [4])
Casey, et al. [Page 4]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
Nested label Label pushed onto label stack first, to identify
nested LSP tunnel link.
Nested LSP tunnel A LSP in which the links between nodes are
hops are themselves base network LSP's. The
label for a nested LSP tunnel link is pushed
onto the label stack before the base label.
Peer label A nested label used to identify the single
logical hop between peer VR's
Peer VR's VR's that serve the same IP VPN within the same
VPN area.
Stub link Dedicated IP link between a VBR and an
enterprise site
VBR VPN Border (Label Switched) Router
VR Virtual Router
VPN Area A partition of the base network, upon which IP
VPN service is offered. Within a VPN Area the
various VPN mechanisms (tunnelling, VPN
membership discovery etc.) are the same.
2.Architectural Overview
2.1 Components
The key elements of the MPLS based VPN architecture proposed in
this draft are shown in Figure 1.
+----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+
|EntR|----|VBR|---|LSR|--|LSR|---|VBR|---|LSR|---|VBR|----|EntR|
+----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+
Enter- <--------VPN Area-------> <---VPN Area----> Enter-
Prise <-----MPLS Domain-----> <--MPLS Domain--> prise
Figure 1: IP VPN Path over 2 VPN Areas
2.1.1 Enterprises, VPN-ID's and Enterprise Sites
The purpose of an IP VPN is to carry IP traffic between
geographically dispersed sites of an enterprise.
An enterprise that wants IP VPN service is first assigned a VPN-
ID by the service provider. The VPN-ID as an identifier that is
Casey, et al. [Page 5]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
unique within the carrier or group of carriers offering IP VPN
service. (Strictly speaking for this proposal, a VPN-ID needs
only be unique within a VPN area. However, we propose that a 16
bit VPN-ID be used that is unique within an AS. Prepending the
AS number will then give a 32 bit globally unique VPN-ID,
suitable for cross provider administrative purposes).
2.1.2 Stub Links
All but the smallest of sites will interface to the provider's
network from an enterprise router (EntR in figure 1) over a stub
link. (Very small sites might not have an enterprise router,
instead they might consist of a single LAN subnet, e,g an
Ethernet, served directly from a VBR). Enterprise sites are
connected to VBR's by dedicated stub links. The links may be
logical (e.g. a Frame Relay VC) or physical, but they carry only
traffic of the particular enterprise. The service offered on
stub links is routed IP. There will be agreement between
enterprise and provider on such factors as the routing protocol
for each stub link. Since the VBR will participating in a
routing exchange with enterprise routers it must have an IP
address compatible with the enterprise's IP address space.
An Enterprise may wish to use the same link for its traffic to
and from the Internet or some extranet(s). This is most securely
done by using different Layer 2 connections or tunnels, but a
VBR might be able to separate out non-VPN traffic based upon its
destination address. The handling of such traffic is outside the
scope of this draft.
Some larger Enterprise sites may be "not so stubby". They may
have multiple links, from the same or different enterprise
routers, to the same VBR or to different VBR's. There might be
direct links between enterprise sites outside of the VPN.
2.1.3 VBRs and VR's
VBR's are located at the edge of VPN areas. In this proposal
they are edge LSR's: they serve as tunnel ingress and egress
points for enterprise IP traffic crossing the provider's shared
network. In multi VPN area networks, they also serve as the
gateway device between VPN areas.
We say that a VBR serves a particular VPN if it terminates one
or more stub links to enterprise sites of that VPN. A gateway
VBR that straddles two or more VPN areas serves a particular VPN
if it forwards traffic for that VPN between the areas. With a VR
implementation there is one VR realization on a VBR for each VPN
that VBR serves. Each VR in effect terminates all the stub links
of one enterprise.
Casey, et al. [Page 6]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
A VBR may serve just one VPN, in which case it has just one VR
(but since it is a LSR, it is also running a router
instantiation in the provider's IP address space and routing
regime). The more interesting case is when a VBR serves a large
number of VPN's and consequently has a large number of VR
realizations.
2.1.4 Base Network and interior LSR's
The base network is the provider's underlying network that is
shared amongst enterprises' IP VPN service. Here the base
network is an MPLS network. The VBR's are MPLS edge nodes. In
general, they will be connected to interior Label Switch Routers
(LSR's). In this proposal the interior LSR's have no knowledge
of the VPN service. They do not see native packets of the
enterprises; all VPN traffic is tunneled through them.
2.2 Operation
2.2.1 Establishing VPN Areas
A carrier, or consortium of carriers, (the Provider) wishing to
offer IP VPN service has first to configure one or more MPLS
domains. Each MPLS domain becomes a VPN area. The VPN area
consists of VBR's around the edge and plain (non-edge) LSR's,
interconnected by links. The interfaces to the links each have
assigned to them an IP address from the provider's IP address
space. In particular a VBR has an IP address in the Provider's
IP address space. This address is not directly visible within
any of the IP VPN's that the VBR will support.
The provider determined routing regime determines routes within
the MPLS domain and then, as per normal MPLS operation, LDP is
invoked to establish implicit LSP's across the MPLS domain. The
result is a full mesh of LSP's between all edge LSR's (which
includes all VBR's). I.e. in each VBR's the is a Forwarding
Equivalence Class (FEC) to next hop label map [4] that has an
entry in it for every other VBR for the first hop of an LSP to
that VBR. This defines the base tunnel mesh.
We call these first hop labels in the FEC map base labels. They
will be used as the top of stack labels for all inter VBR
traffic. Base labels will be swapped at each LSR on the path to
the destination VBR. (Since there are going to be two labels on
the MPLS packets in this scheme, the somewhat confusing
terminology of [4] would have base labels called level 2 labels
- the LSP's that form the base tunnel mesh between VBR's would
be called level 2 LSP's).
Casey, et al. [Page 7]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
2.2.2 Establishing a new VPN
The IP VPN Provider selects VBR's that will serve the new VPN
and configures a VR at each one with the VP-ID. The provider
then provisions stub links between VR's and one or more routers
at each enterprise site. The stub link interfaces are assigned
IP addresses from the enterprise's IP address space. (Note that
in fact, if the provider has a globally unique subnet address
range, he can reuse it within every IP VPN. It will not overlap
with the enterprise IP address space whether the enterprise is
using its own globally unique address space, or is using private
addresses, 10.x.x.x etc).
If the IP VPN to be established spans multiple VPN areas the
provider must enable VR's in some of the gateway VBR's that
straddle the relevant VPN areas. These VR's will participate in
the following steps in all the VPN areas that they have been
configured to operate in.
2.2.3 Learning Site Reachability Information:
Heinanen et al. in [3] suggest a number of mechanisms for the
VBR to learn the set of address prefixes that are reachable over
the stub link to an Enterprise site. Using a VR to exchange
routing information with one or more enterprise site routers is
the most general mechanism. Part of the stub link configuration
is to specify what routing protocol runs over it, between the
Enterprise Router and the VBR. Of course, for genuine stub
enterprise sites the degenerate routing regime is default
routing at the enterprise router and static routing at the VR
towards the enterprise site.
2.2.4 VPN member dissemination:
Concurrent with a VR learning the IP address prefixes of the
enterprise sites it is directly connected to, the VR needs to
find its peer VR's. It has to discover which other VBR's in the
VPN area serve its VPN. Although [3] suggests a number of
mechanisms for this step, the one proposed here is unique to
MPLS. Basically, the VR offers to establish a direct LDP session
with every other VBR in the VPN area. But only VR's serving the
same VPN will discover each other, and go on to establish pair-
wise LDP sessions with each other. LDP sessions will only be
successfully established between (the VR's in) VBR's that are
supporting the same VPN's.
A more complete description of this step is given in Section
3.1.
Casey, et al. [Page 8]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
2.2.5 Nested Tunnel Mesh Establishment
With every VR having an LDP session with every other VR of the
same VPN, the stage is set to establish MPLS single hop nested
tunnels between all the VR's, forming a private tunnel mesh.
Each VR offers a single label to its peer (the upstream VR) for
it to use when forwarding traffic to it. The peer VR will store
this in a forwarding table as the nested label (i.e. the first
label to be pushed on the label stack) for the destination VR).
2.2.6 Intra VPN reachability
The first traffic that will flow over the nested tunnels is the
exchange of routing information between VR's. We assume that
when a VR is first configured for an IP VPN, part of the
configuration information is the routing protocol that it should
use "intra VPN". It would also be given any security credentials
that it needs in order to participate as a neighbour router to
the other VR's. After any discovery phase of the "intra VPN"
routing regime, each VR will be advertising the enterprise
address prefixes reachable through it.
2.2.7 IP Packet Forwarding
As a result of routing exchanges between peer VR's and between
VR's and enterprise routers, as appropriate, each VR will build
a forwarding table that relates enterprise address prefixes
(forward equivalency classes) to next hop. The next hop could be
stored as the IP addresses of the end points the nested LSP
tunnel to be used, or it could just be the tunnel labels (both
levels). When IP packets arrive whose next hop is a VBR, the
forwarding process pushes first the label for the peer VR (the
nested tunnel label). Then the base label, for the first hop of
the base network LSP that leads to the VBR, is pushed onto the
packet. The doubly labeled packet is then forwarded to the next
LSR in the base network LSP.
When the packet arrives at the destination VBR the outermost
label may have changed several times but the nested label has
not changed. As the label stack is popped, the nested label is
used to direct the packet to the correct VR.
3 Details
3.1 VPN membership discovery
This section examines more closely the VPN membership discovery
process: the way that each VR discovers all other VR's in the
VPN area that are serving the same IP VPN.
The entire process is enabled by the fact that each VBR has a
set of labels for LSP's that lead to all other VBR's in the VPN
Casey, et al. [Page 9]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
area. This is the result of the basic MPLS implicit LSP
construction process. We call this resulting mesh of MPLS hop-by-
hop LSP's the base network tunnel mesh. An advantage of using
MPLS is that the mesh of LSP's is self-healing in the event of
interior, base network, topology changes. There is no route re-
calculations performed by the VR's.
Note that if the MPLS base network is used for traffic other
than IP VPN's then some method of flagging VBR IP addresses from
other FEC's is needed. A suggested method is that an unique
address prefix be assigned to the VPN area and addresses from it
only be used for VBR interfaces. Other methods are for further
study.
The LDP session initiation process [5] is used as the method of
VR's discovering their peers, since the ultimate intent of the
scheme is to establish a second level of MPLS tunnels. Every VR
sends an LDP hello message down every base network LSP that
exits its VBR. Hello messages (and any subsequent session
messages) are encapsulated with the base MPLS label so that they
are carried all the way to destination VBR. The LDP hello
message is a form of query to determine if a VR for the same VPN
(a peer) resides at the destination VBR. The VPN-ID (16 bits) is
carried in the header of the LDP link hello as the <label space
id> field [5]. A receiving VBR will only register an LDP hello
adjacency if the <label space id> is one that it supports i.e.
if it has a VR for the same VPN-ID.
When a hello adjacency is registered, the relevant VR proceeds
to initiate an LDP session with its peer. One of the two VR's
will initiate a TCP connection to the other based upon the rules
of [5]. The IP source and destination addresses used here are
the base network IP addresses of the respective VBR's. After the
TCP connection is in place, and the necessary initiation
messages have been exchanged, then an LDP session between the
peer VR's exists. Immediately the LDP session is established the
two VR's each offer the other a label for a LSP tunnel to
itself. As far as the VR's are concerned, this LSP tunnel is a
single hop to its peer. We call the labels the peer labels. The
LSP tunnel is a nested tunnel in our terminology (it is a level
1 tunnel in the somewhat confusing terminology of [4]), its
label is pushed onto a packets label stack before the base
network LSP label.
The peer labels may be the only ones that are exchanged between
VR's particularly if there is only one MPLS VPN area in the
provider's network. Section 4.2 describes how label switching
can be used between adjacent MPLS VPN areas, and, in that case,
the LDP session between peer VR's would be used to offer a
larger number of labels. Even in single VPN areas there may be
extra labels exchanged for LSP's of different QoS, particularly
if the base labels do not have a ToS field in them (e.g. ATM).
Casey, et al. [Page 10]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
3.1.1 Label space for nested labels
At a VBR, the nested label space used by each VPN has to be
disjoint from all other VPN's supported by the same VBR. It is
suggested that the peer label include the VPN-ID (16 bits) as a
simple way to ensure this.
However the nested labels can usually be "platform wide",
meaning that the same label can be used for all peer labels
issued by a particular VR. A simple label allocation scheme
would see the VPN-ID used as the peer label for all of the
nested tunnels of a particular VPN. (This rule may not hold for
certain uses of ATM, see [8] and section 5.3.1. - in this case
distinct peer labels are needed for every peer VR).
3.2 Detailed VBR Forwarding Behavior
To be provided in a future draft.
3.3 A note on QoS and diff-serv
As noted in [7], one of the advantages of VR's is that multiple
tunnels may exist between them. This supports both an ability
for the service provider to engineer specific traffic guarantees
and a degree of resilience. In the context of MPLS explict LSP's
may provided between specified VR's serving manufacturing sites
to support mission critical applications, while most corporate
sites are served by the default, best effort MPLS LSP's. The
multiple tunnels can be priority ordered so that, for example,
if the explicit LSP fails the traffic will go over the default
LSP (which gets it path automatically restored following the
base network routing topology update). However, if the LSR's in
the MPLS domain are diff-serv enabled, then there may not be a need
for multiple paths, each supporting a different classes of QoS.
In this case, the VR's in a VBR have to transfer the DS byte on
incoming packets into the ToS field of the outer MPLS header.
4 Extending the scope of MPLS.
So far in this Internet draft we have considered that a VPN area
coincides with an MPLS domain. This section addresses two
extensions of MPLS scope that are possible.
4.1 Extending MPLS into the enterprise site networks.
There are two scenarios in using MPLS over stub links. The first
is when the enterprise site is using MPLS tunnels to separate
traffic travelling on the same physical link but destined for
different VPN's (or the Internet). This is a straightforward
local use of MPLS, akin to separating traffic using frame relay
Casey, et al. [Page 11]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
or ATM. The MPLS tunnel is terminated at the VBR.
The second scenario is far more interesting: it involves a
change of VPN service definition. Rather than the service
offered being routed IP, the service offered is MPLS. We can no
longer talk about an IP VPN but must use the term MPLS VPN. In
an MPLS VPN the VPN is an MPLS domain dedicated to the
enterprise. There can be an arbitrary number of LSR's at the
enterprise sites. These will form LSP's through the VBR's of the
provider's network. This scenario is for further study.
4.2 Using MPLS between two or more MPLS VPN areas
As so far described, VR's in gateway VBR's forward packets
between adjacent VPN areas at the IP level, that is the
forwarding decision is based upon the enterprise IP address
fields in the packet. When the adjacent VPN areas are MPLS
domains, it could be more efficient to label switch between the
VPN areas.
While more details will be forthcoming in a future version of
this document, supporting label switching between VPN areas is
relatively straightforward. When the VR's run a full routing
protocol between each other, the total intra VPN space can be
considered as a (nested) MPLS domain. The routing protocol
produces a forwarding topology, the nested tunnel links are the
links connecting VR's, the LDP sessions between VR's are
established as described above. Hence, it is an entirely
standard process to build a (nested) mesh of multi-hop LSP's
between edge VBR's, based upon the topology discovered by the
intra VPN routing. In general, the nested LSP from an ingress VR
(located in an edge VBR) will traverse through a sequence of
VR's in gateway VBR's and terminate at a VR in an edge VBR. A VR
in a gateway VBR will have a label swap map to define how it
changes the incoming nested label of a packet from one VPN area
into a label appropriate for the destination VPN area.
5 Properties of the proposed scheme
The scheme proposed here uses MPLS as it is likely first going
to be deployed. In particular, it only requires the implicit LSP
establishment process, and the supporting LDP definition. It
does not assume the existence of an explicit routed LSP
capability with a matching signaling protocol.
Section 5.1 outlines briefly how the scheme proposed here meets
the attributes of an IP VPN as outlined by Heinenan et al [3].
Section 5.2 describes a number of benefits the solution
provides. Section 5.3 addresses the particular scalability
properties of the proposal.
Casey, et al. [Page 12]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
5.1 IP VPN attributes
5.1.1 A Routed IP service
The provider provides routed IP service within its own network.
Specifically customer packets are routed at VR's within the
provider's network. Reachability information is exchanged
between enterprise sites and VBR's.
5.1.2 Data privacy
In the provider's network all enterprise data is carried on
dedicated stub links and on dedicated (nested) LSP tunnels.
Provided that stub links are correctly provisioned to VR's there
can be no mixing of traffic between enterprises or on and off
the Internet.
5.1.3 Address Isolation
Using VR's in VBR's ensures that enterprises have complete
freedom in choice of IP addressing schemes.
5.2 Other properties
5.2.1 Separation of state
Using two levels of routing regime, one for the base network and
one at the VR level, separates the provider's IP network from
the enterprise networks. Enterprise routers do not communicate
any routing information with the provider's internal LSR's. the
internal LSR's do not maintain any kind of state information
related to VPN's.
Topology changes (route flapping) in an enterprise network are
transparent to the provider's base network. Thus, if the
provider is just running IP VPN's over its MPLS network, its
network is protected from many kinds of damage, deliberate or
accidental, that can occur in shared IP networks.
Many changes in carrier network topology will be transparent to
enterprise networks. When routes change in the provider's
network, new base LSP's are automatically created to maintain
the base network's intra VBR mesh, so that VPN routes are
entirely unchanged. Since no VR sees any routing change the
topology update processing load on a VBR is restricted to base
network: it does not increase with the number of VR's supported.
The use of VR's also ensures state separation between all of the
customer enterprises. VPN's do not share fate, for more details
see [1].
Casey, et al. [Page 13]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
5.2.2 Automatic configuration of VPN's.
The use of LDP as a VPN membership discovery mechanism solves a
large problem that would otherwise inhibit deployment of large
VPN's and large numbers of VPN's. The administrative procedures
needed to install a new VPN, or add or remove an enterprise site
to a IP VPN, are reduced to the absolute minimum. Only the VBR
that is serving the enterprise site needs to be updated with new
configuration information. Provisioning scales linearly with
this scheme while many other VPN implementations require
intervention at all existing edges in the VPN (an "n squared"
task).
The use of VR's enables the exchange of enterprise routing
information between enterprise sites and the provider network to
be dynamic. This property eases network management and removes
the need for static routing, requiring operator intervention.
Note that as described in this Internet Draft, the automatic
configuration of a VPN is confined to a single VPN area. For a
VPN that spans multiple VPN areas, VR's at some gateway VBR's
have to be initiated administratively. This is because we
believe that the Gateway VBR's between VPN areas should serve as
policy and traffic engineering points, see [1]. However, an LDP
based mechanism does exist that would obviate the administrative
initiation of VR's that straddle MPLS VPN areas, if this were
desired.
5.2.3 Exploits IP's Resilience
Using MPLS as the base network retains the advantages of IP in
the handling of failed links or routers. Hop by hop implicit
routed tunnel LSP's (but not explicit routed tunnel LSP's)
exploit the well-established IP routing mechanisms to
automatically reroute around failures. This scheme provides
automatic recovery, with low processing overheads(see 5.2.1),
resulting in better end to end availability. VPN's based upon
layer 2 Virtual Connections (or explicit routed LSP's) do not
have this property.
5.2.4 Shared Bandwidth between Enterprises
One of the attractions of an IP network is that its bandwidth is
statistically shared amongst all users, reducing the costs to
all users of basic IP transport. Using MPLS as the base network
retains this advantage for IP VPN's. A basic IP VPN service can
be offered where the providers network bandwidth is shared, best-
effort, between all enterprises. As diff-serv is deployed,
aggregate traffic class resources can also be shared between
enterprises, based upon their subscriptions to each class.
Casey, et al. [Page 14]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
5.2.5 Engineerable to Enterprise Requirements
The administrative load of both best-effort and diff-serv
service is very light. However just having access to a shared
pool of resources may not meet all of an enterprise's needs. The
scheme proposed here does not preclude an administrator from
provisioning explicit links (with a defined Q.O.S) between
particular VR's (and VR's and enterprise sites) for particular
IP VPN's. The explicit links may be explicit routed tunnel
LSP's or, indeed, could be off a different technology such as an
ATM Virtual connection. The shared bandwidth pool LSP mesh
enhances this solution by proving an alternate route for the
enterprise routers and VR's to choose should the explicit link fail.
The traffic engineering control, alluded to above, deriving from
the assignment of VPN's to Gateway VBR's is described further in [1].
5.2.6 Tracks MPLS Improvements
As mentioned above, the scheme proposed here uses MPLS as it is
likely first going to be deployed. It will also automatically
incorporate any improvements in MPLS hop by hop routing that
come along. Currently MPLS is not able to load share traffic
over multiple equivalent links, but it is anticipated that such
an improvement in forwarding behavior will come. Similarly,
advances in IP routing and forwarding to be Q.O.S aware will add
to the functionality of the proposed VPN realization.
5.3 Scaling Factors
The general good scaling behavior of VPN areas and VR's is
discussed in [1]. It has also been noted above (sec 5.2.2) how
the nested use of LDP provides a scalable solution to the
challenge of VPN configuration. Scaling benefits of the use of
two levels of MPLS labels was alluded to in section 5.2.1. There
is no VPN related state information kept at interior LSR's.
Since VPN's are isolated from base network topology changes, no
per VPN, or per VR, routing re-computations are required when an
interior link fails. This section discusses 2 more scaling
aspects of the scheme proposed here.
5.3.1 Label Space Considerations
The approach of using two levels of MPLS tunnels, and hence 2
levels of label space, was also driven by considerations of
supporting a large number of VPN's, 10,000 or more. Another
assumption that the number of of VBR's in a VPN area was modest
number, say 100 or less, since more VBR's could be supported by
constructing extra VPN areas. The modest size of VPN areas
ensures that there are no label space depletion issues in
Casey, et al. [Page 15]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
establishing the base network tunnel mesh, even for legacy link
technologies such as Frame Relay and ATM. Assuming label
merging, the most base network labels needed on a link is the
total number of VBR's in the VPN area (or a small multiple thereoff,
to allow for different QoS levels being assigned to different LSP's).
While some IP VPN's will serve a 100 or more enterprise sites,
it is anticipated that the average number of enterprise sites
will be around 5. If 10,000 VPN's were all realized in one VPN
area, these would give an average of 500 VR's per VBR. The
nested label space size needed at the typical VBR would then be
around 500 labels when, as noted in section 3.1.1, the same
label can be used by all peers. Note that, when the base network
is an ATM network without VC-merge, when base labels are VPI's
and are merged, and when the VCI field is being used as the
nested label (see [8]), then the nested labels must be distinct.
The number of such labels required would be around 2,500.
5.3.2 VPN membership dissemination
The automatic discovery of VPN members by having each VR send an
LDP hello message to every VBR may result in a lot of messages.
Using the figures from above, every VBR in a VPN area would
receive approximately 500 small UDP packets every time a failed
VBR came back on line. Most of these packets would be of no use
to it and would be immediately discarded.
If the load on VBR's this introduces was thought to be
significant, a modified hello could be devised that offered
multiple label spaces (i.e. VPN ID's) in a single UDP packet.
This would to provide a significant reduction in traffic.
The load on a recovering VBR of sending approximately 50,000
hello messages is not insignificant. MPLS support for multicast
would help here. Alternatively the LDP hello messages could be
multicast on the base network, but, if core LSR's are going to
ignore them, the multicast address used would have to be a new
one - an all VBR's multicast address.
6.Security Considerations
One of the major functions of a VPN is to provide both data
privacy and addressing privacy for multiple customers over a
shared network infrastructure. At the same time the provider of
the shared network infrastructure need assurance that it can not
be compromised by a customer, to the detriment of the provider
or other customers.
6.1 User Data Privacy
A Service Provider may choose to deploy VBR's, each with a
single VR, at a customer's enterprise premise, or they may
deploy VBR's with multiple VR's at a Service Provider location.
Casey, et al. [Page 16]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
In both cases, the only traffic that will enter a customers
premise is that of the customer's VPN. This is ensured by the
isolation of VR's within a VBR (i.e. no traffic passes between
them) and the use of tunnels dedicated to single VPN's.
There is a threat from an intruder setting up a fake VBR and
persuading genuine VR's to send it traffic. This is little
different from threats today from hackers setting up routers
that advertise false routes. Solutions involve having network
nodes only exchange information with other network nodes that
are part of a chain of trust. VBR to VBR and/or VR to VR
authentication must be part of a full solution. VR to VR
authentication should be performed using the authentication
mechanisms of the selected "intra VPN" routing regime.
As provided here, there is no confidentiality of enterprise data
from the Service Provider. I.e. enterprise data is kept separate
from other enterprises and is not readily available to hackers,
but the provider the Service Provider has full access to the
content of packets. An Enterprise that wants to assure total
confidentiality of its data must encrypt it. End to end
encryption will ensure total confidentiality over the entire
enterprise intranet. If the enterprise is not worried about
internal threats, but perceives the service provider as a
threat, then encryption should be performed on all traffic
crossing the WAN interface (i.e. before it reaches the providers
VBR).
6.2 Service Provider Security
Keeping user traffic in tunnels is the best way to ensure the
service provider's network is not compromised. While the VR's
participating in a particular IP VPN share IP address space with
the customer, the customer has no visibility of the IP addresses
used in the Service Providers base IP/MPLS network. The service
provider's network is transparent to users. Even if a hacker
within an Enterprise knows the address of a router inside a
service provider's network, the router can't be reached: packets
will either be forwarded to an enterprise node which happens to
have the same address, or dropped, because the VR's don't have
forwarding entries for it.
The VR mechanism can actually provide extra security for service
providers whose base network is part of the Internet. Service
providers can configure an IP VPN for their own operational use.
Covering all of their nodes, this VPN isolates all of the
service provider's legitimate management traffic from general
user traffic.
7.Intellectual Property Considerations
Casey, et al. [Page 17]
Internet Draft draft-casey-mpls-vpn-00.txt November 1998
Nortel 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 Nortel, Nortel
intends to disclose those patents and license them on reasonable
and non-discriminatory terms.
8.References
[1] Casey, "An extended IP VPN Architecture" <draft-casey-vpn-
extns-00.txt> Oct 1998.
[2] Heinanen et al., "VPN support with MPLS", <draft-heinanen-
mpls-vpn-01.txt>, March 1998.
[3] Heinanen et al., "MPLS Mappings of Generic VPN Mechanisms",
<draft-heinanen-generic-vpn-mpls-00.txt>, Aug 1998.
[4] Rosen et al., "Multiprotocol Label Switching Architecture",
<draft-ietf-mpls-arch-01.txt>, March 1998.
[5] Anderson et al., "Label Distribution Protocol", <draft-mpls-
ldp-00.txt>, March 1998.
[6] Jamieson et al., "MPLS VPN Architecture", <draft-jamieson-
mpls-vpn-00.txt>, Aug 1998
[7] Muthukrishnan and Malis, "Core IP VPN Architecture", <draft-
muthukrishnan-corevpn-arch-00.txt>, Oct 1998.
[8] Davie et al., "Use of Label Switching With ATM", <draft-
davie-mpls-atm-01.txt>, July 1998
9.Authors' Addresses
Liam Casey
Nortel Networks
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: liam@nortel.com
Ian Cunningham
Nortel Networks
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: ian_cunningham@nortel.com
Robert Eros
Nortel Networks
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: reros@nortel.com
Casey, et al. [Page 18]