idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-04.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 (January 7, 2014) is 3733 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: July 11, 2014 R. Casellas 6 CTTC 7 January 7, 2014 9 Standard Representation Of Domain-Sequence 10 draft-ietf-pce-pcep-domain-sequence-04 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 July 11, 2014. 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 110 1. Introduction 112 A PCE may be used to compute end-to-end paths across multi-domain 113 environments using a per-domain path computation technique [RFC5152]. 114 The so called backward recursive path computation (BRPC) mechanism 115 [RFC5441] defines a PCE-based path computation procedure to compute 116 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 117 and BRPC techniques assume that the sequence of domains to be crossed 118 from source to destination is known, either fixed by the network 119 operator or obtained by other means. Also for inter-domain point-to- 120 multi-point (P2MP) tree computation, [PCE-P2MP-PROCEDURES] assumes 121 the domain-tree is known in priori. 123 The list of domains (domain-sequence) in a point-to-point (P2P) path 124 or a point-to-multi-point (P2MP) tree is usually a constraint in the 125 path computation request. The PCE determines the next PCE to forward 126 the request based on the domain-sequence. In a multi-domain path 127 computation, a PCC MAY indicate the sequence of domains to be 128 traversed using the Include Route Object (IRO) defined in [RFC5440]. 130 When the sequence of domains is not known in advance, the 131 Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be 132 used to determine the end-to-end Domain-Sequence. 134 This document defines a standard way to represent and encode a 135 Domain-Sequence in various deployment scenarios including P2P, P2MP 136 and H-PCE. 138 The Domain-Sequence (the set of domains traversed to reach the 139 destination domain) is either administratively predetermined or 140 discovered by some means (H-PCE) that is outside of the scope of this 141 document. 143 [RFC5440] defines the Include Route Object (IRO) and the Explicit 144 Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO) 145 and the Explicit Exclusion Route Subobject (EXRS); The use of 146 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 147 abstract node representing domain is defined in [RFC3209], this 148 document specifies new subobjects to include or exclude domains such 149 as an IGP area or an Autonomous Systems (4-Byte as per [RFC4893]). 151 Further, the domain identifier may simply act as delimiter to specify 152 where the domain boundary starts and ends. 154 This is a companion document to Resource ReserVation Protocol - 155 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 156 [DOMAIN-SUBOBJ]. 158 1.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2. Terminology 166 The following terminology is used in this document. 168 ABR: OSPF Area Border Router. Routers used to connect two IGP 169 areas. 171 AS: Autonomous System. 173 ASBR: Autonomous System Boundary Router. 175 BN: Boundary Node, Can be an ABR or ASBR. 177 BRPC: Backward Recursive Path Computation 179 Domain: As per [RFC4655], any collection of network elements within 180 a common sphere of address management or path computational 181 responsibility. Examples of domains include Interior Gateway 182 Protocol (IGP) areas and Autonomous Systems (ASs). 184 Domain-Sequence: An ordered sequence of domains traversed to reach 185 the destination domain. 187 ERO: Explicit Route Object 189 H-PCE: Hierarchical PCE 190 IGP: Interior Gateway Protocol. Either of the two routing 191 protocols, Open Shortest Path First (OSPF) or Intermediate System 192 to Intermediate System (IS-IS). 194 IRO: Include Route Object 196 IS-IS: Intermediate System to Intermediate System. 198 OSPF: Open Shortest Path First. 200 PCC: Path Computation Client: any client application requesting a 201 path computation to be performed by a Path Computation Element. 203 PCE: Path Computation Element. An entity (component, application, 204 or network node) that is capable of computing a network path or 205 route based on a network graph and applying computational 206 constraints. 208 P2MP: Point-to-Multipoint 210 P2P: Point-to-Point 212 RSVP: Resource Reservation Protocol 214 TE LSP: Traffic Engineering Label Switched Path. 216 3. Detail Description 218 3.1. Domains 220 [RFC4726] and [RFC4655] define domain as a separate administrative or 221 geographic environment within the network. A domain may be further 222 defined as a zone of routing or computational ability. Under these 223 definitions a domain might be categorized as an AS or an IGP area. 224 Each AS can be made of several IGP areas. In order to encode a 225 Domain-Sequence, it is required to uniquely identify a domain in the 226 Domain-Sequence. A domain can be uniquely identified by area-id or 227 AS or both. 229 3.2. Domain-Sequence 231 A domain-sequence is an ordered sequence of domains traversed to 232 reach the destination domain. 234 A domain-sequence can be applied as a constraint and carried in path 235 computation request to PCE(s). A domain-sequence can also be the 236 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 [RFC5440] in its description of IRO does not require the subobjects 419 to be in a given particular order. When considering a Domain- 420 Sequence, the domain relative ordering is a basic criterion and, as 421 such, this option suggest a new IRO object type. 423 IRO Object-Class is 10. 424 IRO Object-Type is TBD. (2 suggested value to IANA) 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 // (Subobjects) // 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Subobjects: The IRO is made of subobjects identical to the ones 435 defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO 436 subobject type is identical to the subobject type defined in the 437 related documents. Some new subobjects related to Domain-Sequence 438 are also added in this document as mentioned in Section 3.4. 440 [RFC3209] defines subobjects for IPv4, IPv6 and unnumbered Interface 441 ID, which in the context of domain-sequence is used to specify 442 Boundary Node (ABR/ASBR) and Inter-AS-Links. The subobjects for AS 443 Number (2 or 4 Byte) and IGP Area is used to specify the domain 444 identifiers in the domain-sequence. 446 The new IRO Object-Type used to define the domain-sequence would 447 handle the L bit (Loose / Strict) in the subobjects similar to 448 [RFC3209]. 450 Further we have following options: 452 * Option (A.1): New IRO Object Type for Domain-Sequence object only. 453 A new IRO Object Type is used to specify the ordered sequence of 454 domains (Domain-Sequence) only. The PCReq message is modified to 455 allow encoding of both types of IRO; one with IRO Type 1 [RFC5440] 456 used to specify the intra-domain abstract nodes and resources and 457 the second IRO Type with the new subobjects as described in this 458 section to specify the domain-sequence. All other rules of PCEP 459 objects and message processing (ex. P bit handling of Common 460 Object Header) is as per [RFC5440]. 462 * Option (A.2): New IRO Object Type for both intra and inter-domain 463 (domain-sequence). A new IRO Object Type is used to include both 464 intra nodes and inter-domains nodes but the sequence of domain is 465 strict. The intra-domain nodes can still be ordered. In case of 466 inter-domain path computation, only the new IRO type is used which 467 contains the specific intra domain network nodes as well as inter- 468 domain abstract nodes or domains. The inter-domain abstract nodes 469 are encoded in the sequence they must be traversed but the intra- 470 domain elements MAY be an unordered set. There is no need to 471 change the PCReq message format. 473 3.4.2.1. Handling of the Domain-Sequence IRO object 475 An IRO object containing Domain-Sequence subobjects constraints or 476 defines the domains involved in a multi-domain path computation, 477 typically involving two or more collaborative PCEs. 479 A Domain-Sequence can have varying degrees of granularity; it is 480 possible to have a Domain-Sequence composed of, uniquely, AS 481 identifiers. It is also possible to list the involved areas for a 482 given AS. 484 In any case, the mapping between domains and responsible PCEs is not 485 defined in this document. It is assumed that a PCE that needs to 486 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 487 administrative configuration, or discovery). 489 A PCC builds a Domain-Sequence IRO to encode the Domain-Sequence, 490 that is all domains that it wishes the cooperating PCEs to traverse 491 in order to compute the end to end path. 493 For each inclusion, the PCC clears the L-bit to indicate that the PCE 494 is required to include the domain, or sets the L-bit to indicate that 495 the PCC simply desires that the domain be included in the domain- 496 sequence. 498 When a PCE receives a PCEP Request message with an IRO, it looks for 499 a Domain-Sequence IRO (new type) to see if a domain-sequence is 500 specified. If the message contains more than one Domain-Sequence IRO 501 (new type), it MUST use the first one in the message and MUST ignore 502 subsequent instances. 504 If a PCE does not recognize the Domain-Sequence IRO (new type), it 505 MUST return a PCErr message with Error-Type "Unknown Object" and 506 Error-value "Unrecognized object Type" as described in [RFC5440]. 508 If a PCE is unwilling or unable to process the Domain-Sequence IRO 509 (new type), it MUST return a PCErr message with the Error-Type "Not 510 supported object" and follow the relevant procedures described in 511 [RFC5440]. 513 If a PCE that supports the Domain-Sequence IRO (new type) and 514 encounters a subobject that it does not support or recognize, it MUST 515 act according to the setting of the L-bit in the subobject. If the 516 L-bit is clear, the PCE MUST respond with a PCErr with Error-Type 517 "Unrecognized subobject" and set the Error-Value to the subobject 518 type code. If the L-bit is set, the PCE MAY respond with a PCErr as 519 already stated or MAY ignore the subobject: this choice is a local 520 policy decision. 522 If a PCE parses a Domain-Sequence IRO (new type), it MUST act 523 according to the requirements expressed in the subobject. That is, 524 if the L-bit is clear, the PCE(s) MUST produce a path that follows 525 domain-sequence nodes in order identified by the subobjects in the 526 path. If the L-bit is set, the PCE(s) SHOULD produce a path along 527 the Domain-Sequence unless it is not possible to construct a path 528 complying with the other constraints expressed in the request. 530 A successful path computation reported in a PCEP response message 531 MUST include an ERO to specify the path that has been computed as 532 specified in [RFC5440] following the sequence of domains. 534 In a PCEP response message, PCE MAY also supply a Domain-Sequence IRO 535 (new type) with the NO-PATH object indicating that the set of 536 elements of the request's Domain-Sequence IRO prevented the PCE from 537 finding a path. 539 Subobject types for AS and IGP Area affect the next domain selection 540 as well as finding the PCE serving that domain. 542 Note that a particular domain in the domain-sequence can be 543 identified by :- 545 o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is 546 used to identify the next domain. (Refer Figure 1) 548 o A single AS: Only the AS subobject is used to identify the next 549 domain. (Refer Figure 2) 551 o Both an AS and an IGP Area: Combination of both AS and Area are 552 used to identify the next domain. In this case the order is AS 553 Subobject followed by Area. (Refer Figure 3) 555 Subobject representing Boundary Node or Inter-AS-Link MUST be applied 556 during the final path computation procedure as before. 558 3.4.3. Option B: Existing IRO Object Type 560 The IRO (Include Route Object) [RFC5440] is an optional object used 561 to specify a set of network elements that the computed path MUST 562 traverse. 564 The new subobjects denoting the domain-sequence are carried in the 565 same IRO Type 1, and all the rules of processing as specified in 566 [RFC5440] are applied. 568 Note the following differences :- 570 o Order: Since there is no inherent order specified in the encoding 571 of the subobjects in IRO Type 1 [RFC5440], it is the job of the 572 PCE to figure out the optimal order of the domains to be crossed 573 to reach the destination domain. Note that in case of doubt, or 574 when applicable, the PCE can still apply the ordering as specified 575 in the request message. Further PCE may have to crankback and try 576 multiple permutations before figuring out the correct sequence. 578 o Loose / Strict (L-Bit): [RFC5440] state that the L bit of the 579 subobjects within an IRO Type 1 [RFC5440] has no meaning. This 580 will be applicable for subobjects denoting domain-sequence as 581 well. 583 o Scope: Coexistence of intra-domain nodes, boundary nodes and 584 domain nodes in the same IRO List. It is the job of PCE to figure 585 out the scope and apply the processing rules accordingly. The 586 nodes in the IRO which are recognized by the PCE are handled 587 locally and others are forwarded to next PCE hoping they would 588 handle them, the aggregating PCE (Ingress PCE or Parent) would 589 make sure that all nodes in IRO are handled correctly. 591 3.4.4. Comparison 593 +-------------+-------------------+-------------------+-------------------+ 594 | |Option (A.1): New |Option (A.2): New |Option B: Existing | 595 | |IRO Object Type for|IRO Object Type for|IRO Object Type | 596 | |Domain-Sequence |both intra and | | 597 | |object only |inter-domain | | 598 +-------------+-------------------+-------------------+-------------------+ 599 |Order |Yes |Yes |No | 600 +-------------+-------------------+-------------------+-------------------+ 601 |L/X bit |Yes |Yes |No | 602 +-------------+-------------------+-------------------+-------------------+ 603 |Msg Format |No |Yes |Yes | 604 |Unchanged | | | | 605 +-------------+-------------------+-------------------+-------------------+ 606 |Seperation |Yes |Yes* |No | 607 |of scope | | | | 608 +-------------+-------------------+-------------------+-------------------+ 610 * becasue of the ordered nature, intra-domain nodes would be first in the 611 new IRO type 613 [Editor's Note: Based on our opinion and the feedback received so 614 far, we feel the option A.2 should be selected.] 616 3.5. Exclude Route Object (XRO) 618 The Exclude Route Object (XRO) [RFC5521] is an optional object used 619 to specify exclusion of certain abstract nodes or resources from the 620 whole path. 622 3.5.1. Subobjects 624 The following subobject types are defined to be used in XRO as 625 defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. 627 Type Subobject 628 1 IPv4 prefix 629 2 IPv6 prefix 630 4 Unnumbered Interface ID 631 32 Autonomous system number (2 Byte) 632 34 SRLG 633 64 IPv4 Path Key 634 65 IPv6 Path Key 636 This document extends the above list to support 4-Byte AS numbers and 637 IGP Areas. 639 Type Subobject 640 TBD Autonomous system number (4 Byte) 641 TBD OSPF Area id 642 TBD ISIS Area id 644 3.5.1.1. Autonomous system 646 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 647 MAY also be used in the XRO to specify exclusion of certain domains 648 in the path computation procedure. 650 0 1 2 3 651 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |X| Type | Length | Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | AS-ID (4 bytes) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 The X-bit indicates whether the exclusion is mandatory or desired. 660 0: indicates that the AS specified MUST be excluded from the path 661 computed by the PCE(s). 663 1: indicates that the AS specified SHOULD be avoided from the inter- 664 domain path computed by the PCE(s), but MAY be included subject to 665 PCE policy and the absence of a viable path that meets the other 666 constraints. 668 All other fields are consistent with the definition in Section 3.4. 670 3.5.1.2. IGP Area 672 Since the length and format of Area-id is different for OSPF and 673 ISIS, following two subobjects are defined: 675 For OSPF, the area-id is a 32 bit number. The subobject is encoded 676 as follows: 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 |X| Type | Length | Reserved | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | OSPF Area Id (4 bytes) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 The X-bit indicates whether the exclusion is mandatory or desired. 688 0: indicates that the OSFF Area specified MUST be excluded from the 689 path computed by the PCE(s). 691 1: indicates that the OSFF Area specified SHOULD be avoided from the 692 inter-domain path computed by the PCE(s), but MAY be included 693 subject to PCE policy and the absence of a viable path that meets 694 the other constraints. 696 All other fields are consistent with the definition in Section 3.4. 698 For IS-IS, the area-id is of variable length and thus the length of 699 the subobject is variable. The Area-id is as described in IS-IS by 700 ISO standard [ISO10589]. The subobject is encoded as follows: 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |X| Type | Length | Area-Len | Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 // IS-IS Area ID // 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 The X-bit indicates whether the exclusion is mandatory or desired. 714 0: indicates that the ISIS Area specified MUST be excluded from the 715 path computed by the PCE(s). 717 1: indicates that the ISIS Area specified SHOULD be avoided from the 718 inter-domain path computed by the PCE(s), but MAY be included 719 subject to PCE policy and the absence of a viable path that meets 720 the other constraints. 722 All other fields are consistent with the definition in Section 3.4. 724 If a PCE that supports XRO and encounters a subobject that it does 725 not support or recognize, it MUST act according to the setting of the 726 X-bit in the subobject. If the X-bit is clear, the PCE MUST respond 727 with a PCErr with Error-Type "Unrecognized subobject" and set the 728 Error-Value to the subobject type code. If the X-bit is set, the PCE 729 MAY respond with a PCErr as already stated or MAY ignore the 730 subobject: this choice is a local policy decision. 732 All the other processing rules are as per [RFC5521]. 734 3.6. Explicit Exclusion Route Subobject (EXRS) 736 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 737 specify exclusion of certain abstract nodes between a specific pair 738 of nodes. 740 The EXRS subobject may carry any of the subobjects defined for 741 inclusion in the XRO, thus the new subobjects to support 4 byte AS 742 and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The 743 meanings of the fields of the new XRO subobjects are unchanged when 744 the subobjects are included in an EXRS, except that scope of the 745 exclusion is limited to the single hop between the previous and 746 subsequent elements in the IRO. 748 All the processing rules are as per [RFC5521]. 750 3.7. Explicit Route Object (ERO) 752 The Explicit Route Object (ERO) [RFC5440] is used to specify a 753 computed path in the network. PCEP ERO subobject types correspond to 754 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 755 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. 757 Type Subobject 758 1 IPv4 prefix 759 2 IPv6 prefix 760 3 Label 761 4 Unnumbered Interface ID 762 32 Autonomous system number (2 Byte) 763 33 Explicit Exclusion (EXRS) 764 37 Protection 765 64 IPv4 Path Key 766 65 IPv6 Path Key 768 This document extends the above list to support 4-Byte AS numbers and 769 IGP Areas. 771 Type Subobject 772 TBD Autonomous system number (4 Byte) 773 TBD OSPF Area id 774 TBD ISIS Area id 776 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 777 MAY also be used in the ERO to specify an abstract node (a group of 778 nodes whose internal topology is opaque to the ingress node of the 779 LSP). Using this concept of abstraction, an explicitly routed LSP 780 can be specified as a sequence of domains. 782 In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested 783 to find the domain-sequence. Refer example in Section 4.6. 785 The format of the new ERO subobjects is similar to new IRO 786 subobjects, refer Section 3.4. 788 4. Other Considerations 790 The examples in this section are for illustration purposes only; to 791 show how the new subobjects may be encoded. 793 4.1. Inter-Area Path Computation 795 In an inter-area path computation where the ingress and the egress 796 nodes belong to different IGP areas within the same AS, the Domain- 797 Sequence MAY be represented using a ordered list of Area subobjects. 798 The AS number MAY be skipped, as area information is enough to select 799 the next PCE. 801 +-------------------+ +-------------------+ 802 | | | | 803 | +--+ | | +--+ | 804 | +--+ | | | | | | | 805 | | | +--+ | | +--+ +--+ | 806 | +--* + + | | | 807 | | | +--+ | 808 | *--+ + + | 809 | | | | | +--+ | 810 | +--+ | | | | | 811 | |+--------------------------+| +--+ | 812 | ++++ +-++ | 813 | |||| +--+ | || | 814 | Area 2 ++++ | | +-++ Area 4 | 815 +-------------------+| +--+ |+-------------------+ 816 | | 817 | +--+ | 818 | +--+ | | | 819 | | | +--+ | 820 | +--+ | 821 | | 822 | | 823 | | 824 | | 825 | +--+ | 826 | | | | 827 | +--+ | 828 +------------------+| |+--------------------+ 829 | ++-+ +-++ | 830 | || | | || | 831 | ++-+ Area 0 +-++ | 832 | |+--------------------------+| +--+ | 833 | +--+ | | | | | 834 | | | | | +--+ | 835 | +--+ +--+ | | | 836 | | | + + +--+ | 837 | +--+ | | | | | 838 | + + +--+ | 839 | +--+ | | | 840 | | | | | +--+ | 841 | +--+ | | | | | 842 | | | +--+ | 843 | | | | 844 | Area 1 | | Area 5 | 845 +------------------+ +--------------------+ 847 Figure 1: Inter-Area Path Computation 849 AS Number is 100. 851 This could be represented in the as: 853 +---------+ +---------+ +---------+ +---------+ 854 |IRO | |Sub | |Sub | |Sub | 855 |Object | |Object | |Object | |Object | 856 |Header | |Area 2 | |Area 0 | |Area 4 | 857 | | | | | | | | 858 | | | | | | | | 859 +---------+ +---------+ +---------+ +---------+ 861 +---------+ +---------+ +---------+ +---------+ +---------+ 862 |IRO | |Sub | |Sub | |Sub | |Sub | 863 |Object | |Object AS| |Object | |Object | |Object | 864 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 865 | | | | | | | | | | 866 | | | | | | | | | | 867 +---------+ +---------+ +---------+ +---------+ +---------+ 869 AS is optional and it MAY be skipped. PCE should be able to 870 understand both notations. 872 4.2. Inter-AS Path Computation 874 In inter-AS path computation, where ingress and egress belong to 875 different AS, the Domain-Sequence is represented using an ordered 876 list of AS subobjects. The Domain-Sequence MAY further include 877 decomposed area information in Area subobjects. 879 4.2.1. Example 1 881 As shown in Figure 2, where AS to be made of a single area, the area 882 subobject MAY be skipped in the Domain-Sequence as AS is enough to 883 uniquely identify the next domain and PCE. 885 +---------------------------------+ 886 |AS 200 | 887 | +------+ | 888 | | | | 889 +------------------------+ | | | +------+ | 890 | AS 100 | | +------+ | | | 891 | +------+ | | +------+ | | | 892 | | +-+-----+-+ | +------+ | 893 | | | | | | | | 894 | +------+ | | +------+ | 895 | +------+ | | +------+ | 896 | | | | | | | | 897 | | | | | | | | 898 | +------+ | | +------+ | 899 | | | | 900 | +------+ | | +------+ | 901 | | +-+-----+-+ | +------+ | 902 | | | | | | | | | | 903 | +------+ | | +------+ | | | 904 | | | +------+ | 905 | | | | 906 | | | | 907 | +------+ | | +------+ | 908 | | | | | | | | 909 | |PCE | | | |PCE | | 910 | +------+ | | +------+ | 911 | | | | 912 +------------------------+ | | 913 +---------------------------------+ 915 Figure 2: Inter-AS Path Computation 917 Both AS are made of Area 0. 919 This could be represented in the as: 921 +---------+ +---------+ +---------+ 922 |IRO | |Sub | |Sub | 923 |Object | |Object AS| |Object AS| 924 |Header | |100 | |200 | 925 | | | | | | 926 | | | | | | 927 +---------+ +---------+ +---------+ 929 +---------+ +---------+ +---------+ +---------+ +---------+ 930 |IRO | |Sub | |Sub | |Sub | |Sub | 931 |Object | |Object AS| |Object | |Object AS| |Object | 932 |Header | |100 | |Area 0 | |200 | |Area 0 | 933 | | | | | | | | | | 934 | | | | | | | | | | 935 +---------+ +---------+ +---------+ +---------+ +---------+ 937 Area subobject is optional and it MAY be skipped. PCE should be able 938 to understand both notations. 940 4.2.2. Example 2 942 As shown in Figure 3, where AS 200 is made up of multiple areas and 943 multiple domain-sequence exist, PCE MAY include both AS and Area 944 subobject to uniquely identify the next domain and PCE. 946 | 947 | +-------------+ +----------------+ 948 | |Area 2 | |Area 4 | 949 | | +--+| | +--+ | 950 | | | || | | | | 951 | | +--+ +--+| | +--+ +--+ | 952 | | | | | | | | | 953 | | *--+ | | +--+ | 954 | | / +--+ | | +--+ | 955 | |/ | | | | | | | 956 | / +--+ | | +--+ +--+ | 957 | /| +--+ |+--------------+| | | | 958 |/ | | | ++-+ +-++ +--+ | 959 +-------------+/ | +--+ || | | || | 960 | /| | ++-+ +-++ | 961 | +--*|| +-------------+| |+----------------+ 962 | | ||| | +--+ | 963 | +--+|| | | | | 964 | +--+ || | +--+ | 965 | | | || | | 966 | +--+ || | | 967 | || | +--+ | 968 |+--+ || | | | | 969 || | || | +--+ | 970 |+--+ || | | 971 | || | +--+ | 972 | +--+ || +------------+ | | | |+----------------+ 973 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 974 | +--+ || | | || | || | 975 | || | +-++ +-++ | 976 | +--+|| | +--+ | | Area 0 || +--+ | 977 | | ||| | | | | +--------------+| | | | 978 | +--*|| | +--+ | | +--+ | 979 | \| | | | +--+ | 980 |Area 1 |\ | +--+ | | +--+ | | | 981 +-------------+|\ | | | | | | | +--+ | 982 | \| +--+ +--+ | +--+ | 983 | \ | | | | 984 | |\ +--+ | +--+ | 985 | | \ +--+ | | | | | 986 | | \| | | | +--+ | 987 | | *--+ | | | 988 | | | | | 989 | +------------+ +----------------+ 990 | 991 | 992 AS 100 | AS 200 993 | 995 Figure 3: Inter-AS Path Computation 997 The Domain-Sequence can be carried in the IRO as shown below: 999 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1000 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 1001 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 1002 |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 1003 | | | | | | | | | | | | | | 1004 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1006 The combination of both an AS and an Area uniquely identify a domain 1007 in the Domain-Sequence. 1009 Note that an Area domain identifier always belongs to the previous AS 1010 that appears before it or, if no AS subobjects are present, it is 1011 assumed to be the current AS. 1013 If the area information cannot be provided, PCE MAY forward the path 1014 computation request to the next PCE based on AS alone. If multiple 1015 PCEs are responsible, PCE MAY apply local policy to select the next 1016 PCE. 1018 4.3. Boundary Node and Inter-AS-Link 1020 A PCC or PCE MAY add additional constraints covering which Boundary 1021 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 1022 while defining a Domain-Sequence. In which case the Boundary Node or 1023 Link MAY be encoded as a part of the domain-sequence using the 1024 existing subobjects. 1026 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 1027 prefix subobjects usually the loopback address of 32 and 128 prefix 1028 length respectively. An Inter-AS link can be encoded using the IPv4 1029 or IPv6 prefix subobjects or unnumbered interface subobjects. 1031 For Figure 1, an ABR to be traversed can be specified as: 1033 +---------+ +---------+ +---------++---------+ +---------+ 1034 |IRO | |Sub | |Sub ||Sub | |Sub | 1035 |Object | |Object | |Object ||Object | |Object | 1036 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 1037 | | | | |x.x.x.x || | | | 1038 | | | | | || | | | 1039 +---------+ +---------+ +---------++---------+ +---------+ 1041 For Figure 2, an inter-AS-link to be traversed can be specified as: 1043 +---------+ +---------+ +---------+ +---------+ +---------+ 1044 |IRO | |Sub | |Sub | |Sub | |Sub | 1045 |Object | |Object AS| |Object | |Object | |Object AS| 1046 |Header | |100 | |IPv4 | |IPv4 | |200 | 1047 | | | | |x.x.x.x | |x.x.x.x | | | 1048 | | | | | | | | | | 1049 +---------+ +---------+ +---------+ +---------+ +---------+ 1051 4.4. PCE Serving multiple Domains 1053 A single PCE MAY be responsible for multiple domains; for example PCE 1054 function deployed on an ABR. A PCE which can support 2 adjacent 1055 domains can internally handle this situation without any impact on 1056 the neighboring domains. 1058 4.5. P2MP 1060 In case of inter-domain P2MP path computation, (Refer 1061 [PCE-P2MP-PROCEDURES]) the path domain tree is nothing but a series 1062 of Domain Sequences, as shown in the below figure: 1064 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 1065 D1 1066 / \ 1067 D2 D3 1068 / / \ 1069 D4 D5 D6 1071 All rules of processing as applied to P2P can be applied to P2MP as 1072 well. 1074 In case of P2MP, different destinations MAY have different Domain- 1075 Sequence within the domain tree, it requires domain-sequence to be 1076 attached per destination. (Refer [PCE-P2MP-PER-DEST]) 1078 4.6. Hierarchical PCE 1080 As per [RFC6805], consider a case as shown in Figure 4 consisting of 1081 multiple child PCEs and a parent PCE. 1083 +--------+ 1084 | Parent | 1085 | PCE | 1086 +--------+ 1088 +-------------------+ +-------------------+ 1089 | +--+ | | +--+ | 1090 | +--+ | | | | | | | 1091 | | | +--+ | | +--+ +--+ | 1092 | +--* + + | | | 1093 | | | +--+ | 1094 | *--+ + + | 1095 | | | | | +--+ | 1096 | +--+ | | | | | 1097 | |+--------------------------+| +--+ | 1098 | ++++ +-++ | 1099 | |||| +--+ | || | 1100 | Area 2 ++++ | | +-++ Area 4 | 1101 +-------------------+| +--+ |+-------------------+ 1102 | +--+ | 1103 | +--+ | | | 1104 | | | +--+ | 1105 | +--+ | 1106 | | 1107 | +--+ | 1108 | | | | 1109 | +--+ | 1110 +------------------+| |+--------------------+ 1111 | ++-+ +-++ | 1112 | || | | || | 1113 | ++-+ Area 0 +-++ | 1114 | |+--------------------------+| +--+ | 1115 | +--+ | | | | | 1116 | | | | | +--+ | 1117 | +--+ +--+ | | | 1118 | | | + + +--+ | 1119 | +--+ | | | | | 1120 | + + +--+ | 1121 | +--+ | | | 1122 | | | | | +--+ | 1123 | +--+ | | | | | 1124 | | | +--+ | 1125 | Area 1 | | Area 5 | 1126 +------------------+ +--------------------+ 1128 Figure 4: Hierarchical PCE 1130 In H-PCE, the Ingress PCE PCE(1) can request the parent PCE to 1131 determine the Domain-Sequence and return it in the PCEP response, 1132 using the ERO Object. The ERO can contain an ordered sequence of 1133 subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, 1134 the Domain-Sequence appear as: 1136 +---------+ +---------+ +---------+ +---------+ 1137 |ERO | |Sub | |Sub | |Sub | 1138 |Object | |Object | |Object | |Object | 1139 |Header | |Area 2 | |Area 0 | |Area 4 | 1140 | | | | | | | | 1141 | | | | | | | | 1142 +---------+ +---------+ +---------+ +---------+ 1144 +---------+ +---------+ +---------+ +---------+ +---------+ 1145 |ERO | |Sub | |Sub | |Sub | |Sub | 1146 |Object | |Object AS| |Object | |Object | |Object | 1147 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 1148 | | | | | | | | | | 1149 | | | | | | | | | | 1150 +---------+ +---------+ +---------+ +---------+ +---------+ 1152 Note that, in the case of ERO objects, no new PCEP object type is 1153 required since the ordering constraint is assumed. 1155 4.7. Relationship to PCE Sequence 1157 Instead of a domain-sequence, a sequence of PCEs MAY be enforced by 1158 policy on the PCC, and this constraint can be carried in the PCReq 1159 message (as defined in [RFC5886]). 1161 Note that PCE-Sequence can be used along with domain-sequence in 1162 which case PCE-Sequence SHOULD have higher precedence in selecting 1163 the next PCE in the inter-domain path computation procedures. Note 1164 that Domain-Sequence IRO constraints should still be checked as per 1165 the rules of processing IRO. 1167 4.8. Relationship to RSVP-TE 1169 [RFC3209] already describes the notion of abstract nodes, where an 1170 abstract node is a group of nodes whose internal topology is opaque 1171 to the ingress node of the LSP. It further defines a subobject for 1172 AS but with a 2-Byte AS Number. 1174 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1175 subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY 1176 be included in Explicit Route Object (ERO), Exclude Route object 1177 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1179 In any case subobject type defined in RSVP-TE are identical to the 1180 subobject type defined in the related documents in PCEP. 1182 5. IANA Considerations 1184 5.1. PCEP Objects 1186 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 1187 IANA is requested to make the following allocations from this 1188 registry. 1190 Object Name Reference 1191 Class 1192 10 IRO [RFC5440] 1193 Object-Type 1194 (TBA): Domain-Sequence [This I.D.] 1196 5.2. New Subobjects 1198 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1199 with an entry for the Include Route Object (IRO), Exclude Route 1200 Object (XRO) and Explicit Route Object (ERO). IANA is requested to 1201 add further subobjects as follows: 1203 7 ERO 1204 10 IRO 1205 17 XRO 1207 Subobject Type Reference 1208 TBA 4 byte AS number [This I.D.] 1209 TBA OSPF Area ID [This I.D.] 1210 TBA IS-IS Area ID [This I.D.] 1212 5.3. Error Object Field Values 1214 The "PCEP Parameters" registry contains a subregistry "Error Types 1215 and Values". IANA is requested to make the following allocations 1216 from this subregistry 1218 ERROR Meaning Reference 1219 Type 1220 TBA "Unrecognized subobject" [This I.D.] 1221 Error-Value: type code 1223 6. Security Considerations 1225 This document specifies a standard representation of Domain-Sequence 1226 and new subobjects, which MAY be used in inter-domain PCE scenarios 1227 as explained in other RFC and drafts. The new subobjects and Domain- 1228 Sequence mechanisms defined in this document allow finer and more 1229 specific control of the path computed by a cooperating PCE(s). Such 1230 control increases the risk if a PCEP message is intercepted, 1231 modified, or spoofed because it allows the attacker to exert control 1232 over the path that the PCE will compute or to make the path 1233 computation impossible. Therefore, the security techniques described 1234 in [RFC5440] are considered more important. 1236 Note, however, that the Domain-Sequence mechanisms also provide the 1237 operator with the ability to route around vulnerable parts of the 1238 network and may be used to increase overall network security. 1240 7. Manageability Considerations 1242 7.1. Control of Function and Policy 1244 Several local policy decisions should be made at the PCE. Firstly, 1245 the exact behavior with regard to desired inclusion and exclusion of 1246 domains must be available for examination by an operator and may be 1247 configurable. Second, the behavior on receipt of an unrecognized 1248 subobjects with the L or X-bit set should be configurable and must be 1249 available for inspection. The inspection and control of these local 1250 policy choices may be part of the PCEP MIB module. 1252 7.2. Information and Data Models 1254 A MIB module for management of the PCEP is being specified in a 1255 separate document [PCEP-MIB]. That MIB module allows examination of 1256 individual PCEP messages, in particular requests, responses and 1257 errors. The MIB module MUST be extended to include the ability to 1258 view the domain-sequence extensions defined in this document. 1260 7.3. Liveness Detection and Monitoring 1262 Mechanisms defined in this document do not imply any new liveness 1263 detection and monitoring requirements in addition to those already 1264 listed in [RFC5440]. 1266 7.4. Verify Correct Operations 1268 Mechanisms defined in this document do not imply any new operation 1269 verification requirements in addition to those already listed in 1270 [RFC5440]. 1272 7.5. Requirements On Other Protocols 1274 In case of per-domain path computation [RFC5152], where the full path 1275 of an inter-domain TE LSP cannot be or is not determined at the 1276 ingress node, and signaling message may use domain identifiers. The 1277 Subobjects defined in this document SHOULD be supported by RSVP-TE. 1278 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1279 subobjects for IGP Areas and 4-byte AS numbers. 1281 Apart from this, mechanisms defined in this document do not imply any 1282 requirements on other protocols in addition to those already listed 1283 in [RFC5440]. 1285 7.6. Impact On Network Operations 1287 Mechanisms defined in this document do not have any impact on network 1288 operations in addition to those already listed in [RFC5440]. 1290 8. Acknowledgments 1292 We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, 1293 Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1294 Venugopal Reddy, Reeja Paul Sandeep Boina and Avantika for their 1295 useful comments and suggestions. 1297 9. References 1299 9.1. Normative References 1301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1302 Requirement Levels", BCP 14, RFC 2119, March 1997. 1304 9.2. Informative References 1306 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1307 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1308 Tunnels", RFC 3209, December 2001. 1310 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1311 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1312 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1314 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1315 in Resource ReSerVation Protocol - Traffic Engineering 1316 (RSVP-TE)", RFC 3477, January 2003. 1318 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1319 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1321 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1322 Inter-Domain Multiprotocol Label Switching Traffic 1323 Engineering", RFC 4726, November 2006. 1325 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1326 "GMPLS Segment Recovery", RFC 4873, May 2007. 1328 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1329 Extension to Resource ReserVation Protocol-Traffic 1330 Engineering (RSVP-TE)", RFC 4874, April 2007. 1332 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1333 Number Space", RFC 4893, May 2007. 1335 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1336 Path Computation Method for Establishing Inter-Domain 1337 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1338 5152, February 2008. 1340 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1341 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1342 2009. 1344 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1345 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1346 to Compute Shortest Constrained Inter-Domain Traffic 1347 Engineering Label Switched Paths", RFC 5441, April 2009. 1349 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1350 Topology Confidentiality in Inter-Domain Path Computation 1351 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1353 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1354 Path Computation Element Communication Protocol (PCEP) for 1355 Route Exclusions", RFC 5521, April 2009. 1357 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1358 Monitoring Tools for Path Computation Element (PCE)-Based 1359 Architecture", RFC 5886, June 2010. 1361 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1362 Computation Element Architecture to the Determination of a 1363 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 1364 2012. 1366 [PCE-P2MP-PROCEDURES] 1367 Zhao, Q., Dhody, D., Ali, Z., Saad,, T., Sivabalan,, S., 1368 and R. Casellas, "PCE-based Computation Procedure To 1369 Compute Shortest Constrained P2MP Inter-domain Traffic 1370 Engineering Label Switched Paths (draft-ietf-pce-pcep- 1371 inter-domain-p2mp-procedures)", July 2013. 1373 [PCEP-MIB] 1374 Koushik, A., Emile, S., Zhao, Q., King, D., and J. 1375 Hardwick, "PCE communication protocol(PCEP) Management 1376 Information Base", July 2013. 1378 [PCE-P2MP-PER-DEST] 1379 Dhody, D., Palle, U., and V. Kondreddy, "Supporting 1380 explicit inclusion or exclusion of abstract nodes for a 1381 subset of P2MP destinations in Path Computation Element 1382 Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp- 1383 per-destination)", October 2013. 1385 [DOMAIN-SUBOBJ] 1386 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1387 "Domain Subobjects for Resource ReserVation Protocol - 1388 Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te- 1389 domain-subobjects)", January 2014. 1391 [ISO10589] 1392 ISO, "Intermediate system to Intermediate system routing 1393 information exchange protocol for use in conjunction with 1394 the Protocol for providing the Connectionless-mode Network 1395 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1397 Authors' Addresses 1399 Dhruv Dhody 1400 Huawei Technologies 1401 Leela Palace 1402 Bangalore, Karnataka 560008 1403 INDIA 1405 EMail: dhruv.ietf@gmail.com 1406 Udayasree Palle 1407 Huawei Technologies 1408 Leela Palace 1409 Bangalore, Karnataka 560008 1410 INDIA 1412 EMail: udayasree.palle@huawei.com 1414 Ramon Casellas 1415 CTTC 1416 Av. Carl Friedrich Gauss n7 1417 Castelldefels, Barcelona 08860 1418 SPAIN 1420 EMail: ramon.casellas@cttc.es