idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-03.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1063. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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: 3. 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 'MUST not' in this paragraph: SRLGs may also be indicated for exclusion from the path to the next abstract node in the ERO by the inclusion of an EXRO Subobject containing an SRLG subobject. If the L-bit value in the SRLG subobject is zero, the resources (nodes, links, etc.) identified by the SRLG MUST not be used on the path to the next abstract node indicated in the ERO. If the L-bit is set, the resources identified by the SRLG SHOULD be avoided. == 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 (February 18, 2005) is 7007 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 738, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 321, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 794, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-overlay-04 -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group CY. Lee 2 Internet-Draft Alcatel 3 Expires: August 22, 2005 A. Farrel 4 Old Dog Consulting 5 S. De Cnodder 6 Alcatel 7 February 18, 2005 9 Exclude Routes - Extension to RSVP-TE 10 draft-ietf-ccamp-rsvp-te-exclude-route-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 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 29 material 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 This Internet-Draft will expire on August 22, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for 46 LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 47 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 48 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 49 abstract nodes and resources to be explicitly included in a path 50 setup, but not to be explicitly excluded. 52 In some networks where precise explicit paths are not computed at the 53 head end it may be useful to specify and signal abstract nodes and 54 resources that are to be explicitly excluded from routes. These 55 exclusions may apply to the whole path, or to parts of a path between 56 two abstract nodes specified in an explicit path. How Shared Risk 57 Link Groups (SLRGs) can be excluded is also specified in this 58 document. 60 This document specifies ways to communicate route exclusions during 61 path setup using RSVP-TE. 63 Table of Contents 65 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 66 1.1 Changes compared to version 01 . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 5 69 2.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 7 70 3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 8 71 3.1 SRLG ERO Subobject . . . . . . . . . . . . . . . . . . . . 8 72 4. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 9 74 4.1.1 Subobject 1: IPv4 prefix . . . . . . . . . . . . . . 10 75 4.1.2 Subobject 2: IPv6 Prefix . . . . . . . . . . . . . . 11 76 4.1.3 Subobject 32: Autonomous System Number . . . . . . . 11 77 4.1.4 Subobject TBD: SRLG . . . . . . . . . . . . . . . . . 12 78 4.1.5 Subobject 4: Unnumbered Interface ID Subobject . . . . 12 79 4.2 Semantics and Processing Rules for the Exclude Route 80 Object (XRO) . . . . . . . . . . . . . . . . . . . . . . . 13 81 5. Explicit Exclude Route . . . . . . . . . . . . . . . . . . . . 16 82 5.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16 83 5.2 Semantics and Processing Rules for the EXRS . . . . . . . 17 84 6. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 18 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 8.1 New Class Numbers . . . . . . . . . . . . . . . . . . . . 20 88 8.2 New Subobject Types . . . . . . . . . . . . . . . . . . . 20 89 8.3 New Error Codes . . . . . . . . . . . . . . . . . . . . . 20 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 10.1 Normative References . . . . . . . . . . . . . . . . . . . 22 93 10.2 Informational References . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 95 A. applications . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 A.1 Inter-area LSP protection . . . . . . . . . . . . . . . . 24 97 A.2 Inter-AS LSP protection . . . . . . . . . . . . . . . . . 25 98 A.3 Protection in the GMPLS overlay model . . . . . . . . . . 26 99 A.4 LSP protection inside a single area . . . . . . . . . . . 28 100 Intellectual Property and Copyright Statements . . . . . . . . 29 102 1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 1.1 Changes compared to version 01 110 o References updated. 111 o Editorial updates. 112 o Added Unnumbered Interface exclusions 113 o Acknowledgements updated. 114 o IPR section. 115 o Appendix A with applications is added. 117 2. Introduction 119 The current RSVP-TE specification [RFC3209] and GMPLS extensions 120 [RFC3473] allow abstract nodes and resources to be explicitly 121 included in a path setup, using the Explicit Route Object (ERO). 123 In some systems it may be useful to specify and signal abstract nodes 124 and resources that are to be explicitly excluded from routes. This 125 may be because loose hops or abstract nodes need to be prevented from 126 selecting a route through a specific resource. This is a special 127 case of distributed path calculation in the network. 129 Two types of exclusions are required: 131 1. Exclude any of the abstract nodes in a given set anywhere on the 132 path. This set of abstract nodes is referred to as the Exclude 133 Route list. 134 2. Exclude certain abstract nodes or resources between a specific 135 pair of abstract nodes present in an ERO. Such specific 136 exclusions are referred to as Explicit Exclusion Route. 138 To convey these constructs within the signaling protocol, a new RSVP 139 object and a new ERO subobject are introcuded respectively. 141 1. A new RSVP-TE object is introduced to convey the Exclude Route 142 list. This object is the Exclude Route Object (XRO). 143 2. The second type of exclusion is achieved through a modification 144 to the existing ERO. A new subobject type the Explicit Exclude 145 Route Subobject (EXRS) is introduced to indicate an exclusion 146 between a pair of included abstract nodes. 148 The knowledge of SRLGs, as defined in [INTERAS-REQ], may be used to 149 compute diverse paths that can be used for protection. In systems 150 where it is useful to signal exclusions, it may be useful to signal 151 SRLGs to indicate groups of resources that should be excluded on the 152 whole of a path or between two abstract nodes specified in an 153 explicit path. 155 This document introduces an ERO subobject to indicate an SRLG to be 156 signaled in either of the two exclusion methods described above. 157 This subobject might also be appropriate for use within Explicit 158 Routes or Record Routes, but that discussion is outside the scope of 159 this document. 161 2.1 Scope of Exclude Routes 163 This document does not preclude a route exclusion from listing many 164 nodes or network elements to avoid. The intent is, however, to 165 indicate only the minimal number of subobjects to be avoided. For 166 instance it may be necessary to signal only the SRLGs (or Shared 167 Risk Groups) to avoid. 169 It is envisaged that most of the conventional inclusion subobjects 170 are specified in the signaled ERO only for the area where they are 171 pertinent. The number of subobjects to be avoided, specified in the 172 signaled XRO may be constant throughout the whole path setup, or the 173 subobjects to be avoided may be removed from the XRO as they become 174 irrelevant in the subsequent hops of the path setup. 176 For example, consider an LSP that traverses multiple computation 177 domains. A computation domain may be an area in the administrative 178 or IGP sense, or may be an arbitrary division of the network for 179 active management and path computational purposes. Let the primary 180 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: 181 o Xn denotes a node in domain X, and 182 o XYn denotes a node on the border of domain X and domain Y. 184 Note that Ingress is a node in domain A, and Egress is a node in 185 domain C. This is shown in Figure 1 where the domains correspond 186 with areas. 188 area A area B area C 189 <-------------------> <----------------> <------------------> 190 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress 191 ^ \ / | \ / | \ / 192 | \ / | \ / | \ / 193 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4 194 | ^ ^ 195 | | | 196 | | ERO: (C3-strict, C4-strict, 197 | | Egress-strict) 198 | | XRO: Not needed 199 | | 200 | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) 201 | XRO: (C1, C2) 202 | 203 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) 204 XRO: (B1, B2, BC1, C1, C2, Egress) 206 Consider the establishment of a node-diverse protection path in the 207 example above. The protection path must avoid all nodes on the 208 primary path. The exclusions for area A are handled during 209 Constrained Shortest Path First (CSPF) computation at Ingress, so the 210 ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, 211 AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively. At 212 AB2 the ERO and XRO could be (B3-strict, B4-strict, BC2-strict, 213 Egress-loose) and (C1,C2) respectively. At BC2 the ERO could be 214 (C3-strict, C4-strict, Egress-strict) and an XRO is not needed from 215 BC2 onwards. 217 In general, consideration should be given (as with explicit route) to 218 the size of signaled data and the impact on the signaling protocol. 220 2.2 Relationship to MPLS TE MIB 222 [RFC3812] defines managed objects for managing and modeling 223 MPLS-based traffic engineering. Included in [RFC3812] is a means to 224 configure explicit routes for use on specific LSPs. This 225 configuration allows the exclusion of certain resources. 227 In systems where the full explicit path is not computed at the 228 ingress (or at a path computation site for use at the ingress) it may 229 be necessary to signal those exclusions. This document offers a 230 means of doing this signaling. 232 3. Shared Risk Link Groups 234 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 235 OSPF]. 237 3.1 SRLG ERO Subobject 239 The format of the ERO and its subobjects are defined in [RFC3209]. 240 The new SRLG subobject is defined by this document as follows. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |L| Type | Length | SRLG Id (4 bytes) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | SRLG Id (continued) | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 L 252 The L bit is an attribute of the subobject. The L bit is set 253 if the subobject represents a loose hop in the explicit route. 254 If the bit is not set, the subobject represents a strict hop in 255 the explicit route. 257 For exclusions (as used by XRO and EXRS defined in this 258 document), the L bit SHOULD be set to zero and ignored. 260 Type 262 The type of the subobject [TBD]. 264 Length 266 The Length contains the total length of the subobject in bytes, 267 including the Type and Length fields. The Length is always 8. 269 SRLG Id 271 The 32 bit identifier of the SRLG. 273 Reserved 275 Zero on transmission. Ignored on receipt 277 4. Exclude Route List 279 The exclude route identifies a list of abstract nodes that MUST NOT 280 be traversed along the path of the LSP being established. It is 281 RECOMMENDED to limit size of the exlude route list to a value local 282 to the node originating the exclude route list. 284 4.1 Exclude Route Object (XRO) 286 Abstract nodes to be excluded from the path are specified via the 287 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 289 Currently one C_Type is defined, Type 1 Exclude Route. The 290 EXCLUDE_ROUTE object has the following format: 292 Class = TBD, C_Type = 1 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 // (Subobjects) // 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Subobjects 304 The contents of an EXCLUDE_ROUTE object are a series of variable- 305 length data items called subobjects. The subobjects are identical to 306 those defined in [RFC3209] and [RFC3473] for use in EROs. 308 The following subobject types are supported. 310 Type Subobject 311 1 IPv4 prefix 312 2 IPv6 prefix 313 4 Unnumbered Interface ID 314 32 Autonomous system number 315 TBD SRLG 317 The defined values for Type above are specified in [RFC3209] and in 318 this document. 320 The concept of loose or strict hops has no meaning in route 321 exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is 322 reused here to indicate that an abstract node MUST be avoided (value 323 0) or SHOULD be avoided (value 1). 325 An Attribute octet is introduced in the subobjects that define IP 326 addresses to indicate the attribute (e.g. interface, node, SRLG) 327 associated with the IP addresses that can be excluded from the path. 328 For instance, the attribute node allows a whole node to be excluded 329 from the path, in contrast to the attribute interface, which allows 330 specific interfaces to be excluded from the path. The attribute SRLG 331 allows all SRLGs associated with an IP address to be excluded from 332 the path. 334 4.1.1 Subobject 1: IPv4 prefix 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |L| Type | Length | IPv4 address (4 bytes) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | IPv4 address (continued) | Prefix Length | Attribute | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 L 346 0 indicates that the attribute specified MUST be excluded 347 1 indicates that the attribute specified SHOULD be avoided 349 Attribute 351 interface 353 0 indicates that the interface or set of interfaces associ- 354 ated with the IP prefix should be excluded or avoided 356 node 358 1 indicates that the node or set of nodes associated with 359 the IP prefix should be excluded or avoided 361 SRLG 363 2 indicates that all the SRLGs associated with the IP 364 prefix should be excluded or avoided 366 The rest of the fields are as defined in [RFC3209]. 368 4.1.2 Subobject 2: IPv6 Prefix 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |L| Type | Length | IPv6 address (16 bytes) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | IPv6 address (continued) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | IPv6 address (continued) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | IPv6 address (continued) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | IPv6 address (continued) | Prefix Length | Attribute | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 L 386 0 indicates that the attribute specified MUST be excluded 387 1 indicates that the attribute specified SHOULD be avoided 389 Attribute 391 interface 393 0 indicates that the interface or set of interfaces associ- 394 ated with the IP prefix should be excluded or avoided 396 node 398 1 indicates that the node or set of nodes associated with 399 the IP prefix should be excluded or avoided 401 SRLG 403 2 indicates that all the SRLG associated with the IP 404 prefix should be excluded or avoided 406 The rest of the fields are as defined in [RFC3209]. 408 4.1.3 Subobject 32: Autonomous System Number 410 The L bit of an Autonomous System Number subobject has meaning in an 411 Exclude Route (contrary to its usage in an Explict Route defined in 412 [RFC3209]. The meaning is as for other subobjects described above. 413 That is: 415 0 indicates that the abstract node specified MUST be excluded 417 1 indicates that the abstract node specified SHOULD be avoided 419 The rest of the fields are as defined in [RFC3209]. There is no 420 Attribute octet defined. 422 4.1.4 Subobject TBD: SRLG 424 The meaning of the L bit is as follows: 426 0 indicates that the SRLG specified MUST be excluded 428 1 indicates that the SRLG specified SHOULD be avoided 430 The Attribute octet is not present. The rest of the fields are as 431 defined in the "SRLG ERO Subobject" section of this document. 433 4.1.5 Subobject 4: Unnumbered Interface ID Subobject 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 |L| Type | Length | Reserved | Attribute | 439 | | | |(must be zero) | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Router ID | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Interface ID (32 bits) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 L 448 0 indicates that the attribute specified MUST be excluded 449 1 indicates that the attribute specified SHOULD be avoided 451 Attribute 453 interface 455 0 indicates that the Interface ID specified should be 456 excluded or avoided 458 node 460 1 indicates that the node with the Router ID should be 461 excluded or avoided (this can be achieved using IPv4/v6 462 subobject as well, but is included here because it may be 463 convenient to use subobjects from RRO, in specifying the 464 exclusions) 466 SRLG 468 2 indicates that all the SRLGs associated with the 469 interface should be excluded or avoided 471 Reserved 473 Zero on transmission. Ignored on receipt. 475 The rest of the fields are as defined in [RFC3477]. 477 4.2 Semantics and Processing Rules for the Exclude Route Object (XRO) 479 The exclude route list is encoded as a series of subobjects con- 480 tained in an EXCLUDE_ROUTE object. Each subobject identifies an 481 abstract node in the exclude route list. 483 Each abstract node may be a precisely specified IP address belonging 484 to a node, or an IP address with prefix identifying interfaces of a 485 group of nodes, or an Autonomous System. 487 The Explicit Route and routing processing is unchanged from the 488 description in [RFC3209] with the following additions: 490 1. When a Path message is received at a node, the node must check 491 that it is not a member of any of the abstract nodes in the XRO 492 if it is present in the Path message. If the node is a member of 493 any of the abstract nodes in the XRO with the L-flag set to 494 "exclude", it should return a PathErr with the error code 495 "Routing Problem" and error value of "Local node in Exclude 496 Route". If there are SRLGs in the XRO, the node should check 497 that the resources the node uses are not part of any SRLG with 498 the L-flag set to "exclude" that is specified in the XRO. If it 499 is, it should return a PathErr with error code "Routing Problem" 500 and error value of "Local node in Exclude Route". 502 2. Each subobject must be consistent. If a subobject is not con- 503 sistent then the node should return a PathErr with error code 504 "Routing Problem" and error value "Inconsistent Subobject". An 505 example of an inconsistent subobject is an IPv4 Prefix subobject 506 containing the IP address of a node and the attribute field is 507 set to "interface" or "SRLG". 509 3. The subobjects in the ERO and XRO SHOULD not contradict each 510 other. If they do contradict, the subobjects with the L flag not 511 set, strict or MUST be excluded, respectively, in the ERO or XRO 512 MUST take precedence. If there is still a conflict, a PathErr 513 with error code "Routing Problem" and error value of "Route 514 blocked by Exclude Route" should be returned. 516 4. When choosing a next hop or expanding an explicit route to 517 include additional subobjects, a node: 519 1. must not introduce an explicit node or an abstract node that 520 equals or is a member of any abstract node that is specified 521 in the Exclude Route Object with the L-flag set to "exclude". 522 The number of introduced exlicit nodes or abstract nodes with 523 the L flag set to "avoid" should be minimised. 525 2. must not introduce links, nodes or resources identified by 526 the SRLG Id specified in the SRLG subobjects(s). The number 527 of introduced SLRGs with the L flag set to "avoid" should be 528 minimised. 530 If these rules preclude further forwarding of the Path message, 531 the node should return a PathErr with the error code "Routing 532 Problem" and error value of "Route blocked by Exclude Route". 534 Note that the subobjects in the XRO is an unordered list of 535 subob- jects. 537 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 538 support the XRO will forward it uninspected and will not apply the 539 extensions to ERO processing described above. This makes the XRO a 540 'best effort' process. 542 This 'best-effort' approach is chosen to allow route exclusion to 543 traverse parts of the network that are not capable of parsing or 544 handling the new function. Note that Record Route may be used to 545 allow computing nodes to observe violations of route exclusion and 546 attempt to re-route the LSP accordingly. 548 If a node supports the XRO, but not a particular subobject or part of 549 that subobject, then that particular subobject is ignored. Examples 550 of a part of a subobject that can be supported are: (1) only prefix 551 32 of the IPv4 prefix subobject could be supported, or (2) a 552 particular subobject is supported but not the particular attribute 553 field. 555 When a node forwards a Path message, it can do the following three 556 operations related to XRO besides of the processing rules mentioned 557 above: 559 1. If no XRO was present, an XRO may be included. 561 2. If an XRO was present, it may remove the XRO if it is sure that 562 the next nodes do not need this information anymore. An example 563 is where a node can expand the ERO to a full strict path towards 564 the destination. See Figure 1 where BC2 is removing the XRO from 565 the Path message. 567 3. If an XRO was present, the content of the XRO can be modified. 568 Subobjects can be added or removed. See Figure 1 for an example 569 where AB2 is stripping off some subobjects. 571 5. Explicit Exclude Route 573 The Explicit Exclude Route defines abstract nodes or resources (such 574 as links, unnumbered interfaces or labels) that must not be used on 575 the path between two inclusive abstract nodes or resources in the 576 explicit route. 578 5.1 Explicit Exclusion Route Subobject (EXRS) 580 A new ERO subobject type is defined. The Explicit Exclude Route 581 Subobject (EXRS) has type [TBD]. The EXRS may not be present in an 582 RRO or XRO. 584 The format of the EXRS is as follows. 586 0 1 587 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 589 |L| Type | Length | EXRS subobjects | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 592 L 594 ignored and must be zero [Note: The L bit in an EXRS subobject 595 is as defined for the XRO subobjects] 597 Type 599 The type of the subobject, i.e. EXRS [TBD] 601 EXRS subobjects 603 An EXRS subobject indicates the abstract node or resource to be 604 excluded. The format of this field is exactly the format of an 605 XRO subobject and may include an SRLG subobject. Both subob- 606 jects are as described earlier in this document. 608 Thus, an EXRO subobject for an IP hop might look as follows: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |L| Type | Length |L| Type | Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | IPv4 address (4 bytes) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Prefix Length | Attribute | Reserved | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Note: The Most Significant Bit in the Type field could be used to 621 indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating 622 the need to prepend the subobject with an additional TLV header. 623 This would reduce the number bytes require for each subobject by 2 624 bytes. However, this approach would reduce the ERO Type field space 625 by half. This issue need WG discussion and feedback. 627 5.2 Semantics and Processing Rules for the EXRS 629 Each EXRS may carry multiple exclusions. The exclusion is encoded 630 exactly as for XRO subobjects and prefixed by an additional Type and 631 Length. 633 The scope of the exclusion is the step between the previous ERO 634 subobject that identifies an abstract node, and the subsequent ERO 635 subobject that identifies an abstract node. Multiple exclusions may 636 be present between any pair of abstract nodes. 638 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 639 Systems that must not be traversed on the path to the next abstract 640 node indicated in the ERO. 642 Exclusions may also indicate resources (such as unnumbered 643 interfaces, link ids, labels) that must not be used on the path to 644 the next abstract node indicated in the ERO. 646 SRLGs may also be indicated for exclusion from the path to the next 647 abstract node in the ERO by the inclusion of an EXRO Subobject 648 containing an SRLG subobject. If the L-bit value in the SRLG 649 subobject is zero, the resources (nodes, links, etc.) identified by 650 the SRLG MUST not be used on the path to the next abstract node 651 indicated in the ERO. If the L-bit is set, the resources identified 652 by the SRLG SHOULD be avoided. 654 The subobjects in the ERO and EXRS SHOULD not contradict each other. 655 If they do contradict, the subobjects with the L bit not set, strict 656 or MUST be excluded, respectively, in the ERO or XRO MUST take pre- 657 cedence. If there is still a conflict, the subobjects in the ERO 658 MUST take precedence. 660 If a node is called upon to process an EXRS and does not support 661 handling of exclusions it will return a PathErr with a "Bad 662 EXPLICIT_ROUTE object" error. 664 If the presence of EXRO Subobjects precludes further forwarding of 665 the Path message, the node should return a PathErr with the error 666 code "Routing Problem" and error value of "Route blocked by Exclude 667 Route". 669 6. Minimum compliance 671 An implementation must be at least compliant with the following: 673 1. The XRO MUST be supported with the following restrictions: 674 * The IPv4 Prefix subobject MUST be supported with a prefix 675 length of 32, and an attribute value of "interface" and 676 "node". Other prefix values and attribute values MAY be 677 supported. 678 * The IPv6 Prefix subobject MUST be supported with a prefix 679 length of 128, and an attriubute value of "interface" and 680 "node". Other prefix values and attribute values MAY be 681 supported. 683 2. The EXRS SHOULD be supported. If supported, the same 684 restrictions as for the XRO apply. 686 3. If XRO or EXRS are supported, the implementation MUST be 687 compliant with the processing rules of the supported, not 688 supported, or partially supported subobjects as specified within 689 this document. 691 7. Security Considerations 693 The new exclude route object poses no security exposures over and 694 above [RFC3209] and [RFC3473]. Note that any security concerns that 695 exist with Explicit Routes should be considered with regard to route 696 exclusions. 698 8. IANA Considerations 700 It might be considered that a possible approach would be to assign 701 one of the bits of the ERO sub-object type field (perhaps the top 702 bit) to identify that a sub-object is intended for inclusion rather 703 than exclusion. However, [RFC3209] states that the type field (seven 704 bits) should be assigned as 0 - 63 through IETF consensus action, 64 705 - 95 as first come first served, and 96 - 127 are reserved for 706 private use. It would not be acceptable to disrupt existing 707 implementations so the only option would be to split the IETF 708 consensus range leaving only 32 sub-object types. It is felt that 709 that would be an unacceptably small number for future expansion of 710 the protocol. 712 8.1 New Class Numbers 714 One new class number is required. 716 EXCLUDE_ROUTE 717 Class-Num = 011bbbbb 718 CType: 1 720 8.2 New Subobject Types 722 A new subobject type for the Exclude Route Object and Explicit 723 Exclude Route Subobject is required. 725 SRLG subobject 727 A new subobject type for the ERO is required. 729 Explicit Exclude Route subobject 731 8.3 New Error Codes 733 New error values are needed for the error code 'Routing Problem'. 735 Unsupported Exclude Route Subobject Type [TBD] 736 Inconsistent Subobject [TBD] 737 Local Node in Exclude Route [TBD] 738 Route Blocked by Exclude Route [TBD] 740 9. Acknowledgments 742 This document reuses text from [RFC3209] for the description of 743 EXCLUDE_ROUTE. 745 The authors would like to express their thanks to Lou Berger, Steffen 746 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and 747 Richard Rabbat for their considered opinions on this draft. Also 748 thanks to Yakov Rekhter for reminding us about SRLGs! 750 10. References 752 10.1 Normative References 754 [GMPLS-OSPF] 755 Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 756 of Generalized Multi-Protocol Label Switching", 757 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, work in 758 progress, October 2003. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 764 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 765 Tunnels", RFC 3209, December 2001. 767 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 768 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 769 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 771 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 772 in Resource ReSerVation Protocol - Traffic Engineering 773 (RSVP-TE)", RFC 3477, January 2003. 775 10.2 Informational References 777 [CRANKBACK] 778 Farrel, A., Satyanarayana, A., Iwata, A., Ash, G. and S. 779 Marshall-Unitt, "Crankback Signaling Extensions for MPLS 780 Signaling", draft-ietf-ccamp-crankback-02.txt, work in 781 progress, July 2004. 783 [INTERAS] De Cnodder, S. and C. Pelsser, "Protection for inter-AS 784 MPLS tunnels", 785 draft-decnodder-ccamp-interas-protection-00.txt, work in 786 progress, July 2004. 788 [INTERAS-REQ] 789 Zhang, R. and JP. Vasseur, "MPLS Inter-AS Traffic 790 Engineering requirements", 791 draft-ietf-tewg-interas-mpls-te-req-09.txt, work in 792 progress, September 2004. 794 [MPLS-BUNDLE] 795 Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in 796 MPLS Traffic Engineering", 797 draft-ietf-mpls-bundle-04.txt, work in progress, July 798 2002. 800 [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H. and Y. Rekhter, 801 "GMPLS UNI: RSVP Support for the Overlay Model", 802 draft-ietf-ccamp-gmpls-overlay-04.txt, work in progress, 803 April 2004. 805 [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering 806 (TE) Extensions to OSPF Version 2", RFC 3630, September 807 2003. 809 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 810 System (IS-IS) Extensions for Traffic Engineering (TE)", 811 RFC 3784, June 2004. 813 [RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau, 814 "Multiprotocol Label Switching (MPLS) Traffic Engineering 815 (TE) Management Information Base (MIB)", RFC 3812, June 816 2004. 818 Authors' Addresses 820 Cheng-Yin Lee 821 Alcatel 822 600 March Road. 823 Ottawa, Ontario 824 Canada K2K 2E6 826 Email: Cheng-Yin.Lee@alcatel.com 828 Adrian Farrel 829 Old Dog Consulting 831 Phone: +44 (0) 1978 860944 832 Email: adrian@olddog.co.uk 834 Stefaan De Cnodder 835 Alcatel 836 Francis Wellesplein 1 837 B-2018 Antwerp 838 Belgium 840 Phone: +32 3 240 85 15 841 Email: stefaan.de_cnodder@alcatel.be 843 Appendix A. applications 845 This section describes some applications that can make use of the 846 XRO. The intention is to show that the XRO is not an application 847 specific object, but that it can be used for multiple purposes. In a 848 few examples, other solutions might be possible for that particular 849 case but the intention is to show that also a single object can be 850 used for all the examples, hence making the XRO a rather generic 851 object without having to define a solution and new objects for each 852 new application. 854 A.1 Inter-area LSP protection 856 One method to establish an inter-area LSP is where the ingress router 857 selects an ABR, and then the ingress router computes a path towards 858 this selected ABR such that the configured constraints of the LSP are 859 fulfilled. In the example of figure A.1, an LSP has to be 860 established from node A in area 1 to node C in area 2. If no loose 861 hops are con- figured, then the computed ERO at A could looks as 862 follows: (A1- strict, A2-strict, ABR1-strict, C-loose). When the 863 Path message arrives at ABR1, then the ERO is (ABR1-strict, C-loose) 864 and it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). 865 Similar, at ABR3 the received ERO is (ABR3-strict, C-loose) and it 866 can be expanded to (C1-strict, C2-strict, C-strict). If also a 867 backup LSP has to be established, then A takes another ABR (ABR2 in 868 this case) and computes a path towards this ABR that fulfills the 869 constraints of the LSP and such that is disjoint from the path of the 870 primary LSP. The ERO generated by A looks as follows for this 871 example: (A3-strict, A4-strict, ABR2-strict, C-loose). 873 In order to let ABR2 expand the ERO, it also needs to know the path 874 of the primary LSP to expand the ERO such that it is disjoint from 875 the path of the primary LSP. Therefore, A also includes an XRO that 876 at least contains (ABR1, B1, ABR3, C1, C2). Based on these con- 877 straints, ABR2 can expand the ERO such that it is disjoint from the 878 primary LSP. In this example, the ERO computed by ABR2 would be (B2- 879 strict, ABR4-strict, C-loose), and the XRO generated by B contains at 880 least (ABR3, C1, C2). The latter information is needed to let ABR4 881 to expand the ERO such that the path is disjoint from the primary LSP 882 in area 2. 884 Area 1 Area 0 Area 2 885 <---------------><--------------><---------------> 887 +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ 888 | | | | | 889 | | | | | 890 A | | | C 891 | | | | | 892 | | | | | 893 +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+ 895 Figure A.1: Inter-area LSPs 897 In this example, a node performing the path computation, first 898 selects an ABR and then it computes a strict path towards this ABR. 899 For the backup LSP, all nodes of the primary LSP in the next areas 900 has to be put in the XRO (with the exception of the destination node 901 if node protection and no link protection is required). When an ABR 902 computes the next path segment, i.e. the path over the next area, it 903 may remove the nodes from the XRO that are located in that area with 904 the exception of the ABR where the primary LSP is exiting the area. 905 The latter information is still required because when the selected 906 ABR (ABR4 in this example) further expands the ERO, it has to exclude 907 the ABR on which the primary is entering that area (ABR3 in this 908 example). This means that when ABR2 generates an XRO, it may remove 909 the nodes in area 0 from the XRO but not ABR3. Note that not doing 910 this would not harm in this example because there is no path from 911 ABR4 to C via ABR3 in area2. If there would be a links between ABR4- 912 ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen- 913 erated by ABR2. 915 Discussion on the length of the XRO: when link or node protection is 916 requested, the length of the XRO is bounded by the length of the RRO 917 of the primary LSP. It can be made shorter by removing nodes by the 918 ingress node and the ABRs. In the example above, the RRO of the pri- 919 mary LSP contains 8 subobjects, while the maximum XRO length can be 920 bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the 921 XRO. For SRLG protection, the XRO has to list all SRLGs that are 922 crossed by the primary LSP. 924 A.2 Inter-AS LSP protection 926 When an inter-AS LSP is established, which has to be protected by a 927 backup LSP to provide link or node protection, the same method as for 928 the inter-area LSP case can be used. The difference is when the 929 backup LSP is not following the same AS-path as the primary LSP 930 because then the XRO should always contain the full path of the pri- 931 mary LSP. In case the backup LSP is following the same AS-path (but 932 with different ASBRs - at least in case of node protection), it is 933 much similar as the inter-area case: ASBRs expanding the ERO over the 934 next AS may remove the XRO subobjects located in that AS. Note that 935 this can only be done by ingress ASBRs (the ASBR where the LSP is 936 entering the AS). 938 Discussion on the length of the XRO: the XRO is bounded by the length 939 of the RRO of the primary LSP. 941 Suppose that SRLG protection is required, and the ASs crossed by the 942 main LSP use a consistent way of allocating SRLG-ids to the links 943 (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids 944 of each link used by the main LSP can be recorded by means of the 945 RRO, which are then used by the XRO. If the SRLG-ids are only 946 meaningfull local to the AS, putting SRLG-ids in the XRO crossing 947 many ASs makes no sense. More details on the method of providing 948 SRLG protection for inter-AS LSPs can be found in [INTERAS]. 949 Basically, the link IP address of the inter-AS link used by the 950 primary LSP is put into the XRO of the Path message of the detour LSP 951 or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is 952 entering the AS can translate this into the list of SRLG-ids known to 953 the local AS. 955 Discussion on the length of the XRO: the XRO only contains 1 subob- 956 ject, which contains the IP address of the inter-AS link traversed by 957 the primary LSP (in the assumption that the primary LSP and detour 958 LSP or bypass tunnel are leaving the AS in the same area, and they 959 are also entering the next AS in the same area). 961 A.3 Protection in the GMPLS overlay model 963 When an edge-node wants to establish an LSP towards another edge-node 964 over an optical core network as described in [OVERLAY] (see figure 965 A.2), the XRO can be used for multiple purposes. 967 Overlay Overlay 968 Network +--------------------------------+ Network 969 +----------+ | | +----------+ 970 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 971 | | | | | | | | | | | | | | | | 972 | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- | 973 | | | | +--+--+ | | | | +---+--+ | | | | 974 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 975 | | | | | | | | | | | 976 +----------+ | | | | | | | +----------+ 977 | | | | | | | 978 +----------+ | | | | | | | +----------+ 979 | | | | +--+--+ | +--+--+ | | | | 980 | +----+ | | | | | +------+ | | | | +----+ | 981 | | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | | 982 | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | 983 | | | | | +-----+ +-----+ | | | | | 984 | +----+ | | | | +----+ | 985 | | +--------------------------------+ | | 986 +----------+ Core Network +----------+ 987 Overlay Overlay 988 Network Network 990 Legend: EN - Edge Node 991 CN - Core Node 992 Figure A.2 994 A first application is where an edge-node wants to establish multiple 995 LSPs towards the same destinatin edge-node, and these LSPs need to 996 have as few or no SRLGs in common. In this case EN1 could establish 997 an LSP towards EN3 and then it can establish a second LSP listing all 998 links used by the first LSP with the indicition to avoid the SRLGs of 999 these links. This information can be used by CN1 to compute a path 1000 for the second LSP. If the core network consists of multiple areas, 1001 then the SRLG-ids have to be listed in the XRO. The same example 1002 applies to nodes and links. 1004 Another application is where the edge-node wants to set up a backup 1005 LSP that is also protecting the links between the edge-nodes and 1006 core-nodes. For instance, when EN2 establishes an LSP to EN4, it 1007 sends a Path message to CN4, which computes a path towards EN4 over 1008 for instance CN5. When EN2 gets back the RRO of that LSP, it can 1009 sig- nal a new LSP to CN1 with EN4 as destination and the XRO 1010 computed based on the RRO of the first LSP. Based on this 1011 information, CN1 can compute a path that has the requested diversaty 1012 properties (e.g, a path going over CN2, CN3 and then to EN4). 1014 It is clear that in these examples, the core-node may not edit the 1015 RRO in a Resv message such that it includes only the subobjects from 1016 the egress core-node through the egress edge-node. 1018 A.4 LSP protection inside a single area 1020 The XRO can also be used inside a single area. Take for instance a 1021 network where the TE extensions of the IGPs as described in [RFC3630] 1022 and [RFC3784] are not used, and hence each node has to select a 1023 next-hop and possibly crankback [CRANKBACK] has to be used when there 1024 is no viable next-hop. In this case, when signaling a backup LSP, 1025 the XRO can be put in the Path message to exclude the links, nodes or 1026 SRLGs of the primary LSP. An alternative to provide this functional- 1027 ity would be to indicate in the Path message of the backup LSP, the 1028 primary LSP together witn an indication which type of protection is 1029 required. This latter solution would work for link and node protec- 1030 tion, but not for SRLG protection. 1032 Discussion on the length of the XRO: when link or node protection is 1033 requested, the XRO is of the same length as the RRO of the primary 1034 LSP. For SRLG protection, the XRO has to list all SRLGs that are 1035 crossed by the primary LSP. Note that for SRLG protection, the link 1036 IP address to reference the SRLGs of that link cannot be used since 1037 the TE extensions of the IGPs are not used in this example, hence, a 1038 node cannot translate any link IP address located in that area to its 1039 SRLGs. 1041 Intellectual Property Statement 1043 The IETF takes no position regarding the validity or scope of any 1044 Intellectual Property Rights or other rights that might be claimed to 1045 pertain to the implementation or use of the technology described in 1046 this document or the extent to which any license under such rights 1047 might or might not be available; nor does it represent that it has 1048 made any independent effort to identify any such rights. Information 1049 on the procedures with respect to rights in RFC documents can be 1050 found in BCP 78 and BCP 79. 1052 Copies of IPR disclosures made to the IETF Secretariat and any 1053 assurances of licenses to be made available, or the result of an 1054 attempt made to obtain a general license or permission for the use of 1055 such proprietary rights by implementers or users of this 1056 specification can be obtained from the IETF on-line IPR repository at 1057 http://www.ietf.org/ipr. 1059 The IETF invites any interested party to bring to its attention any 1060 copyrights, patents or patent applications, or other proprietary 1061 rights that may cover technology that may be required to implement 1062 this standard. Please address the information to the IETF at 1063 ietf-ipr@ietf.org. 1065 Disclaimer of Validity 1067 This document and the information contained herein are provided on an 1068 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1069 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1070 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1071 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1072 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1073 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1075 Copyright Statement 1077 Copyright (C) The Internet Society (2005). This document is subject 1078 to the rights, licenses and restrictions contained in BCP 78, and 1079 except as set forth therein, the authors retain all their rights. 1081 Acknowledgment 1083 Funding for the RFC Editor function is currently provided by the 1084 Internet Society.