Network Working Group J.-P Vasseur (Editor) IETF Internet Draft Zafar Ali Siva Sivabalan Cisco Systems, Inc. Proposed Status: Standard Expires: May 2006 November 2005 draft-ietf-mpls-nodeid-subobject-07.txt Definition of an RRO node-id subobject 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. Vasseur et al. 1 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 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 Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an IGP area or an Autonomous System. Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain 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 Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id subobject in order to solve this issue. The MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. Table of content 1. Terminology...............................2 2. Introduction..............................3 3. Signaling node-ids in RROs................5 4. Finding Merge Points......................6 5. Security Considerations...................6 6. IANA Considerations.......................6 7. Intellectual Property Considerations......6 8. Acknowlegments............................7 9. References................................7 9.1 Normative References.....................7 9.2 Informative References...................7 10. Authors' addresses.......................8 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 ABR Routers: border routers used to connect two IGP areas (areas in OSPF or levels in IS-IS) ASBR Routers: border routers used to connect to another AS of a different or the same Service Provider via one or more links inter- connecting between ASs. Backup Tunnel: the LSP that is used to backup up one of the many LSPs in many-to-one backup. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. Inter-area TE LSP: A TE LSP that crosses an IGP area. LSR: Label Switching Router LSP: Label Switched Path Local Repair: techniques used to repair LSP tunnels quickly when a node or link along the LSPs path fails. PCE: Path Computation Element: an entity (component, application or Vasseur, Ali and Sivabalan 2 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. 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. PLR: Point of Local Repair. The head-end of a backup tunnel. 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. TE LSP: Traffic Engineering Label Switched Path 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. There are several requirements on the backup tunnel path that must be satisfied. First, the backup tunnel must not traverse the element that 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 is the Head-end LSR of the backup tunnel and the latter is 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 an explicitly configured path or the PLR can be configured to automatically compute a backup path or to send a path computation request to a PCE (see [PCE-ARCH]). Consider the following scenario (figure 1) 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 FAST-REROUTE object) from R0 to R3, - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following the R1-ABR3-R2 path. Vasseur, Ali and Sivabalan 3 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 - The PLR 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 Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR failure with MPLS Traffic Engineering Fast Reroute 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-domain TE LSP. This document addresses these limitations. R1 needs to select an existing backup tunnel with the following properties: 1. The backup tunnel intersects with the primary tunnel at the MP. For the sake of illustration, in Figure 1, R1 needs to determine that T1 and B1 intersect at the node R2. 2. The 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 (link or node failure), as specified in [FAST- REROUTE]. One technique for the PLR to ensure that condition (1) is met consists of examining the Record Route Object (RRO) of the primary tunnel to see if any of the addresses specified in the RRO corresponds to the MP. That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 sub-objects 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 the case of a single IGP area. Specifically, in the case of a single IGP area, 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 unambiguously determine whether a backup tunnel intersecting a protected TE LSP on a downstream node exists and can also find the MP address regardless of how the addresses carried in the RRO IPv4 or IPv6 sub-objects are specified (i.e., whether using the interface addresses or the node-ids). However, such routing information is not available in the case of inter-domain environments. Hence, unambiguously making sure Vasseur, Ali and Sivabalan 4 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 that condition (1) above is met in the case of inter-domain 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. Note that the requirement for the support of the fast recovery technique specified in [FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER- AREA-TE-REQS] and [INTER-AREA-TE-REQS]. 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 sub-objects, as defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub- objects. Moreover, two additional flags are defined in [FAST-REROUTE]: the "Local Protection Available" and "Local protection in use" bits. 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. 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-domain TE LSP is solved by inserting a node-id subobject (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO object carried in the RSVP Resv message. An implementation may either decide to: 1) Add the node-id subobject in the RRO carried in an RSVP Resv message and, when required, also add another IPv4/IPv6 subobject to record interface address. Example: an inter-domain fast reroutable TE LSP would have in the RRO carried in Resv message two sub-objects: a node-id subobject and a label sub-object. If recording the interface address is required, then an additional IPv4/IPv6 subobject is added. 2) Add an IPv4/IPv6 sub-object recording the interface address and, when required, add a node-id subobject in the RRO. Example: an inter-domain fast reroutable TE LSP would have in the RRO carried in Resv message three sub-objects: an IPv4/IPv6 sub-object Vasseur, Ali and Sivabalan 5 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 recording interface address, a label sub-object and a node-id sub- object. Note also that the node-id sub-object 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. It must be noted that although the technique described in this document for selecting an appropriate backup tunnel using the node-id sub-object applies to the case of Inter-area and Inter-AS, in the case of Inter- AS, the assumption is made that the MP's node-id (of the downstream domain) does not overlap with any LSR's node-id present in the PLR's AS. 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. IANA considerations This document does not make any request for IANA action. 7. Intellectual Property Considerations 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. Vasseur, Ali and Sivabalan 6 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 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. 8. Acknowledgments We would like to acknowledge input and helpful comments from Carol Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews. A special thank to Adrian Farrel for his thorough review of this document. 9. References 9.1 Normative References [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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-07.txt. RFC 4090, May 2005. [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC3630. [ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS- IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for Traffic Engineering", RFC3784. 9.2 Informative references [INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. Vasseur, Ali and Sivabalan 7 draft-ietf-mpls-nodeid-subobject-07.txt November 2005 [INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic Engineering requirements", RFC 4216, November 2005. [PCE-ARCH] Farrel, A., Vasseur JP., Ash J., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. 10. Authors' Addresses J.-P Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue 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 Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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. Vasseur, Ali and Sivabalan 8