idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1122. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 '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 EXRS 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. -- 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 (July 17, 2005) is 6855 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 289, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 851, but no explicit reference was found in the text -- No information found for draft-ietf-ccamp-gmpls-routing-9 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-RTG' == 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: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group CY. Lee 3 Internet-Draft Alcatel 4 Expires: January 18, 2006 A. Farrel 5 Old Dog Consulting 6 S. De Cnodder 7 Alcatel 8 July 17, 2005 10 Exclude Routes - Extension to RSVP-TE 11 draft-ietf-ccamp-rsvp-te-exclude-route-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 18, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP 45 Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 46 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 47 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 48 abstract nodes and resources to be explicitly included in a path 49 setup, but not to be explicitly excluded. 51 In some networks where precise explicit paths are not computed at the 52 head end it may be useful to specify and signal abstract nodes and 53 resources that are to be explicitly excluded from routes. These 54 exclusions may apply to the whole path, or to parts of a path between 55 two abstract nodes specified in an explicit path. How Shared Risk 56 Link Groups (SLRGs) can be excluded is also specified in this 57 document. 59 This document specifies ways to communicate route exclusions during 60 path setup using RSVP-TE. 62 Table of Contents 64 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 6 67 2.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 7 68 3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 8 69 3.1 SRLG ERO Subobject . . . . . . . . . . . . . . . . . . . . 8 70 4. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 10 72 4.1.1 IPv4 prefix Subobject . . . . . . . . . . . . . . . . 11 73 4.1.2 IPv6 Prefix Subobject . . . . . . . . . . . . . . . . 12 74 4.1.3 Unnumbered Interface ID Subobject . . . . . . . . . . 13 75 4.1.4 Autonomous System Number Subobject . . . . . . . . . . 14 76 4.1.5 SRLG Subobject . . . . . . . . . . . . . . . . . . . . 15 77 4.2 Processing Rules for the Exclude Route Object (XRO) . . . 15 78 5. Explicit Exclusion Route . . . . . . . . . . . . . . . . . . . 18 79 5.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 18 80 5.2 Processing Rules for the Explicit Exclusion Route 81 Subobject (EXRS) . . . . . . . . . . . . . . . . . . . . . 19 82 6. Processing of XRO together with EXRS . . . . . . . . . . . . . 21 83 7. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 22 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 9.1 New RSVP-TE Class Numbers . . . . . . . . . . . . . . . . 24 87 9.2 New ERO Subobject Type . . . . . . . . . . . . . . . . . . 24 88 9.3 New ERO and XRO Subobject Type . . . . . . . . . . . . . . 24 89 9.4 New Error Codes . . . . . . . . . . . . . . . . . . . . . 25 90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 11.1 Normative References . . . . . . . . . . . . . . . . . . . 27 93 11.2 Informational References . . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 95 A. applications . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 A.1 Inter-area LSP protection . . . . . . . . . . . . . . . . 29 97 A.2 Inter-AS LSP protection . . . . . . . . . . . . . . . . . 30 98 A.3 Protection in the GMPLS overlay model . . . . . . . . . . 31 99 A.4 LSP protection inside a single area . . . . . . . . . . . 33 100 Intellectual Property and Copyright Statements . . . . . . . . 34 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 2. Introduction 110 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 111 allow abstract nodes and resources to be explicitly included in a 112 path setup, using the Explicit Route Object (ERO). 114 In some systems it may be useful to specify and signal abstract nodes 115 and resources that are to be explicitly excluded from routes. This 116 may be because loose hops or abstract nodes need to be prevented from 117 selecting a route through a specific resource. This is a special 118 case of distributed path calculation in the network. 120 Two types of exclusions are required: 122 1. Exclusion of certain abstract nodes or resources on the whole 123 path. This set of abstract nodes is referred to as the Exclude 124 Route list. 126 2. Exclusion of certain abstract nodes or resources between a 127 specific pair of abstract nodes present in an ERO. Such specific 128 exclusions are referred to as Explicit Exclusion Route. 130 To convey these constructs within the signaling protocol, a new RSVP 131 object and a new ERO subobject are introduced respectively. 133 1. A new RSVP-TE object is introduced to convey the Exclude Route 134 list. This object is the Exclude Route Object (XRO). 136 2. The second type of exclusion is achieved through a modification 137 to the existing ERO. A new ERO subobject type the Explicit 138 Exclusion Route Subobject (EXRS) is introduced to indicate an 139 exclusion between a pair of included abstract nodes. 141 The knowledge of SRLGs, as defined in [INTERAS-REQ], may be used to 142 compute diverse paths that can be used for protection. In systems 143 where it is useful to signal exclusions, it may be useful to signal 144 SRLGs to indicate groups of resources that should be excluded on the 145 whole path or between two abstract nodes specified in an explicit 146 path. 148 This document introduces an ERO subobject to indicate an SRLG to be 149 signaled in either of the two exclusion methods described above and 150 this document does not assume or preclude any other usage for this 151 subobject. This subobject might also be appropriate for use within 152 Explicit Routes or Record Routes, but this is outside the scope of 153 this document. 155 2.1 Scope of Exclude Routes 157 This document does not preclude a route exclusion from listing 158 arbitrary nodes or network elements to avoid. The intent is, 159 however, to indicate only the minimal number of subobjects to be 160 avoided. For instance it may be necessary to signal only the SRLGs 161 (or Shared Risk Groups) to avoid. 163 It is envisaged that most of the conventional inclusion subobjects 164 are specified in the signaled ERO only for the area where they are 165 pertinent. The number of subobjects to be avoided, specified in the 166 signaled XRO may be constant throughout the whole path setup, or the 167 subobjects to be avoided may be removed from the XRO as they become 168 irrelevant in the subsequent hops of the path setup. 170 For example, consider an LSP that traverses multiple computation 171 domains. A computation domain may be an area in the administrative 172 or IGP sense, or may be an arbitrary division of the network for 173 active management and path computational purposes. Let the primary 174 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: 176 o Xn denotes a node in domain X, and 178 o XYn denotes a node on the border of domain X and domain Y. 180 Note that Ingress is a node in domain A, and Egress is a node in 181 domain C. This is shown in Figure 1 where the domains correspond with 182 areas. 184 area A area B area C 185 <-------------------> <----------------> 186 <------------------> 188 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress 189 ^ \ / | \ / | \ / 190 | \ / | \ / | \ / 191 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4 192 | ^ ^ 193 | | | 194 | | ERO: (C3-strict, C4-strict, 195 | | Egress-strict) 196 | | XRO: Not needed 197 | | 198 | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) 199 | XRO: (BC1, C1, C2) 200 | 201 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) 202 XRO: (AB1, B1, B2, BC1, C1, C2, Egress) 204 Consider the establishment of a node-diverse protection path in the 205 example above. The protection path must avoid all nodes on the 206 primary path. The exclusions for area A are handled during 207 Constrained Shortest Path First (CSPF) computation at Ingress, so the 208 ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2- 209 strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2) respectively. 210 At AB2 the ERO and XRO could be (B3-strict, B4-strict, BC2-strict, 211 Egress-loose) and (BC1, C1, C2) respectively. At BC2 the ERO could 212 be (C3-strict, C4-strict, Egress-strict) and an XRO is not needed 213 from BC2 onwards. 215 In general, consideration should be given (as with explicit route) to 216 the size of signaled data and the impact on the signaling protocol. 218 2.2 Relationship to MPLS TE MIB 220 [RFC3812] defines managed objects for managing and modeling MPLS- 221 based traffic engineering. Included in [RFC3812] is a means to 222 configure explicit routes for use on specific LSPs. This 223 configuration allows the exclusion of certain resources. 225 In systems where the full explicit path is not computed at the 226 ingress (or at a path computation site for use at the ingress) it may 227 be necessary to signal those exclusions. This document offers a 228 means of doing this signaling. 230 3. Shared Risk Link Groups 232 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 233 RTG]. An SRLG ERO subobject is introduced such that it can be used 234 in the exclusion methods as described in the following sections. 235 This document does not assume or preclude any other usage for this 236 subobject. This subobject might also be appropriate for use within 237 Explicit Routes or Record Routes, but this is outside the scope of 238 this document. 240 3.1 SRLG ERO Subobject 242 The format of the ERO and its subobjects are defined in [RFC3209]. 243 The new SRLG subobject is defined by this document as follows. 245 0 1 2 3 246 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |L| Type | Length | SRLG Id (4 bytes) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | SRLG Id (continued) | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The L bit is an attribute of the subobject. The L bit is set 255 if the subobject represents a loose hop in the explicit route. 256 If the bit is not set, the subobject represents a strict hop in 257 the explicit route. 259 For exclusions (as used by XRO and EXRS defined in this 260 document), the L bit SHOULD be set to zero and ignored. 262 Type 264 The type of the subobject [TBD by IANA]. 266 Length 267 The Length contains the total length of the subobject in bytes, 268 including the Type and Length fields. The Length is always 8. 270 SRLG Id 272 The 32 bit identifier of the SRLG. 274 Reserved 276 This field is reserved. It MUST be set to zero on transmission 277 and MUST be ignored on receipt. 279 4. Exclude Route List 281 The exclude route identifies a list of abstract nodes that should not 282 be traversed along the path of the LSP being established. It is 283 RECOMMENDED to limit size of the exlude route list to a value local 284 to the node originating the exclude route list. 286 4.1 Exclude Route Object (XRO) 288 Abstract nodes to be excluded from the path are specified via the 289 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 291 Currently one C_Type is defined, Type 1 Exclude Route. The 292 EXCLUDE_ROUTE object has the following format: 294 Class = TBD by IANA, C_Type = 1 296 0 1 2 3 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 // (Subobjects) // 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Subobjects 307 The contents of an EXCLUDE_ROUTE object are a series of variable- 308 length data items called subobjects. This specification adapts ERO 309 subojbects as defined in [RFC3209], [RFC3473], and [RFC3477] for use 310 in route exclusions. The SRLG ERO subobject as defined in Section 3 311 of this document and its processing within ERO have not been defined 312 before. The SRLG ERO subobject is defined here for use with route 313 exclusions. 315 The following subobject types are supported. 317 Type Subobject 318 1 IPv4 prefix 319 2 IPv6 prefix 320 4 Unnumbered Interface ID 322 32 Autonomous system number 323 TBD SRLG 325 The defined values for Type above are specified in [RFC3209] and in 326 this document. 328 The concept of loose or strict hops has no meaning in route 329 exclusion. The L bit, defined for ERO subobjects in [RFC3209], is 330 reused here to indicate that an abstract node MUST be avoided (value 331 0) or SHOULD be avoided (value 1). 333 Subobjects 1, 2, and 4 refer to an interface or a set of interfaces. 334 An Attribute octet is introduced in these subobjects to indicate the 335 attribute (e.g. interface, node, SRLG) associated with the interfaces 336 that should be excluded from the path. For instance, the attribute 337 node allows a whole node to be excluded from the path by specifying 338 an interface of that node in the XRO subobject, in contrast to the 339 attribute interface, which allows a specific interface (or multiple 340 interfaces) to be excluded from the path without excluding the whole 341 nodes. The attribute SRLG allows all SRLGs associated with an 342 interface to be excluded from the path. 344 4.1.1 IPv4 prefix Subobject 346 0 1 2 3 347 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |L| Type | Length | IPv4 address (4 bytes) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | IPv4 address (continued) | Prefix Length | Attribute | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 L 357 0 indicates that the attribute specified MUST be excluded 359 1 indicates that the attribute specified SHOULD be avoided 361 Attribute 363 interface 365 0 indicates that the interface or set of interfaces 366 associated with the IPv4 prefix should be excluded or avoided 367 node 369 1 indicates that the node or set of nodes associated with 370 the IPv4 prefix should be excluded or avoided 372 SRLG 374 2 indicates that all the SRLGs associated with the IPv4 375 prefix should be excluded or avoided 377 The rest of the fields are as defined in [RFC3209]. 379 4.1.2 IPv6 Prefix Subobject 381 0 1 2 3 382 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |L| Type | Length | IPv6 address (16 bytes) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | IPv6 address (continued) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | IPv6 address (continued) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | IPv6 address (continued) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | IPv6 address (continued) | Prefix Length | Attribute | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 L 398 0 indicates that the attribute specified MUST be excluded 400 1 indicates that the attribute specified SHOULD be avoided 402 Attribute 403 interface 405 0 indicates that the interface or set of interfaces associated 406 with the IPv6 prefix should be excluded or avoided 408 node 410 1 indicates that the node or set of nodes associated with 411 the IPv6 prefix should be excluded or avoided 413 SRLG 415 2 indicates that all the SRLG associated with the IPv6 416 prefix should be excluded or avoided 418 The rest of the fields are as defined in [RFC3209]. 420 4.1.3 Unnumbered Interface ID Subobject 422 0 1 2 3 423 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |L| Type | Length | Reserved | Attribute | 427 | | | |(must be zero) | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | TE Router ID | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Interface ID (32 bits) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 L 436 0 indicates that the attribute specified MUST be excluded 438 1 indicates that the attribute specified SHOULD be avoided 440 Attribute 442 interface 444 0 indicates that the Interface ID specified should be 445 excluded or avoided 447 node 449 1 indicates that the node with the Router ID should be 450 excluded or avoided (this can be achieved using IPv4/v6 451 subobject as well, but is included here because it may be 452 convenient to use information from subobjects of an RRO 453 as defined in [RFC3477], in specifying the exclusions). 455 SRLG 457 2 indicates that all the SRLGs associated with the 458 interface should be excluded or avoided 460 Reserved 462 This field is reserved. It MUST be set to zero on transmission 463 and MUST be ignored on receipt. 465 The rest of the fields are as defined in [RFC3477]. 467 4.1.4 Autonomous System Number Subobject 469 The meaning of the L bit is as follows: 471 0 indicates that the abstract node specified MUST be excluded 473 1 indicates that the abstract node specified SHOULD be avoided 475 The rest of the fields are as defined in [RFC3209]. There is no 476 Attribute octet defined. 478 4.1.5 SRLG Subobject 480 The meaning of the L bit is as follows: 482 0 indicates that the SRLG specified MUST be excluded 484 1 indicates that the SRLG specified SHOULD be avoided 486 The Attribute octet is not present. The rest of the fields are as 487 defined in the "SRLG ERO Subobject" section of this document. 489 4.2 Processing Rules for the Exclude Route Object (XRO) 491 The exclude route list is encoded as a series of subobjects con- 492 tained in an EXCLUDE_ROUTE object. Each subobject identifies an 493 abstract node in the exclude route list. 495 Each abstract node may be a precisely specified IP address belonging 496 to a node, or an IP address with prefix identifying interfaces of a 497 group of nodes, or an Autonomous System. 499 The Explicit Route and routing processing is unchanged from the 500 description in [RFC3209] with the following additions: 502 1. When a Path message is received at a node, the node must check 503 that it is not a member of any of the abstract nodes in the XRO 504 if it is present in the Path message. If the node is a member of 505 any of the abstract nodes in the XRO with the L-flag set to 506 "exclude", it should return a PathErr with the error code 507 "Routing Problem" and error value of "Local node in Exclude 508 Route". If there are SRLGs in the XRO, the node should check 509 that the resources the node uses are not part of any SRLG with 510 the L-flag set to "exclude" that is specified in the XRO. If it 511 is, it should return a PathErr with error code "Routing Problem" 512 and error value of "Local node in Exclude Route". 514 2. Each subobject must be consistent. If a subobject is not con- 515 sistent then the node should return a PathErr with error code 516 "Routing Problem" and error value "Inconsistent Subobject". An 517 example of an inconsistent subobject is an IPv4 Prefix subobject 518 containing the IP address of a node and the attribute field is 519 set to "interface" or "SRLG". 521 3. The subobjects in the ERO and XRO MUST NOT contradict each other. 522 If a Path message is received that contains contradicting ERO and 523 XRO subobjects, then: 525 * subobjects in the XRO with the L flag not set (zero) MUST take 526 precedence over the subobjects in the ERO - that is, a 527 mandatory exclusion expressed in the XRO MUST be honored and 528 an implementation MUST reject such a Path message. This means 529 that a PathErr with error code "Routing Problem" and error 530 value of "Route blocked by Exclude Route" is returned. 532 * subobjects in the XRO with the L flag set do not take 533 precedence over ERO subobjects - that is, an implementation 534 MAY choose to reject a Path message because of such a 535 contradiction, but MAY continue and set up the LSP (ignoring 536 the XRO subobjects contradicting the ERO subobjects). 538 4. When choosing a next hop or expanding an explicit route to 539 include additional subobjects, a node: 541 1. must not introduce an explicit node or an abstract node that 542 equals or is a member of any abstract node that is specified 543 in the Exclude Route Object with the L-flag set to "exclude". 544 The number of introduced explicit nodes or abstract nodes 545 with the L flag set to "avoid", which indicate that it is not 546 mandatory to be excluded but that it is less preferred, 547 should be minimised in the computed path. 549 2. must not introduce links, nodes or resources identified by 550 the SRLG Id specified in the SRLG subobjects(s). The number 551 of introduced SLRGs with the L flag set to "avoid" should be 552 minimised. 554 If these rules preclude further forwarding of the Path message, 555 the node should return a PathErr with the error code "Routing 556 Problem" and error value of "Route blocked by Exclude Route". 558 Note that the subobjects in the XRO is an unordered list of 559 subobjects. 561 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 562 support the XRO, forward it uninspected and do not apply the 563 extensions to ERO processing described above. This approach is 564 chosen to allow route exclusion to traverse parts of the network that 565 are not capable of parsing or handling the new function. Note that 566 Record Route may be used to allow computing nodes to observe 567 violations of route exclusion and attempt to re-route the LSP 568 accordingly. 570 If a node supports the XRO, but not a particular subobject or part of 571 that subobject, then that particular subobject is ignored. Examples 572 of a part of a subobject that can be supported are: (1) only prefix 573 32 of the IPv4 prefix subobject could be supported, or (2) a 574 particular subobject is supported but not the particular attribute 575 field. 577 When a node forwards a Path message, it can do the following three 578 operations related to XRO besides the processing rules mentioned 579 above: 581 1. If no XRO was present, an XRO may be included. 583 2. If an XRO was present, it may remove the XRO if it is sure that 584 the next nodes do not need this information anymore. An example 585 is where a node can expand the ERO to a full strict path towards 586 the destination. See Figure 1 where BC2 is removing the XRO from 587 the Path message. 589 3. If an XRO was present, the content of the XRO can be modified. 590 Subobjects can be added or removed. See Figure 1 for an example 591 where AB2 is stripping off some subobjects. 593 In any case, a node MUST NOT introduce any explicit or abstract node 594 in the XRO (irrespective of the value of the L flag) that it also has 595 introduced in the ERO. 597 5. Explicit Exclusion Route 599 The Explicit Exclusion Route defines abstract nodes or resources 600 (such as links, unnumbered interfaces or labels) that must not or 601 should not be used on the path between two inclusive abstract nodes 602 or resources in the explicit route. 604 5.1 Explicit Exclusion Route Subobject (EXRS) 606 A new ERO subobject type is defined. The Explicit Exclusion Route 607 Subobject (EXRS) has type [TBD by IANA]. Although the EXRS is an ERO 608 subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT 609 be present in an XRO. An EXRS is an ERO subobject, which contains 610 one or more subobjects in its own, called EXRS subobjects. 612 The format of the EXRS is as follows: 614 0 1 2 3 615 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |L| Type | Length | Reserved | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 // one or more EXRS subobjects // 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 L 627 It MUST be set to zero on transmission and MUST be ignored on 628 receipt. [Note: The L bit in an EXRS subobject is as defined 629 for the XRO subobjects] 631 Type 633 The type of the subobject, i.e. EXRS [TBD by IANA] 635 Reserved 637 This field is reserved. It MUST be set to zero on transmission 638 and MUST be ignored on receipt. 640 EXRS subobjects 641 An EXRS subobject indicates the abstract node or resource to be 642 excluded. The format of an EXRS subobject is exactly the same 643 as the format of a subobject in the XRO. An EXRS may include 644 all subobjects defined in this document for the XRO. 646 Thus, an EXRS for an IP hop may look as follows: 648 0 1 2 3 649 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |L| Type | Length | Reserved | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |L| Type | Length | IPv4 address (4 bytes) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | IPv4 address (continued) | Prefix Length | Attribute | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 5.2 Processing Rules for the Explicit Exclusion Route Subobject (EXRS) 661 Each EXRS may carry multiple exclusions. The exclusion is encoded 662 exactly as for XRO subobjects and prefixed by an additional Type and 663 Length. 665 The scope of the exclusion is the step between the previous ERO 666 subobject that identifies an abstract node, and the subsequent ERO 667 subobject that identifies an abstract node. The processing rules of 668 the EXRS are the same as the processing rule of the XRO within this 669 scope. Multiple exclusions may be present between any pair of 670 abstract nodes. 672 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 673 Systems that must not be traversed on the path to the next abstract 674 node indicated in the ERO. 676 Exclusions may also indicate resources (such as unnumbered 677 interfaces, link ids, labels) that must not be used on the path to 678 the next abstract node indicated in the ERO. 680 SRLGs may also be indicated for exclusion from the path to the next 681 abstract node in the ERO by the inclusion of an EXRS containing an 682 SRLG subobject. If the L-bit value in the SRLG subobject is zero, 683 the resources (nodes, links, etc.) identified by the SRLG MUST not be 684 used on the path to the next abstract node indicated in the ERO. If 685 the L-bit is set, the resources identified by the SRLG SHOULD be 686 avoided. 688 If a node is called upon to process an EXRS and does not support 689 handling of exclusions it will behave as described in [RFC3209] when 690 an unrecognized ERO subobject is encountered. This means that this 691 node will return a PathErr with error code "Routing Error" and error 692 value "Bad Explicit Route Object" with the EXPLICIT_ROUTE object 693 inlcuded, truncated (on the left) to the offending EXRS. 695 If the presence of EXRS precludes further forwarding of the Path 696 message, the node should return a PathErr with the error code 697 "Routing Problem" and error value of "Route blocked by Exclude 698 Route". 700 6. Processing of XRO together with EXRS 702 When an LSR performs ERO expansion and finds both the XRO in the Path 703 message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes, 704 links and resources listed in both places. Where some elements 705 appears in both lists it MUST be handled according to the stricter 706 exclusion request - that is, if one list says that an SRLG, node, 707 link or resource must be excluded and the other says only that it 708 should be avoided then the element MUST be excluded. 710 7. Minimum compliance 712 An implementation must be at least compliant with the following: 714 1. The XRO MUST be supported with the following restrictions: 716 * The IPv4 Prefix subobject MUST be supported with a prefix 717 length of 32, and an attribute value of "interface" and 718 "node". Other prefix values and attribute values MAY be 719 supported. 721 * The IPv6 Prefix subobject MUST be supported with a prefix 722 length of 128, and an attribute value of "interface" and 723 "node". Other prefix values and attribute values MAY be 724 supported. 726 2. The EXRS MAY be supported. If supported, the same restrictions 727 as for the XRO apply. 729 3. If XRO or EXRS are supported, the implementation MUST be 730 compliant with the processing rules of the supported, not 731 supported, or partially supported subobjects as specified within 732 this document. 734 8. Security Considerations 736 The new exclude route object poses no security exposures over and 737 above [RFC3209] and [RFC3473]. Note that any security concerns that 738 exist with Explicit Routes should be considered with regard to route 739 exclusions. 741 9. IANA Considerations 743 It might be considered that an alternative approach would be to 744 assign one of the bits of the ERO sub-object type field (perhaps the 745 top bit) to identify that a sub-object is intended for inclusion 746 rather than exclusion. However, [RFC3209] states that the type field 747 (seven bits) should be assigned as 0 - 63 through IETF consensus 748 action, 64 - 95 as first come first served, and 96 - 127 are reserved 749 for private use. It would not be acceptable to disrupt existing 750 implementations so the only option would be to split the IETF 751 consensus range leaving only 32 sub-object types. It is felt that 752 that would be an unacceptably small number for future expansion of 753 the protocol. 755 9.1 New RSVP-TE Class Numbers 757 One new class number is required for Exclude Route object (XRO) 758 defined in section "Exclude Route Object (XRO)". 760 EXCLUDE_ROUTE 761 Class-Num of type 11bbbbbb 762 Suggested value 232 764 Defined CType: 1 (Exclude Route) 766 Subobjects 1, 2, 4 and 32 as for Explicit Route Object. 767 Additional SRLG subobject as requested in "New ERO and XRO 768 Subobject Type" 770 9.2 New ERO Subobject Type 772 The Explicit Exclusion Route subobject (EXRS) is defined in section 773 "Explicit Exclusion Route Subobject (EXRS)". This subobject may be 774 present in the Explicit Route Object, but not in the Route Record 775 Object, nor in the new Exclude Route Object. 777 Suggested value 33 779 9.3 New ERO and XRO Subobject Type 781 The SRLG subobject is defined in section "SRLG ERO Subobject". This 782 subobject may be present in the Exclude Route Object or in the 783 Explicit Route Object, but not in the Route Record Object. 785 Suggested value 34 787 9.4 New Error Codes 789 New error values are needed for the error code 'Routing Problem' 790 (24). 792 Unsupported Exclude Route Subobject Type Suggested value 64 793 Inconsistent Subobject Suggested value 65 794 Local Node in Exclude Route Suggested value 66 795 Route Blocked by Exclude Route Suggested value 67 797 10. Acknowledgments 799 This document reuses text from [RFC3209] for the description of 800 EXCLUDE_ROUTE. 802 The authors would like to express their thanks to Lou Berger, Steffen 803 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and 804 Richard Rabbat for their considered opinions on this draft. Also 805 thanks to Yakov Rekhter for reminding us about SRLGs! 807 11. References 809 11.1 Normative References 811 [GMPLS-RTG] 812 Kompella, K. and Y. Rekhter, "Routing Extensions in 813 Support of Generalized Multi-Protocol Label Switching", 814 draft-ietf-ccamp-gmpls-routing-9.txt, work in progress, 815 October 2003. 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, March 1997. 820 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 821 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 822 Tunnels", RFC 3209, December 2001. 824 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 825 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 826 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 828 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 829 in Resource ReSerVation Protocol - Traffic Engineering 830 (RSVP-TE)", RFC 3477, January 2003. 832 11.2 Informational References 834 [CRANKBACK] 835 Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. 836 Marshall-Unitt, "Crankback Signaling Extensions for MPLS 837 Signaling", draft-ietf-ccamp-crankback-02.txt, work in 838 progress, July 2004. 840 [INTERAS] De Cnodder, S. and C. Pelsser, "Protection for inter-AS 841 MPLS tunnels", 842 draft-decnodder-ccamp-interas-protection-00.txt, work in 843 progress, July 2004. 845 [INTERAS-REQ] 846 Zhang, R. and JP. Vasseur, "MPLS Inter-AS Traffic 847 Engineering requirements", 848 draft-ietf-tewg-interas-mpls-te-req-09.txt, work in 849 progress, September 2004. 851 [MPLS-BUNDLE] 852 Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 853 in MPLS Traffic Engineering", 854 draft-ietf-mpls-bundle-04.txt, work in progress, 855 July 2002. 857 [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 858 "GMPLS UNI: RSVP Support for the Overlay Model", 859 draft-ietf-ccamp-gmpls-overlay-04.txt, work in progress, 860 April 2004. 862 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 863 (TE) Extensions to OSPF Version 2", RFC 3630, 864 September 2003. 866 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 867 System (IS-IS) Extensions for Traffic Engineering (TE)", 868 RFC 3784, June 2004. 870 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 871 "Multiprotocol Label Switching (MPLS) Traffic Engineering 872 (TE) Management Information Base (MIB)", RFC 3812, 873 June 2004. 875 Authors' Addresses 877 Cheng-Yin Lee 878 Alcatel 879 600 March Road. 880 Ottawa, Ontario 881 Canada K2K 2E6 883 Email: Cheng-Yin.Lee@alcatel.com 885 Adrian Farrel 886 Old Dog Consulting 888 Phone: +44 (0) 1978 860944 889 Email: adrian@olddog.co.uk 891 Stefaan De Cnodder 892 Alcatel 893 Francis Wellesplein 1 894 B-2018 Antwerp 895 Belgium 897 Phone: +32 3 240 85 15 898 Email: stefaan.de_cnodder@alcatel.be 900 Appendix A. applications 902 This section describes some applications that can make use of the 903 XRO. The intention is to show that the XRO is not an application 904 specific object, but that it can be used for multiple purposes. In a 905 few examples, other solutions might be possible for that particular 906 case but the intention is to show that a single object can be used 907 for all the examples, hence making the XRO a rather generic object 908 without having to define a solution and new objects for each new 909 application. 911 A.1 Inter-area LSP protection 913 One method to establish an inter-area LSP is where the ingress router 914 selects an ABR, and then the ingress router computes a path towards 915 this selected ABR such that the configured constraints of the LSP are 916 fulfilled. In the example of figure A.1, an LSP has to be 917 established from node A in area 1 to node C in area 2. If no loose 918 hops are con- figured, then the computed ERO at A could looks as 919 follows: (A1- strict, A2-strict, ABR1-strict, C-loose). When the 920 Path message arrives at ABR1, then the ERO is (ABR1-strict, C-loose) 921 and it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). 922 Similar, at ABR3 the received ERO is (ABR3-strict, C-loose) and it 923 can be expanded to (C1-strict, C2-strict, C-strict). If also a 924 backup LSP has to be established, then A takes another ABR (ABR2 in 925 this case) and computes a path towards this ABR that fulfills the 926 constraints of the LSP and such that is disjoint from the path of the 927 primary LSP. The ERO generated by A looks as follows for this 928 example: (A3-strict, A4-strict, ABR2-strict, C-loose). 930 In order to let ABR2 expand the ERO, it also needs to know the path 931 of the primary LSP to expand the ERO such that it is disjoint from 932 the path of the primary LSP. Therefore, A also includes an XRO that 933 at least contains (ABR1, B1, ABR3, C1, C2). Based on these con- 934 straints, ABR2 can expand the ERO such that it is disjoint from the 935 primary LSP. In this example, the ERO computed by ABR2 would be (B2- 936 strict, ABR4-strict, C-loose), and the XRO generated by B contains at 937 least (ABR3, C1, C2). The latter information is needed to let ABR4 938 to expand the ERO such that the path is disjoint from the primary LSP 939 in area 2. 941 Area 1 Area 0 Area 2 942 <---------------><--------------><---------------> 944 +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ 945 | | | | | 946 | | | | | 947 A | | | C 948 | | | | | 949 | | | | | 950 +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+ 952 Figure A.1: Inter-area LSPs 954 In this example, a node performing the path computation, first 955 selects an ABR and then it computes a strict path towards this ABR. 956 For the backup LSP, all nodes of the primary LSP in the next areas 957 has to be put in the XRO (with the exception of the destination node 958 if node protection and no link protection is required). When an ABR 959 computes the next path segment, i.e. the path over the next area, it 960 may remove the nodes from the XRO that are located in that area with 961 the exception of the ABR where the primary LSP is exiting the area. 962 The latter information is still required because when the selected 963 ABR (ABR4 in this example) further expands the ERO, it has to exclude 964 the ABR on which the primary is entering that area (ABR3 in this 965 example). This means that when ABR2 generates an XRO, it may remove 966 the nodes in area 0 from the XRO but not ABR3. Note that not doing 967 this would not harm in this example because there is no path from 968 ABR4 to C via ABR3 in area2. If there is a link between ABR4- ABR3 969 and ABR3-C, then it is required to have ABR3 in the XRO gen- erated 970 by ABR2. 972 Discussion on the length of the XRO: when link or node protection is 973 requested, the length of the XRO is bounded by the length of the RRO 974 of the primary LSP. It can be made shorter by removing nodes by the 975 ingress node and the ABRs. In the example above, the RRO of the pri- 976 mary LSP contains 8 subobjects, while the maximum XRO length can be 977 bounded by 6 subobjects (nodes A1 and A2 do not have to be in the 978 XRO. For SRLG protection, the XRO has to list all SRLGs that are 979 crossed by the primary LSP. 981 A.2 Inter-AS LSP protection 983 When an inter-AS LSP is established, which has to be protected by a 984 backup LSP to provide link or node protection, the same method as for 985 the inter-area LSP case can be used. The difference is when the 986 backup LSP is not following the same AS-path as the primary LSP 987 because then the XRO should always contain the full path of the pri- 988 mary LSP. In case the backup LSP is following the same AS-path (but 989 with different ASBRs - at least in case of node protection), it is 990 similar to the inter-area case: ASBRs expanding the ERO over the next 991 AS may remove the XRO subobjects located in that AS. Note that this 992 can only be done by ingress ASBRs (the ASBR where the LSP is entering 993 the AS). 995 Discussion on the length of the XRO: the XRO is bounded by the length 996 of the RRO of the primary LSP. 998 Suppose that SRLG protection is required, and the ASs crossed by the 999 main LSP use a consistent way of allocating SRLG-ids to the links 1000 (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids 1001 of each link used by the main LSP can be recorded by means of the 1002 RRO, which are then used by the XRO. If the SRLG-ids are only 1003 meaningfull local to the AS, putting SRLG-ids in the XRO crossing 1004 many ASs makes no sense. More details on the method of providing 1005 SRLG protection for inter-AS LSPs can be found in [INTERAS]. 1006 Basically, the link IP address of the inter-AS link used by the 1007 primary LSP is put into the XRO of the Path message of the detour LSP 1008 or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is 1009 entering the AS can translate this into the list of SRLG-ids known to 1010 the local AS. 1012 Discussion on the length of the XRO: the XRO only contains 1 1013 subobject, which contains the IP address of the inter-AS link 1014 traversed by the primary LSP (assuming that the primary LSP and 1015 detour LSP or bypass tunnel are leaving the AS in the same area, and 1016 they are also entering the next AS in the same area). 1018 A.3 Protection in the GMPLS overlay model 1020 When an edge-node wants to establish an LSP towards another edge-node 1021 over an optical core network as described in [OVERLAY] (see figure 1022 A.2), the XRO can be used for multiple purposes. 1024 Overlay Overlay 1025 Network +--------------------------------+ Network 1027 +----------+ | | +----------+ 1028 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 1029 | | | | | | | | | | | | | | | | 1030 | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- | 1031 | | | | +--+--+ | | | | +---+--+ | | | | 1032 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 1033 | | | | | | | | | | | 1034 +----------+ | | | | | | | +----------+ 1035 | | | | | | | 1036 +----------+ | | | | | | | +----------+ 1037 | | | | +--+--+ | +--+--+ | | | | 1038 | +----+ | | | | | +------+ | | | | +----+ | 1039 | | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | | 1040 | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | 1041 | | | | | +-----+ +-----+ | | | | | 1042 | +----+ | | | | +----+ | 1043 | | +--------------------------------+ | | 1044 +----------+ Core Network +----------+ 1046 Overlay Overlay 1047 Network Network 1048 Legend: 1049 EN- Edge Node 1050 CN- Core Node 1052 Figure A.2 1054 A first application is where an edge-node wants to establish multiple 1055 LSPs towards the same destination edge-node, and these LSPs need to 1056 have as few or no SRLGs in common. In this case EN1 could establish 1057 an LSP towards EN3 and then it can establish a second LSP listing all 1058 links used by the first LSP with the indication to avoid the SRLGs of 1059 these links. This information can be used by CN1 to compute a path 1060 for the second LSP. If the core network consists of multiple areas, 1061 then the SRLG-ids have to be listed in the XRO. The same example 1062 applies to nodes and links. 1064 Another application is where the edge-node wants to set up a backup 1065 LSP that is also protecting the links between the edge-nodes and 1066 core-nodes. For instance, when EN2 establishes an LSP to EN4, it 1067 sends a Path message to CN4, which computes a path towards EN4 over 1068 for instance CN5. When EN2 gets back the RRO of that LSP, it can 1069 sig- nal a new LSP to CN1 with EN4 as destination and the XRO 1070 computed based on the RRO of the first LSP. Based on this 1071 information, CN1 can compute a path that has the requested diversity 1072 properties (e.g, a path going over CN2, CN3 and then to EN4). 1074 It is clear that in these examples, the core-node may not edit the 1075 RRO in a Resv message such that it includes only the subobjects from 1076 the egress core-node through the egress edge-node. 1078 A.4 LSP protection inside a single area 1080 The XRO can also be used inside a single area. Take for instance a 1081 network where the TE extensions of the IGPs as described in [RFC3630] 1082 and [RFC3784] are not used, and hence each node has to select a next- 1083 hop and possibly crankback [CRANKBACK] has to be used when there is 1084 no viable next-hop. In this case, when signaling a backup LSP, the 1085 XRO can be put in the Path message to exclude the links, nodes or 1086 SRLGs of the primary LSP. An alternative to provide this 1087 functionality would be to indicate in the Path message of the backup 1088 LSP, the primary LSP together with an indication which type of 1089 protection is required. This latter solution would work for link and 1090 node protec- tion, but not for SRLG protection. 1092 When link or node protection is requested, the XRO is of the same 1093 length as the RRO of the primary LSP. For SRLG protection, the XRO 1094 has to list all SRLGs that are crossed by the primary LSP. Note that 1095 for SRLG protection, the link IP address to reference the SRLGs of 1096 that link cannot be used since the TE extensions of the IGPs are not 1097 used in this example. Hence, a node cannot translate any link IP 1098 address located in that area to its SRLGs. 1100 Intellectual Property Statement 1102 The IETF takes no position regarding the validity or scope of any 1103 Intellectual Property Rights or other rights that might be claimed to 1104 pertain to the implementation or use of the technology described in 1105 this document or the extent to which any license under such rights 1106 might or might not be available; nor does it represent that it has 1107 made any independent effort to identify any such rights. Information 1108 on the procedures with respect to rights in RFC documents can be 1109 found in BCP 78 and BCP 79. 1111 Copies of IPR disclosures made to the IETF Secretariat and any 1112 assurances of licenses to be made available, or the result of an 1113 attempt made to obtain a general license or permission for the use of 1114 such proprietary rights by implementers or users of this 1115 specification can be obtained from the IETF on-line IPR repository at 1116 http://www.ietf.org/ipr. 1118 The IETF invites any interested party to bring to its attention any 1119 copyrights, patents or patent applications, or other proprietary 1120 rights that may cover technology that may be required to implement 1121 this standard. Please address the information to the IETF at 1122 ietf-ipr@ietf.org. 1124 Disclaimer of Validity 1126 This document and the information contained herein are provided on an 1127 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1128 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1129 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1130 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1131 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1132 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1134 Copyright Statement 1136 Copyright (C) The Internet Society (2005). This document is subject 1137 to the rights, licenses and restrictions contained in BCP 78, and 1138 except as set forth therein, the authors retain all their rights. 1140 Acknowledgment 1142 Funding for the RFC Editor function is currently provided by the 1143 Internet Society.