idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-06.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1155. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 763 has weird spacing: '...ce will poten...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2006) is 6344 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) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 3 errors (**), 0 flaws (~~), 3 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 A. Farrel (Old Dog Consulting) 3 Intended Status: Standards Track S. De Cnodder (Alcatel) 4 Updates: RFC3209 and RFC3473 November 2006 6 Exclude Routes - Extension to RSVP-TE 7 draft-ietf-ccamp-rsvp-te-exclude-route-06.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP 35 Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 36 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 37 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 38 abstract nodes and resources to be explicitly included in a path 39 setup, but not to be explicitly excluded. 41 In some networks where precise explicit paths are not computed at the 42 head end it may be useful to specify and signal abstract nodes and 43 resources that are to be explicitly excluded from routes. These 44 exclusions may apply to the whole path, or to parts of a path between 45 two abstract nodes specified in an explicit path. How Shared Risk 46 Link Groups (SLRGs) can be excluded is also specified in this 47 document. 49 This document specifies ways to communicate route exclusions during 50 path setup using RSVP-TE. 52 Requirements notation 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 4 62 1.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 5 63 2. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 6 64 2.1 SRLG Subobject . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 7 67 3.1.1 IPv4 prefix Subobject . . . . . . . . . . . . . . . . 8 68 3.1.2 IPv6 Prefix Subobject . . . . . . . . . . . . . . . . 9 69 3.1.3 Unnumbered Interface ID Subobject . . . . . . . . . . 10 70 3.1.4 Autonomous System Number Subobject . . . . . . . . . . 10 71 3.1.5 SRLG Subobject . . . . . . . . . . . . . . . . . . . . 11 72 3.2 Processing Rules for the Exclude Route Object (XRO) . . . 11 73 4. Explicit Exclusion Route . . . . . . . . . . . . . . . . . . . 13 74 4.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 13 75 4.2 Processing Rules for the Explicit Exclusion Route 76 Subobject (EXRS) . . . . . . . . . . . . . . . . . . . . . 15 77 5. Processing of XRO together with EXRS . . . . . . . . . . . . . 16 78 6. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 8.1 New ERO Subobject Type . . . . . . . . . . . . . . . . . . 17 82 8.2 New RSVP-TE Class Numbers . . . . . . . . . . . . . . . . 18 83 8.3 New Error Codes . . . . . . . . . . . . . . . . . . . . . 18 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.1 Normative References . . . . . . . . . . . . . . . . . . . 19 87 10.2 Informational References . . . . . . . . . . . . . . . . . 19 88 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 89 Apendix A. Aplications . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] 94 allow abstract nodes and resources to be explicitly included in a 95 path setup, using the Explicit Route Object (ERO). 97 In some systems it may be useful to specify and signal abstract nodes 98 and resources that are to be explicitly excluded from routes. This 99 may be because loose hops or abstract nodes need to be prevented from 100 selecting a route through a specific resource. This is a special 101 case of distributed path calculation in the network. 103 For example, route exclusion could be used in the case where two 104 non-overlapping Label Switched Paths (LSPs) are required. In this 105 case, one option might be to set up one path and collect its route 106 using route recording, and then to exclude the routers on that first 107 path from the setup for the second path. Another option might be to 108 set up two parallel backbones, dual home the provider edge (PE) 109 routers to both backbones, and then exclude the local router on 110 backbone A the first time that you set up an LSP (to a particular 111 distant PE), and exclude the local router on backbone B the second 112 time that you set up an LSP. 114 Two types of exclusions are required: 116 1. Exclusion of certain abstract nodes or resources on the whole 117 path. This set of abstract nodes is referred to as the Exclude 118 Route list. 120 2. Exclusion of certain abstract nodes or resources between a 121 specific pair of abstract nodes present in an ERO. Such specific 122 exclusions are referred to as Explicit Exclusion Route. 124 To convey these constructs within the signaling protocol, a new RSVP 125 object and a new ERO subobject are introduced respectively. 127 - A new RSVP-TE object is introduced to convey the Exclude Route 128 list. This object is the Exclude Route Object (XRO). 130 - The second type of exclusion is achieved through a modification to 131 the existing ERO. A new ERO subobject type the Explicit Exclusion 132 Route Subobject (EXRS) is introduced to indicate an exclusion 133 between a pair of included abstract nodes. 135 The knowledge of SRLGs, as defined in [RFC4216], may be used to 136 compute diverse paths that can be used for protection. In systems 137 where it is useful to signal exclusions, it may be useful to signal 138 SRLGs to indicate groups of resources that should be excluded on the 139 whole path or between two abstract nodes specified in an explicit 140 path. 142 This document introduces a subobject to indicate an SRLG to be 143 signaled in either of the two exclusion methods described above. This 144 document does not assume or preclude any other usage for this 145 subobject. This subobject might also be appropriate for use within an 146 Explicit Route object (ERO) or Record Route object (RRO), but this is 147 outside the scope of this document. 149 1.1 Scope of Exclude Routes 151 This document does not preclude a route exclusion from listing 152 arbitrary nodes or network elements to avoid. The intent is, 153 however, to indicate only the minimal number of subobjects to be 154 explicitly avoided. For instance it may be necessary to signal only 155 the SRLGs (or Shared Risk Groups) to avoid. That is, the route 156 exclusion is not intended to define the actual route by listing all 157 of the choices to exclude at each hop, but rather to constrain the 158 normal route selection process where loose hops or abstract nodes 159 are to be expanded by listing certain elements to be avoided. 161 It is envisaged that most of the conventional inclusion subobjects 162 are specified in the signaled ERO only for the area where they are 163 pertinent. The number of subobjects to be avoided, specified in the 164 signaled XRO may be constant throughout the whole path setup, or the 165 subobjects to be avoided may be removed from the XRO as they become 166 irrelevant in the subsequent hops of the path setup. 168 For example, consider an LSP that traverses multiple computation 169 domains. A computation domain may be an area in the administrative 170 or IGP sense, or may be an arbitrary division of the network for 171 active management and path computational purposes. Let the primary 172 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: 174 - Xn denotes a node in domain X, and 176 - XYn denotes a node on the border of domain X and domain Y. 178 Note that Ingress is a node in domain A, and Egress is a node in 179 domain C. This is shown in Figure 1 where the domains correspond with 180 areas. 182 area A area B area C 183 <-------------------> <----------------> <------------------> 185 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress 186 ^ \ / | \ / | \ / 187 | \ / | \ / | \ / 188 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4 189 | ^ ^ 190 | | | 191 | | | 192 | | ERO: (C3-strict, C4-strict, 193 | | Egress-strict) 194 | | XRO: Not needed 195 | | 196 | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) 197 | XRO: (BC1, C1, C2) 198 | 199 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) 200 XRO: (AB1, B1, B2, BC1, C1, C2, Egress) 202 Figure 1 : Domains Corresponding to IGP Areas 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 1.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 2. Shared Risk Link Groups 232 The identifier of a SRLG is defined as a 32 bit quantity in 233 [RFC4202]. An SRLG 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 Route object (ERO) or Record Route object (RRO), but this is 238 outside the scope of this document. 240 2.1 SRLG Subobject 242 The new SRLG subobject is defined by this document as follows. Its 243 format is modeled on the ERO subobjects defined in [RFC3209]. 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 L 255 The L bit is an attribute of the subobject. The L bit is set 256 if the subobject represents a loose hop in the explicit route. 257 If the bit is not set, the subobject represents a strict hop in 258 the explicit route. 260 For exclusions (as used by XRO and EXRS defined in this 261 document), the L bit SHOULD be set to zero and ignored. 263 Type 264 The type of the subobject (XX) 265 -- RFC Editor. Please replace XX with the value define by IANA and 266 -- remove this note. 268 Length 269 The Length contains the total length of the subobject in bytes, 270 including the Type and Length fields. The Length is always 8. 272 SRLG Id 273 The 32 bit identifier of the SRLG. 275 Reserved 276 This field is reserved. It SHOULD be set to zero on 277 transmission and MUST be ignored on receipt. 279 3. 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 exclude route list to a value local 284 to the node originating the exclude route list. 286 3.1 Exclude Route Object (XRO) 288 Abstract nodes to be excluded from the path are specified via the 289 EXCLUDE_ROUTE object (XRO). 291 Currently one C_Type is defined, Type 1 Exclude Route. The 292 EXCLUDE_ROUTE object has the following format: 294 Class = XX, C_Type = 1 295 -- RFC Editor. Please replace XX with the value define by IANA and 296 -- remove this note. 298 0 1 2 3 299 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 // (Subobjects) // 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 The contents of an EXCLUDE_ROUTE object are a series of variable- 308 length data items called subobjects. This specification adapts ERO 309 subobjects as defined in [RFC3209], [RFC3473], and [RFC3477] for 310 use in route exclusions. The SRLG subobject as defined in Section 2 311 of this document has not been defined before. The SRLG subobject is 312 defined here for use with route exclusions. 314 The following subobject types are supported. 316 Type Subobject 317 -------------+------------------------------- 318 1 IPv4 prefix 319 2 IPv6 prefix 320 4 Unnumbered Interface ID 321 32 Autonomous system number 322 XX SRLG 323 -- RFC Editor. Please replace XX with the value define by IANA and 324 -- remove this note. 326 The defined values for Type above are specified in [RFC3209] and in 327 this document. 329 The concept of loose or strict hops has no meaning in route 330 exclusion. The L bit, defined for ERO subobjects in [RFC3209], is 331 reused here to indicate that an abstract node MUST be excluded (value 332 0) or SHOULD be avoided (value 1). The distinction is that the path 333 of an LSP must not traverse an abstract node listed in the XRO with 334 the L bit clear, but may traverse one with the L bit set. A node 335 responsible for routing an LSP (for example, for expanding a loose 336 hop) should attempt to minimize the number of abstract nodes listed 337 in the XRO with the L bit set that are traversed by the LSP according 338 to local policy. A node generating XRO subobjects with the L bit set 339 must be prepared to accept an LSP that traverses one, some, or all of 340 the corresponding abstract nodes. 342 Subobjects 1, 2, and 4 refer to an interface or a set of interfaces. 343 An Attribute octet is introduced in these subobjects to indicate the 344 attribute (e.g. interface, node, SRLG) associated with the interfaces 345 that should be excluded from the path. For instance, the attribute 346 node allows a whole node to be excluded from the path by specifying 347 an interface of that node in the XRO subobject, in contrast to the 348 attribute interface, which allows a specific interface (or multiple 349 interfaces) to be excluded from the path without excluding the whole 350 nodes. The attribute SRLG allows all SRLGs associated with an 351 interface to be excluded from the path. 353 3.1.1 IPv4 prefix Subobject 355 0 1 2 3 356 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 |L| Type | Length | IPv4 address (4 bytes) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | IPv4 address (continued) | Prefix Length | Attribute | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 L 365 0 indicates that the attribute specified MUST be excluded 366 1 indicates that the attribute specified SHOULD be avoided 368 Attribute 370 Interface attribute values 371 0 indicates that the interface or set of interfaces 372 associated with the IPv4 prefix should be excluded or avoided 373 node 375 Node attribute value 376 1 indicates that the node or set of nodes associated with 377 the IPv4 prefix should be excluded or avoided 379 SRLG attribute values 380 2 indicates that all the SRLGs associated with the IPv4 381 prefix should be excluded or avoided 383 The rest of the fields are as defined in [RFC3209]. 385 3.1.2 IPv6 Prefix Subobject 387 0 1 2 3 388 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |L| Type | Length | IPv6 address (16 bytes) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | IPv6 address (continued) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | IPv6 address (continued) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | IPv6 address (continued) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | IPv6 address (continued) | Prefix Length | Attribute | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 L 403 0 indicates that the attribute specified MUST be excluded 404 1 indicates that the attribute specified SHOULD be avoided 406 Attribute 408 Interface attribute value 409 0 indicates that the interface or set of interfaces associated 410 with the IPv6 prefix should be excluded or avoided 412 Node attribute value 413 1 indicates that the node or set of nodes associated with 414 the IPv6 prefix should be excluded or avoided 416 SRLG attribute value 417 2 indicates that all the SRLG associated with the IPv6 418 prefix should be excluded or avoided 420 The rest of the fields are as defined in [RFC3209]. 422 3.1.3 Unnumbered Interface ID Subobject 424 0 1 2 3 425 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |L| Type | Length | Reserved | Attribute | 429 | | | |(must be zero) | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | TE Router ID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Interface ID (32 bits) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 L 437 0 indicates that the attribute specified MUST be excluded 438 1 indicates that the attribute specified SHOULD be avoided 440 Attribute 442 Interface attribute value 443 0 indicates that the Interface ID specified should be 444 excluded or avoided 446 Node attribute value 447 1 indicates that the node with the Router ID should be 448 excluded or avoided (this can be achieved using IPv4/v6 449 subobject as well, but is included here because it may be 450 convenient to use information from subobjects of an RRO 451 as defined in [RFC3477], in specifying the exclusions). 453 SRLG attribute value 454 2 indicates that all the SRLGs associated with the 455 interface should be excluded or avoided 457 Reserved 458 This field is reserved. It SHOULD be set to zero on 459 transmission and MUST be ignored on receipt. 461 The rest of the fields are as defined in [RFC3477]. 463 3.1.4 Autonomous System Number Subobject 465 The meaning of the L bit is as follows: 466 0 indicates that the abstract node specified MUST be excluded 467 1 indicates that the abstract node specified SHOULD be avoided 469 The rest of the fields are as defined in [RFC3209]. There is no 470 Attribute octet defined. 472 3.1.5 SRLG Subobject 474 The meaning of the L bit is as follows: 475 0 indicates that the SRLG specified MUST be excluded 476 1 indicates that the SRLG specified SHOULD be avoided 478 The Attribute octet is not present. The rest of the fields are as 479 defined in the "SRLG Subobject" section of this document. 481 3.2 Processing Rules for the Exclude Route Object (XRO) 483 The exclude route list is encoded as a series of subobjects con- 484 tained in an EXCLUDE_ROUTE object. Each subobject identifies an 485 abstract node in the exclude route list. 487 Each abstract node may be a precisely specified IP address belonging 488 to a node, or an IP address with prefix identifying interfaces of a 489 group of nodes, an Autonomous System, or an SRLG. 491 The Explicit Route and routing processing is unchanged from the 492 description in [RFC3209] with the following additions: 494 1. When a Path message is received at a node, the node MUST check 495 that it is not a member of any of the abstract nodes in the XRO 496 if it is present in the Path message. If the node is a member of 497 any of the abstract nodes in the XRO with the L-flag set to 498 "exclude", it SHOULD return a PathErr with the error code 499 "Routing Problem" and error value of "Local node in Exclude 500 Route". If there are SRLGs in the XRO, the node SHOULD check 501 that the resources the node uses are not part of any SRLG with 502 the L-flag set to "exclude" that is specified in the XRO. If it 503 is, it SHOULD return a PathErr with error code "Routing Problem" 504 and error value of "Local node in Exclude Route". 506 2. Each subobject MUST be consistent. If a subobject is not con- 507 sistent then the node SHOULD return a PathErr with error code 508 "Routing Problem" and error value "Inconsistent Subobject". An 509 example of an inconsistent subobject is an IPv4 Prefix subobject 510 containing the IP address of a node and the attribute field is 511 set to "interface" or "SRLG". 513 3. The subobjects in the ERO and XRO SHOULD NOT contradict each 514 other. If a Path message is received that contains contradicting 515 ERO and XRO subobjects, then: 517 - subobjects in the XRO with the L flag not set (zero) MUST take 518 precedence over the subobjects in the ERO - that is, a 519 mandatory exclusion expressed in the XRO MUST be honored and 520 an implementation MUST reject such a Path message. This means 521 that a PathErr with error code "Routing Problem" and error 522 value of "Route blocked by Exclude Route" is returned. 524 - subobjects in the XRO with the L flag set do not take 525 precedence over ERO subobjects - that is, an implementation 526 MAY choose to reject a Path message because of such a 527 contradiction, but MAY continue and set up the LSP (ignoring 528 the XRO subobjects contradicting the ERO subobjects). 530 4. When choosing a next hop or expanding an explicit route to 531 include additional subobjects, a node: 533 a. MUST NOT introduce an explicit node or an abstract node that 534 equals or is a member of any abstract node that is specified 535 in the Exclude Route Object with the L-flag set to "exclude". 536 The number of introduced explicit nodes or abstract nodes 537 with the L flag set to "avoid", which indicate that it is not 538 mandatory to be excluded but that it is less preferred, 539 SHOULD be minimized in the computed path. 541 b. MUST NOT introduce links, nodes or resources identified by 542 the SRLG Id specified in the SRLG subobjects(s). The number 543 of introduced SLRGs with the L flag set to "avoid" SHOULD be 544 minimized. 546 If these rules preclude further forwarding of the Path message, 547 the node SHOULD return a PathErr with the error code "Routing 548 Problem" and error value of "Route blocked by Exclude Route". 550 Note that the subobjects in the XRO is an unordered list of 551 subobjects. 553 A node receiving a Path message carrying an XRO MAY reject the 554 message if the XRO is too large or complicated for the local 555 implementation or as governed by local policy. In this case, the 556 node MUST send a PathErr message with the error code "Routing Error" 557 and error value "XRO Too Complex". An ingress LSR receiving this 558 error code/value combination MAY reduce the complexity of the XRO or 559 route around the node that rejected the XRO. 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 4. 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 4.1 Explicit Exclusion Route Subobject (EXRS) 606 A new ERO subobject type is defined. The Explicit Exclusion Route 607 Subobject (EXRS) has type XX. Although the EXRS is an ERO subobject 608 and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present 609 in an XRO. An EXRS is an ERO subobject, which contains one or more 610 subobjects in its own, called EXRS subobjects. 611 -- RFC Editor. Please replace XX with the value define by IANA and 612 -- remove this note. 614 The format of the EXRS is as follows: 616 0 1 2 3 617 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |L| Type | Length | Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | 623 // one or more EXRS subobjects // 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 L 628 It MUST be set to zero on transmission and MUST be ignored on 629 receipt. [Note: The L bit in an EXRS subobject is as defined 630 for the XRO subobjects] 632 Type 633 The type of the subobject (XX). 634 -- RFC Editor. Please replace XX with the value define by IANA and 635 -- remove this note. 637 Reserved 638 This field is reserved. It SHOULD be set to zero on 639 transmission and MUST be ignored on receipt. 641 EXRS subobjects 642 An EXRS subobject indicates the abstract node or resource to be 643 excluded. The format of an EXRS subobject is exactly the same 644 as the format of a subobject in the XRO. An EXRS may include 645 all subobjects defined in this document for the XRO. 647 Thus, an EXRS for an IP hop may look as follows: 649 0 1 2 3 650 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |L| Type | Length | Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |L| Type | Length | IPv4 address (4 bytes) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | IPv4 address (continued) | Prefix Length | Attribute | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 4.2 Processing Rules for the Explicit Exclusion Route Subobject (EXRS) 662 Each EXRS may carry multiple exclusions. The exclusion is encoded 663 exactly as for XRO subobjects and prefixed by an additional Type and 664 Length. 666 The scope of the exclusion is the step between the previous ERO 667 subobject that identifies an abstract node, and the subsequent ERO 668 subobject that identifies an abstract node. The processing rules of 669 the EXRS are the same as the processing rule of the XRO within this 670 scope. Multiple exclusions may be present between any pair of 671 abstract nodes. 673 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 674 Systems that must not be traversed on the path to the next abstract 675 node indicated in the ERO. 677 Exclusions may also indicate resources (such as unnumbered 678 interfaces, link ids, labels) that must not be used on the path to 679 the next abstract node indicated in the ERO. 681 SRLGs may also be indicated for exclusion from the path to the next 682 abstract node in the ERO by the inclusion of an EXRS containing an 683 SRLG subobject. If the L-bit in the SRLG subobject is zero, the 684 resources (nodes, links, etc.) identified by the SRLG MUST NOT be 685 used on the path to the next abstract node indicated in the ERO. If 686 the L-bit is set, the resources identified by the SRLG SHOULD be 687 avoided. 689 If a node is called upon to process an EXRS and does not support 690 handling of exclusions it will behave as described in [RFC3209] when 691 an unrecognized ERO subobject is encountered. This means that this 692 node will return a PathErr with error code "Routing Error" and error 693 value "Bad Explicit Route Object" with the EXPLICIT_ROUTE object 694 inlcuded, truncated (on the left) to the offending EXRS. 696 If the presence of EXRS precludes further forwarding of the Path 697 message, the node SHOULD return a PathErr with the error code 698 "Routing Problem" and error value "Route blocked by Exclude Route". 700 A node MAY reject a Path message if the EXRS is too large or 701 complicated for the local implementation or as governed by local 702 policy. In this case, the node MUST send a PathErr message with the 703 error code "Routing Error" and error value "EXRS Too Complex". An 704 ingress LSR receiving this error code/value combination MAY reduce 705 the complexity of the EXRS or route around the node that rejected 706 the EXRS. 708 5. Processing of XRO together with EXRS 710 When an LSR performs ERO expansion and finds both the XRO in the Path 711 message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes, 712 links and resources listed in both places. Where some elements 713 appears in both lists it MUST be handled according to the stricter 714 exclusion request - that is, if one list says that an SRLG, node, 715 link or resource must be excluded and the other says only that it 716 should be avoided then the element MUST be excluded. 718 6. Minimum compliance 720 An implementation MUST be at least compliant with the following: 722 1. The XRO MUST be supported with the following restrictions: 724 - The IPv4 Prefix subobject MUST be supported with a prefix 725 length of 32, and an attribute value of "interface" and 726 "node". Other prefix values and attribute values MAY be 727 supported. 729 - The IPv6 Prefix subobject MUST be supported with a prefix 730 length of 128, and an attribute value of "interface" and 731 "node". Other prefix values and attribute values MAY be 732 supported. 734 2. The EXRS MAY be supported. If supported, the same restrictions 735 as for the XRO apply. If not supported, an EXRS encountered 736 during normal ERO processing MUST be rejected as an unknown 737 ERO subobject as described in Section 4.2. Note that a node 738 SHOULD NOT parse ahead into an ERO, and if it does, MUST NOT 739 reject the ERO if it discovers an EXRS that applies to another 740 node. 742 3. If XRO or EXRS are supported, the implementation MUST be 743 compliant with the processing rules of the supported, not 744 supported, or partially supported subobjects as specified within 745 this document. 747 7. Security Considerations 749 Security considerations for MPLS-TE and GMPLS signaling are covered 750 in [RFC3209] and [RFC3473]. This document does not introduce any new 751 messages or any substantive new processing, and so those security 752 considerations continue to apply. 754 Note that any security concerns that exist with explicit routes 755 should be considered with regard to route exclusions. For example, 756 some administrative boundaries may consider explicit routes to be 757 security violations and may strip EROs from the Path messages that 758 they process. In this case, the XRO should also be considered for 759 removal from the Path message. 761 It is possible that an arbitrarily complex XRO or EXRS sequence could 762 be introduced as a form of denial of service attack since its 763 presence will potentially cause additional processing at each node 764 on the path of the LSP. It should be noted that such an attack 765 assumes that an otherwise trusted LSR (i.e., one that has been 766 authenticated by its neighbors) is misbehaving. A node that receives 767 an XRO or EXRS sequence that it considers too complex according to 768 its local policy may respond with a PathErr message carrying the 769 error code "Routing Error" and error value "XRO Too Complex" or "EXRS 770 Too Complex". 772 8. IANA Considerations 774 It might be considered that an alternative approach would be to 775 assign one of the bits of the ERO sub-object type field (perhaps the 776 top bit) to identify that a sub-object is intended for inclusion 777 rather than exclusion. However, [RFC3209] states that the type field 778 (seven bits) should be assigned as 0 - 63 through IETF consensus 779 action, 64 - 95 as first come first served, and 96 - 127 are reserved 780 for private use. It would not be acceptable to disrupt existing 781 implementations so the only option would be to split the IETF 782 consensus range leaving only 32 sub-object types. It is felt that 783 that would be an unacceptably small number for future expansion of 784 the protocol. 786 8.1 New ERO Subobject Type 788 IANA registry: RSVP PARAMETERS 789 Subsection: Class Names, Class Numbers, and Class Types 791 Add a new subobject of the existing entry for: 793 20 EXPLICIT_ROUTE 795 The text should read: 797 33 Explicit Exclusion Route subobject (EXRS) 799 The Explicit Exclusion Route subobject (EXRS) is defined in section 800 "Explicit Exclusion Route Subobject (EXRS)". This subobject may be 801 present in the Explicit Route Object, but not in the Route Record 802 Object, nor in the new Exclude Route Object and should not be listed 803 among the subobjects for those objects. 805 Suggested value 33 807 8.2 New RSVP-TE Class Numbers 809 IANA registry: RSVP PARAMETERS 810 Subsection: Class Names, Class Numbers, and Class Types 812 One new class number is required for Exclude Route object (XRO) 813 defined in Section "Exclude Route Object (XRO)". 815 EXCLUDE_ROUTE 816 Class-Num of type 11bbbbbb 817 Suggested value 232 818 Defined CType: 1 (Exclude Route) 820 Subobjects 1, 2, 4 and 32 as for Explicit Route Object. 821 Additional subobject as requested in Section "New ERO and XRO 822 Subobject Type". The text should appear as: 824 Sub-object type 825 1 IPv4 address [RFC3209] 826 2 IPv6 address [RFC3209] 827 4 Unnumbered Interface ID [RFC3477] 828 32 Autonomous system number [RFC3209] 829 33 Explicit Exclusion Route subobject (EXRS) [this doc] 830 34 SRLG [this doc] 832 The SRLG subobject is defined in section "SRLG Subobject". The value 833 34 is suggested. 835 8.3 New Error Codes 837 IANA registry: RSVP PARAMETERS 838 Subsection: Error Codes and Globally-Defined Error Value Sub-Codes 840 New Error Values sub-codes are needed for the Error Code 'Routing 841 Problem' (24). 843 Unsupported Exclude Route Subobject Type Suggested value 64 844 Inconsistent Subobject Suggested value 65 845 Local Node in Exclude Route Suggested value 66 846 Route Blocked by Exclude Route Suggested value 67 847 XRO Too Complex Suggested value 68 848 EXRS Too Complex Suggested value 69 850 9. Acknowledgments 852 This document reuses text from [RFC3209] for the description of 853 EXCLUDE_ROUTE. 855 The authors would like to express their thanks to Lou Berger, Steffen 856 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and 857 Richard Rabbat for their considered opinions on this draft. Also 858 thanks to Yakov Rekhter for reminding us about SRLGs! 860 Thanks to Eric Gray for providing GenArt review and to Ross Callon 861 for his comments. 863 10. References 865 10.1 Normative References 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, March 1997. 870 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 871 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 872 Tunnels", RFC 3209, December 2001. 874 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 875 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 876 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 878 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 879 in Resource ReSerVation Protocol - Traffic Engineering 880 (RSVP-TE)", RFC 3477, January 2003. 882 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 883 Support of Generalized Multi-Protocol Label Switching 884 (GMPLS)", RFC 4202, October 2005. 886 10.2 Informational References 888 [CRANKBACK] 889 Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. 890 Marshall-Unitt, "Crankback Signaling Extensions for MPLS 891 Signaling", draft-ietf-ccamp-crankback, work in progress. 893 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 894 (TE) Extensions to OSPF Version 2", RFC 3630, 895 September 2003. 897 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 898 System (IS-IS) Extensions for Traffic Engineering (TE)", 899 RFC 3784, June 2004. 901 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 902 "Multiprotocol Label Switching (MPLS) Traffic Engineering 903 (TE) Management Information Base (MIB)", RFC 3812, 904 June 2004. 906 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 907 "Generalized Multiprotocol Label Switching (GMPLS) 908 User-Network Interface (UNI): Resource ReserVation 909 Protocol-Traffic Engineering (RSVP-TE) Support for the 910 Overlay Model", RFC 4208, October 2005. 912 [RFC4216] Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System 913 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 914 November 2005. 916 11. Authors' Addresses 918 Cheng-Yin Lee 919 Email: c.yin.lee@gmail.com 921 Adrian Farrel 922 Old Dog Consulting 923 Phone: +44 (0) 1978 860944 924 Email: adrian@olddog.co.uk 926 Stefaan De Cnodder 927 Alcatel 928 Francis Wellesplein 1 929 B-2018 Antwerp 930 Belgium 931 Phone: +32 3 240 85 15 932 Email: stefaan.de_cnodder@alcatel.be 934 Appendix A. Applications 936 This section describes some applications that can make use of the 937 XRO. The intention is to show that the XRO is not an application 938 specific object, but that it can be used for multiple purposes. In a 939 few examples, other solutions might be possible for that particular 940 case but the intention is to show that a single object can be used 941 for all the examples, hence making the XRO a rather generic object 942 without having to define a solution and new objects for each new 943 application. 945 A.1 Inter-area LSP protection 947 One method to establish an inter-area LSP is where the ingress router 948 selects an ABR, and then the ingress router computes a path towards 949 this selected ABR such that the configured constraints of the LSP are 950 fulfilled. In the example of figure A.1, an LSP has to be 951 established from node A in area 1 to node C in area 2. If no loose 952 hops are con- figured, then the computed ERO at A could looks as 953 follows: (A1- strict, A2-strict, ABR1-strict, C-loose). When the 954 Path message arrives at ABR1, then the ERO is (ABR1-strict, C-loose) 955 and it can be expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). 956 Similar, at ABR3 the received ERO is (ABR3-strict, C-loose) and it 957 can be expanded to (C1-strict, C2-strict, C-strict). If also a 958 backup LSP has to be established, then A takes another ABR (ABR2 in 959 this case) and computes a path towards this ABR that fulfills the 960 constraints of the LSP and such that is disjoint from the path of the 961 primary LSP. The ERO generated by A looks as follows for this 962 example: (A3-strict, A4-strict, ABR2-strict, C-loose). 964 In order to let ABR2 expand the ERO, it also needs to know the path 965 of the primary LSP to expand the ERO such that it is disjoint from 966 the path of the primary LSP. Therefore, A also includes an XRO that 967 at least contains (ABR1, B1, ABR3, C1, C2). Based on these con- 968 straints, ABR2 can expand the ERO such that it is disjoint from the 969 primary LSP. In this example, the ERO computed by ABR2 would be (B2- 970 strict, ABR4-strict, C-loose), and the XRO generated by B contains at 971 least (ABR3, C1, C2). The latter information is needed to let ABR4 972 to expand the ERO such that the path is disjoint from the primary LSP 973 in area 2. 975 Area 1 Area 0 Area 2 976 <---------------><--------------><---------------> 978 +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ 979 | | | | | 980 | | | | | 981 A | | | C 982 | | | | | 983 | | | | | 984 +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+ 986 Figure A.1: Inter-area LSPs 988 In this example, a node performing the path computation, first 989 selects an ABR and then it computes a strict path towards this ABR. 990 For the backup LSP, all nodes of the primary LSP in the next areas 991 has to be put in the XRO (with the exception of the destination node 992 if node protection and no link protection is required). When an ABR 993 computes the next path segment, i.e. the path over the next area, it 994 may remove the nodes from the XRO that are located in that area with 995 the exception of the ABR where the primary LSP is exiting the area. 996 The latter information is still required because when the selected 997 ABR (ABR4 in this example) further expands the ERO, it has to exclude 998 the ABR on which the primary is entering that area (ABR3 in this 999 example). This means that when ABR2 generates an XRO, it may remove 1000 the nodes in area 0 from the XRO but not ABR3. Note that not doing 1001 this would not harm in this example because there is no path from 1002 ABR4 to C via ABR3 in area2. If there is a link between ABR4- ABR3 1003 and ABR3-C, then it is required to have ABR3 in the XRO gen- erated 1004 by ABR2. 1006 Discussion on the length of the XRO: when link or node protection is 1007 requested, the length of the XRO is bounded by the length of the RRO 1008 of the primary LSP. It can be made shorter by removing nodes by the 1009 ingress node and the ABRs. In the example above, the RRO of the pri- 1010 mary LSP contains 8 subobjects, while the maximum XRO length can be 1011 bounded by 6 subobjects (nodes A1 and A2 do not have to be in the 1012 XRO. For SRLG protection, the XRO has to list all SRLGs that are 1013 crossed by the primary LSP. 1015 A.2 Inter-AS LSP protection 1017 When an inter-AS LSP is established, which has to be protected by a 1018 backup LSP to provide link or node protection, the same method as for 1019 the inter-area LSP case can be used. The difference is when the 1020 backup LSP is not following the same AS-path as the primary LSP 1021 because then the XRO should always contain the full path of the pri- 1022 mary LSP. In case the backup LSP is following the same AS-path (but 1023 with different ASBRs - at least in case of node protection), it is 1024 similar to the inter-area case: ASBRs expanding the ERO over the next 1025 AS may remove the XRO subobjects located in that AS. Note that this 1026 can only be done by ingress ASBRs (the ASBR where the LSP is entering 1027 the AS). 1029 Discussion on the length of the XRO: the XRO is bounded by the length 1030 of the RRO of the primary LSP. 1032 Suppose that SRLG protection is required, and the ASs crossed by the 1033 main LSP use a consistent way of allocating SRLG-ids to the links 1034 (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids 1035 of each link used by the main LSP can be recorded by means of the 1036 RRO, which are then used by the XRO. If the SRLG-ids are only 1037 meaningfull local to the AS, putting SRLG-ids in the XRO crossing 1038 many ASs makes no sense. To provide SRLG protection for inter-AS LSPs 1039 the link IP address of the inter-AS link used by the primary LSP can 1040 be put into the XRO of the Path message of the detour LSP or bypass 1041 tunnel. The ASBR where the detour LSP or bypass tunnel is entering 1042 the AS can translate this into the list of SRLG-ids known to the 1043 local AS. 1045 Discussion on the length of the XRO: the XRO only contains 1 1046 subobject, which contains the IP address of the inter-AS link 1047 traversed by the primary LSP (assuming that the primary LSP and 1048 detour LSP or bypass tunnel are leaving the AS in the same area, and 1049 they are also entering the next AS in the same area). 1051 A.3 Protection in the GMPLS overlay model 1053 When an edge-node wants to establish an LSP towards another edge-node 1054 over an optical core network as described in [RFC4208] (see figure 1055 A.2), the XRO can be used for multiple purposes. 1057 Overlay Overlay 1058 Network +--------------------------------+ Network 1059 +----------+ | | +----------+ 1060 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 1061 | | | | | | | | | | | | | | | | 1062 | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- | 1063 | | | | +--+--+ | | | | +---+--+ | | | | 1064 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 1065 | | | | | | | | | | | 1066 +----------+ | | | | | | | +----------+ 1067 | | | | | | | 1068 +----------+ | | | | | | | +----------+ 1069 | | | | +--+--+ | +--+--+ | | | | 1070 | +----+ | | | | | +------+ | | | | +----+ | 1071 | | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | | 1072 | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | 1073 | | | | | +-----+ +-----+ | | | | | 1074 | +----+ | | | | +----+ | 1075 | | +--------------------------------+ | | 1076 +----------+ Core Network +----------+ 1078 Overlay Overlay 1079 Network Network 1081 Legend: 1082 EN- Edge Node 1083 CN- Core Node 1085 Figure A.2 1087 A first application is where an edge-node wants to establish multiple 1088 LSPs towards the same destination edge-node, and these LSPs need to 1089 have as few or no SRLGs in common. In this case EN1 could establish 1090 an LSP towards EN3 and then it can establish a second LSP listing all 1091 links used by the first LSP with the indication to avoid the SRLGs of 1092 these links. This information can be used by CN1 to compute a path 1093 for the second LSP. If the core network consists of multiple areas, 1094 then the SRLG-ids have to be listed in the XRO. The same example 1095 applies to nodes and links. 1097 Another application is where the edge-node wants to set up a backup 1098 LSP that is also protecting the links between the edge-nodes and 1099 core-nodes. For instance, when EN2 establishes an LSP to EN4, it 1100 sends a Path message to CN4, which computes a path towards EN4 over 1101 for instance CN5. When EN2 gets back the RRO of that LSP, it can 1102 sig- nal a new LSP to CN1 with EN4 as destination and the XRO 1103 computed based on the RRO of the first LSP. Based on this 1104 information, CN1 can compute a path that has the requested diversity 1105 properties (e.g, a path going over CN2, CN3 and then to EN4). 1107 It is clear that in these examples, the core-node may not edit the 1108 RRO in a Resv message such that it includes only the subobjects from 1109 the egress core-node through the egress edge-node. 1111 A.4 LSP protection inside a single area 1113 The XRO can also be used inside a single area. Take for instance a 1114 network where the TE extensions of the IGPs as described in [RFC3630] 1115 and [RFC3784] are not used, and hence each node has to select a next- 1116 hop and possibly crankback [CRANKBACK] has to be used when there is 1117 no viable next-hop. In this case, when signaling a backup LSP, the 1118 XRO can be put in the Path message to exclude the links, nodes or 1119 SRLGs of the primary LSP. An alternative to provide this 1120 functionality would be to indicate in the Path message of the backup 1121 LSP, the primary LSP together with an indication which type of 1122 protection is required. This latter solution would work for link and 1123 node protec- tion, but not for SRLG protection. 1125 When link or node protection is requested, the XRO is of the same 1126 length as the RRO of the primary LSP. For SRLG protection, the XRO 1127 has to list all SRLGs that are crossed by the primary LSP. Note that 1128 for SRLG protection, the link IP address to reference the SRLGs of 1129 that link cannot be used since the TE extensions of the IGPs are not 1130 used in this example. Hence, a node cannot translate any link IP 1131 address located in that area to its SRLGs. 1133 Intellectual Property Statement 1135 The IETF takes no position regarding the validity or scope of any 1136 Intellectual Property Rights or other rights that might be claimed to 1137 pertain to the implementation or use of the technology described in 1138 this document or the extent to which any license under such rights 1139 might or might not be available; nor does it represent that it has 1140 made any independent effort to identify any such rights. Information 1141 on the procedures with respect to rights in RFC documents can be 1142 found in BCP 78 and BCP 79. 1144 Copies of IPR disclosures made to the IETF Secretariat and any 1145 assurances of licenses to be made available, or the result of an 1146 attempt made to obtain a general license or permission for the use of 1147 such proprietary rights by implementers or users of this 1148 specification can be obtained from the IETF on-line IPR repository at 1149 http://www.ietf.org/ipr. 1151 The IETF invites any interested party to bring to its attention any 1152 copyrights, patents or patent applications, or other proprietary 1153 rights that may cover technology that may be required to implement 1154 this standard. Please address the information to the IETF at 1155 ietf-ipr@ietf.org. 1157 Disclaimer of Validity 1159 This document and the information contained herein are provided on an 1160 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1161 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1162 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1163 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1164 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1165 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1167 Copyright Statement 1169 Copyright (C) The IETF Trust (2006). 1171 This document is subject to the rights, licenses and restrictions 1172 contained in BCP 78, and except as set forth therein, the authors 1173 retain all their rights.