Decoupled Virtual Private LAN Services
draft-kompella-ppvpn-dtls-03

Versions: 00 01 02 03                                                   
PPVPN Working Group                             K. Kompella    (Juniper)
Internet Draft                                  J. Achirica (Telefonica)
Expiration Date: April 2002                     L. Andersson    (Utfors)
                                                M. Lasserre (Riverstone)
                                                P. Lin           (Yipes)
                                                P. Menezes    (Terabeam)
                                                A. Moranganti   (Appian)
                                                H. Ould-Brahim  (Nortel)
                                                S. Yeong-il  (Korea Tel)

                   Decoupled Transparent LAN Services

                    draft-kompella-ppvpn-dtls-00.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
















K. Kompella (editor)       Expires April 2002                   [Page 1]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


2. Abstract

   Transparent LAN Service (TLS) is a useful Service Provider offering.
   A common scenario where this offering is made is in the metro area,
   where several Multi-Tenant buildings are connected to an Office, and
   several Offices are connected by a metro area network.  The Service
   Provider places a simple, low-cost box (MTU) in each building; these
   MTUs have uplinks to some box (PE) in one or more Offices.  In such a
   scenario, it is useful to decouple the functions needed to offer TLS
   across the MTU and PE; this document proposes one way of
   accomplishing that.


3. Introduction

   Transparent LAN Service (TLS) is a useful Service Provider offering.
   A Transparent LAN appears in (almost) all respects as a LAN to the
   Service Provider customer; "transparent" is used in the sense of
   "transparent" bridging.  However, in a TLS, the customers are not all
   connected to a single LAN; the customers may be spread across a metro
   or wide area.  In essence, a TLS glues several individual LANs across
   a metro area to appear and function as a single LAN.

   A common scenario where TLS is offered is in the metro area, where
   several Multi-Tenant buildings are connected to an Office, and
   several Offices are connected by a metro area network, for example, a
   SONET ring.  The Service Provider places a simple, low-cost box (MTU)
   in each building.  A typical MTU has 10-100 Ethernet ports that
   connect to customers (we call these the "customer-facing ports"), and
   one or more uplinks to a Service Provider aggregation box (PE) (we
   call these the "WAN" links, although they may either metro area or
   wide area links).  The customer hand-off is thus an Ethernet; the MTU
   acts as a metro/wide area bridge connecting the LAN at a customer
   site to other MTUs that are connected to other LANs belonging to the
   same customer.

   In such a scenario, it is useful to decouple the functions needed to
   offer TLS across the MTU and PE.  These functions comprise learning
   MAC addresses, including learning across the metro area from other
   MTUs; building a spanning tree, both on the LAN side and on the metro
   side; and discovering other MTUs connected to a given customer.  This
   document suggests that the former two functions (layer 2 functions)
   be run on the MTU, and that the last function (layer 3) be run on the
   PE.  In addition, there needs to be some information exchange between
   the PE and its MTUs.  This document does not suggest that decoupling
   is appropriate for all scenarios.

   The spanning tree algorithm is useful in the case that an MTU is



K. Kompella (editor)       Expires April 2002                   [Page 2]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   connected to more than one PE which can reach a destination MTU.
   This gives the MTU a means to choosing one of the PEs as the primary
   means of reaching the destination MTU, while preserving the others as
   backup paths.  Alternative means of accomplishing this objective may
   be possible, and indeed, preferable, and are not ruled out by this
   document.


3.1. Motivation for Decoupling

   We consider three ways of splitting the TLS functions across the MTU
   and PE: run all TLS functions on the MTU; run all TLS functions on
   the PE; or run learning and spanning tree on the MTU, and discovery
   on the PE, and some information exchange between them.  In this
   subsection, we examine the repercussions of each.


3.1.1. Function Compatibility

   In this document, we assume that an MTU is a simple, low-cost layer 2
   device, usually based on a bridge.  That implies that an MTU is
   designed to learn MAC addresses, and to run a spanning tree
   algorithm.  An MTU does not usually run complex layer 3 protocols, in
   particular, BGP, which is the de facto VPN discovery protocol.

   On the other hand, a PE device is a more complex layer 3 device.
   Besides being connected to MTUs and offering TLS, a PE may offer
   several other services.  For example, a PE may be directly connected
   to customers through WAN circuits to offer various VPN services,
   and/or public Internet access; and a PE may take part in peering
   sessions.  This requires the PE to be capable of VPN discovery, and
   to run BGP, so it is natural for a PE to do TLS discovery.


3.1.2. Scalability

   Let's posit the following hypothetical numbers to get a feel for the
   scaling requirements.  The numbers are just orders of magnitude;
   there is no claim that these are realistic, or supported by market
   data.

      # of end hosts per TLS           100-1000
      # of TLS's per MTU                10-100
      # of MTUs per PE                  10-100
      # of PEs in a metro area          10-100

   Armed with these, let's examine the effect of running each of the TLS
   functions at an MTU vs. at the PE.



K. Kompella (editor)       Expires April 2002                   [Page 3]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   The number of MAC addresses that would need to be learned by an MTU
   ranges from 1000 to 100,000.  The number that would need to be
   learned by a PE ranges from 10,000 to 10,000,000.

   A spanning tree may need to be built for each TLS.  If so, the number
   of spanning trees that would need to be built by an MTU ranges from
   10 to a 100.  The number of spanning trees that would need to be
   built by a PE ranges from 100 to 10,000.

   The number of "discovery peers" (i.e., BGP peers if BGP is the
   discovery protocol) for an MTU doing discovery ranges from 100 to
   10,000.  The number of peers for a PE doing discovery ranges from 10
   to 100.  (Note that the number of peers can be mitigated using
   techniques similar to those recommended for RFC 2547-style VPNs
   [IPVPN, IPVPNbis], e.g., partitioned route-reflector topologies.)


3.1.3. Configuration

   Both the fact that the MTU is a simple, low-cost box, and that there
   are one to two orders of magnitude more MTUs than PEs suggest that
   the PE is more suitable as the place where TLS should be configured.
   If all TLS functions are run on the PE, this is automatically
   satisfied.  If all TLS functions are run on the MTU, this is
   difficult to achieve.  This document shows how this can be achieved
   in the case that the TLS functions are distributed across the MTU and
   PE.


4. Functional Requirements

   This section presents the functional requirements of MTUs and PEs in
   order to participate in a decoupled TLS.


4.1. Requirements on the MTU

   An MTU must be able to function as a transparent learning bridge, as
   it might well be connected to traditional bridges on customer-facing
   ports.  Thus, it must be able to learn MAC addresses and run the
   spanning tree algorithm and flood packets when necessary.  An MTU
   must also be able to run the modified learning and spanning tree
   algorithms described below, as well as the modified flooding.

   In addition, an MTU must be able to send and receive labeled packets.
   This labeling could either be MPLS labels, or VLAN tagging.  In the
   latter case, the VLAN tag could either be the first tag, or a stacked
   tag; unfortunately, there is no standard yet for VLAN stacking.  It



K. Kompella (editor)       Expires April 2002                   [Page 4]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   is absolutely necessary that the VLAN tag that is added is assigned
   by the Service Provider, and is independent of customer tags.  More
   details on the use of VLAN tags between an MTU and a PE will be
   forthcoming in a future version of this document.

   For MPLS labeling, an MTU must be able to take an Ethernet frame from
   a customer-facing port, verify the CRC, strip the Ethernet preamble
   and CRC, and encapsulate the remaining Layer 2 frame as an MPLS
   packet with the appropriate label stack and send it to a PE.  On the
   receiving side, the MTU must be able to receive a labeled packet from
   a PE, and based on the label decide which TLS the enclosed Ethernet
   frame belongs to; if necessary, learn the origin of the source MAC
   address (as described in the section on modified learning); remove
   the MPLS encapsulation and label; and generate a CRC and send the
   packet on the appropriate customer-facing port.  Furthermore, the MTU
   must be able to distinguish from which PE it received the labeled
   packet, i.e., it must support per-interface labels, for reasons
   described below.

   Also, an MTU should have some means to be provisioned and to monitor
   its operation.  This requires some form of access to the MTU; for
   example, if the provisioning and monitoring is to be done via SNMP,
   the MTU would have to be IP-addressable, and to support SNMP
   functions.

   Finally, an MTU must run the MTU-PE protocol described below, and to
   carry out the actions required by the protocol.

   In order to accomplish the above, the MTU may maintain in some form a
   mapping from (learned) MAC addresses to customer ports (for
   traditional learning), and a mapping from MAC addresses to received
   labels (for the modified learning); these mappings constitute the
   MTU's MAC address cache.  Ideally, the MTU should maintain a separate
   MAC address cache for each TLS it is part of, although in principle
   MAC addresses being globally unique, this should not be necessary.
   Also, the MTU must have a (configured) mapping from a customer port
   to a TLS, and for convenience, a mapping from a TLS to a list of
   customer ports.


4.2. Requirements on the PE

   A PE must have the Layer 2 VPN functionality described in [L2VPN],
   with the modifications described below.  This requires that a PE be
   able to run BGP; MPLS: i.e., send and receive labeled packets, and
   swap, push and pop labels; and that a PE have some form of tunnels to
   every other PE taking part in any TLS in which this PE is
   participating.



K. Kompella (editor)       Expires April 2002                   [Page 5]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   A PE must also support the configuration of TLSs, and be able to run
   the MTU-PE protocol described below.


5. PE Operation

   This section describes how a PE running a decoupled TLS operates,
   that is, how the TLS is configured, how members are discovered, how
   the PE forwards packets in a TLS.

   The discovery mechanism used here is a variant of the Layer 2 VPN
   discovery [L2VPN].  Familiarity with that document is a prerequisite
   to understanding the operation of decoupled TLSs as described here.


5.1. Configuration

   We first list the configuration information that MTUs and PEs need,
   then we suggest a means of configuring this information.

   As we said earlier, an MTU has several Ethernet ports that connect to
   customers, and some uplinks to PEs.  The MTU needs to be told which
   of its customer-facing ports belong in which TLS.  More precisely,
   the MTU needs to be told which TLSs it is a member of, and which PEs
   it is connected to.  For each <PE, TLS> pair, the MTU must be told
   what its "site ID" is for that <PE, TLS>.  Finally, for each TLS, the
   MTU must be given the list of its <physical port, VLAN>s that belong
   to the TLS.

   A PE needs to be told which MTUs it is connected to (and over which
   link), and which TLSs each such MTU participates in.

   The minimum information that a PE must be configured with is the
   following:

      <<MTU ID (router ID)>
       <connecting interface>
       <<TLS ID> <MTU site ID>
       <<TLS ID> <MTU site ID>
       ...
      >

   That is, the PE is given the MTU ID (as an IP address), the interface
   over which it is connected to the MTU, and a list of TLSs that that
   MTU participates in.  For each TLS in this list, the PE is given the
   TLS ID, the MTU's site ID in this TLS.  A TLS ID is an 8 octet Route
   Distinguisher; a site ID is a two octet integer (see [L2VPN] for
   details).



K. Kompella (editor)       Expires April 2002                   [Page 6]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   If it is desired that all TLS configuration be done at the PE, here
   is how this can be accomplished.  The PE is configured with the
   following information for each MTU to which it is connected:

      <<MTU ID (router ID)>
       <connecting interface>
       <<TLS ID> <MTU site ID>
        <<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
       <<TLS ID> <MTU site ID>
        <<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
       ...
      >

   That is, in addition to the above, the PE is given, for each MTU and
   each TLS that the MTU participates in, a list of customer facing port
   IDs and corresponding VLAN tags that belong to that TLS.  An MTU port
   ID is a two octet integer; a VLAN tag is a two octet (12 bit) 802.1q
   tag.

   The PE then transfers all information relevant to an MTU to that MTU
   using the MTU-PE protocol described later.  The PE transfers all
   information relevant to other PEs running TLS to them using a
   mechanism similar to [L2VPN], described below.


5.2. Generated Information

   A PE given the above configuration generates label ranges as in
   [L2VPN] consisting of a label base, an offset and a size.  It is
   expected that for a TLS, a single, contiguous label range with offset
   0 would suffice; if not, a number of non-overlapping label ranges can
   be used, as described in [L2VPN].  Call these label ranges the WAN
   label ranges for the <MTU, TLS> pair.

   For the same <MTU, TLS> pair, the PE must generate a second set of
   label ranges called the MTU label ranges.  Each MTU label range for
   an <MTU, TLS> pair corresponds exactly to one of the WAN label ranges
   for the <MTU, TLS>; in fact, the only difference is the label base.

   All WAN label ranges generated by a given PE must be non-overlapping;
   similarly, all MTU label ranges generated by a given PE must be non-
   overlapping.  It is possible that some WAN label range and some MTU
   label range overlap; this depends on factors outside the scope of
   this document (such as whether per-interface or per-box labels are
   being used).  An implementation may of course choose to ensure that
   PE WAN labels and MTU labels are always non-overlapping.





K. Kompella (editor)       Expires April 2002                   [Page 7]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


5.2.1. Multipoint Uplinks

   If the PE-MTU link is a multipoint link (such as Ethernet), and there
   are multiple PEs on this link, there is the possibility that the MTU
   label ranges from the PEs overlap.  In this case, some mechanism is
   needed to resolve the overlap.

   One solution is that PEs that are connected to MTUs over a multipoint
   link multicast their messages to the MTUs, say to the ALL-ROUTERS
   multicast address.  If PE y hears that PE x is using a certain label
   range, it remembers that, and ensures that future label ranges that
   it sends to an MTU don't overlap.  If two PEs send overlapping label
   ranges simultaneously, the PE with the lower router ID wins the
   contention, and the other PE withdraws its label range and issues a
   non-overlapping range.  Details will be forthcoming.

   Other solutions may also be possible.


5.3. TLS Discovery

   The mechanism used for TLS member discovery is that in [L2VPN], with
   the following changes: there is a new code-point for encapsulations
   for Decoupled TLS; and the "routes" that are installed are different
   (described next).  Furthermore, it is anticipated that there is no
   need for topology information, as TLSs are fully meshed.  For
   simplicity, it is assumed that a single label range with offset 0 is
   used for both WAN and MTU label ranges for a given <MTU, TLS> pair.

   Say MTU U is attached to PE X, and that MTU U participates in TLS T.
   Suppose MTU U' attached to PE X' also participates in TLS T.  Suppose
   further that the site ID for MTU U in TLS T is p, and the site ID for
   MTU U' is p'.  Suppose finally that there is a tunnel W from PE X to
   PE X' and a reverse tunnel W' from PE X' to PE X.

   PE X announces a WAN label range to all other PEs with label base K,
   offset 0, and length k (k >= p, p') for <MTU U, TLS T>.  According to
   [L2VPN], this tells PE X' to use label (K+p') to send packets from
   MTU U' to MTU U.  PE X' announces a WAN label range to all other PEs
   with label base K', offset 0, and length k' (k' >= p, p') for <MTU
   U', TLS T>.  This tells PE X to use label (K'+p) to send packets from
   MTU U to MTU U'.

   PE X also sends an MTU label range to MTU U with label base A, offset
   0, and length k for TLS T.  This tells MTU U to use label (A+p') to
   send to the MTU with site ID p' (i.e., MTU U'); and also that packets
   received with label (A+p') belong to TLS T, and were originated at
   the MTU with site ID p'.  Similarly, PE X' sends an MTU label range



K. Kompella (editor)       Expires April 2002                   [Page 8]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   to MTU U' with label base A', offset 0, and length k' for TLS T.

   PE X installs "MTU routes" and "WAN routes".  We describe the MTU
   route for packets from MTU U to MTU U': for labeled packets arriving
   from MTU U, swap incoming label (A+p') with (K'+p), then put the
   packet in tunnel W to PE X'.  The WAN route is for packets from MTU
   U' to MTU U, and is as follows: for packets arriving on tunnel W'
   from PE X', remove the packets from the tunnel (if needed), then swap
   incoming label (K+p') with label (A+p').

   To complete the path from MTU U to MTU U', the WAN route installed by
   PE X' is described.  For packets arriving on tunnel W from PE X,
   remove the packets from the tunnel (if needed), then swap incoming
   label (K'+p) with (A'+p).

   Figure 1 below depicts this scenario: MTU U connected to PE X and MTU
   U' connected to PE X'.  It further depicts MTU U dual homed to PE Z,
   and another MTU V dual homed to the same PE, PE Y.  For each PE, it
   shows the WAN label range announced to other PEs, as well as the MTU
   label range sent to its MTU.  Note that a dual homed MTU MUST be
   given distinct site IDs for each uplink, whether to the same PE or
   different PEs; and that a PE must allocate and announce WAN and MTU
   label ranges for each MTU that it is connected, even if it is the
   same MTU over different links (such as PE Y and MTU V).


   Figure 1

       {A,0,k} <- +-------+       W  ->      +-------+ -> {A',0,k'}
      ============| PE X  |<****************>| PE X' |=======[MTU U']
      |           +-------+       W' <-      +-------+
      |  announces {K,0,k} \                /  announces {K',0,k'}
      | for MTU U, site ID p\              /   for MTU U', site ID p'
      |                      ..............
   [MTU U]                   .    core    .
      |                      ..............   announces {L,0,l} for
      | announces {M,0,m}   /              \ MTU V, site ID q
      | MTU U, site ID r   /      announces \        -> {B,0,l}
      |           +-------+       {L',0,l'}  +-------+=======[     ]
      ============| PE Z  |       for MTU V, | PE Y  |       [MTU V]
       {C,0,m} <- +-------+       site ID q' +-------+=======[     ]
                                                      -> {B',0,l'}









K. Kompella (editor)       Expires April 2002                   [Page 9]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


5.4. Packet Forwarding

   All TLS packets from/to the MTU to/from its PE are sent as labeled
   packets: the entire Ethernet frame (minus preamble and checksum) is
   encapsulated in an MPLS frame with a single label.  This label
   encodes both the TLS to which the packet belongs, as well as the
   source (for packets received) or destination (for packets sent).

   TLS packets from PE to PE are sent as a single label MPLS packet in a
   PE-PE tunnel.  Thus, the packet may be an MPLS packet with a two or
   more label stack; or it may be MPLS in a GRE or IPSec tunnel, etc.

   Say an endpoint "behind" MTU U decides to send a TLS T packet to some
   endpoint "behind" MTU U'.  All MTU U knows about MTU U' is that its
   site ID is p', i.e., to send packets to MTU U', MTU U must use label
   (A+p') (how it arrives at this is described in the section on
   learning).  The MTU route at PE X states that the label (A+p') is
   swapped with (K'+p), and the packet is put in tunnel W to PE X'.
   When PE X' gets the packet, it removes the packet from the tunnel,
   and sees label (K'+p).  PE X' swaps the label with (A'+p) per its MTU
   route, and sends this packet to MTU U'.  Seeing label (A'+p), MTU U'
   knows that the packet is a TLS T packet which originated at MTU U
   (i.e., the MTU with site ID p).


6. MTU Operation

   This section describes the information that an MTU gets from its PE,
   and how learning and spanning tree computations are done in a TLS.

   Modified flooding and learning in the case that the MTU-PE labeling
   is done using VLANs is entirely analogous, and will be detailed in a
   future version of this document.


6.1. MTU-PE Information Exchange

   The PE sends the following information to attached MTUs:

      <<PE ID (router ID)> <MTU ID (router ID)>
       <<TLS ID> <MTU site ID>
        <<MTU label range> <MTU label range> ...>
        <<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
       <<TLS ID> <MTU site ID>
        <<MTU label range> <MTU label range> ...>
        <<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
       ...
      >



K. Kompella (editor)       Expires April 2002                  [Page 10]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   That is, the PE sends its own ID, the MTU's ID (for sanity checking),
   and a list of TLS IDs.  For each TLS, the PE tells the MTU its site
   ID in the TLS, a list of MTU label ranges, and a list of customer
   ports in the TLS.  (The last list is for the MTU's private
   consumption, and is optional.)  An MTU label range consists of a
   label base, a site ID offset, the number of sites in the range, and a
   bit vector of currently active sites.  The length of the bit vector
   in octets is (number of sites in the range)/8.

   The exact format of this information, and the protocol that is used
   to transfer this information, as well as a list of status codes sent
   by the MTU in response will be specified in greater detail in a later
   version.


6.2. Modified Flooding

   Flooding is used for example when an MTU wants to send a packet, but
   doesn't have the packet destination MAC address in its MAC address
   cache; or when the destination MAC address is a broadcast or
   multicast address.  Such a packet may be received either from a
   customer port, or from a PE.  The MTU must first identify to which
   TLS the packet belongs.  It must then flood this packet, i.e., send a
   copy of the packet out on multiple ports.  If the packet is received
   on a customer port, the MTU must send a copy out on every other
   customer port in the TLS, as well as to every other MTU participating
   in the TLS.  If the packet is received from a PE, then the packet
   must be sent on every customer port; if the TLS is a full mesh, the
   packet need not be sent to any other PE/MTU.  If the TLS is not a
   full mesh, the MTU must be told to which other PE/MTUs it needs to
   flood the packet.

   If an MTU wants to flood a TLS packet to all other MTUs in the TLS,
   the MTU sends a copy of the packet with each label in the MTU label
   ranges for that TLS (except of course the label corresponding to the
   MTU itself) and sends it to the PE.  If an MTU has multiple
   connections to PEs (the same or different), it MUST flood to each PE
   over each available connection.


6.3. Modified Learning

   When MTU x receives a packet from one of its PEs, it matches the
   incoming label with all the MTU label ranges received from the
   sending PE.  (Note: MTU label ranges sent by a PE to an MTU MUST be
   non-overlapping.  However, an MTU label range sent by one PE MAY
   overlap with an MTU label range sent by another PE.  An MTU MUST be
   able to identify the interface over which a packet arrived, and use



K. Kompella (editor)       Expires April 2002                  [Page 11]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   that information to disambiguate incoming labels.)

   The incoming label tells MTU x which TLS this packet belongs to, and
   which MTU it originated at (say x').  If the source MAC address S of
   the packet is not in the MAC address cache of MTU x, MTU x "learns" S
   by remembering the site ID of MTU x' (or more simply, by associating
   S with the incoming label L).  If at some future point, MTU x wants
   to send a packet to destination MAC address S, it looks up its cache,
   sees that S maps to label L, pushes label L and sends it to its PE.


6.4. Modified Spanning Tree

   An MTU x will receive multiple copies of a flooded packet with a
   given source MAC address S from MTU y if either MTU x or MTU y (or
   both) is multiply connected to PEs; each copy of the packet will be
   received with a distinct <incoming interface, MTU label> pair.  In
   that case, MTU x must choose which <outgoing interface, MTU label>
   pair it will use to get to MAC address S.  This situation corresponds
   exactly to there being multiple ports connecting two bridges.  If the
   TLS is fully meshed, MTU x can choose on its own which <interface,
   label> to use to send packets to MAC address S; i.e., MTUs need not
   run a spanning tree algorithm across the metro or wide area which may
   be a distinct benefit.

   If a TLS is not fully meshed, each MTU in the TLS may treat multiple
   incoming MTU labels for a given MAC address as multiple parallel
   ports to the same "bridge" (i.e., remote MTU) and use the spanning
   tree algorithm to pick the active port (i.e., label) to use to reach
   the MAC address.

   Finally, MTU may use an IGP (or configuration) to decide which of the
   multiple incoming MTU labels to use to map a given source MAC
   address.


6.5. Load Balancing

   If an MTU is multi-homed (i.e., it has multiple uplinks to one or
   more PEs), it may decide to load balance across those links.  This
   decision can be made locally by the MTU.  The main consideration is
   to make sure that packets to the same destination use the same path
   to avoid packet re-ordering.  This can be tricky, as broadcast or
   multicast packets may go to the same destination.  A reasonable
   approach is to use the same uplink for all packets in a given TLS,
   but to use different uplinks for different TLSs, thus achieving some
   degree of load balancing.




K. Kompella (editor)       Expires April 2002                  [Page 12]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


7. Security Considerations

   The security aspects of this solution will be discussed at a later
   time.


8. IANA Considerations

   (To be filled in in a later revision.)


9. Acknowledgments

   Many thanks to Brian Brown, Ian Hood, Vasile Radaoca and the Juniper
   "ethernet geeks", from whose stimulating discussions this idea was
   born; and to Yakov Rekhter whose probing questions helped clarify and
   refine the details.


10. References

   [IPVPN] Rosen, E., and Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
   1999.

   [IPVPNbis] Rosen, E., et al, "BGP/MPLS VPNs", work in progress.

   [L2VPN] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in
   progress.


11. Intellectual Property Considerations

   Juniper Networks 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 Juniper Networks,
   Juniper intends to disclose those patents and license them on
   reasonable and non-discriminatory terms.













K. Kompella (editor)       Expires April 2002                  [Page 13]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


12. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


13. Author Information

   Yeong-il,Seo
   Korea Telecom
   Telecommunication Network Laboratory
   Member of Technical Staff
   463-1 Junmin-dong, Yusung-gu, Taejeon, Korea
   Tel : +82-42-870-8333 / FAX : +82-42-870-8339
   Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr

   Hamid Ould-Brahim
   Nortel Networks
   P O Box 3511 Station C
   Ottawa ON K1Y 4H7 Canada
   Phone: +1 (613) 765 3418
   Email: hbrahim@nortelnetworks.com

   Ashwin Moranganti
   Appian Communications



K. Kompella (editor)       Expires April 2002                  [Page 14]


Internet Draft      draft-kompella-ppvpn-dtls-00.txt        October 2001


   email: amoranganti@appiancom.com
   phone: 978 206-7248

   Pascal Menezes
   Terabeam Networks, Inc.
   14833 NE 87th St.
   Redmond, WA, USA
   phone: (206) 686-2001
   email: Pascal.Menezes@Terabeam.com

   Pierre Lin
   Yipes Communications, Inc.
   114 Sansome St.
   San Francisco CA 94104
   email: pierre.lin@yipes.com

   Marc Lasserre
   Riverstone Networks
   5200 Great America Parkway
   Santa Clara CA 95054
   marc@riverstonenet.com

   Loa Andersson
   Utfors AB
   Box 525, 169 29 Solna
   Sweden
   phone: +46 8 5270 5038
   email: loa.andersson@utfors.se

   Javier Achirica
   Telefonica Data
   javier.achirica@telefonica-data.com

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   kireeti@juniper.net













K. Kompella (editor)       Expires April 2002                  [Page 15]