idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-05.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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2014) is 3588 days in the past. Is this intentional? 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 (==), 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: January 2, 2015 R. Casellas 6 CTTC 7 July 1, 2014 9 Standard Representation Of Domain-Sequence 10 draft-ietf-pce-pcep-domain-sequence-05 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 January 2, 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.2. Option (A): New IRO Object Type . . . . . . . . . . . 9 73 3.4.2.1. Handling of the Domain-Sequence IRO object . . . 11 74 3.4.3. Option B: Existing IRO Object Type . . . . . . . . . 12 75 3.4.4. Comparison . . . . . . . . . . . . . . . . . . . . . 13 76 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 14 77 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 14 78 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 14 79 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 15 80 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16 81 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 17 82 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 17 83 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 18 84 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 20 85 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 86 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 87 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 24 88 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 89 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 25 91 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . 27 92 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 94 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 28 95 5.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . 28 96 5.3. Error Object Field Values . . . . . . . . . . . . . . . . 28 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 98 7. Manageability Considerations . . . . . . . . . . . . . . . . 29 99 7.1. Control of Function and Policy . . . . . . . . . . . . . 29 100 7.2. Information and Data Models . . . . . . . . . . . . . . . 29 101 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 102 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 103 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 30 104 7.6. Impact On Network Operations . . . . . . . . . . . . . . 30 105 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 108 9.2. Informative References . . . . . . . . . . . . . . . . . 30 109 Appendix A. Sample Text for the IRO survey . . . . . . . . . . . 33 111 1. Introduction 113 A PCE may be used to compute end-to-end paths across multi-domain 114 environments using a per-domain path computation technique [RFC5152]. 115 The so called backward recursive path computation (BRPC) mechanism 116 [RFC5441] defines a PCE-based path computation procedure to compute 117 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 118 and BRPC techniques assume that the sequence of domains to be crossed 119 from source to destination is known, either fixed by the network 120 operator or obtained by other means. Also for inter-domain point-to- 121 multi-point (P2MP) tree computation, [PCE-P2MP-PROCEDURES] assumes 122 the domain-tree is known in priori. 124 The list of domains (domain-sequence) in a point-to-point (P2P) path 125 or a point-to-multi-point (P2MP) tree is usually a constraint in the 126 path computation request. The PCE determines the next PCE to forward 127 the request based on the domain-sequence. In a multi-domain path 128 computation, a PCC MAY indicate the sequence of domains to be 129 traversed using the Include Route Object (IRO) defined in [RFC5440]. 131 When the sequence of domains is not known in advance, the 132 Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be 133 used to determine the end-to-end Domain-Sequence. 135 This document defines a standard way to represent and encode a 136 Domain-Sequence in various deployment scenarios including P2P, P2MP 137 and H-PCE. 139 The Domain-Sequence (the set of domains traversed to reach the 140 destination domain) is either administratively predetermined or 141 discovered by some means (H-PCE) that is outside of the scope of this 142 document. 144 [RFC5440] defines the Include Route Object (IRO) and the Explicit 145 Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO) 146 and the Explicit Exclusion Route Subobject (EXRS); The use of 147 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 148 abstract node representing domain is defined in [RFC3209], this 149 document specifies new subobjects to include or exclude domains such 150 as an IGP area or an Autonomous Systems (4-Byte as per [RFC4893]). 152 Further, the domain identifier may simply act as delimiter to specify 153 where the domain boundary starts and ends. 155 This is a companion document to Resource ReserVation Protocol - 156 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 157 [DOMAIN-SUBOBJ]. 159 1.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 2. Terminology 167 The following terminology is used in this document. 169 ABR: OSPF Area Border Router. Routers used to connect two IGP 170 areas. 172 AS: Autonomous System. 174 ASBR: Autonomous System Boundary Router. 176 BN: Boundary Node, Can be an ABR or ASBR. 178 BRPC: Backward Recursive Path Computation 180 Domain: As per [RFC4655], any collection of network elements within 181 a common sphere of address management or path computational 182 responsibility. Examples of domains include Interior Gateway 183 Protocol (IGP) areas and Autonomous Systems (ASs). 185 Domain-Sequence: An ordered sequence of domains traversed to reach 186 the destination domain. 188 ERO: Explicit Route Object 189 H-PCE: Hierarchical PCE 191 IGP: Interior Gateway Protocol. Either of the two routing 192 protocols, Open Shortest Path First (OSPF) or Intermediate System 193 to Intermediate System (IS-IS). 195 IRO: Include Route Object 197 IS-IS: Intermediate System to Intermediate System. 199 OSPF: Open Shortest Path First. 201 PCC: Path Computation Client: any client application requesting a 202 path computation to be performed by a Path Computation Element. 204 PCE: Path Computation Element. An entity (component, application, 205 or network node) that is capable of computing a network path or 206 route based on a network graph and applying computational 207 constraints. 209 P2MP: Point-to-Multipoint 211 P2P: Point-to-Point 213 RSVP: Resource Reservation Protocol 215 TE LSP: Traffic Engineering Label Switched Path. 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 this context, the ordered nature of a domain-sequence is 242 considered to be important. In a P2P path, the domains listed appear 243 in the order that they are crossed. In a P2MP path, the domain tree 244 is represented as list of domain sequences. 246 A domain-sequence enables a PCE to select the next PCE to forward the 247 path computation request based on the domain information. 249 A PCC or PCE MAY add an additional constraints covering which 250 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be 251 traversed while defining a Domain-Sequence. 253 Thus a Domain-Sequence MAY be made up of one or more of - 255 o AS Number 257 o Area ID 259 o Boundary Node ID 261 o Inter-AS-Link Address 263 Consequently, a Domain-Sequence can be used: 265 1. by a PCE in order to discover or select the next PCE in a 266 collaborative path computation, such as in BRPC [RFC5441]; 268 2. by the Parent PCE to return the Domain-Sequence when unknown, 269 this can further be an input to BRPC procedure [RFC6805]; 271 3. by a PCC (or PCE) to constraint the domains used in a H-PCE path 272 computation, explicitly specifying which domains to be expanded; 274 4. by a PCE in per-domain path computation model [RFC5152] to 275 identify the next domain(s); 277 3.3. Standard Representation 279 Domain-Sequence MAY appear in PCEP Messages, notably in - 281 o Include Route Object (IRO): As per [RFC5440], used to specify set 282 of network elements that MUST be traversed. These subobjects are 283 used to specify the domain-sequence that MUST be traversed to 284 reach the destination. 286 o Exclude Route Object (XRO): As per [RFC5521], used to specify 287 certain abstract nodes that MUST be excluded from whole path. 288 These subobjects are used to specify certain domains that MUST be 289 avoided to reach the destination. 291 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used 292 to specify exclusion of certain abstract nodes between a specific 293 pair of nodes. EXRS are a subobject inside the IRO. These 294 subobjects are used to specify the domains that must be excluded 295 between two abstract nodes. 297 o Explicit Route Object (ERO): As per [RFC5440], used to specify a 298 computed path in the network. For example, in the case of H-PCE 299 [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a 300 path computation reply using ERO. 302 3.4. Include Route Object (IRO) 304 As per [RFC5440], IRO (Include Route Object) can be used to specify 305 that the computed path MUST traverse a set of specified network 306 elements or abstract nodes. 308 3.4.1. Subobjects 310 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 311 [RFC4874], but new subobjects related to Domain-Sequence are needed. 313 The following subobject types are used in IRO. 315 Type Subobject 316 1 IPv4 prefix 317 2 IPv6 prefix 318 4 Unnumbered Interface ID 319 32 Autonomous system number (2 Byte) 320 33 Explicit Exclusion (EXRS) 322 This document extends the above list to support 4-Byte AS numbers and 323 IGP Areas. 325 Type Subobject 326 TBD Autonomous system number (4 Byte) 327 TBD OSPF Area id 328 TBD ISIS Area id 330 - Autonomous system 332 [RFC3209] already defines 2 byte AS number. 334 To support 4 byte AS number as per [RFC4893] following subobject is 335 defined: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |L| Type | Length | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | AS-ID (4 bytes) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 L: The L bit is an attribute of the subobject as defined in 346 [RFC3209]. 348 Type: (TBA by IANA) indicating a 4-Byte AS Number. 350 Length: 8 (Total length of the subobject in bytes). 352 Reserved: Zero at transmission, ignored at receipt. 354 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 355 use, the low order bits (16 through 31) should be used and the 356 high order bits (0 through 15) should be set to zero. 358 - IGP Area 360 Since the length and format of Area-id is different for OSPF and 361 ISIS, following two subobjects are defined: 363 For OSPF, the area-id is a 32 bit number. The subobject is encoded 364 as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |L| Type | Length | Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | OSPF Area Id (4 bytes) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 L: The L bit is an attribute of the subobject as defined in 375 [RFC3209]. 377 Type: (TBA by IANA) indicating a 4-Byte OSPF Area ID. 379 Length: 8 (Total length of the subobject in bytes). 381 Reserved: Zero at transmission, ignored at receipt. 383 OSPF Area Id: The 4-Byte OSPF Area ID. 385 For IS-IS, the area-id is of variable length and thus the length of 386 the Subobject is variable. The Area-id is as described in IS-IS by 387 ISO standard [ISO10589]. The subobject is encoded as follows: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |L| Type | Length | Area-Len | Reserved | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 // IS-IS Area ID // 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 L: The L bit is an attribute of the subobject as defined in 400 [RFC3209]. 402 Type: (TBA by IANA) indicating IS-IS Area ID. 404 Length: Variable. As per [RFC3209], the total length of the 405 subobject in bytes, including the L, Type and Length fields. The 406 Length MUST be at least 4, and MUST be a multiple of 4. 408 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 409 Identifier in octets; Valid values are from 2 to 11 inclusive). 411 Reserved: Zero at transmission, ignored at receipt. 413 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 414 with trailing zeroes to a four-byte boundary. 416 3.4.2. Option (A): New IRO Object Type 418 [Editor's Note: Currently there is a discussion going on in the 419 working group (WG) to evaluate if the existing IRO as per [RFC5440] 420 can be considered to be ordered in nature. It has been suggested 421 that a poll could be issued to gather feedback from the current 422 implementations, based on which WG could decide to clarify the 423 position on IRO. The following section would be revaluated and 424 updated based on that decision. See Appendix A for the sample survey 425 text.] 427 [RFC5440] in its description of IRO does not require the subobjects 428 to be in a given particular order. When considering a Domain- 429 Sequence, the domain relative ordering is a basic criterion and, as 430 such, this option suggest a new IRO object type. 432 IRO Object-Class is 10. 433 IRO Object-Type is TBD. (2 suggested value to IANA) 435 0 1 2 3 436 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 // (Subobjects) // 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Subobjects: The IRO is made of subobjects identical to the ones 444 defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO 445 subobject type is identical to the subobject type defined in the 446 related documents. Some new subobjects related to Domain-Sequence 447 are also added in this document as mentioned in Section 3.4. 449 [RFC3209] defines subobjects for IPv4, IPv6 and unnumbered Interface 450 ID, which in the context of domain-sequence is used to specify 451 Boundary Node (ABR/ASBR) and Inter-AS-Links. The subobjects for AS 452 Number (2 or 4 Byte) and IGP Area is used to specify the domain 453 identifiers in the domain-sequence. 455 The new IRO Object-Type used to define the domain-sequence would 456 handle the L bit (Loose / Strict) in the subobjects similar to 457 [RFC3209]. 459 Further we have following options: 461 * Option (A.1): New IRO Object Type for Domain-Sequence object only. 462 A new IRO Object Type is used to specify the ordered sequence of 463 domains (Domain-Sequence) only. The PCReq message is modified to 464 allow encoding of both types of IRO; one with IRO Type 1 [RFC5440] 465 used to specify the intra-domain abstract nodes and resources and 466 the second IRO Type with the new subobjects as described in this 467 section to specify the domain-sequence. All other rules of PCEP 468 objects and message processing (ex. P bit handling of Common 469 Object Header) is as per [RFC5440]. 471 * Option (A.2): New IRO Object Type for both intra and inter-domain 472 (domain-sequence). A new IRO Object Type is used to include both 473 intra nodes and inter-domains nodes but the sequence of domain is 474 strict. The intra-domain nodes can still be ordered. In case of 475 inter-domain path computation, only the new IRO type is used which 476 contains the specific intra domain network nodes as well as inter- 477 domain abstract nodes or domains. The inter-domain abstract nodes 478 are encoded in the sequence they must be traversed but the intra- 479 domain elements MAY be an unordered set. There is no need to 480 change the PCReq message format. 482 3.4.2.1. Handling of the Domain-Sequence IRO object 484 An IRO object containing Domain-Sequence subobjects constraints or 485 defines the domains involved in a multi-domain path computation, 486 typically involving two or more collaborative PCEs. 488 A Domain-Sequence can have varying degrees of granularity; it is 489 possible to have a Domain-Sequence composed of, uniquely, AS 490 identifiers. It is also possible to list the involved areas for a 491 given AS. 493 In any case, the mapping between domains and responsible PCEs is not 494 defined in this document. It is assumed that a PCE that needs to 495 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 496 administrative configuration, or discovery). 498 A PCC builds a Domain-Sequence IRO to encode the Domain-Sequence, 499 that is all domains that it wishes the cooperating PCEs to traverse 500 in order to compute the end to end path. 502 For each inclusion, the PCC clears the L-bit to indicate that the PCE 503 is required to include the domain, or sets the L-bit to indicate that 504 the PCC simply desires that the domain be included in the domain- 505 sequence. 507 When a PCE receives a PCEP Request message with an IRO, it looks for 508 a Domain-Sequence IRO (new type) to see if a domain-sequence is 509 specified. If the message contains more than one Domain-Sequence IRO 510 (new type), it MUST use the first one in the message and MUST ignore 511 subsequent instances. 513 If a PCE does not recognize the Domain-Sequence IRO (new type), it 514 MUST return a PCErr message with Error-Type "Unknown Object" and 515 Error-value "Unrecognized object Type" as described in [RFC5440]. 517 If a PCE is unwilling or unable to process the Domain-Sequence IRO 518 (new type), it MUST return a PCErr message with the Error-Type "Not 519 supported object" and follow the relevant procedures described in 520 [RFC5440]. 522 If a PCE that supports the Domain-Sequence IRO (new type) and 523 encounters a subobject that it does not support or recognize, it MUST 524 act according to the setting of the L-bit in the subobject. If the 525 L-bit is clear, the PCE MUST respond with a PCErr with Error-Type 526 "Unrecognized subobject" and set the Error-Value to the subobject 527 type code. If the L-bit is set, the PCE MAY respond with a PCErr as 528 already stated or MAY ignore the subobject: this choice is a local 529 policy decision. 531 If a PCE parses a Domain-Sequence IRO (new type), it MUST act 532 according to the requirements expressed in the subobject. That is, 533 if the L-bit is clear, the PCE(s) MUST produce a path that follows 534 domain-sequence nodes in order identified by the subobjects in the 535 path. If the L-bit is set, the PCE(s) SHOULD produce a path along 536 the Domain-Sequence unless it is not possible to construct a path 537 complying with the other constraints expressed in the request. 539 A successful path computation reported in a PCEP response message 540 MUST include an ERO to specify the path that has been computed as 541 specified in [RFC5440] following the sequence of domains. 543 In a PCEP response message, PCE MAY also supply a Domain-Sequence IRO 544 (new type) with the NO-PATH object indicating that the set of 545 elements of the request's Domain-Sequence IRO prevented the PCE from 546 finding a path. 548 Subobject types for AS and IGP Area affect the next domain selection 549 as well as finding the PCE serving that domain. 551 Note that a particular domain in the domain-sequence can be 552 identified by :- 554 o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is 555 used to identify the next domain. (Refer Figure 1) 557 o A single AS: Only the AS subobject is used to identify the next 558 domain. (Refer Figure 2) 560 o Both an AS and an IGP Area: Combination of both AS and Area are 561 used to identify the next domain. In this case the order is AS 562 Subobject followed by Area. (Refer Figure 3) 564 Subobject representing Boundary Node or Inter-AS-Link MUST be applied 565 during the final path computation procedure as before. 567 3.4.3. Option B: Existing IRO Object Type 569 The IRO (Include Route Object) [RFC5440] is an optional object used 570 to specify a set of network elements that the computed path MUST 571 traverse. 573 The new subobjects denoting the domain-sequence are carried in the 574 same IRO Type 1, and all the rules of processing as specified in 575 [RFC5440] are applied. 577 Note the following differences :- 579 o Order: Since there is no inherent order specified in the encoding 580 of the subobjects in IRO Type 1 [RFC5440], it is the job of the 581 PCE to figure out the optimal order of the domains to be crossed 582 to reach the destination domain. Note that in case of doubt, or 583 when applicable, the PCE can still apply the ordering as specified 584 in the request message. Further PCE may have to crankback and try 585 multiple permutations before figuring out the correct sequence. 587 o Loose / Strict (L-Bit): [RFC5440] state that the L bit of the 588 subobjects within an IRO Type 1 [RFC5440] has no meaning. This 589 will be applicable for subobjects denoting domain-sequence as 590 well. 592 o Scope: Coexistence of intra-domain nodes, boundary nodes and 593 domain nodes in the same IRO List. It is the job of PCE to figure 594 out the scope and apply the processing rules accordingly. The 595 nodes in the IRO which are recognized by the PCE are handled 596 locally and others are forwarded to next PCE hoping they would 597 handle them, the aggregating PCE (Ingress PCE or Parent) would 598 make sure that all nodes in IRO are handled correctly. 600 3.4.4. Comparison 602 +-------------+-------------------+-------------------+-------------------+ 603 | |Option (A.1): New |Option (A.2): New |Option B: Existing | 604 | |IRO Object Type for|IRO Object Type for|IRO Object Type | 605 | |Domain-Sequence |both intra and | | 606 | |object only |inter-domain | | 607 +-------------+-------------------+-------------------+-------------------+ 608 |Order |Yes |Yes |No | 609 +-------------+-------------------+-------------------+-------------------+ 610 |L/X bit |Yes |Yes |No | 611 +-------------+-------------------+-------------------+-------------------+ 612 |Msg Format |No |Yes |Yes | 613 |Unchanged | | | | 614 +-------------+-------------------+-------------------+-------------------+ 615 |Seperation |Yes |Yes* |No | 616 |of scope | | | | 617 +-------------+-------------------+-------------------+-------------------+ 619 * becasue of the ordered nature, intra-domain nodes would be first in the 620 new IRO type 622 [Editor's Note: Based on our opinion and the feedback received so 623 far, we feel the option A.2 should be selected.] 625 3.5. Exclude Route Object (XRO) 627 The Exclude Route Object (XRO) [RFC5521] is an optional object used 628 to specify exclusion of certain abstract nodes or resources from the 629 whole path. 631 3.5.1. Subobjects 633 The following subobject types are defined to be used in XRO as 634 defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. 636 Type Subobject 637 1 IPv4 prefix 638 2 IPv6 prefix 639 4 Unnumbered Interface ID 640 32 Autonomous system number (2 Byte) 641 34 SRLG 642 64 IPv4 Path Key 643 65 IPv6 Path Key 645 This document extends the above list to support 4-Byte AS numbers and 646 IGP Areas. 648 Type Subobject 649 TBD Autonomous system number (4 Byte) 650 TBD OSPF Area id 651 TBD ISIS Area id 653 3.5.1.1. Autonomous system 655 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 656 MAY also be used in the XRO to specify exclusion of certain domains 657 in the path computation procedure. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |X| Type | Length | Reserved | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | AS-ID (4 bytes) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 The X-bit indicates whether the exclusion is mandatory or desired. 669 0: indicates that the AS specified MUST be excluded from the path 670 computed by the PCE(s). 672 1: indicates that the AS specified SHOULD be avoided from the inter- 673 domain path computed by the PCE(s), but MAY be included subject to 674 PCE policy and the absence of a viable path that meets the other 675 constraints. 677 All other fields are consistent with the definition in Section 3.4. 679 3.5.1.2. IGP Area 681 Since the length and format of Area-id is different for OSPF and 682 ISIS, following two subobjects are defined: 684 For OSPF, the area-id is a 32 bit number. The subobject is encoded 685 as follows: 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 |X| Type | Length | Reserved | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | OSPF Area Id (4 bytes) | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 The X-bit indicates whether the exclusion is mandatory or desired. 697 0: indicates that the OSFF Area specified MUST be excluded from the 698 path computed by the PCE(s). 700 1: indicates that the OSFF Area specified SHOULD be avoided from the 701 inter-domain path computed by the PCE(s), but MAY be included 702 subject to PCE policy and the absence of a viable path that meets 703 the other constraints. 705 All other fields are consistent with the definition in Section 3.4. 707 For IS-IS, the area-id is of variable length and thus the length of 708 the subobject is variable. The Area-id is as described in IS-IS by 709 ISO standard [ISO10589]. The subobject is encoded as follows: 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 |X| Type | Length | Area-Len | Reserved | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | | 717 // IS-IS Area ID // 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 The X-bit indicates whether the exclusion is mandatory or desired. 723 0: indicates that the ISIS Area specified MUST be excluded from the 724 path computed by the PCE(s). 726 1: indicates that the ISIS Area specified SHOULD be avoided from the 727 inter-domain path computed by the PCE(s), but MAY be included 728 subject to PCE policy and the absence of a viable path that meets 729 the other constraints. 731 All other fields are consistent with the definition in Section 3.4. 733 If a PCE that supports XRO and encounters a subobject that it does 734 not support or recognize, it MUST act according to the setting of the 735 X-bit in the subobject. If the X-bit is clear, the PCE MUST respond 736 with a PCErr with Error-Type "Unrecognized subobject" and set the 737 Error-Value to the subobject type code. If the X-bit is set, the PCE 738 MAY respond with a PCErr as already stated or MAY ignore the 739 subobject: this choice is a local policy decision. 741 All the other processing rules are as per [RFC5521]. 743 3.6. Explicit Exclusion Route Subobject (EXRS) 745 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 746 specify exclusion of certain abstract nodes between a specific pair 747 of nodes. 749 The EXRS subobject may carry any of the subobjects defined for 750 inclusion in the XRO, thus the new subobjects to support 4 byte AS 751 and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The 752 meanings of the fields of the new XRO subobjects are unchanged when 753 the subobjects are included in an EXRS, except that scope of the 754 exclusion is limited to the single hop between the previous and 755 subsequent elements in the IRO. 757 All the processing rules are as per [RFC5521]. 759 3.7. Explicit Route Object (ERO) 761 The Explicit Route Object (ERO) [RFC5440] is used to specify a 762 computed path in the network. PCEP ERO subobject types correspond to 763 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 764 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. 766 Type Subobject 767 1 IPv4 prefix 768 2 IPv6 prefix 769 3 Label 770 4 Unnumbered Interface ID 771 32 Autonomous system number (2 Byte) 772 33 Explicit Exclusion (EXRS) 773 37 Protection 774 64 IPv4 Path Key 775 65 IPv6 Path Key 777 This document extends the above list to support 4-Byte AS numbers and 778 IGP Areas. 780 Type Subobject 781 TBD Autonomous system number (4 Byte) 782 TBD OSPF Area id 783 TBD ISIS Area id 785 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 786 MAY also be used in the ERO to specify an abstract node (a group of 787 nodes whose internal topology is opaque to the ingress node of the 788 LSP). Using this concept of abstraction, an explicitly routed LSP 789 can be specified as a sequence of domains. 791 In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested 792 to find the domain-sequence. Refer example in Section 4.6. 794 The format of the new ERO subobjects is similar to new IRO 795 subobjects, refer Section 3.4. 797 4. Other Considerations 799 The examples in this section are for illustration purposes only; to 800 show how the new subobjects may be encoded. 802 4.1. Inter-Area Path Computation 804 In an inter-area path computation where the ingress and the egress 805 nodes belong to different IGP areas within the same AS, the Domain- 806 Sequence MAY be represented using a ordered list of Area subobjects. 807 The AS number MAY be skipped, as area information is enough to select 808 the next PCE. 810 +-------------------+ +-------------------+ 811 | | | | 812 | +--+ | | +--+ | 813 | +--+ | | | | | | | 814 | | | +--+ | | +--+ +--+ | 815 | +--* + + | | | 816 | | | +--+ | 817 | *--+ + + | 818 | | | | | +--+ | 819 | +--+ | | | | | 820 | |+--------------------------+| +--+ | 821 | ++++ +-++ | 822 | |||| +--+ | || | 823 | Area 2 ++++ | | +-++ Area 4 | 824 +-------------------+| +--+ |+-------------------+ 825 | | 826 | +--+ | 827 | +--+ | | | 828 | | | +--+ | 829 | +--+ | 830 | | 831 | | 832 | | 833 | | 834 | +--+ | 835 | | | | 836 | +--+ | 837 +------------------+| |+--------------------+ 838 | ++-+ +-++ | 839 | || | | || | 840 | ++-+ Area 0 +-++ | 841 | |+--------------------------+| +--+ | 842 | +--+ | | | | | 843 | | | | | +--+ | 844 | +--+ +--+ | | | 845 | | | + + +--+ | 846 | +--+ | | | | | 847 | + + +--+ | 848 | +--+ | | | 849 | | | | | +--+ | 850 | +--+ | | | | | 851 | | | +--+ | 852 | | | | 853 | Area 1 | | Area 5 | 854 +------------------+ +--------------------+ 856 Figure 1: Inter-Area Path Computation 858 AS Number is 100. 860 This could be represented in the as: 862 +---------+ +---------+ +---------+ +---------+ 863 |IRO | |Sub | |Sub | |Sub | 864 |Object | |Object | |Object | |Object | 865 |Header | |Area 2 | |Area 0 | |Area 4 | 866 | | | | | | | | 867 | | | | | | | | 868 +---------+ +---------+ +---------+ +---------+ 870 +---------+ +---------+ +---------+ +---------+ +---------+ 871 |IRO | |Sub | |Sub | |Sub | |Sub | 872 |Object | |Object AS| |Object | |Object | |Object | 873 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 874 | | | | | | | | | | 875 | | | | | | | | | | 876 +---------+ +---------+ +---------+ +---------+ +---------+ 878 AS is optional and it MAY be skipped. PCE should be able to 879 understand both notations. 881 4.2. Inter-AS Path Computation 883 In inter-AS path computation, where ingress and egress belong to 884 different AS, the Domain-Sequence is represented using an ordered 885 list of AS subobjects. The Domain-Sequence MAY further include 886 decomposed area information in Area subobjects. 888 4.2.1. Example 1 890 As shown in Figure 2, where AS to be made of a single area, the area 891 subobject MAY be skipped in the Domain-Sequence as AS is enough to 892 uniquely identify the next domain and PCE. 894 +---------------------------------+ 895 |AS 200 | 896 | +------+ | 897 | | | | 898 +------------------------+ | | | +------+ | 899 | AS 100 | | +------+ | | | 900 | +------+ | | +------+ | | | 901 | | +-+-----+-+ | +------+ | 902 | | | | | | | | 903 | +------+ | | +------+ | 904 | +------+ | | +------+ | 905 | | | | | | | | 906 | | | | | | | | 907 | +------+ | | +------+ | 908 | | | | 909 | +------+ | | +------+ | 910 | | +-+-----+-+ | +------+ | 911 | | | | | | | | | | 912 | +------+ | | +------+ | | | 913 | | | +------+ | 914 | | | | 915 | | | | 916 | +------+ | | +------+ | 917 | | | | | | | | 918 | |PCE | | | |PCE | | 919 | +------+ | | +------+ | 920 | | | | 921 +------------------------+ | | 922 +---------------------------------+ 924 Figure 2: Inter-AS Path Computation 926 Both AS are made of Area 0. 928 This could be represented in the as: 930 +---------+ +---------+ +---------+ 931 |IRO | |Sub | |Sub | 932 |Object | |Object AS| |Object AS| 933 |Header | |100 | |200 | 934 | | | | | | 935 | | | | | | 936 +---------+ +---------+ +---------+ 938 +---------+ +---------+ +---------+ +---------+ +---------+ 939 |IRO | |Sub | |Sub | |Sub | |Sub | 940 |Object | |Object AS| |Object | |Object AS| |Object | 941 |Header | |100 | |Area 0 | |200 | |Area 0 | 942 | | | | | | | | | | 943 | | | | | | | | | | 944 +---------+ +---------+ +---------+ +---------+ +---------+ 946 Area subobject is optional and it MAY be skipped. PCE should be able 947 to understand both notations. 949 4.2.2. Example 2 951 As shown in Figure 3, where AS 200 is made up of multiple areas and 952 multiple domain-sequence exist, PCE MAY include both AS and Area 953 subobject to uniquely identify the next domain and PCE. 955 | 956 | +-------------+ +----------------+ 957 | |Area 2 | |Area 4 | 958 | | +--+| | +--+ | 959 | | | || | | | | 960 | | +--+ +--+| | +--+ +--+ | 961 | | | | | | | | | 962 | | *--+ | | +--+ | 963 | | / +--+ | | +--+ | 964 | |/ | | | | | | | 965 | / +--+ | | +--+ +--+ | 966 | /| +--+ |+--------------+| | | | 967 |/ | | | ++-+ +-++ +--+ | 968 +-------------+/ | +--+ || | | || | 969 | /| | ++-+ +-++ | 970 | +--*|| +-------------+| |+----------------+ 971 | | ||| | +--+ | 972 | +--+|| | | | | 973 | +--+ || | +--+ | 974 | | | || | | 975 | +--+ || | | 976 | || | +--+ | 977 |+--+ || | | | | 978 || | || | +--+ | 979 |+--+ || | | 980 | || | +--+ | 981 | +--+ || +------------+ | | | |+----------------+ 982 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 983 | +--+ || | | || | || | 984 | || | +-++ +-++ | 985 | +--+|| | +--+ | | Area 0 || +--+ | 986 | | ||| | | | | +--------------+| | | | 987 | +--*|| | +--+ | | +--+ | 988 | \| | | | +--+ | 989 |Area 1 |\ | +--+ | | +--+ | | | 990 +-------------+|\ | | | | | | | +--+ | 991 | \| +--+ +--+ | +--+ | 992 | \ | | | | 993 | |\ +--+ | +--+ | 994 | | \ +--+ | | | | | 995 | | \| | | | +--+ | 996 | | *--+ | | | 997 | | | | | 998 | +------------+ +----------------+ 999 | 1000 | 1001 AS 100 | AS 200 1002 | 1004 Figure 3: Inter-AS Path Computation 1006 The Domain-Sequence can be carried in the IRO as shown below: 1008 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1009 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 1010 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 1011 |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 1012 | | | | | | | | | | | | | | 1013 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1015 The combination of both an AS and an Area uniquely identify a domain 1016 in the Domain-Sequence. 1018 Note that an Area domain identifier always belongs to the previous AS 1019 that appears before it or, if no AS subobjects are present, it is 1020 assumed to be the current AS. 1022 If the area information cannot be provided, PCE MAY forward the path 1023 computation request to the next PCE based on AS alone. If multiple 1024 PCEs are responsible, PCE MAY apply local policy to select the next 1025 PCE. 1027 4.3. Boundary Node and Inter-AS-Link 1029 A PCC or PCE MAY add additional constraints covering which Boundary 1030 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 1031 while defining a Domain-Sequence. In which case the Boundary Node or 1032 Link MAY be encoded as a part of the domain-sequence using the 1033 existing subobjects. 1035 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 1036 prefix subobjects usually the loopback address of 32 and 128 prefix 1037 length respectively. An Inter-AS link can be encoded using the IPv4 1038 or IPv6 prefix subobjects or unnumbered interface subobjects. 1040 For Figure 1, an ABR to be traversed can be specified as: 1042 +---------+ +---------+ +---------++---------+ +---------+ 1043 |IRO | |Sub | |Sub ||Sub | |Sub | 1044 |Object | |Object | |Object ||Object | |Object | 1045 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 1046 | | | | |x.x.x.x || | | | 1047 | | | | | || | | | 1048 +---------+ +---------+ +---------++---------+ +---------+ 1050 For Figure 2, an inter-AS-link to be traversed can be specified as: 1052 +---------+ +---------+ +---------+ +---------+ +---------+ 1053 |IRO | |Sub | |Sub | |Sub | |Sub | 1054 |Object | |Object AS| |Object | |Object | |Object AS| 1055 |Header | |100 | |IPv4 | |IPv4 | |200 | 1056 | | | | |x.x.x.x | |x.x.x.x | | | 1057 | | | | | | | | | | 1058 +---------+ +---------+ +---------+ +---------+ +---------+ 1060 4.4. PCE Serving multiple Domains 1062 A single PCE MAY be responsible for multiple domains; for example PCE 1063 function deployed on an ABR. A PCE which can support 2 adjacent 1064 domains can internally handle this situation without any impact on 1065 the neighboring domains. 1067 4.5. P2MP 1069 In case of inter-domain P2MP path computation, (Refer 1070 [PCE-P2MP-PROCEDURES]) the path domain tree is nothing but a series 1071 of Domain Sequences, as shown in the below figure: 1073 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 1074 D1 1075 / \ 1076 D2 D3 1077 / / \ 1078 D4 D5 D6 1080 All rules of processing as applied to P2P can be applied to P2MP as 1081 well. 1083 In case of P2MP, different destinations MAY have different Domain- 1084 Sequence within the domain tree, it requires domain-sequence to be 1085 attached per destination. (Refer [PCE-P2MP-PER-DEST]) 1087 4.6. Hierarchical PCE 1089 As per [RFC6805], consider a case as shown in Figure 4 consisting of 1090 multiple child PCEs and a parent PCE. 1092 +--------+ 1093 | Parent | 1094 | PCE | 1095 +--------+ 1097 +-------------------+ +-------------------+ 1098 | +--+ | | +--+ | 1099 | +--+ | | | | | | | 1100 | | | +--+ | | +--+ +--+ | 1101 | +--* + + | | | 1102 | | | +--+ | 1103 | *--+ + + | 1104 | | | | | +--+ | 1105 | +--+ | | | | | 1106 | |+--------------------------+| +--+ | 1107 | ++++ +-++ | 1108 | |||| +--+ | || | 1109 | Area 2 ++++ | | +-++ Area 4 | 1110 +-------------------+| +--+ |+-------------------+ 1111 | +--+ | 1112 | +--+ | | | 1113 | | | +--+ | 1114 | +--+ | 1115 | | 1116 | +--+ | 1117 | | | | 1118 | +--+ | 1119 +------------------+| |+--------------------+ 1120 | ++-+ +-++ | 1121 | || | | || | 1122 | ++-+ Area 0 +-++ | 1123 | |+--------------------------+| +--+ | 1124 | +--+ | | | | | 1125 | | | | | +--+ | 1126 | +--+ +--+ | | | 1127 | | | + + +--+ | 1128 | +--+ | | | | | 1129 | + + +--+ | 1130 | +--+ | | | 1131 | | | | | +--+ | 1132 | +--+ | | | | | 1133 | | | +--+ | 1134 | Area 1 | | Area 5 | 1135 +------------------+ +--------------------+ 1137 Figure 4: Hierarchical PCE 1139 In H-PCE, the Ingress PCE PCE(1) can request the parent PCE to 1140 determine the Domain-Sequence and return it in the PCEP response, 1141 using the ERO Object. The ERO can contain an ordered sequence of 1142 subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, 1143 the Domain-Sequence appear as: 1145 +---------+ +---------+ +---------+ +---------+ 1146 |ERO | |Sub | |Sub | |Sub | 1147 |Object | |Object | |Object | |Object | 1148 |Header | |Area 2 | |Area 0 | |Area 4 | 1149 | | | | | | | | 1150 | | | | | | | | 1151 +---------+ +---------+ +---------+ +---------+ 1153 +---------+ +---------+ +---------+ +---------+ +---------+ 1154 |ERO | |Sub | |Sub | |Sub | |Sub | 1155 |Object | |Object AS| |Object | |Object | |Object | 1156 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 1157 | | | | | | | | | | 1158 | | | | | | | | | | 1159 +---------+ +---------+ +---------+ +---------+ +---------+ 1161 Note that, in the case of ERO objects, no new PCEP object type is 1162 required since the ordering constraint is assumed. 1164 4.7. Relationship to PCE Sequence 1166 Instead of a domain-sequence, a sequence of PCEs MAY be enforced by 1167 policy on the PCC, and this constraint can be carried in the PCReq 1168 message (as defined in [RFC5886]). 1170 Note that PCE-Sequence can be used along with domain-sequence in 1171 which case PCE-Sequence SHOULD have higher precedence in selecting 1172 the next PCE in the inter-domain path computation procedures. Note 1173 that Domain-Sequence IRO constraints should still be checked as per 1174 the rules of processing IRO. 1176 4.8. Relationship to RSVP-TE 1178 [RFC3209] already describes the notion of abstract nodes, where an 1179 abstract node is a group of nodes whose internal topology is opaque 1180 to the ingress node of the LSP. It further defines a subobject for 1181 AS but with a 2-Byte AS Number. 1183 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1184 subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY 1185 be included in Explicit Route Object (ERO), Exclude Route object 1186 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1188 In any case subobject type defined in RSVP-TE are identical to the 1189 subobject type defined in the related documents in PCEP. 1191 5. IANA Considerations 1193 5.1. PCEP Objects 1195 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 1196 IANA is requested to make the following allocations from this 1197 registry. 1199 Object Name Reference 1200 Class 1201 10 IRO [RFC5440] 1202 Object-Type 1203 (TBA): Domain-Sequence [This I.D.] 1205 5.2. New Subobjects 1207 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1208 with an entry for the Include Route Object (IRO), Exclude Route 1209 Object (XRO) and Explicit Route Object (ERO). IANA is requested to 1210 add further subobjects as follows: 1212 7 ERO 1213 10 IRO 1214 17 XRO 1216 Subobject Type Reference 1217 TBA 4 byte AS number [This I.D.] 1218 TBA OSPF Area ID [This I.D.] 1219 TBA IS-IS Area ID [This I.D.] 1221 5.3. Error Object Field Values 1223 The "PCEP Parameters" registry contains a subregistry "Error Types 1224 and Values". IANA is requested to make the following allocations 1225 from this subregistry 1227 ERROR Meaning Reference 1228 Type 1229 TBA "Unrecognized subobject" [This I.D.] 1230 Error-Value: type code 1232 6. Security Considerations 1234 This document specifies a standard representation of Domain-Sequence 1235 and new subobjects, which MAY be used in inter-domain PCE scenarios 1236 as explained in other RFC and drafts. The new subobjects and Domain- 1237 Sequence mechanisms defined in this document allow finer and more 1238 specific control of the path computed by a cooperating PCE(s). Such 1239 control increases the risk if a PCEP message is intercepted, 1240 modified, or spoofed because it allows the attacker to exert control 1241 over the path that the PCE will compute or to make the path 1242 computation impossible. Therefore, the security techniques described 1243 in [RFC5440] are considered more important. 1245 Note, however, that the Domain-Sequence mechanisms also provide the 1246 operator with the ability to route around vulnerable parts of the 1247 network and may be used to increase overall network security. 1249 7. Manageability Considerations 1251 7.1. Control of Function and Policy 1253 Several local policy decisions should be made at the PCE. Firstly, 1254 the exact behavior with regard to desired inclusion and exclusion of 1255 domains must be available for examination by an operator and may be 1256 configurable. Second, the behavior on receipt of an unrecognized 1257 subobjects with the L or X-bit set should be configurable and must be 1258 available for inspection. The inspection and control of these local 1259 policy choices may be part of the PCEP MIB module. 1261 7.2. Information and Data Models 1263 A MIB module for management of the PCEP is being specified in a 1264 separate document [PCEP-MIB]. That MIB module allows examination of 1265 individual PCEP messages, in particular requests, responses and 1266 errors. The MIB module MUST be extended to include the ability to 1267 view the domain-sequence extensions defined in this document. 1269 7.3. Liveness Detection and Monitoring 1271 Mechanisms defined in this document do not imply any new liveness 1272 detection and monitoring requirements in addition to those already 1273 listed in [RFC5440]. 1275 7.4. Verify Correct Operations 1277 Mechanisms defined in this document do not imply any new operation 1278 verification requirements in addition to those already listed in 1279 [RFC5440]. 1281 7.5. Requirements On Other Protocols 1283 In case of per-domain path computation [RFC5152], where the full path 1284 of an inter-domain TE LSP cannot be or is not determined at the 1285 ingress node, and signaling message may use domain identifiers. The 1286 Subobjects defined in this document SHOULD be supported by RSVP-TE. 1287 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1288 subobjects for IGP Areas and 4-byte AS numbers. 1290 Apart from this, mechanisms defined in this document do not imply any 1291 requirements on other protocols in addition to those already listed 1292 in [RFC5440]. 1294 7.6. Impact On Network Operations 1296 Mechanisms defined in this document do not have any impact on network 1297 operations in addition to those already listed in [RFC5440]. 1299 8. Acknowledgments 1301 We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, 1302 Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1303 Venugopal Reddy, Reeja Paul Sandeep Boina and Avantika for their 1304 useful comments and suggestions. 1306 9. References 1308 9.1. Normative References 1310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1311 Requirement Levels", BCP 14, RFC 2119, March 1997. 1313 9.2. Informative References 1315 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1316 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1317 Tunnels", RFC 3209, December 2001. 1319 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1320 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1321 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1323 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1324 in Resource ReSerVation Protocol - Traffic Engineering 1325 (RSVP-TE)", RFC 3477, January 2003. 1327 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1328 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1330 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1331 Inter-Domain Multiprotocol Label Switching Traffic 1332 Engineering", RFC 4726, November 2006. 1334 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1335 "GMPLS Segment Recovery", RFC 4873, May 2007. 1337 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1338 Extension to Resource ReserVation Protocol-Traffic 1339 Engineering (RSVP-TE)", RFC 4874, April 2007. 1341 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1342 Number Space", RFC 4893, May 2007. 1344 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1345 Path Computation Method for Establishing Inter-Domain 1346 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1347 5152, February 2008. 1349 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1350 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1351 2009. 1353 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1354 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1355 to Compute Shortest Constrained Inter-Domain Traffic 1356 Engineering Label Switched Paths", RFC 5441, April 2009. 1358 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1359 Topology Confidentiality in Inter-Domain Path Computation 1360 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1362 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1363 Path Computation Element Communication Protocol (PCEP) for 1364 Route Exclusions", RFC 5521, April 2009. 1366 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1367 Monitoring Tools for Path Computation Element (PCE)-Based 1368 Architecture", RFC 5886, June 2010. 1370 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1371 Computation Element Architecture to the Determination of a 1372 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 1373 2012. 1375 [PCE-P2MP-PROCEDURES] 1376 Zhao, Q., Dhody, D., Ali, Z., Saad,, T., Sivabalan,, S., 1377 and R. Casellas, "PCE-based Computation Procedure To 1378 Compute Shortest Constrained P2MP Inter-domain Traffic 1379 Engineering Label Switched Paths (draft-ietf-pce-pcep- 1380 inter-domain-p2mp-procedures)", June 2014. 1382 [PCEP-MIB] 1383 Koushik, A., Emile, S., Zhao, Q., King, D., and J. 1384 Hardwick, "PCE communication protocol(PCEP) Management 1385 Information Base", April 2014. 1387 [PCE-P2MP-PER-DEST] 1388 Dhody, D., Palle, U., and V. Kondreddy, "Supporting 1389 explicit inclusion or exclusion of abstract nodes for a 1390 subset of P2MP destinations in Path Computation Element 1391 Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp- 1392 per-destination)", March 2014. 1394 [DOMAIN-SUBOBJ] 1395 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1396 "Domain Subobjects for Resource ReserVation Protocol - 1397 Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te- 1398 domain-subobjects)", July 2014. 1400 [ISO10589] 1401 ISO, "Intermediate system to Intermediate system routing 1402 information exchange protocol for use in conjunction with 1403 the Protocol for providing the Connectionless-mode Network 1404 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1406 Appendix A. Sample Text for the IRO survey 1408 During discussion of draft-ietf-pce-pcep-domain-sequence-04, it has been 1409 noted that RFC5440 does not define whether the sub-objects in the IRO 1410 are ordered or unordered. 1412 We would like to do an informal and *confidential* survey of current 1413 implementations, to help clarify this situation. 1415 1. IRO Encoding 1417 a. Does your implementation construct IRO? 1419 b. If your answer to part (a) is Yes, does your implementation 1420 construct the IRO as an ordered list always, sometimes or never? 1422 c. If your answer to part (b) is Sometimes, what criteria do you use 1423 to decide if the IRO is an ordered or unordered list? 1425 d. If your answer to part (b) is Always or Sometimes, does your 1426 implementation construct the IRO as a sequence of strict hops 1427 or as a sequence of loose hops? 1429 2. IRO Decoding 1431 a. Does your implementation decode IRO? 1433 b. If your answer to part (a) is Yes, does your implementation 1434 interpret the decoded IRO as an ordered list always, sometimes 1435 or never? 1437 c. If your answer to part (b) is Sometimes, what criteria do you use 1438 to decide if the IRO is an ordered or unordered list? 1440 d. If your answer to part (b) is Always or Sometimes, does your 1441 implementation interpret the IRO as a sequence of strict hops 1442 or as a sequence of loose hops? 1444 3. Impact 1446 a. Will there be an impact to your implementation if RFC 5440 is 1447 updated to state that the IRO is an ordered list? 1449 b. Will there be an impact to your implementation if RFC 5440 is 1450 updated to state that the IRO is an unordered list? 1452 c. If RFC 5440 is updated to state that the IRO is an ordered list, 1453 will there be an impact to your implementation if RFC 5440 is also 1454 updated to allow IRO sub-objects to use the loose bit (L-bit)? 1456 4. Respondents 1458 a. Are you a Vendor/Research Lab/Software House/Other (please 1459 specify)? 1461 b. If your answer to part (a) is Vendor, is the implementation for a 1462 shipping product, product under development or a prototype? 1464 Authors' Addresses 1466 Dhruv Dhody 1467 Huawei Technologies 1468 Leela Palace 1469 Bangalore, Karnataka 560008 1470 INDIA 1472 EMail: dhruv.ietf@gmail.com 1474 Udayasree Palle 1475 Huawei Technologies 1476 Leela Palace 1477 Bangalore, Karnataka 560008 1478 INDIA 1480 EMail: udayasree.palle@huawei.com 1482 Ramon Casellas 1483 CTTC 1484 Av. Carl Friedrich Gauss n7 1485 Castelldefels, Barcelona 08860 1486 SPAIN 1488 EMail: ramon.casellas@cttc.es