GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6389

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:
  1. RSVP-TE P2MP LSP TLV (value 28)
  1. LDP P2MP LSP TLV (value 29)
  1. IP Multicast Tunnel TLV (value 30)
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6389.txt · Last modified: 2011/11/07 16:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki