diff options
Diffstat (limited to 'doc/rfc/rfc6389.txt')
| -rw-r--r-- | doc/rfc/rfc6389.txt | 731 |
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] + |