[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-raggarwa-mpls-ldp-upstream) 00 01 02 03 04 05 06 07 08 09 10 RFC 6389

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Category: Standards Track
Expiration Date: August 2011
                                                           J. L. Le Roux
                                                          France Telecom

                                                       February 02, 2011


                 MPLS Upstream Label Assignment for LDP


                  draft-ietf-mpls-ldp-upstream-10.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Raggarwa & LeRoux                                               [Page 1]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



Abstract

   This document describes procedures for distributing upstream-assigned
   labels for Label Distribution Protocol (LDP). It also describes how
   these procedures can be used for avoiding branch Label Switching
   Router (LSR) traffic replication on a LAN for LDP point-to-multipoint
   (P2MP) Label Switched Paths (LSPs).




























Raggarwa & LeRoux                                               [Page 2]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


Table of Contents

 1          Specification of requirements  .........................   3
 2          Introduction  ..........................................   3
 3          LDP Upstream Label Assignment Capability  ..............   4
 4          Distributing Upstream-Assigned Labels in LDP  ..........   5
 4.1        Procedures  ............................................   5
 5          LDP Tunnel Identifier Exchange  ........................   6
 6          LDP Point-to-Multipoint LSPs on a LAN  .................  10
 7          IANA Considerations  ...................................  12
 7.1        LDP TLVs  ..............................................  12
 7.2        Interface Type Identifiers  ............................  12
 8          Security Considerations  ...............................  12
 9          Acknowledgements  ......................................  13
10          References  ............................................  13
10.1        Normative References  ..................................  13
10.2        Informative References  ................................  13
11          Author's Address  ......................................  14






1. Specification of requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2. Introduction

   This document describes procedures for distributing upstream-assigned
   labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036].
   These procedures follow the architecture for MPLS Upstream Label
   Assignment described in [RFC5331].

   This document describes extensions to LDP that a Label Switching
   Router (LSR) can use to advertise to its neighboring LSRs whether the
   LSR supports upstream label assignment.

   This document also describes extensions to LDP to distribute



Raggarwa & LeRoux                                               [Page 3]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   upstream-assigned labels.

   The usage of MPLS upstream label assignment using LDP for avoiding
   branch LSR traffic replication on a LAN for LDP point-to-multipoint
   (P2MP) Label Switched Paths (LSPs) [MLDP] is also described.


3. LDP Upstream Label Assignment Capability

   According to [RFC5331], upstream-assigned label bindings MUST NOT be
   used unless it is known that a downstream LSR supports them. This
   implies that there MUST be a mechanism to enable an LSR to advertise
   to its LDP neighbor LSR(s) its support of upstream-assigned labels.

   A new Capability Parameter, the LDP Upstream Label Assignment
   Capability, is introduced to allow an LDP peer to exchange with its
   peers, its support of upstream label assignment. This parameter
   follows the format and procedures for exchanging Capability
   Parameters defined in [RFC5561].

   Following is the format of the LDP Upstream Label Assignment
   Capability Parameter:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| Upstream Lbl Ass Cap(IANA)|      Length (= 1)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1| Reserved    |
      +-+-+-+-+-+-+-+-+


   If an LSR includes the Upstream Label Assignment Capability in LDP
   Initialization Messages it implies that the LSR is capable of both
   distributing upstream-assigned label bindings and receiving upstream-
   assigned label bindings. The reserved bits MUST be set to zero on
   transmission and ignored on receipt. The Upstream Label Assignment
   Capability Parameter MUST be carried only in LDP initialization
   messages and MUST be ignored if received in LDP Capability messages.












Raggarwa & LeRoux                                               [Page 4]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


4. Distributing Upstream-Assigned Labels in LDP

   An optional LDP TLV, Upstream-Assigned Label Request TLV, is
   introduced.  To request an upstream-assigned label an LDP peer MUST
   include this TLV in a Label Request message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0| Upstream Ass Lbl Req (TBD)|      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Reserved                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   An optional LDP TLV, Upstream-Assigned Label TLV is introduced to
   signal an upstream-assigned label. Upstream-Assigned Label TLVs are
   carried by the messages used to advertise, release and withdraw
   upstream assigned label mappings.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0| Upstream Ass Label (TBD)  |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Label                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Label field is a 20-bit label value as specified in [RFC3032]
   represented as a 20-bit number in a 4 octet field as specified in
   section 3.4.2.1 of RFC5036 [RFC5036].


4.1. Procedures

   Procedures for Label Mapping, Label Request, Label Abort, Label
   Withdraw and Label Release follow [RFC5036] other than the
   modifications pointed out in this section.

   A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a
   neighboring LSR if the neighboring LSR had not previously advertised
   the Upstream Label Assignment Capability in its LDP Initialization
   messages.  A LDP LSR MUST NOT send the Upstream Assigned Label
   Request TLV to a neighboring LSR if the neighboring LSR had not
   previously advertised the Upstream Label Assignment Capability in its
   LDP Initialization messages.



Raggarwa & LeRoux                                               [Page 5]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   As described in [RFC5331] the distribution of upstream-assigned
   labels is similar to either ordered LSP control or independent LSP
   control of the downstream assigned labels.

   When the label distributed in a Label Mapping message is an upstream-
   assigned label, the Upstream Assigned Label TLV MUST be included in
   the Label Mapping message. When an LSR receives a Label Mapping
   message with an Upstream Assigned Label TLV and it does not recognize
   the TLV, it MUST generate a Notification message with a status code
   of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is
   unable to process the upstream label, it MUST generate a Notification
   message with a status code of "No Label Resources". If the Label
   Mapping message was generated in response to a Label Request message,
   the Label Request message MUST contain an Upstream Assigned Label
   Request TLV. A LSR that generates an upstream assigned label request
   to a neighbor LSR, for a given FEC, MUST NOT send a downstream label
   mapping to the neighbor LSR for that FEC unless it withdraws the
   upstream-assigned label binding. Similarly if an LSR generates a
   downstream assigned label request to a neighbor LSR, for a given FEC,
   it MUST NOT send an upstream label mapping to that LSR for that FEC,
   unless it aborts the downstream assigned label request.

   The Upstream Assigned Label TLV may be optionally included in Label
   Withdraw and Label Release messages that withdraw/release a
   particular upstream assigned label binding.


5. LDP Tunnel Identifier Exchange

   As described in [RFC5331] an upstream LSR Ru MAY transmit an MPLS
   packet, the top label of which (L) is upstream-assigned, to a
   downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In
   this case the fact that L is upstream-assigned is determined by Rd by
   the tunnel on which the packet is received. There must be a mechanism
   for Ru to inform Rd that a particular tunnel from Ru to Rd will be
   used by Ru for transmitting MPLS packets with upstream-assigned MPLS
   labels.

   When LDP is used for upstream label assignment, the Interface ID TLV
   [RFC3472] is used for signaling the Tunnel Identifier.  If Ru uses an
   IP or MPLS tunnel to transmit MPLS packets with upstream assigned
   labels to Rd, Ru MUST include the Interface ID TLV in the Label
   Mapping messages along with the Upstream Assigned Label TLV.  The
   IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields
   in the Interface ID TLV SHOULD be set to 0 by the sender and ignored
   by the receiver. The Length field indicates the total length of the
   TLV, i.e., 4 + the length of the value field in octets.  A value
   field whose length is not a multiple of four MUST be zero-padded so



Raggarwa & LeRoux                                               [Page 6]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   that the TLV is four- octet aligned.

   Hence the IPv4 Interface ID TLV has the following format:


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|0|     Type (0x082d)         |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 IPv4 Next/Previous Hop Address (0)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Logical Interface ID (0)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Sub-TLVs                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The IPv6 Interface ID TLV has the following format:


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0|0|     Type (0x082e)         |             Length            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 IPv6 Next/Previous Hop Address (0)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Logical Interface ID (0)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Sub-TLVs                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   As shown in the above figures the Interface ID TLV carries sub-TLVs.
   Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP
   LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The
   sub-TLV value in the sub-TLV acts as the tunnel identifier.

   Following are the sub-TLVs that are introduced:

   1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
   the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875].

   Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4
   Interface ID TLV:





Raggarwa & LeRoux                                               [Page 7]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Type (0x1c)                |  16                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                       P2MP ID                                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  MUST be zero                 |      Tunnel ID                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                      Extended Tunnel ID                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6
   Interface ID TLV:


          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Type (0x1c)                |  28                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                       P2MP ID                                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  MUST be zero                 |      Tunnel ID                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                      Extended Tunnel ID                       |
         |                                                               |
         |                             .......                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an
   "inner" LDP P2MP LSP, the label for which is upstream assigned, over
   an "outer" RSVP-TE P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE
   P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn>  the binding of
   the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control
   plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP
   uses targeted LDP signaling messages

   2. LDP P2MP LSP TLV. Type = 29 (To be assigned by IANA). Value of the
   TLV is the LDP P2MP FEC as defined in [MLDP] and has to be set as per
   the procedures in [MLDP].  Here is the format of the LDP P2MP FEC as
   defined in [MLDP]:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Raggarwa & LeRoux                                               [Page 8]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


         |P2MP Type      |        Address Family         | Address Length|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ~                       Root Node Address                       ~
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    Opaque Length              |    Opaque Value ...           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
         ~                                                               ~
         |                                                               |
         |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Address Family MUST be set to IPv4, the Address Length MUST be
   set to 4 and the Root Node Address MUST be set to an IPv4 address
   when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV.
   The Address Family MUST be set to IPv6, the Address Length MUST be
   set to 16 and the Root Node Address MUST be set to an IPv6 address
   when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV.

   The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an
   "inner" LDP P2MP LSP, the label for which is upstream assigned, over
   an "outer" LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP
   IF_ID TLV allows Ru to signal to <Rd1...Rdn>  the binding of the
   inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane
   signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses
   targeted LDP signaling messages

   3. IP Multicast Tunnel TLV. Type = 30 (To be assigned by IANA) In
   this case the TLV value is a <Source Address, Multicast Group
   Address> tuple. Source Address is the IP address of the root of the
   tunnel i.e. Ru, and Multicast Group Address is the Multicast Group
   Address used by the tunnel. The addresses MUST be IPv4 addresses when
   the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV.
   The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV
   is included in the IPv6 Interface ID TLV.

   4. MPLS Context Label TLV. Type = 31 (To be assigned by IANA). In
   this case the TLV value is a <Source Address, MPLS Context Label>
   tuple. The Source Address belongs to Ru and the MPLS Context Label is
   an upstream assigned label, assigned by Ru. The Source Address MUST
   be set to an IPv4 address when the MPLS Context Label TLV is carried
   in the IPv4 Interface ID TLV. The Source Address MUST be set to an
   IPv6 address when the MPLS Context Label TLV is carried in the IPv6
   Interface ID TLV.  This allows Ru to tunnel an "inner" LDP P2MP LSP,
   the label of which is upstream assigned, over an "outer" one-hop MPLS
   LSP, where the outer one-hop LSP has the following property:




Raggarwa & LeRoux                                               [Page 9]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


     + The label pushed by Ru for the outer MPLS LSP is an upstream
       assigned context label, assigned by Ru. When <Rd1...Rdn> perform
       an MPLS label lookup on this label a combination of this label
       and the incoming interface MUST be sufficient for <Rd1...Rdn> to
       uniquely determine Ru's context specific label space to lookup
       the next label on the stack in. <Rd1...Rdn> MUST receive the data
       sent by Ru with the context specific label assigned by Ru being
       the top label on the label stack.

   Currently the usage of the context label TLV is limited only to LDP
   P2MP LSPs on a LAN as specified in the next section. The context
   label TLV MUST NOT be used for any other purposes.

   Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP
   the above procedures assume that Ru has a priori knowledge of all the
   <Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled
   using RSVP-TE, Ru can obtain this information from RSVP-TE. However,
   in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP
   does not provide this information to Ru. In this scenario the
   procedures by which Ru could acquire this information are outside the
   scope of this document.


6. LDP Point-to-Multipoint LSPs on a LAN

   This section describes one application of upstream label assignment
   using LDP. Further applications are to be described in separate
   documents.

   [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the
   solution relies on "ingress replication". A LSR on a LAN, that is a
   branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet
   that it receives on the P2MP LSP to each of the downstream LSRs on
   the LAN (say <Rd1...Rdn> that are adjacent to it in the P2MP LSP.

   It is desirable for Ru to send a single copy of the packet for the
   LDP P2MP LSP on the LAN, when there are multiple downstream routers
   on the LAN that are adjacent to Ru in that LDP P2MP LSP. This
   requires that each of <Rd1...Rdn> must be able to associate the label
   L, used by Ru to transmit packets for the P2MP LSP on the LAN, with
   that P2MP LSP. It is possible to achieve this using LDP upstream-
   assigned labels with the following procedures.

   Consider an LSR Rd that receives the LDP P2MP FEC [MLDP] from its
   downstream LDP peer. Further the upstream interface to reach LSR Ru
   which is the next-hop to the P2MP LSP root address, Pr, in the LDP
   P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream-
   assigned labels.  In this case Rd instead of sending a Label Mapping



Raggarwa & LeRoux                                              [Page 10]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   message as described in [MLDP] sends a Label Request message to Ru.
   This Label Request message MUST contain an Upstream Assigned Label
   Request TLV.

   On receiving this message, Ru sends back a Label Mapping message to
   Rd with an upstream-assigned label. This message also contains an
   Interface ID TLV with a  MPLS Context Label sub-TLV, as described in
   the previous section, with the value of the MPLS label set to a value
   assigned by Ru on inteface Li as specified in [RFC5331]. Processing
   of the Label Request and Label Mapping messages for LDP upstream-
   assigned labels is as described in section 4.1. If Ru receives a
   Label Request for an upstream assigned label for the same P2MP FEC
   from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send
   the same upstream-assigned label to each of <Rd1...Rdn>.

   Ru transmits the MPLS packet using the procedures defined in
   [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains
   as the top label the context label assigned by Ru on the LAN
   interface, Li. The bottom label is the upstream label assigned by Ru
   to the LDP P2MP LSP. The top label is looked up in the context of the
   LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This
   lookup enables the downstream LSR to determine the context specific
   label space to lookup the inner label in.

   Note that <Rd1...Rdn> may have more than one equal cost next-hop on
   the LAN to reach Pr. It MAY be desirable for all of them to send the
   label request to the same upstream LSR and they MAY select one
   upstream LSR using the following procedure:

   1. The candidate upstream LSRs are numbered from lower to higher IP
   address

   2. The following hash is performed: H = (Sum Opaque value) modulo N,
   where N is the number of candidate upstream LSRs. Opaque value is
   defined in [MLDP] and comprises the P2MP LSP identifier.

   3. The selected upstream LSR U is the LSR that has the number H.

   This allows for load balancing of a set of LSPs among a set of
   candidate upstream LSRs, while ensuring that on a LAN interface a
   single upstream LSR is selected. It is also to be noted that the
   procedures in this section can still be used by Rd and Ru if other
   LSRs on the LAN do not support upstream label assignment. Ingress
   replication and downstream label assignment will continue to be used
   for LSRs that do not support upstream label assignment.






Raggarwa & LeRoux                                              [Page 11]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


7. IANA Considerations

7.1. LDP TLVs

   IANA maintains a registry of LDP TLVs at the registry "Label
   Distribution Protocol" in the sub-registry called "TLV Type Name
   Space".

   This document defines a new LDP Upstream Label Assignment Capability
   TLV (Section 3). IANA is requested to assign the value 0x0507 to this
   TLV.

   This document defines a new LDP Upstream-Assigned Label TLV (Section
   4). IANA is requested to assign the type value of 0x204 to this TLV.

   This document defines a new LDP Upstream-Assigned Label Request TLV
   (Section 4). IANA is requested to assign the type value of 0x205 to
   this TLV.


7.2. Interface Type Identifiers

   [RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top-
   level TLVs can carry sub-TLVs dependent on the interface type. These
   sub-TLVs are assigned "Interface ID Types". IANA maintains a registry
   of Interface ID Types for use in GMPLS in the registry "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub-
   registry "Interface_ID Types". IANA is requested to make
   corresponding allocations from this registry as follows:

     - RSVP-TE P2MP LSP TLV (requested value 28)

     - LDP P2MP LSP TLV (requested value 29)

     - IP Multicast Tunnel TLV (requested value 30)

     - MPLS Context Label TLV (requested value 31)


8. Security Considerations

   The security considerations discussed in RFC 5036, RFC 5331 and RFC
   5332 apply to this document.

   More detailed discussion of security issues that are relevant in the
   context of MPLS and GMPLS, including security threats, related
   defensive techniques, and the mechanisms for detection and reporting,
   are discussed in "Security Framework for MPLS and GMPLS Networks



Raggarwa & LeRoux                                              [Page 12]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


   [MPLS-SEC].


9. Acknowledgements

   Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
   Thomas Morin for their comments. The hashing algorithm used on LAN
   interfaces is taken from [MLDP]. Thanks to Loa Andersson, Adrian
   Farrel and Eric Rosen for their comments and review.


10. References

10.1. Normative References

   [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
   Assignment and Context Specific Label Space", RFC5331

   [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997

   [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036.

   [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
   "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875

   [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
   Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
   Paths", draft-ietf-mpls-ldp-p2mp-08.txt


10.2. Informative References

   [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux,
   "LDP Capabilities", RFC5561

   [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS
   Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt

   [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032

   [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based
   Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
   January 2003.




Raggarwa & LeRoux                                              [Page 13]

Internet Draft     draft-ietf-mpls-ldp-upstream-10.txt     February 2011


11. Author's Address

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Phone: +1-408-936-2720
   Email: rahul@juniper.net

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   E-mail: jeanlouis.leroux@orange-ftgroup.com




































Raggarwa & LeRoux                                              [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/