MPLS Working Group D. Jamieson
Internet Draft B. Jamoussi
Expiration Date: January 1999 G. Wright
P. Beaubien
Nortel (Northern Telecom) Ltd.
August 1998
MPLS VPN Architecture
<draft-jamieson-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 Internet Draft defines an architectural model for building
Virtual Private Networks (VPNs) in an MPLS domain. The proposed model
takes advantage of both network layer peering and packet switching,
and link layer circuits and per-stream switching. The model provides
a set of simple mechanisms for controlling VPN membership, including
registration, propagation, discovery, and dynamic creation of Label
Switch Paths to provide connectivity.
The architectural constructs described in this document, when
combined with the MPLS architecture [1], provide a flexible and
scaleable basis for building VPNs.
Table of Contents
1 Introduction ............................................ 2
2 Architectural Overview .................................. 3
2.1 Building Blocks ......................................... 3
Jamieson, et. al. August 7, 1998 [Page 1]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
2.2 MPLS-VPN Architecture Summary ........................... 5
2.3 Emulated LAN Model ...................................... 7
2.4 Elements of a LAN Model ................................. 7
2.5 Other Models ............................................ 8
3 Architectural Details ................................... 8
3.1 Registration of VPN and VPN subnet Information on a PEL . 8
3.2 Distribution of VPN Information ......................... 9
3.2.1 Static Provisioning ..................................... 10
3.2.2 OSPF Opaque LSAs Option ................................. 10
3.2.3 TCP Connection/BGP Options .............................. 10
3.2.4 Withdrawal of VPN Subnet Information .................... 10
3.3 Establishment of VPN Subnet LSPs ........................ 10
3.3.1 Creation of Unicast LSPs ................................ 10
3.4 Creation of Multicast LSPs .............................. 11
3.5 Layer 3 Modeling of VSI ................................. 12
3.6 Layer 3 to Layer 2 Address Mapping ...................... 13
3.7 PNL Routing & Forwarding ................................ 13
4 Extending MPLS into the VPN Member Network .............. 13
5 Summary ................................................. 14
6 Security Considerations ................................. 14
6.1 User Data Privacy and User Address Privacy .............. 14
6.2 Service Provider Security ............................... 14
7 Intellectual Property Considerations .................... 14
8 Acknowledgement ......................................... 14
9 References .............................................. 15
10 Authors' Addresses ...................................... 15
1. Introduction
Virtual Private Networks (VPNs) enable private restricted
communications of distinct, closed networks over a common shared
network infrastructure. Supporting VPNs with MPLS or other
connectionless and connection-oriented layers requires three basic
functions.
- Discovery of VPN members.
It is assumed that VPN members connect to a provider network and
those members need to find out what other members there are in the
VPN. Members may join and leave the service network and those
changes need to be known by all remaining members. Mechanisms to
support discovery include manual configuration, client-server
approaches, and notification provided by the provider network
(i.e., auto-discovery). The discovery of membership in one VPN
must not allow members of other VPNs to be discovered. That is,
discovery within a VPN is kept separate from discovery in another
VPN in the same provider network.
Jamieson, et. al. August 7, 1998 [Page 2]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
- Exchanging reachability and control traffic between VPN members.
Members in the same VPN need to exchange reachability information
about their network layer addresses. These addresses may be in a
different space from the provider network and may in fact overlap
with other VPN address spaces. Control traffic could include
topology information specific to that VPN. As with the discovery
mechanism, the exchange of reachability and control traffic must
be kept separate between VPNs sharing the same provider network.
- Carrying data traffic between VPN members.
This mechanism enables data traffic to be carried between users
within a VPN. Data traffic from different VPNs is kept separate.
In [2] the discovery mechanism involves local configuration (VPNid)
and then propagation in LDP, OSPF, or BGP. The reachability exchange
is also accomplished by LDP, OSPF, or BGP. Topology information is
not propagated between VPN member subnets over the MPLS network
providing the VPN service. Data traffic is carried on LSPs which are
created to connect all members of the same VPN.
This Internet-Draft proposes the use of OSPF, BGP-4, or TCP
connections for the discovery mechanism. Reachability and control
traffic (topology information) are exchanged over LSPs which are
setup between members in the same VPN. Data traffic is carried on
LSPs which are created to connect all members of the same VPN.
This internet draft is different from [2] and is proposed as an
alternative.
In Section 2, an architectural overview of building VPNs in an MPLS
domain is presented. Section 3 presents the details of the proposed
architecture. Extending MPLS into the VPN member network is
highlighted in Section 4. Section 5 summarizes the draft.
2. Architectural Overview
2.1 Building Blocks
The building blocks of the MPLS VPN architecture proposed in this
draft are shown in Figure 1 and described in this section.
Private Network LSR (PNL):
The PNL is a device that runs standards based layer 3 (OSPF, BGP,
RIP, static routes, etc.) protocols to distribute and calculate
reachability information for the private network. It also runs an
Jamieson, et. al. August 7, 1998 [Page 3]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
LDP [3] process for the purpose of establishing Label Switched
Paths (LSP) between itself and other members of the same VPN
connected over the provider network. The PNL may be a physical
device that resides in either the private or provider's premise.
It could also be a logical device embedded in some other device,
such as a Provider Edge LSR (PEL).
PNL PEL Core LSRs PEL PNL
+------+ SAL +----+ +--+ +--+ +----+ SAL +------+
| A |-------| |--| 1|--| 2|-----| |---------| B |
+------+ | Y | +--+ +--+ / | X | +------+
+----+ \ | / +----+
\ | /
\ | / +----+ SAL +------+
\ +--+ | |---------| C |
\| 3|----| Z | +------+
+--+ +----+ PNL
PEL
Figure 1. MPLS VPN Architecture
Provider Edge LSR (PEL):
The Provider Edge LSR (PEL) is an LSR in the provider domain. It
has one or more Shared Access Links (SALs) connecting it to one or
more PNLs. LDP peering is established over these SALs which is
used to setup end to end (PNL to PNL) LSPs.
PELs dynamically discover other PELs supporting the same VPN and
VPN subnets. LSPs are then established between those PELs to
transport VPN traffic.
Core LSR:
Core LSRs provide transport across the provider network. They run
a layer 3 protocol and MPLS. Core LSRs don't attach directly to
PNLs.
Shared Access Link (SAL):
The SAL is a IP capable physical or logical link that connects the
PNL to the PEL.
VPN Subnets:
A VPN subnet connects an IP subnet between 2 or more PNLs. A VPN
subnet is uniquely identified within the provider network by a VPN
Jamieson, et. al. August 7, 1998 [Page 4]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
Id, an IP address and prefix.
VPN Subnet Interface (VSI):
The IP interface on a PNL for an VPN subnet. A SAL supports 1 or
more VSIs.
The PNL device has a Shared Access Link (SAL) to a PEL. A VPN Subnet
Interface (VSI) is established over the SAL. The VSI is viewed as a
broadcast emulated LAN interface by the IP process running on the
PNL. IP routing information can be exchanged between all PNLs of the
same VPN subnet. The emulated LAN connectivity is achieved using a
set of LSPs.
2.2 MPLS-VPN Architecture Summary
- The provider network provides LSPs that are used by PNLs of the
same VPN subnet to exchange VPN routing information and to carry
datagrams across the provider network.
- The exchange of routing information across provider network is
dynamic. This property eases network management and removes the need
for static routing requiring operator intervention.
- No routing information is exchanged between PNLs and PELs. PNLs
form peering relationships across the provider network. Eliminating
the routing exchange between the PNL and the PEL provides several
benefits:
- Topology changes (route flapping) in the private network are
transparent to the provider network. Routing engines in the LSRs
inside the provider network are not affected by route flaps.
- Topology changes in provider network are transparent to private
network. When routes change in the provider network, new LSPs are
created to re-route the VPN traffic without involving the PNLs.
- Private routes are never mixed with provider routes. This
eliminates possible address conflicts between VPNs.
- The provider network emulates a LAN for each VPN subnet. A
particular PNL can send a unicast datagram to any other PNL in the
same VPN subnet, or multicast a datagram to all other PNLs in the VPN
subnet.
- The ELAN requires multicast capability. This functionality can be
accomplished three ways: multipoint-to-multipoint LSPs, a set of
Jamieson, et. al. August 7, 1998 [Page 5]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
point-to-multipoint LSPs, or by PNL copy and send broadcast over
existing unicast LSPs.
- Three types of LSPs are used to interconnect PNLs:
- Multipoint-to-point LSP.
Each PNL has a multipoint-to-point LSP directed to it. It is used
by all other PNLs within the VPN subnet for unicast sends.
- Multipoint-to-multipoint LSP (option 1).
All PNLs are also interconnected using a bi-directional
multipoint-to-multipoint LSP. It is used for sending multicast
datagrams. There is one such LSP per VPN subnet.
- Point-to-multipoint LSP (option 2).
If multipoint-to-multipoint LSPs are not supported by the
underlying infrastructure, then point-to-multipoint LSP going from
each PNL to all other PNL in a VPN subnet is necessary.
- LSP scaling within a SAL.
N is defined as the number of PNLs in a VPN subnet. Each PNL
therefore uses (assuming the single multipoint-to-point LSP
model):
- 1 label for the incoming unicast datagram traffic from all
other PNLs in the subnet,
- N-1 labels to send unicast datagrams to any other PNL in the
subnet,
- 1 label to send and receive multicast traffic on the subnet
using multicast option 1.
- N-1 labels to send and receive multicast traffic on the
subnet using multicast option 2.
- MAC addresses are represented as labels. For a particular PNL, say
PNL A, the MAC address of another PNL, say PNL B, is the label that
must be used by PNL A to send unicast datagrams to PNL B. Because
labels have local significance only, the MAC address used to reach a
particular PNL is usually different for different senders.
- Layer 2 to layer 3 address mapping is achieved through one of 2
methods; propagating the information from the PEL to the PNL or a
Jamieson, et. al. August 7, 1998 [Page 6]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
modified ARP procedure
- When the PNL is an LSR in its own right, label stacking can be used
to label-switch datagrams in that PNL (instead of doing layer-3
forwarding).
2.3 Emulated LAN Model
To provide maximum flexibility to the VPN members, the provider
network appears as a Local Area Network (LAN) to the various VPN
member sites as shown in Figure 2.
The MPLS architecture with architectural constructs described in this
document provide for a flexible model to construct an emulated LAN in
an efficient manner. There are several advantages to adopting an
emulated LAN model as explained in this section:
PNL |
+------+ | PNL
| A |-----------| +------+
+------+ |----| B |
| +------+
|
| +------+
Logical View of |----| C |
Provider Network ->| +------+
| PNL
Figure 2. Emulated LAN in an MPLS Domain
- The emulated LAN model provides IP address space conservation. IP
address pace conservation occurs two ways. First by eliminating the
double addressing requirement for IP tunneling and by decreasing the
subnet requirements for equivalent connectivity with current ATM or
FR services
- The emulated LAN model simplifies the configuration of the VPN
within the shared network. Adding or deleting a site from VPS only
requires a change only on the interface being added or deleted.
2.4 Elements of a LAN model
Each node is identified by a MAC address. A MAC address is equivalent
to a Label on a VSI port.
Each node on a LAN must be able to send a unicast packet to any other
node on the LAN. This unicast traffic would include both control and
Jamieson, et. al. August 7, 1998 [Page 7]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
user traffic between any two given PNLs.
Each node on a LAN must be able to transmit a single packet onto the
LAN and have it delivered to all other nodes on the LAN (multicast).
These packets are sent to a multicast MAC address. Multicast traffic
includes Hello packets, LSAs, ARP, etc.
2.5 Other models
This architecture does not rule out other models such as a star or
point to point model. The details of other models are left for
further study.
3. Architectural Details
This sections describes the following architectural components of the
proposal:
- The provisioning of an SAL and the registration of VPN and VPN
subnet information on a PEL
- The distribution of the VPN information across in the provider
network
- The establishment of VPN subnet LSPs based on learned VPN subnet
information
- The modeling of the VPN subnet LSPs into a LAN like broadcast media
on the PNL
3.1 Registration of VPN and VPN subnet information on a PEL
The first step in adding a new site to a VPN subnet is to establish
an SAL between the PEL and PNL. The SAL is the link over which LDP
runs between the PEL and PNL. Only one SAL needs to be provisioned
for all VPN subnets on a PNL, so if the SAL already existed this step
can be skipped.
Once the SAL has been provisioned on the PEL, a VPN Identifier is
assigned to the SAL. There is a one to one mapping between VPN Id and
SAL. Again, if the SAL was already provisioned then the VPN Id will
also have been provisioned.
The next step is to provision the VPN subnet information. This
requires an IP address and prefix. The IP address and prefix are the
same as the PNL's VSI to which this SAL is linked. The VPN Id
together with the IP address and prefix define the VPN Subnet. The IP
address itself defines an instance of the subnet. If the same PEL has
Jamieson, et. al. August 7, 1998 [Page 8]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
another SAL to another PNL that supports the same VPN Id and subnet
then the IP address distinguishes between the two instances.
A protocol could be used to dynamically learn the IP address and
prefix from the PNL. Because the learning of this information causes
the consumption of resources in the provider network, appropriate
control mechanism would have to be part of the protocol. The details
of such a protocol are left for further study.
Once all of the VPN subnet information has been provisioned or
learned on the PEL, LDP is triggered on the PEL to establish an LSP
for the VPN subnet that goes from the PEL to the PNL. This LSP does
not go any further at this point. It will be spliced onto a
multipoint to point LSP later after other PELs supporting the same
VPN subnet learn of the existence of this instance of the VPN subnet.
The successful establishment of this first LSP also signals to the
PEL that the PNL has provisioned the associated VSI port and that
port is enabled.
3.2 Distribution of VPN information
This section describes the distribution of the VPN subnet information
within the provider network.
All PELs in the network, at least those that have links to the same
VPN Subnet, must be made aware of the other PELs that support the
same VPN Subnet. This is required to establish LSPs across the
provider network for the VPN Subnet.
There are several ways to accomplish the distribution of the VPN
information:
- Static provisioning
- OSPF opaque LSAs;
- TCP connections;
- BGP-4
Regardless of the distribution mechanism, the information that is
distributed is the PEL provider IP address and a list of VPN records.
Each VPN record is a VPN Id followed by a list of IP address/prefix
pairs. This information is referred to as the VPN subnet information.
Other information that may be part of the VPN subnet information is a
QOS value and a status flag. The status flag would indicate if the
subnet is being added or withdrawn.
3.2.1 Static provisioning
Jamieson, et. al. August 7, 1998 [Page 9]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
Each PEL that has a connection to a VPN subnet can be provisioned
with VPN subnet information from other PELs that have a connection to
the same subnet.
3.2.2 OSPF Opaque LSAs Option
With opaque LSAs, the VPN subnet information is put into an opaque
LSA and flooded throughout the OSPF AS. This information is
delivered, reliably, to every other node via the normal LSA flooding
mechanisms. The amount of information distributed in a single LSA
(all, for a single VPN Id, for a single VPN subnet) is left for
further study.
3.2.3 TCP connections/BGP Options
The TCP connection option allows for a TCP connection to be
established between a PEL and all other PELs that support the same
set of VPN subnets. The VPN information would be transmitted
reliably across the TCP connections to the PEL peers. This option
would require that the IP address of each PEL peer be provisioned,
however, it provides an option that is independent of the layer 3
routing protocol(s) running in the provider network.
BGP-4, could also be modified to carry the VPN information. BGP-4
would require a new opaque update type in which it would carry the
VPN information.
3.2.4 Withdrawal of VPN subnet information.
If an instance of a VPN subnet on a PEL is operationally or
administratively disabled or deleted, the withdrawal of the VPN
subnet information is distributed through the provider network using
the same mechanism used to distribute new VPN subnet information. The
format of a withdrawal message is left for further study. The
withdrawal of an instance of VPN subnet information from a PEL will
cause the removal of the LSPs that go to that VPN subnet instance on
that PEL.
3.3 Establishment of VPN Subnet LSPs
VPN subnet LSPs are created when a PEL learns, via one of the
distribution mechanism described in 3.2, that it has a VPN subnet in
common with some other PEL in the provider network. Two types of LSPs
are created; unicast LSPs and multicast LSPs.
3.3.1 Creation of Unicast LSPs
When a PEL receives new VPN information, it determines if any LSPs
Jamieson, et. al. August 7, 1998 [Page 10]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
need to be established.
First, the PEL determines if it has any VPNs in common with the new
list. If so, it checks to see if it has any VPN subnets in common. If
there are, LSPs are triggered for each of the IP addresses that are
members of the subnets.
In Figure 3, the creation of LSPs is triggered when PEL X learns
that PEL Y supports a common VPN subnet.
Using the example below, an LSP will be established from PNL B to PEL
X. LDP then continues to establish the LSP from X to Y. At Y, the
LSP is spliced onto the LSP that was created when the VPN subnet for
PNL A was provisioned.
---------------------------------
| |
PNL | PEL Core LSRs PEL | PNL
+------+ | +----+ +--+ +--+ +----+ | +------+
| A |---| |<-| 1|--| 2|---| |-------| B |
+------+ | | Y | +--+ +--+ | X | | +------+
| +----+ ^ | /+----+ |
| \ | / |
| \ | \/ +----+ | +------+
| \ +--+ | |-------| C |
| \| 3|<--| Z | | +------+
| +--+ +----+ | PNL
| |
| Provider domain |
---------------------------------
Figure 3. Unicast LSP Setup
Downstream label allocation is used from the PELs (leafs of the
multi-point to point tree) to the PNL. Upstream on demand label
allocation is used by the PEL (root of the mpt-to-pt tree) and its
connected PNL.
The LSP that is created is a unidirectional LSP that carries data
from PNL B to PNL A. Within the provider network, the LSP can be
established along the best hop route or an explicitly provisioned
route. If during the establishment of a best hop LSP, another LSP is
encountered that goes to the same destination for the same VPN
subnet, the LSPs can be merged. For example, when Z tries to
establish an LSP to Y, an existing LSP to Y for the given VPN subnet
will be encountered on core router 3. The LSP will be merged at that
point.
Jamieson, et. al. August 7, 1998 [Page 11]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
3.5 Creation of Multicast LSPs
An emulated LAN must be able to multicast certain packets (Hellos,
Routing Updates) across the LAN. This draft describes three options
for providing this capability.
1> A single bi-directional multi-point to multi-point LSP
2> A set of unidirectional point to multi-point LSPs
3> No multicast LSP is established. VSI interface is responsible
for copying and sending multicast packets on all outgoing unicast
LSPs.
With option 1, when a PEL (e.g. X) learns of the existence of another
PEL (e.g. Y) which supports a VPN subnet which it supports, the
creation of both unicast and multicast LSPs are initiated. The
multicast LSP is a bi-directional LSP that can follow either the next
best hop route or an explicit route. If, during the creation of a
next best hop multicast LSP, an existing multicast LSP is encountered
for the same VPN, the LSP may be merged.
Even though a merge point is encountered during the creation of a
multi-point to multi-point LSP, LDP must continue through to the
destination PNL in case the multicast LSP requires a new branch to
reach the destination.
Option 2 is simply a less efficient version of option one, at least
in terms of label consumption. In this case a point to multi-point
LSP is established from each PNL to all other PNLs for the VPN
subnet. Again, they are established at the same time as the unicast
LSPs.
Option 3 is the least expensive in terms of label consumption and
most expensive in terms of bandwidth and PNL/PEL resources. When the
VSI media has a multicast packet to send it copies and sends the
packet on each outgoing label for the VSI.
Changes required to LDP to support multicast LSPs is left for further
study.
3.6 Layer 3 Modeling of VSI
For each VSI on a PNL there will be one multicast LSP, one incoming
LSP and N-1 outgoing LSPs where N is the number of PNLs in the VPN
subnet. The incoming label will be viewed by layer 3 as the MAC
address for the interface. The outgoing labels will be viewed as
Jamieson, et. al. August 7, 1998 [Page 12]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
destination MAC addresses for all of the peer routers on the VSI. The
multicast LSP will be viewed as the viewed as the multicast MAC
address.
3.7 Layer 3 to Layer 2 address mapping
Two methods of mapping layer 3 to layer 2 addresses for a VSI
interface are proposed. The first is the distribution of the layer 3
information learned on a PEL for a given VPN subnet into the PNL.
This information is injected into the ARP table on the PNL. The
second is a modified ARP protocol run between the PNLs on the VPN
subnet.
When a PEL learns VPN information from other PELs, it learns the VSI
IP addresses that belong to VPN subnets. The PEL then triggers LDP to
establish an LSP form the PNL to the PEL to reach that peer IP
address. Once the LSP is established, the mapping, IP address to
label is known. This information is then propagated into the PNL
where it can be injected into the ARP table. It may be possible to
use LDP on the PNL side to learn the mapping. The details of this
mechanism are left for further study.
The other option is to use a modified ARP that runs across the VPN
subnet. This would be similar to Inverse ARP in that when a new
outgoing MAC label is enabled an ARP request is sent across that
label. The receiver of the ARP request would put their own VSI IP
address in the ARP response packet and send the packet.
The local significance of labels and multipoint to point LSPs provide
an additional twist. The ARP response packet may need to be sent on
the multicast path. An ARP request has the sender's IP address in the
packet. If the receiver of an ARP request had already resolved the
mapping of the sender's IP address to MAC label, the response can be
sent on that unicast LSP, otherwise the response must be sent on the
multicast LSP.
3.8 PNL Routing and Forwarding
Once the mapping for next hop IP address to MAC label is established,
normal IP routing and forwarding can take place between the PNLs For
each destination IP address that a PNL can send to, its forwarding
table will contain an entry which contains the exit port, the next
hop IP address to which the packet is to be sent and the MAC
address/label for that next hop IP address.
4. Extending MPLS into the VPN Member's Network
The private network could run MPLS across the VPN by forming LDP
Jamieson, et. al. August 7, 1998 [Page 13]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
peers with other PNLs on the logical LAN and using a shim in the
packet header to identify MPLS flows.
5. Summary
This internet draft presents a VPN architecture over MPLS networks.
It addresses the three basic functions required to establish VPNs
over MPLS. Using an emulated LAN model for connectivity across the
provider network, simplifies the configuration and management
coordination effort between the service provider and the VPN.
6. Security Considerations
One of the major functions of VPN is being able to provide both data
privacy and addressing privacy for users [2]. The architecture
proposed in this draft comes with built-in security which is robust
under dynamic environment.
6.1 User Data Privacy and User Address Privacy
Both user data privacy and user address privacy are achieved by
assigning different VPN identifier to different VPN and building a
separate logical network for each VPN. These logical networks may
share the same physical connections. But as far as users are
concerned, they won't see each other at all. The exceptional case
will be one user participate in multiple VPNs. But that would be a
configuration issue.
6.2 Service Provider Security
Due to the emulated LAN model adopted in this architecture, each user
won't see the service provider's network at all. i.e. the service
provider's network is transparent to users. The latter case indicates
that users can even have the same address space as the service
provider's.
6.3 IP SEC
Since the original VPN IP addresses can be transported across the
provider network IP SEC functionality is not impacted. One benefit
provided by this mode is IP SEC can run in transport as opposed to
tunnel mode reducing bandwidth consumption across the provider
network.
7. Intellectual Property Considerations
Nortel may seek patent or other intellectual property protection for
some of all of the technologies disclosed in this document. If any
Jamieson, et. al. August 7, 1998 [Page 14]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
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. Acknowledgment
The authors would like to acknowledge the valuable review and
comments of Jerry Wu, Stephen Shew, Ian Duncan, and Scott Pegrum.
9. References
[1] Rosen et al, "Multiprotocol Label Switching Architecture",
draft-ietf-mpls-arch-01.txt, March 1998.
[2] J. Heinanen, et. al, "VPN support with MPLS", <draft-heinanen-
mpls-vpn-01.txt>, March 1998.
[3] Anderson, et. al., "Label Distribution Protocol", draft-mpls-
ldp-00.txt, March 1998.
10. Authors' Addresses
Dwight Jamieson
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: djamies@Nortel.ca
Bilel Jamoussi
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: jamoussi@Nortel.ca
Gregory Wright
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: gwright@Nortel.ca
Paul Beaubien
Nortel (Northern Telecom), Ltd.
Jamieson, et. al. August 7, 1998 [Page 15]
Internet Draft draft-jamieson-mpls-vpn-00.txt August 1998
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: beaubien@Nortel.ca
Jamieson, et. al. August 7, 1998 [Page 16]