[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/