idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-12.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 (December 7, 2015) is 3034 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 (-18) exists of draft-ietf-pce-pceps-06 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: June 9, 2016 R. Casellas 6 CTTC 7 December 7, 2015 9 Domain Subobjects for Path Computation Element (PCE) Communication 10 Protocol (PCEP). 11 draft-ietf-pce-pcep-domain-sequence-12 13 Abstract 15 The ability to compute shortest constrained Traffic Engineering Label 16 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 17 Generalized MPLS (GMPLS) networks across multiple domains has been 18 identified as a key requirement. In this context, a domain is a 19 collection of network elements within a common sphere of address 20 management or path computational responsibility such as an Interior 21 Gateway Protocol (IGP) area or an Autonomous System (AS). This 22 document specifies a representation and encoding of a Domain- 23 Sequence, which is defined as an ordered sequence of domains 24 traversed to reach the destination domain to be used by Path 25 Computation Elements (PCEs) to compute inter-domain constrained 26 shortest paths across a predetermined sequence of domains . This 27 document also defines new subobjects to be used to encode domain 28 identifiers. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 9, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 72 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 73 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 74 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 75 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9 76 3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 77 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 78 3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11 79 3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11 80 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 81 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 13 82 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13 83 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 14 84 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15 85 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 16 86 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16 88 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18 89 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 90 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 91 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23 92 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 93 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 26 96 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 26 97 5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 26 98 5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 26 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 27 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 8. Manageability Considerations . . . . . . . . . . . . . . . . 28 103 8.1. Control of Function and Policy . . . . . . . . . . . . . 28 104 8.2. Information and Data Models . . . . . . . . . . . . . . . 28 105 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 106 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 107 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 29 108 8.6. Impact On Network Operations . . . . . . . . . . . . . . 29 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 112 10.2. Informative References . . . . . . . . . . . . . . . . . 31 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 115 1. Introduction 117 A Path Computation Element (PCE) may be used to compute end-to-end 118 paths across multi-domain environments using a per-domain path 119 computation technique [RFC5152]. The backward recursive path 120 computation (BRPC) mechanism [RFC5441] also defines a PCE-based path 121 computation procedure to compute inter-domain constrained path for 122 (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume 123 that the sequence of domains to be crossed from source to destination 124 is known, either fixed by the network operator or obtained by other 125 means. Also for inter-domain point-to-multi-point (P2MP) tree 126 computation, [RFC7334] assumes the domain-tree is known in priori. 128 The list of domains (Domain-Sequence) in point-to-point (P2P) or a 129 domain tree in point-to-multipoint (P2MP) is usually a constraint in 130 inter-domain path computation procedure. 132 The Domain-Sequence (the set of domains traversed to reach the 133 destination domain) is either administratively predetermined or 134 discovered by some means like H-PCE. 136 [RFC5440] defines the Include Route Object (IRO) and the Explicit 137 Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) 138 and the Explicit Exclusion Route Subobject (EXRS). The use of 139 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 140 abstract node representing a domain is defined in [RFC3209]. In the 141 current document, we specify new subobjects to include or exclude 142 domains including IGP area or an Autonomous Systems (4-Byte as per 143 [RFC6793]). 145 Further, the domain identifier may simply act as delimiter to specify 146 where the domain boundary starts and ends in some cases. 148 This is a companion document to Resource ReserVation Protocol - 149 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 150 [DOMAIN-SUBOBJ]. 152 1.1. Scope 154 The procedures described in this document are experimental. The 155 experiment is intended to enable research for the usage of Domain- 156 Sequence at the PCEs for inter-domain paths. For this purpose this 157 document specifies new domain subobjects as well as how they 158 incorporate with existing subobjects to represent a Domain-Sequence. 160 The experiment will end two years after the RFC is published. At 161 that point, the RFC authors will attempt to determine how widely this 162 has been implemented and deployed. 164 This document does not change the procedures for handling existing 165 subobjects in PCEP. 167 The new subobjects introduced by this document will not be understood 168 by legacy implementations. If a legacy implementation receives one 169 of the subobjects that it does not understand in a PCEP object, the 170 legacy implementation will behave as described in Section 3.4.3. 171 Therefore, it is assumed that this experiment will be conducted only 172 when both the PCE and the PCC form part of the experiment. It is 173 possible that a PCC or PCE can operate with peers some of which form 174 part of the experiment and some that do not. In this case, since no 175 capabilities exchange is used to identify which nodes can use these 176 extensions, manual configuration should be used to determine which 177 peerings form part of the experiment. 179 When the result of implementation and deployment are available, this 180 document will be updated and refined, and then be moved from 181 Experimental to Standard Track. 183 1.2. Requirements Language 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 2. Terminology 191 The following terminology is used in this document. 193 ABR: OSPF Area Border Router. Routers used to connect two IGP 194 areas. 196 AS: Autonomous System. 198 ASBR: Autonomous System Boundary Router. 200 BN: Boundary Node, Can be an ABR or ASBR. 202 BRPC: Backward Recursive Path Computation 204 Domain: As per [RFC4655], any collection of network elements within 205 a common sphere of address management or path computational 206 responsibility. Examples of domains include Interior Gateway 207 Protocol (IGP) area and Autonomous System (AS). 209 Domain-Sequence: An ordered sequence of domains traversed to reach 210 the destination domain. 212 ERO: Explicit Route Object 214 H-PCE: Hierarchical PCE 216 IGP: Interior Gateway Protocol. Either of the two routing 217 protocols, Open Shortest Path First (OSPF) or Intermediate System 218 to Intermediate System (IS-IS). 220 IRO: Include Route Object 222 IS-IS: Intermediate System to Intermediate System. 224 OSPF: Open Shortest Path First. 226 PCC: Path Computation Client: any client application requesting a 227 path computation to be performed by a Path Computation Element. 229 PCE: Path Computation Element. An entity (component, application, 230 or network node) that is capable of computing a network path or 231 route based on a network graph and applying computational 232 constraints. 234 P2MP: Point-to-Multipoint 236 P2P: Point-to-Point 237 RSVP: Resource Reservation Protocol 239 TE LSP: Traffic Engineering Label Switched Path. 241 XRO: Exclude Route Object 243 3. Detail Description 245 3.1. Domains 247 [RFC4726] and [RFC4655] define domain as a separate administrative or 248 geographic environment within the network. A domain could be further 249 defined as a zone of routing or computational ability. Under these 250 definitions a domain might be categorized as an AS or an IGP area. 251 Each AS can be made of several IGP areas. In order to encode a 252 Domain-Sequence, it is required to uniquely identify a domain in the 253 Domain-Sequence. A domain can be uniquely identified by area-id or 254 AS number or both. 256 3.2. Domain-Sequence 258 A Domain-Sequence is an ordered sequence of domains traversed to 259 reach the destination domain. 261 A Domain-Sequence can be applied as a constraint and carried in a 262 path computation request to PCE(s). A Domain-Sequence can also be 263 the result of a path computation. For example, in the case of 264 Hierarchical PCE (H-PCE) [RFC6805], Parent PCE could send the Domain- 265 Sequence as a result in a path computation reply. 267 In a P2P path, the domains listed appear in the order that they are 268 crossed. In a P2MP path, the domain tree is represented as a list of 269 Domain-Sequences. 271 A Domain-Sequence enables a PCE to select the next domain and the PCE 272 serving that domain to forward the path computation request based on 273 the domain information. 275 Domain-Sequence can include Boundary Nodes (ABR or ASBR) or Border 276 links (Inter-AS-links) to be traversed as an additional constraint. 278 Thus a Domain-Sequence can be made up of one or more of - 280 o AS Number 282 o Area ID 284 o Boundary Node ID 285 o Inter-AS-Link Address 287 These are encoded in the new subobjects defined in this document as 288 well as the existing subobjects to represent a Domain-Sequence. 290 Consequently, a Domain-Sequence can be used: 292 1. by a PCE in order to discover or select the next PCE in a 293 collaborative path computation, such as in BRPC [RFC5441]; 295 2. by the Parent PCE to return the Domain-Sequence when unknown; 296 this can then be an input to the BRPC procedure [RFC6805]; 298 3. by a Path Computation Client (PCC) or a PCE, to constrain the 299 domains used in inter-domain path computation, explicitly 300 specifying which domains to be expanded or excluded; 302 4. by a PCE in the per-domain path computation model [RFC5152] to 303 identify the next domain. 305 3.3. Domain-Sequence Representation 307 Domain-Sequence appears in PCEP messages, notably in - 309 o Include Route Object (IRO): As per [RFC5440], IRO can be used to 310 specify a set of network elements to be traversed to reach the 311 destination, which includes subobjects used to specify the Domain- 312 Sequence. 314 o Exclude Route Object (XRO): As per [RFC5521], XRO can be used to 315 specify certain abstract nodes, to be excluded from whole path, 316 which includes subobjects used to specify the Domain-Sequence. 318 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], EXRS 319 can be used to specify exclusion of certain abstract nodes 320 (including domains) between a specific pair of nodes. EXRS are a 321 subobject inside the IRO. 323 o Explicit Route Object (ERO): As per [RFC5440], ERO can be used to 324 specify a computed path in the network. For example, in the case 325 of H-PCE [RFC6805], a Parent PCE can send the Domain-Sequence as a 326 result, in a path computation reply using ERO. 328 3.4. Include Route Object (IRO) 330 As per [RFC5440], IRO (Include Route Object) can be used to specify 331 that the computed path needs to traverse a set of specified network 332 elements or abstract nodes. 334 3.4.1. Subobjects 336 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 337 [RFC4874], but new subobjects related to Domain-Sequence are needed. 339 This document extends the support for 4-Byte AS numbers and IGP 340 Areas. 342 Type Subobject 343 TBD1 Autonomous system number (4 Byte) 344 TBD2 OSPF Area id 345 TBD3 ISIS Area id 347 Note: The twins of these subobjects are carried in RSVP-TE messages 348 as defined in [DOMAIN-SUBOBJ]. 350 3.4.1.1. Autonomous system 352 [RFC3209] already defines 2 byte AS number. 354 To support 4 byte AS number as per [RFC6793] following subobject is 355 defined: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |L| Type | Length | Reserved | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | AS-ID (4 bytes) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 L: The L bit is an attribute of the subobject as defined in [RFC3209] 366 and usage in IRO subobject updated in [IRO-UPDATE]. 368 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 370 Length: 8 (Total length of the subobject in bytes). 372 Reserved: Zero at transmission, ignored at receipt. 374 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 375 use, the low order bits (16 through 31) MUST be used and the high 376 order bits (0 through 15) MUST be set to zero. 378 3.4.1.2. IGP Area 380 Since the length and format of Area-id is different for OSPF and 381 ISIS, following two subobjects are defined: 383 For OSPF, the area-id is a 32 bit number. The subobject is encoded 384 as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |L| Type | Length | Reserved | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | OSPF Area Id (4 bytes) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 L: The L bit is an attribute of the subobject as defined in [RFC3209] 395 and usage in IRO subobject updated in [IRO-UPDATE]. 397 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 399 Length: 8 (Total length of the subobject in bytes). 401 Reserved: Zero at transmission, ignored at receipt. 403 OSPF Area Id: The 4-Byte OSPF Area ID. 405 For IS-IS, the area-id is of variable length and thus the length of 406 the Subobject is variable. The Area-id is as described in IS-IS by 407 ISO standard [ISO10589]. The subobject is encoded as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |L| Type | Length | Area-Len | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 // IS-IS Area ID // 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 L: The L bit is an attribute of the subobject as defined in [RFC3209] 420 and usage in IRO subobject updated in [IRO-UPDATE]. 422 Type: (TBD3 by IANA) indicating IS-IS Area ID. 424 Length: Variable. The Length MUST be at least 8, and MUST be a 425 multiple of 4. 427 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 428 Identifier in octets; Valid values are from 1 to 13 inclusive). 430 Reserved: Zero at transmission, ignored at receipt. 432 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 433 with trailing zeroes to a four-byte boundary. 435 3.4.2. Update in IRO specification 437 [RFC5440] describes IRO as an optional object used to specify network 438 elements to be traversed by the computed path. It further state that 439 the L bit of such subobject has no meaning within an IRO. It also 440 did not mention if IRO is an ordered or un-ordered list of 441 subobjects. 443 An update to IRO specification [IRO-UPDATE] makes IRO as an ordered 444 list, as well as support for loose bit (L-bit) is added. 446 The use of IRO for Domain-Sequence, assumes the updated specification 447 for IRO, as per [IRO-UPDATE]. 449 3.4.3. IRO for Domain-Sequence 451 The subobject type for IPv4, IPv6, and unnumbered Interface ID can be 452 used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The 453 subobject type for the AS Number (2 or 4 Byte) and the IGP Area are 454 used to specify the domain identifiers in the Domain-Sequence. 456 The IRO can incorporate the new domain subobjects with the existing 457 subobjects in a sequence of traversal. 459 Thus an IRO, comprising subobjects, that represents a Domain- 460 Sequence, define the domains involved in an inter-domain path 461 computation, typically involving two or more collaborative PCEs. 463 A Domain-Sequence can have varying degrees of granularity. It is 464 possible to have a Domain-Sequence composed of, uniquely, AS 465 identifiers. It is also possible to list the involved IGP areas for 466 a given AS. 468 In any case, the mapping between domains and responsible PCEs is not 469 defined in this document. It is assumed that a PCE that needs to 470 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 471 administrative configuration, or discovery). 473 3.4.3.1. PCC Procedures 475 A PCC builds an IRO to encode the Domain-Sequence, so that the 476 cooperating PCEs could compute an inter-domain shortest constrained 477 path across the specified sequence of domains. 479 A PCC may intersperse Area and AS subobjects with other subobjects 480 without change to the previously specified processing of those 481 subobjects in the IRO. 483 3.4.3.2. PCE Procedures 485 If a PCE receives an IRO in a Path Computation request (PCReq) 486 message that contains the subobjects defined in this document, that 487 it does not recognize, it will respond according to the rules for a 488 malformed object as per [RFC5440]. The PCE MAY also include the IRO 489 in the PCErr message as per [RFC5440]. 491 The interpretation of Loose bit (L bit) is as per section 4.3.3.1 of 492 [RFC3209] (as per [IRO-UPDATE]). 494 In a Path Computation reply (PCRep), PCE MAY also supply IRO (with 495 Domain-Sequence information) with the NO-PATH object indicating that 496 the set of elements (domains) of the request's IRO prevented the PCEs 497 from finding a path. 499 The following processing rules apply for Domain-Sequence in IRO - 501 o When a PCE parses an IRO, it interprets each subobject according 502 to the AS number associated with the preceding subobject. We call 503 this the "current AS". Certain subobjects modify the current AS, 504 as follows. 506 * The current AS is initialized to the AS number of the PCC. 508 * If the PCE encounters an AS subobject, then it updates the 509 current AS to this new AS number. 511 * If the PCE encounters an Area subobject, then it assumes that 512 the area belongs to the current AS. 514 * If the PCE encounters an IP address that is globally routable, 515 then it updates the current AS to the AS that owns this IP 516 address. This document does not define how the PCE learns 517 which AS owns the IP address. 519 * If the PCE encounters an IP address that is not globally 520 routable, then it assumes that it belongs to the current AS. 522 * If the PCE encounters an unnumbered link, then it assumes that 523 it belongs to the current AS. 525 o When a PCE parses an IRO, it interprets each subobject according 526 to the Area ID associated with the preceding subobject. We call 527 this the "current Area". Certain subobjects modify the current 528 Area, as follows. 530 * The current Area is initialized to the Area ID of the PCC. 532 * If the current AS is changed, the current Area is reset and 533 need to be determined again by current or subsequent subobject. 535 * If the PCE encounters an Area subobject, then it updates the 536 current Area to this new Area ID. 538 * If the PCE encounters an IP address that belongs to a different 539 area, then it updates the current Area to the Area that has 540 this IP address. This document does not define how the PCE 541 learns which Area has the IP address. 543 * If the PCE encounters an unnumbered link that belongs to a 544 different area, then it updates the current Area to the Area 545 that has this link. 547 * Otherwise, it assumes that the subobject belongs to the current 548 Area. 550 o In case the current PCE is not responsible for the path 551 computation in the current AS or Area, then the PCE selects the 552 "next PCE" in the domain-sequence based on the current AS and 553 Area. 555 Note that it is advised that, PCC should use AS and Area subobject 556 while building the domain-sequence in IRO and avoid using other 557 mechanism to change the "current AS" and "current Area" as described 558 above. 560 3.5. Exclude Route Object (XRO) 562 The Exclude Route Object (XRO) [RFC5521] is an optional object used 563 to specify exclusion of certain abstract nodes or resources from the 564 whole path. 566 3.5.1. Subobjects 568 Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], 569 [RFC4874], and [RFC5520], but new subobjects related to Domain- 570 Sequence are needed. 572 This document extends the support for 4-Byte AS numbers and IGP 573 Areas. 575 Type Subobject 576 TBD1 Autonomous system number (4 Byte) 577 TBD2 OSPF Area id 578 TBD3 ISIS Area id 580 Note: The twins of these subobjects are carried in RSVP-TE messages 581 as defined in [DOMAIN-SUBOBJ]. 583 3.5.1.1. Autonomous system 585 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 586 MAY also be used in the XRO to specify exclusion of certain domains 587 in the path computation procedure. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 |X| Type | Length | Reserved | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | AS-ID (4 bytes) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 The X-bit indicates whether the exclusion is mandatory or desired. 599 0: indicates that the AS specified MUST be excluded from the path 600 computed by the PCE(s). 602 1: indicates that the AS specified SHOULD be avoided from the inter- 603 domain path computed by the PCE(s), but MAY be included subject to 604 PCE policy and the absence of a viable path that meets the other 605 constraints. 607 All other fields are consistent with the definition in Section 3.4. 609 3.5.1.2. IGP Area 611 Since the length and format of Area-id is different for OSPF and 612 ISIS, following two subobjects are defined: 614 For OSPF, the area-id is a 32 bit number. The subobject is encoded 615 as follows: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |X| Type | Length | Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | OSPF Area Id (4 bytes) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 The X-bit indicates whether the exclusion is mandatory or desired. 627 0: indicates that the OSFF Area specified MUST be excluded from the 628 path computed by the PCE(s). 630 1: indicates that the OSFF Area specified SHOULD be avoided from the 631 inter-domain path computed by the PCE(s), but MAY be included 632 subject to PCE policy and the absence of a viable path that meets 633 the other constraints. 635 All other fields are consistent with the definition in Section 3.4. 637 For IS-IS, the area-id is of variable length and thus the length of 638 the subobject is variable. The Area-id is as described in IS-IS by 639 ISO standard [ISO10589]. The subobject is encoded as follows: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 |X| Type | Length | Area-Len | Reserved | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | | 647 // IS-IS Area ID // 648 | | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 The X-bit indicates whether the exclusion is mandatory or desired. 653 0: indicates that the ISIS Area specified MUST be excluded from the 654 path computed by the PCE(s). 656 1: indicates that the ISIS Area specified SHOULD be avoided from the 657 inter-domain path computed by the PCE(s), but MAY be included 658 subject to PCE policy and the absence of a viable path that meets 659 the other constraints. 661 All other fields are consistent with the definition in Section 3.4. 663 All the processing rules are as per [RFC5521]. 665 Note that, if a PCE receives an XRO in a PCReq message that contains 666 subobjects defined in this document, that it does not recognize, it 667 will respond according to the rules for a malformed object as per 668 [RFC5440]. 670 IGP Area subobjects in the XRO are local to the current AS. In case 671 of multi-AS path computation to exclude an IGP area in a different 672 AS, IGP Area subobject should be part of Explicit Exclusion Route 673 Subobject (EXRS) in the IRO to specify the AS in which the IGP area 674 is to be excluded. Further policy may be applied to prune/ignore 675 Area subobjects in XRO after "current AS" change during path 676 computation. 678 3.6. Explicit Exclusion Route Subobject (EXRS) 680 EXRS [RFC5521] is used to specify exclusion of certain abstract nodes 681 between a specific pair of nodes. 683 The EXRS subobject can carry any of the subobjects defined for 684 inclusion in the XRO, thus the new subobjects to support 4 byte AS 685 and IGP (OSPF / ISIS) Area can also be used in the EXRS. The 686 meanings of the fields of the new XRO subobjects are unchanged when 687 the subobjects are included in an EXRS, except that scope of the 688 exclusion is limited to the single hop between the previous and 689 subsequent elements in the IRO. 691 The EXRS subobject should be interpreted in the context of the 692 current AS and current Area of the preceding subobject in the IRO. 693 The EXRS subobject does not change the current AS or current Area. 694 All other processing rules are as per [RFC5521]. 696 Note that, if a PCE that supports the EXRS in an IRO, parses an IRO, 697 and encounters an EXRS that contains subobjects defined in this 698 document, that it does not recognize, it will act according to the 699 setting of the X-bit in the subobject as per [RFC5521]. 701 3.7. Explicit Route Object (ERO) 703 The Explicit Route Object (ERO) [RFC5440] is used to specify a 704 computed path in the network. PCEP ERO subobject types correspond to 705 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 706 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. The subobjects 707 related to Domain-Sequence are further defined in [DOMAIN-SUBOBJ]. 709 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 710 can also be used in the ERO to specify an abstract node (a group of 711 nodes whose internal topology is opaque to the ingress node of the 712 LSP). Using this concept of abstraction, an explicitly routed LSP 713 can be specified as a sequence of domains. 715 In case of Hierarchical PCE [RFC6805], a Parent PCE can be requested 716 to find the Domain-Sequence. Refer example in Section 4.6. The ERO 717 in reply from parent PCE can then be used in Per-Domain path 718 computation or BRPC. 720 If a PCC receives an ERO in a PCRep message that contains subobject 721 defined in this document, that it does not recognize, it will respond 722 according to the rules for a malformed object as per [RFC5440]. 724 4. Examples 726 The examples in this section are for illustration purposes only; to 727 highlight how the new subobjects could be encoded. They are not 728 meant to be an exhaustive list of all possible usecases and 729 combinations. 731 4.1. Inter-Area Path Computation 733 In an inter-area path computation where the ingress and the egress 734 nodes belong to different IGP areas within the same AS, the Domain- 735 Sequence could be represented using a ordered list of Area 736 subobjects. 738 ----------------- ----------------- 739 | | | | 740 | +--+ | | +--+ | 741 | +--+ | | | | | | | 742 | | | +--+ | | +--+ +--+ | 743 | +--+ | | | | | 744 | | | +--+ | 745 | +--+ | | | 746 | | | | | +--+ | 747 | +--+ | | | | | 748 | | -------------------------- | +--+ | 749 | +--+ +--+ | 750 | | | +--+ | | | 751 |Area 2 +--+ | | +--+ Area 4 | 752 ----------------- | +--+ | ----------------- 753 | | 754 | +--+ | 755 | +--+ | | | 756 | | | +--+ | 757 | +--+ | 758 | | 759 | | 760 | | 761 | | 762 | +--+ | 763 | | | | 764 | +--+ | 765 ----------------- | | ------------------ 766 | +--+ +--+ | 767 | | | | | | 768 | +--+ Area 0 +--+ | 769 | | -------------------------- | +--+ | 770 | +--+ | | | | | 771 | | | | | +--+ | 772 | +--+ +--+ | | | 773 | | | | | +--+ | 774 | +--+ | | | | | 775 | | | +--+ | 776 | +--+ | | | 777 | | | | | +--+ | 778 | +--+ | | | | | 779 | | | +--+ | 780 | | | | 781 | Area 1 | | Area 5 | 782 ----------------- ------------------ 784 Figure 1: Inter-Area Path Computation 786 AS Number is 100. 788 If the ingress is in Area 2, egress in Area 4 and transit through 789 Area 0. Some possible way a PCC can encode the IRO: 791 +---------+ +---------+ +---------+ 792 |IRO | |Sub | |Sub | 793 |Object | |Object | |Object | 794 |Header | |Area 0 | |Area 4 | 795 | | | | | | 796 | | | | | | 797 +---------+ +---------+ +---------+ 799 or 801 +---------+ +---------+ +---------+ +---------+ 802 |IRO | |Sub | |Sub | |Sub | 803 |Object | |Object | |Object | |Object | 804 |Header | |Area 2 | |Area 0 | |Area 4 | 805 | | | | | | | | 806 | | | | | | | | 807 +---------+ +---------+ +---------+ +---------+ 809 or 811 +---------+ +---------+ +---------+ +---------+ +---------+ 812 |IRO | |Sub | |Sub | |Sub | |Sub | 813 |Object | |Object AS| |Object | |Object | |Object | 814 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 815 | | | | | | | | | | 816 | | | | | | | | | | 817 +---------+ +---------+ +---------+ +---------+ +---------+ 819 The Domain-Sequence can further include encompassing AS information 820 in the AS subobject. 822 4.2. Inter-AS Path Computation 824 In inter-AS path computation, where ingress and egress belong to 825 different AS, the Domain-Sequence could be represented using an 826 ordered list of AS subobjects. The Domain-Sequence can further 827 include decomposed area information in the Area subobject. 829 4.2.1. Example 1 831 As shown in Figure 2, where AS has a single area, AS subobject in the 832 domain-sequence can uniquely identify the next domain and PCE. 834 AS A AS E AS C 835 <-------------> <----------> <-------------> 837 A4----------E1---E2---E3---------C4 838 / / \ 839 / / \ 840 / / AS B \ 841 / / <----------> \ 842 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 843 \ / / 844 \ / / 845 \ / / 846 \ / / 847 A3----------D1---D2---D3---------C3 849 <----------> 850 AS D 852 * All AS have one area (area 0) 854 Figure 2: Inter-AS Path Computation 856 If the ingress is in AS A, egress in AS C and transit through AS B. 857 Some possible way a PCC can encode the IRO: 859 +-------+ +-------+ +-------+ 860 |IRO | |Sub | |Sub | 861 |Object | |Object | |Object | 862 |Header | |AS B | |AS C | 863 | | | | | | 864 +-------+ +-------+ +-------+ 866 or 868 +-------+ +-------+ +-------+ +-------+ 869 |IRO | |Sub | |Sub | |Sub | 870 |Object | |Object | |Object | |Object | 871 |Header | |AS A | |AS B | |AS C | 872 | | | | | | | | 873 +-------+ +-------+ +-------+ +-------+ 875 or 877 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 878 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 879 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 880 |Header | |AS A | |Area 0 | |AS B | |Area 0 | |AS C | |Area 0 | 881 | | | | | | | | | | | | | | 882 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 884 Note that to get a domain disjoint path, the ingress could also 885 request the backup path with - 887 +-------+ +-------+ 888 |XRO | |Sub | 889 |Object | |Object | 890 |Header | |AS B | 891 | | | | 892 +-------+ +-------+ 894 As described in Section 3.4.3, domain subobject in IRO changes the 895 domain information associated with the next set of subobjects; till 896 you encounter a subobject that changes the domain too. Consider the 897 following IRO: 899 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 900 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | 901 |Object | |Object | |Object | |Object | |Object | |Object | 902 |Header | |AS B | |IP | |IP | |AS C | |IP | 903 | | | | |B1 | |B3 | | | |C1 | 904 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 905 On processing subobject "AS B", it changes the AS of the subsequent 906 subobjects till we encounter another subobject "AS C" which changes 907 the AS for its subsequent subobjects. 909 Consider another IRO: 911 +-------+ +-------+ +-------+ +-------+ +-------+ 912 |IRO | |Sub | |Sub | |Sub | |Sub | 913 |Object | |Object | |Object | |Object | |Object | 914 |Header | |AS D | |IP | |IP | |IP | 915 | | | | |D1 | |D3 | |C3 | 916 +-------+ +-------+ +-------+ +-------+ +-------+ 918 Here as well, on processing "AS D", it changes the AS of the 919 subsequent subobjects till you encounter another subobject "C3" which 920 belong in another AS and changes the AS for its subsequent 921 subobjects. 923 Further description for the Boundary Node and Inter-AS-Link can be 924 found in Section 4.3. 926 4.2.2. Example 2 928 In Figure 3, AS 200 is made up of multiple areas. 930 | 931 | +-------------+ +----------------+ 932 | |Area 2 | |Area 4 | 933 | | +--+| | +--+ | 934 | | | || | | B| | 935 | | +--+ +--+| | +--+ +--+ | 936 | | | | | | | | | 937 | | +--+ | | +--+ | 938 | | +--+ | | +--+ | 939 | | | | | | | | | 940 | | +--+ | | +--+ +--+ | 941 | | +--+ |+--------------+| | | | 942 | | | | +--+ +--+ +--+ | 943 +-------------+| | +--+ | | | | | 944 | || | +--+ +--+ | 945 | +--+|| +-------------+| |+----------------+ 946 | | ||| | +--+ | 947 | +--+|| | | | | 948 | +--+ || | +--+ | 949 | | | +---+ +--+ | 950 | +--+ | |----------------| | | 951 | +---+ Inter-AS +--+ +--+ | 952 |+--+ || Links | | | | 953 ||A | +---+ +--+ +--+ | 954 |+--+ | |----------------| | | 955 | +---+ +--+ +--+ | 956 | +--+ || +------------+ | | | |+----------------+ 957 | | | || |Area 3 +--+ +--+ +--+ Area 5 | 958 | +--+ || | | | | | | 959 | || | +--+ +--+ | 960 | +--+|| | +--+ | | Area 0 || +--+ | 961 | | ||| | | | | +--------------+| | | | 962 | +--+|| | +--+ | | +--+ | 963 | || | | | +--+ | 964 |Area 0 || | +--+ | | +--+ | | | 965 +-------------+| | | | | | | | +--+ | 966 | | +--+ +--+ | +--+ | 967 | | | | | | 968 | | +--+ | +--+ | 969 | | +--+ | | | C| | 970 | | | | | | +--+ | 971 | | +--+ | | | 972 | | | | | 973 | +------------+ +----------------+ 974 | 975 | 976 AS 100 | AS 200 977 | 979 Figure 3: Inter-AS Path Computation 981 For LSP (A-B), where ingress A is in (AS 100, Area 0), egress B in 982 (AS 200, Area 4) and transit through (AS 200, Area 0). Some possible 983 way a PCC can encode the IRO: 985 +-------+ +-------+ +-------+ +-------+ 986 |IRO | |Sub | |Sub | |Sub | 987 |Object | |Object | |Object | |Object | 988 |Header | |AS 200 | |Area 0 | |Area 4 | 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 4 | 998 | | | | | | | | | | | | 999 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1000 For LSP (A-C), where ingress A is in (AS 100, Area 0), egress C in 1001 (AS 200, Area 5) and transit through (AS 200, Area 0). Some possible 1002 way a PCC can encode the IRO: 1004 +-------+ +-------+ +-------+ +-------+ 1005 |IRO | |Sub | |Sub | |Sub | 1006 |Object | |Object | |Object | |Object | 1007 |Header | |AS 200 | |Area 0 | |Area 5 | 1008 | | | | | | | | 1009 +-------+ +-------+ +-------+ +-------+ 1011 or 1013 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1014 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | 1015 |Object | |Object | |Object | |Object | |Object | |Object | 1016 |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 5 | 1017 | | | | | | | | | | | | 1018 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 1020 4.3. Boundary Node and Inter-AS-Link 1022 A PCC or PCE can include additional constraints covering which 1023 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) to be 1024 traversed while defining a Domain-Sequence. In which case the 1025 Boundary Node or Link can be encoded as a part of the Domain- 1026 Sequence. 1028 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 1029 prefix subobjects usually the loopback address of 32 and 128 prefix 1030 length respectively. An Inter-AS link can be encoded using the IPv4 1031 or IPv6 prefix subobjects or unnumbered interface subobjects. 1033 For Figure 1, an ABR (say 203.0.113.1) to be traversed can be 1034 specified in IRO as: 1036 +---------+ +---------+ +---------++---------+ +---------+ 1037 |IRO | |Sub | |Sub ||Sub | |Sub | 1038 |Object | |Object | |Object ||Object | |Object | 1039 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 1040 | | | | |203.0. || | | | 1041 | | | | |112.1 || | | | 1042 +---------+ +---------+ +---------++---------+ +---------+ 1044 For Figure 3, an inter-AS-link (say 198.51.100.1 - 198.51.100.2) to 1045 be traversed can be specified as: 1047 +---------+ +---------+ +---------+ +---------+ 1048 |IRO | |Sub | |Sub | |Sub | 1049 |Object | |Object AS| |Object | |Object AS| 1050 |Header | |100 | |IPv4 | |200 | 1051 | | | | |198.51. | | | 1052 | | | | |100.2 | | | 1053 +---------+ +---------+ +---------+ +---------+ 1055 4.4. PCE Serving multiple Domains 1057 A single PCE can be responsible for multiple domains; for example PCE 1058 function deployed on an ABR could be responsible for multiple areas. 1059 A PCE which can support adjacent domains can internally handle those 1060 domains in the Domain-Sequence without any impact on the other 1061 domains in the Domain-Sequence. 1063 4.5. P2MP 1065 [RFC7334] describes an experimental inter-domain P2MP path 1066 computation mechanism where the path domain tree is described as a 1067 series of Domain-Sequences, an example is shown in the below figure: 1069 +----------------+ 1070 | |Domain D1 1071 | R | 1072 | | 1073 | A | 1074 | | 1075 +-B------------C-+ 1076 / \ 1077 / \ 1078 / \ 1079 Domain D2 / \ Domain D3 1080 +-------------D--+ +-----E----------+ 1081 | | | | 1082 | F | | | 1083 | G | | H | 1084 | | | | 1085 | | | | 1086 +-I--------------+ +-J------------K-+ 1087 /\ / \ 1088 / \ / \ 1089 / \ / \ 1090 / \ / \ 1091 / \ / \ 1092 / \ / \ 1093 / Domain D4 \ Domain D5 / Domain D6 \ 1094 +-L-------------W+ +------P---------+ +-----------T----+ 1095 | | | | | | 1096 | | | Q | | U | 1097 | M O | | S | | | 1098 | | | | | V | 1099 | N | | R | | | 1100 +----------------+ +----------------+ +----------------+ 1102 The domain tree can be represented as a series of domain-sequence - 1104 o Domain D1, Domain D3, Domain D6 1106 o Domain D1, Domain D3, Domain D5 1108 o Domain D1, Domain D2, Domain D4 1110 The domain sequence handling described in this document could be 1111 applied to P2MP path domain tree. 1113 4.6. Hierarchical PCE 1115 In case of H-PCE [RFC6805], the parent PCE can be requested to 1116 determine the Domain-Sequence and return it in the path computation 1117 reply, using the ERO. . For the example in section 4.6 of [RFC6805], 1118 the Domain-Sequence can possibly appear as: 1120 +---------+ +---------+ +---------+ +---------+ 1121 |ERO | |Sub | |Sub | |Sub | 1122 |Object | |Object | |Object | |Object | 1123 |Header | |Domain 1 | |Domain 2 | |Domain 3 | 1124 | | | | | | | | 1125 | | | | | | | | 1126 +---------+ +---------+ +---------+ +---------+ 1128 or 1130 +---------+ +---------+ +---------+ 1131 |ERO | |Sub | |Sub | 1132 |Object | |Object | |Object | 1133 |Header | |BN 21 | |Domain 3 | 1134 | | | | | | 1135 | | | | | | 1136 +---------+ +---------+ +---------+ 1138 5. Other Considerations 1140 5.1. Relationship to PCE Sequence 1142 Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by 1143 policy on the PCC, and this constraint can be carried in the PCReq 1144 message (as defined in [RFC5886]). 1146 Note that PCE-Sequence can be used along with Domain-Sequence in 1147 which case PCE-Sequence MUST have higher precedence in selecting the 1148 next PCE in the inter-domain path computation procedures. 1150 5.2. Relationship to RSVP-TE 1152 [RFC3209] already describes the notion of abstract nodes, where an 1153 abstract node is a group of nodes whose internal topology is opaque 1154 to the ingress node of the LSP. It further defines a subobject for 1155 AS but with a 2-Byte AS Number. 1157 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1158 subobjects for IGP Areas and 4-byte AS numbers. These subobjects can 1159 be included in Explicit Route Object (ERO), Exclude Route object 1160 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1162 In any case subobject type defined in RSVP-TE are identical to the 1163 subobject type defined in the related documents in PCEP. 1165 6. IANA Considerations 1167 6.1. New Subobjects 1169 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 1170 at . Within this registry IANA 1171 maintains two sub-registries: 1173 o IRO Subobjects (see IRO Subobjects at 1174 http://www.iana.org/assignments/pcep) 1176 o XRO Subobjects (see XRO Subobjects at 1177 http://www.iana.org/assignments/pcep) 1179 Upon approval of this document, IANA is requested to make identical 1180 additions to these registries as follows: 1182 Subobject Type Reference 1183 TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ] 1184 TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ] 1185 TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ] 1187 Further upon approval of this document, IANA is requested to add a 1188 reference to this document to the new RSVP numbers that are 1189 registered by [DOMAIN-SUBOBJ]. 1191 7. Security Considerations 1193 The protocol extensions defined in this document do not substantially 1194 change the nature of PCEP. Therefore, the security considerations 1195 set out in [RFC5440] apply unchanged. Note that further security 1196 considerations for the use of PCEP over TCP are presented in 1197 [RFC6952]. 1199 This document specifies a representation of Domain-Sequence and new 1200 subobjects, which could be used in inter-domain PCE scenarios as 1201 explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334] etc. The 1202 security considerations set out in each of these mechanisms remain 1203 unchanged by the new subobjects and Domain-Sequence representation in 1204 this document. 1206 But the new subobjects do allow finer and more specific control of 1207 the path computed by a cooperating PCE(s). Such control increases 1208 the risk if a PCEP message is intercepted, modified, or spoofed 1209 because it allows the attacker to exert control over the path that 1210 the PCE will compute or to make the path computation impossible. 1211 Consequently, it is important that implementations conform to the 1212 relevant security requirements of [RFC5440]. These mechanisms 1213 include: 1215 o Securing the PCEP session messages using TCP security techniques 1216 (Section 10.2 of [RFC5440]). PCEP implementations SHOULD also 1217 consider the additional security provided by the TCP 1218 Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. 1220 o Authenticating the PCEP messages to ensure the message is intact 1221 and sent from an authorized node (Section 10.3 of [RFC5440]). 1223 o PCEP operates over TCP, so it is also important to secure the PCE 1224 and PCC against TCP denial-of-service attacks. Section 10.7.1 of 1225 [RFC5440] outlines a number of mechanisms for minimizing the risk 1226 of TCP-based denial-of-service attacks against PCEs and PCCs. 1228 o In inter-AS scenarios, attacks may be particularly significant 1229 with commercial as well as service-level implications. 1231 Note, however, that the Domain-Sequence mechanisms also provide the 1232 operator with the ability to route around vulnerable parts of the 1233 network and may be used to increase overall network security. 1235 8. Manageability Considerations 1237 8.1. Control of Function and Policy 1239 The exact behaviour with regards to desired inclusion and exclusion 1240 of domains MUST be available for examination by an operator and MAY 1241 be configurable. Manual configurations is needed to identify which 1242 PCEP peers understand the new domain subobjects defined in this 1243 document. 1245 8.2. Information and Data Models 1247 A MIB module for management of the PCEP is being specified in a 1248 separate document [RFC7420]. This document does not imply any new 1249 extension to the current MIB module. 1251 8.3. Liveness Detection and Monitoring 1253 Mechanisms defined in this document do not imply any new liveness 1254 detection and monitoring requirements in addition to those already 1255 listed in [RFC5440]. 1257 8.4. Verify Correct Operations 1259 Mechanisms defined in this document do not imply any new operation 1260 verification requirements in addition to those already listed in 1261 [RFC5440]. 1263 8.5. Requirements On Other Protocols 1265 In case of per-domain path computation [RFC5152], where the full path 1266 of an inter-domain TE LSP cannot be, or is not determined at the 1267 ingress node, a signaling message can use the domain identifiers. 1268 The Subobjects defined in this document SHOULD be supported by RSVP- 1269 TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding 1270 new subobjects for IGP Areas and 4-byte AS numbers. 1272 Apart from this, mechanisms defined in this document do not imply any 1273 requirements on other protocols in addition to those already listed 1274 in [RFC5440]. 1276 8.6. Impact On Network Operations 1278 The mechanisms described in this document can provide the operator 1279 with the ability to exert finer and more specific control of the path 1280 computation by inclusion or exclusion of domain subobjects. There 1281 may be some scaling benefit when a single domain subobject may 1282 substitute for many subobjects and can reduce the overall message 1283 size and processing. 1285 Backward compatibility issues associated with the new subobjects 1286 arise when a PCE does not recognize them, in which case PCE responds 1287 according to the rules for a malformed object as per [RFC5440]. For 1288 successful operations the PCEs in the network would need to be 1289 upgraded. 1291 9. Acknowledgments 1293 Authors would like to especially thank Adrian Farrel for his detailed 1294 reviews as well as providing text to be included in the document. 1296 Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin 1297 Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1298 Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti 1299 and Jonathan Hardwick for their useful comments and suggestions. 1301 Thanks to Jonathan Hardwick for shepherding this document. 1303 Thanks to Deborah Brungard for being the Responsible AD. 1305 Thanks to Amanda Baber for IANA Review. 1307 Thanks to Joel Halpern for Gen-ART Review. 1309 Thanks to Klaas Wierenga for SecDir Review. 1311 Thanks to Spencer Dawkins and Barry Leiba for comments during the 1312 IESG Review. 1314 10. References 1316 10.1. Normative References 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, 1320 DOI 10.17487/RFC2119, March 1997, 1321 . 1323 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1324 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1325 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1326 . 1328 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1329 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1330 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1331 DOI 10.17487/RFC3473, January 2003, 1332 . 1334 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1335 in Resource ReSerVation Protocol - Traffic Engineering 1336 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1337 . 1339 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1340 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1341 DOI 10.17487/RFC5440, March 2009, 1342 . 1344 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1345 "A Backward-Recursive PCE-Based Computation (BRPC) 1346 Procedure to Compute Shortest Constrained Inter-Domain 1347 Traffic Engineering Label Switched Paths", RFC 5441, 1348 DOI 10.17487/RFC5441, April 2009, 1349 . 1351 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1352 Path Computation Element Communication Protocol (PCEP) for 1353 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 1354 2009, . 1356 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1357 Path Computation Element Architecture to the Determination 1358 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1359 DOI 10.17487/RFC6805, November 2012, 1360 . 1362 [ISO10589] 1363 ISO, "Intermediate system to Intermediate system routing 1364 information exchange protocol for use in conjunction with 1365 the Protocol for providing the Connectionless-mode Network 1366 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1368 [IRO-UPDATE] 1369 Dhody, D., "Update to Include Route Object (IRO) 1370 specification in Path Computation Element communication 1371 Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015. 1373 [DOMAIN-SUBOBJ] 1374 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1375 "Domain Subobjects for Resource ReserVation Protocol - 1376 Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- 1377 domain-subobjects-05)", November 2015. 1379 10.2. Informative References 1381 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1382 Element (PCE)-Based Architecture", RFC 4655, 1383 DOI 10.17487/RFC4655, August 2006, 1384 . 1386 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1387 Inter-Domain Multiprotocol Label Switching Traffic 1388 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 1389 2006, . 1391 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1392 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1393 May 2007, . 1395 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1396 Extension to Resource ReserVation Protocol-Traffic 1397 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 1398 April 2007, . 1400 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1401 Per-Domain Path Computation Method for Establishing Inter- 1402 Domain Traffic Engineering (TE) Label Switched Paths 1403 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 1404 . 1406 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1407 "Preserving Topology Confidentiality in Inter-Domain Path 1408 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1409 DOI 10.17487/RFC5520, April 2009, 1410 . 1412 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 1413 Monitoring Tools for Path Computation Element (PCE)-Based 1414 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 1415 . 1417 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1418 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1419 June 2010, . 1421 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1422 Autonomous System (AS) Number Space", RFC 6793, 1423 DOI 10.17487/RFC6793, December 2012, 1424 . 1426 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1427 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1428 and Authentication for Routing Protocols (KARP) Design 1429 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1430 . 1432 [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, 1433 "PCE-Based Computation Procedure to Compute Shortest 1434 Constrained Point-to-Multipoint (P2MP) Inter-Domain 1435 Traffic Engineering Label Switched Paths", RFC 7334, 1436 DOI 10.17487/RFC7334, August 2014, 1437 . 1439 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1440 Hardwick, "Path Computation Element Communication Protocol 1441 (PCEP) Management Information Base (MIB) Module", 1442 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1443 . 1445 [PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1446 Transport for PCEP", draft-ietf-pce-pceps-06 (work in 1447 progress), November 2015. 1449 Authors' Addresses 1451 Dhruv Dhody 1452 Huawei Technologies 1453 Divyashree Techno Park, Whitefield 1454 Bangalore, Karnataka 560037 1455 India 1457 EMail: dhruv.ietf@gmail.com 1459 Udayasree Palle 1460 Huawei Technologies 1461 Divyashree Techno Park, Whitefield 1462 Bangalore, Karnataka 560037 1463 India 1465 EMail: udayasree.palle@huawei.com 1467 Ramon Casellas 1468 CTTC 1469 Av. Carl Friedrich Gauss n7 1470 Castelldefels, Barcelona 08860 1471 Spain 1473 EMail: ramon.casellas@cttc.es