doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6389.txt b/doc/rfc/rfc6389.txt
new file mode 100644
index 0000000..52a76f6
--- /dev/null
+++ b/doc/rfc/rfc6389.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       R. Aggarwal
+Request for Comments: 6389                              Juniper Networks
+Category: Standards Track                                    JL. Le Roux
+ISSN: 2070-1721                                                   Orange
+                                                           November 2011
+
+
+                 MPLS Upstream Label Assignment for LDP
+
+Abstract
+
+   This document describes procedures for distributing upstream-assigned
+   labels for the 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).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6389.
+
+Copyright 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
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 1]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Specification of Requirements ...................................3
+   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 ...........................9
+   7. IANA Considerations ............................................11
+      7.1. LDP TLVs ..................................................11
+      7.2. Interface Type Identifiers ................................11
+   8. Security Considerations ........................................12
+   9. Acknowledgements ...............................................12
+   10. References ....................................................12
+      10.1. Normative References .....................................12
+      10.2. Informative References ...................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 2]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+1.  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 whether the LSR supports upstream
+   label assignment to its neighboring LSRs.
+
+   This document also describes extensions to LDP to distribute
+   upstream-assigned labels.
+
+   The usage of MPLS upstream label assignment using LDP to avoid branch
+   LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)
+   Label Switched Paths (LSPs) [RFC6388] is also described.
+
+2.  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].
+
+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| Upstrm Lbl Ass Cap(0x0507)|      Length (= 1)             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |1| Reserved    |
+      +-+-+-+-+-+-+-+-+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 3]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   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.
+
+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|Upstrm-Ass Lbl Req (0x0205)|      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| Upstrm-Ass Label (0x0204) |      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 RFC 5036 [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.
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 4]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   An LDP LSR MUST NOT distribute the Upstream-Assigned Label TLV to a
+   neighboring LSR if the neighboring LSR has not previously advertised
+   the Upstream Label Assignment Capability in its LDP Initialization
+   messages.  An LDP LSR MUST NOT send the Upstream-Assigned Label
+   Request TLV to a neighboring LSR if the neighboring LSR has not
+   previously advertised the Upstream Label Assignment Capability in its
+   LDP Initialization messages.
+
+   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.  An 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], a specific upstream LSR (Ru) MAY transmit
+   an MPLS packet, the top label of which (L) is upstream assigned, to
+   its downstream neighbor LSR (Rd).  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
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 5]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   Mapping messages along with the Upstream-Assigned Label TLV.  The
+   IPv4/IPv6 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 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 -
+   Traffic Engineering (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.
+
+
+
+
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 6]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   The following sub-TLVs are introduced:
+
+   1. RSVP-TE P2MP LSP TLV (Type = 28)
+
+   The 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:
+
+       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.
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 7]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   2. LDP P2MP LSP TLV (Type = 29)
+
+   The value of the TLV is the LDP P2MP FEC as defined in [RFC6388] and
+   has to be set as per the procedures in [RFC6388].  Here is the format
+   of the LDP P2MP FEC as defined in [RFC6388]:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |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)
+
+   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.
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 8]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   4. MPLS Context Label TLV (Type = 31)
+
+   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:
+
+      o  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 look up the next label on the stack.  <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 purpose.
+
+   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.
+
+   [RFC6388] describes how to setup P2MP LSPs using LDP.  On a LAN the
+   solution relies on "ingress replication".  An 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
+
+
+
+Aggarwal & Le Roux           Standards Track                    [Page 9]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   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 [RFC6388] from its
+   downstream LDP peer.  Additionally, consider that the upstream
+   interface to reach LSR Ru that is the next hop to the P2MP LSP root
+   address (Pr) in the LDP P2MP FEC is a LAN interface (Li) and that Rd
+   and Ru support upstream-assigned labels.  In this case, instead of
+   sending a Label Mapping message as described in [RFC6388], Rd 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 an 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 interface 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) by a downstream LSR on the LAN.  This lookup
+   enables the downstream LSR to determine the context-specific label
+   space in which to look up the inner label.
+
+   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.  The Opaque
+      value is defined in [RFC6388] and comprises the P2MP LSP
+      identifier.
+
+
+
+
+Aggarwal & Le Roux           Standards Track                   [Page 10]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+   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.
+
+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 has assigned the value 0x0507 to this TLV.
+
+   This document defines a new LDP Upstream-Assigned Label TLV (Section
+   4).  IANA has assigned the type value of 0x204 to this TLV.
+
+   This document defines a new LDP Upstream-Assigned Label Request TLV
+   (Section 4).  IANA has assigned 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 has made the
+   corresponding allocations from this registry as follows:
+
+      -  RSVP-TE P2MP LSP TLV (value 28)
+
+      -  LDP P2MP LSP TLV (value 29)
+
+      -  IP Multicast Tunnel TLV (value 30)
+
+      -  MPLS Context Label TLV (value 31)
+
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                   [Page 11]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+8.  Security Considerations
+
+   The security considerations discussed in [RFC5036], [RFC5331], and
+   [RFC5332] 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"
+   [RFC5920].
+
+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 [RFC6388].  Thanks to Loa Andersson,
+   Adrian Farrel, and Eric Rosen for their comments and review.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+             "LDP Specification", RFC 5036, October 2007.
+
+   [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa,
+             Ed., "Extensions to Resource Reservation Protocol - Traffic
+             Engineering (RSVP-TE) for Point-to-Multipoint TE Label
+             Switched Paths (LSPs)", RFC 4875, May 2007.
+
+   [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
+             Label Assignment and Context-Specific Label Space", RFC
+             5331, August 2008.
+
+   [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
+             "MPLS Multicast Encapsulations", RFC 5332, August 2008.
+
+   [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
+             Le Roux, "LDP Capabilities", RFC 5561, July 2009.
+
+   [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
+             Thomas, "Label Distribution Protocol Extensions for Point-
+             to-Multipoint and Multipoint-to-Multipoint Label Switched
+             Paths", RFC 6388, November 2011.
+
+
+
+
+Aggarwal & Le Roux           Standards Track                   [Page 12]
+
+RFC 6389         MPLS Upstream Label Assignment for LDP    November 2011
+
+
+10.2.  Informative References
+
+   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+             Encoding", RFC 3032, January 2001.
+
+   [RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized
+             Multi-Protocol Label Switching (GMPLS) Signaling
+             Constraint-based Routed Label Distribution Protocol
+             (CR-LDP) Extensions", RFC 3472, January 2003.
+
+   [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+             Networks", RFC 5920, July 2010.
+
+Author's Address
+
+   Rahul Aggarwal
+   Juniper Networks
+   1194 North Mathilda Ave.
+   Sunnyvale, CA 94089
+   Phone: +1-408-936-2720
+   EMail: raggarwa_1@yahoo.com
+
+
+   Jean-Louis Le Roux
+   France Telecom
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex
+   France
+   EMail: jeanlouis.leroux@orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal & Le Roux           Standards Track                   [Page 13]
+