idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages 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. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: c. The subobjects in the ERO and XRO SHOULD not contradict each other. If they do contradict, the subobjects with the L flag not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take precedence. If there is still a conflict, a PathErr with error code "Routing Problem" and error value of "Route blocked by Exclude Route" should be returned. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The subobjects in the ERO and EXRS SHOULD not contradict each other. If they do contradict, the subobjects with the L bit not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take pre-cedence. If there is still a conflict, the subobjects in the ERO MUST take precedence. -- 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 (December 2003) is 7436 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 654, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 299, but not defined == Missing Reference: 'RFC-2026' is mentioned on line 668, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'MPLS-UNNUM' is defined on line 727, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-09 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-02) exists of draft-papadimitriou-ccamp-srlg-processing-01 == Outdated reference: A later version (-01) exists of draft-decnodder-mpls-interas-protection-00 -- No information found for draft-ccamp-gmpls-overlay - is the name correct? == Outdated reference: A later version (-07) exists of draft-iwata-mpls-crankback-05 Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group CY Lee 3 Internet Draft A. Farrel 4 Expiration Date: June 2004 S. De Cnodder 5 December 2003 7 Exclude Routes - Extension to RSVP-TE 8 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 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 2. Abstract 30 The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for 31 LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 32 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 33 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 34 abstract nodes and resources to be explicitly included in a path 35 setup, but not to be explicitly excluded. 37 In some networks where precise explicit paths are not computed at the 38 head end it may be useful to specify and signal abstract nodes and 39 resources that are to be explicitly excluded from routes. These 40 exclusions may apply to the whole path, or to parts of a path between 41 two abstract nodes specified in an explicit path. How Shared Risk 42 Link Groups (SLRGs) can be excluded is also specified in this 43 document. 45 This document specifies ways to communicate route exclusions during 46 path setup using RSVP-TE. 48 2.1 Future Work 50 Future work on this document may include the following. 52 - Exclusion of unnumbered links. 54 - Line up with LSP attribute. This could mean that EXRS has to be 55 revised. 57 - Convergence of SRLG identification with formats defined in other 58 drafts. 60 - Update MIB section. 62 2.2 Changes compared to version 00 64 - This section is added. 66 - Tolerance field in SRLG subobject is removed. 68 - References updated. 70 - Editorial updates. 72 - XRO processing rules further detailed. 74 - Recommendation added to limit the size of the exlude route list to 75 a value local to the node originating the exclude route list. 77 - Section added with minimum compliance statement. 79 - Acknowledgements updated. 81 - IPR section. 83 - Appendix A with applications is added. 85 3. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 4. Overview 93 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 94 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 95 included in a path setup, using the Explicit Route Object (ERO). 97 In some systems it may be useful to specify and signal abstract nodes 98 and resources that are to be explicitly excluded from routes. This 99 may be because loose hops or abstract nodes need to be prevented from 100 selecting a route through a specific resource. This is a special case 101 of distributed path calculation in the network. 103 Two types of exclusions are required: 105 i) Exclude any of the abstract nodes in a given set anywhere on the 106 path. This set of abstract nodes is referred to as the Exclude 107 Route list. 109 ii) Exclude certain abstract nodes or resources between a specific 110 pair of abstract nodes present in an ERO. Such specific exclu- 111 sions are referred to as Explicit Exclusion Route. 113 To convey these constructs within the signaling protocol, a new RSVP 114 object and a new ERO subobject are introcuded respectively. 116 i) A new RSVP-TE object is introduced to convey the Exclude Route 117 list. This object is the Exclude Route Object (XRO). 119 ii) The second type of exclusion is achieved through a modification 120 to the existing ERO. A new subobject type the Explicit Exclude 121 Route Subobject (EXRS) is introduced to indicate an exclusion 122 between a pair of included abstract nodes. 124 SRLGs allow the definition of resources or groups of resources that 125 share the same risk of failure. The knowledge of SRLGs may be used 126 to compute diverse paths that can be used for protection. In systems 127 where it is useful to signal exclusions, it may be useful to signal 128 SRLGs to indicate groups of resources that should be excluded on the 129 whole of a path or between two abstract nodes specified in an expli- 130 cit path. 132 This document introduces an ERO subobject to indicate an SRLG to be 133 signaled in either of the two exclusion methods described above. This 134 subobject might also be appropriate for use within Explicit Routes or 135 Record Routes, but that discussion is outside the scope of this docu- 136 ment. 138 4.1 Scope of Exclude Routes 140 This document does not preclude a route exclusion from listing many 141 nodes or network elements to avoid. The intent is, however, to indi- 142 cate only the minimal number of subobjects to be avoided. For 143 instance it may be necessary to signal only the SRLGs (or Shared 144 Risk Groups) to avoid. 146 It is envisaged that most of the conventional inclusion subobjects 147 are specified in the signaled ERO only for the area where they are 148 pertinent. The number of subobjects to be avoided, specified in the 149 signaled XRO may be constant throughout the whole path setup, or the 150 subobjects to be avoided may be removed from the XRO as they become 151 irrelevant in the subsequent hops of the path setup. 153 For example, consider an LSP that traverses multiple computation 154 domains. A computation domain may be an area in the administrative 155 or IGP sense, or may be an arbitrary division of the network for 156 active management and path computational purposes. Let the primary 157 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: 159 - Xn denotes a node in domain X, and 161 - XYn denotes a node on the border of domain X and domain Y. 163 Note that Ingress is a node in domain A, and Egress is a node in 164 domain C. This is shown in Figure 1 where the domains correspond with 165 areas. 167 area A area B area C 168 <-------------------> <----------------> <------------------> 170 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress 171 ^ \ / | \ / | \ / 172 | \ / | \ / | \ / 173 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4 174 | ^ ^ 175 | | | 176 | | ERO: (C3-strict, C4-strict, 177 | | Egress-strict) 178 | | XRO: Not needed 179 | | 180 | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) 181 | XRO: (C1, C2) 182 | 183 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) 184 XRO: (B1, B2, BC1, C1, C2, Egress) 186 Consider the establishment of a node-diverse protection path in the 187 example above. The protection path must avoid all nodes on the pri- 188 mary path. The exclusions for area A are handled during Constrained 189 Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO 190 signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, 191 Egress-loose) and (B1, B2, BC1, C1, C2) respectively. At AB2 the ERO 192 and XRO could be (B3-strict, B4-strict, BC2-strict, Egress-loose) and 193 (C1,C2) respectively. At BC2 the ERO could be (C3-strict, C4-strict, 194 Egress-strict) and an XRO is not needed from BC2 onwards. 196 In general, consideration should be given (as with explicit route) to 197 the size of signaled data and the impact on the signaling protocol. 199 4.2 Relationship to MPLS TE MIB 201 [MPLS-TE-MIB] defines managed objects for managing and modeling 202 MPLS-based traffic engineering. Included in [MPLS-TE-MIB] is a means 203 to configure explicit routes for use on specific LSPs. This confi- 204 guration allows the exclusion of certain resources. 206 In systems where the full explicit path is not computed at the 207 ingress (or at a path computation site for use at the ingress) it may 208 be necessary to signal those exclusions. This document offers a means 209 of doing this signaling. 211 5. Shared Risk Link Groups 213 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 214 OSPF]. These 32 bits are divided into an 8 bit type field and a 24 215 bit identifier in [CCAMP-SRLG]. 217 5.1 SRLG ERO Subobject 219 The format of the ERO and its subobjects are defined in [RSVP-TE]. 220 The new SRLG subobject is defined by this document as follows. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |L| Type | Length | SRLG Id (4 bytes) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | SRLG Id (continued) | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 L 232 The L bit is an attribute of the subobject. The L bit is set 233 if the subobject represents a loose hop in the explicit route. 234 If the bit is not set, the subobject represents a strict hop in 235 the explicit route. 237 For exclusions, the L bit SHOULD be set to zero and ignored. 239 Type 241 The type of the subobject [TBD]. 243 Length 245 The Length contains the total length of the subobject in bytes, 246 including the Type and Length fields. The Length is always 8. 248 SRLG Id 250 The 32 bit identifier of the SRLG. 252 Reserved 254 Zero on transmission. Ignored on receipt 256 6. Exclude Route List 258 The exclude route identifies a list of abstract nodes that MUST NOT 259 be traversed along the path of the LSP being established. It is 260 RECOMMENDED to limit size of the exlude route list to a value local 261 to the node originating the exclude route list. 263 6.1 Exclude Route Object (XRO) 265 Abstract nodes to be excluded from the path are specified via the 266 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 268 Currently one C_Type is defined, Type 1 Exclude Route. The 269 EXCLUDE_ROUTE object has the following format: 271 Class = TBD, C_Type = 1 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 // (Subobjects) // 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Subobjects 283 The contents of an EXCLUDE_ROUTE object are a series of variable- 284 length data items called subobjects. The subobjects are identical 285 to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. 287 The following subobject types are supported. 289 Type Subobject 290 1 IPv4 prefix 291 2 IPv6 prefix 292 32 Autonomous system number 293 TBD SRLG 295 The defined values for Type above are specified in [RSVP-TE] and 296 in this document. 298 The concept of loose or strict hops has no meaning in route exclu- 299 sion. The L bit, defined for ERO subobjects in [RSPV-TE], is re- 300 used here to indicate that an abstract node MUST be avoided (value 301 0) or SHOULD be avoided (value 1). 303 An Attribute octet is introduced in the subobjects that define IP 304 addresses to indicate the attribute (e.g. interface, node, SRLG) 305 associated with the IP addresses that can be excluded from the 306 path. For instance, the attribute node allows a whole node to be 307 excluded from the path, in contrast to the attribute interface, 308 which allows specific interfaces to be excluded from the path. 309 The attribute SRLG allows all SRLGs associated with an IP address 310 to be excluded from the path. 312 6.1.1 Subobject 1: IPv4 prefix 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |L| Type | Length | IPv4 address (4 bytes) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | IPv4 address (continued) | Prefix Length | Attribute | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 L 323 0 indicates that the attribute specified MUST be excluded 324 1 indicates that the attribute specified SHOULD be avoided 326 Attribute 328 interface 330 0 indicates that the interface or set of interfaces associ- 331 ated with the IP prefix should be excluded or avoided 333 node 335 1 indicates that the node or set of nodes associated with the 336 IP prefix should be excluded or avoided 338 SRLG 340 2 indicates that all the SRLGs associated with the IP prefix 341 should be excluded or avoided 343 Resvd 344 Zero on transmission. Ignored on receipt. 346 The rest of the fields are as defined in [RSVP-TE]. 348 6.1.2 Subobject 2: IPv6 Prefix 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |L| Type | Length | IPv6 address (16 bytes) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | IPv6 address (continued) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv6 address (continued) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | IPv6 address (continued) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | IPv6 address (continued) | Prefix Length | Attribute | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 L 365 0 indicates that the abstract node specified MUST be excluded 366 1 indicates that the abstract node specified SHOULD be avoided 368 Attribute 370 interface 372 0 indicates that the interface or set of interfaces associ- 373 ated with the IP prefix should be excluded or avoided 375 node 377 1 indicates that the node or set of nodes associated with the 378 IP prefix should be excluded or avoided 380 SRLG 381 2 indicates that all the SRLG associated with the IP prefix 382 should be excluded or avoided 384 Resvd 385 Zero on transmission. Ignored on receipt. 387 The rest of the fields are as defined in [RSVP-TE]. 389 6.1.3 Subobject 32: Autonomous System Number 391 The L bit of an Autonomous System Number subobject has meaning in 392 an Exclude Route (contrary to its usage in an Explict Route 393 defined in [RSVP-TE]. The meaning is as for other subobjects 394 described above. That is: 396 0 indicates that the abstract node specified MUST be excluded 398 1 indicates that the abstract node specified SHOULD be avoided 400 The rest of the fields are as defined in [RSVP-TE]. There is no 401 Attribute octet defined. 403 6.1.4 Subobject TBD: SRLG 405 The Attribute octet is not present. The rest of the fields are as 406 defined in the "SRLG ERO Subobject" section of this document. 408 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 410 The exclude route list is encoded as a series of subobjects contained 411 in an EXCLUDE_ROUTE object. Each subobject identifies an abstract 412 node in the exclude route list. 414 Each abstract node may be a precisely specified IP address belonging 415 to a node, or an IP address with prefix identifying interfaces of a 416 group of nodes, or an Autonomous System. 418 The Explicit Route and routing processing is unchanged from the 419 description in [RSVP-TE] with the following additions: 421 a. When a Path message is received at a node, the node must check 422 that it is not a member of any of the abstract nodes in the XRO if 423 it is present in the Path message. If the node is a member of any 424 of the abstract nodes in the XRO with the L-flag set to "exclude", 425 it should return a PathErr with the error code "Routing Problem" 426 and error value of "Local node in Exclude Route". If there are 427 SRLGs in the XRO, the node should check that the resources the 428 node uses are not part of any SRLG with the L-flag set to 429 "exclude" that is specified in the XRO. If it is, it should 430 return a PathErr with error code "Routing Problem" and error value 431 of "Local node in Exclude Route". 433 b. Each subobject must be consistent. If a subobject is not con- 434 sistent then the node should return a PathErr with error code 435 "Routing Problem" and error value "Inconsistent Subobject". An 436 example of an inconsistent subobject is an IPv4 Prefix subobject 437 containing the IP address of a node and the attribute field is set 438 to "interface" or "SRLG". 440 c. The subobjects in the ERO and XRO SHOULD not contradict each 441 other. If they do contradict, the subobjects with the L flag not 442 set, strict or MUST be excluded, respectively, in the ERO or XRO 443 MUST take precedence. If there is still a conflict, a PathErr 444 with error code "Routing Problem" and error value of "Route 445 blocked by Exclude Route" should be returned. 447 d. When choosing a next hop or expanding an explicit route to include 448 additional subobjects, a node: 450 i) must not introduce an explicit node or an abstract node that 451 equals or is a member of any abstract node that is specified 452 in the Exclude Route Object with the L-flag set to "exclude". 453 The number of introduced exlicit nodes or abstract nodes with 454 the L flag set to "avoid" should be minimised. 456 ii) must not introduce links, nodes or resources identified by the 457 SRLG Id specified in the SRLG subobjects(s). The number of 458 introduced SLRGs with the L flag set to "avoid" should be 459 minimised. 461 If these rules preclude further forwarding of the Path message, 462 the node should return a PathErr with the error code "Routing 463 Problem" and error value of "Route blocked by Exclude Route". 465 Note that the subobjects in the XRO is an unordered list of subob- 466 jects. 468 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 469 support the XRO will forward it uninspected and will not apply the 470 extensions to ERO processing described above. This makes the XRO a 471 'best effort' process. 473 This 'best-effort' approach is chosen to allow route exclusion to 474 traverse parts of the network that are not capable of parsing or han- 475 dling the new function. Note that Record Route may be used to allow 476 computing nodes to observe violations of route exclusion and attempt 477 to re-route the LSP accordingly. 479 If a node supports the XRO, but not a particular subobject or part of 480 that subobject, then that particular subobject is ignored. Examples 481 of a part of a subobject that can be supported are: (1) only prefix 482 32 of the IPv4 prefix subobject could be supported, or (2) a particu- 483 lar subobject is supported but not the particular attribute field. 485 When a node forwards a Path message, it can do the following three 486 operations related to XRO besides of the processing rules mentioned 487 above: 489 1. If no XRO was present, an XRO may be included. 491 2. If an XRO was present, it may remove the XRO if it is sure that 492 the next nodes do not need this information anymore. An example is 493 where a node can expand the ERO to a full strict path towards the 494 destination. See Figure 1 where BC2 is removing the XRO from the 495 Path message. 497 3. If an XRO was present, the content of the XRO can be modified. 498 Subobjects can be added or removed. See Figure 1 for an example 499 where AB2 is stripping off some subobjects. 501 7. Explicit Exclude Route 503 The Explicit Exclude Route defines abstract nodes or resources (such 504 as links, unnumbered interfaces or labels) that must not be used on 505 the path between two inclusive abstract nodes or resources in the 506 explicit route. 508 7.1. Explicit Exclusion Route Subobject (EXRS) 510 A new ERO subobject type is defined. The Explicit Exclude Route 511 Subobject (EXRS) has type [TBD]. The EXRS may not be present in an 512 RRO or XRO. 514 The format of the EXRS is as follows. 516 0 1 517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 519 |L| Type | Length | EXRS subobjects | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 521 L 522 ignored and must be zero 523 [Note: The L bit in an ERES subobject is as defined for the XRO 524 subobjects] 526 Type 527 The type of the subobject, i.e. EXRS [TBD] 529 EXRS subobjects 530 An EXRS subobject indicates the abstract node or resource to be 531 excluded. The format of this field is exactly the format of an 532 XRO subobject and may include an SRLG subobject. Both subob- 533 jects are as described earlier in this document. 535 Thus, an EXRO subobject for an IP hop might look as follows: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |L| Type | Length |L| Type | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | IPv4 address (4 bytes) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Prefix Length | Attribute | Reserved | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Note: The Most Significant Bit in the Type field could be used to 548 indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating 549 the need to prepend the subobject with an additional TLV header. This 550 would reduce the number bytes require for each subobject by 2 bytes. 551 However, this approach would reduce the ERO Type field space by half. 552 This issue need WG discussion and feedback. 554 7.2. Semantics and Processing Rules for the EXRS 556 Each EXRS may carry multiple exclusions. The exclusion is encoded 557 exactly as for XRO subobjects and prefixed by an additional Type and 558 Length. 560 The scope of the exclusion is the step between the previous ERO 561 subobject that identifies an abstract node, and the subsequent ERO 562 subobject that identifies an abstract node. Multiple exclusions may 563 be present between any pair of abstract nodes. 565 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 566 Systems that must not be traversed on the path to the next abstract 567 node indicated in the ERO. 569 Exclusions may also indicate resources (such as unnumbered inter- 570 faces, link ids, labels) that must not be used on the path to the 571 next abstract node indicated in the ERO. 573 SRLGs may also be indicated for exclusion from the path to the next 574 abstract node in the ERO by the inclusion of an EXRO Subobject con- 575 taining an SRLG subobject. If the Tolerance value in the SRLG subob- 576 ject is zero, the resources (nodes, links, etc.) identified by the 577 SRLG must not be used on the path to the next abstract node indicated 578 in the ERO. If the Tolerance value is non- zero, the resources iden- 579 tified by the SRLG should be avoided, but may be used in preference 580 to resources associated with another SRLG indicated for exclusion if 581 that SRLG has a (numerically) lower Tolerance value. 583 The subobjects in the ERO and EXRS SHOULD not contradict each other. 584 If they do contradict, the subobjects with the L bit not set, strict 585 or MUST be excluded, respectively, in the ERO or XRO MUST take pre- 586 cedence. If there is still a conflict, the subobjects in the ERO 587 MUST take precedence. 589 If a node is called upon to process an EXRS and does not support han- 590 dling of exclusions it will return a PathErr with a "Bad 591 EXPLICIT_ROUTE object" error. 593 If the presence of EXRO Subobjects precludes further forwarding of 594 the Path message, the node should return a PathErr with the error 595 code "Routing Problem" and error value of "Route blocked by Exclude 596 Route". 598 8. Minimum compliance 600 An implementation must be at least compliant with the following: 602 A. The XRO MUST be supported with the following restrictions: 604 A.1. The IPv4 Prefix subobject MUST be supported with a prefix length 605 of 32, and an attribute value of "interface" and "node". Other 606 prefix values and attribute values MAY be supported. 608 A.2. The IPv6 Prefix subobject MUST be supported with a prefix length 609 of 128, and an attriubute value of "interface" and "node". Other 610 prefix values and attribute values MAY be supported. 612 B. The EXRS SHOULD be supported. If supported, the same restrictions 613 as for the XRO apply. 615 C. If XRO or EXRS are supported, the implementation MUST be compliant 616 with the processing rules of the supported, not supported, or par- 617 tially supported subobjects as specified within this document. 619 9. Security 621 The new exclude route object poses no security exposures over and 622 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security con- 623 cerns that exist with Explicit Routes should be considered with 624 regard to route exclusions. 626 10. IANA Considerations 628 10.1. New Class Numbers 630 One new class number is required. 632 EXCLUDE_ROUTE 633 Class-Num = 011bbbbb 634 CType: 1 636 10.2. New Subobject Types 638 A new subobject type for the Exclude Route Object and Explicit 639 Exclude Route Subobject is required. 641 SRLG subobject 643 A new subobject type for the ERO is required. 645 Explicit Exclude Route subobject 647 10.3. New Error Codes 649 New error values are needed for the error code 'Routing Problem'. 651 Unsupported Exclude Route Subobject Type [TBD] 652 Inconsistent Subobject [TBD] 653 Local Node in Exclude Route [TBD] 654 Route Blocked by Exclude Route [TBD] 656 11. Acknowledgments 658 This document reuses text from [RSVP-TE] for the description of 659 EXCLUDE_ROUTE. 661 The authors would like to express their thanks to Lou Berger, Steffen 662 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and 663 Richard Rabbat for their considered opinions on this draft. Also 664 thanks to Yakov Rekhter for reminding us about SRLGs! 666 12. Intellectual Property Considerations 668 This section is taken from Section 10.4 of [RFC-2026]. 670 The IETF takes no position regarding the validity or scope of any 671 intellectual property or other rights that might be claimed to per- 672 tain to the implementation or use of the technology described in this 673 document or the extent to which any license under such rights might 674 or might not be available; neither does it represent that it has made 675 any effort to identify any such rights. Information on the IETF's 676 procedures with respect to rights in standards-track and standards- 677 related documentation can be found in BCP-11. Copies of claims of 678 rights made available for publication and any assurances of licenses 679 to be made available, or the result of an attempt made to obtain a 680 general license or permission for the use of such proprietary rights 681 by implementors or users of this specification can be obtained from 682 the IETF Secretariat. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary 686 rights which may cover technology that may be required to practice 687 this standard. Please address the information to the IETF Executive 688 Director. 690 The IETF has been notified of intellectual property rights claimed in 691 regard to some or all of the specification contained in this docu- 692 ment. For more information consult the online list of claimed 693 rights. 695 13. References 697 13.1 Normative References 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, March 1997 702 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP 703 for LSP Tunnels", RFC 3209, December 2001. 705 [GMPLS-RSVP-TE] Berger, L., (Editor), "Generalized Multi-Protocol Label 706 Switching (GMPLS) Signaling Resource ReserVation 707 Protocol-Traffic Engineering (RSVP-TE) Extensions", 708 RFC 3473, January 2003. 710 [GMPLS-OSPF] K. Kompela, Y. Rekhter, (Editors) "OSPF Extensions 711 in Support of Generalized MPLS", Internet Draft, 712 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, 713 October 2003 (work in progress). 715 [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label 716 Switching (MPLS) Traffic Engineering Management 717 Information Base", Internet Draft, draft-ietf-mpls- 718 te-mib-09.txt, November 2002 (work in progress). 720 13.2 Informational References 722 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 723 "Link Bundling in MPLS Traffic Engineering", 724 Internet Draft, draft-ietf-mpls-bundle-04.txt, 725 July 2002, (work in progress). 727 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 728 Links in RSVP-TE", RFC 3477, January 2003. 730 [CCAMP-SRLG] D. Papadimitriou, et al., "Shared Risk Link Groups 731 Encoding and Processing", Internet Draft, 732 draft-papadimitriou-ccamp-srlg-processing-01.txt, 733 November 2002 (work in progress). 735 [INTERAS] De Cnodder, S., Pelsser, C., "Protection for 736 inter-AS MPLS tunnels", Internet Draft, draft- 737 decnodder-mpls-interas-protection-00.txt, February 738 2003, (work in progress). 740 [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y., 741 GMPLS RSVP Support for the Overlay Model", Internet 742 Draft, draft-ccamp-gmpls-overlay-02.txt, October 743 2003, (work in progress). 745 [OSPF-TE] Katz, D., Yeung, D., and Kompella, K., "Traffic 746 Engineering Extensions to OSPF version 2", RFC 3630, 747 September 2003. 749 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 750 Engineering", Internet Draft, draft-ietf-isis- 751 traffic-05.txt, August 2003, (work in progress). 753 [CRANKBACK] Farrel, A., (Editor), "Crankback Routing Extensions 754 for MPLS Signaling", Internet Draft, draft-iwata-mpls- 755 crankback-05.txt, March 2003, (work in progress). 757 14. Authors' Information 758 Cheng-Yin Lee 759 Alcatel 760 600 March Road. 761 Ottawa, Ontario 762 Canada K2K 2E6 763 email: Cheng-Yin.Lee@alcatel.com 765 Adrian Farrel 766 Movaz Networks, Inc. 767 7926 Jones Branch Drive, Suite 615 768 McLean VA, 22102 USA 769 Phone: +1-703-847-1867 770 Email: afarrel@movaz.com 772 Stefaan De Cnodder 773 Alcatel 774 Francis Wellesplein 1 775 B-2018 Antwerp, Belgium 776 email: stefaan.de_cnodder@alcatel.be 778 15. Appendix A: applications 780 This section describes some applications that can make use of the 781 XRO. The intention is to show that the XRO is not an application 782 specific object, but that it can be used for multiple purposes. In a 783 few examples, other solutions might be possible for that particular 784 case but the intention is to show that also a single object can be 785 used for all the examples, hence making the XRO a rather generic 786 object without having to define a solution and new objects for each 787 new application. 789 15.1 Inter-area LSP protection 791 One method to establish an inter-area LSP is where the ingress router 792 selects an ABR, and then the ingress router computes a path towards 793 this selected ABR such that the configured constraints of the LSP are 794 fulfilled. In the example of figure A.1, an LSP has to be established 795 from node A in area 1 to node C in area 2. If no loose hops are con- 796 figured, then the computed ERO at A could looks as follows: (A1- 797 strict, A2-strict, ABR1-strict, C-loose). When the Path message 798 arrives at ABR1, then the ERO is (ABR1-strict, C-loose) and it can be 799 expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similar, at 800 ABR3 the received ERO is (ABR3-strict, C-loose) and it can be 801 expanded to (C1-strict, C2-strict, C-strict). If also a backup LSP 802 has to be established, then A takes another ABR (ABR2 in this case) 803 and computes a path towards this ABR that fulfills the constraints of 804 the LSP and such that is disjoint from the path of the primary LSP. 805 The ERO generated by A looks as follows for this example: (A3-strict, 806 A4-strict, ABR2-strict, C-loose). 808 In order to let ABR2 expand the ERO, it also needs to know the path 809 of the primary LSP to expand the ERO such that it is disjoint from 810 the path of the primary LSP. Therefore, A also includes an XRO that 811 at least contains (ABR1, B1, ABR3, C1, C2). Based on these con- 812 straints, ABR2 can expand the ERO such that it is disjoint from the 813 primary LSP. In this example, the ERO computed by ABR2 would be (B2- 814 strict, ABR4-strict, C-loose), and the XRO generated by B contains at 815 least (ABR3, C1, C2). The latter information is needed to let ABR4 to 816 expand the ERO such that the path is disjoint from the primary LSP in 817 area 2. 819 Area 1 Area 0 Area 2 820 <---------------><--------------><---------------> 822 +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ 823 | | | | | 824 | | | | | 825 A | | | C 826 | | | | | 827 | | | | | 828 +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+ 830 Figure A.1: Inter-area LSPs 832 In this example, a node performing the path computation, first 833 selects an ABR and then it computes a strict path towards this ABR. 834 For the backup LSP, all nodes of the primary LSP in the next areas 835 has to be put in the XRO (with the exception of the destination node 836 if node protection and no link protection is required). When an ABR 837 computes the next path segment, i.e. the path over the next area, it 838 may remove the nodes from the XRO that are located in that area with 839 the exception of the ABR where the primary LSP is exiting the area. 840 The latter information is still required because when the selected 841 ABR (ABR4 in this example) further expands the ERO, it has to exclude 842 the ABR on which the primary is entering that area (ABR3 in this 843 example). This means that when ABR2 generates an XRO, it may remove 844 the nodes in area 0 from the XRO but not ABR3. Note that not doing 845 this would not harm in this example because there is no path from 846 ABR4 to C via ABR3 in area2. If there would be a links between ABR4- 847 ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen- 848 erated by ABR2. 850 Discussion on the length of the XRO: when link or node protection is 851 requested, the length of the XRO is bounded by the length of the RRO 852 of the primary LSP. It can be made shorter by removing nodes by the 853 ingress node and the ABRs. In the example above, the RRO of the 854 primary LSP contains 8 subobjects, while the maximum XRO length can 855 be bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the 856 XRO. For SRLG protection, the XRO has to list all SRLGs that are 857 crossed by the primary LSP. 859 15.2 Inter-AS LSP protection 861 When an inter-AS LSP is established, which has to be protected by a 862 backup LSP to provide link or node protection, the same method as for 863 the inter-area LSP case can be used. The difference is when the 864 backup LSP is not following the same AS-path as the primary LSP 865 because then the XRO should always contain the full path of the pri- 866 mary LSP. In case the backup LSP is following the same AS-path (but 867 with different ASBRs - at least in case of node protection), it is 868 much similar as the inter-area case: ASBRs expanding the ERO over the 869 next AS may remove the XRO subobjects located in that AS. Note that 870 this can only be done by ingress ASBRs (the ASBR where the LSP is 871 entering the AS). 873 Discussion on the length of the XRO: the XRO is bounded by the length 874 of the RRO of the primary LSP. 876 Suppose that SRLG protection is required, and the ASs crossed by the 877 main LSP use a consistent way of allocating SRLG-ids to the links 878 (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids of 879 each link used by the main LSP can be recorded by means of the RRO, 880 which are then used by the XRO. If the SRLG-ids are only meaningfull 881 local to the AS, putting SRLG-ids in the XRO crossing many ASs makes 882 no sense. More details on the method of providing SRLG protection for 883 inter-AS LSPs can be found in [INTERAS]. Basically, the link IP 884 address of the inter-AS link used by the primary LSP is put into the 885 XRO of the Path message of the detour LSP or bypass tunnel. The ASBR 886 where the detour LSP or bypass tunnel is entering the AS can 887 translate this into the list of SRLG-ids known to the local AS. 889 Discussion on the length of the XRO: the XRO only contains 1 subob- 890 ject, which contains the IP address of the inter-AS link traversed by 891 the primary LSP (in the assumption that the primary LSP and detour 892 LSP or bypass tunnel are leaving the AS in the same area, and they 893 are also entering the next AS in the same area). 895 15.3 Protection in the GMPLS overlay model 897 When an edge-node wants to establish an LSP towards another edge-node 898 over an optical core network as described in [OVERLAY] (see figure 899 A.2), the XRO can be used for multiple purposes. 901 Overlay Overlay 902 Network +----------------------------------+ Network 903 +----------+ | | +----------+ 904 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 905 | | | | | | | | | | | | | | | | 906 | --+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+-- | 907 | | | | +--+--+ | | | | +---+--+ | | | | 908 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 909 | | | | | | | | | | | 910 +----------+ | | | | | | | +----------+ 911 | | | | | | | 912 +----------+ | | | | | | | +----------+ 913 | | | | +--+--+ | +--+--+ | | | | 914 | +----+ | | | | | +-------+ | | | | +----+ | 915 | | +-+--+ | | CN4 +---------------+ CN5 | | +--+-+ | | 916 | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | 917 | | | | | +-----+ +-----+ | | | | | 918 | +----+ | | | | +----+ | 919 | | +----------------------------------+ | | 920 +----------+ Core Network +----------+ 921 Overlay Overlay 922 Network Network 924 Legend: EN - Edge Node 925 CN - Core Node 926 Figure A.2 928 A first application is where an edge-node wants to establish multiple 929 LSPs towards the same destinatin edge-node, and these LSPs need to 930 have as few or no SRLGs in common. In this case EN1 could establish 931 an LSP towards EN3 and then it can establish a second LSP listing all 932 links used by the first LSP with the indicition to avoid the SRLGs of 933 these links. This information can be used by CN1 to compute a path 934 for the second LSP. If the core network consists of multiple areas, 935 then the SRLG-ids have to be listed in the XRO. The same example 936 applies to nodes and links. 938 Another application is where the edge-node wants to set up a backup 939 LSP that is also protecting the links between the edge-nodes and 940 core-nodes. For instance, when EN2 establishes an LSP to EN4, it 941 sends a Path message to CN4, which computes a path towards EN4 over 942 for instance CN5. When EN2 gets back the RRO of that LSP, it can sig- 943 nal a new LSP to CN1 with EN4 as destination and the XRO computed 944 based on the RRO of the first LSP. Based on this information, CN1 can 945 compute a path that has the requested diversaty properties (e.g, a 946 path going over CN2, CN3 and then to EN4). 948 It is clear that in these examples, the core-node may not edit the 949 RRO in a Resv message such that it includes only the subobjects from 950 the egress core-node through the egress edge-node. 952 15.4 LSP protection inside a single area 954 The XRO can also be used inside a single area. Take for instance a 955 network where the TE extensions of the IGPs as described in [OSPF-TE] 956 and [ISIS-TE] are not used, and hence each node has to select a 957 next-hop and possibly crankback [CRANKBACK] has to be used when there 958 is no viable next-hop. In this case, when signaling a backup LSP, the 959 XRO can be put in the Path message to exclude the links, nodes or 960 SRLGs of the primary LSP. An alternative to provide this functional- 961 ity would be to indicate in the Path message of the backup LSP, the 962 primary LSP together witn an indication which type of protection is 963 required. This latter solution would work for link and node protec- 964 tion, but not for SRLG protection. 966 Discussion on the length of the XRO: when link or node protection is 967 requested, the XRO is of the same length as the RRO of the primary 968 LSP. For SRLG protection, the XRO has to list all SRLGs that are 969 crossed by the primary LSP. Note that for SRLG protection, the link 970 IP address to reference the SRLGs of that link cannot be used since 971 the TE extensions of the IGPs are not used in this example, hence, a 972 node cannot translate any link IP address located in that area to its 973 SRLGs. 975 16. Full Copyright Statement 977 Copyright (C) The Internet Society (2002). All Rights Reserved. 979 This document and translations of it may be copied and furnished to 980 others, and derivative works that comment on or otherwise explain it 981 or assist in its implementation may be prepared, copied, published 982 and distributed, in whole or in part, without restriction of any 983 kind, provided that the above copyright notice and this paragraph are 984 included on all such copies and derivative works. However, this 985 document itself may not be modified in any way, such as by removing 986 the copyright notice or references to the Internet Society or other 987 Internet organizations, except as needed for the purpose of develop- 988 ing Internet standards in which case the procedures for copyrights 989 defined in the Internet Standards process must be followed, or as 990 required to translate it into languages other than English. 992 The limited permissions granted above are perpetual and will not be 993 revoked by the Internet Society or its successors or assigns. This 994 document and the information contained herein is provided on an "AS 995 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 996 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 997 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 998 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 999 OR FITNESS FOR A PARTICULAR PURPOSE.