Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: April 2006
                                                           J. L. Le Roux
                                                          France Telecom

                                                            October 2005


                 MPLS Upstream Label Assignment for LDP


                draft-raggarwa-mpls-ldp-upstream-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

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 LSR traffic
   replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.








Raggarwa & LeRoux                                               [Page 1]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


Table of Contents

 1          Specification of requirements  .........................   2
 2          Introduction  ..........................................   2
 3          LDP Upstream Label Assignment Capability  ..............   3
 4          Distributing Upstream-Assigned Labels in LDP  ..........   4
 4.1        Procedures  ............................................   4
 5          LDP Tunnel Identifier Exchange  ........................   5
 6          LDP Point-to-Multipoint LSPs on a LAN  .................   6
 7          Acknowledgements  ......................................   7
 8          References  ............................................   7
 8.1        Normative References  ..................................   7
 8.2        Informative References  ................................   8
 9          Author Information  ....................................   8
10          Intellectual Property Statement  .......................   8
11          Full Copyright Statement  ..............................   9




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 [MPLS-UPSTREAM] for Label Distribution Protocol (LDP). These
   procedures follow the architecture for MPLS Upstream Label Assignment
   described in [MPLS-UPSTREAM].

   This document describes extensions to LDP that a 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
   upstream-assigned labels.

   The usage of MPLS upstream label assignment using LDP for avoiding
   branch LSR traffic replication on a LAN for LDP P2MP LSPs [LDP-P2MP1,
   LDP-P2MP2] is also described.




Raggarwa & LeRoux                                               [Page 2]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


3. LDP Upstream Label Assignment Capability

   According to [MPLS-UPSTREAM], 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 a LSR to adver-
   tise to its LDP neighbor LSR(s) its support of upstream-assigned
   labels.

   A new optional parameter, the LDP Capability TLV, is introduced to
   allow LDP peers to exchange capabilities as part of LDP Initializa-
   tion messages.  This TLV contains one or more sub-TLVs, each to sig-
   nal a specific capability. LDP Capability TLV and detailed procedures
   for supporting LDP Capability signaling will be described in a sepa-
   rate document.

   A Upstream Label Assignment Capability sub-TLV is introduced to sig-
   nal a LSR's support of upstream label assignment, to its LDP peers.
   This sub-TLV is carried in the LDP Capability TLV.

   Following is the format of the LDP Capability 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0| Capability TLV (TBD)      |      Length (= 4)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sub-TLVs...                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Following is the format of the Upstream Label Assignment Capability
   sub-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Upstream Lbl Ass Cap = 1       |      Length (= 4)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   If a LSR includes the Upstream Label Assignment Capability sub-TLV in
   LDP Initialization Messages it implies that the LSR is capable of
   both distributing upstream-assigned label bindings and receiving
   upstream-assigned label bindings. Reserved bits MUST be set to zero
   on transmission and MUST be ignored on receipt.




Raggarwa & LeRoux                                               [Page 3]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


4. Distributing Upstream-Assigned Labels in LDP

   An optional LDP TLV, Upstream-Assigned Label Request TLV, is intro-
   duced.  This TLV MUST be carried in a Label Request message if an
   upstream-assigned label is being requested.

       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                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Label

   This is a 20-bit label value as specified in [RFC3032] represented as
   a 20-bit number in a 4 octet field.


4.1. Procedures

   Procedures for Label Mapping, Label Request, Label Abort, Label With-
   draw and Label Release follow [RFC3036] 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 pre-
   viously advertised the Upstream Label Assignment Capability in its



Raggarwa & LeRoux                                               [Page 4]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


   LDP Initialization messages.

   As described in [MPLS-UPSTREAM] 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 a LSR receives a Label Mapping mes-
   sage with an Upstream Assigned Label TLV and if it does not recognize
   the TLV, it MUST generate a Notification message with a status code
   of "Unknown TLV" [RFC3036]. 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 Map-
   ping 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 a LSR generates a down-
   stream 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 particu-
   lar upstream assigned label binding.


5. LDP Tunnel Identifier Exchange

   As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a
   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 Map-
   ping messages along with the Upstream Assigned Label TLV.  Two new
   Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs and IP
   Multicast Tunnels. The TLV value acts as the tunnel identifier.




Raggarwa & LeRoux                                               [Page 5]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


   1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE
   P2MP Session Object and optionally the P2MP Sender Template Object
   [RSVP-TE-P2MP].  The TLV value 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 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. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is
   a <Source Address, Multicast Group Address> tuple.


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 docu-
   ments.

   [LDP-P2MP1, LDP-P2MP2] describe 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 down-
   stream 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 a LSR Rd that receives the LDP P2MP FEC [LDP-P2MP1, LDP-
   P2MP2] 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. Further Rd and Ru sup-
   port upstream-assigned labels. In this case Rd instead of sending a
   Label Mapping message as described in [LDP-P2MP1, LDP-P2MP2] sends a
   Label Request message to Ru.  This Label Request message MUST contain
   an Upstream Assigned Label Request TLV.  Ru on receiving this message
   sends back a Label Mapping message to Rd with an upstream-assigned
   label. Processing of the Label Request and Label Mapping messages for
   LDP upstream-assigned labels is as described in section 4.2.  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



Raggarwa & LeRoux                                               [Page 6]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


   MUST send the same upstream-assigned label to each of <Rd1...Rdn>. Ru
   transmits the MPLS packet with an upstream-assigned label on the LAN
   using the procedures defined in [MPLS-UPSTREAM] and [MPLS-MCAST-
   ENCAPS].

   Note that <Rd1...Rdn> may have more than one equal cost next-hop on
   the LAN to reach Pr. In this case they MAY be configured to send the
   upstream assigned label request to the next-hop LSR with the lowest
   Router ID, if it is desirable for all of them to send the label
   request to the same upstream LSR. It is also to be noted that these
   procedures can still be used by Rd and Ru if other LSRs on the LAN do
   not support upstream label assignment. Ingress replication and down-
   stream label assignment will continue to be used for LSRs that do not
   support upstream label assignment.




7. Acknowledgements

   Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
   Thomas Morin for their comments.


8. References

8.1. Normative References

   [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
   RFC 3031.

   [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
   Label Assignment and Context Specific Label Space", draft-raggarwa-
   mpls-upstream-label-00.txt

   [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
   draft-rosen-mpls-codepoint-00.txt

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

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

   [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling Functional Description", RFC 3471 January



Raggarwa & LeRoux                                               [Page 7]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


   2003.

   [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001.


8.2. Informative References

   [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs"

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

   [LDP-P2MP1] I. Minei et. al, "Label Distribution Protocol Extensions
   for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp-
   p2mp-00.txt

   [LDP-P2MP2] I. Wijnands et. al., "Multicast Extensions for LDP",
   draft-wijnands-mpls-ldp-mcast-ext-00.txt


9. Author Information

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net

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



10. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.




Raggarwa & LeRoux                                               [Page 8]


Internet Draft   draft-raggarwa-mpls-ldp-upstream-00.txt    October 2005


   Copies of IPR disclosures made to the IETF Secretariat and any assur-
   ances of licenses to be made available, or the result of an attempt
   made to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.



11. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.























Raggarwa & LeRoux                                               [Page 9]