idnits 2.17.1 draft-ietf-mpls-nodeid-subobject-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 324. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 483 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2005) is 6734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'INTER-AS-TE-REQS' is defined on line 363, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.-P Vasseur (Editor) 3 IETF Internet Draft Zafar Ali 4 Siva Sivabalan 5 Cisco Systems, Inc. 7 Proposed Status: Standard 8 Expires: May 2006 9 November 2005 11 draft-ietf-mpls-nodeid-subobject-07.txt 13 Definition of an RRO node-id subobject 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Vasseur et al. 1 38 Abstract 40 In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is 41 required at the Point of Local Repair (PLR) in order to select a backup 42 tunnel intersecting a fast reroutable Traffic Engineering Label 43 Switched Path (TE LSP) on a downstream Label Switching Router (LSR). 44 However, existing protocol mechanisms are not sufficient to find an MP 45 address in multi-domain routing networks where a domain is defined as 46 an IGP area or an Autonomous System. Hence, the current MPLS Fast 47 Reroute mechanism cannot be used in order to protect inter-domain TE 48 LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous 49 System Border Router) respectively. This document specifies the use of 50 existing Route Record Object (RRO) IPv4 and IPv6 sub-objects (with a 51 new flag defined) thus defining the node-id subobject in order to solve 52 this issue. The MPLS Fast reroute mechanism mentioned in this document 53 refers to the "Facility backup" MPLS TE Fast Reroute method. 55 Table of content 57 1. Terminology...............................2 58 2. Introduction..............................3 59 3. Signaling node-ids in RROs................5 60 4. Finding Merge Points......................6 61 5. Security Considerations...................6 62 6. IANA Considerations.......................6 63 7. Intellectual Property Considerations......6 64 8. Acknowlegments............................7 65 9. References................................7 66 9.1 Normative References.....................7 67 9.2 Informative References...................7 68 10. Authors' addresses.......................8 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC-2119 [i]. 76 1. Terminology 78 ABR Routers: border routers used to connect two IGP areas (areas in 79 OSPF or levels in IS-IS) 81 ASBR Routers: border routers used to connect to another AS of a 82 different or the same Service Provider via one or more links inter- 83 connecting between ASs. 85 Backup Tunnel: the LSP that is used to backup up one of the many LSPs 86 in many-to-one backup. 88 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 90 Inter-area TE LSP: A TE LSP that crosses an IGP area. 92 LSR: Label Switching Router 94 LSP: Label Switched Path 96 Local Repair: techniques used to repair LSP tunnels quickly when a node 97 or link along the LSPs path fails. 99 PCE: Path Computation Element: an entity (component, application or 101 Vasseur, Ali and Sivabalan 2 102 network node) that is capable of computing a network path or route 103 based on a network graph and applying computational constraints. 105 MP: Merge Point. The LSR where one or more backup tunnels rejoin the 106 path of the protected LSP downstream of the potential failure. 108 Protected LSP: an LSP is said to be protected at a given hop if it has 109 one or multiple associated backup tunnels originating at that hop. 111 PLR: Point of Local Repair. The head-end of a backup tunnel. 113 Reroutable LSP: Any LSP for with the "Local protection desired" bit is 114 set in the Flag field of the SESSION_ATTRIBUTE object of its Path 115 messages. 117 TE LSP: Traffic Engineering Label Switched Path 119 2. Introduction 121 MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local 122 protection technique used to protect Traffic Engineering LSPs from 123 link/SRLG/node failure. One or more backup tunnels are pre-established 124 to protect against the failure of a link/node/SRLG. In case of failure, 125 every protected TE LSP traversing the failed resource is rerouted onto 126 the appropriate backup tunnels. 128 There are several requirements on the backup tunnel path that must be 129 satisfied. First, the backup tunnel must not traverse the element that 130 it protects. Additionally, a primary tunnel and its associated backup 131 tunnel should intersect at least at two points (nodes): Point of Local 132 Repair (PLR) and Merge Point (MP). The former is the Head-end LSR of 133 the backup tunnel and the latter is the Tail-end LSR of the backup 134 tunnel. The PLR is where FRR is triggered when link/node/SRLG failure 135 happens. 137 There are different methods for computing paths for backup tunnels at a 138 given PLR. Specifically, a user can statically configure one or more 139 backup tunnels at the PLR with an explicitly configured path or the PLR 140 can be configured to automatically compute a backup path or to send a 141 path computation request to a PCE (see [PCE-ARCH]). 143 Consider the following scenario (figure 1) 145 Assumptions: 146 - A multi-area network made of three areas: 0, 1 and 2, 147 - A fast reroutable TE LSP T1 (TE LSP signaled with the "local 148 Protection desired" bit set in the SESSION-ATTRIBUTE object or the 149 FAST-REROUTE object) from R0 to R3, 150 - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following 151 the R1-ABR3-R2 path. 153 Vasseur, Ali and Sivabalan 3 154 - The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the 155 backup tunnel B1 in case of ABR1's failure. 157 <--- area 1 --><---area 0---><---area 2---> 158 R0-----R1-ABR1--R2------ABR2--------R3 159 \ / 160 \ / 161 ABR3 163 Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR 164 failure with MPLS Traffic Engineering Fast Reroute 166 When T1 is first signaled, the PLR R1 needs to dynamically select an 167 appropriate backup tunnel intersecting T1 on a downstream LSR. However, 168 existing protocol mechanisms are not sufficient to unambiguously find 169 the MP address in a network with inter-domain TE LSP. This document 170 addresses these limitations. 172 R1 needs to select an existing backup tunnel with the following 173 properties: 175 1. The backup tunnel intersects with the primary tunnel at the MP. 176 For the sake of illustration, in Figure 1, R1 needs to determine 177 that T1 and B1 intersect at the node R2. 179 2. The backup tunnel satisfies the primary LSP's request with 180 respect to the bandwidth protection request (i.e., bandwidth 181 guaranteed for the primary tunnel during failure), and the type 182 of protection (link or node failure), as specified in [FAST- 183 REROUTE]. 185 One technique for the PLR to ensure that condition (1) is met consists 186 of examining the Record Route Object (RRO) of the primary tunnel to see 187 if any of the addresses specified in the RRO corresponds to the MP. 188 That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or 189 IPv6 sub-objects sent in Resv messages can be node-ids and/or interface 190 addresses. Hence, in Figure 1, router R2 may specify interface 191 addresses in the RROs for T1 and B1. Note that these interface 192 addresses are different in this example. 194 The problem of finding the MP using the interface addresses or node-ids 195 can be easily solved in the case of a single IGP area. Specifically, in 196 the case of a single IGP area, the PLR has the knowledge of all the 197 interfaces attached to the tail-end of the backup tunnel. This 198 information is available in PLR's IGP topology database. Thus, the PLR 199 can unambiguously determine whether a backup tunnel intersecting a 200 protected TE LSP on a downstream node exists and can also find the MP 201 address regardless of how the addresses carried in the RRO IPv4 or IPv6 202 sub-objects are specified (i.e., whether using the interface addresses 203 or the node-ids). However, such routing information is not available in 204 the case of inter-domain environments. Hence, unambiguously making sure 206 Vasseur, Ali and Sivabalan 4 207 that condition (1) above is met in the case of inter-domain TE LSPs is 208 not possible with existing mechanisms. 210 In this document, we define extensions to and describe the use of RSVP 211 [RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the 212 requirement for the support of the fast recovery technique specified in 213 [FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER- 214 AREA-TE-REQS] and [INTER-AREA-TE-REQS]. 216 3. Signaling node-ids in RROs 218 As mentioned above, the limitation that we need to address is the 219 generality of the contents of the RRO IPv4 and IPv6 sub-objects, as 220 defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub- 221 objects. Moreover, two additional flags are defined in [FAST-REROUTE]: 222 the "Local Protection Available" and "Local protection in use" bits. 224 In this document, we define the following new flag: 226 Node-id: 0x20 228 When set, this indicates that the address specified in the 229 RRO's IPv4 or IPv6 subobject is a node-id address, which refers 230 to the "Router Address" as defined in [OSPF-TE], or "Traffic 231 Engineering Router ID" as defined in [ISIS-TE]. A node MUST use 232 the same address consistently. Once an address is used in RRO's 233 IPv4 or IPv6 subobject, it SHOULD always be used for the 234 lifetime of the LSP. 236 An IPv4 or IPv6 RRO subobject with the node-id flag set is also called 237 a node-id subobject. The problem of finding a MP address in a network 238 with inter-domain TE LSP is solved by inserting a node-id subobject (an 239 RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO 240 object carried in the RSVP Resv message. 242 An implementation may either decide to: 244 1) Add the node-id subobject in the RRO carried in an RSVP Resv message 245 and, when required, also add another IPv4/IPv6 subobject to record 246 interface address. 248 Example: an inter-domain fast reroutable TE LSP would have in the RRO 249 carried in Resv message two sub-objects: a node-id subobject and a 250 label sub-object. If recording the interface address is required, then 251 an additional IPv4/IPv6 subobject is added. 253 2) Add an IPv4/IPv6 sub-object recording the interface address and, 254 when required, add a node-id subobject in the RRO. 256 Example: an inter-domain fast reroutable TE LSP would have in the RRO 257 carried in Resv message three sub-objects: an IPv4/IPv6 sub-object 259 Vasseur, Ali and Sivabalan 5 260 recording interface address, a label sub-object and a node-id sub- 261 object. 263 Note also that the node-id sub-object may have other application than 264 Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that 265 an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also 266 set the Node-id flag. 268 4. Finding Merge Point 270 Two cases should be considered: 272 - Case 1: the backup tunnel destination is the MP's node-id. Then a PLR 273 can find the MP and suitable backup tunnel by simply comparing the 274 backup tunnel's destination address with the node-id included in the 275 RRO of the primary tunnel. 276 - Case 2: the backup tunnel terminates at an address different than the 277 MP's node-id. Then a node-id subobject MUST also be included in the RRO 278 object of the backup tunnel. A PLR can find the MP and suitable backup 279 tunnel by simply comparing the node-ids present in the RRO objects of 280 both the primary and backup tunnels. 282 It must be noted that although the technique described in this document 283 for selecting an appropriate backup tunnel using the node-id sub-object 284 applies to the case of Inter-area and Inter-AS, in the case of Inter- 285 AS, the assumption is made that the MP's node-id (of the downstream 286 domain) does not overlap with any LSR's node-id present in the PLR's 287 AS. 289 When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR 290 may use any or both of them in finding the MP address. 292 5. Security Considerations 294 This document does not introduce new security issues. The security 295 considerations pertaining to [RSVP] and [RSVP-TE] remain relevant. 297 6. IANA considerations 299 This document does not make any request for IANA action. 301 7. Intellectual Property Considerations 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has made 308 any independent effort to identify any such rights. Information on the 309 procedures with respect to rights in RFC documents can be found in BCP 310 78 and BCP 79. 312 Vasseur, Ali and Sivabalan 6 313 Copies of IPR disclosures made to the IETF Secretariat and any 314 assurances of licenses to be made available, or the result of an 315 attempt made to obtain a general license or permission for the use of 316 such proprietary rights by implementers or users of this specification 317 can be obtained from the IETF on-line IPR repository at 318 http://www.ietf.org/ipr. 320 The IETF invites any interested party to bring to its attention any 321 copyrights, patents or patent applications, or other proprietary rights 322 that may cover technology that may be required to implement this 323 standard. Please address the information to the IETF at ietf- 324 ipr@ietf.org. 326 8. Acknowledgments 328 We would like to acknowledge input and helpful comments from Carol 329 Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews. A 330 special thank to Adrian Farrel for his thorough review of this 331 document. 333 9. References 335 9.1 Normative References 337 [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 341 1, Functional Specification", RFC 2205, September 1997. 343 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 344 3209, December 2001. 346 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for 347 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. RFC 4090, 348 May 2005. 350 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF 351 Version 2", RFC3630. 353 [ISIS-TE] Smit et al., "Intermediate System to Intermediate System (IS- 354 IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for 355 Traffic Engineering", RFC3784. 357 9.2 Informative references 359 [INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., "Requirements for 360 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 362 Vasseur, Ali and Sivabalan 7 363 [INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic 364 Engineering requirements", RFC 4216, November 2005. 366 [PCE-ARCH] Farrel, A., Vasseur JP., Ash J., "Path Computation Element 367 (PCE) Architecture", draft-ietf-pce-architecture, work in progress. 369 10. Authors' Addresses 371 J.-P Vasseur (Editor) 372 Cisco Systems, Inc. 373 1414 Massachusetts Avenue 374 Boxborough , MA - 01719 375 USA 376 Email: jpv@cisco.com 378 Zafar Ali 379 Cisco Systems, Inc. 380 100 South Main St. #200 381 Ann Arbor, MI 48104 382 USA 383 zali@cisco.com 385 Siva Sivabalan 386 Cisco Systems, Inc. 387 2000 Innovation Drive 388 Kanata, Ontario, K2K 3E8 389 Canada 390 msiva@cisco.com 392 Full Copyright Statement 394 Full Copyright Statement 396 Copyright (C) The Internet Society (2005). This document is subject to 397 the rights, licenses and restrictions contained in BCP 78, and except 398 as set forth therein, the authors retain all their rights. 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 403 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 404 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 405 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Vasseur, Ali and Sivabalan 8