Jean Philippe Vasseur (Editor) Zafar Ali Siva Sivabalan Cisco Systems, Inc. IETF Internet Draft Expires: July, 2004 January, 2004 draft-ietf-mpls-nodeid-subobject-02.txt Definition of an RRO node-id subobject Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Vasseur, Ali and Sivabalan 1 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 Abstract In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. 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 [i]. 1. Terminology LSR - Label Switch Router LSP - An MPLS Label Switched Path PCS - Path Computation Server (may be any kind of LSR (ABR, ...) or a centralized path computation server PCC - Path Computation Client (any head-end LSR) requesting a path computation of the Path Computation Server. Local Repair - Techniques used to repair LSP tunnels quickly when a node or link along the LSPs path fails. Protected LSP - An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop. Bypass Tunnel - An LSP that is used to protect a set of LSPs passing over a common facility. Backup Tunnel - The LSP that is used to backup up one of the many LSPs in many-to-one backup. PLR - Point of Local Repair. The head-end of a backup tunnel or a detour LSP. Vasseur, Ali and Sivabalan 2 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 MP - Merge Point. The LSR where detour or backup tunnels meet the protected LSP. In case of one-to-one backup, this is where multiple detours converge. A MP may also be a PLR. NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single link of the protected LSP. NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single node of the protected LSP. Reroutable LSP - Any LSP for with the "Local protection desired" bit is set in the Flag field of the SESSION_ATTRIBUTE object of its Path messages. CSPF - Constraint-based Shortest Path First. Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do not reside within the same Autonomous System (AS) or both Head-end LSR and Tail-end LSR are in the same AS but the TE tunnel transiting path may be across different ASes Interconnect or ASBR Routers: Routers used to connect to another AS of a different or the same Service Provider via one or more Inter-AS links. 2. Introduction MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local protection technique used to protect Traffic Engineering LSPs from link/SRLG/node failure. One or more backup tunnels are pre- established to protect against the failure of a link/node/SRLG. In case of failure, every protected TE LSP traversing the failed resource is rerouted onto the appropriate backup tunnels in 10s of msecs. There are a couple of requirements on the backup tunnel path. At least, a backup tunnel should not pass through the element it protects. Additionally, a primary tunnel and its associated backup tunnel should intersect at least at two points (nodes): Point of Local Repair (PLR) and Merge Point (MP). The former should be the head-end LSR of the backup tunnel, and the latter should be the tail-end LSR of the backup tunnel. The PLR is where FRR is triggered when link/node/SRLG failure happens. There are different methods for computing paths for backup tunnels at a given PLR. Specifically, a user can statically configure one or more backup tunnels at the PLR, with explicit path or the PLR can be configured to automatically compute a backup path or to send a path computation request to a PCS (which can be an LSR or an off-line tool). Consider the following scenario: Vasseur, Ali and Sivabalan 3 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 Assumptions: - A multi-area network made of three areas: 0, 1 and 2. - A fast reroutable TE LSP T1 (TE LSP signaled with the "local Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR object) from R0 to R3 - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1 onto the backup tunnel B1 in case of ABR1's failure. <--- area 1 --><---area 0---><---area 2---> R0-----R1-ABR1--R2------ABR2--------R3 \ / \ ABR3 / When T1 is first signaled, the PLR R1 needs to dynamically select an appropriate backup tunnel intersecting T1 on a downstream LSR. However, existing protocol mechanisms are not sufficient to unambiguously find the MP address in a network with inter-area or inter-AS traffic engineering (although the example above was given in the context of multi-area networks, a similar reasoning applies to TE LSP spanning multiple ASes). This document addresses these limitations. R1 needs to ensure the following: 1. Backup tunnel intersects with the primary tunnel at the MP (and thus has a valid MP address), e.g., in Figure 1, R1 needs to determine that T1 and B1 share the same MP node R2, 2. Backup tunnel satisfies the primary LSP's request with respect to the bandwidth protection request (i.e., bandwidth guaranteed for the primary tunnel during failure), and the type of protection (preferably, protecting against a node failure versus a link failure), as specified in [FAST-REROUTE]. A PLR can make sure that condition (1) is met by examining the Record Route Object (RRO) of the primary tunnel to see if any of the addresses specified in the RRO is attached to the tail-end of the backup tunnel. As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 subobjects sent in Resv messages can be node-ids and/or interface addresses . Hence, in Figure 1, router R2 may specify interface addresses in the RROs for T1 and B1. Note that these interface addresses are different in this example. The problem of finding the MP using the interface addresses or node-ids can be easily solved in a single area (OSPF_)/level (IS-IS). Specifically, in the case of single area/level, the PLR has the knowledge of all the interfaces attached to the tail-end of the backup tunnel. This information is available in PLR's IGP topology database. Thus, the PLR can determine whether a backup tunnel intersecting a protected TE LSP on a downstream node exists and can also find the MP Vasseur, Ali and Sivabalan 4 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 address regardless of how the addresses contained in the RRO IPv4 or IPv6 subobjects are specified (i.e., whether using the interface addresses or the node IDs). However, such routing information is not available in multi-area and inter-AS traffic engineering environments. Hence, unambiguously making sure that condition (1) above is met with inter-area TE and inter-AS traffic-engineering TE LSPs is not possible with existing mechanisms. In this document, we define extensions to and describe the use of RSVP [RSVP, RSVP-TE] to solve the above-mentioned problem. 3. Signaling node-ids in RROs As mentioned above, the limitation that we need to address is the generality of the contents of the RRO IPv4 and IPv6 subobjects, as defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobjects along with two flags (namely the ôLocal Protection Availableö and ôLocal protection in useö bits). Moreover, other bits have been specified in [FAST-REROUTE] and [SOFT-PREEMPTION]. In this document, we define the following new flag: Node-id: 0x20 When set, this indicates that the address specified in the RRO's IPv4 or IPv6 subobject is a node-id address, which refers to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]. A node MUST use the same address consistently. In other words, once an address is used in RRO's IPv4 or IPv6 subobject, it should always be used for the lifetime of the LSP. An IPv4 or IPv6 RRO subobject with the node-id flag set is also called a node-id subobject. The problem of finding a MP address in a network with inter-area or inter-AS traffic engineering is solved by inserting a node-id subobject (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set). An implementation MAY either decide to support of one the following options: Option 1: add the node-id subobject in an RSVP Resv message and, when required, also add another IPv4/IPv6 subobject to record interface address. Example: a fast reroutable TE LSP would have in the RRO object carried in Resv message two subobjects: a node-id subobject and a label subobject. If recording the interface address is required, then an additional IPv4/IPv6 subobject is added. Vasseur, Ali and Sivabalan 5 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 Option 2: add an IPv4/IPv6 subobject recording the interface address and, when required, add a node-id subobject in the RRO object. Example: an inter-area/inter-AS fast reroutable TE LSP would have in the RRO object carried in Resv message three subobjects: an IPv4/IPv6 subobject recording interface address, a label subobject and a node-id subobject. Note also, that the node-id subobject may have other application than Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also set the Node-id flag. 4. Finding Merge Point Two cases should be considered: - case 1: the backup tunnel destination is the MP's node-id. Then a PLR can find the MP and suitable backup tunnel by simply comparing the backup tunnel's destination address with the node-id included in the RRO of the primary tunnel. - case 2: the backup tunnel terminates at an address different than the MP's node-id. Then a node-id subobject MUST also be included in the RRO object of the backup tunnel. A PLR can find the MP and suitable backup tunnel by simply comparing the node-ids present in the RRO objects of both the primary and backup tunnels. When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR may use any or both of them in finding the MP address. 5. Security Considerations This document does not introduce new security issues. The security considerations pertaining to [RSVP] and [RSVP-TE] remain relevant. 6. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Vasseur, Ali and Sivabalan 6 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 7. Acknowledgments We would like to acknowledge input and helpful comments from Carol Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and Adrian Farrel. Normative References [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003. [OSPF-TE] Katz et al., ôTraffic Engineering (TE) Extensions to OSPF Version 2ö, RFC3630. [ISIS-TE] Smit et al., IS-IS extensions for Traffic Engineering, draft-ietf-isis-traffic-05.txt, work in progress. Informative references [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering requirements", draft-tewg-interas-te-req-05.txt, work in progress. [INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", draft-vasseur-mpls-inter-as-te-01.txt, work in progress. [MULTI-AREA-TE] Kompella et al,"Multi-area MPLS Traffic Engineering", draft-kompella-mpls-multiarea-te-03.txt, work in progress. [LOOSE-PATH-REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS Vasseur, Ali and Sivabalan 7 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 Traffic Engineering loosely routed explicit LSP path", , Internet Draft, work in progress. Authors' Address: Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Zafar Ali Cisco Systems, Inc. 100 South Main St. #200 Ann Arbor, MI 48104 USA zali@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada msiva@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE Vasseur, Ali and Sivabalan 8 draft-ietf-mpls-nodeid-subobject-02.txt January 2004 DISCLAIMS 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. Vasseur, Ali and Sivabalan 9