idnits 2.17.1 draft-ietf-pce-pcep-domain-sequence-02.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 (Feb 2013) is 4060 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental Huawei Technologies India Pvt 5 Expires: August 5, 2013 Ltd 6 R. Casellas 7 CTTC - Centre Tecnologic de 8 Telecomunicacions de Catalunya 9 Feb 2013 11 Standard Representation Of Domain-Sequence 12 draft-ietf-pce-pcep-domain-sequence-02 14 Abstract 16 The ability to compute shortest constrained Traffic Engineering Label 17 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) networks across multiple domains has been 19 identified as a key requirement for P2P and P2MP scenarios. In this 20 context, a domain is a collection of network elements within a common 21 sphere of address management or path computational responsibility 22 such as an IGP area or an Autonomous Systems. This document 23 specifies a standard representation and encoding of a Domain- 24 Sequence, which is defined as an ordered sequence of domains 25 traversed to reach the destination domain. This document also 26 defines new subobjects to be used to encode domain identifiers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 5, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Detail Description . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Standard Representation . . . . . . . . . . . . . . . . . 7 69 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . . 8 70 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . . 8 71 3.4.2. Option (A): New IRO Object Type . . . . . . . . . . . 10 72 3.4.2.1. Handling of the Domain-Sequence IRO object . . . . 11 73 3.4.3. Option B: Existing IRO Object Type . . . . . . . . . . 13 74 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 14 75 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . . 14 76 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 14 77 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . . 15 78 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16 79 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 17 80 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 18 82 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 20 83 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 84 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 85 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 24 86 4.4. PCE serving multiple domains . . . . . . . . . . . . . . . 25 87 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . . 25 89 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . . 27 90 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28 93 5.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 28 94 5.3. Error Object Field Values . . . . . . . . . . . . . . . . 28 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 96 7. Manageability Considerations . . . . . . . . . . . . . . . . . 29 97 7.1. Control of Function and Policy . . . . . . . . . . . . . . 29 98 7.2. Information and Data Models . . . . . . . . . . . . . . . 29 99 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 100 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 30 101 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 30 102 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 30 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 108 1. Introduction 110 A PCE may be used to compute end-to-end paths across multi-domain 111 environments using a per-domain path computation technique [RFC5152]. 112 The so called backward recursive path computation (BRPC) mechanism 113 [RFC5441] defines a PCE-based path computation procedure to compute 114 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 115 and BRPC techniques assume that the sequence of domains to be crossed 116 from source to destination is known, either fixed by the network 117 operator or obtained by other means. For inter-domain point-to- 118 multi-point (P2MP) tree, [PCE-P2MP-PROCEDURES] assumes the domain- 119 tree is known. 121 The list of domains (domain-sequence) in a point-to-point (P2P) path 122 or a point-to-multi-point (P2MP) tree is usually a constraint in the 123 path computation request. The PCE determines the next PCE to forward 124 the request based on the domain-sequence. 126 In a multi-domain path computation, a PCC MAY indicate the sequence 127 of domains to be traversed using the Include Route Object (IRO) 128 defined in [RFC5440]. 130 When the sequence of domains is not known in advance, the 131 Hierarchical PCE [RFC6805] architecture and mechanisms can be used to 132 determine the end-to-end Domain-Sequence. 134 This document defines a standard way to represent and encode a 135 Domain-Sequence in various deployment scenarios including P2P, P2MP 136 and Hierarchical PCE (H-PCE) [RFC6805]. 138 The Domain-Sequence (the set of domains traversed to reach the 139 destination domain) is either administratively predetermined or 140 discovered by some means (H-PCE) that is outside of the scope of this 141 document. 143 [RFC5440] defines the Include Route Object (IRO) and the Explicit 144 Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO) 145 and the Explicit Exclusion Route Subobject (EXRS); The use of 146 Autonomous Number (AS) (2-Byte) as an abstract node representing 147 domain is defined in [RFC3209], This document specifies new 148 subobjects to include or exclude domains such as an IGP area or an 149 Autonomous Systems (4-Byte). 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. Terminology 159 The following terminology is used in this document. 161 ABR: OSPF Area Border Router. Routers used to connect two IGP 162 areas. 164 AS: Autonomous System. 166 ASBR: Autonomous System Boundary Router. 168 BN: Boundary Node, Can be an ABR or ASBR. 170 BRPC: Backward Recursive Path Computation 172 Domain: As per [RFC4655], any collection of network elements within 173 a common sphere of address management or path computational 174 responsibility. Examples of domains include Interior Gateway 175 Protocol (IGP) areas and Autonomous Systems (ASs). 177 Domain-Sequence: An ordered sequence of domains traversed to reach 178 the destination domain. 180 ERO: Explicit Route Object 182 H-PCE: Hierarchical PCE 184 IGP: Interior Gateway Protocol. Either of the two routing 185 protocols, Open Shortest Path First (OSPF) or Intermediate System 186 to Intermediate System (IS-IS). 188 IRO: Include Route Object 190 IS-IS: Intermediate System to Intermediate System. 192 OSPF: Open Shortest Path First. 194 PCC: Path Computation Client: any client application requesting a 195 path computation to be performed by a Path Computation Element. 197 PCE: Path Computation Element. An entity (component, application, 198 or network node) that is capable of computing a network path or 199 route based on a network graph and applying computational 200 constraints. 202 P2MP: Point-to-Multipoint 204 P2P: Point-to-Point 206 RSVP: Resource Reservation Protocol 208 TE LSP: Traffic Engineering Label Switched Path. 210 3. Detail Description 212 3.1. Domains 214 [RFC4726] and [RFC4655] define domain as a separate administrative or 215 geographic environment within the network. A domain may be further 216 defined as a zone of routing or computational ability. Under these 217 definitions a domain might be categorized as an Autonomous System 218 (AS) or an Interior Gateway Protocol (IGP) area. Each AS can be made 219 of several IGP areas. In order to encode a Domain-Sequence, it is 220 required to uniquely identify a domain in the Domain-Sequence. A 221 domain can be uniquely identified by area-id or AS or both. 223 3.2. Domain-Sequence 225 A domain-sequence is an ordered sequence of domains traversed to 226 reach the destination domain. 228 A domain-sequence can be applied as a constraint and carried in path 229 computation request to PCE(s). A domain-sequence can also be the 230 result of a path computation. For example, in the case of H-PCE 231 [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a 232 path computation reply. 234 In this context, the ordered nature of a domain-sequence is 235 important. In a P2P path, the domains listed appear in the order 236 that they are crossed. In a P2MP path, the domain tree is 237 represented as list of domain sequences. 239 A domain-sequence enables a PCE to select the next PCE to forward the 240 path computation request based on the domain information. 242 A PCC or PCE MAY add an additional constraints covering which 243 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be 244 traversed while defining a Domain-Sequence. 246 Thus a Domain-Sequence MAY be made up of one or more of - 247 o AS Number 249 o Area ID 251 o Boundary Node ID 253 o Inter-AS-Link Address 255 Consequently, a Domain-Sequence can be used: 257 1. by a PCE in order to discover or select the next PCE in a 258 collaborative path computation, such as in BRPC [RFC5441]; 260 2. by the Parent PCE to return the Domain-Sequence when unknown, 261 this can further be an input to BRPC procedure [RFC6805]; 263 3. by a PCC (or PCE) to constraint the domains used in a H-PCE path 264 computation, explicitly specifying which domains to be expanded; 266 4. by a PCE in per-domain path computation model [RFC5152] to 267 identify the next domain(s); 269 3.3. Standard Representation 271 Domain-Sequence MAY appear in PCEP Messages, notably in - 273 o Include Route Object (IRO): As per [RFC5440], used to specify set 274 of network elements that MUST be traversed. These subobjects are 275 used to specify the domain-sequence that MUST be traversed to 276 reach the destination. 278 o Exclude Route Object (XRO): As per [RFC5521], used to specify 279 certain abstract nodes that MUST be excluded from whole path. 280 These subobjects are used to specify certain domains that MUST be 281 avoided to reach the destination. 283 o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used 284 to specify exclusion of certain abstract nodes between a specific 285 pair of nodes. EXRS are a subobject inside the IRO. These 286 subobjects are used to specify the domains that must be excluded 287 between two abstract nodes. 289 o Explicit Route Object (ERO): As per [RFC5440],used to specify a 290 computed path in the network. 292 3.4. Include Route Object (IRO) 294 As per [RFC5440], IRO (Include Route Object) can be used to specify 295 that the computed path MUST traverse a set of specified network 296 elements or abstract nodes. 298 3.4.1. Subobjects 300 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and 301 [RFC4874], but new subobjects related to Domain-Sequence are needed. 303 The following subobject types are used in IRO. 305 The following subobject types are used. 306 Type Subobject 307 1 IPv4 prefix 308 2 IPv6 prefix 309 4 Unnumbered Interface ID 310 32 Autonomous system number (2 Byte) 311 33 Explicit Exclusion (EXRS) 313 This document extends the above list to support 4-Byte AS numbers and 314 IGP Areas. 316 The following subobject types are used. 317 Type Subobject 318 TBD Autonomous system number (4 Byte) 319 TBD OSPF Area id 320 TBD ISIS Area id 322 - Autonomous system 324 [RFC3209] already defines 2 byte AS number. 326 To support 4 byte AS number as per [RFC4893] following subobject is 327 defined: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |L| Type | Length | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | AS Id (4 bytes) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 L: The L bit is an attribute of the subobject as define in [RFC3209]. 339 Type: (TBA by IANA) indicating 4 byte AS Number. 341 Length: 8 (Total length of the subobject in bytes). 343 Reserved: Zero at transmission, Ignored at receipt. 345 AS-ID: The 4 byte AS Number. Note that if 16-bit AS numbers are in 346 use, the low order bits (16 through 31) should be used and the high 347 order bits (0 through 15) should be set to zero. 349 - IGP Area 351 Since the length and format of Area-id is different for OSPF and 352 ISIS, following two subobjects are defined: 354 For OSPF, the area-id is a 32 bit number. The Subobject looks 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |L| Type | Length | Reserved | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | OSPF Area Id (4 bytes) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 L: The L bit is an attribute of the subobject as define in [RFC3209]. 365 Type: (TBA by IANA) indicating 4 byte OSPF Area ID. 367 Length: 8 (Total length of the subobject in bytes). 369 Reserved: Zero at transmission, Ignored at receipt. 371 OSPF Area Id: The 4 byte OSPF Area ID. 373 For IS-IS, the area-id is of variable length and thus the length of 374 the Subobject is variable. The Area-id is as described in IS-IS by 375 ISO standard [ISO 10589]. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |L| Type | Length | Area-Len | Reserved | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 // IS-IS Area ID // 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 L: The L bit is an attribute of the subobject as define in [RFC3209]. 389 Type: (TBA by IANA) indicating IS-IS Area ID. 391 Length: Variable (Total length of the subobject in bytes including 392 padding). The Length MUST be at least 4, and MUST be a multiple of 393 4. 395 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 396 Identifier in octets; Valid values are from 2 to 11 inclusive). 398 Reserved: Zero at transmission, Ignored at receipt. 400 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 401 with trailing zeroes to a four-byte boundary. 403 3.4.2. Option (A): New IRO Object Type 405 [RFC5440] in its description of IRO does not require the subobjects 406 to be in a given particular order. When considering a Domain- 407 Sequence, the domain relative ordering is a basic criterion and, as 408 such, this option suggest a new IRO object type. 410 IRO Object-Class is 10. 411 IRO Object-Type is TBD. (2 suggested value to IANA) 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 // (Subobjects) // 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Subobjects: The IRO is made of subobjects identical to the ones 422 defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO 423 subobject type is identical to the subobject type defined in the 424 related documents. Some new subobjects related to Domain-Sequence 425 are also added in this document as mentioned in Section 3.4. 427 [RFC3209] defines subobjects for IPv4, IPv6 and unnumbered Interface 428 ID, which in the context of domain-sequence is used to specify 429 Boundary Node (ABR/ASBR) and Inter-AS-Links. The subobjects for AS 430 Number (2 or 4 Byte) and IGP Area is used to specify the domains in 431 the domain-sequence. 433 The new IRO Object-Type used to define the domain-sequence would 434 handle the L bit (Loose / Strict) in the subobjects similar to 435 [RFC3209]. 437 Further we have following options: 439 * Option (A.1): New IRO Object Type for Domain-Sequence object only 441 A new IRO Object Type is used to specify the ordered sequence of 442 domains (Domain-Sequence) only. The PCReq message is modified to 443 allow encoding of both types of IRO; one with IRO Type 1 [RFC5440] 444 used to specify the intra-domain abstract nodes and resources and the 445 second IRO Type with the new subobjects as described in this section 446 to specify the domain-sequence. 448 All other rules of PCEP objects and message processing (ex. P bit 449 handling of Common Object Header) is as per [RFC5440]. 451 * Option (A.2): New IRO Object Type for both intra and inter-domain 452 (domain-sequence) 454 A new IRO Object Type is used to include both intra nodes and inter- 455 domains nodes but the sequence of domain is strict. The intra-domain 456 nodes can still be ordered. 458 In case of inter-domain path computation, only the new IRO type is 459 used which contains the specific intra domain network nodes as well 460 as inter-domain abstract nodes or domains. The inter-domain abstract 461 nodes are encoded in the sequence they must be traversed but the 462 intra-domain elements MAY be an unordered set. 464 3.4.2.1. Handling of the Domain-Sequence IRO object 466 An IRO object containing Domain-Sequence subobjects constraints or 467 defines the domains involved in a multi-domain path computation, 468 typically involving two or more collaborative PCEs. 470 A Domain-Sequence can have varying degrees of granularity; it is 471 possible to have a Domain-Sequence composed of, uniquely, AS 472 identifiers. It is also possible to list the involved areas for a 473 given AS. 475 In any case, the mapping between domains and responsible PCEs is not 476 defined in this document. It is assumed that a PCE that needs to 477 obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via 478 administrative configuration, or discovery). 480 A PCC builds a Domain-Sequence IRO to encode the Domain-Sequence, 481 that is all domains that it wishes the cooperating PCEs to traverse 482 in order to compute the end to end path. 484 For each inclusion, the PCC clears the L-bit to indicate that the PCE 485 is required to include the domain, or sets the L-bit to indicate that 486 the PCC simply desires that the domain be included in the domain- 487 sequence. 489 When a PCE receives a PCEP Request message with an IRO, it looks for 490 a Domain-Sequence IRO (new type) to see if a domain-sequence is 491 specified. If the message contains more than one Domain-Sequence IRO 492 (new type), it MUST use the first one in the message and MUST ignore 493 subsequent instances. 495 If a PCE does not recognize the Domain-Sequence IRO (new type), it 496 MUST return a PCErr message with Error-Type "Unknown Object" and 497 Error-value "Unrecognized object Type" as described in [RFC5440]. 499 If a PCE is unwilling or unable to process the Domain-Sequence IRO 500 (new type), it MUST return a PCErr message with the Error-Type "Not 501 supported object" and follow the relevant procedures described in 502 [RFC5440]. 504 If a PCE that supports the Domain-Sequence IRO (new type) and 505 encounters a subobject that it does not support or recognize, it MUST 506 act according to the setting of the L-bit in the subobject. If the 507 L-bit is clear, the PCE MUST respond with a PCErr with Error-Type 508 "Unrecognized subobject" and set the Error-Value to the subobject 509 type code. If the L-bit is set, the PCE MAY respond with a PCErr as 510 already stated or MAY ignore the subobject: this choice is a local 511 policy decision. 513 If a PCE parses a Domain-Sequence IRO (new type), it MUST act 514 according to the requirements expressed in the subobject. That is, 515 if the L-bit is clear, the PCE(s) MUST produce a path that follows 516 domain-sequence nodes in order identified by the subobjects in the 517 path. If the L-bit is set, the PCE(s) SHOULD produce a path along 518 the Domain-Sequence unless it is not possible to construct a path 519 complying with the other constraints expressed in the request. 521 A successful path computation reported in a PCEP response message 522 MUST include an ERO to specify the path that has been computed as 523 specified in [RFC5440] following the sequence of domains. 525 In a PCEP response message, PCE MAY also supply a Domain-Sequence IRO 526 (new type) with the NO-PATH object indicating that the set of 527 elements of the request's Domain-Sequence IRO prevented the PCE from 528 finding a path. 530 Subobject types for AS and IGP Area affect the next domain selection 531 as well as finding the PCE serving that domain. 533 Note that a particular domain in the domain-sequence can be 534 identified by :- 536 o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is 537 used to identify the next domain. (Refer Figure 1) 539 o A single AS: Only the AS subobject is used to identify the next 540 domain. (Refer Figure 2) 542 o Both an AS and an IGP Area: Combination of both AS and Area are 543 used to identify the next domain. In this case the order is AS 544 Subobject followed by Area. (Refer Figure 3) 546 Subobject of other types representing Boundary Node or Inter-AS-Link 547 do not pay any role in the selection of next domain, but they MUST be 548 applied during the final path computation procedure as before. 550 3.4.3. Option B: Existing IRO Object Type 552 The IRO (Include Route Object) [RFC5440] is an optional object used 553 to specify a set of network elements that the computed path MUST 554 traverse. 556 The new subobjects denoting the domain-sequence are carried in the 557 same IRO Type 1, and all the rules of processing as specified in 558 [RFC5440] are applied. 560 Note the following differences :- 562 o Order: Since there is no inherent order specified in the encoding 563 of the subobjects in IRO Type 1 [RFC5440], it is the job of the 564 PCE to figure out the optimal order of the domains to be crossed 565 to reach the destination domain. Note that in case of doubt, or 566 when applicable, the PCE can still apply the ordering as specified 567 in the request message. Further PCE may have to crankback and try 568 multiple permutations before figuring out the correct sequence. 570 o Loose / Strict (L-Bit): [RFC5440] state that the L bit of the 571 subobjects within an IRO Type 1 [RFC5440] has no meaning. This 572 will be applicable for subobjects denoting domain-sequence as 573 well. 575 o Scope: Coexistence of intra-domain nodes, boundary nodes and 576 domain nodes in the same IRO List. It is the job of PCE to figure 577 out the scope and apply the processing rules accordingly. The 578 nodes in the IRO which are recognized by the PCE are handled 579 locally and others are forwarded to next PCE hoping they would 580 handle them, the aggregating PCE (Ingress PCE or Parent) would 581 make sure that all nodes in IRO are handled correctly. 583 3.5. Exclude Route Object (XRO) 585 The Exclude Route Object (XRO) [RFC5521] is an optional object used 586 to specify exclusion of certain abstract nodes or resources from the 587 whole path. 589 3.5.1. Subobjects 591 The following subobject types are defined to be used in XRO as 592 defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. 594 Type Subobject 595 1 IPv4 prefix 596 2 IPv6 prefix 597 4 Unnumbered Interface ID 598 32 Autonomous system number (2 Byte) 599 34 SRLG 600 64 IPv4 Path Key 601 65 IPv6 Path Key 603 This document extends the above list to support 4-Byte AS numbers and 604 IGP Areas. 606 Type Subobject 607 TBD Autonomous system number (4 Byte) 608 TBD OSPF Area id 609 TBD ISIS Area id 611 3.5.1.1. Autonomous system 613 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 614 MAY also be used in the XRO to specify exclusion of certain domains 615 in the path computation procedure. 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 | AS Id (4 bytes) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 The X-bit indicates whether the exclusion is mandatory or desired. 627 0 indicates that the AS specified MUST be excluded from the path 628 computed by the PCE(s). 630 1 indicates that the AS specified SHOULD be avoided from the inter- 631 domain path computed by the PCE(s), but MAY be included subject to 632 PCE policy and the absence of a viable path that meets the other 633 constraints. 635 All other fields are consistent with the definition in Section 3.4. 637 3.5.1.2. IGP Area 639 Since the length and format of Area-id is different for OSPF and 640 ISIS, following two subobjects are defined: 642 For OSPF, the area-id is a 32 bit number. The subobject is encoded 643 as follows: 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 |X| Type | Length | Reserved | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | OSPF Area Id (4 bytes) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 The X-bit indicates whether the exclusion is mandatory or desired. 655 0 indicates that the OSFF Area specified MUST be excluded from the 656 path computed by the PCE(s). 658 1 indicates that the OSFF Area specified SHOULD be avoided from the 659 inter-domain path computed by the PCE(s), but MAY be included subject 660 to PCE policy and the absence of a viable path that meets the other 661 constraints. 663 All other fields are consistent with the definition in Section 3.4. 665 For IS-IS, the area-id is of variable length and thus the length of 666 the subobject is variable. The Area-id is as described in IS-IS by 667 ISO standard [ISO 10589]. The subobject is encoded as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |X| Type | Length | Area-Len | Reserved | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | | 675 // IS-IS Area ID // 676 | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 The X-bit indicates whether the exclusion is mandatory or desired. 681 0 indicates that the ISIS Area specified MUST be excluded from the 682 path computed by the PCE(s). 684 1 indicates that the ISIS Area specified SHOULD be avoided from the 685 inter-domain path computed by the PCE(s), but MAY be included subject 686 to PCE policy and the absence of a viable path that meets the other 687 constraints. 689 All other fields are consistent with the definition in Section 3.4. 691 If a PCE that supports XRO and encounters a subobject that it does 692 not support or recognize, it MUST act according to the setting of the 693 X-bit in the subobject. If the X-bit is clear, the PCE MUST respond 694 with a PCErr with Error-Type "Unrecognized subobject" and set the 695 Error-Value to the subobject type code. If the X-bit is set, the PCE 696 MAY respond with a PCErr as already stated or MAY ignore the 697 subobject: this choice is a local policy decision. 699 All the other processing rules are as per [RFC5521]. 701 3.6. Explicit Exclusion Route Subobject (EXRS) 703 Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to 704 specify exclusion of certain abstract nodes between a specific pair 705 of nodes. 707 The EXRS subobject may carry any of the subobjects defined for 708 inclusion in the XRO, thus the new subobjects to support 4 byte AS 709 and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The 710 meanings of the fields of the new XRO subobjects are unchanged when 711 the subobjects are included in an EXRS, except that scope of the 712 exclusion is limited to the single hop between the previous and 713 subsequent elements in the IRO. 715 All the processing rules are as per [RFC5521]. 717 3.7. Explicit Route Object (ERO) 719 The Explicit Route Object (ERO) [RFC5440] is used to specify a 720 computed path in the network. PCEP ERO subobject types correspond to 721 RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], 722 [RFC3477], [RFC4873], [RFC4874], and [RFC5520]. 724 Type Subobject 725 1 IPv4 prefix 726 2 IPv6 prefix 727 3 Label 728 4 Unnumbered Interface ID 729 32 Autonomous system number (2 Byte) 730 33 Explicit Exclusion (EXRS) 731 37 Protection 732 64 IPv4 Path Key 733 65 IPv6 Path Key 735 This document extends the above list to support 4-Byte AS numbers and 736 IGP Areas. 738 Type Subobject 739 TBD Autonomous system number (4 Byte) 740 TBD OSPF Area id 741 TBD ISIS Area id 743 The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area 744 MAY also be used in the ERO to specify an abstract node (a group of 745 nodes whose internal topology is opaque to the ingress node of the 746 LSP). Using this concept of abstraction, an explicitly routed LSP 747 can be specified as a sequence of domains. 749 In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested 750 to find the domain-sequence. Refer example in Section 4.6. 752 The format of the new ERO subobjects is similar to new IRO 753 subobjects, refer Section 3.4. 755 4. Other Considerations 757 4.1. Inter-Area Path Computation 759 In an inter-area path computation where the ingress and the egress 760 nodes belong to different IGP areas within the same AS, the Domain- 761 Sequence MAY be represented using a ordered list of Area subobjects. 762 The AS number MAY be skipped, as area information is enough to select 763 the next PCE. 765 +-------------------+ +-------------------+ 766 | | | | 767 | +--+ | | +--+ | 768 | +--+ | | | | | | | 769 | | | +--+ | | +--+ +--+ | 770 | +--* + + | | | 771 | | | +--+ | 772 | *--+ + + | 773 | | | | | +--+ | 774 | +--+ | | | | | 775 | |+--------------------------+| +--+ | 776 | ++++ +-++ | 777 | |||| +--+ | || | 778 | Area 2 ++++ | | +-++ Area 4 | 779 +-------------------+| +--+ |+-------------------+ 780 | | 781 | +--+ | 782 | +--+ | | | 783 | | | +--+ | 784 | +--+ | 785 | | 786 | | 787 | | 788 | | 789 | +--+ | 790 | | | | 791 | +--+ | 792 +------------------+| |+--------------------+ 793 | ++-+ +-++ | 794 | || | | || | 795 | ++-+ Area 0 +-++ | 796 | |+--------------------------+| +--+ | 797 | +--+ | | | | | 798 | | | | | +--+ | 799 | +--+ +--+ | | | 800 | | | + + +--+ | 801 | +--+ | | | | | 802 | + + +--+ | 803 | +--+ | | | 804 | | | | | +--+ | 805 | +--+ | | | | | 806 | | | +--+ | 807 | | | | 808 | Area 1 | | Area 5 | 809 +------------------+ +--------------------+ 811 AS Number is 100. 813 Figure 1: Inter-Area Path Computation 815 This could be represented in the as: 817 +---------+ +---------+ +---------+ +---------+ 818 |IRO | |Sub | |Sub | |Sub | 819 |Object | |Object | |Object | |Object | 820 |Header | |Area 2 | |Area 0 | |Area 4 | 821 | | | | | | | | 822 | | | | | | | | 823 +---------+ +---------+ +---------+ +---------+ 825 +---------+ +---------+ +---------+ +---------+ +---------+ 826 |IRO | |Sub | |Sub | |Sub | |Sub | 827 |Object | |Object AS| |Object | |Object | |Object | 828 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 829 | | | | | | | | | | 830 | | | | | | | | | | 831 +---------+ +---------+ +---------+ +---------+ +---------+ 833 AS is optional and it MAY be skipped. PCE should be able to 834 understand both notations. 836 4.2. Inter-AS Path Computation 838 In inter-AS path computation, where ingress and egress belong to 839 different AS, the Domain-Sequence is represented using an ordered 840 list of AS subobjects. The Domain-Sequence MAY further include 841 decomposed area information in Area subobjects. 843 4.2.1. Example 1 845 As shown in Figure 2, where AS to be made of a single area, the area 846 subobject MAY be skipped in the Domain-Sequence as AS is enough to 847 uniquely identify the next domain and PCE. 849 +---------------------------------+ 850 |AS 200 | 851 | +------+ | 852 | | | | 853 +------------------------+ | | | +------+ | 854 | AS 100 | | +------+ | | | 855 | +------+ | | +------+ | | | 856 | | +-+-----+-+ | +------+ | 857 | | | | | | | | 858 | +------+ | | +------+ | 859 | +------+ | | +------+ | 860 | | | | | | | | 861 | | | | | | | | 862 | +------+ | | +------+ | 863 | | | | 864 | +------+ | | +------+ | 865 | | +-+-----+-+ | +------+ | 866 | | | | | | | | | | 867 | +------+ | | +------+ | | | 868 | | | +------+ | 869 | | | | 870 | | | | 871 | +------+ | | +------+ | 872 | | | | | | | | 873 | |PCE | | | |PCE | | 874 | +------+ | | +------+ | 875 | | | | 876 +------------------------+ | | 877 +---------------------------------+ 879 Both AS are made of Area 0. 881 Figure 2: Inter-AS Path Computation 883 This could be represented in the as: 885 +---------+ +---------+ +---------+ 886 |IRO | |Sub | |Sub | 887 |Object | |Object AS| |Object AS| 888 |Header | |100 | |200 | 889 | | | | | | 890 | | | | | | 891 +---------+ +---------+ +---------+ 893 +---------+ +---------+ +---------+ +---------+ +---------+ 894 |IRO | |Sub | |Sub | |Sub | |Sub | 895 |Object | |Object AS| |Object | |Object AS| |Object | 896 |Header | |100 | |Area 0 | |200 | |Area 0 | 897 | | | | | | | | | | 898 | | | | | | | | | | 899 +---------+ +---------+ +---------+ +---------+ +---------+ 900 Area subobject is optional and it MAY be skipped. PCE should be 901 able to understand both notations. 903 4.2.2. Example 2 905 As shown in Figure 3, where AS 200 is made up of multiple areas and 906 multiple domain-sequence exist, PCE MAY include both AS and Area 907 subobject to uniquely identify the next domain and PCE. 909 | 910 | +-------------+ +----------------+ 911 | |Area 2 | |Area 4 | 912 | | +--+| | +--+ | 913 | | | || | | | | 914 | | +--+ +--+| | +--+ +--+ | 915 | | | | | | | | | 916 | | *--+ | | +--+ | 917 | | / +--+ | | +--+ | 918 | |/ | | | | | | | 919 | / +--+ | | +--+ +--+ | 920 | /| +--+ |+--------------+| | | | 921 |/ | | | ++-+ +-++ +--+ | 922 +-------------+/ | +--+ || | | || | 923 | /| | ++-+ +-++ | 924 | +--*|| +-------------+| |+----------------+ 925 | | ||| | +--+ | 926 | +--+|| | | | | 927 | +--+ || | +--+ | 928 | | | || | | 929 | +--+ || | | 930 | || | +--+ | 931 |+--+ || | | | | 932 || | || | +--+ | 933 |+--+ || | | 934 | || | +--+ | 935 | +--+ || +------------+ | | | |+----------------+ 936 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 937 | +--+ || | | || | || | 938 | || | +-++ +-++ | 939 | +--+|| | +--+ | | Area 0 || +--+ | 940 | | ||| | | | | +--------------+| | | | 941 | +--*|| | +--+ | | +--+ | 942 | \| | | | +--+ | 943 |Area 1 |\ | +--+ | | +--+ | | | 944 +-------------+|\ | | | | | | | +--+ | 945 | \| +--+ +--+ | +--+ | 946 | \ | | | | 947 | |\ +--+ | +--+ | 948 | | \ +--+ | | | | | 949 | | \| | | | +--+ | 950 | | *--+ | | | 951 | | | | | 952 | +------------+ +----------------+ 953 | 954 | 955 AS 100 | AS 200 956 | 957 Figure 3: Inter-AS Path Computation 959 The Domain-Sequence can be carried in the IRO as shown below: 961 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 962 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 963 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 964 |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 965 | | | | | | | | | | | | | | 966 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 968 The combination of both an AS and an Area uniquely identify a domain 969 in the Domain-Sequence. 971 Note that an Area domain identifier always belongs to the previous AS 972 that appears before it or, if no AS subobjects are present, it is 973 assumed to be the current AS. 975 If the area information cannot be provided, PCE MAY forward the path 976 computation request to the next PCE based on AS alone. If multiple 977 PCEs are responsible, PCE MAY apply local policy to select the next 978 PCE. 980 4.3. Boundary Node and Inter-AS-Link 982 A PCC or PCE MAY add additional constraints covering which Boundary 983 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 984 while defining a Domain-Sequence. In which case the Boundary Node or 985 Link MAY be encoded as a part of the domain-sequence using the 986 existing subobjects. 988 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6 989 prefix subobjects usually the loopback address of 32 and 128 prefix 990 length respectively. An Inter-AS link can be encoded using the IPv4 991 or IPv6 prefix subobjects or unnumbered interface subobjects. 993 For Figure 1, an ABR to be traversed can be specified as: 995 +---------+ +---------+ +---------++---------+ +---------+ 996 |IRO | |Sub | |Sub ||Sub | |Sub | 997 |Object | |Object | |Object ||Object | |Object | 998 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 999 | | | | |x.x.x.x || | | | 1000 | | | | | || | | | 1001 +---------+ +---------+ +---------++---------+ +---------+ 1003 For Figure 2, an inter-AS-link to be traversed can be specified as: 1005 +---------+ +---------+ +---------+ +---------+ +---------+ 1006 |IRO | |Sub | |Sub | |Sub | |Sub | 1007 |Object | |Object AS| |Object | |Object | |Object AS| 1008 |Header | |100 | |IPv4 | |IPv4 | |200 | 1009 | | | | |x.x.x.x | |x.x.x.x | | | 1010 | | | | | | | | | | 1011 +---------+ +---------+ +---------+ +---------+ +---------+ 1013 4.4. PCE serving multiple domains 1015 A single PCE MAY be responsible for multiple domains; for example PCE 1016 function deployed on an ABR. A PCE which can support 2 adjacent 1017 domains can internally handle this situation without any impact on 1018 the neighboring domains. 1020 4.5. P2MP 1022 In case of inter-domain P2MP path computation, (Refer 1023 [PCE-P2MP-PROCEDURES]) the path domain tree is nothing but a series 1024 of Domain Sequences, as shown in the below figure: 1026 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 1027 D1 1028 / \ 1029 D2 D3 1030 / / \ 1031 D4 D5 D6 1033 All rules of processing as applied to P2P can be applied to P2MP as 1034 well. 1036 In case of P2MP, different destinations MAY have different Domain- 1037 Sequence within the domain tree, it requires domain-sequence to be 1038 attached per destination. (Refer [PCE-P2MP-PER-DEST]) 1040 4.6. Hierarchical PCE 1042 As per [RFC6805], consider a case as shown in Figure 4 consisting of 1043 multiple child PCEs and a parent PCE. 1045 +--------+ 1046 | Parent | 1047 | PCE | 1048 +--------+ 1050 +-------------------+ +-------------------+ 1051 | +--+ | | +--+ | 1052 | +--+ | | | | | | | 1053 | | | +--+ | | +--+ +--+ | 1054 | +--* + + | | | 1055 | | | +--+ | 1056 | *--+ + + | 1057 | | | | | +--+ | 1058 | +--+ | | | | | 1059 | |+--------------------------+| +--+ | 1060 | ++++ +-++ | 1061 | |||| +--+ | || | 1062 | Area 2 ++++ | | +-++ Area 4 | 1063 +-------------------+| +--+ |+-------------------+ 1064 | +--+ | 1065 | +--+ | | | 1066 | | | +--+ | 1067 | +--+ | 1068 | | 1069 | +--+ | 1070 | | | | 1071 | +--+ | 1072 +------------------+| |+--------------------+ 1073 | ++-+ +-++ | 1074 | || | | || | 1075 | ++-+ Area 0 +-++ | 1076 | |+--------------------------+| +--+ | 1077 | +--+ | | | | | 1078 | | | | | +--+ | 1079 | +--+ +--+ | | | 1080 | | | + + +--+ | 1081 | +--+ | | | | | 1082 | + + +--+ | 1083 | +--+ | | | 1084 | | | | | +--+ | 1085 | +--+ | | | | | 1086 | | | +--+ | 1087 | Area 1 | | Area 5 | 1088 +------------------+ +--------------------+ 1090 Figure 4: Hierarchical PCE 1092 In H-PCE, the Ingress PCE PCE(1) can request the parent PCE to 1093 determine the Domain-Sequence and return it in the PCEP response, 1094 using the ERO Object. The ERO can contain an ordered sequence of 1095 subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case, 1096 the Domain-Sequence appear as: 1098 +---------+ +---------+ +---------+ +---------+ 1099 |ERO | |Sub | |Sub | |Sub | 1100 |Object | |Object | |Object | |Object | 1101 |Header | |Area 2 | |Area 0 | |Area 4 | 1102 | | | | | | | | 1103 | | | | | | | | 1104 +---------+ +---------+ +---------+ +---------+ 1106 +---------+ +---------+ +---------+ +---------+ +---------+ 1107 |ERO | |Sub | |Sub | |Sub | |Sub | 1108 |Object | |Object AS| |Object | |Object | |Object | 1109 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 1110 | | | | | | | | | | 1111 | | | | | | | | | | 1112 +---------+ +---------+ +---------+ +---------+ +---------+ 1114 Note that, in the case of ERO objects, no new PCEP object type is 1115 required since the ordering constraint is assumed. 1117 4.7. Relationship to PCE Sequence 1119 Instead of a domain-sequence, a sequence of PCEs MAY be enforced by 1120 policy on the PCC, and this constraint can be carried in the PCEP 1121 path computation request (as defined in [RFC5886]). 1123 Note that PCE-Sequence can be used along with domain-sequence in 1124 which case PCE-Sequence SHOULD have higher precedence in selecting 1125 the next PCE in the inter-domain path computation procedures. Note 1126 that Domain-Sequence IRO constraints should still be checked as per 1127 the rules of processing IRO. 1129 4.8. Relationship to RSVP-TE 1131 [RFC3209] already describes the notion of abstract nodes, where an 1132 abstract node is a group of nodes whose internal topology is opaque 1133 to the ingress node of the LSP. It further defines a subobject for 1134 Autonomous Systems (AS) (2-Byte). 1136 [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new 1137 subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY 1138 be included in Explicit Route Object (ERO), Exclude Route object 1139 (XRO) or Explicit Exclusion Route Subobject (EXRS). 1141 In any case subobject type defined in RSVP-TE are identical to the 1142 subobject type defined in the related documents in PCEP. 1144 5. IANA Considerations 1146 5.1. PCEP Objects 1148 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 1149 IANA is requested to make the following allocations from this 1150 registry. 1152 Object Name Reference 1153 Class 1154 10 IRO [RFC5440] 1155 Object-Type 1156 (TBA): Domain-Sequence [This I.D.] 1158 5.2. New Subobjects 1160 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 1161 with an entry for the Include Route Object (IRO), Exclude Route 1162 Object (XRO) and Explicit Route Object (ERO). IANA is requested to 1163 add further subobjects as follows: 1165 7 ERO 1166 10 IRO 1167 17 XRO 1169 Subobject Type Reference 1170 TBA 4 byte AS number [This I.D.] 1171 TBA OSPF Area ID [This I.D.] 1172 TBA IS-IS Area ID [This I.D.] 1174 5.3. Error Object Field Values 1176 The "PCEP Parameters" registry contains a subregistry "Error Types 1177 and Values". IANA is requested to make the following allocations 1178 from this subregistry 1180 ERROR Meaning Reference 1181 Type 1182 TBA "Unrecognized subobject" [This I.D.] 1183 Error-Value: type code 1185 6. Security Considerations 1187 This document specifies a standard representation of Domain-Sequence 1188 and new subobjects, which MAY be used in inter-domain PCE scenarios 1189 as explained in other RFC and drafts. The new subobjects and Domain- 1190 Sequence mechanisms defined in this document allow finer and more 1191 specific control of the path computed by a cooperating PCE(s). Such 1192 control increases the risk if a PCEP message is intercepted, 1193 modified, or spoofed because it allows the attacker to exert control 1194 over the path that the PCE will compute or to make the path 1195 computation impossible. Therefore, the security techniques described 1196 in [RFC5440] are considered more important. 1198 Note, however, that the Domain-Sequence mechanisms also provide the 1199 operator with the ability to route around vulnerable parts of the 1200 network and may be used to increase overall network security. 1202 7. Manageability Considerations 1204 7.1. Control of Function and Policy 1206 Several local policy decisions should be made at the PCE. Firstly, 1207 the exact behavior with regard to desired inclusion and exclusion of 1208 domains must be available for examination by an operator and may be 1209 configurable. Second, the behavior on receipt of an unrecognized 1210 subobjects with the L or X-bit set should be configurable and must be 1211 available for inspection. The inspection and control of these local 1212 policy choices may be part of the PCEP MIB module. 1214 7.2. Information and Data Models 1216 A MIB module for management of the PCEP is being specified in a 1217 separate document [PCEP-MIB]. That MIB module allows examination of 1218 individual PCEP messages, in particular requests, responses and 1219 errors. The MIB module MUST be extended to include the ability to 1220 view the domain-sequence extensions defined in this document. 1222 7.3. Liveness Detection and Monitoring 1224 Mechanisms defined in this document do not imply any new liveness 1225 detection and monitoring requirements in addition to those already 1226 listed in [RFC5440]. 1228 7.4. Verify Correct Operations 1230 Mechanisms defined in this document do not imply any new operation 1231 verification requirements in addition to those already listed in 1232 [RFC5440]. 1234 7.5. Requirements On Other Protocols 1236 The Subobjects defined in this document SHOULD be supported by RSVP 1237 especially for per-domain path computation [RFC5152] where the 1238 domains need to encoded in the RSVP messages. [DOMAIN-SUBOBJ] 1239 extends the notion of abstract nodes by adding new subobjects for IGP 1240 Areas and 4-byte AS numbers. 1242 Apart from this, mechanisms defined in this document do not imply any 1243 requirements on other protocols in addition to those already listed 1244 in [RFC5440]. 1246 7.6. Impact On Network Operations 1248 Mechanisms defined in this document do not have any impact on network 1249 operations in addition to those already listed in [RFC5440]. 1251 8. Acknowledgments 1253 We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, 1254 Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, 1255 Venugopal Reddy, Reeja Paul and Sandeep Boina for their useful 1256 comments and suggestions. 1258 9. References 1260 9.1. Normative References 1262 [RFC2119] Bradner, S., "Key words for use in RFCs to 1263 Indicate Requirement Levels", BCP 14, 1264 RFC 2119, March 1997. 1266 [ISO 10589] ISO, "Intermediate system to Intermediate 1267 system routing information exchange protocol 1268 for use in conjunction with the Protocol for 1269 providing the Connectionless-mode Network 1270 Service (ISO 8473)", ISO/IEC 10589:2002. 1272 9.2. Informative References 1274 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 1275 Srinivasan, V., and G. Swallow, "RSVP-TE: 1277 Extensions to RSVP for LSP Tunnels", RFC 3209, 1278 December 2001. 1280 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1281 Switching (GMPLS) Signaling Resource 1282 ReserVation Protocol-Traffic Engineering 1283 (RSVP-TE) Extensions", RFC 3473, January 2003. 1285 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling 1286 Unnumbered Links in Resource ReSerVation 1287 Protocol - Traffic Engineering (RSVP-TE)", 1288 RFC 3477, January 2003. 1290 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 1291 Computation Element (PCE)-Based Architecture", 1292 RFC 4655, August 2006. 1294 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A 1295 Framework for Inter-Domain Multiprotocol Label 1296 Switching Traffic Engineering", RFC 4726, 1297 November 2006. 1299 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., 1300 and A. Farrel, "GMPLS Segment Recovery", 1301 RFC 4873, May 2007. 1303 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, 1304 "Exclude Routes - Extension to Resource 1305 ReserVation Protocol-Traffic Engineering 1306 (RSVP-TE)", RFC 4874, April 2007. 1308 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four- 1309 octet AS Number Space", RFC 4893, May 2007. 1311 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A 1312 Per-Domain Path Computation Method for 1313 Establishing Inter-Domain Traffic Engineering 1314 (TE) Label Switched Paths (LSPs)", RFC 5152, 1315 February 2008. 1317 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path 1318 Computation Element (PCE) Communication 1319 Protocol (PCEP)", RFC 5440, March 2009. 1321 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le 1322 Roux, "A Backward-Recursive PCE-Based 1323 Computation (BRPC) Procedure to Compute 1324 Shortest Constrained Inter-Domain Traffic 1325 Engineering Label Switched Paths", RFC 5441, 1326 April 2009. 1328 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, 1329 "Preserving Topology Confidentiality in Inter- 1330 Domain Path Computation Using a Path-Key-Based 1331 Mechanism", RFC 5520, April 2009. 1333 [RFC5521] Oki, E., Takeda, T., and A. Farrel, 1334 "Extensions to the Path Computation Element 1335 Communication Protocol (PCEP) for Route 1336 Exclusions", RFC 5521, April 2009. 1338 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A 1339 Set of Monitoring Tools for Path Computation 1340 Element (PCE)-Based Architecture", RFC 5886, 1341 June 2010. 1343 [RFC6805] King, D. and A. Farrel, "The Application of 1344 the Path Computation Element Architecture to 1345 the Determination of a Sequence of Domains in 1346 MPLS and GMPLS", RFC 6805, November 2012. 1348 [PCE-P2MP-PROCEDURES] Zhao, Q., Dhody, D., Ali, Z., Saad,, T., 1349 Sivabalan,, S., and R. Casellas, "PCE-based 1350 Computation Procedure To Compute Shortest 1351 Constrained P2MP Inter-domain Traffic 1352 Engineering Label Switched Paths (draft-ietf- 1353 pce-pcep-inter-domain-p2mp-procedures)", 1354 February 2012. 1356 [PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., 1357 and J. Hardwick, "PCE communication 1358 protocol(PCEP) Management Information Base", 1359 July 2012. 1361 [PCE-P2MP-PER-DEST] Dhody, D., Palle, U., and V. Kondreddy, 1362 "Supporting explicit inclusion or exclusion of 1363 abstract nodes for a subset of P2MP 1364 destinations in Path Computation Element 1365 Communication Protocol (PCEP). 1366 (draft-dhody-pce-pcep-p2mp-per-destination)", 1367 Oct 2012. 1369 [DOMAIN-SUBOBJ] Dhody, D., Palle, U., Kondreddy, V., and R. 1370 Casellas, "Domain Subobjects for Resource 1371 ReserVation Protocol - Traffic Engineering 1372 (RSVP-TE). 1374 (draft-dhody-ccamp-rsvp-te-domain- 1375 subobjects)", Sept 2012. 1377 Authors' Addresses 1379 Dhruv Dhody 1380 Huawei Technologies India Pvt Ltd 1381 Leela Palace 1382 Bangalore, Karnataka 560008 1383 INDIA 1385 EMail: dhruv.dhody@huawei.com 1387 Udayasree Palle 1388 Huawei Technologies India Pvt Ltd 1389 Leela Palace 1390 Bangalore, Karnataka 560008 1391 INDIA 1393 EMail: udayasree.palle@huawei.com 1395 Ramon Casellas 1396 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 1397 Av. Carl Friedrich Gauss n7 1398 Castelldefels, Barcelona 08860 1399 SPAIN 1401 EMail: ramon.casellas@cttc.es