idnits 2.17.00 (12 Aug 2021) /tmp/idnits32891/draft-zhang-pcep-hierarchy-extensions-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PCE-HIERARCHY-FWK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Duplicate reference: RFC5316, mentioned in 'RFC5392', was also mentioned in 'RFC5316'. == Outdated reference: A later version (-06) exists of draft-king-pce-hierarchy-fwk-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group F. Zhang 2 Internet-Draft Q. Zhao 3 Intended status: Standards Track Huawei Technologies 4 Expires: April 18, 2011 O. Gonzalez de Dios 5 Telefonica I+D 6 R. Casellas 7 CTTC 8 D. King 9 Old Dog Consulting 10 October 18, 2010 12 Extensions to 13 Path Computation Element Communication Protocol (PCEP) 14 for Hierarchical Path Computation Elements (PCE) 15 draft-zhang-pcep-hierarchy-extensions-00 17 Abstract 19 The hierachical Path Computation Element (PCE) architecture defined 20 in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be 21 selected, and the optimum end-to-end path to be derived through the 22 use of a hierarchical relationship between domains. 24 This document defines the Path Computation Element Protocol (PCEP) 25 extensions for the purpose of implementing hierarchical PCE 26 procedures which are described in [PCE-HIERARCHY-FWK]. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on April 18, 2011. 51 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...............................................3 68 2. PCEP Extension Requirements................................4 69 2.1. New Objective Functions...............................4 70 2.2. PCEP Request Qualifiers...............................4 71 2.3. Discovery Between Parent and Child PCEs...............4 72 2.3.1. Parent PCE Capability Discovery..................5 73 2.3.2. PCE Domain and PCE ID Discovery..................5 74 2.4. Domain Connectivity Information Collection............5 75 2.5. Error Case Handling...................................6 76 3. PCEP Extensions............................................6 77 3.1. Extensions to OPEN Object.............................7 78 3.1.1. OF Codes.........................................7 79 3.1.2. OPEN Object Flags................................7 80 3.1.3. Domain-ID TLV....................................7 81 3.1.4. PCE-ID TLV.......................................8 82 3.1.5. Procedures.......................................8 83 3.2. Extensions to RP Object...............................9 84 3.2.1. RP Object Flags..................................9 85 3.2.2. Domain-ID TLV....................................9 86 3.2.3. Procedures.......................................9 87 3.3. Extensions to NOTIFICATION Object.....................9 88 3.3.1. Notification Types...............................10 89 3.3.2. Inter-domain Link TLV............................10 90 3.3.3. Inter-domain Node TLV............................11 91 3.3.4. Domain-ID TLV....................................11 92 3.3.5. PCE-ID TLV.......................................11 93 3.3.6. Procedures.......................................12 94 3.4. Extensions to PCEP-ERROR Object.......................12 95 3.4.1. Hierarchy PCE Error-Type.........................12 96 3.4.2. Procedures.......................................12 97 4. Manageability Considerations...............................13 98 5. IANA Considerations........................................13 99 6. Security Considerations....................................13 100 7. References.................................................13 101 7.1. Normative References..................................13 102 7.2. Informative References................................13 104 1. Introduction 106 [PCE-HIERARCHY-FWK] describes a hierarchy PCE architecture which can 107 be used for computing the end-to-end paths of inter-domain MPLS 108 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). In 109 the hierarchy PCE architecture, the parent PCE can compute a domain 110 path based on the domain connectivity information and the child PCE 111 can compute the intra-domain path based on the domain topology 112 information. The end-to-end domain path computing procedures can be 113 abstracted as follows: 115 o The PCC requests a child PCE to return an inter-domain path. 117 o The child PCE forwards the request to the parent PCE. 119 o The parent PCE computes one or multiple domain paths from the 120 ingress domain to the egress domain. 122 o The parent PCE sends the intra-domain path computation requests 123 (between the domain border nodes) to the child PCEs which are 124 responsible for the domains along the domain path(s). 126 o The child PCEs return the intra-domain paths to the parent PCE. 128 o The parent PCE constructs the end-to-end inter-domain path based 129 on the intra-domain paths and returns the inter-domain path to the 130 child PCE. 132 o The child PCE forwards the inter-domain path to the PCC. 134 This document defines the PCEP extensions for the purpose of 135 implementing hierarchy PCE procedures which are described in 136 [PCE-HIERARCHY-FWK]. 138 The document also uses a number of editor notes to describe options 139 and alternative solutions. These options and notes will be removed 140 before publication. 142 1.1. Terminology 144 This document uses the terminology defined in [RFC4655] and [RFC5440] 145 and [PCE-HIERARCHY-FWK]. 147 1.2. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2. PCEP Extension Requirements 155 2.1. New Objective Functions 157 For inter-domain path computation, there are three new objective 158 functions which are defined in section 1.3.1 of [PCE-HIERARCHY-FWK]. 160 o Minimize the number of boundary nodes used. 162 o Limit the number of domains crossed. 164 o Disallow domain re-entry. 166 During the PCEP session establishment procedure, the PCE needs to be 167 capable of indicating the objective functions (OF) capability in the 168 Open message. This information can be, in turn, announced by child 169 PCEs and used for selecting the PCE when a PCC want a path that 170 satisfies a certain inter-domain objective function. 172 When a PCC requests a PCE to compute an inter-domain path, the PCC 173 needs also to be capable of indicating the new objective functions 174 for inter-domain path. 176 For the reasons described above, new OF codes need to be defined for 177 the new inter-domain objective functions. Then the PCE can notify its 178 new inter-domain objective functions to the PCC by carrying them in 179 the OF-list TLV which is carried in the OPEN object. The PCC can 180 specify which objective function code to use, which is carried in the 181 OF object when requesting a PCE to compute an inter-domain path. 183 2.2. PCEP Request Qualifiers 185 As described in section 5.8.1 of [PCE-HIERARCHY-FWK], support of the 186 H-PCE architecture will introduce two new qualifications as follows: 188 o It must be possible for a child PCE to indicate that the request it 189 sends to a parent PCE should be satisfied by a domain sequence 190 only, that is, not by a full end-to-end path. This allows the child 191 PCE to initiate per-domain or backward recursive path computation. 193 o A parent PCE needs to be able to ask a child PCE whether a 194 particular node address (the destination of an end-to-end path) is 195 present in the domain that the child PCE serves. 197 To meet the above requirements, the PCEP PCReq message should be 198 extended. 200 2.3. Discovery Between Parent and Child PCEs 202 In the H-PCE architecture, the parent PCE does not need to be aware 203 of each child domain topology. Therefore, it is possible that the 204 parent PCE does not join the IGP instance of the child PCE domain, 205 i.e. there is no IGP discovery mechanism between the parent PCE and 206 child PCE. 208 Therefore there must be a discovery mechanism for basic PCE 209 information between the parent and child PCEs. In this case, PCEP 210 needs to provide discovery mechanisms that do not rely on IGP 211 announcement/discovery procedures. 213 Editors note. A child PCE could forward the topology within PCNtf 214 messages or any other mechanisms, without an IGP adjacency. Further 215 discussion of the discovery mechanism and scope will be discussed in 216 later versions of this document. 218 2.3.1. Parent PCE Capability Discovery 220 As described in [PCE-HIERARCHY-FWK], during the PCEP session 221 establishment procedure, the child PCE needs to be capable of 222 indicating to the parent PCE whether it requests the parent PCE 223 capability or not. The parent PCE needs also to be capable of 224 indicating whether its parent capability can be provided to the 225 child PCE or not. 227 2.3.2. PCE Domain and PCE ID Discovery 229 A PCE domain is a single domain with an associated PCE. it is 230 possible for a PCE to manage multiple domains. The PCE domain may be 231 an IGP area or AS. 233 The PCE ID is an IPv4 and/or IPv6 address that is used to reach the 234 parent/child PCE. It is RECOMMENDED to use an address that is always 235 reachable if there is any connectivity to the PCE. 237 The PCE ID information and PCE domain identifiers may be provided 238 during the PCEP session establishment procedure or the domain 239 connectivity information collection procedure. 241 2.4. Domain Connectivity Information Collection 243 As described in [PCE-HIERARCHY-FWK], the parent PCE builds the domain 244 topology map either from configuration or from information received 245 from each child PCE. A child PCE may report its neighbor domain 246 connectivity to its parent PCE. It is reasonable to use PCEP PCNtf 247 message to do this procedure. If an IGP adjacency is established 248 between parent and children, it could be used for this purpose. 250 There are two types of domain border for providing the domain 251 connectivity information: 253 o Domain border is a TE link, e.g. the inter-AS TE link which 254 connects two ASs. 256 o Domain border is a node, e.g. the IGP ABR which connects two IGP 257 areas. 259 For the inter-AS TE links, the following information needs to be 260 notified to the parent PCE: 262 o Identifier of advertising child PCE. 264 o Identifier of PCE's domain. 266 o Identifier of the link. 268 o TE properties of the link (metrics, bandwidth) 270 o Other properties of the link (technology-specific). 272 o Identifier of link end-points. 274 o Identifier of adjacent domain. 276 For the ABR, the following information needs to be notified to the 277 parent PCE: 279 o Identifier of the ABR. 281 o Identifier of the IGP Area IDs. 283 2.5. Error Case Handling 285 A PCE that is capable of acting as a parent PCE might not be 286 configured or willing to act as the parent for a specific child PCE. 287 This fact could be determined when the child sends a PCReq that 288 requires parental activity (such as querying other child PCEs), and 289 could result in a negative response in a PCEP Error (PCErr) message 290 and indicate the hierarchy PCE error types. 292 3. PCEP Extensions 294 3.1. Extensions to OPEN Object 296 3.1.1. OF Codes 298 There are three new OF codes defined here for H-PCE: 300 o Name: Minimize the number of Boundary Nodes used (MBN) 301 Objective Function Code: (to be assigned by IANA, recommended 9) 302 Description: Find a path P such that passes through the least 303 boundary nodes. 305 o Name: Minimize the number of Transit Domains (MTD) 10) 306 Objective Function Code: (to be assigned by IANA, recommended 307 Description: Find a path P such that passes through the least 308 transit domains. 310 o Name: Disallow Domain Re-entry (DDR) 311 Objective Function Code: (to be assigned by IANA, recommended 11) 312 Description: Find a path P such that does not entry a domain more 313 than once. 315 3.1.2. OPEN Object Flags 317 There are two OPEN object flags defined here for H-PCE: 319 o Parent PCE request bit (to be assigned by IANA, recommended bit 0): 320 if set it means the child PCE wishes to use the peer PCE as a 321 parent PCE. 323 o Parent PCE indication bit (to be assigned by IANA, recommended bit 324 1): if set it means the PCE can be used as a parent PCE by the peer 325 PCE. 327 Editors Note. It is possible that a parent PCE will also act as a 328 child PCE. 330 3.1.3. Domain-ID TLV 332 The type of Domain-ID TLV is to be assigned by IANA (recommended 7). 333 The length is 8 octets. The format of this TLV is defined below: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Domain Type | Reserved | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Domain ID | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 1: Domain-ID TLV 345 Domain Type (8 bits): Indicates the domain type. There are two types 346 of domain defined currently: 348 o Type=1: the Domain ID field carries an IGP Area ID. 350 o Type=2: the Domain ID field carries an AS number. 352 Domain ID (32 bits): Indicates an IGP Area ID or AS number. 354 Editors note. It maybe necessary to support 64 bit domain IDs. 356 3.1.4. PCE-ID TLV 358 The type of PCE-ID TLV is to be assigned by IANA (recommended 8). 359 The length is 4. The format of this TLV is defined below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Address Type | Reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 // PCE IP Address // 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 2: PCE ID TLV 373 Address Type (16 bits): Indicates the address type of PCE IP Address. 374 1 means IPv4 address type, 2 means IPv6 address type. 376 PCE IP Address: Indicates the reachable address of a PCE. 378 3.1.5. Procedures 380 The OF codes defined in this document can be carried in the OF-list 381 TLV of the OPEN object. If the OF-list TLV carries the OF codes, it 382 means that the PCE is capable of implementing the corresponding 383 objective functions. This information can be used for selecting a 384 proper parent PCE when a child PCE wants to get a path that satisfies 385 a certain objective function. 387 If a child PCE wants to use the peer PCE as a parent, it can set the 388 parent PCE request bit in the OPEN object carried in the Open message 389 during the PCEP session creation procedure. If the peer PCE does not 390 want to provide the parent function to the child PCE, it must send a 391 PCErr message to the child PCE and clear the parent PCE indication 392 bit in the OPEN object. 394 If the parent PCE can provide the parent function to the peer PCE, it 395 may set the parent PCE indication bit in the OPEN object carried in 396 the Open message during the PCEP session creation procedure. 398 The PCE may also report its PCE ID and list of domain ID to the peer 399 PCE by specifying them in the PCE-ID TLV and List of Domain-ID TLVs 400 in the OPEN object carried in the Open message during the PCEP 401 session creation procedure. 403 3.2. Extensions to RP Object 405 3.2.1. RP Object Flags 407 o Domain Path Request bit (to be assigned by IANA, recommended bit 408 17): if set it means the child PCE wishes to get the domain 409 sequence. 411 o Destination Domain Query bit (to be assigned by IANA, recommended 412 bit 16): if set it means the parent PCE wishes to get the 413 destination domain ID. 415 3.2.2. Domain-ID TLV 417 The format of this TLV is defined in section 2.1.3. This TLV can be 418 carried in an OPEN object to indicate a (list of) managed domains, or 419 carried in a RP object to indicate the destination domain ID when a 420 child PCE responds to the parent PCE's destination domain query by a 421 PCRep message. 423 Editors note. In some cases, the Parent PCE may need to allocate a 424 node which is not necessarily the destination node. 426 3.2.3. Procedures 428 If a child PCE only wants to get the domain sequence for a 429 multi-domain path computation from a parent PCE, it can set the 430 Domain Path Request bit in the RP object carried in a PCReq message. 431 The parent PCE which receives the PCReq message tries to compute a 432 domain sequence for it. If the domain path computation succeeds the 433 parent PCE sends a PCRep message which carries the domain sequence in 434 the ERO to the child PCE . The domain sequence is specified as AS or 435 AREA ERO sub-objects (type 32 for AS [RFC3209] or type. Otherwise it 436 sends a PCReq message which carries the NO-PATH object to the child 437 PCE. 439 The parent PCE can set the Destination Domain Query bit in a PCReq 440 message to query the destination (which is specified in the 441 END-POINTS objects) domain ID from a child PCE. If the child PCE 442 knows the destination(s) domain ID, it sends a PCRep message to the 443 parent PCE and specifies the domain ID in the Domain-ID TLV which is 444 carried in the RP object. Otherwise it sends a PCRep message with a 445 NO-PATH object to the parent PCE. 447 3.3. Extensions to NOTIFICATION Object 449 Because there will not be too many PCEP sessions between the child 450 PCE(s) and parent PCE, it is recommended that the PCEP sessions 451 between them keeping alive all the time . Then the child PCE can 452 report all of the domain connectivity information to the parent PCE 453 when the PCEP session is established successfully. It can also notify 454 the parent PCE to update or delete the domain connectivity 455 information when it detects the changes. 457 3.3.1. Notification Types 459 There is a new notification type defined in this document : 461 o Domain Connectivity Information notification-type (to be assigned 462 by IANA, recommended 3). 464 Notification-value=0: sent from the parent to the child to query 465 all of the domain connectivity information maintained by the child 466 PCE. 468 Notification-value=1: sent from the child to the parent to update 469 the domain connectivity information maintained by the child PCE. 471 Notification-value=2: sent from the child to the parent to delete 472 the domain connectivity information maintained by the child PCE. 474 3.3.2. Inter-domain Link TLV 476 IGP in each neighbor domain can advertise its inter-domain TE link 477 capabilities [RFC5316], [RFC5392]. This information can be collected 478 by the child PCEs and forwarded to the parent PCE. PCEP Inter-domain 479 Link TLV is used for carrying the inter-domain TE link attributes for 480 this purpose. Each Inter-domain Link TLV can carry the attributes of 481 one inter-domain link at the most. 483 The type of Inter-domain Link TLV is to be assigned by IANA 484 (recommended 9). The length is variable. The format of this TLV is 485 defined below: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Advertise Router ID | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 // sub-TLVS // 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 3: Inter-domain Link TLV 499 Advertise Router ID (32 bits): indicates the router ID which 500 advertises the TE LSA or LSP. 502 Sub-TLVs: the OSPF sub-TLVs for a TE link which defined in [RFC5392] 503 and other associated OSPF RFCs. It is noted that if the IGP is IS-IS 504 for the child domain the sub-TLVs must be converted to the OSPF 505 sub-TLVs format when sending this information to the parent PCE 506 through PCEP PCNtf message. 508 Each inter-domain link is identified by the combination of advertise 509 router ID and the link local IP address or link local unnumbered 510 identifier. The PCNtf message which is used for notifying the parent 511 PCE to update or delete a inter-domain link must contain the 512 information identifies a TE link exclusively. 514 3.3.3. Inter-domain Node TLV 516 The Inter-domain Node TLV carries only the two adjacent domain ID and 517 the router (IGP ABR) ID. 519 The type of Inter-domain Node Information TLV is to be assigned by 520 IANA (recommended 10). The length is variable . The format of this 521 TLV is defined below: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | ABR ID | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Area ID1 | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Area ID2 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 4 : Inter-domain Node TLV 535 ABR ID (32 bits): indicates the domain border router ID. 537 Area ID1 & Area ID2 (32 bits): indicates the two neighbor area IDs. 539 3.3.4. Domain-ID TLV 541 The format of this TLV is defined in section 2.1.3. This TLV can be 542 carried in a NOTIFICATION object to indicate the domain ID of the 543 PCE who sends the PCNtf message. 545 Editors note. A PCE may be responsible for several domains, it may be 546 beneficial to use a list of TLVs. 548 3.3.5. PCE-ID TLV 550 The format of this TLV is defined in section 2.1.4. This TLV can be 551 carried in a NOTIFICATION object to indicate the PCE ID of the PCE 552 who sends the PCNtf message. 554 3.3.6. Procedures 556 When a parent PCE establishes a PCEP session with a child PCE 557 successfully, the parent PCE may request the child PCE to report the 558 domain connectivity information. This procedure can be done by 559 sending a PCNtf message from the parent to the child, setting the 560 notification-type to 3 and notification-value to 0 in the 561 NOTIFICATION object. 563 When a child PCE receives the PCNtf message, it may send all of the 564 domain connectivity information to the parent PCE by the PCNtf 565 message(s). The notification-type is 3 and notification-value is 1 in 566 the NOTIFICATION object. The NOTIFICATION object may carry the 567 inter-domain link TLV and inter-domain node TLV to describe the 568 inter-domain connectivity information. It is noted that if the child 569 PCE dose not support this function, it will ignore the received PCNtf 570 message and the parent PCE will not receive the response. 572 The child PCE can also update the domain connectivity information by 573 re-sending the PCNtf message(s) with the newly information. 575 When the child PCE detects a deletion of domain connectivity (e.g., 576 the inter-domain link TLV is aged out), it must notify the parent PCE 577 to delete the inter-domain link by sending the PCNtf message. The 578 notification-type is 3 and notification-value is 2 in the 579 NOTIFICATION object. 581 3.4. Extensions to PCEP-ERROR Object 583 3.4.1. Hierarchy PCE Error-Type 585 A new PCEP Error-Type is allocated for hierarchy PCE (to be assigned 586 by IANA, recommended 11): 588 Error-Type Meaning 589 11 Hierarchy PCE error 590 Error-value=1: parent PCE capability can not be 591 provided 593 3.4.2. Procedures 595 When a specific child PCE sends a PCReq to a peer PCE that requires 596 parental activity and the peer PCE does not want to act as the parent 597 for it, the peer PCE should send a PCErr message to the child PCE and 598 specify the error-type (11) and error-value (1) in the PCEP-ERROR 599 object. 601 4. Manageability Considerations 603 TBD. 605 5. IANA Considerations 607 TBD. 609 6. Security Considerations 611 TBD. 613 7. References 615 7.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 621 Computation Element (PCE) Communication Protocol (PCEP)", 622 RFC 5440, March 2009. 624 7.2. Informative References 626 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 627 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 628 Tunnels", RFC 3209, December 2001. 630 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 631 Computation Element (PCE)-Based Architecture", RFC 4655, 632 August 2006. 634 [RFC5316] M. Chen, R. Zhang, X. Duan, " ISIS Extensions in 635 Support of Inter-Autonomous System (AS) MPLS and GMPLS 636 Traffic Engineering ", RFC 5316, December 2008. 638 [RFC5392] M. Chen, R. Zhang, X. Duan, " OSPF Extensions in 639 Support of Inter-Autonomous System (AS) MPLS and GMPLS 640 Traffic Engineering ", RFC 5316, January 2009. 642 [PCE-HIERARCHY-FWK] D. King, A. Farrel, " The Application of the Path 643 Computation Element Architecture to the Determination 644 of a Sequence of Domains in MPLS and GMPLS ", 645 draft-king-pce-hierarchy-fwk-05, September 2010. 647 Authors' Addresses 649 Fatai Zhang 650 Huawei Technologies 651 F3-5-B R&D Center, Huawei Base 652 Bantian, Longgang District 653 Shenzhen 518129 P.R.China 654 Phone: +86-755-28972912 655 Email: zhangfatai@huawei.com 657 Quintin Zhao 658 Huawei Technology 659 125 Nagog Technology Park 660 Acton, MA 01719 661 US 662 Email: qzhao@huawei.com 664 Oscar Gonzalez de Dios 665 Telefonica I+D 666 Emilio Vargas 6, Madrid 667 Spain 668 Email: ogondio@tid.es 670 Ramon Casellas 671 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 672 Av. Carl Friedrich Gauss n7 673 Castelldefels, Barcelona 08860 674 Spain 675 Email: ramon.casellas@cttc.es 677 Daniel King 678 Old Dog Consulting 679 Email: daniel@olddog.co.uk