Network Working Group Y. Brehon Internet-Draft M. Vigoureux Intended status: Informational L. Ciavaglia Expires: May 15, 2008 Alcatel-Lucent November 12, 2007 IGP Routing Protocol Extensions for Discovery of Upstream Label Assignment Node Capability draft-brevigcia-ccamp-mpls-upstream-node-cap-00.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. 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. 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. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Brehon, et al. Expires May 15, 2008 [Page 1] Internet-Draft Upstream-Node-Cap November 2007 Abstract This document proposes to extend [TE-NODE-CAP] in order to support additional TE node capabilities in the context of Point-to-MultiPoint (P2MP) LSP routing and fast reroute protection. As for point-to- point LSP, nesting P2MP LSPs into P2MP Tunnels is a desirable traffic-engineering feature. However, nesting P2MP LSPs requires a mechanism to coordinate the label allocation of the inner P2MP LSP between the egress nodes of the P2MP Tunnel as described in [MPLS- UPSTREAM]. To solve this issue, a new label allocation scheme called Upstream Label Assignment (ULA) is defined. Network elements responsible for the route computation of P2MP LSP should be aware of the nodes that support this functionality. For that purpose, we define a new bit flag to the TE Node Capability Descriptor as defined in [TE-NODE-CAP]. The bit flag (U) enables a node to advertise its capability to accept Upstream Label Assignment. Brehon, et al. Expires May 15, 2008 [Page 2] Internet-Draft Upstream-Node-Cap November 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Advantages of the solution . . . . . . . . . . . . . . . . . . 7 4. New value to the TE Node Capability Descriptor . . . . . . . . 9 5. TE Node Capability Descriptor TLV formats . . . . . . . . . . 10 5.1. OSPF TE Node Capability Descriptor TLV format . . . . . . 10 5.2. IS-IS TE Node Capability Descriptor sub-TLV format . . . . 10 6. Elements of procedure . . . . . . . . . . . . . . . . . . . . 12 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Capability Registry . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Brehon, et al. Expires May 15, 2008 [Page 3] Internet-Draft Upstream-Node-Cap November 2007 1. Terminology This document uses terminologies defined in [RFC3031], [RFC3209] and [RFC4461]. 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 RFC 2119 [RFC2119]. Brehon, et al. Expires May 15, 2008 [Page 4] Internet-Draft Upstream-Node-Cap November 2007 2. Introduction This document proposes to extend [TE-NODE-CAP] in order to support additional TE node capabilities in the context of Point-to-MultiPoint (P2MP) LSP routing and Fast ReRoute protection. As for point-to- point LSP, nesting P2MP LSPs into P2MP Tunnels is a desirable traffic-engineering feature. P2MP Fast ReRoute (FRR) [P2MP-FRR] is typical application of P2MP LSPs nesting that is likely to be deployed in MPLS-TE networks transporting multicast traffic. However, nesting P2MP LSPs requires a mechanism to coordinate the label allocation of the inner P2MP LSP between the egress nodes of the P2MP Tunnel as described in [MPLS-UPSTREAM]. To solve this issue, a new label allocation scheme called Upstream Label Assignment (ULA) is defined where the ingress node of the P2MP Tunnel allocates a single label to the egress nodes of the P2MP Tunnel for the nested P2MP LSP. Using this technique raises an additional issue: as the upstream neighbor now assigns the label, two different upstream nodes may allocate the same label value to the same receiver(s) for two different P2MP LSPs nested in different P2MP Tunnels. The egress nodes cannot anymore distinguish the LSPs based on the incoming label value. To overcome this issue, [MPLS-UPSTREAM] defines a Context- specific Label Space (CLS). The egress node must now disambiguate the label it receives based on the value of this label and according to the emitting node (i.e., defining a per-upstream-neighbor label space) or according to the value of the P2MP Tunnel label (i.e., defining a per-tunnel label space). [RSVP-UPSTREAM] and [LDP-UPSTREAM] define extensions to [RFC4875] and [MLDP] to support the advertisement of the ULA capability between adjacent nodes - i.e., between nodes which have a signaling adjacency. Unfortunately, when nesting P2MP LSPs in P2MP Tunnels, the ingress nodes and the egress nodes usually do not have such a signaling adjacency. Nevertheless, the knowledge of this capability is crucial when calculating the routes of nested P2MP LSPs over P2MP tunnels (either by the ingress node or by a Path Computation Element, PCE). If the ingress of the (nested) P2MP LSP or the PCE does not have a control adjacency with the egress nodes of the P2MP Tunnel, LSP setup will be tried and will fail in case all the egress nodes do not support the ULA capability. This is a trial-and-error approach, which can reveal inefficient and time and resource consuming. The idea is thus to extend the MPLS/GMPLS routing protocols (OSPF-TE and IS-IS-TE) to allow LSRs to inform all nodes within a network domain of a node's capability to receive upstream-assigned labels and process them accordingly. Using the routing protocol guarantees this information will be distributed to all nodes, which should perform route calculations, independently of the signaling protocols used for Brehon, et al. Expires May 15, 2008 [Page 5] Internet-Draft Upstream-Node-Cap November 2007 establishing the LSPs (LDP and/or RSVP-TE). For that purpose, this document defines a new bit flag to the TE Node Capability Descriptor as defined in [TE-NODE-CAP]. The bit flag (U) enables a node to advertise its capability to accept Upstream Label Assignment. *** Open for discussion *** Two additional bit flags can be defined to indicate the type of context label space the egress node accepts. The bit flag (N) enables a node to advertise its capability to maintain and process per-upstream-neighbor context-specific labels. The bit flag (T) enables a node to advertise its capability to maintain and process per-tunnel-neighbor context-specific labels. *** Brehon, et al. Expires May 15, 2008 [Page 6] Internet-Draft Upstream-Node-Cap November 2007 3. Advantages of the solution The advertisement of the ULA capability across the network brings additional Traffic Engineering possibilities to better manage P2MP TE LSPs. A first advantage of the proposed solution concerns P2MP TE path computation. When transporting multicast traffic over their MPLS networks, service providers and operators will often establish P2MP TE Tunnels and nest the client P2MP LSPs into them in order to keep control of the planning and resource allocation in their networks. As described briefly above, remote nodes at the endpoints of tunnels do not usually establish signaling adjacency because this would result in a fully connected graph where each node would have a control adjacency with all other nodes in the network. Similarly, if the network operator uses a PCE to calculate P2MP TE paths, the knowledge of the ULA capability cannot be advertised by the signaling protocols. Therefore, in order to avoid these blocking situations and to allow remote nodes to efficiently calculate TE P2MP paths with all the relevant information, disseminating the node capability to accept upstream-assigned labels through IGP routing protocols appears as a desirable feature and seems a scalable and efficient approach. Moreover, if an operator wishes to setup P2MP tunnels to transport P2MP LSPs, the egress nodes of the P2MP tunnel will have to support ULA. Therefore, it is pointless to setup a P2MP tunnel to only afterwards fail in all nested P2MP LSP establishments; it is much more efficient to have the relevant information for the P2MP tunnel setup right from the start. A second advantage of the proposed solution concerns P2MP fast reroute protection. As described in [P2MP-FRR], in the P2MP Facility Backup method, a P2MP Bypass Tunnel can be used to protect a set of P2MP TE LSPs. During failure, the same backup label MUST be used for all S2L sub-LSPs of a given backup P2MP LSP, tunneled within the same P2MP Bypass Tunnel to avoid data replication and traffic mis-routing in the Merge Points (MP). The Point of Local Repair (PLR) assigns the same label to all the Merge Points (MP) using the Upstream Label Assignment procedure. The backup P2MP LSPs and the P2MP Bypass tunnel have to be established prior to the failure and to work properly, the mechanism needs to know the capability of the remote nodes to accept upstream- assigned labels. If some egress nodes do not support ULA, then the PLR will establish dedicated P2P Tunnels towards them. In P2MP FRR protection, the knowledge of the ULA capability is Brehon, et al. Expires May 15, 2008 [Page 7] Internet-Draft Upstream-Node-Cap November 2007 crucial and particularly important in order to limit the number of trials before the appropriate backup LSP(s) are found and established. Globally, the proposed solution to transport the ULA capability bit in IGP routing protocols enables a scalable deployment of the P2MP mechanisms, protection mechanisms to work properly, and provides for less failure during the signaling phase. Brehon, et al. Expires May 15, 2008 [Page 8] Internet-Draft Upstream-Node-Cap November 2007 4. New value to the TE Node Capability Descriptor The TE Node Capability Descriptor contains a variable length set of bit flags, where each bit corresponds to a given TE node capability. Currently, five TE Node Capabilities are defined in [TE-NODE-CAP]. This document defines a new TE Node Capability: - U bit: when set, this flag indicates that the LSR accepts Upstream Label Assignment ([RSVP-UPSTREAM], [LDP-UPSTREAM]); *** Open for discussion *** - N bit: when set, this flag indicates that the LSR accepts per- upstream-neighbor label space. - T bit: when set, this flag indicates that the LSR accepts per- tunnel label space. *** Brehon, et al. Expires May 15, 2008 [Page 9] Internet-Draft Upstream-Node-Cap November 2007 5. TE Node Capability Descriptor TLV formats 5.1. OSPF TE Node Capability Descriptor TLV format The OSPF TE Node Capability Descriptor TLV is a variable length TLV that contains a series of bit flags, where each bit correspond to a TE node capability. The OSPF TE Node Capability Descriptor TLV is carried within an OSPF Router Information LSA which is defined in [OSPF-CAP]. The format of the OSPF TE Node Capability Descriptor TLV is the same as the TLV format used by the Traffic Engineering Extensions to OSPF [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the length of the value field and a value field. The OSPF TE Node Capability Descriptor TLV has the following format: TYPE: Assigned by IANA - see Section 8.1. LENGTH: Variable (multiple of 4). VALUE: Array of units of 32 flags numbered from the most significant bit as bit zero, where each bit represents a TE node capability. The following bits are added: Bit Capabilities 5 U bit: If set this indicates that the LSR accepts Upstream Label Assignment ([RSVP-UPSTREAM], [LDP-UPSTREAM]). *** Open for discussion *** 6 N bit: If set, this indicates that the LSR accepts per-upstream- neighbor label space. 7 T bit: If set, this indicates that the LSR accepts per-tunnel label space. *** x-31 Reserved for future assignments by IANA. 5.2. IS-IS TE Node Capability Descriptor sub-TLV format The IS-IS TE Node Capability Descriptor sub-TLV is a variable length sub-TLV that contains a series of bit flags, where each bit Brehon, et al. Expires May 15, 2008 [Page 10] Internet-Draft Upstream-Node-Cap November 2007 correspond to a TE node capability. The IS-IS TE Node Capability Descriptor sub-TLV is carried within an IS-IS CAPABILITY TLV which is defined in [IS-IS-CAP]. The format of the IS-IS TE Node Capability sub-TLV is the same as the TLV format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The IS-IS TE Node Capability Descriptor sub-TLV has the following format: TYPE: Assigned by IANA - see Section 8.1. LENGTH: Variable (multiple of 4). VALUE: Array of units of 32 flags numbered from the most significant bit as bit zero, where each bit represents a TE node capability. The following bits are added: Bit Capabilities 5 U bit: If set this indicates that the LSR accepts Upstream Label Assignment ([RSVP-UPSTREAM], [LDP-UPSTREAM]). *** Open for discussion *** 6 N bit: If set, this indicates that the LSR accepts per-upstream- neighbor label space. 7 T bit: If set, this indicates that the LSR accepts per-tunnel label space. *** x-31 Reserved for future assignments by IANA. Brehon, et al. Expires May 15, 2008 [Page 11] Internet-Draft Upstream-Node-Cap November 2007 6. Elements of procedure *** no new elements introduced by this draft *** Brehon, et al. Expires May 15, 2008 [Page 12] Internet-Draft Upstream-Node-Cap November 2007 7. Backward Compatibility *** no new elements introduced by this draft *** Brehon, et al. Expires May 15, 2008 [Page 13] Internet-Draft Upstream-Node-Cap November 2007 8. Security Considerations *** no new elements introduced by this draft *** Brehon, et al. Expires May 15, 2008 [Page 14] Internet-Draft Upstream-Node-Cap November 2007 9. IANA considerations 9.1. Capability Registry [OSPF-CAP] defines a new code point registry for TLVs carried in the Router Information LSA defined in [OSPF-CAP]. IANA is requested to make a new codepoint assignment from that registry for the TE Node Capability Descriptor TLV defined in this document and carried within the Router Information LSA. The value 1 is suggested. See Section 4.1 of this document. IANA is requested to make assignments for the (three) TE node capability(ies) defined in this document (see Sections 4.1 and 4.2) using the following suggested values, in the Capability Registry for TE-node capabilities: Bit No. Name Reference ------+-----------------------------------------------------+---------- 6 U bit: Upstream Label Assignment capability [This.I-D] 7 N bit: per-upstream-neighbor label space capability [This.I-D] 8 T bit: per-upstream-neighbor label space capability [This.I-D] Brehon, et al. Expires May 15, 2008 [Page 15] Internet-Draft Upstream-Node-Cap November 2007 10. References [TE-NODE-CAP] J.P. Vasseur, J.L. Le Roux et al., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", draft-ietf-ccamp-te-node-cap-05, work in progress. [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf-mpls-upstream-label-02, work in progress. [P2MP-FRR] J. L. Le Roux, R. Aggarwal, J.P. Vasseur, M. Vigoureux, "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", draft-ietf-mpls-p2mp-te-bypass-01, work in progress. [RSVP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream-01, work in progress. [LDP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for LDP", draft-ietf-mpls-ldp-upstream-01, work in progress. [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al. "Extensions to RSVP-TE for point-to-multipoint TE LSPs", RFC 4875. [MLDP] Minei, I., Wijnands, I., Thomas, B., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-03, work in progress. Brehon, et al. Expires May 15, 2008 [Page 16] Internet-Draft Upstream-Node-Cap November 2007 Authors' Addresses Yannick Brehon Alcatel-Lucent Route de Villejust Nozay, 91620 France Phone: +33 1 3077 2633 Email: Yannick.Brehon@alcatel-lucent.fr URI: Martin Vigoureux Alcatel-Lucent Route de Villejust Nozay, 91620 France Phone: +33 1 3077 2669 Email: Martin.Vigoureux@alcatel-lucent.fr URI: Laurent Ciavaglia Alcatel-Lucent Route de Villejust Nozay, 91620 France Phone: +33 1 3077 2636 Email: Laurent.ciavaglia@alcatel-lucent.fr URI: Brehon, et al. Expires May 15, 2008 [Page 17] Internet-Draft Upstream-Node-Cap November 2007 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Brehon, et al. Expires May 15, 2008 [Page 18]