idnits 2.17.1 draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3473], [RFC4874], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2013) is 3944 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental V. Kondreddy 5 Expires: January 10, 2014 Huawei Technologies 6 R. Casellas 7 CTTC 8 July 9, 2013 10 Domain Subobjects for Resource ReserVation Protocol - Traffic 11 Engineering (RSVP-TE) 12 draft-dhody-ccamp-rsvp-te-domain-subobjects-02 14 Abstract 16 The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) 17 specification [RFC3209] and the Generalized Multiprotocol Label 18 Switching (GMPLS) extensions to RSVP-TE [RFC3473] allow abstract 19 nodes and resources to be explicitly included in a path setup. 20 Further Exclude Routes extensions [RFC4874] allow abstract nodes and 21 resources to be explicitly excluded in a path setup. 23 This document specifies new subobjects to include or exclude domains 24 during path setup where domain is a collection of network elements 25 within a common sphere of address management or path computational 26 responsibility (such as an Interior Gateway Protocol (IGP) area or an 27 Autonomous System (AS)). Note that the use of AS as an abstract node 28 representing domain is already defined in [RFC3209] and [RFC4874], 29 albeit with a 2-Byte AS number. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 10, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Explicit Route Object (ERO)'s Subobjects . . . . . . . . . 5 70 3.2.1. Autonomous system . . . . . . . . . . . . . . . . . . 6 71 3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 7 73 3.3. Exclude Route Object (XRO)'s Subobjects . . . . . . . . . 8 74 3.3.1. Autonomous system . . . . . . . . . . . . . . . . . . 8 75 3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 10 77 3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . . 10 78 4. Interaction with Path Computation Element (PCE) . . . . . . . 11 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 11 81 5.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 12 82 5.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 12 83 5.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 13 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 The RSVP-TE specification [RFC3209] and the GMPLS extensions to 95 RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly 96 included in a path setup using the Explicit Route Object (ERO). 98 Further Exclude Routes extensions [RFC4874] allow abstract nodes or 99 resources to be excluded from the whole path using the Exclude Route 100 object (XRO). To exclude certain abstract nodes or resources between 101 a specific pair of abstract nodes present in an ERO, a Explicit 102 Exclusion Route Subobject (EXRS) is used. 104 [RFC3209] already describes the notion of abstract nodes, where an 105 abstract node is a group of nodes whose internal topology is opaque 106 to the ingress node of the Label Switched Path (LSP). It further 107 defines a subobject for AS, but with a 2-Byte AS number only. 109 This document extends the notion of abstract nodes by adding new 110 subobjects for IGP Areas and 4-byte AS numbers (as per [RFC4893]). 111 These subobjects MAY be included in Explicit Route Object (ERO), 112 Exclude Route object (XRO) or Explicit Exclusion Route Subobject 113 (EXRS). 115 In case of per-domain path computation [RFC5152], where the full path 116 of an inter-domain TE LSP cannot be or is not determined at the 117 ingress node, and signaling message may use domain identifiers. The 118 use of these new subobjects is illustrated in Section 5. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Terminology 128 The following terminology is used in this document. 130 AS: Autonomous System. 132 Domain: As per [RFC4655], any collection of network elements within 133 a common sphere of address management or path computational 134 responsibility. Examples of domains include Interior Gateway 135 Protocol (IGP) areas and Autonomous Systems (ASs). 137 ERO: Explicit Route Object 139 EXRS: Explicit Exclusion Route Subobject 141 IGP: Interior Gateway Protocol. Either of the two routing 142 protocols, Open Shortest Path First (OSPF) or Intermediate System 143 to Intermediate System (IS-IS). 145 IS-IS: Intermediate System to Intermediate System. 147 OSPF: Open Shortest Path First. 149 PCE: Path Computation Element. An entity (component, application, 150 or network node) that is capable of computing a network path or 151 route based on a network graph and applying computational 152 constraints. 154 PCEP: Path Computation Element Protocol. 156 RSVP: Resource Reservation Protocol 158 TE LSP: Traffic Engineering Label Switched Path. 160 XRO: Exclude Route Object 162 3. Subobjects for Domains 164 3.1. Domains 166 [RFC4726] and [RFC4655] define domain as a separate administrative or 167 geographic environment within the network. A domain may be further 168 defined as a zone of routing or computational ability. Under these 169 definitions a domain might be categorized as an AS or an IGP area. 171 As per [RFC3209], an abstract node is a group of nodes whose internal 172 topology is opaque to the ingress node of the LSP. Using this 173 concept of abstraction, an explicitly routed LSP can be specified as 174 a sequence of IP prefixes or a sequence of Autonomous Systems. In 175 this document we extend the notion to include IGP area and 4-Byte AS 176 number. 178 The sub-objects MAY appear in RSVP-TE, notably in - 180 o Explicit Route Object (ERO): As per [RFC3209], an explicit route 181 is a particular path in the network topology including abstract 182 nodes (domains). 184 o Exclude Route Object (XRO): As per [RFC4874], an exclude route 185 identifies a list of abstract nodes (domains) that should not be 186 traversed along the path of the LSP being established. 188 o Explicit Exclusion Route Subobject (EXRS): As per [RFC4874], used 189 to specify exclusion of certain abstract nodes between a specific 190 pair of nodes. EXRS are a subobject carried inside the ERO. 191 These subobjects are used to specify the domains that must be 192 excluded between two abstract nodes. 194 3.2. Explicit Route Object (ERO)'s Subobjects 196 As stated in [RFC3209], an explicit route is a particular path in the 197 network topology. In addition to the ability to identify specific 198 nodes along the path, an explicit route can identify a group of nodes 199 (abstract nodes) that must be traversed along the path. 201 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], 202 [RFC4874] and [RFC5553] but new subobjects related to domains are 203 needed. 205 The following subobject types are used in ERO. 207 Type Subobject 208 1 IPv4 prefix 209 2 IPv6 prefix 210 3 Label 211 4 Unnumbered Interface ID 212 32 Autonomous system number (2 Byte) 213 33 Explicit Exclusion (EXRS) 214 34 SRLG 215 64 IPv4 Path Key 216 65 IPv6 Path Key 218 This document extends the above list to support 4-Byte AS numbers and 219 IGP Areas. 221 Type Subobject 222 TBD Autonomous system number (4 Byte) 223 TBD OSPF Area id 224 TBD ISIS Area id 226 3.2.1. Autonomous system 228 [RFC3209] already defines 2-Byte AS number. 230 To support 4-Byte AS numbers as per [RFC4893], the following 231 subobject is defined: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |L| Type | Length | Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | AS-ID (4 bytes) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 L: The L bit is an attribute of the subobject as defined in 242 [RFC3209]. 244 Type: (TBA by IANA) indicating a 4-Byte AS Number. 246 Length: 8 (Total length of the subobject in bytes). 248 Reserved: Zero at transmission, ignored at receipt. 250 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 251 use, the low order bits (16 through 31) should be used and the 252 high order bits (0 through 15) should be set to zero. 254 3.2.2. IGP Area 256 Since the length and format of Area-id is different for OSPF and 257 ISIS, the following two subobjects are defined: 259 For OSPF, the area-id is a 32 bit number. The subobject is encoded 260 as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |L| Type | Length | Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | OSPF Area Id (4 bytes) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 L: The L bit is an attribute of the subobject as defined in 271 [RFC3209]. 273 Type: (TBA by IANA) indicating a 4-Byte OSPF Area ID. 275 Length: 8 (Total length of the subobject in bytes). 277 Reserved: Zero at transmission, ignored at receipt. 279 OSPF Area Id: The 4-Byte OSPF Area ID. 281 For IS-IS, the area-id is of variable length and thus the length of 282 the subobject is variable. The Area-id is as described in IS-IS by 283 ISO standard [ISO 10589]. The subobject is encoded as follows: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |L| Type | Length | Area-Len | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 // IS-IS Area ID // 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 L: The L bit is an attribute of the subobject as defined in 296 [RFC3209]. 298 Type: (TBA by IANA) indicating IS-IS Area ID. 300 Length: Variable. As per [RFC3209], the total length of the 301 subobject in bytes, including the L, Type and Length fields. The 302 Length MUST be at least 4, and MUST be a multiple of 4. 304 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 305 Identifier in octets; Valid values are from 2 to 11 inclusive). 307 Reserved: Zero at transmission, ignored at receipt. 309 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 310 with trailing zeroes to a four-byte boundary. 312 3.2.3. Mode of Operation 314 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 315 MAY also be used in the ERO to specify an abstract node (a group of 316 nodes whose internal topology is opaque to the ingress node of the 317 LSP). 319 All the rules of processing (for example Next Hop Selection, L bit 320 processing, unrecognized subobjects etc) are as per the [RFC3209]. 322 3.3. Exclude Route Object (XRO)'s Subobjects 324 As stated in [RFC4874], the exclude route identifies a list of 325 abstract nodes that should not be traversed along the path of the LSP 326 being established. 328 Some subobjects are defined in [RFC3209], [RFC3477], [RFC4874] and 329 [RFC6001] but new subobjects related to domains are needed. 331 The following subobject types are used in XRO. 333 Type Subobject 334 1 IPv4 prefix 335 2 IPv6 prefix 336 3 Label 337 4 Unnumbered Interface ID 338 32 Autonomous system number (2 Byte) 339 34 SRLG 341 This document extends the above list to support 4-Byte AS numbers and 342 IGP Areas. 344 Type Subobject 345 TBD Autonomous system number (4 Byte) 346 TBD OSPF Area id 347 TBD ISIS Area id 349 3.3.1. Autonomous system 351 [RFC3209] and [RFC4874] already define a 2-Byte AS number. 353 To support 4-Byte AS numbers as per [RFC4893], the following 354 subobject is defined: 356 0 1 2 3 357 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 | Reserved | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | AS-ID (4 bytes) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 The meaning of the L bit, similar to [RFC4874], is as follows: 366 0: indicates that the abstract node (AS) specified MUST be excluded. 368 1: indicates that the abstract node (AS) specified SHOULD be avoided. 370 The meaning of all the other elements (Type, Length, Reserved and 371 4-Byte AS Id) is same as explained above in Section 3.2.1. 373 3.3.2. IGP Area 375 Since the length and format of Area-id is different for OSPF and 376 ISIS, the following two subobjects are defined: 378 For OSPF, the area-id is a 32 bit number. The subobject is encoded 379 as follows: 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |L| Type | Length | Reserved | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | OSPF Area Id (4 bytes) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 The meaning of the L bit, similar to [RFC4874], is as follows: 391 0: indicates that the abstract node (OSPF Area)) specified MUST be 392 excluded. 394 1: indicates that the abstract node (OSPF Area) specified SHOULD be 395 avoided. 397 The meaning of all the other elements (Type, Length, Reserved and 398 OSPF Area Id) is same as explained above in Section 3.2.2. 400 For IS-IS, the area-id is of variable length and thus the length of 401 the subobject is variable. The Area-id is as described in IS-IS by 402 ISO standard [ISO 10589]. The subobject is encoded as follows: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |L| Type | Length | Area-Len | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 // IS-IS Area ID // 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 The meaning of the L bit, similar to [RFC4874], is as follows: 416 0: indicates that the abstract node (IS-IS Area) specified MUST be 417 excluded. 419 1: indicates that the abstract node (IS-IS Area) specified SHOULD be 420 avoided. 422 The meaning of all the other elements (Type, Length, Area-Len, 423 Reserved and IS-IS Area Id) is same as explained above in 424 Section 3.2.2. 426 3.3.3. Mode of Operation 428 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 429 MAY also be used in the XRO to specify exclusion of an abstract node 430 (a group of nodes whose internal topology is opaque to the ingress 431 node of the LSP). 433 All the rules of processing are as per the [RFC4874]. 435 3.4. Explicit Exclusion Route Subobject 437 As per [RFC4874], the Explicit Exclusion Route defines abstract nodes 438 or resources that must not or should not be used on the path between 439 two inclusive abstract nodes or resources in the explicit route. 440 EXRS is an ERO subobject that contains one or more subobjects of its 441 own, called EXRS subobjects. 443 The EXRS subobject may carry any of the subobjects defined for XRO, 444 thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) 445 Area MAY also be used in the EXRS. The meanings of the fields of the 446 new XRO subobjects are unchanged when the subobjects are included in 447 an EXRS, except that scope of the exclusion is limited to the single 448 hop between the previous and subsequent elements in the ERO. 450 All the rules of processing are as per the [RFC4874]. 452 4. Interaction with Path Computation Element (PCE) 454 The domain subobjects to be used in Path Computation Element Protocol 455 (PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain 456 subobjects follow the principle that subobjects used in PCEP 457 [RFC5440] are identical to the subobjects used in RSVP-TE. 459 5. Examples 461 5.1. Inter-Area LSP Path Setup 463 In an inter-area LSP path setup where the ingress and the egress 464 belong to different IGP areas within the same AS, the domain 465 subobjects MAY be represented using an ordered list of IGP area 466 subobjects in an ERO. The AS number MAY be skipped, as area 467 information is enough to uniquely identify a domain. 469 D2 Area D 470 | 471 | 472 D1 473 | 474 | 475 ********BD1****** 476 * | * 477 * | * Area C 478 Area A * | * 479 * | * 480 Ingress------A1-----ABF1------B1------BC1------C1------Egress 481 / * | * 482 / * | * 483 / * Area | B * 484 F1 * | * 485 / ********BE1****** 486 / | 487 / | 488 F2 E1 489 | 490 Area F | 491 E2 Area E 493 * All IGP Area in one AS (AS 100) 495 Figure 1: Domain Corresponding to IGP Area 497 As per Figure 1, the signaling at Ingress MAY be - 499 ERO:(A1, ABF1, Area B, Area C, Egress); or 501 ERO:(A1, ABF1, AS 100, Area B, AS 100, Area C, Egress). 503 The AS subobject is optional and it MAY be skipped. An RSVP-TE 504 implementation should be able to understand both notations and there 505 is no change in the processing rules as mentioned in [RFC3209]. 507 5.2. Inter-AS LSP Path Setup 509 5.2.1. Example 1 511 In an inter-AS LSP path setup where the ingress and the egress belong 512 to different AS, the domain subobjects MAY be represented using an 513 ordered list of AS subobjects in an ERO. 515 AS A AS E AS C 516 <-------------> <----------> <-------------> 518 A4----------E1---E2---E3---------C4 519 / / \ 520 / / \ 521 / / AS B \ 522 / / <----------> \ 523 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 524 \ / / 525 \ / / 526 \ / / 527 \ / / 528 A3----------D1---D2---D3---------C3 530 <----------> 531 AS D 533 * All AS have one area (area 0) 535 Figure 2: Domain Corresponding to AS 537 As per Figure 2, the signaling at Ingress MAY be - 539 ERO:(A1, A2, AS B, AS C, Egress); or 541 ERO:(A1, A2, AS B, Area 0, AS C, Area 0, Egress). 543 Each AS has a single IGP area (area 0), Area subobject is optional 544 and it MAY be skipped as AS is enough to uniquely identify a domain. 545 An RSVP-TE implementation should be able to understand both notations 546 and there is no change in the processing rules as mentioned in 547 [RFC3209]. 549 Note that to get a domain disjoint path, the ingress may also signal 550 the backup path with - 552 XRO:(AS B) 554 5.2.2. Example 2 556 As shown in Figure 3, where AS 200 is made up of multiple areas, the 557 signaling MAY include both AS and Area subobject to uniquely identify 558 a domain. 560 Ingress # 561 | # 562 | # 563 X1 # 564 | \ # 565 | # \ 566 |# \ 567 # | \ Inter-AS 568 AS 100 # | \ Link 569 # | \ 570 # | \ 571 # | \ 572 | D2 Area D 573 AS 200 | | 574 | | 575 Inter | D1 576 -AS | | 577 Link | | 578 A3 ********BD1****** 579 | * | * 580 | * | * Area C 581 | Area A * | * 582 | * | * 583 A2------A1------AB1------B1------BC1------C1------Egress 584 * | * 585 * | * 586 * | * 587 * Area | B * 588 ********BE1****** 589 | 590 | 591 E1 592 | 593 | 594 E2 Area E 596 Figure 3: Domain Corresponding to AS and Area 598 As per Figure 3, the signaling at Ingress MAY be - 600 ERO:(X1, AS 200, Area D, Area B, Area C, Egress). 602 The combination of both an AS and an Area uniquely identifies a 603 domain, note that an Area domain identifier always belongs to the 604 previous AS that appears before it or, if no AS subobjects are 605 present, it is assumed to be the current AS. Also note that there 606 are no changes in the processing rules as mentioned in [RFC3209] with 607 respect to subobjects. 609 6. IANA Considerations 611 6.1. New Subobjects 613 IANA registry: RSVP PARAMETERS 615 Subsection: Class Names, Class Numbers, and Class Types 617 IANA is requested to add further subobjects to the existing entry 618 for: 620 20 EXPLICIT_ROUTE 621 232 EXCLUDE_ROUTE 623 Subobject Type Reference 624 TBA 4-Byte AS number [This I.D.] 625 TBA OSPF Area ID [This I.D.] 626 TBA IS-IS Area ID [This I.D.] 628 7. Security Considerations 630 Security considerations for MPLS-TE and GMPLS signaling are covered 631 in [RFC3209] and [RFC3473]. This document does not introduce any new 632 messages or any substantive new processing, and so those security 633 considerations continue to apply. 635 The route exclusion security consideration are covered in [RFC4874] 636 and continue to apply. 638 8. Acknowledgments 640 We would like to thank Lou Berger, George Swallow, Chirag Shah, Reeja 641 Paul and Sandeep Boina for their useful comments and suggestions. 643 9. References 645 9.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 9.2. Informative References 652 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 653 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 654 LSP Tunnels", RFC 3209, December 2001. 656 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 657 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 658 Engineering (RSVP-TE) Extensions", RFC 3473, 659 January 2003. 661 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 662 Links in Resource ReSerVation Protocol - Traffic 663 Engineering (RSVP-TE)", RFC 3477, January 2003. 665 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 666 Computation Element (PCE)-Based Architecture", 667 RFC 4655, August 2006. 669 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 670 for Inter-Domain Multiprotocol Label Switching Traffic 671 Engineering", RFC 4726, November 2006. 673 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 674 Routes - Extension to Resource ReserVation Protocol- 675 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 677 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 678 Number Space", RFC 4893, May 2007. 680 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 681 Path Computation Method for Establishing Inter-Domain 682 Traffic Engineering (TE) Label Switched Paths (LSPs)", 683 RFC 5152, February 2008. 685 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 686 (PCE) Communication Protocol (PCEP)", RFC 5440, 687 March 2009. 689 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 690 Reservation Protocol (RSVP) Extensions for Path Key 691 Support", RFC 5553, May 2009. 693 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., 694 Brungard, D., and JL. Le Roux, "Generalized MPLS 695 (GMPLS) Protocol Extensions for Multi-Layer and Multi- 696 Region Networks (MLN/MRN)", RFC 6001, October 2010. 698 [PCE-DOMAIN] Dhody, D., Palle, U., and R. Casellas, "Standard 699 Representation Of Domain Sequence. 700 (draft-ietf-pce-pcep-domain-sequence)", July 2013. 702 [ISO 10589] ISO, "Intermediate system to Intermediate system 703 routing information exchange protocol for use in 704 conjunction with the Protocol for providing the 705 Connectionless-mode Network Service (ISO 8473)", ISO/ 706 IEC 10589:2002. 708 Authors' Addresses 710 Dhruv Dhody 711 Huawei Technologies 712 Leela Palace 713 Bangalore, Karnataka 560008 714 INDIA 716 EMail: dhruv.dhody@huawei.com 718 Udayasree Palle 719 Huawei Technologies 720 Leela Palace 721 Bangalore, Karnataka 560008 722 INDIA 724 EMail: udayasree.palle@huawei.com 726 Venugopal Reddy Kondreddy 727 Huawei Technologies 728 Leela Palace 729 Bangalore, Karnataka 560008 730 INDIA 732 EMail: venugopalreddyk@huawei.com 734 Ramon Casellas 735 CTTC 736 Av. Carl Friedrich Gauss n7 737 Castelldefels, Barcelona 08860 738 SPAIN 740 EMail: ramon.casellas@cttc.es