idnits 2.17.1 draft-lee-ccamp-rsvp-te-exclude-route-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RSVP-TE], [GMPLS-RSVP-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 2002) is 8017 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) == Missing Reference: 'TBD' is mentioned on line 287, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'MPLS-UNNUM' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SIG' is defined on line 439, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 -- Possible downref: Normative reference to a draft: ref. 'IPO-SRLG' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C.Y Lee 2 Internet Draft A. Farrel 3 Expiration Date: November 2002 4 May 2002 6 Exclude Routes - Extension to RSVP-TE 8 draft-lee-ccamp-rsvp-te-exclude-route-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 33 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 34 included in a path setup, but not to be explicitly excluded. 36 In some systems where precise explicit paths are not computed at the 37 head end it may be useful to specify and signal abstract nodes and 38 resources that are to be explicitly excluded from routes. These 39 exclusions may apply to the whole of a path, or to parts of a path 40 between two abstract nodes specified in an explicit route. 42 Shared Risk Link Groups (SRLGs) allow the definition of resources or 43 groups of resources that share the same risk of failure. The 44 knowledge of SRLGs may be used to compute diverse paths that can be 45 used for protection. In systems where it is useful to signal 46 exclusions, it may be useful to signal SRLGs to indicate groups of 47 resources that should be excluded on the whole of a path or between 48 two abstract nodes specified in an explicit path. 50 This draft specifies ways to communicate route exclusions during path 51 setup using RSVP-TE. 53 These approaches are equally applicable to other MPLS TE signaling 54 protocols such as CR-LDP. 56 3. Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in [RFC2119]. 62 4. Overview 64 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 65 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 66 included in a path setup, using the Explicit Route Object (ERO). 68 In some systems it may be useful to specify and signal abstract nodes 69 and resources that are to be explicitly excluded from routes. 71 Two types of exclusions are required: 73 i) Do not include any of the abstract nodes in a given set anywhere 74 on the path. This set of abstract nodes to exclude is referred 75 to as the Exclude Route list. 77 ii) Do not include certain abstract nodes or resources between a 78 specific pair of abstract nodes present in an ERO. Such specific 79 exclusions are referred to as Explicit Route Exclusions. 81 A new RSVP-TE object is introduced to convey the Exclude Route list. 82 This object is the Exclude Route Object (XRO). 84 The second type of exclusion is achieved through a modification to 85 the existing ERO. A new subobject type (the Exclude Route Subobject) 86 is introduced to indicate an exclusion between a pair of included 87 abstract nodes. 89 At the same time, it is recognized that SRLGs are a useful means of 90 indicating resources that share the same risk of failure. When 91 establishing protection LSPs they are often required to be node and 92 link diverse from the LSPs that they protect. Further, where SRLGs 93 are known, the protection LSPs are required to not utilize resources 94 in the SRLGs traversed by the protected LSPs. 96 This draft introduces an ERO subobject to indicate an SRLG to be 97 signaled in either of the two exclusion methods described above. This 98 subobject might also be appropriate for use within Explicit Routes, 99 but that discussion is outside the scope of this draft. 101 5. Shared Risk Link Groups 103 The identifier of a SRLG is defined as a 32 bit quantity in 104 [GMPLS-OSPF]. These 32 bits are divided into an 8 bit type field 105 and a 24 bit identifier in [IPO-SRLG]. 107 5.1 SRLG ERO Subobject 109 The format of the ERO and its subobjects are defined in [RSVP-TE]. 111 The SRLG subobject is defined as follows. 113 0 1 2 3 114 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 |L| Type | Length | Tolerance | Reserved | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | SRLG Id | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 L 123 The L bit is an attribute of the subobject. The L bit is set 124 if the subobject represents a loose hop in the explicit route. 125 If the bit is not set, the subobject represents a strict hop in 126 the explicit route. 128 For exclusions, the L bit SHOULD be set to zero and ignored. 130 Type 132 The type of the subobject [TBD]. 134 Length 136 The Length contains the total length of the subobject in bytes, 137 including the Type and Length fields. The Length is always 8. 139 Tolerance 141 The level to which it is permissible for this SRLG to be 142 included in the path when more than one SRLG is specified. 143 A value of zero indicates that this SRLG MUST be avoided. A 144 tolerance value of n < m indicates that the SRLG MUST be 145 avoided in preference to an SRLG with tolerance value m. 147 If only one SRLG is present, then a value other than zero 148 indicates the SRLG SHOULD be avoided. 150 SRLG Id 152 The 32 bit identifier of the SRLG. 154 5.2 Exclusion Tolerance Semantics 156 The Tolerance field in the SRLG subobject indicates the degree to 157 which the SRLG must be avoided. (The degree to which it is 158 permissible to include it.) 160 If the Tolerance field has the value zero (0), the LSP MUST NOT 161 traverse or use any resource that is a member of the SRLG. 163 If the value is non-zero, all path computation elements SHOULD 164 attempt to select routes that avoid all resources that are members of 165 the SRLG. 167 Where more than one SRLG with non-zero Tolerance value is specified 168 for exclusion and no route can be found that avoids both SRLGs, a 169 route SHOULD be chosen that avoids the SRLG with the lower Tolerance 170 value. 172 6. Exclude Route List 174 The exclude route identifies a list of abstract nodes that MUST NOT 175 be traversed along the path. 177 6.1 Exclude Route Object 179 Abstract nodes to be excluded from the path are specified via the 180 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 182 Currently one C_Type is defined, Type 1 Exclude Route. The 183 EXCLUDE_ROUTE object has the following format: 185 Class = TBD, C_Type = 1 187 0 1 2 3 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 // (Subobjects) // 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Subobjects 197 The contents of an EXCLUDE_ROUTE object are a series of variable- 198 length data items called subobjects. The subobjects are identical 199 to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. 201 The following subobject types are supported. 203 1 IPv4 prefix 204 2 IPv6 prefix 205 32 Autonomous system number 206 TBD SRLG 208 The defined values for Type above are specified in [RSVP-TE] 209 and in this document. 211 The L bit that denotes a loose hop when the subobject is used in 212 the ERO has no meaning in the XRO and should be ignored. 214 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 216 The exclude route list is encoded as a series of subobjects contained 217 in an EXCLUDE_ROUTE object. Each subobject identifies an abstract 218 node in the exclude route list. 220 Each abstract node may be a precisely specified IP address of a 221 single node, an IP address with prefix identifying a group of nodes, 222 or an Autonomous System. 224 The Explicit Route and routing processing is unchanged from the 225 description in [RSVP-TE] with the following additions: 227 a. When a Path message is received at a node, the node must check 228 that it is not a member of any of the abstract nodes in the XRO 229 if it is present in the Path message. If the node is a member 230 of any of the abstract nodes in the XRO it should return a PathErr 231 with the error code "Routing Problem" and error value of "Local 232 node in Exclude Route". 233 If there are SRLGs in the XRO, the node should check that it and 234 the resources it uses are not part of any SRLG that is specified 235 with Tolerance value of zero. If it is, it should return a 236 PathErr with the error code "Routing Problem" and error value of 237 "Local node in Exclude Route". 238 The node may be a member of an SRLG in the XRO that is specified 239 with a non-zero Tolerance value. 241 b. When choosing a next hop or expanding an explicit route to include 242 additional subobjects, a node: 243 i) must not introduce an explicit node or an abstract node that 244 equals or is a member of any abstract node that is specified 245 in the Exclude Route Object. 246 ii) must not (or should not, in the case of a non-zero Tolerance 247 value) introduce links, nodes or resources identified by the 248 SRLG ID specified in the SRLG subobjects(s). 249 If these rules preclude further forwarding of the Path message, 250 the node should return a PathErr with the error code "Routing 251 Problem" and error value of "Route blocked by Exclude Route". 253 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 254 support the XRO will forward it uninspected and will not apply the 255 extensions to ERO processing described above. This makes the XRO 256 a 'best effort' process. 258 This 'best-effort' approach is chosen to allow route exclusion to 259 traverse parts of the network that are not capable of parsing or 260 handling the new function. Note that Record Route may be used to 261 allow computing nodes to observe violations of route exclusion and 262 attempt to re-route the LSP accordingly. 264 7. Explicit Route Exclusions 266 Explicit Route Exclusions define abstract nodes or resources (such 267 as links, unnumbered interfaces or labels) that must not be used 268 on the path between two inclusive abstract nodes or resources in the 269 explicit route. 271 7.1. Exclude Object Subobject 273 A new subobject type is defined. The Exclude Object Subobject has 274 type [TBD]. 276 The format of the Exclude Object Subobject is as follows. 278 0 1 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 281 |L| Type | Length | Exclude subobject contents | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 284 L (ignored, must be 0) 286 Type 287 The type of the subobject [TBD] 289 Exclude subobject contents 290 An ERO subobject indicating the abstract node or resource to 291 be excluded. The format of this field is exactly the format of 292 an ERO subobject contained in an ERO and may include an SRLG 293 subobject as described earlier in this draft. 295 Thus, an exclude subobject for an IP hop might look as follows: 297 0 1 2 3 298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |L| Type | Length |R| Type | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | IPv4 address (4 bytes) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Prefix Length | Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 R is reserved and must be zero 309 7.2. Semantics and Processing Rules for the Exclude Object Subobject 311 Each Exclude Object Subobject carries a single exclusion. The 312 exclusion is encoded exactly as an inclusion in the ERO and prefixed 313 by an additional Type and Length. 315 The scope of the exclusion is the step between the previous ERO 316 subobject that identifies an abstract node, and the subsequent 317 ERO subobject that identifies an abstract node. Multiple exclusions 318 may be present between any pair of abstract nodes. 320 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 321 Systems that must not be traversed on the path to the next abstract 322 node indicated in the ERO. 324 Exclusions may also indicate resources (such as unnumbered 325 interfaces, link ids, labels) that must not be used on the path to 326 the next abstract node indicated in the ERO. 328 SRLGs may also be indicated for exclusion from the path to the next 329 abstract node in the ERO by the inclusion of an Exclude Object 330 Subobject containing an SRLG subobject. If the Tolerance value in 331 the SRLG subobject is zero, the resources (nodes, links, etc.) 332 identified by the SRLG must not be used on the path to the next 333 abstract node indicated in the ERO. If the Tolerance value is non- 334 zero, the resources identified by the SRLG should be avoided, but may 335 be used in preference to resources associated with another SRLG 336 indicated for exclusion if that SRLG has a (numerically) lower 337 Tolerance value. 339 If a node is called upon to process an Exclude Object Subobject and 340 does not support handling of exclusions it will return a PathErr 341 with a "Bad EXPLICIT_ROUTE object" error. 343 If the presence of Exclude Object Subobjects precludes further 344 forwarding of the Path message, the node should return a PathErr with 345 the error code "Routing Problem" and error value of "Route blocked by 346 Exclude Route". 348 8. Security 350 The new exclude route object poses no security exposures over and 351 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security concerns 352 that exist with Explicit Routes should be considered with regard to 353 route exclusions. 355 9. IANA Considerations 357 9.1. New Class Numbers 359 One new class number is required. 361 EXCLUDE_ROUTE 362 Class-Num = 011bbbbb 363 CType: 1 365 9.2. Explicit Route Subobject Types 367 Two new subobject types for the Explicit Route Object are required. 369 SRLG subobject 370 Exclude object subobject 372 9.3. New Error Codes 374 New error values are needed for the error code 'Routing Problem'. 376 Unsupported Exclude Route Subobject Type 377 Local node in Exclude Route 378 Route blocked by Exclude Route 380 10. Acknowledgments 382 This draft reuses text from [RSVP-TE] for the description of 383 EXCLUDE_ROUTE. 385 The authors would like to express their thanks to Igor Bryskin, 386 Lou Berger and Stefaan de Cnodder for their considered opinions on 387 this draft. Also thanks to Yakov Rekhter for reminding us about 388 SRLGs. 390 11. Authors' Information 392 Cheng-Yin Lee 393 600 March Road 394 Ottawa, Ontario 395 Canada K2K 2E6 396 email: Cheng-Yin.Lee@alcatel.com 398 Adrian Farrel 399 Movaz Networks, Inc. 400 7926 Jones Branch Drive, Suite 615 401 McLean VA, 22102 USA 402 Phone: +1-703-847-1867 403 Email: afarrel@movaz.com 405 12. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997 410 [RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP 411 for LSP Tunnels", RFC 3209, December 2001. 413 [GMPLS-RSVP-TE] P. Ashwood-Smith, et al., "Generalized MPLS 414 Signaling - RSVP-TE Extensions", Internet Draft, 415 draft-ietf-mpls-generalized-rsvp-te-07.txt, 416 April 2002 (work in progress). 418 [GMPLS-OSPF] K. Kompela, et al., "OSPF Extensions in Support of 419 Generalized MPLS", Internet Draft, 420 draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, 421 May 2002 (work in progress). 423 [IPO-SRLG] D. Papadimitriou, et al., "Inference of Shared Risk 424 Link Groups", Internet Draft, draft-many-inference- 425 srlg-02.txt, November 2001 (work in progress). 427 13. Informational References 429 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 430 "Link Bundling in MPLS Traffic Engineering", 431 Internet Draft, draft-ietf-mpls-bundle-02.txt, 432 May 2002, (work in progress). 434 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 435 Links in RSVP-TE", Internet Draft, 436 draft-ietf-mpls-rsvp-unnum-06.txt, May 2002, (work 437 in progress). 439 [GMPLS-SIG] P. Ashwood-Smith, et al, "Generalized MPLS - 440 Signaling Functional Description", 441 draft-ietf-mpls-generalized-signaling-08.txt 442 April 2002, (work in progress). 444 14. Full Copyright Statement 446 Copyright (C) The Internet Society (2002). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it 450 or assist in its implementation may be prepared, copied, published 451 and distributed, in whole or in part, without restriction of any 452 kind, provided that the above copyright notice and this paragraph 453 are included on all such copies and derivative works. However, this 454 document itself may not be modified in any way, such as by removing 455 the copyright notice or references to the Internet Society or other 456 Internet organizations, except as needed for the purpose of 457 developing Internet standards in which case the procedures for 458 copyrights defined in the Internet Standards process must be 459 followed, or as required to translate it into languages other than 460 English. 462 The limited permissions granted above are perpetual and will not be 463 revoked by the Internet Society or its successors or assigns. This 464 document and the information contained herein is provided on an "AS 465 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 466 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 467 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 468 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 469 OR FITNESS FOR A PARTICULAR PURPOSE.