Network Working Group J.L. Le Roux Internet Draft France Telecom Category: Standard Track Expires: February 2007 R. Aggarwal Juniper Networks August 2006 P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels draft-leroux-mpls-p2mp-te-bypass-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. Abstract This document defines procedures for fast reroute protection of point-to-multipoint (P2MP) MPLS-TE LSPs, with point-to-multipoint bypass tunnels. During branch node failure the traffic on a protected P2MP TE-LSP is tunneled within a P2MP bypass tunnel towards the set of Merge Points. To avoid data duplication, the backup label is assigned by the PLR following the RSVP-TE upstream label assignment procedure. Le Roux, Aggarwal Fast Reroute with P2MP Bypass Tunnels [Page 1] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 Conventions used in this document 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. Table of Contents 1. Terminology.................................................2 2. Introduction................................................3 3. Solution overview...........................................3 4. PLR procedures..............................................4 4.1. Before failure..............................................4 4.2. During failure..............................................5 5. MP Procedures...............................................5 6. Backward compatibility......................................6 7. Security Considerations.....................................6 8. References..................................................6 8.1. Normative references........................................6 9. Authors' Addresses:.........................................7 10. Intellectual Property Statement.............................7 1. Terminology This document uses terminologies defined in [RFC3031], [RFC3209], [RFC4090] and [RFC4461]. It defines the following new terms: P2MP Bypass tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE- LSP that is used to protect a set of P2MP TE-LSPs traversing a common node. The Ingress LSR of a P2MP bypass tunnel is the PLR and the leaf LSRs are a set of LSRs, on the protected P2MP LSP, downstream of the protected node. P2MP Facility Backup: A local repair method in which a P2MP bypass tunnel is used to protect one or more P2MP TE-LSPs that traverse the PLR (P2MP Bypass Ingress), the resource being protected, and the set of Merge Points (P2MP Bypass leaves) downstream to the protected resource. Backup P2MP LSP: The LSP that is used to backup up one of the many protected P2MP LSPs in P2MP Facility Backup. Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP. . Le Roux, Aggarwal [Page 2] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 2. Introduction [RFC4090] defines fast reroute extensions to RSVP-TE for local protection of P2P MPLS TE LSPs. Two techniques are defined: the one- to-one backup method, which creates a detour LSP for each protected LSP at each PLR, and the facility backup method, which creates a bypass tunnel that can be used to protect a set of LSPs by taking advantage of MPLS label stacking. [RSVP-P2MP] defines extensions to RSVP-TE for setting up P2MP TE- LSPs. It specifies extensions to one-to-one and facility backup Fast Reroute procedures defined in [RFC4090] so as to support fast reroute protection of P2MP LSPs. The facility backup solution defined in [RSVP-P2MP] only relies on P2P bypass tunnels for link and node protection. This faces the following limitation: The protection of a P2MP LSP against node failures requires, when the protected node is a Branch LSR, a set of P2P Next Next Hop (NNHOP) Bypass tunnels towards all LSRs downstream to the protected node. During failure the PLR has to replicate traffic on each P2P NNHOP bypass tunnel, and this may lead to significant inefficient bandwidth usage. To overcome this limitation it is highly desired to define extensions to the fast reroute facility backup solution, so as to support P2MP Bypass tunnels. This draft specifies extensions to the Fast Reroute procedures defined in [RFC4090] and [RSVP-P2MP] to support P2MP TE-LSP node protection with P2MP bypass tunnels. Procedures defined in [RFC4090] and [RSVP-P2MP] MUST be followed unless specified below. 3. Solution overview The P2MP Facility Backup method defined in this document relies on the use of P2MP bypass tunnels. A P2MP bypass tunnel can be used to protect a set of P2MP TE-LSPs by taking advantage of MPLS label stacking. A P2MP Bypass tunnel is used to protect a P2MP TE-LSP against branch LSR failures. The bypass tunnel head-end is the PLR, and the bypass tunnel leaf LSRs are the set of MPs, that is the set of LSRs downstream to the protected branch node, on the protected P2MP TE-LSP. The P2MP bypass tunnel protects the set of S2L sub-LSPs that transit the protected node. When P2MP facility backup method is used, during failure the PLR MUST send data for each protected P2MP LSP into the P2MP bypass tunnel. Label stacking is used: The inner label is the backup label for the backup P2MP LSP, that will be used on the MP to forward traffic to Le Roux, Aggarwal [Page 3] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 the corresponding protected P2MP LSP, and the outer label is the P2MP bypass tunnel label. To avoid data replication on the PLR, the same backup label MUST be used for all S2L sub-LSPs towards all MPs of a given backup P2MP LSP. This backup label will indicate to the MPs that packets received with that label should be switched along the protected P2MP LSP. For that purpose upstream label assignment procedures defined in [MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the same backup label, is distributed by the PLR to the set of MPs, in the context of the P2MP bypass tunnel. This requires the backup P2MP LSP to be signalled prior to the failure. On the MP, backup S2L sub-LSPs (i.e. S2L sub-LSPs of the backup P2MP LSP) are merged with protected S2L sub-LSPs. The MPs, (i.e. the bypass tunnel leaf LSRs), maintain a context specific ILM for the P2MP Bypass tunnel. The context of an inner label (i.e a backup label) is determined by the underlying P2MP bypass tunnel on which it is received. This requires deactivating PHP on the P2MP bypass tunnel. A label, in a given Bypass tunnel specific ILM, is mapped to the outgoing interfaces and labels of the corresponding protected P2MP LSP. 4. PLR procedures 4.1. Before failure To protect a P2MP LSP against a branch node failure, a PLR MUST select a P2MP bypass tunnel with a set of leaf LSRs with the following properties: - These leaf LSRs are transit or egress LSRs on the protected P2MP LSP. We will denote this subset as {LSR1.LSRn}. - {LSR1.LSRn} are downstream of the protected node on the Protected P2MP LSP. - In the event of failure of the protected node, traffic received on the protected P2MP LSP by the PLR, can be delivered to all the leaves of the protected P2MP LSP downstream to the failed node, if it is tunnelled to {LSR1.LSRn} over the P2MP bypass. PHP MUST be deactivated on the P2MP Bypass tunnel, in order to allow MPs to determine the context for the backup labels assigned by the PLR. The backup label (i.e. the inner label) used for every backup S2L sub-LSPs, (i.e. the inner label within the P2MP bypass tunnel), of a given backup P2MP LSP MUST be the same, so as to avoid traffic replication on the PLR. This label MUST be assigned by the PLR using upstream label assignment procedures. Le Roux, Aggarwal [Page 4] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 Backup P2MP LSPs MUST be signaled prior to the failure. To signal the backup P2MP LSP, the PLR MUST send one or more Path messages to each MP. The Path messages to signal a backup P2MP LSP are sent to the MPs using directed signaling; they are addressed to the MPs, without Router Alert option. The PLR MUST use the sender template specific method to identify a Path message for a backup P2MP LSPs. Hence the PLR will set the source address in the sender template to a local PLR address. A Path message to a given MP comprises one or more backup S2L sub- LSPs that transit through this MP. The backup label MUST be assigned by the PLR, in the context of the underlying P2MP Bypass tunnel, following upstream label assignment and P2MP RSVP-TE context identification procedures defined in [RSVP- UP]. Hence, a Path message sent to a MP for a backup P2MP LSP MUST include an Upstream Assigned Label object carrying the value of the backup label. It MUST also include an RSVP-TE P2MP LSP TLV within an IF_ID RSVP TLV, that carries the session object of the underlying P2MP Bypass tunnel. This allows MPs to identify the label space of the backup label assigned by the PLR. The same backup label MUST be sent to all MPs of a protected P2MP LSP. Note that the PLR MUST continue to refresh Path messages for the protected P2MP LSP along the nominal route. The processing of backup S2L sub-LSP SEROs/SRROs MUST follow backup LSP ERO/RRO processing described in [RFC4090]. 4.2. During failure When the PLR detects a link or/and node failure condition, it has to reroute a protected P2MP LSP onto the P2MP bypass tunnel using as inner label the backup label assigned for this P2MP LSP. The PLR MUST continue to send Path messages for the backup P2MP LSP. The RRO/ERO flags MUST be updated as per defined in [RFC4090] 5. MP Procedures A MP receives one or more Path messages for the protected P2MP LSP and one or more Path messages for the backup P2MP LSP. Note that, as specified in [RFC4090], the reception of a backup LSP's Path message does not indicate that a failure has occurred or that the incoming protected LSP will no longer be used. A S2L sub-LSP is received within a Path message for the protected P2MP LSP and within a Path message for the backup P2MP LSP. These two Path messages are distinguished thanks to the sender-template specific method. As specified in [RFC4090], each of these Path messages will have a different SENDER_TEMPLATE. The protected LSP can be recognized because it will include the FAST_REROUTE object or Le Roux, Aggarwal [Page 5] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 have the "local protection desired" flag set in the SESSION_ATTRIBUTE object, or both. A MP MUST install the upstream assigned label received in a backup LSP Path message, within an ILM specific to the underlying bypass tunnel, which is identified by its session object, carried within the IF_ID RSVP_HOP object of the backup Path message. An upstream assigned label for a backup P2MP LSP MUST be mapped to the outgoing interfaces and labels of the corresponding protected P2MP LSP. As specified in [RSVP-UP], the Resv message sent by a MP to the PLR, does not carry any Label Object. The processing of backup S2L sub-LSP SEROs/SRROs MUST follow backup tunnel ERO/RRO processing described in [RFC4090]. 6. Backward compatibility Procedures with MPs that do not support upstream label assignment are to be defined (combination of P2P and P2MP bypass LSPs). 7. Security Considerations No new security issues are raised in this document. 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", RFC 3031. [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209. [RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC4461. [RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090. [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-p2mp-rsvp-te, work in progress. [MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf-mpls- upstream-label, work in progress. Le Roux, Aggarwal [Page 6] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 [RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress. 9. Authors' Addresses: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net 10. 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. Disclaimer of Validity 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 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 Le Roux, Aggarwal [Page 7] Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Le Roux, Aggarwal [Page 8]