idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-07.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 30, 2014) is 3405 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-teas-rsvp-te-domain-subobjects-00 Summary: 0 errors (**), 0 flaws (~~), 2 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: July 3, 2015 R. Casellas 6 CTTC 7 December 30, 2014 9 Standard Representation of Domain-Sequence 10 draft-ietf-pce-pcep-domain-sequence-07 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 July 3, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Standard Representation . . . . . . . . . . . . . . . . . 6 70 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 71 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 7 72 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 73 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 8 74 3.4.2. Update in IRO specification . . . . . . . . . . . . . 9 75 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 76 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 11 77 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 78 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 12 79 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 80 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14 81 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 14 82 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 15 83 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 15 84 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 17 85 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 86 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 19 87 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 21 88 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 21 89 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 22 91 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . 24 92 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 24 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 25 95 5.2. Error Object Field Values . . . . . . . . . . . . . . . . 25 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 7. Manageability Considerations . . . . . . . . . . . . . . . . 26 98 7.1. Control of Function and Policy . . . . . . . . . . . . . 26 99 7.2. Information and Data Models . . . . . . . . . . . . . . . 26 100 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26 101 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26 102 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 26 103 7.6. Impact On Network Operations . . . . . . . . . . . . . . 27 104 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 107 9.2. Informative References . . . . . . . . . . . . . . . . . 27 109 1. Introduction 111 A PCE may be used to compute end-to-end paths across multi-domain 112 environments using a per-domain path computation technique [RFC5152]. 113 The backward recursive path computation (BRPC) mechanism [RFC5441] 114 also defines a PCE-based path computation procedure to compute inter- 115 domain constrained path for (G)MPLS TE LSPs. However, both per- 116 domain and BRPC techniques assume that the sequence of domains to be 117 crossed from source to destination is known, either fixed by the 118 network operator or obtained by other means. Also for inter-domain 119 point-to-multi-point (P2MP) tree computation, [RFC7334] assumes the 120 domain-tree is known in priori. 122 The list of domains (Domain-Sequence) in point-to-point (P2P) or a 123 domain tree in point-to-multipoint (P2MP) is usually a constraint in 124 inter-domain path computation procedure. A PCE determines the next 125 PCE to forward the request based on the Domain-Sequence. In a multi- 126 domain path computation, a Path Computation Client (PCC) MAY indicate 127 the sequence of domains to be traversed using the Include Route 128 Object (IRO) defined in [RFC5440]. 130 When the sequence of domains is not known in advance, the 131 Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be 132 used to determine the Domain-Sequence. 134 This document defines a standard way to represent and encode a 135 Domain-Sequence in various scenarios including P2P LSP, P2MP LSP, and 136 use of H-PCE. 138 The Domain-Sequence (the set of domains traversed to reach the 139 destination domain) is either administratively predetermined or 140 discovered by some means like H-PCE. 142 [RFC5440] defines the Include Route Object (IRO) and the Explicit 143 Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) 144 and the Explicit Exclusion Route Subobject (EXRS). The use of 145 Autonomous System (AS) (albeit with a 2-Byte AS number) as an 146 abstract node representing a domain is defined in [RFC3209], this 147 document specifies new subobjects to include or exclude domains 148 including IGP area or an Autonomous Systems (4-Byte as per 149 [RFC6793]). 151 Further, the domain identifier may simply act as delimiter to specify 152 where the domain boundary starts and ends in some cases. 154 This is a companion document to Resource ReserVation Protocol - 155 Traffic Engineering (RSVP-TE) extensions for the domain identifiers 156 [DOMAIN-SUBOBJ]. 158 1.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2. Terminology 166 The following terminology is used in this document. 168 ABR: OSPF Area Border Router. Routers used to connect two IGP 169 areas. 171 AS: Autonomous System. 173 ASBR: Autonomous System Boundary Router. 175 BN: Boundary Node, Can be an ABR or ASBR. 177 BRPC: Backward Recursive Path Computation 179 Domain: As per [RFC4655], any collection of network elements within 180 a common sphere of address management or path computational 181 responsibility. Examples of domains include Interior Gateway 182 Protocol (IGP) area and Autonomous System (AS). 184 Domain-Sequence: An ordered sequence of domains traversed to reach 185 the destination domain. 187 ERO: Explicit Route Object 189 H-PCE: Hierarchical PCE 190 IGP: Interior Gateway Protocol. Either of the two routing 191 protocols, Open Shortest Path First (OSPF) or Intermediate System 192 to Intermediate System (IS-IS). 194 IRO: Include Route Object 196 IS-IS: Intermediate System to Intermediate System. 198 OSPF: Open Shortest Path First. 200 PCC: Path Computation Client: any client application requesting a 201 path computation to be performed by a Path Computation Element. 203 PCE: Path Computation Element. An entity (component, application, 204 or network node) that is capable of computing a network path or 205 route based on a network graph and applying computational 206 constraints. 208 P2MP: Point-to-Multipoint 210 P2P: Point-to-Point 212 RSVP: Resource Reservation Protocol 214 TE LSP: Traffic Engineering Label Switched Path. 216 XRO: Exclude Route Object 218 3. Detail Description 220 3.1. Domains 222 [RFC4726] and [RFC4655] define domain as a separate administrative or 223 geographic environment within the network. A domain may be further 224 defined as a zone of routing or computational ability. Under these 225 definitions a domain might be categorized as an AS or an IGP area. 226 Each AS can be made of several IGP areas. In order to encode a 227 Domain-Sequence, it is required to uniquely identify a domain in the 228 Domain-Sequence. A domain can be uniquely identified by area-id or 229 AS number or both. 231 3.2. Domain-Sequence 233 A Domain-Sequence is an ordered sequence of domains traversed to 234 reach the destination domain. 236 A Domain-Sequence can be applied as a constraint and carried in a 237 path computation request to PCE(s). A Domain-Sequence can also be 238 the result of a path computation. For example, in the case of H-PCE 239 [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a 240 path computation reply. 242 In a P2P path, the domains listed appear in the order that they are 243 crossed. In a P2MP path, the domain tree is represented as a list of 244 Domain-Sequences. 246 A Domain-Sequence enables a PCE to select the next domain and the PCE 247 serving that domain to forward the path computation request based on 248 the domain information. 250 A PCC or PCE MAY add an additional constraint covering which Boundary 251 Nodes (ABR or ASBR) or Border links (Inter-AS-links) MUST be 252 traversed while defining a Domain-Sequence. 254 Thus a Domain-Sequence MAY be made up of one or more of - 256 o AS Number 258 o Area ID 260 o Boundary Node ID 262 o Inter-AS-Link Address 264 Consequently, a Domain-Sequence can be used: 266 1. by a PCE in order to discover or select the next PCE in a 267 collaborative path computation, such as in BRPC [RFC5441]; 269 2. by the Parent PCE to return the Domain-Sequence when unknown; 270 this can then be an input to the BRPC procedure [RFC6805]; 272 3. by a PCC (or PCE) to constraint the domains used in a H-PCE path 273 computation, explicitly specifying which domains to be expanded; 275 4. by a PCE in the per-domain path computation model [RFC5152] to 276 identify the next domain; 278 3.3. Standard Representation 280 Domain-Sequence MAY appear in PCEP messages, notably in - 282 o Include Route Object (IRO): As per [RFC5440], used to specify set 283 of network elements that MUST be traversed. The subobjects in IRO 284 are used to specify the Domain-Sequence that MUST be traversed to 285 reach the destination. 287 o Exclude Route Object (XRO): As per [RFC5521], used to specify 288 certain abstract nodes that MUST be excluded from whole path. The 289 subobjects in XRO are used to specify certain domains that MUST be 290 avoided to reach the destination. 292 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used 293 to specify exclusion of certain abstract nodes between a specific 294 pair of nodes. EXRS are a subobject inside the IRO. These 295 subobjects are used to specify the domains that must be excluded 296 between two abstract nodes. 298 o Explicit Route Object (ERO): As per [RFC5440], used to specify a 299 computed path in the network. For example, in the case of H-PCE 300 [RFC6805], a Parent PCE MAY send the Domain-Sequence as a result 301 in a path computation reply using ERO. 303 3.4. Include Route Object (IRO) 305 As per [RFC5440], IRO (Include Route Object) can be used to specify 306 that the computed path MUST traverse a set of specified network 307 elements or abstract nodes. 309 3.4.1. Subobjects 311 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 312 [RFC4874], but new subobjects related to Domain-Sequence are needed. 314 The following subobject types are used in IRO. 316 Type Subobject 317 1 IPv4 prefix 318 2 IPv6 prefix 319 4 Unnumbered Interface ID 320 32 Autonomous system number (2 Byte) 321 33 Explicit Exclusion (EXRS) 323 This document extends the above list to support 4-Byte AS numbers and 324 IGP Areas. 326 Type Subobject 327 TBD1 Autonomous system number (4 Byte) 328 TBD2 OSPF Area id 329 TBD3 ISIS Area id 331 3.4.1.1. Autonomous system 333 [RFC3209] already defines 2 byte AS number. 335 To support 4 byte AS number as per [RFC6793] following subobject is 336 defined: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |L| Type | Length | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | AS-ID (4 bytes) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 L: The L bit is an attribute of the subobject as defined in [RFC3209] 347 and usage in IRO subobject updated in [IRO-UPDATE]. 349 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 351 Length: 8 (Total length of the subobject in bytes). 353 Reserved: Zero at transmission, ignored at receipt. 355 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 356 use, the low order bits (16 through 31) should be used and the 357 high order bits (0 through 15) should be set to zero. 359 3.4.1.2. IGP Area 361 Since the length and format of Area-id is different for OSPF and 362 ISIS, following two subobjects are defined: 364 For OSPF, the area-id is a 32 bit number. The subobject is encoded 365 as follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |L| Type | Length | Reserved | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | OSPF Area Id (4 bytes) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 L: The L bit is an attribute of the subobject as defined in [RFC3209] 376 and usage in IRO subobject updated in [IRO-UPDATE]. 378 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 380 Length: 8 (Total length of the subobject in bytes). 382 Reserved: Zero at transmission, ignored at receipt. 384 OSPF Area Id: The 4-Byte OSPF Area ID. 386 For IS-IS, the area-id is of variable length and thus the length of 387 the Subobject is variable. The Area-id is as described in IS-IS by 388 ISO standard [ISO10589]. The subobject is encoded as follows: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |L| Type | Length | Area-Len | Reserved | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 // IS-IS Area ID // 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 L: The L bit is an attribute of the subobject as defined in [RFC3209] 401 and usage in IRO subobject updated in [IRO-UPDATE]. 403 Type: (TBD3 by IANA) indicating IS-IS Area ID. 405 Length: Variable. As per [RFC3209], the total length of the 406 subobject in bytes, including the L, Type and Length fields. The 407 Length MUST be at least 4, and MUST be a multiple of 4. 409 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 410 Identifier in octets; Valid values are from 2 to 11 inclusive). 412 Reserved: Zero at transmission, ignored at receipt. 414 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 415 with trailing zeroes to a four-byte boundary. 417 3.4.2. Update in IRO specification 419 [RFC5440] describes IRO as an optional object used to specify that 420 the computed path MUST traverse a set of specified network elements. 421 It further state that the L bit of such subobject has no meaning 422 within an IRO. It did not mention if IRO is an ordered or un-ordered 423 list of subobjects. 425 An update to IRO specification [IRO-UPDATE] makes IRO as an ordered 426 list as well as support for loose bit (L-bit). 428 The use IRO for Domain-Sequence assumes the updated specification for 429 IRO as per [IRO-UPDATE]. 431 3.4.3. IRO for Domain-Sequence 433 Some subobjects for the IRO are defined in [RFC3209], [RFC3473], 434 [RFC3477], and [RFC4874]; further some new subobjects related to 435 Domain-Sequence are also added in this document as mentioned in 436 Section 3.4. 438 The subobject type for IPv4, IPv6, and unnumbered Interface ID can be 439 used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The 440 subobject type for the AS Number (2 or 4 Byte) and the IGP Area are 441 used to specify the domain identifiers in the Domain-Sequence. 443 The IRO MAY have both intra-domain (from the context of the ingress 444 PCC) and inter-domain (Domain-Sequence) subobjects in a sequence in 445 which they must be traversed in the computed path. 447 Thus an IRO, comprising of subobjects that represents a Domain- 448 Sequence, define the domains involved in an inter-domain path 449 computation, typically involving two or more collaborative PCEs. 451 A Domain-Sequence can have varying degrees of granularity. It is 452 possible to have a Domain-Sequence composed of, uniquely, AS 453 identifiers. It is also possible to list the involved IGP areas for 454 a given AS. 456 In any case, the mapping between domains and responsible PCEs is not 457 defined in this document. It is assumed that a PCE that needs to 458 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 459 administrative configuration, or discovery). 461 A PCC builds an IRO to encode the Domain-Sequence, so that the 462 cooperating PCEs should compute an inter-domain shortest constrained 463 path across the specified sequence of domains. 465 For each inclusion, the PCC clears the L-bit to indicate that the PCE 466 is required to include the domain, or sets the L-bit to indicate that 467 the PCC simply desires that the domain be included in the Domain- 468 Sequence. 470 If a PCE encounters a subobject that it does not support or 471 recognize, it MUST act according to the setting of the L-bit in the 472 subobject. If the L-bit is clear, the PCE MUST respond with a PCErr 473 with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value 474 to the subobject type code. If the L-bit is set, the PCE MAY respond 475 with a PCErr as already stated or MAY ignore the subobject: this 476 choice is a local policy decision. 478 PCE MUST act according to the requirements expressed in the 479 subobject. That is, if the L-bit is clear, the PCE(s) MUST produce a 480 path that follows the Domain-Sequence in order identified by the 481 subobjects in the path. If the L-bit is set, the PCE(s) SHOULD 482 produce a path along the Domain-Sequence unless it is not possible to 483 construct a path complying with the other constraints expressed in 484 the request. 486 A successful path computation reported in a path computation reply 487 message (PCRep) MUST include an ERO to specify the path that has been 488 computed as specified in [RFC5440] following the sequence of domains. 490 In a PCRep, PCE MAY also supply IRO (with Domain-Sequence 491 information) with the NO-PATH object indicating that the set of 492 elements (domains) of the request's IRO prevented the PCEs from 493 finding a path. 495 Selection of the next domain and the PCE serving that domain is 496 dependent on the domain subobjects (AS and IGP area) in the IRO. 498 Note that a particular domain in the Domain-Sequence can be 499 identified by :- 501 o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is 502 used to identify the next domain. (Refer Figure 1) 504 o A single AS: Only the AS subobject is used to identify the next 505 domain. (Refer Figure 2) 507 o Both an AS and an IGP Area: AS and Area in combination are used to 508 identify the next domain. In this case the order is AS Subobject 509 followed by Area. (Refer Figure 3) 511 The Subobjects representing an internal node, a Boundary Node or an 512 Inter-AS-Link MAY also influence the selection of the path. 514 3.5. Exclude Route Object (XRO) 516 The Exclude Route Object (XRO) [RFC5521] is an optional object used 517 to specify exclusion of certain abstract nodes or resources from the 518 whole path. 520 3.5.1. Subobjects 522 The following subobject types are defined to be used in XRO as 523 defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. 525 Type Subobject 526 1 IPv4 prefix 527 2 IPv6 prefix 528 4 Unnumbered Interface ID 529 32 Autonomous system number (2 Byte) 530 34 SRLG 531 64 IPv4 Path Key 532 65 IPv6 Path Key 534 This document extends the above list to support 4-Byte AS numbers and 535 IGP Areas. 537 Type Subobject 538 TBD1 Autonomous system number (4 Byte) 539 TBD2 OSPF Area id 540 TBD3 ISIS Area id 542 3.5.1.1. Autonomous system 544 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 545 MAY also be used in the XRO to specify exclusion of certain domains 546 in the path computation procedure. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |X| Type | Length | Reserved | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | AS-ID (4 bytes) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 The X-bit indicates whether the exclusion is mandatory or desired. 558 0: indicates that the AS specified MUST be excluded from the path 559 computed by the PCE(s). 561 1: indicates that the AS specified SHOULD be avoided from the inter- 562 domain path computed by the PCE(s), but MAY be included subject to 563 PCE policy and the absence of a viable path that meets the other 564 constraints. 566 All other fields are consistent with the definition in Section 3.4. 568 3.5.1.2. IGP Area 570 Since the length and format of Area-id is different for OSPF and 571 ISIS, following two subobjects are defined: 573 For OSPF, the area-id is a 32 bit number. The subobject is encoded 574 as follows: 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |X| Type | Length | Reserved | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | OSPF Area Id (4 bytes) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 The X-bit indicates whether the exclusion is mandatory or desired. 586 0: indicates that the OSFF Area specified MUST be excluded from the 587 path computed by the PCE(s). 589 1: indicates that the OSFF Area specified SHOULD be avoided from the 590 inter-domain path computed by the PCE(s), but MAY be included 591 subject to PCE policy and the absence of a viable path that meets 592 the other constraints. 594 All other fields are consistent with the definition in Section 3.4. 596 For IS-IS, the area-id is of variable length and thus the length of 597 the subobject is variable. The Area-id is as described in IS-IS by 598 ISO standard [ISO10589]. The subobject is encoded as follows: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |X| Type | Length | Area-Len | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 // IS-IS Area ID // 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 The X-bit indicates whether the exclusion is mandatory or desired. 612 0: indicates that the ISIS Area specified MUST be excluded from the 613 path computed by the PCE(s). 615 1: indicates that the ISIS Area specified SHOULD be avoided from the 616 inter-domain path computed by the PCE(s), but MAY be included 617 subject to PCE policy and the absence of a viable path that meets 618 the other constraints. 620 All other fields are consistent with the definition in Section 3.4. 622 If a PCE that supports XRO and encounters a subobject that it does 623 not support or recognize, it MUST act according to the setting of the 624 X-bit in the subobject. If the X-bit is clear, the PCE MUST respond 625 with a PCErr with Error-Type TBD4 "Unrecognized subobject" and set 626 the Error-Value to the subobject type code. If the X-bit is set, the 627 PCE MAY respond with a PCErr as already stated or MAY ignore the 628 subobject: this choice is a local policy decision. 630 All the other processing rules are as per [RFC5521]. 632 3.6. Explicit Exclusion Route Subobject (EXRS) 634 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 635 specify exclusion of certain abstract nodes between a specific pair 636 of nodes. 638 The EXRS subobject may carry any of the subobjects defined for 639 inclusion in the XRO, thus the new subobjects to support 4 byte AS 640 and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The 641 meanings of the fields of the new XRO subobjects are unchanged when 642 the subobjects are included in an EXRS, except that scope of the 643 exclusion is limited to the single hop between the previous and 644 subsequent elements in the IRO. 646 All the processing rules are as per [RFC5521]. 648 3.7. Explicit Route Object (ERO) 650 The Explicit Route Object (ERO) [RFC5440] is used to specify a 651 computed path in the network. PCEP ERO subobject types correspond to 652 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 653 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. 655 Type Subobject 656 1 IPv4 prefix 657 2 IPv6 prefix 658 3 Label 659 4 Unnumbered Interface ID 660 32 Autonomous system number (2 Byte) 661 33 Explicit Exclusion (EXRS) 662 37 Protection 663 64 IPv4 Path Key 664 65 IPv6 Path Key 666 This document extends the above list to support 4-Byte AS numbers and 667 IGP Areas. 669 Type Subobject 670 TBD1 Autonomous system number (4 Byte) 671 TBD2 OSPF Area id 672 TBD3 ISIS Area id 674 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 675 MAY also be used in the ERO to specify an abstract node (a group of 676 nodes whose internal topology is opaque to the ingress node of the 677 LSP). Using this concept of abstraction, an explicitly routed LSP 678 can be specified as a sequence of domains. 680 In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested 681 to find the Domain-Sequence. Refer example in Section 4.6. 683 The format of the new ERO subobjects is similar to new IRO 684 subobjects, refer Section 3.4. 686 4. Other Considerations 688 The examples in this section are for illustration purposes only; to 689 highlight how the new subobjects may be encoded. 691 4.1. Inter-Area Path Computation 693 In an inter-area path computation where the ingress and the egress 694 nodes belong to different IGP areas within the same AS, the Domain- 695 Sequence MAY be represented using a ordered list of Area subobjects. 696 The AS number MAY be skipped, as area information is enough to select 697 the next PCE. 699 +-------------------+ +-------------------+ 700 | | | | 701 | +--+ | | +--+ | 702 | +--+ | | | | | | | 703 | | | +--+ | | +--+ +--+ | 704 | +--* + + | | | 705 | | | +--+ | 706 | *--+ + + | 707 | | | | | +--+ | 708 | +--+ | | | | | 709 | |+--------------------------+| +--+ | 710 | ++++ +-++ | 711 | |||| +--+ | || | 712 | Area 2 ++++ | | +-++ Area 4 | 713 +-------------------+| +--+ |+-------------------+ 714 | | 715 | +--+ | 716 | +--+ | | | 717 | | | +--+ | 718 | +--+ | 719 | | 720 | | 721 | | 722 | | 723 | +--+ | 724 | | | | 725 | +--+ | 726 +------------------+| |+--------------------+ 727 | ++-+ +-++ | 728 | || | | || | 729 | ++-+ Area 0 +-++ | 730 | |+--------------------------+| +--+ | 731 | +--+ | | | | | 732 | | | | | +--+ | 733 | +--+ +--+ | | | 734 | | | + + +--+ | 735 | +--+ | | | | | 736 | + + +--+ | 737 | +--+ | | | 738 | | | | | +--+ | 739 | +--+ | | | | | 740 | | | +--+ | 741 | | | | 742 | Area 1 | | Area 5 | 743 +------------------+ +--------------------+ 745 Figure 1: Inter-Area Path Computation 747 AS Number is 100. 749 This could be represented in the as: 751 +---------+ +---------+ +---------+ +---------+ 752 |IRO | |Sub | |Sub | |Sub | 753 |Object | |Object | |Object | |Object | 754 |Header | |Area 2 | |Area 0 | |Area 4 | 755 | | | | | | | | 756 | | | | | | | | 757 +---------+ +---------+ +---------+ +---------+ 759 +---------+ +---------+ +---------+ +---------+ +---------+ 760 |IRO | |Sub | |Sub | |Sub | |Sub | 761 |Object | |Object AS| |Object | |Object | |Object | 762 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 763 | | | | | | | | | | 764 | | | | | | | | | | 765 +---------+ +---------+ +---------+ +---------+ +---------+ 767 AS is optional and it MAY be skipped. PCE should be able to 768 understand both notations. 770 4.2. Inter-AS Path Computation 772 In inter-AS path computation, where ingress and egress belong to 773 different AS, the Domain-Sequence is represented using an ordered 774 list of AS subobjects. The Domain-Sequence MAY further include 775 decomposed area information in Area subobjects. 777 4.2.1. Example 1 779 As shown in Figure 2, where AS to be made of a single area, the area 780 subobject MAY be skipped in the Domain-Sequence as AS is enough to 781 uniquely identify the next domain and PCE. 783 +---------------------------------+ 784 |AS 200 | 785 | +------+ | 786 | | | | 787 +------------------------+ | | | +------+ | 788 | AS 100 | | +------+ | | | 789 | +------+ | | +------+ | | | 790 | | +-+-----+-+ | +------+ | 791 | | | | | | | | 792 | +------+ | | +------+ | 793 | +------+ | | +------+ | 794 | | | | | | | | 795 | | | | | | | | 796 | +------+ | | +------+ | 797 | | | | 798 | +------+ | | +------+ | 799 | | +-+-----+-+ | +------+ | 800 | | | | | | | | | | 801 | +------+ | | +------+ | | | 802 | | | +------+ | 803 | | | | 804 | | | | 805 | +------+ | | +------+ | 806 | | | | | | | | 807 | |PCE | | | |PCE | | 808 | +------+ | | +------+ | 809 | | | | 810 +------------------------+ | | 811 +---------------------------------+ 813 Figure 2: Inter-AS Path Computation 815 Both AS are made of Area 0. 817 This could be represented in the as: 819 +---------+ +---------+ +---------+ 820 |IRO | |Sub | |Sub | 821 |Object | |Object AS| |Object AS| 822 |Header | |100 | |200 | 823 | | | | | | 824 | | | | | | 825 +---------+ +---------+ +---------+ 827 +---------+ +---------+ +---------+ +---------+ +---------+ 828 |IRO | |Sub | |Sub | |Sub | |Sub | 829 |Object | |Object AS| |Object | |Object AS| |Object | 830 |Header | |100 | |Area 0 | |200 | |Area 0 | 831 | | | | | | | | | | 832 | | | | | | | | | | 833 +---------+ +---------+ +---------+ +---------+ +---------+ 835 Area subobject is optional and it MAY be skipped. PCE should be able 836 to understand both notations. 838 4.2.2. Example 2 840 As shown in Figure 3, where AS 200 is made up of multiple areas and 841 multiple Domain-Sequence exist, PCE MAY include both AS and Area 842 subobject to uniquely identify the next domain and PCE. 844 | 845 | +-------------+ +----------------+ 846 | |Area 2 | |Area 4 | 847 | | +--+| | +--+ | 848 | | | || | | | | 849 | | +--+ +--+| | +--+ +--+ | 850 | | | | | | | | | 851 | | *--+ | | +--+ | 852 | | / +--+ | | +--+ | 853 | |/ | | | | | | | 854 | / +--+ | | +--+ +--+ | 855 | /| +--+ |+--------------+| | | | 856 |/ | | | ++-+ +-++ +--+ | 857 +-------------+/ | +--+ || | | || | 858 | /| | ++-+ +-++ | 859 | +--*|| +-------------+| |+----------------+ 860 | | ||| | +--+ | 861 | +--+|| | | | | 862 | +--+ || | +--+ | 863 | | | || | | 864 | +--+ || | | 865 | || | +--+ | 866 |+--+ || | | | | 867 || | || | +--+ | 868 |+--+ || | | 869 | || | +--+ | 870 | +--+ || +------------+ | | | |+----------------+ 871 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 872 | +--+ || | | || | || | 873 | || | +-++ +-++ | 874 | +--+|| | +--+ | | Area 0 || +--+ | 875 | | ||| | | | | +--------------+| | | | 876 | +--*|| | +--+ | | +--+ | 877 | \| | | | +--+ | 878 |Area 1 |\ | +--+ | | +--+ | | | 879 +-------------+|\ | | | | | | | +--+ | 880 | \| +--+ +--+ | +--+ | 881 | \ | | | | 882 | |\ +--+ | +--+ | 883 | | \ +--+ | | | | | 884 | | \| | | | +--+ | 885 | | *--+ | | | 886 | | | | | 887 | +------------+ +----------------+ 888 | 889 | 890 AS 100 | AS 200 891 | 893 Figure 3: Inter-AS Path Computation 895 The Domain-Sequence can be carried in the IRO as shown below: 897 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 898 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 899 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 900 |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 901 | | | | | | | | | | | | | | 902 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 904 The combination of both an AS and an Area uniquely identify a domain 905 in the Domain-Sequence. 907 Note that an Area domain identifier always belongs to the previous AS 908 that appears before it or, if no AS subobjects are present, it is 909 assumed to be the current AS. 911 If the area information cannot be provided, PCE MAY forward the path 912 computation request to the next PCE based on AS alone. If multiple 913 PCEs are responsible, PCE MAY apply local policy to select the next 914 PCE. 916 4.3. Boundary Node and Inter-AS-Link 918 A PCC or PCE MAY add additional constraints covering which Boundary 919 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 920 while defining a Domain-Sequence. In which case the Boundary Node or 921 Link MAY be encoded as a part of the Domain-Sequence using the 922 existing subobjects. 924 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 925 prefix subobjects usually the loopback address of 32 and 128 prefix 926 length respectively. An Inter-AS link can be encoded using the IPv4 927 or IPv6 prefix subobjects or unnumbered interface subobjects. 929 For Figure 1, an ABR to be traversed can be specified as: 931 +---------+ +---------+ +---------++---------+ +---------+ 932 |IRO | |Sub | |Sub ||Sub | |Sub | 933 |Object | |Object | |Object ||Object | |Object | 934 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 935 | | | | |x.x.x.x || | | | 936 | | | | | || | | | 937 +---------+ +---------+ +---------++---------+ +---------+ 939 For Figure 2, an inter-AS-link to be traversed can be specified as: 941 +---------+ +---------+ +---------+ +---------+ +---------+ 942 |IRO | |Sub | |Sub | |Sub | |Sub | 943 |Object | |Object AS| |Object | |Object | |Object AS| 944 |Header | |100 | |IPv4 | |IPv4 | |200 | 945 | | | | |x.x.x.x | |x.x.x.x | | | 946 | | | | | | | | | | 947 +---------+ +---------+ +---------+ +---------+ +---------+ 949 4.4. PCE Serving multiple Domains 951 A single PCE MAY be responsible for multiple domains; for example PCE 952 function deployed on an ABR. A PCE which can support 2 adjacent 953 domains can internally handle this situation without any impact on 954 the neighbouring domains. 956 4.5. P2MP 958 In case of inter-domain P2MP path computation, (Refer [RFC7334]) the 959 path domain tree is nothing but a series of Domain-Sequences, as 960 shown in the below figure: 962 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 963 D1 964 / \ 965 D2 D3 966 / / \ 967 D4 D5 D6 969 All rules of processing as applied to P2P can be applied to P2MP as 970 well. 972 In case of P2MP, different destinations MAY have different Domain- 973 Sequence within the domain tree, it requires Domain-Sequence to be 974 attached per destination. (Refer [PCE-P2MP-PER-DEST]) 976 4.6. Hierarchical PCE 978 As per [RFC6805], consider a case as shown in Figure 4 consisting of 979 multiple child PCEs and a parent PCE. 981 +--------+ 982 | Parent | 983 | PCE | 984 +--------+ 986 +-------------------+ +-------------------+ 987 | +--+ | | +--+ | 988 | +--+ | | | | | | | 989 | | | +--+ | | +--+ +--+ | 990 | +--* + + | | | 991 | | | +--+ | 992 | *--+ + + | 993 | | | | | +--+ | 994 | +--+ | | | | | 995 | |+--------------------------+| +--+ | 996 | ++++ +-++ | 997 | |||| +--+ | || | 998 | Area 2 ++++ | | +-++ Area 4 | 999 +-------------------+| +--+ |+-------------------+ 1000 | +--+ | 1001 | +--+ | | | 1002 | | | +--+ | 1003 | +--+ | 1004 | | 1005 | +--+ | 1006 | | | | 1007 | +--+ | 1008 +------------------+| |+--------------------+ 1009 | ++-+ +-++ | 1010 | || | | || | 1011 | ++-+ Area 0 +-++ | 1012 | |+--------------------------+| +--+ | 1013 | +--+ | | | | | 1014 | | | | | +--+ | 1015 | +--+ +--+ | | | 1016 | | | + + +--+ | 1017 | +--+ | | | | | 1018 | + + +--+ | 1019 | +--+ | | | 1020 | | | | | +--+ | 1021 | +--+ | | | | | 1022 | | | +--+ | 1023 | Area 1 | | Area 5 | 1024 +------------------+ +--------------------+ 1026 Figure 4: Hierarchical PCE 1028 In H-PCE, the Ingress PCE 'PCE(1)' can request the parent PCE to 1029 determine the Domain-Sequence and return it in the PCEP response, 1030 using the ERO Object. The ERO can contain an ordered sequence of 1031 subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, 1032 the Domain-Sequence appear as: 1034 +---------+ +---------+ +---------+ +---------+ 1035 |ERO | |Sub | |Sub | |Sub | 1036 |Object | |Object | |Object | |Object | 1037 |Header | |Area 2 | |Area 0 | |Area 4 | 1038 | | | | | | | | 1039 | | | | | | | | 1040 +---------+ +---------+ +---------+ +---------+ 1042 +---------+ +---------+ +---------+ +---------+ +---------+ 1043 |ERO | |Sub | |Sub | |Sub | |Sub | 1044 |Object | |Object AS| |Object | |Object | |Object | 1045 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 1046 | | | | | | | | | | 1047 | | | | | | | | | | 1048 +---------+ +---------+ +---------+ +---------+ +---------+ 1050 4.7. Relationship to PCE Sequence 1052 Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by 1053 policy on the PCC, and this constraint can be carried in the PCReq 1054 message (as defined in [RFC5886]). 1056 Note that PCE-Sequence can be used along with Domain-Sequence in 1057 which case PCE-Sequence SHOULD have higher precedence in selecting 1058 the next PCE in the inter-domain path computation procedures. Note 1059 that Domain-Sequence IRO constraints should still be checked as per 1060 the rules of processing IRO. 1062 4.8. Relationship to RSVP-TE 1064 [RFC3209] already describes the notion of abstract nodes, where an 1065 abstract node is a group of nodes whose internal topology is opaque 1066 to the ingress node of the LSP. It further defines a subobject for 1067 AS but with a 2-Byte AS Number. 1069 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1070 subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY 1071 be included in Explicit Route Object (ERO), Exclude Route object 1072 (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. 1074 In any case subobject type defined in RSVP-TE are identical to the 1075 subobject type defined in the related documents in PCEP. 1077 5. IANA Considerations 1079 5.1. New Subobjects 1081 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1082 with an entry for the Include Route Object (IRO), Exclude Route 1083 Object (XRO) and Explicit Route Object (ERO). IANA is requested to 1084 add further subobjects as follows: 1086 7 ERO 1087 10 IRO 1088 17 XRO 1090 Subobject Type Reference 1091 TBD1 4 byte AS number [This I.D.] 1092 TBD2 OSPF Area ID [This I.D.] 1093 TBD3 IS-IS Area ID [This I.D.] 1095 5.2. Error Object Field Values 1097 The "PCEP Parameters" registry contains a subregistry "Error Types 1098 and Values". IANA is requested to make the following allocations 1099 from this subregistry 1101 ERROR Meaning Reference 1102 Type 1103 TBD4 "Unrecognized subobject" [This I.D.] 1104 Error-Value: type code 1106 6. Security Considerations 1108 This document specifies a standard representation of Domain-Sequence 1109 and new subobjects, which MAY be used in inter-domain PCE scenarios 1110 as explained in other RFC and drafts. The new subobjects and Domain- 1111 Sequence mechanisms defined in this document allow finer and more 1112 specific control of the path computed by a cooperating PCE(s). Such 1113 control increases the risk if a PCEP message is intercepted, 1114 modified, or spoofed because it allows the attacker to exert control 1115 over the path that the PCE will compute or to make the path 1116 computation impossible. Therefore, the security techniques described 1117 in [RFC5440] are considered more important. 1119 Note, however, that the Domain-Sequence mechanisms also provide the 1120 operator with the ability to route around vulnerable parts of the 1121 network and may be used to increase overall network security. 1123 7. Manageability Considerations 1125 7.1. Control of Function and Policy 1127 Several local policy decisions should be made at the PCE. Firstly, 1128 the exact behavior with regard to desired inclusion and exclusion of 1129 domains must be available for examination by an operator and may be 1130 configurable. Second, the behavior on receipt of an unrecognized 1131 subobjects with the L or X-bit set should be configurable and must be 1132 available for inspection. The inspection and control of these local 1133 policy choices may be part of the PCEP MIB module. 1135 7.2. Information and Data Models 1137 A MIB module for management of the PCEP is being specified in a 1138 separate document [RFC7420]. That MIB module allows examination of 1139 individual PCEP messages, in particular requests, responses and 1140 errors. The MIB module MUST be extended to include the ability to 1141 view the Domain-Sequence extensions defined in this document. 1143 7.3. Liveness Detection and Monitoring 1145 Mechanisms defined in this document do not imply any new liveness 1146 detection and monitoring requirements in addition to those already 1147 listed in [RFC5440]. 1149 7.4. Verify Correct Operations 1151 Mechanisms defined in this document do not imply any new operation 1152 verification requirements in addition to those already listed in 1153 [RFC5440]. 1155 7.5. Requirements On Other Protocols 1157 In case of per-domain path computation [RFC5152], where the full path 1158 of an inter-domain TE LSP cannot be, or is not determined at the 1159 ingress node, a signaling message may use the domain identifiers. 1160 The Subobjects defined in this document SHOULD be supported by RSVP- 1161 TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding 1162 new subobjects for IGP Areas and 4-byte AS numbers. 1164 Apart from this, mechanisms defined in this document do not imply any 1165 requirements on other protocols in addition to those already listed 1166 in [RFC5440]. 1168 7.6. Impact On Network Operations 1170 Mechanisms defined in this document do not have any impact on network 1171 operations in addition to those already listed in [RFC5440]. 1173 8. Acknowledgments 1175 We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, 1176 Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1177 Venugopal Reddy, Reeja Paul Sandeep Boina and Avantika for their 1178 useful comments and suggestions. 1180 9. References 1182 9.1. Normative References 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1188 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1189 2009. 1191 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1192 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1193 to Compute Shortest Constrained Inter-Domain Traffic 1194 Engineering Label Switched Paths", RFC 5441, April 2009. 1196 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1197 Path Computation Element Communication Protocol (PCEP) for 1198 Route Exclusions", RFC 5521, April 2009. 1200 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1201 Computation Element Architecture to the Determination of a 1202 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 1203 2012. 1205 9.2. Informative References 1207 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1208 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1209 Tunnels", RFC 3209, December 2001. 1211 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1212 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1213 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1215 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1216 in Resource ReSerVation Protocol - Traffic Engineering 1217 (RSVP-TE)", RFC 3477, January 2003. 1219 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1220 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1222 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1223 Inter-Domain Multiprotocol Label Switching Traffic 1224 Engineering", RFC 4726, November 2006. 1226 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1227 "GMPLS Segment Recovery", RFC 4873, May 2007. 1229 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1230 Extension to Resource ReserVation Protocol-Traffic 1231 Engineering (RSVP-TE)", RFC 4874, April 2007. 1233 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1234 Path Computation Method for Establishing Inter-Domain 1235 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1236 5152, February 2008. 1238 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving 1239 Topology Confidentiality in Inter-Domain Path Computation 1240 Using a Path-Key-Based Mechanism", RFC 5520, April 2009. 1242 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1243 Monitoring Tools for Path Computation Element (PCE)-Based 1244 Architecture", RFC 5886, June 2010. 1246 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1247 Autonomous System (AS) Number Space", RFC 6793, December 1248 2012. 1250 [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, 1251 "PCE-Based Computation Procedure to Compute Shortest 1252 Constrained Point-to-Multipoint (P2MP) Inter-Domain 1253 Traffic Engineering Label Switched Paths", RFC 7334, 1254 August 2014. 1256 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1257 Hardwick, "Path Computation Element Communication Protocol 1258 (PCEP)", RFC 7420, December 2014. 1260 [PCE-P2MP-PER-DEST] 1261 Dhody, D., Palle, U., and V. Kondreddy, "Supporting 1262 explicit inclusion or exclusion of abstract nodes for a 1263 subset of P2MP destinations in Path Computation Element 1264 Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp- 1265 per-destination)", September 2014. 1267 [DOMAIN-SUBOBJ] 1268 Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 1269 "Domain Subobjects for Resource ReserVation Protocol - 1270 Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- 1271 domain-subobjects-00)", December 2014. 1273 [IRO-UPDATE] 1274 Dhody, D., "Update to Include Route Object (IRO) 1275 specification in Path Computation Element communication 1276 Protocol (PCEP. (draft-dhody-pce-iro-update-02)", December 1277 2014. 1279 [ISO10589] 1280 ISO, "Intermediate system to Intermediate system routing 1281 information exchange protocol for use in conjunction with 1282 the Protocol for providing the Connectionless-mode Network 1283 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1285 Authors' Addresses 1287 Dhruv Dhody 1288 Huawei Technologies 1289 Leela Palace 1290 Bangalore, Karnataka 560008 1291 India 1293 EMail: dhruv.ietf@gmail.com 1295 Udayasree Palle 1296 Huawei Technologies 1297 Leela Palace 1298 Bangalore, Karnataka 560008 1299 India 1301 EMail: udayasree.palle@huawei.com 1302 Ramon Casellas 1303 CTTC 1304 Av. Carl Friedrich Gauss n7 1305 Castelldefels, Barcelona 08860 1306 Spain 1308 EMail: ramon.casellas@cttc.es