idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2014) is 3474 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'IRO-SURVEY' is defined on line 1273, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-02) exists of draft-dhody-pce-iro-survey-01 == Outdated reference: A later version (-02) exists of draft-dhody-pce-iro-update-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental Huawei Technologies 5 Expires: April 25, 2015 R. Casellas 6 CTTC 7 October 22, 2014 9 Standard Representation Of Domain-Sequence 10 draft-ietf-pce-pcep-domain-sequence-06 12 Abstract 14 The ability to compute shortest constrained Traffic Engineering Label 15 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 16 Generalized MPLS (GMPLS) networks across multiple domains has been 17 identified as a key requirement. In this context, a domain is a 18 collection of network elements within a common sphere of address 19 management or path computational responsibility such as an Interior 20 Gateway Protocol (IGP) area or an Autonomous Systems (AS). This 21 document specifies a standard representation and encoding of a 22 Domain-Sequence, which is defined as an ordered sequence of domains 23 traversed to reach the destination domain to be used by Path 24 Computation Elements (PCEs) to compute inter-domain shortest 25 constrained paths across a predetermined sequence of domains . This 26 document also defines new subobjects to be used to encode domain 27 identifiers. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Standard Representation . . . . . . . . . . . . . . . . . 6 70 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 71 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 7 72 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 73 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 8 74 3.4.2. Update in IRO specification . . . . . . . . . . . . . 9 75 3.4.3. IRO for domain-sequence . . . . . . . . . . . . . . . 10 76 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 11 77 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 78 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 12 79 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 80 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14 81 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 14 82 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 15 83 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 15 84 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 17 85 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 86 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 19 87 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 21 88 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 21 89 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 22 91 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . 24 92 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 24 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 25 95 5.2. Error Object Field Values . . . . . . . . . . . . . . . . 25 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 7. Manageability Considerations . . . . . . . . . . . . . . . . 26 98 7.1. Control of Function and Policy . . . . . . . . . . . . . 26 99 7.2. Information and Data Models . . . . . . . . . . . . . . . 26 100 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26 101 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26 102 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 26 103 7.6. Impact On Network Operations . . . . . . . . . . . . . . 27 104 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 107 9.2. Informative References . . . . . . . . . . . . . . . . . 27 109 1. Introduction 111 A PCE may be used to compute end-to-end paths across multi-domain 112 environments using a per-domain path computation technique [RFC5152]. 113 The so called backward recursive path computation (BRPC) mechanism 114 [RFC5441] defines a PCE-based path computation procedure to compute 115 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 116 and BRPC techniques assume that the sequence of domains to be crossed 117 from source to destination is known, either fixed by the network 118 operator or obtained by other means. Also for inter-domain point-to- 119 multi-point (P2MP) tree computation, [RFC7334] assumes the domain- 120 tree is known in priori. 122 The list of domains (domain-sequence) in a point-to-point (P2P) path 123 or a point-to-multipoint (P2MP) tree is usually a constraint in the 124 path computation request. A PCE determines the next PCE to forward 125 the request based on the domain-sequence. In a multi-domain path 126 computation, a PCC MAY indicate the sequence of domains to be 127 traversed using the Include Route Object (IRO) defined in [RFC5440]. 129 When the sequence of domains is not known in advance, the 130 Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be 131 used to determine the end-to-end Domain-Sequence. 133 This document defines a standard way to represent and encode a 134 Domain-Sequence in various deployment scenarios including P2P, P2MP 135 and H-PCE. 137 The Domain-Sequence (the set of domains traversed to reach the 138 destination domain) is either administratively predetermined or 139 discovered by some means (H-PCE) that is outside of the scope of this 140 document. 142 [RFC5440] defines the Include Route Object (IRO) and the Explicit 143 Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO) 144 and the Explicit Exclusion Route Subobject (EXRS); The use of 145 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 146 abstract node representing domain is defined in [RFC3209], this 147 document specifies new subobjects to include or exclude domains such 148 as an IGP area or an Autonomous Systems (4-Byte as per [RFC4893]). 150 Further, the domain identifier may simply act as delimiter to specify 151 where the domain boundary starts and ends. 153 This is a companion document to Resource ReserVation Protocol - 154 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 155 [DOMAIN-SUBOBJ]. 157 1.1. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Terminology 165 The following terminology is used in this document. 167 ABR: OSPF Area Border Router. Routers used to connect two IGP 168 areas. 170 AS: Autonomous System. 172 ASBR: Autonomous System Boundary Router. 174 BN: Boundary Node, Can be an ABR or ASBR. 176 BRPC: Backward Recursive Path Computation 178 Domain: As per [RFC4655], any collection of network elements within 179 a common sphere of address management or path computational 180 responsibility. Examples of domains include Interior Gateway 181 Protocol (IGP) areas and Autonomous Systems (ASs). 183 Domain-Sequence: An ordered sequence of domains traversed to reach 184 the destination domain. 186 ERO: Explicit Route Object 188 H-PCE: Hierarchical PCE 189 IGP: Interior Gateway Protocol. Either of the two routing 190 protocols, Open Shortest Path First (OSPF) or Intermediate System 191 to Intermediate System (IS-IS). 193 IRO: Include Route Object 195 IS-IS: Intermediate System to Intermediate System. 197 OSPF: Open Shortest Path First. 199 PCC: Path Computation Client: any client application requesting a 200 path computation to be performed by a Path Computation Element. 202 PCE: Path Computation Element. An entity (component, application, 203 or network node) that is capable of computing a network path or 204 route based on a network graph and applying computational 205 constraints. 207 P2MP: Point-to-Multipoint 209 P2P: Point-to-Point 211 RSVP: Resource Reservation Protocol 213 TE LSP: Traffic Engineering Label Switched Path. 215 XRO: Exclude Route Object 217 3. Detail Description 219 3.1. Domains 221 [RFC4726] and [RFC4655] define domain as a separate administrative or 222 geographic environment within the network. A domain may be further 223 defined as a zone of routing or computational ability. Under these 224 definitions a domain might be categorized as an AS or an IGP area. 225 Each AS can be made of several IGP areas. In order to encode a 226 Domain-Sequence, it is required to uniquely identify a domain in the 227 Domain-Sequence. A domain can be uniquely identified by area-id or 228 AS or both. 230 3.2. Domain-Sequence 232 A domain-sequence is an ordered sequence of domains traversed to 233 reach the destination domain. 235 A domain-sequence can be applied as a constraint and carried in path 236 computation request to PCE(s). A domain-sequence can also be the 237 result of a path computation. For example, in the case of H-PCE 238 [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a 239 path computation reply. 241 In a P2P path, the domains listed appear in the order that they are 242 crossed. In a P2MP path, the domain tree is represented as list of 243 domain sequences. 245 A domain-sequence enables a PCE to select the next PCE to forward the 246 path computation request based on the domain information. 248 A PCC or PCE MAY add an additional constraints covering which 249 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be 250 traversed while defining a Domain-Sequence. 252 Thus a Domain-Sequence MAY be made up of one or more of - 254 o AS Number 256 o Area ID 258 o Boundary Node ID 260 o Inter-AS-Link Address 262 Consequently, a Domain-Sequence can be used: 264 1. by a PCE in order to discover or select the next PCE in a 265 collaborative path computation, such as in BRPC [RFC5441]; 267 2. by the Parent PCE to return the Domain-Sequence when unknown, 268 this can further be an input to BRPC procedure [RFC6805]; 270 3. by a PCC (or PCE) to constraint the domains used in a H-PCE path 271 computation, explicitly specifying which domains to be expanded; 273 4. by a PCE in per-domain path computation model [RFC5152] to 274 identify the next domain(s); 276 3.3. Standard Representation 278 Domain-Sequence MAY appear in PCEP Messages, notably in - 280 o Include Route Object (IRO): As per [RFC5440], used to specify set 281 of network elements that MUST be traversed. The subobjects in IRO 282 are used to specify the domain-sequence that MUST be traversed to 283 reach the destination. 285 o Exclude Route Object (XRO): As per [RFC5521], used to specify 286 certain abstract nodes that MUST be excluded from whole path. The 287 subobjects in XRO are used to specify certain domains that MUST be 288 avoided to reach the destination. 290 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used 291 to specify exclusion of certain abstract nodes between a specific 292 pair of nodes. EXRS are a subobject inside the IRO. These 293 subobjects are used to specify the domains that must be excluded 294 between two abstract nodes. 296 o Explicit Route Object (ERO): As per [RFC5440], used to specify a 297 computed path in the network. For example, in the case of H-PCE 298 [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a 299 path computation reply using ERO. 301 3.4. Include Route Object (IRO) 303 As per [RFC5440], IRO (Include Route Object) can be used to specify 304 that the computed path MUST traverse a set of specified network 305 elements or abstract nodes. 307 3.4.1. Subobjects 309 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 310 [RFC4874], but new subobjects related to Domain-Sequence are needed. 312 The following subobject types are used in IRO. 314 Type Subobject 315 1 IPv4 prefix 316 2 IPv6 prefix 317 4 Unnumbered Interface ID 318 32 Autonomous system number (2 Byte) 319 33 Explicit Exclusion (EXRS) 321 This document extends the above list to support 4-Byte AS numbers and 322 IGP Areas. 324 Type Subobject 325 TBD1 Autonomous system number (4 Byte) 326 TBD2 OSPF Area id 327 TBD3 ISIS Area id 329 3.4.1.1. Autonomous system 331 [RFC3209] already defines 2 byte AS number. 333 To support 4 byte AS number as per [RFC4893] following subobject is 334 defined: 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |L| Type | Length | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | AS-ID (4 bytes) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 L: The L bit is an attribute of the subobject as defined in [RFC3209] 345 and usage in IRO subobject updated in [IRO-UPDATE]. 347 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 349 Length: 8 (Total length of the subobject in bytes). 351 Reserved: Zero at transmission, ignored at receipt. 353 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 354 use, the low order bits (16 through 31) should be used and the 355 high order bits (0 through 15) should be set to zero. 357 3.4.1.2. IGP Area 359 Since the length and format of Area-id is different for OSPF and 360 ISIS, following two subobjects are defined: 362 For OSPF, the area-id is a 32 bit number. The subobject is encoded 363 as follows: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |L| Type | Length | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | OSPF Area Id (4 bytes) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 L: The L bit is an attribute of the subobject as defined in [RFC3209] 374 and usage in IRO subobject updated in [IRO-UPDATE]. 376 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 378 Length: 8 (Total length of the subobject in bytes). 380 Reserved: Zero at transmission, ignored at receipt. 382 OSPF Area Id: The 4-Byte OSPF Area ID. 384 For IS-IS, the area-id is of variable length and thus the length of 385 the Subobject is variable. The Area-id is as described in IS-IS by 386 ISO standard [ISO10589]. The subobject is encoded as follows: 388 0 1 2 3 389 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 | Area-Len | Reserved | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 // IS-IS Area ID // 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 L: The L bit is an attribute of the subobject as defined in [RFC3209] 399 and usage in IRO subobject updated in [IRO-UPDATE]. 401 Type: (TBD3 by IANA) indicating IS-IS Area ID. 403 Length: Variable. As per [RFC3209], the total length of the 404 subobject in bytes, including the L, Type and Length fields. The 405 Length MUST be at least 4, and MUST be a multiple of 4. 407 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 408 Identifier in octets; Valid values are from 2 to 11 inclusive). 410 Reserved: Zero at transmission, ignored at receipt. 412 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 413 with trailing zeroes to a four-byte boundary. 415 3.4.2. Update in IRO specification 417 [RFC5440] describes IRO as an optional object used to specify that 418 the computed path MUST traverse a set of specified network elements. 419 It further state that the L bit of such sub-object has no meaning 420 within an IRO. It did not mention if IRO is an ordered or un-ordered 421 list of sub-objects. 423 An update to IRO specification [IRO-UPDATE] makes IRO as an ordered 424 list as well as support for loose bit (L-bit). 426 The use IRO for domain-sequence assumes the updated specification for 427 IRO as per [IRO-UPDATE]. 429 3.4.3. IRO for domain-sequence 431 Some subobjects for IRO are defined in [RFC3209], [RFC3473], 432 [RFC3477] and [RFC4874], further some new subobjects related to 433 Domain-Sequence are also added in this document as mentioned in 434 Section 3.4. 436 The subobjects for IPv4, IPv6 and unnumbered Interface ID can be used 437 to specify Boundary Node (ABR/ASBR) and Inter-AS-Links. The 438 subobjects for AS Number (2 or 4 Byte) and IGP Area is used to 439 specify the domain identifiers in the domain-sequence. 441 The IRO MAY have both intra-domain (from the context of the ingress 442 PCC) and inter-domain (domain-sequence) subobjects in a sequence in 443 which they must be traversed in the computed path. 445 Thus an IRO comprising of subobjects that represents a domain- 446 sequence may constraints or define the domains involved in an inter- 447 domain path computation, typically involving two or more 448 collaborative PCEs. 450 A Domain-Sequence can have varying degrees of granularity; it is 451 possible to have a Domain-Sequence composed of, uniquely, AS 452 identifiers. It is also possible to list the involved areas for a 453 given AS. 455 In any case, the mapping between domains and responsible PCEs is not 456 defined in this document. It is assumed that a PCE that needs to 457 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 458 administrative configuration, or discovery). 460 A PCC builds an IRO to encode the Domain-Sequence, that the 461 cooperating PCEs should compute an inter-domain shortest constrained 462 paths across the specified sequence of domains. 464 For each inclusion, the PCC clears the L-bit to indicate that the PCE 465 is required to include the domain, or sets the L-bit to indicate that 466 the PCC simply desires that the domain be included in the domain- 467 sequence. 469 If a PCE encounters a subobject that it does not support or 470 recognize, it MUST act according to the setting of the L-bit in the 471 subobject. If the L-bit is clear, the PCE MUST respond with a PCErr 472 with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value 473 to the subobject type code. If the L-bit is set, the PCE MAY respond 474 with a PCErr as already stated or MAY ignore the subobject: this 475 choice is a local policy decision. 477 PCE MUST act according to the requirements expressed in the 478 subobject. That is, if the L-bit is clear, the PCE(s) MUST produce a 479 path that follows domain-sequence nodes in order identified by the 480 subobjects in the path. If the L-bit is set, the PCE(s) SHOULD 481 produce a path along the Domain-Sequence unless it is not possible to 482 construct a path complying with the other constraints expressed in 483 the request. 485 A successful path computation reported in a PCEP reply message 486 (PCRep) MUST include an ERO to specify the path that has been 487 computed as specified in [RFC5440] following the sequence of domains. 489 In a PCRep, PCE MAY also supply IRO (with domain sequence 490 information) with the NO-PATH object indicating that the set of 491 elements (domains) of the request's IRO prevented the PCEs from 492 finding a path. 494 The Subobject types for domains (AS and IGP Area) affect the next 495 domain selection as well as finding the PCE serving that domain. 497 Note that a particular domain in the domain-sequence can be 498 identified by :- 500 o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is 501 used to identify the next domain. (Refer Figure 1) 503 o A single AS: Only the AS subobject is used to identify the next 504 domain. (Refer Figure 2) 506 o Both an AS and an IGP Area: Combination of both AS and Area are 507 used to identify the next domain. In this case the order is AS 508 Subobject followed by Area. (Refer Figure 3) 510 The Subobjects representing an internal node, a Boundary Node or an 511 Inter-AS-Link MAY influence the selection of the path as well. 513 3.5. Exclude Route Object (XRO) 515 The Exclude Route Object (XRO) [RFC5521] is an optional object used 516 to specify exclusion of certain abstract nodes or resources from the 517 whole path. 519 3.5.1. Subobjects 521 The following subobject types are defined to be used in XRO as 522 defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. 524 Type Subobject 525 1 IPv4 prefix 526 2 IPv6 prefix 527 4 Unnumbered Interface ID 528 32 Autonomous system number (2 Byte) 529 34 SRLG 530 64 IPv4 Path Key 531 65 IPv6 Path Key 533 This document extends the above list to support 4-Byte AS numbers and 534 IGP Areas. 536 Type Subobject 537 TBD1 Autonomous system number (4 Byte) 538 TBD2 OSPF Area id 539 TBD3 ISIS Area id 541 3.5.1.1. Autonomous system 543 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 544 MAY also be used in the XRO to specify exclusion of certain domains 545 in the path computation procedure. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |X| Type | Length | Reserved | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | AS-ID (4 bytes) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 The X-bit indicates whether the exclusion is mandatory or desired. 557 0: indicates that the AS specified MUST be excluded from the path 558 computed by the PCE(s). 560 1: indicates that the AS specified SHOULD be avoided from the inter- 561 domain path computed by the PCE(s), but MAY be included subject to 562 PCE policy and the absence of a viable path that meets the other 563 constraints. 565 All other fields are consistent with the definition in Section 3.4. 567 3.5.1.2. IGP Area 569 Since the length and format of Area-id is different for OSPF and 570 ISIS, following two subobjects are defined: 572 For OSPF, the area-id is a 32 bit number. The subobject is encoded 573 as follows: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |X| Type | Length | Reserved | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | OSPF Area Id (4 bytes) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 The X-bit indicates whether the exclusion is mandatory or desired. 585 0: indicates that the OSFF Area specified MUST be excluded from the 586 path computed by the PCE(s). 588 1: indicates that the OSFF Area specified SHOULD be avoided from the 589 inter-domain path computed by the PCE(s), but MAY be included 590 subject to PCE policy and the absence of a viable path that meets 591 the other constraints. 593 All other fields are consistent with the definition in Section 3.4. 595 For IS-IS, the area-id is of variable length and thus the length of 596 the subobject is variable. The Area-id is as described in IS-IS by 597 ISO standard [ISO10589]. The subobject is encoded as follows: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 |X| Type | Length | Area-Len | Reserved | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | | 605 // IS-IS Area ID // 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 The X-bit indicates whether the exclusion is mandatory or desired. 611 0: indicates that the ISIS Area specified MUST be excluded from the 612 path computed by the PCE(s). 614 1: indicates that the ISIS Area specified SHOULD be avoided from the 615 inter-domain path computed by the PCE(s), but MAY be included 616 subject to PCE policy and the absence of a viable path that meets 617 the other constraints. 619 All other fields are consistent with the definition in Section 3.4. 621 If a PCE that supports XRO and encounters a subobject that it does 622 not support or recognize, it MUST act according to the setting of the 623 X-bit in the subobject. If the X-bit is clear, the PCE MUST respond 624 with a PCErr with Error-Type TBD4 "Unrecognized subobject" and set 625 the Error-Value to the subobject type code. If the X-bit is set, the 626 PCE MAY respond with a PCErr as already stated or MAY ignore the 627 subobject: this choice is a local policy decision. 629 All the other processing rules are as per [RFC5521]. 631 3.6. Explicit Exclusion Route Subobject (EXRS) 633 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 634 specify exclusion of certain abstract nodes between a specific pair 635 of nodes. 637 The EXRS subobject may carry any of the subobjects defined for 638 inclusion in the XRO, thus the new subobjects to support 4 byte AS 639 and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The 640 meanings of the fields of the new XRO subobjects are unchanged when 641 the subobjects are included in an EXRS, except that scope of the 642 exclusion is limited to the single hop between the previous and 643 subsequent elements in the IRO. 645 All the processing rules are as per [RFC5521]. 647 3.7. Explicit Route Object (ERO) 649 The Explicit Route Object (ERO) [RFC5440] is used to specify a 650 computed path in the network. PCEP ERO subobject types correspond to 651 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 652 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. 654 Type Subobject 655 1 IPv4 prefix 656 2 IPv6 prefix 657 3 Label 658 4 Unnumbered Interface ID 659 32 Autonomous system number (2 Byte) 660 33 Explicit Exclusion (EXRS) 661 37 Protection 662 64 IPv4 Path Key 663 65 IPv6 Path Key 665 This document extends the above list to support 4-Byte AS numbers and 666 IGP Areas. 668 Type Subobject 669 TBD1 Autonomous system number (4 Byte) 670 TBD2 OSPF Area id 671 TBD3 ISIS Area id 673 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 674 MAY also be used in the ERO to specify an abstract node (a group of 675 nodes whose internal topology is opaque to the ingress node of the 676 LSP). Using this concept of abstraction, an explicitly routed LSP 677 can be specified as a sequence of domains. 679 In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested 680 to find the domain-sequence. Refer example in Section 4.6. 682 The format of the new ERO subobjects is similar to new IRO 683 subobjects, refer Section 3.4. 685 4. Other Considerations 687 The examples in this section are for illustration purposes only; to 688 show how the new subobjects may be encoded. 690 4.1. Inter-Area Path Computation 692 In an inter-area path computation where the ingress and the egress 693 nodes belong to different IGP areas within the same AS, the Domain- 694 Sequence MAY be represented using a ordered list of Area subobjects. 695 The AS number MAY be skipped, as area information is enough to select 696 the next PCE. 698 +-------------------+ +-------------------+ 699 | | | | 700 | +--+ | | +--+ | 701 | +--+ | | | | | | | 702 | | | +--+ | | +--+ +--+ | 703 | +--* + + | | | 704 | | | +--+ | 705 | *--+ + + | 706 | | | | | +--+ | 707 | +--+ | | | | | 708 | |+--------------------------+| +--+ | 709 | ++++ +-++ | 710 | |||| +--+ | || | 711 | Area 2 ++++ | | +-++ Area 4 | 712 +-------------------+| +--+ |+-------------------+ 713 | | 714 | +--+ | 715 | +--+ | | | 716 | | | +--+ | 717 | +--+ | 718 | | 719 | | 720 | | 721 | | 722 | +--+ | 723 | | | | 724 | +--+ | 725 +------------------+| |+--------------------+ 726 | ++-+ +-++ | 727 | || | | || | 728 | ++-+ Area 0 +-++ | 729 | |+--------------------------+| +--+ | 730 | +--+ | | | | | 731 | | | | | +--+ | 732 | +--+ +--+ | | | 733 | | | + + +--+ | 734 | +--+ | | | | | 735 | + + +--+ | 736 | +--+ | | | 737 | | | | | +--+ | 738 | +--+ | | | | | 739 | | | +--+ | 740 | | | | 741 | Area 1 | | Area 5 | 742 +------------------+ +--------------------+ 744 Figure 1: Inter-Area Path Computation 746 AS Number is 100. 748 This could be represented in the as: 750 +---------+ +---------+ +---------+ +---------+ 751 |IRO | |Sub | |Sub | |Sub | 752 |Object | |Object | |Object | |Object | 753 |Header | |Area 2 | |Area 0 | |Area 4 | 754 | | | | | | | | 755 | | | | | | | | 756 +---------+ +---------+ +---------+ +---------+ 758 +---------+ +---------+ +---------+ +---------+ +---------+ 759 |IRO | |Sub | |Sub | |Sub | |Sub | 760 |Object | |Object AS| |Object | |Object | |Object | 761 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 762 | | | | | | | | | | 763 | | | | | | | | | | 764 +---------+ +---------+ +---------+ +---------+ +---------+ 766 AS is optional and it MAY be skipped. PCE should be able to 767 understand both notations. 769 4.2. Inter-AS Path Computation 771 In inter-AS path computation, where ingress and egress belong to 772 different AS, the Domain-Sequence is represented using an ordered 773 list of AS subobjects. The Domain-Sequence MAY further include 774 decomposed area information in Area subobjects. 776 4.2.1. Example 1 778 As shown in Figure 2, where AS to be made of a single area, the area 779 subobject MAY be skipped in the Domain-Sequence as AS is enough to 780 uniquely identify the next domain and PCE. 782 +---------------------------------+ 783 |AS 200 | 784 | +------+ | 785 | | | | 786 +------------------------+ | | | +------+ | 787 | AS 100 | | +------+ | | | 788 | +------+ | | +------+ | | | 789 | | +-+-----+-+ | +------+ | 790 | | | | | | | | 791 | +------+ | | +------+ | 792 | +------+ | | +------+ | 793 | | | | | | | | 794 | | | | | | | | 795 | +------+ | | +------+ | 796 | | | | 797 | +------+ | | +------+ | 798 | | +-+-----+-+ | +------+ | 799 | | | | | | | | | | 800 | +------+ | | +------+ | | | 801 | | | +------+ | 802 | | | | 803 | | | | 804 | +------+ | | +------+ | 805 | | | | | | | | 806 | |PCE | | | |PCE | | 807 | +------+ | | +------+ | 808 | | | | 809 +------------------------+ | | 810 +---------------------------------+ 812 Figure 2: Inter-AS Path Computation 814 Both AS are made of Area 0. 816 This could be represented in the as: 818 +---------+ +---------+ +---------+ 819 |IRO | |Sub | |Sub | 820 |Object | |Object AS| |Object AS| 821 |Header | |100 | |200 | 822 | | | | | | 823 | | | | | | 824 +---------+ +---------+ +---------+ 826 +---------+ +---------+ +---------+ +---------+ +---------+ 827 |IRO | |Sub | |Sub | |Sub | |Sub | 828 |Object | |Object AS| |Object | |Object AS| |Object | 829 |Header | |100 | |Area 0 | |200 | |Area 0 | 830 | | | | | | | | | | 831 | | | | | | | | | | 832 +---------+ +---------+ +---------+ +---------+ +---------+ 834 Area subobject is optional and it MAY be skipped. PCE should be able 835 to understand both notations. 837 4.2.2. Example 2 839 As shown in Figure 3, where AS 200 is made up of multiple areas and 840 multiple domain-sequence exist, PCE MAY include both AS and Area 841 subobject to uniquely identify the next domain and PCE. 843 | 844 | +-------------+ +----------------+ 845 | |Area 2 | |Area 4 | 846 | | +--+| | +--+ | 847 | | | || | | | | 848 | | +--+ +--+| | +--+ +--+ | 849 | | | | | | | | | 850 | | *--+ | | +--+ | 851 | | / +--+ | | +--+ | 852 | |/ | | | | | | | 853 | / +--+ | | +--+ +--+ | 854 | /| +--+ |+--------------+| | | | 855 |/ | | | ++-+ +-++ +--+ | 856 +-------------+/ | +--+ || | | || | 857 | /| | ++-+ +-++ | 858 | +--*|| +-------------+| |+----------------+ 859 | | ||| | +--+ | 860 | +--+|| | | | | 861 | +--+ || | +--+ | 862 | | | || | | 863 | +--+ || | | 864 | || | +--+ | 865 |+--+ || | | | | 866 || | || | +--+ | 867 |+--+ || | | 868 | || | +--+ | 869 | +--+ || +------------+ | | | |+----------------+ 870 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 871 | +--+ || | | || | || | 872 | || | +-++ +-++ | 873 | +--+|| | +--+ | | Area 0 || +--+ | 874 | | ||| | | | | +--------------+| | | | 875 | +--*|| | +--+ | | +--+ | 876 | \| | | | +--+ | 877 |Area 1 |\ | +--+ | | +--+ | | | 878 +-------------+|\ | | | | | | | +--+ | 879 | \| +--+ +--+ | +--+ | 880 | \ | | | | 881 | |\ +--+ | +--+ | 882 | | \ +--+ | | | | | 883 | | \| | | | +--+ | 884 | | *--+ | | | 885 | | | | | 886 | +------------+ +----------------+ 887 | 888 | 889 AS 100 | AS 200 890 | 892 Figure 3: Inter-AS Path Computation 894 The Domain-Sequence can be carried in the IRO as shown below: 896 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 897 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 898 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 899 |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 900 | | | | | | | | | | | | | | 901 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 903 The combination of both an AS and an Area uniquely identify a domain 904 in the Domain-Sequence. 906 Note that an Area domain identifier always belongs to the previous AS 907 that appears before it or, if no AS subobjects are present, it is 908 assumed to be the current AS. 910 If the area information cannot be provided, PCE MAY forward the path 911 computation request to the next PCE based on AS alone. If multiple 912 PCEs are responsible, PCE MAY apply local policy to select the next 913 PCE. 915 4.3. Boundary Node and Inter-AS-Link 917 A PCC or PCE MAY add additional constraints covering which Boundary 918 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 919 while defining a Domain-Sequence. In which case the Boundary Node or 920 Link MAY be encoded as a part of the domain-sequence using the 921 existing subobjects. 923 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 924 prefix subobjects usually the loopback address of 32 and 128 prefix 925 length respectively. An Inter-AS link can be encoded using the IPv4 926 or IPv6 prefix subobjects or unnumbered interface subobjects. 928 For Figure 1, an ABR to be traversed can be specified as: 930 +---------+ +---------+ +---------++---------+ +---------+ 931 |IRO | |Sub | |Sub ||Sub | |Sub | 932 |Object | |Object | |Object ||Object | |Object | 933 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 934 | | | | |x.x.x.x || | | | 935 | | | | | || | | | 936 +---------+ +---------+ +---------++---------+ +---------+ 938 For Figure 2, an inter-AS-link to be traversed can be specified as: 940 +---------+ +---------+ +---------+ +---------+ +---------+ 941 |IRO | |Sub | |Sub | |Sub | |Sub | 942 |Object | |Object AS| |Object | |Object | |Object AS| 943 |Header | |100 | |IPv4 | |IPv4 | |200 | 944 | | | | |x.x.x.x | |x.x.x.x | | | 945 | | | | | | | | | | 946 +---------+ +---------+ +---------+ +---------+ +---------+ 948 4.4. PCE Serving multiple Domains 950 A single PCE MAY be responsible for multiple domains; for example PCE 951 function deployed on an ABR. A PCE which can support 2 adjacent 952 domains can internally handle this situation without any impact on 953 the neighbouring domains. 955 4.5. P2MP 957 In case of inter-domain P2MP path computation, (Refer [RFC7334]) the 958 path domain tree is nothing but a series of Domain Sequences, as 959 shown in the below figure: 961 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 962 D1 963 / \ 964 D2 D3 965 / / \ 966 D4 D5 D6 968 All rules of processing as applied to P2P can be applied to P2MP as 969 well. 971 In case of P2MP, different destinations MAY have different Domain- 972 Sequence within the domain tree, it requires domain-sequence to be 973 attached per destination. (Refer [PCE-P2MP-PER-DEST]) 975 4.6. Hierarchical PCE 977 As per [RFC6805], consider a case as shown in Figure 4 consisting of 978 multiple child PCEs and a parent PCE. 980 +--------+ 981 | Parent | 982 | PCE | 983 +--------+ 985 +-------------------+ +-------------------+ 986 | +--+ | | +--+ | 987 | +--+ | | | | | | | 988 | | | +--+ | | +--+ +--+ | 989 | +--* + + | | | 990 | | | +--+ | 991 | *--+ + + | 992 | | | | | +--+ | 993 | +--+ | | | | | 994 | |+--------------------------+| +--+ | 995 | ++++ +-++ | 996 | |||| +--+ | || | 997 | Area 2 ++++ | | +-++ Area 4 | 998 +-------------------+| +--+ |+-------------------+ 999 | +--+ | 1000 | +--+ | | | 1001 | | | +--+ | 1002 | +--+ | 1003 | | 1004 | +--+ | 1005 | | | | 1006 | +--+ | 1007 +------------------+| |+--------------------+ 1008 | ++-+ +-++ | 1009 | || | | || | 1010 | ++-+ Area 0 +-++ | 1011 | |+--------------------------+| +--+ | 1012 | +--+ | | | | | 1013 | | | | | +--+ | 1014 | +--+ +--+ | | | 1015 | | | + + +--+ | 1016 | +--+ | | | | | 1017 | + + +--+ | 1018 | +--+ | | | 1019 | | | | | +--+ | 1020 | +--+ | | | | | 1021 | | | +--+ | 1022 | Area 1 | | Area 5 | 1023 +------------------+ +--------------------+ 1025 Figure 4: Hierarchical PCE 1027 In H-PCE, the Ingress PCE 'PCE(1)' can request the parent PCE to 1028 determine the Domain-Sequence and return it in the PCEP response, 1029 using the ERO Object. The ERO can contain an ordered sequence of 1030 subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, 1031 the Domain-Sequence appear as: 1033 +---------+ +---------+ +---------+ +---------+ 1034 |ERO | |Sub | |Sub | |Sub | 1035 |Object | |Object | |Object | |Object | 1036 |Header | |Area 2 | |Area 0 | |Area 4 | 1037 | | | | | | | | 1038 | | | | | | | | 1039 +---------+ +---------+ +---------+ +---------+ 1041 +---------+ +---------+ +---------+ +---------+ +---------+ 1042 |ERO | |Sub | |Sub | |Sub | |Sub | 1043 |Object | |Object AS| |Object | |Object | |Object | 1044 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 1045 | | | | | | | | | | 1046 | | | | | | | | | | 1047 +---------+ +---------+ +---------+ +---------+ +---------+ 1049 4.7. Relationship to PCE Sequence 1051 Instead of a domain-sequence, a sequence of PCEs MAY be enforced by 1052 policy on the PCC, and this constraint can be carried in the PCReq 1053 message (as defined in [RFC5886]). 1055 Note that PCE-Sequence can be used along with domain-sequence in 1056 which case PCE-Sequence SHOULD have higher precedence in selecting 1057 the next PCE in the inter-domain path computation procedures. Note 1058 that Domain-Sequence IRO constraints should still be checked as per 1059 the rules of processing IRO. 1061 4.8. Relationship to RSVP-TE 1063 [RFC3209] already describes the notion of abstract nodes, where an 1064 abstract node is a group of nodes whose internal topology is opaque 1065 to the ingress node of the LSP. It further defines a subobject for 1066 AS but with a 2-Byte AS Number. 1068 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1069 subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY 1070 be included in Explicit Route Object (ERO), Exclude Route object 1071 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1073 In any case subobject type defined in RSVP-TE are identical to the 1074 subobject type defined in the related documents in PCEP. 1076 5. IANA Considerations 1078 5.1. New Subobjects 1080 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1081 with an entry for the Include Route Object (IRO), Exclude Route 1082 Object (XRO) and Explicit Route Object (ERO). IANA is requested to 1083 add further subobjects as follows: 1085 7 ERO 1086 10 IRO 1087 17 XRO 1089 Subobject Type Reference 1090 TBD1 4 byte AS number [This I.D.] 1091 TBD2 OSPF Area ID [This I.D.] 1092 TBD3 IS-IS Area ID [This I.D.] 1094 5.2. Error Object Field Values 1096 The "PCEP Parameters" registry contains a subregistry "Error Types 1097 and Values". IANA is requested to make the following allocations 1098 from this subregistry 1100 ERROR Meaning Reference 1101 Type 1102 TBD4 "Unrecognized subobject" [This I.D.] 1103 Error-Value: type code 1105 6. Security Considerations 1107 This document specifies a standard representation of Domain-Sequence 1108 and new subobjects, which MAY be used in inter-domain PCE scenarios 1109 as explained in other RFC and drafts. The new subobjects and Domain- 1110 Sequence mechanisms defined in this document allow finer and more 1111 specific control of the path computed by a cooperating PCE(s). Such 1112 control increases the risk if a PCEP message is intercepted, 1113 modified, or spoofed because it allows the attacker to exert control 1114 over the path that the PCE will compute or to make the path 1115 computation impossible. Therefore, the security techniques described 1116 in [RFC5440] are considered more important. 1118 Note, however, that the Domain-Sequence mechanisms also provide the 1119 operator with the ability to route around vulnerable parts of the 1120 network and may be used to increase overall network security. 1122 7. Manageability Considerations 1124 7.1. Control of Function and Policy 1126 Several local policy decisions should be made at the PCE. Firstly, 1127 the exact behavior with regard to desired inclusion and exclusion of 1128 domains must be available for examination by an operator and may be 1129 configurable. Second, the behavior on receipt of an unrecognized 1130 subobjects with the L or X-bit set should be configurable and must be 1131 available for inspection. The inspection and control of these local 1132 policy choices may be part of the PCEP MIB module. 1134 7.2. Information and Data Models 1136 A MIB module for management of the PCEP is being specified in a 1137 separate document [PCEP-MIB]. That MIB module allows examination of 1138 individual PCEP messages, in particular requests, responses and 1139 errors. The MIB module MUST be extended to include the ability to 1140 view the domain-sequence extensions defined in this document. 1142 7.3. Liveness Detection and Monitoring 1144 Mechanisms defined in this document do not imply any new liveness 1145 detection and monitoring requirements in addition to those already 1146 listed in [RFC5440]. 1148 7.4. Verify Correct Operations 1150 Mechanisms defined in this document do not imply any new operation 1151 verification requirements in addition to those already listed in 1152 [RFC5440]. 1154 7.5. Requirements On Other Protocols 1156 In case of per-domain path computation [RFC5152], where the full path 1157 of an inter-domain TE LSP cannot be or is not determined at the 1158 ingress node, and signaling message may use domain identifiers. The 1159 Subobjects defined in this document SHOULD be supported by RSVP-TE. 1160 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1161 subobjects for IGP Areas and 4-byte AS numbers. 1163 Apart from this, mechanisms defined in this document do not imply any 1164 requirements on other protocols in addition to those already listed 1165 in [RFC5440]. 1167 7.6. Impact On Network Operations 1169 Mechanisms defined in this document do not have any impact on network 1170 operations in addition to those already listed in [RFC5440]. 1172 8. Acknowledgments 1174 We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, 1175 Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1176 Venugopal Reddy, Reeja Paul Sandeep Boina and Avantika for their 1177 useful comments and suggestions. 1179 9. References 1181 9.1. Normative References 1183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1184 Requirement Levels", BCP 14, RFC 2119, March 1997. 1186 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1187 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1188 2009. 1190 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1191 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1192 to Compute Shortest Constrained Inter-Domain Traffic 1193 Engineering Label Switched Paths", RFC 5441, April 2009. 1195 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1196 Path Computation Element Communication Protocol (PCEP) for 1197 Route Exclusions", RFC 5521, April 2009. 1199 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1200 Computation Element Architecture to the Determination of a 1201 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 1202 2012. 1204 9.2. Informative References 1206 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1207 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1208 Tunnels", RFC 3209, December 2001. 1210 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1211 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1212 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1214 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1215 in Resource ReSerVation Protocol - Traffic Engineering 1216 (RSVP-TE)", RFC 3477, January 2003. 1218 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1219 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1221 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1222 Inter-Domain Multiprotocol Label Switching Traffic 1223 Engineering", RFC 4726, November 2006. 1225 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1226 "GMPLS Segment Recovery", RFC 4873, May 2007. 1228 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1229 Extension to Resource ReserVation Protocol-Traffic 1230 Engineering (RSVP-TE)", RFC 4874, April 2007. 1232 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1233 Number Space", RFC 4893, May 2007. 1235 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1236 Path Computation Method for Establishing Inter-Domain 1237 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1238 5152, February 2008. 1240 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1241 Topology Confidentiality in Inter-Domain Path Computation 1242 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1244 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1245 Monitoring Tools for Path Computation Element (PCE)-Based 1246 Architecture", RFC 5886, June 2010. 1248 [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, 1249 "PCE-Based Computation Procedure to Compute Shortest 1250 Constrained Point-to-Multipoint (P2MP) Inter-Domain 1251 Traffic Engineering Label Switched Paths", RFC 7334, 1252 August 2014. 1254 [PCEP-MIB] 1255 Koushik, A., Emile, S., Zhao, Q., King, D., and J. 1256 Hardwick, "PCE communication protocol(PCEP) Management 1257 Information Base. (draft-ietf-pce-pcep-mib)", September 1258 2014. 1260 [PCE-P2MP-PER-DEST] 1261 Dhody, D., Palle, U., and V. Kondreddy, "Supporting 1262 explicit inclusion or exclusion of abstract nodes for a 1263 subset of P2MP destinations in Path Computation Element 1264 Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp- 1265 per-destination)", September 2014. 1267 [DOMAIN-SUBOBJ] 1268 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1269 "Domain Subobjects for Resource ReserVation Protocol - 1270 Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te- 1271 domain-subobjects)", July 2014. 1273 [IRO-SURVEY] 1274 Dhody, D., "Informal Survey into Include Route Object 1275 (IRO) Implementations in Path Computation Element 1276 communication Protocol (PCEP). (draft-dhody-pce-iro- 1277 survey-01)", October 2014. 1279 [IRO-UPDATE] 1280 Dhody, D., "Update to Include Route Object (IRO) 1281 specification in Path Computation Element communication 1282 Protocol (PCEP. (draft-dhody-pce-iro-update-00)", October 1283 2014. 1285 [ISO10589] 1286 ISO, "Intermediate system to Intermediate system routing 1287 information exchange protocol for use in conjunction with 1288 the Protocol for providing the Connectionless-mode Network 1289 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1291 Authors' Addresses 1293 Dhruv Dhody 1294 Huawei Technologies 1295 Leela Palace 1296 Bangalore, Karnataka 560008 1297 INDIA 1299 EMail: dhruv.ietf@gmail.com 1300 Udayasree Palle 1301 Huawei Technologies 1302 Leela Palace 1303 Bangalore, Karnataka 560008 1304 INDIA 1306 EMail: udayasree.palle@huawei.com 1308 Ramon Casellas 1309 CTTC 1310 Av. Carl Friedrich Gauss n7 1311 Castelldefels, Barcelona 08860 1312 SPAIN 1314 EMail: ramon.casellas@cttc.es