--- 1/draft-ietf-mpls-ldp-upstream-03.txt 2009-07-12 23:12:16.000000000 +0200 +++ 2/draft-ietf-mpls-ldp-upstream-04.txt 2009-07-12 23:12:16.000000000 +0200 @@ -1,102 +1,119 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks -Expiration Date: January 2009 +Expiration Date: January 2010 J. L. Le Roux France Telecom - July 8, 2008 + July 12, 2009 MPLS Upstream Label Assignment for LDP - draft-ietf-mpls-ldp-upstream-03.txt + draft-ietf-mpls-ldp-upstream-04.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + 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. + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. +Copyright and License Notice + + Copyright (c) 2009 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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + 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. + Abstract This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. Table of Contents - 1 Specification of requirements ......................... 2 - 2 Introduction .......................................... 2 + 1 Specification of requirements ......................... 3 + 2 Introduction .......................................... 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 ................. 6 - 7 IANA Considerations ................................... 8 - 8 Acknowledgements ...................................... 8 + 4.1 Procedures ............................................ 5 + 5 LDP Tunnel Identifier Exchange ........................ 6 + 6 LDP Point-to-Multipoint LSPs on a LAN ................. 7 + 7 IANA Considerations ................................... 9 + 8 Acknowledgements ...................................... 9 9 References ............................................ 9 9.1 Normative References .................................. 9 - 9.2 Informative References ................................ 9 + 9.2 Informative References ................................ 10 10 Author's Address ...................................... 10 -11 Intellectual Property Statement ....................... 10 -12 Full Copyright Statement .............................. 11 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction This document describes procedures for distributing upstream-assigned - labels [MPLS-UPSTREAM] for Label Distribution Protocol (LDP). These + labels [RFC5331] for Label Distribution Protocol (LDP). These procedures follow the architecture for MPLS Upstream Label Assignment - described in [MPLS-UPSTREAM]. + described in [RFC5331]. This document describes extensions to LDP that a LSR can use to advertise to its neighboring LSRs whether the LSR supports upstream label assignment. This document also describes extensions to LDP to distribute upstream-assigned labels. The usage of MPLS upstream label assignment using LDP for avoiding branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is also described. 3. LDP Upstream Label Assignment Capability - According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST - NOT be used unless it is known that a downstream LSR supports them. - This implies that there MUST be a mechanism to enable a LSR to - advertise to its LDP neighbor LSR(s) its support of upstream-assigned - labels. + 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 a 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 [LDP-CAP]. Following is the format of the LDP Upstream Label Assignment Capability Parameter: @@ -157,21 +174,21 @@ modifications pointed out in this section. A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a neighboring LSR if the neighboring LSR had not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. A LDP LSR MUST NOT send the Upstream Assigned Label Request TLV to a neighboring LSR if the neighboring LSR had not previously advertised the Upstream Label Assignment Capability in its LDP Initialization messages. - As described in [MPLS-UPSTREAM] the distribution of upstream-assigned + 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 a 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" [RFC3036]. If it does recognize the TLV but is unable to process the upstream label, it MUST generate a Notification @@ -185,73 +202,91 @@ 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 [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a - MPLS packet, the top label of which (L) is upstream-assigned, to a + As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS + packet, the top label of which (L) is upstream-assigned, to a downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In this case the fact that L is upstream-assigned is determined by Rd by the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels. When LDP is used for upstream label assignment, the Interface ID TLV [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an IP or MPLS tunnel to transmit MPLS packets with upstream assigned labels to Rd, Ru MUST include the Interface ID TLV in the Label - Mapping messages along with the Upstream Assigned Label TLV. Three - new Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs, IP - Multicast Tunnels and context labels. The TLV value acts as the - tunnel identifier. + Mapping messages along with the Upstream Assigned Label TLV. 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. - 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE + 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of he TLV is the RSVP-TE P2MP Session Object and optionally the P2MP Sender Template 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 - 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is + 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 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. - 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is + 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is a tuple. The Source Address belongs to Ru and the MPLS Context Label is an upstream assigned label, assigned by Ru. 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: + The label pushed by Ru for the outer MPLS LSP is an upstream assigned context label, assigned by Ru. When perform a MPLS label lookup on this label a combination of this label and the incoming interface MUST be sufficient for to uniquely determine Ru's context specific label space to lookup the next label on the stack in. 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 purposes. + 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 + . 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. [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the solution relies on "ingress replication". A LSR on a LAN, that is a branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet that it receives on the P2MP LSP to each of the downstream LSRs on @@ -271,35 +306,35 @@ 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 [MPLS-UPSTREAM]. 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 . + 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 [MPLS- - UPSTREAM] and [MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru - contains as the top label the context label assigned by Ru on the LAN + 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, [MPLS-UPSTREAM] 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. + 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. Note that 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, @@ -321,120 +356,82 @@ This document defines a new LDP Upstream Label Assignment Capability Parameter. IANA is requested to assign the value 0x0507 to this Parameter. This document defines a new LDP Upstream-Assigned Label Request TLV, IANA is requested to assign the type value of this TLV. This document defines a new LDP Upstream-Assigned Label TLV, IANA is requested to assign the type value of this TLV. - This document defines three new Interface ID TLVs: + This document defines four new Interface ID TLVs: - RSVP-TE P2MP LSP TLV + - LDP P2MP LSP TLV + - IP Multicast Tunnel TLV - MPLS Context Label TLV IANA is requested to assign the type values of these TLVs. 8. 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]. 9. References 9.1. Normative References [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, RFC 3031. - [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream - Label Assignment and Context Specific Label Space", draft-ietf-mpls- - upstream-label-06.txt + [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label + Assignment and Context Specific Label Space", RFC5331 - [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, - draft-ietf-mpls-codepoint-10.txt + [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471 January 2003. [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. 9.2. Informative References [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", - draft-ietf-l3vpn-2547bis-mcast-06.txt + draft-ietf-l3vpn-2547bis-mcast-08.txt [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp- - p2mp-05.txt + p2mp-07.txt [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- - ldp-capabilities-02.txt + ldp-capabilities-04.txt 10. Author's Address Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Phone: +1-408-936-2720 Email: rahul@juniper.net Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France E-mail: jeanlouis.leroux@orange-ftgroup.com - -11. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -12. Full Copyright Statement - - Copyright (C) The IETF Trust (2007). This document is subject to the - rights, licenses and restrictions contained in BCP 78, and except as - set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.