--- 1/draft-ietf-mpls-ldp-upstream-06.txt 2010-03-03 00:11:08.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-upstream-07.txt 2010-03-03 00:11:08.000000000 +0100 @@ -1,22 +1,23 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks -Expiration Date: August 2010 +Category: Standards Track +Expiration Date: September 2010 J. L. Le Roux France Telecom - February 25, 2010 + March 2, 2010 MPLS Upstream Label Assignment for LDP - draft-ietf-mpls-ldp-upstream-06.txt + draft-ietf-mpls-ldp-upstream-07.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -62,32 +63,35 @@ 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. Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 - 3 LDP Upstream Label Assignment Capability .............. 3 - 4 Distributing Upstream-Assigned Labels in LDP .......... 4 + 3 LDP Upstream Label Assignment Capability .............. 4 + 4 Distributing Upstream-Assigned Labels in LDP .......... 5 4.1 Procedures ............................................ 5 5 LDP Tunnel Identifier Exchange ........................ 6 - 6 LDP Point-to-Multipoint LSPs on a LAN ................. 7 + 6 LDP Point-to-Multipoint LSPs on a LAN ................. 8 7 IANA Considerations ................................... 9 - 8 Security Considerations ............................... 9 - 9 Acknowledgements ...................................... 10 -10 References ............................................ 10 -10.1 Normative References .................................. 10 -10.2 Informative References ................................ 10 -11 Author's Address ...................................... 11 + 7.1 LDP TLVs .............................................. 9 + 7.2 Interface Type Identifiers ............................ 10 + 8 Security Considerations ............................... 10 + 9 Acknowledgements ...................................... 11 +10 References ............................................ 11 +10.1 Normative References .................................. 11 +10.2 Informative References ................................ 11 +11 Author's Address ...................................... 12 + 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction This document describes procedures for distributing upstream-assigned labels [RFC5331] for Label Distribution Protocol (LDP). These @@ -218,44 +222,46 @@ the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels. When LDP is used for upstream label assignment, the Interface ID TLV [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream assigned labels to Rd, Ru MUST include the Interface ID TLV in the Label Mapping messages along with the Upstream Assigned Label TLV. The - IPv4 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. + IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields + in the Interface ID TLV SHOULD be set to 0 by the sender and ignored + by the receiver. - Four new Interface ID TLVs are introduced to support RSVP-TE P2MP - LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV - value acts as the tunnel identifier. + The Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs + are introduced to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP + Multicast Tunnels and context labels. The TLV value in the sub-TLV + acts as the tunnel identifier. Following are the sub-TLVs that are + introduced: 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object [RFC4875]. 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 . The P2MP LSP IF_ID TLV allows - Ru to signal to the binding of the inner LDP P2MP LSP to - the outer RSVP-TE P2MP LSP. The control plane signaling between Ru - and for the inner P2MP LSP uses targeted LDP signaling - messages + P2MP LSP that has leaves . The RSVP-TE P2MP LSP IF_ID TLV + allows Ru to signal to the binding of the inner LDP P2MP + LSP to the outer RSVP-TE P2MP LSP. The control plane signaling + between Ru and for the inner P2MP LSP uses targeted LDP + signaling messages 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC as defined in [MLDP]. 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 - . The P2MP LSP IF_ID TLV allows Ru to signal to + . The LDP P2MP LSP IF_ID TLV allows Ru to signal to the binding of the inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane signaling between Ru and for the inner P2MP LSP uses targeted LDP signaling messages 3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is a 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. 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is @@ -310,29 +316,29 @@ Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its downstream LDP peer. Further the upstream interface to reach LSR Ru which is the next-hop to the P2MP LSP root address, Pr, in the LDP P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- assigned labels. In this case Rd instead of sending a Label Mapping message as described in [MLDP] 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. This message also contains a MPLS - Context Label TLV, as described in the previous section, with the - value of the MPLS label set to a value assigned by Ru on inteface Li - as specified in [RFC5331]. Processing of the Label Request and Label - Mapping messages for LDP upstream-assigned labels is as described in - section 4.2. If Ru receives a Label Request for an upstream assigned - label for the same P2MP FEC from multiple downstream LSRs on the LAN, - , it MUST send the same upstream-assigned label to each of - . + with an upstream-assigned label. This message also contains an + Interface ID TLV with a MPLS Context Label sub-TLV, as described in + the previous section, with the value of the MPLS label set to a value + assigned by Ru on inteface Li as specified in [RFC5331]. Processing + of the Label Request and Label Mapping messages for LDP upstream- + assigned labels is as described in section 4.2. If Ru receives a + Label Request for an upstream assigned label for the same P2MP FEC + from multiple downstream LSRs on the LAN, , it MUST send + the same upstream-assigned label to each of . Ru transmits the MPLS packet using the procedures defined in [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains as the top label the context label assigned by Ru on the LAN interface, Li. The bottom label is the upstream label assigned by Ru to the LDP P2MP LSP. The top label is looked up in the context of the LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This lookup enables the downstream LSR to determine the context specific label space to lookup the inner label in. @@ -353,61 +359,72 @@ 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 - Parameter. IANA is requested to assign the value 0x0507 to this - Parameter. + TLV (Section 3). IANA is requested to assign the value 0x0507 to this + TLV. - This document defines a new LDP Upstream-Assigned Label TLV, IANA is - requested to assign the type value of 0x204 to this TLV. + This document defines a new LDP Upstream-Assigned Label TLV (Section + 4). IANA is requested to assign the type value of 0x204 to this TLV. - This document defines a new LDP Upstream-Assigned Label Request TLV, - IANA is requested to assign the type value of 0x205 to this TLV. + This document defines a new LDP Upstream-Assigned Label Request TLV + (Section 4). IANA is requested to assign the type value of 0x205 to + this TLV. - This document defines four new Interface ID TLVs: +7.2. Interface Type Identifiers - - RSVP-TE P2MP LSP TLV + [RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top- + level TLVs can carry sub-TLVs dependent on the interface type. These + sub-TLVs are assigned "Interface ID Types". IANA maintains a registry + of Interface ID Types for use in GMPLS in the registry "Generalized + Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub- + registry "Interface_ID Types". IANA is requested to make + corresponding allocations from this registry as follows: - - LDP P2MP LSP TLV + - RSVP-TE P2MP LSP TLV (requested value 28) - - IP Multicast Tunnel TLV + - LDP P2MP LSP TLV (requested value 29) - - MPLS Context Label TLV + - IP Multicast Tunnel TLV (requested value 30) - These values are assigned from the Interface_ID Type space defined in - [RFC3471]. IANA is requested to assign the type value 6 to RSVP-TE - P2MP LSP TLV, type value 7 to LDP P2MP LSP TLV, type value 8 to IP - Multicast Tunnel TLV and type value 9 to MPLS Context Label TLV. + - MPLS Context Label TLV (requested value 31) 8. Security Considerations The security considerations discussed in RFC 5331 and RFC 5332 apply to this document. More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks [MPLS-SEC]. 9. Acknowledgements Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thomas Morin for their comments. The hashing algorithm used on LAN - interfaces is taken from [MLDP]. + interfaces is taken from [MLDP]. Thanks to Loa Andersson and Adrian + Farrel for their comments on the IANA section. 10. References 10.1. Normative References [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", RFC5331 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332