idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2015) is 3140 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-pce-iro-update-02 == Outdated reference: A later version (-05) exists of draft-ietf-teas-rsvp-te-domain-subobjects-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: March 23, 2016 R. Casellas 6 CTTC 7 September 20, 2015 9 Standard Representation of Domain-Sequence 10 draft-ietf-pce-pcep-domain-sequence-09 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 System (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 constrained 25 shortest 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 March 23, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 71 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 72 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 73 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 74 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9 75 3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 76 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 77 3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11 78 3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11 79 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 80 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 81 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13 82 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 83 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15 84 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 15 85 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16 87 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18 88 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 89 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 90 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23 91 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 92 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 24 95 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 96 5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 25 97 5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 25 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 26 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 8. Manageability Considerations . . . . . . . . . . . . . . . . 26 102 8.1. Control of Function and Policy . . . . . . . . . . . . . 26 103 8.2. Information and Data Models . . . . . . . . . . . . . . . 27 104 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 105 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 106 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 107 8.6. Impact On Network Operations . . . . . . . . . . . . . . 27 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 111 10.2. Informative References . . . . . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 114 1. Introduction 116 A Path Computation Element (PCE) may be used to compute end-to-end 117 paths across multi-domain environments using a per-domain path 118 computation technique [RFC5152]. The backward recursive path 119 computation (BRPC) mechanism [RFC5441] also defines a PCE-based path 120 computation procedure to compute inter-domain constrained path for 121 (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume 122 that the sequence of domains to be crossed from source to destination 123 is known, either fixed by the network operator or obtained by other 124 means. Also for inter-domain point-to-multi-point (P2MP) tree 125 computation, [RFC7334] assumes the domain-tree is known in priori. 127 The list of domains (Domain-Sequence) in point-to-point (P2P) or a 128 domain tree in point-to-multipoint (P2MP) is usually a constraint in 129 inter-domain path computation procedure. 131 The Domain-Sequence (the set of domains traversed to reach the 132 destination domain) is either administratively predetermined or 133 discovered by some means like H-PCE. 135 [RFC5440] defines the Include Route Object (IRO) and the Explicit 136 Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) 137 and the Explicit Exclusion Route Subobject (EXRS). The use of 138 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 139 abstract node representing a domain is defined in [RFC3209]. In the 140 current document, we specify new subobjects to include or exclude 141 domains including IGP area or an Autonomous Systems (4-Byte as per 142 [RFC6793]). 144 Further, the domain identifier may simply act as delimiter to specify 145 where the domain boundary starts and ends in some cases. 147 This is a companion document to Resource ReserVation Protocol - 148 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 149 [DOMAIN-SUBOBJ]. 151 1.1. Scope 153 The procedures described in this document are experimental. The 154 experiment is intended to enable research for the usage of Domain- 155 Sequence at the PCEs for inter-domain paths. For this purpose this 156 document specifies new domain subobjects as well as how they 157 incorporate with existing subobjects to represent a Domain-Sequence. 159 This document does not change the procedures for handling existing 160 subobjects in PCEP. 162 The new subobjects introduced by this document will not be understood 163 by a legacy implementation. If one of the subobjects is received in 164 a PCEP object that does not understand it, it will behave as 165 described in Section 3.4.3. Therefore, it is assumed that this 166 experiment will be conducted only when both the PCE and the PCC form 167 part of the experiment. It is possible that a PCC or PCE can operate 168 with peers some of which form part of the experiment and some that do 169 not. In this case, since no capabilities exchange is used to 170 identify which nodes can use these extensions, manual configuration 171 should be used to determine which peerings form part of the 172 experiment. 174 When the result of implementation and deployment are available, this 175 document will be updated and refined, and then be moved from 176 Experimental to Standard Track. 178 1.2. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. Terminology 186 The following terminology is used in this document. 188 ABR: OSPF Area Border Router. Routers used to connect two IGP 189 areas. 191 AS: Autonomous System. 193 ASBR: Autonomous System Boundary Router. 195 BN: Boundary Node, Can be an ABR or ASBR. 197 BRPC: Backward Recursive Path Computation 199 Domain: As per [RFC4655], any collection of network elements within 200 a common sphere of address management or path computational 201 responsibility. Examples of domains include Interior Gateway 202 Protocol (IGP) area and Autonomous System (AS). 204 Domain-Sequence: An ordered sequence of domains traversed to reach 205 the destination domain. 207 ERO: Explicit Route Object 209 H-PCE: Hierarchical PCE 211 IGP: Interior Gateway Protocol. Either of the two routing 212 protocols, Open Shortest Path First (OSPF) or Intermediate System 213 to Intermediate System (IS-IS). 215 IRO: Include Route Object 217 IS-IS: Intermediate System to Intermediate System. 219 OSPF: Open Shortest Path First. 221 PCC: Path Computation Client: any client application requesting a 222 path computation to be performed by a Path Computation Element. 224 PCE: Path Computation Element. An entity (component, application, 225 or network node) that is capable of computing a network path or 226 route based on a network graph and applying computational 227 constraints. 229 P2MP: Point-to-Multipoint 231 P2P: Point-to-Point 233 RSVP: Resource Reservation Protocol 235 TE LSP: Traffic Engineering Label Switched Path. 237 XRO: Exclude Route Object 239 3. Detail Description 241 3.1. Domains 243 [RFC4726] and [RFC4655] define domain as a separate administrative or 244 geographic environment within the network. A domain could be further 245 defined as a zone of routing or computational ability. Under these 246 definitions a domain might be categorized as an AS or an IGP area. 247 Each AS can be made of several IGP areas. In order to encode a 248 Domain-Sequence, it is required to uniquely identify a domain in the 249 Domain-Sequence. A domain can be uniquely identified by area-id or 250 AS number or both. 252 3.2. Domain-Sequence 254 A Domain-Sequence is an ordered sequence of domains traversed to 255 reach the destination domain. 257 A Domain-Sequence can be applied as a constraint and carried in a 258 path computation request to PCE(s). A Domain-Sequence can also be 259 the result of a path computation. For example, in the case of 260 Hierarchical PCE (H-PCE) [RFC6805], Parent PCE could send the Domain- 261 Sequence as a result in a path computation reply. 263 In a P2P path, the domains listed appear in the order that they are 264 crossed. In a P2MP path, the domain tree is represented as a list of 265 Domain-Sequences. 267 A Domain-Sequence enables a PCE to select the next domain and the PCE 268 serving that domain to forward the path computation request based on 269 the domain information. 271 Domain-Sequence can include Boundary Nodes (ABR or ASBR) or Border 272 links (Inter-AS-links) to be traversed as an additional constraint. 274 Thus a Domain-Sequence can be made up of one or more of - 276 o AS Number 278 o Area ID 280 o Boundary Node ID 282 o Inter-AS-Link Address 284 These are encoded in the new subobjects defined in this document as 285 well as the existing subobjects to represent a Domain-Sequence. 287 Consequently, a Domain-Sequence can be used: 289 1. by a PCE in order to discover or select the next PCE in a 290 collaborative path computation, such as in BRPC [RFC5441]; 292 2. by the Parent PCE to return the Domain-Sequence when unknown; 293 this can then be an input to the BRPC procedure [RFC6805]; 295 3. by a Path Computation Client (PCC) or a PCE, to constrain the 296 domains used in inter-domain path computation, explicitly 297 specifying which domains to be expanded or excluded; 299 4. by a PCE in the per-domain path computation model [RFC5152] to 300 identify the next domain. 302 3.3. Domain-Sequence Representation 304 Domain-Sequence appears in PCEP messages, notably in - 306 o Include Route Object (IRO): As per [RFC5440], IRO can be used to 307 specify a set of network elements to be traversed to reach the 308 destination, which includes subobjects used to specify the Domain- 309 Sequence. 311 o Exclude Route Object (XRO): As per [RFC5521], XRO can be used to 312 specify certain abstract nodes, to be excluded from whole path, 313 which includes subobjects used to specify the Domain-Sequence. 315 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], EXRS 316 can be used to specify exclusion of certain abstract nodes 317 (including domains) between a specific pair of nodes. EXRS are a 318 subobject inside the IRO. 320 o Explicit Route Object (ERO): As per [RFC5440], ERO can be used to 321 specify a computed path in the network. For example, in the case 322 of H-PCE [RFC6805], a Parent PCE can send the Domain-Sequence as a 323 result, in a path computation reply using ERO. 325 3.4. Include Route Object (IRO) 327 As per [RFC5440], IRO (Include Route Object) can be used to specify 328 that the computed path needs to traverse a set of specified network 329 elements or abstract nodes. 331 3.4.1. Subobjects 333 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 334 [RFC4874], but new subobjects related to Domain-Sequence are needed. 336 This document extends the support for 4-Byte AS numbers and IGP 337 Areas. 339 Type Subobject 340 TBD1 Autonomous system number (4 Byte) 341 TBD2 OSPF Area id 342 TBD3 ISIS Area id 344 Note: The twins of these subobjects are carried in RSVP-TE messages 345 as defined in [DOMAIN-SUBOBJ]. 347 3.4.1.1. Autonomous system 349 [RFC3209] already defines 2 byte AS number. 351 To support 4 byte AS number as per [RFC6793] following subobject is 352 defined: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |L| Type | Length | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | AS-ID (4 bytes) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 L: The L bit is an attribute of the subobject as defined in [RFC3209] 363 and usage in IRO subobject updated in [IRO-UPDATE]. 365 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 367 Length: 8 (Total length of the subobject in bytes). 369 Reserved: Zero at transmission, ignored at receipt. 371 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 372 use, the low order bits (16 through 31) MUST be used and the high 373 order bits (0 through 15) MUST be set to zero. 375 3.4.1.2. IGP Area 377 Since the length and format of Area-id is different for OSPF and 378 ISIS, following two subobjects are defined: 380 For OSPF, the area-id is a 32 bit number. The subobject is encoded 381 as follows: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |L| Type | Length | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | OSPF Area Id (4 bytes) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 L: The L bit is an attribute of the subobject as defined in [RFC3209] 392 and usage in IRO subobject updated in [IRO-UPDATE]. 394 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 396 Length: 8 (Total length of the subobject in bytes). 398 Reserved: Zero at transmission, ignored at receipt. 400 OSPF Area Id: The 4-Byte OSPF Area ID. 402 For IS-IS, the area-id is of variable length and thus the length of 403 the Subobject is variable. The Area-id is as described in IS-IS by 404 ISO standard [ISO10589]. The subobject is encoded as follows: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |L| Type | Length | Area-Len | Reserved | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 // IS-IS Area ID // 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 L: The L bit is an attribute of the subobject as defined in [RFC3209] 417 and usage in IRO subobject updated in [IRO-UPDATE]. 419 Type: (TBD3 by IANA) indicating IS-IS Area ID. 421 Length: Variable. The Length MUST be at least 8, and MUST be a 422 multiple of 4. 424 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 425 Identifier in octets; Valid values are from 1 to 13 inclusive). 427 Reserved: Zero at transmission, ignored at receipt. 429 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 430 with trailing zeroes to a four-byte boundary. 432 3.4.2. Update in IRO specification 434 [RFC5440] describes IRO as an optional object used to specify network 435 elements to be traversed by the computed path. It further state that 436 the L bit of such subobject has no meaning within an IRO. It also 437 did not mention if IRO is an ordered or un-ordered list of 438 subobjects. 440 An update to IRO specification [IRO-UPDATE] makes IRO as an ordered 441 list, as well as support for loose bit (L-bit) is added. 443 The use of IRO for Domain-Sequence, assumes the updated specification 444 for IRO, as per [IRO-UPDATE]. 446 3.4.3. IRO for Domain-Sequence 448 The subobject type for IPv4, IPv6, and unnumbered Interface ID can be 449 used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The 450 subobject type for the AS Number (2 or 4 Byte) and the IGP Area are 451 used to specify the domain identifiers in the Domain-Sequence. 453 The IRO can incorporate the new domain subobjects with the existing 454 subobjects in a sequence of traversal. 456 Thus an IRO, comprising subobjects, that represents a Domain- 457 Sequence, define the domains involved in an inter-domain path 458 computation, typically involving two or more collaborative PCEs. 460 A Domain-Sequence can have varying degrees of granularity. It is 461 possible to have a Domain-Sequence composed of, uniquely, AS 462 identifiers. It is also possible to list the involved IGP areas for 463 a given AS. 465 In any case, the mapping between domains and responsible PCEs is not 466 defined in this document. It is assumed that a PCE that needs to 467 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 468 administrative configuration, or discovery). 470 3.4.3.1. PCC Procedures 472 A PCC builds an IRO to encode the Domain-Sequence, so that the 473 cooperating PCEs could compute an inter-domain shortest constrained 474 path across the specified sequence of domains. 476 A PCC may intersperse Area and AS subobjects with other subobjects 477 without change to the previously specified processing of those 478 subobjects in the IRO. 480 3.4.3.2. PCE Procedures 482 If a PCE receives an IRO in a Path Computation request (PCReq) 483 message that contains the subobjects defined in this document, that 484 it does not recognize, it will respond according to the rules for a 485 malformed object as per [RFC5440]. The PCE MAY also include the IRO 486 in the PCErr message as per [RFC5440]. 488 The interpretation of Loose bit (L bit) is as per section 4.3.3.1 of 489 [RFC3209] (as per [IRO-UPDATE]). 491 In a Path Computation reply (PCRep), PCE MAY also supply IRO (with 492 Domain-Sequence information) with the NO-PATH object indicating that 493 the set of elements (domains) of the request's IRO prevented the PCEs 494 from finding a path. 496 The following processing rules apply for Domain-Sequence in IRO - 498 o When a PCE parses an IRO, it interprets each subobject according 499 to the AS number associated with the preceding subobject. We call 500 this the "current AS". Certain subobjects modify the current AS, 501 as follows. 503 * The current AS is initialized to the AS number of the PCC. 505 * If the PCE encounters an AS subobject, then it updates the 506 current AS to this new AS number. 508 * If the PCE encounters an Area subobject, then it assumes that 509 the area belongs to the current AS. 511 * If the PCE encounters an IP address that is globally routable, 512 then it updates the current AS to the AS that owns this IP 513 address. This document does not define how the PCE learns 514 which AS owns the IP address. 516 * If the PCE encounters an IP address that is not globally 517 routable, then it assumes that it belongs to the current AS. 519 * If the PCE encounters an unnumbered link, then it assumes that 520 it belongs to the current AS. 522 o When a PCE parses an IRO, it interprets each subobject according 523 to the Area ID associated with the preceding subobject. We call 524 this the "current Area". Certain subobjects modify the current 525 Area, as follows. 527 * The current Area is initialized to the Area ID of the PCC. 529 * If the current AS is changed, the current Area is reset and 530 need to be determined again by current or subsequent subobject. 532 * If the PCE encounters an Area subobject, then it updates the 533 current Area to this new Area ID. 535 * If the PCE encounters an IP address that belongs to a different 536 area, then it updates the current Area to the Area that has 537 this IP address. This document does not define how the PCE 538 learns which Area has the IP address. 540 * If the PCE encounters an unnumbered link that belongs to a 541 different area, then it updates the current Area to the Area 542 that has this link. 544 * Otherwise, it assumes that the subobject belongs to the current 545 Area. 547 o In case the current PCE is not responsible for the path 548 computation in the current AS or Area, then the PCE selects the 549 "next PCE" in the domain-sequence based on the current AS and 550 Area. 552 3.5. Exclude Route Object (XRO) 554 The Exclude Route Object (XRO) [RFC5521] is an optional object used 555 to specify exclusion of certain abstract nodes or resources from the 556 whole path. 558 3.5.1. Subobjects 560 Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], 561 [RFC4874], and [RFC5520], but new subobjects related to Domain- 562 Sequence are needed. 564 This document extends the support for 4-Byte AS numbers and IGP 565 Areas. 567 Type Subobject 568 TBD1 Autonomous system number (4 Byte) 569 TBD2 OSPF Area id 570 TBD3 ISIS Area id 572 Note: The twins of these subobjects are carried in RSVP-TE messages 573 as defined in [DOMAIN-SUBOBJ]. 575 3.5.1.1. Autonomous system 577 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 578 MAY also be used in the XRO to specify exclusion of certain domains 579 in the path computation procedure. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |X| Type | Length | Reserved | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | AS-ID (4 bytes) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 The X-bit indicates whether the exclusion is mandatory or desired. 591 0: indicates that the AS specified MUST be excluded from the path 592 computed by the PCE(s). 594 1: indicates that the AS specified SHOULD be avoided from the inter- 595 domain path computed by the PCE(s), but MAY be included subject to 596 PCE policy and the absence of a viable path that meets the other 597 constraints. 599 All other fields are consistent with the definition in Section 3.4. 601 3.5.1.2. IGP Area 603 Since the length and format of Area-id is different for OSPF and 604 ISIS, following two subobjects are defined: 606 For OSPF, the area-id is a 32 bit number. The subobject is encoded 607 as follows: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |X| Type | Length | Reserved | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | OSPF Area Id (4 bytes) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 The X-bit indicates whether the exclusion is mandatory or desired. 619 0: indicates that the OSFF Area specified MUST be excluded from the 620 path computed by the PCE(s). 622 1: indicates that the OSFF Area specified SHOULD be avoided from the 623 inter-domain path computed by the PCE(s), but MAY be included 624 subject to PCE policy and the absence of a viable path that meets 625 the other constraints. 627 All other fields are consistent with the definition in Section 3.4. 629 For IS-IS, the area-id is of variable length and thus the length of 630 the subobject is variable. The Area-id is as described in IS-IS by 631 ISO standard [ISO10589]. The subobject is encoded as follows: 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |X| Type | Length | Area-Len | Reserved | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | 639 // IS-IS Area ID // 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 The X-bit indicates whether the exclusion is mandatory or desired. 645 0: indicates that the ISIS Area specified MUST be excluded from the 646 path computed by the PCE(s). 648 1: indicates that the ISIS Area specified SHOULD be avoided from the 649 inter-domain path computed by the PCE(s), but MAY be included 650 subject to PCE policy and the absence of a viable path that meets 651 the other constraints. 653 All other fields are consistent with the definition in Section 3.4. 655 All the processing rules are as per [RFC5521]. 657 Note that, if a PCE receives an XRO in a PCReq message that contains 658 subobjects defined in this document, that it does not recognize, it 659 will respond according to the rules for a malformed object as per 660 [RFC5440]. 662 3.6. Explicit Exclusion Route Subobject (EXRS) 664 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 665 specify exclusion of certain abstract nodes between a specific pair 666 of nodes. 668 The EXRS subobject can carry any of the subobjects defined for 669 inclusion in the XRO, thus the new subobjects to support 4 byte AS 670 and IGP (OSPF / ISIS) Area can also be used in the EXRS. The 671 meanings of the fields of the new XRO subobjects are unchanged when 672 the subobjects are included in an EXRS, except that scope of the 673 exclusion is limited to the single hop between the previous and 674 subsequent elements in the IRO. 676 The EXRS subobject should be interpreted in the context of the 677 current AS and current Area of the preceding subobject in the IRO. 678 The EXRS subobject does not change the current AS or current Area. 679 All other processing rules are as per [RFC5521]. 681 Note that, if a PCE that supports the EXRS in an IRO, parses an IRO, 682 and encounters an EXRS that contains subobjects defined in this 683 document, that it does not recognize, it will act according to the 684 setting of the X-bit in the subobject as per [RFC5521]. 686 3.7. Explicit Route Object (ERO) 688 The Explicit Route Object (ERO) [RFC5440] is used to specify a 689 computed path in the network. PCEP ERO subobject types correspond to 690 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 691 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. The subobjects 692 related to Domain-Sequence are further defined in [DOMAIN-SUBOBJ]. 694 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 695 can also be used in the ERO to specify an abstract node (a group of 696 nodes whose internal topology is opaque to the ingress node of the 697 LSP). Using this concept of abstraction, an explicitly routed LSP 698 can be specified as a sequence of domains. 700 In case of Hierarchical PCE [RFC6805], a Parent PCE can be requested 701 to find the Domain-Sequence. Refer example in Section 4.6. The ERO 702 in reply from parent PCE can then be used in Per-Domain path 703 computation or BRPC. 705 If a PCC receives an ERO in a PCRep message that contains subobject 706 defined in this document, that it does not recognize, it will respond 707 according to the rules for a malformed object as per [RFC5440]. 709 4. Examples 711 The examples in this section are for illustration purposes only; to 712 highlight how the new subobjects could be encoded. They are not 713 meant to be an exhaustive list of all possible usecases and 714 combinations. 716 4.1. Inter-Area Path Computation 718 In an inter-area path computation where the ingress and the egress 719 nodes belong to different IGP areas within the same AS, the Domain- 720 Sequence could be represented using a ordered list of Area 721 subobjects. 723 ----------------- ----------------- 724 | | | | 725 | +--+ | | +--+ | 726 | +--+ | | | | | | | 727 | | | +--+ | | +--+ +--+ | 728 | +--+ | | | | | 729 | | | +--+ | 730 | +--+ | | | 731 | | | | | +--+ | 732 | +--+ | | | | | 733 | | -------------------------- | +--+ | 734 | +--+ +--+ | 735 | | | +--+ | | | 736 |Area 2 +--+ | | +--+ Area 4 | 737 ----------------- | +--+ | ----------------- 738 | | 739 | +--+ | 740 | +--+ | | | 741 | | | +--+ | 742 | +--+ | 743 | | 744 | | 745 | | 746 | | 747 | +--+ | 748 | | | | 749 | +--+ | 750 ----------------- | | ------------------ 751 | +--+ +--+ | 752 | | | | | | 753 | +--+ Area 0 +--+ | 754 | | -------------------------- | +--+ | 755 | +--+ | | | | | 756 | | | | | +--+ | 757 | +--+ +--+ | | | 758 | | | | | +--+ | 759 | +--+ | | | | | 760 | | | +--+ | 761 | +--+ | | | 762 | | | | | +--+ | 763 | +--+ | | | | | 764 | | | +--+ | 765 | | | | 766 | Area 1 | | Area 5 | 767 ----------------- ------------------ 769 Figure 1: Inter-Area Path Computation 771 AS Number is 100. 773 This could be represented in the IRO as: 775 +---------+ +---------+ +---------+ 776 |IRO | |Sub | |Sub | 777 |Object | |Object | |Object | 778 |Header | |Area 0 | |Area 4 | 779 | | | | | | 780 | | | | | | 781 +---------+ +---------+ +---------+ 783 or 785 +---------+ +---------+ +---------+ +---------+ 786 |IRO | |Sub | |Sub | |Sub | 787 |Object | |Object | |Object | |Object | 788 |Header | |Area 2 | |Area 0 | |Area 4 | 789 | | | | | | | | 790 | | | | | | | | 791 +---------+ +---------+ +---------+ +---------+ 793 or 795 +---------+ +---------+ +---------+ +---------+ +---------+ 796 |IRO | |Sub | |Sub | |Sub | |Sub | 797 |Object | |Object AS| |Object | |Object | |Object | 798 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 799 | | | | | | | | | | 800 | | | | | | | | | | 801 +---------+ +---------+ +---------+ +---------+ +---------+ 803 The Domain-Sequence can further include encompassing AS information 804 in the AS subobject. 806 4.2. Inter-AS Path Computation 808 In inter-AS path computation, where ingress and egress belong to 809 different AS, the Domain-Sequence could be represented using an 810 ordered list of AS subobjects. The Domain-Sequence can further 811 include decomposed area information in the Area subobject. 813 4.2.1. Example 1 815 As shown in Figure 2, where AS has a single area, AS subobject in the 816 domain-sequence can uniquely identify the next domain and PCE. 818 AS A AS E AS C 819 <-------------> <----------> <-------------> 821 A4----------E1---E2---E3---------C4 822 / / \ 823 / / \ 824 / / AS B \ 825 / / <----------> \ 826 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 827 \ / / 828 \ / / 829 \ / / 830 \ / / 831 A3----------D1---D2---D3---------C3 833 <----------> 834 AS D 836 * All AS have one area (area 0) 838 Figure 2: Inter-AS Path Computation 840 This could be represented in the IRO as: 842 +-------+ +-------+ +-------+ 843 |IRO | |Sub | |Sub | 844 |Object | |Object | |Object | 845 |Header | |AS B | |AS C | 846 | | | | | | 847 +-------+ +-------+ +-------+ 849 or 851 +-------+ +-------+ +-------+ +-------+ 852 |IRO | |Sub | |Sub | |Sub | 853 |Object | |Object | |Object | |Object | 854 |Header | |AS A | |AS B | |AS C | 855 | | | | | | | | 856 +-------+ +-------+ +-------+ +-------+ 858 or 860 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 861 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 862 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 863 |Header | |AS A | |Area 0 | |AS B | |Area 0 | |AS C | |Area 0 | 864 | | | | | | | | | | | | | | 865 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 867 Note that to get a domain disjoint path, the ingress could also 868 request the backup path with - 870 +-------+ +-------+ 871 |XRO | |Sub | 872 |Object | |Object | 873 |Header | |AS B | 874 | | | | 875 +-------+ +-------+ 877 As described in Section 3.4.3, domain subobject in IRO changes the 878 domain information associated with the next set of subobjects; till 879 you encounter a subobject that changes the domain too. Consider the 880 following IRO: 882 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 883 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | 884 |Object | |Object | |Object | |Object | |Object | |Object | 885 |Header | |AS B | |IP | |IP | |AS C | |IP | 886 | | | | |B1 | |B3 | | | |C1 | 887 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 888 On processing subobject "AS B", it changes the AS of the subsequent 889 subobjects till we encounter another subobject "AS C" which changes 890 the AS for its subsequent subobjects. 892 Consider another IRO: 894 +-------+ +-------+ +-------+ +-------+ +-------+ 895 |IRO | |Sub | |Sub | |Sub | |Sub | 896 |Object | |Object | |Object | |Object | |Object | 897 |Header | |AS D | |IP | |IP | |IP | 898 | | | | |D1 | |D3 | |C3 | 899 +-------+ +-------+ +-------+ +-------+ +-------+ 901 Here as well, on processing "AS D", it changes the AS of the 902 subsequent subobjects till you encounter another subobject "C3" which 903 belong in another AS and changes the AS for its subsequent 904 subobjects. 906 Further description for the Boundary Node and Inter-AS-Link can be 907 found in Section 4.3. 909 4.2.2. Example 2 911 In Figure 3, AS 200 is made up of multiple areas. 913 | 914 | +-------------+ +----------------+ 915 | |Area 2 | |Area 4 | 916 | | +--+| | +--+ | 917 | | | || | | B| | 918 | | +--+ +--+| | +--+ +--+ | 919 | | | | | | | | | 920 | | +--+ | | +--+ | 921 | | +--+ | | +--+ | 922 | | | | | | | | | 923 | | +--+ | | +--+ +--+ | 924 | | +--+ |+--------------+| | | | 925 | | | | +--+ +--+ +--+ | 926 +-------------+| | +--+ | | | | | 927 | || | +--+ +--+ | 928 | +--+|| +-------------+| |+----------------+ 929 | | ||| | +--+ | 930 | +--+|| | | | | 931 | +--+ || | +--+ | 932 | | | +---+ +--+ | 933 | +--+ | |----------------| | | 934 | +---+ Inter-AS +--+ +--+ | 935 |+--+ || Links | | | | 936 ||A | +---+ +--+ +--+ | 937 |+--+ | |----------------| | | 938 | +---+ +--+ +--+ | 939 | +--+ || +------------+ | | | |+----------------+ 940 | | | || |Area 3 +--+ +--+ +--+ Area 5 | 941 | +--+ || | | | | | | 942 | || | +--+ +--+ | 943 | +--+|| | +--+ | | Area 0 || +--+ | 944 | | ||| | | | | +--------------+| | | | 945 | +--+|| | +--+ | | +--+ | 946 | || | | | +--+ | 947 |Area 0 || | +--+ | | +--+ | | | 948 +-------------+| | | | | | | | +--+ | 949 | | +--+ +--+ | +--+ | 950 | | | | | | 951 | | +--+ | +--+ | 952 | | +--+ | | | C| | 953 | | | | | | +--+ | 954 | | +--+ | | | 955 | | | | | 956 | +------------+ +----------------+ 957 | 958 | 959 AS 100 | AS 200 960 | 962 Figure 3: Inter-AS Path Computation 964 The Domain-Sequence for the LSP (A-B) can be carried in the IRO as 965 shown below: 967 +-------+ +-------+ +-------+ +-------+ 968 |IRO | |Sub | |Sub | |Sub | 969 |Object | |Object | |Object | |Object | 970 |Header | |AS 200 | |Area 0 | |Area 4 | 971 | | | | | | | | 972 +-------+ +-------+ +-------+ +-------+ 974 or 976 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 977 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | 978 |Object | |Object | |Object | |Object | |Object | |Object | 979 |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 | 980 | | | | | | | | | | | | 981 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 982 The Domain-Sequence for the LSP (A-C) can be carried in the IRO as 983 shown below: 985 +-------+ +-------+ +-------+ +-------+ 986 |IRO | |Sub | |Sub | |Sub | 987 |Object | |Object | |Object | |Object | 988 |Header | |AS 200 | |Area 0 | |Area 5 | 989 | | | | | | | | 990 +-------+ +-------+ +-------+ +-------+ 992 or 994 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 995 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | 996 |Object | |Object | |Object | |Object | |Object | |Object | 997 |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 5 | 998 | | | | | | | | | | | | 999 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1001 4.3. Boundary Node and Inter-AS-Link 1003 A PCC or PCE can include additional constraints covering which 1004 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) to be 1005 traversed while defining a Domain-Sequence. In which case the 1006 Boundary Node or Link can be encoded as a part of the Domain- 1007 Sequence. 1009 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 1010 prefix subobjects usually the loopback address of 32 and 128 prefix 1011 length respectively. An Inter-AS link can be encoded using the IPv4 1012 or IPv6 prefix subobjects or unnumbered interface subobjects. 1014 For Figure 1, an ABR (say 203.0.113.1) to be traversed can be 1015 specified in IRO as: 1017 +---------+ +---------+ +---------++---------+ +---------+ 1018 |IRO | |Sub | |Sub ||Sub | |Sub | 1019 |Object | |Object | |Object ||Object | |Object | 1020 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 1021 | | | | |203.0. || | | | 1022 | | | | |112.1 || | | | 1023 +---------+ +---------+ +---------++---------+ +---------+ 1025 For Figure 3, an inter-AS-link (say 198.51.100.1 - 198.51.100.2) to 1026 be traversed can be specified as: 1028 +---------+ +---------+ +---------+ +---------+ 1029 |IRO | |Sub | |Sub | |Sub | 1030 |Object | |Object AS| |Object | |Object AS| 1031 |Header | |100 | |IPv4 | |200 | 1032 | | | | |198.51. | | | 1033 | | | | |100.2 | | | 1034 +---------+ +---------+ +---------+ +---------+ 1036 4.4. PCE Serving multiple Domains 1038 A single PCE can be responsible for multiple domains; for example PCE 1039 function deployed on an ABR could be responsible for multiple areas. 1040 A PCE which can support adjacent domains can internally handle those 1041 domains in the Domain-Sequence without any impact on the other 1042 domains in the Domain-Sequence. 1044 4.5. P2MP 1046 [RFC7334] describes an experimental inter-domain P2MP path 1047 computation mechanism where the path domain tree is described as a 1048 series of Domain-Sequences, an example is shown in the below figure: 1050 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 1051 D1 1052 / \ 1053 D2 D3 1054 / / \ 1055 D4 D5 D6 1057 The domain sequence handling described in this document could be 1058 applied to P2MP path domain tree. 1060 4.6. Hierarchical PCE 1062 In case of H-PCE [RFC6805], the parent PCE can be requested to 1063 determine the Domain-Sequence and return it in the path computation 1064 reply, using the ERO. . For the example in section 4.6 of [RFC6805], 1065 the Domain-Sequence can possibly appear as: 1067 +---------+ +---------+ +---------+ +---------+ 1068 |ERO | |Sub | |Sub | |Sub | 1069 |Object | |Object | |Object | |Object | 1070 |Header | |Domain 1 | |Domain 2 | |Domain 3 | 1071 | | | | | | | | 1072 | | | | | | | | 1073 +---------+ +---------+ +---------+ +---------+ 1075 or 1077 +---------+ +---------+ +---------+ 1078 |ERO | |Sub | |Sub | 1079 |Object | |Object | |Object | 1080 |Header | |BN 21 | |Domain 3 | 1081 | | | | | | 1082 | | | | | | 1083 +---------+ +---------+ +---------+ 1085 5. Other Considerations 1087 5.1. Relationship to PCE Sequence 1089 Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by 1090 policy on the PCC, and this constraint can be carried in the PCReq 1091 message (as defined in [RFC5886]). 1093 Note that PCE-Sequence can be used along with Domain-Sequence in 1094 which case PCE-Sequence MUST have higher precedence in selecting the 1095 next PCE in the inter-domain path computation procedures. 1097 5.2. Relationship to RSVP-TE 1099 [RFC3209] already describes the notion of abstract nodes, where an 1100 abstract node is a group of nodes whose internal topology is opaque 1101 to the ingress node of the LSP. It further defines a subobject for 1102 AS but with a 2-Byte AS Number. 1104 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1105 subobjects for IGP Areas and 4-byte AS numbers. These subobjects can 1106 be included in Explicit Route Object (ERO), Exclude Route object 1107 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1109 In any case subobject type defined in RSVP-TE are identical to the 1110 subobject type defined in the related documents in PCEP. 1112 6. IANA Considerations 1114 6.1. New Subobjects 1116 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 1117 at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this 1118 registry IANA maintains two sub-registries: 1120 o "IRO Subobjects": http://www.iana.org/assignments/pcep/ 1121 pcep.xhtml#iro-subobject 1123 o "XRO Subobjects": http://www.iana.org/assignments/pcep/ 1124 pcep.xhtml#xro-subobject 1126 Upon approval of this document, IANA is requested to make identical 1127 additions to these registries as follows: 1129 Subobject Type Reference 1130 TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ] 1131 TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ] 1132 TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ] 1134 7. Security Considerations 1136 This document specifies a standard representation of Domain-Sequence 1137 and new subobjects, which could be used in inter-domain PCE scenarios 1138 as explained in other RFC and drafts. The new subobjects and Domain- 1139 Sequence mechanisms defined in this document allow finer and more 1140 specific control of the path computed by a cooperating PCE(s). Such 1141 control increases the risk if a PCEP message is intercepted, 1142 modified, or spoofed because it allows the attacker to exert control 1143 over the path that the PCE will compute or to make the path 1144 computation impossible. Therefore, the security techniques described 1145 in [RFC5440] are considered more important. 1147 Note, however, that the Domain-Sequence mechanisms also provide the 1148 operator with the ability to route around vulnerable parts of the 1149 network and may be used to increase overall network security. 1151 8. Manageability Considerations 1153 8.1. Control of Function and Policy 1155 The exact behaviour with regards to desired inclusion and exclusion 1156 of domains MUST be available for examination by an operator and MAY 1157 be configurable. Manual configurations is needed to identify which 1158 PCEP peers understand the new domain subobjects defined in this 1159 document. 1161 8.2. Information and Data Models 1163 A MIB module for management of the PCEP is being specified in a 1164 separate document [RFC7420]. This document does not imply any new 1165 extention to the current MIB module. 1167 8.3. Liveness Detection and Monitoring 1169 Mechanisms defined in this document do not imply any new liveness 1170 detection and monitoring requirements in addition to those already 1171 listed in [RFC5440]. 1173 8.4. Verify Correct Operations 1175 Mechanisms defined in this document do not imply any new operation 1176 verification requirements in addition to those already listed in 1177 [RFC5440]. 1179 8.5. Requirements On Other Protocols 1181 In case of per-domain path computation [RFC5152], where the full path 1182 of an inter-domain TE LSP cannot be, or is not determined at the 1183 ingress node, a signaling message can use the domain identifiers. 1184 The Subobjects defined in this document SHOULD be supported by RSVP- 1185 TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding 1186 new subobjects for IGP Areas and 4-byte AS numbers. 1188 Apart from this, mechanisms defined in this document do not imply any 1189 requirements on other protocols in addition to those already listed 1190 in [RFC5440]. 1192 8.6. Impact On Network Operations 1194 The mechanisms described in this document can provide the operator 1195 with the ability to exert finer and more specific control of the path 1196 computation by inclusion or exclusion of domain subobjects. There 1197 may be some scaling benefit when a single domain subobject may 1198 substitute for many subobjects and can reduce the overall message 1199 size and processing. 1201 Backward compatibility issues associated with the new subobjects 1202 arise when a PCE does not recognize them, in which case PCE responds 1203 according to the rules for a malformed object as per [RFC5440]. For 1204 successful operations the PCEs in the network would need to be 1205 upgraded. 1207 9. Acknowledgments 1209 Authors would like to especially thank Adrian Farrel for his detailed 1210 reviews as well as providing text to be included in the document. 1212 Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin 1213 Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1214 Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti 1215 and Jonathan Hardwick for their useful comments and suggestions. 1217 10. References 1219 10.1. Normative References 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, 1223 DOI 10.17487/RFC2119, March 1997, 1224 . 1226 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1227 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1228 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1229 . 1231 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1232 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1233 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1234 DOI 10.17487/RFC3473, January 2003, 1235 . 1237 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1238 in Resource ReSerVation Protocol - Traffic Engineering 1239 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1240 . 1242 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1243 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1244 DOI 10.17487/RFC5440, March 2009, 1245 . 1247 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1248 "A Backward-Recursive PCE-Based Computation (BRPC) 1249 Procedure to Compute Shortest Constrained Inter-Domain 1250 Traffic Engineering Label Switched Paths", RFC 5441, 1251 DOI 10.17487/RFC5441, April 2009, 1252 . 1254 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1255 Path Computation Element Communication Protocol (PCEP) for 1256 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 1257 2009, . 1259 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1260 Path Computation Element Architecture to the Determination 1261 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1262 DOI 10.17487/RFC6805, November 2012, 1263 . 1265 [ISO10589] 1266 ISO, "Intermediate system to Intermediate system routing 1267 information exchange protocol for use in conjunction with 1268 the Protocol for providing the Connectionless-mode Network 1269 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1271 [IRO-UPDATE] 1272 Dhody, D., "Update to Include Route Object (IRO) 1273 specification in Path Computation Element communication 1274 Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015. 1276 [DOMAIN-SUBOBJ] 1277 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1278 "Domain Subobjects for Resource ReserVation Protocol - 1279 Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- 1280 domain-subobjects-02)", July 2015. 1282 10.2. Informative References 1284 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1285 Element (PCE)-Based Architecture", RFC 4655, 1286 DOI 10.17487/RFC4655, August 2006, 1287 . 1289 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1290 Inter-Domain Multiprotocol Label Switching Traffic 1291 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 1292 2006, . 1294 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1295 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1296 May 2007, . 1298 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1299 Extension to Resource ReserVation Protocol-Traffic 1300 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 1301 April 2007, . 1303 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1304 Per-Domain Path Computation Method for Establishing Inter- 1305 Domain Traffic Engineering (TE) Label Switched Paths 1306 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 1307 . 1309 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1310 "Preserving Topology Confidentiality in Inter-Domain Path 1311 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1312 DOI 10.17487/RFC5520, April 2009, 1313 . 1315 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 1316 Monitoring Tools for Path Computation Element (PCE)-Based 1317 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 1318 . 1320 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1321 Autonomous System (AS) Number Space", RFC 6793, 1322 DOI 10.17487/RFC6793, December 2012, 1323 . 1325 [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, 1326 "PCE-Based Computation Procedure to Compute Shortest 1327 Constrained Point-to-Multipoint (P2MP) Inter-Domain 1328 Traffic Engineering Label Switched Paths", RFC 7334, 1329 DOI 10.17487/RFC7334, August 2014, 1330 . 1332 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1333 Hardwick, "Path Computation Element Communication Protocol 1334 (PCEP) Management Information Base (MIB) Module", 1335 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1336 . 1338 Authors' Addresses 1340 Dhruv Dhody 1341 Huawei Technologies 1342 Divyashree Techno Park, Whitefield 1343 Bangalore, Karnataka 560037 1344 India 1346 EMail: dhruv.ietf@gmail.com 1347 Udayasree Palle 1348 Huawei Technologies 1349 Divyashree Techno Park, Whitefield 1350 Bangalore, Karnataka 560037 1351 India 1353 EMail: udayasree.palle@huawei.com 1355 Ramon Casellas 1356 CTTC 1357 Av. Carl Friedrich Gauss n7 1358 Castelldefels, Barcelona 08860 1359 Spain 1361 EMail: ramon.casellas@cttc.es