idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2018) is 2245 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-01 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-08 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-06 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 == Outdated reference: A later version (-03) exists of draft-palle-pce-controller-labeldb-sync-02 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track D. Dhody 5 Expires: September 5, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 March 4, 2018 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of SR-LSPs 15 draft-zhao-pce-pcep-extension-pce-controller-sr-02 17 Abstract 19 In certain networks deployment scenarios, service providers would 20 like to keep all the existing MPLS functionalities in both MPLS and 21 GMPLS while removing the complexity of existing signaling protocols 22 such as LDP and RSVP-TE. PCE has been proposed to be used as a 23 central controller (PCECC) so that LSP can be calculated/setup/ 24 initiated and label forwarding entries are downloaded through a 25 centralized PCE server to each network devices along the path while 26 leveraging the existing PCE technologies as much as possible. 28 This document specifies the procedures and PCEP protocol extensions 29 when the PCE functions as one of the central controller components in 30 Segment Routing(SR). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 5, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Procedures for Using the PCE as the Central Controller 72 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 6 73 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 74 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 75 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 6 76 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 77 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 78 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 7 79 5.5.1.1. PCECC SR Node/Prefix Label allocation . . . . . . 8 80 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 9 81 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 10 82 5.5.1.4. Session Termination . . . . . . . . . . . . . . . 11 83 5.5.1.5. LABEL-DB Synchronization . . . . . . . . . . . . 11 84 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 11 86 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 12 87 6.1.2. The PCLabelRpt message . . . . . . . . . . . . . . . 12 88 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 13 89 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 13 90 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 13 91 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 14 92 7.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 14 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 95 9.1. Control of Function and Policy . . . . . . . . . . . . . 16 96 9.2. Information and Data Models . . . . . . . . . . . . . . . 16 97 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 98 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 99 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 100 9.6. Impact On Network Operations . . . . . . . . . . . . . . 17 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 102 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 17 103 10.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 17 104 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 17 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 108 12.2. Informative References . . . . . . . . . . . . . . . . . 19 109 Appendix A. Using existing PCEP message . . . . . . . . . . . . 22 110 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 23 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 113 1. Introduction 115 The Path Computation Element communication Protocol (PCEP) provides 116 mechanisms for Path Computation Elements (PCEs) to perform route 117 computations in response to Path Computation Clients (PCCs) requests. 118 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 119 [RFC8231] describes a set of extensions to PCEP to enable active 120 control of MPLS-TE and GMPLS tunnels. 122 [RFC8281] describes the setup and tear down of PCE-initiated LSPs 123 under the active stateful PCE model, without the need for local 124 configuration on the PCC, thus allowing for a dynamic MPLS network 125 that is centrally controlled and deployed. 127 [RFC8283] introduces the architecture for PCE as a central 128 controller, examines the motivations and applicability for PCEP as a 129 southbound interface, and introduces the implications for the 130 protocol. [I-D.ietf-teas-pcecc-use-cases] describes the use cases 131 for the PCECC architecture. 133 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the PCEP 134 extension for the PCE as the central controller (PCECC). This 135 document extends the PCECC procedures for Segment Routing (SR). 137 Segment Routing (SR) technology leverage the source routing and 138 tunneling paradigms. A source node can choose a path without relying 139 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 140 is specified as a set of "segments" advertised by link- state routing 141 protocols (IS-IS or OSPF). 143 [I-D.ietf-spring-segment-routing] provides an introduction to SR 144 technology. The corresponding IS-IS and OSPF extensions are 145 specified in [I-D.ietf-isis-segment-routing-extensions] and 146 [I-D.ietf-ospf-segment-routing-extensions] , respectively. 148 A Segment Routed path (SR path) can be derived from an IGP Shortest 149 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 150 paths) may not follow IGP SPT. Such paths may be chosen by a 151 suitable network planning tool and provisioned on the source node of 152 the SR-TE path. 154 It is possible to use a stateful PCE for computing one or more SR-TE 155 paths taking into account various constraints and objective 156 functions. Once a path is chosen, the stateful PCE can instantiate 157 an SR-TE path on a PCC using PCEP extensions specified in [RFC8281] 158 using the SR specific PCEP extensions described in 159 [I-D.ietf-pce-segment-routing]. 161 PCECC may further use PCEP protocol for SR label distribution instead 162 of IGP extensions with some benefits. 164 The [I-D.zhao-pce-pcep-extension-for-pce-controller], specifies the 165 procedures and PCEP protocol extensions for using the PCE as one of 166 the the central controller components and user cases where LSPs are 167 calculated/setup/initiated and label forwarding entries are 168 downloaded on each hop along the path, through extending the existing 169 PCE architectures and PCEP. 171 This draft specify the procedures and PCEP protocol extensions for 172 using the PCE as the central controller for SR label distribution and 173 user cases where SR LSPs are calculated/setup/initiated/downloaded 174 through extending the existing PCE architectures and PCEP. 176 [Important Note - Note that this document achieves by extending the 177 new PCEP message defined in 178 [I-D.zhao-pce-pcep-extension-for-pce-controller]. The authors and WG 179 also debated on the use of existing PCEP messages. Section 5 defines 180 the first approach where as Appendix A defines the latter. The 181 authors are open to either of the approach and will follow the 182 direction of the WG.] 184 1.1. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 2. Terminology 194 Terminologies used in this document is same as described in the draft 195 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 197 3. PCECC SR 199 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 200 allow a stateful PCE to compute, update or initiate SR-TE paths. An 201 ingress node of an SR-TE path appends all outgoing packets with a 202 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 203 capable of carrying a label (SID) as well as the identity of the 204 node/adjacency label (SID). 206 The notion of segment and SID is defined in 207 [I-D.ietf-spring-segment-routing], which fits the MPLS architecture 208 [RFC3031] as the label which is managed by a local allocation process 209 of LSR (similarly to other MPLS signaling protocols) 210 [I-D.ietf-spring-segment-routing-mpls]. The SR information such as 211 node/adjacency label (SID) is flooded via IGP as specified in 212 [I-D.ietf-isis-segment-routing-extensions] and 213 [I-D.ietf-ospf-segment-routing-extensions]. 215 As per [RFC8283], PCE as a central controller can allocate and 216 provision the node/adjacency label (SID) via PCEP. 218 Rest of the processing is similar to existing stateful PCE with SR 219 mechanism. 221 For the purpose of this document, it is assumed that label range to 222 be used by a PCE is set on both PCEP peers. Further, a global label 223 range is assumed to be set on all PCEP peers in the SR domain. 225 4. PCEP Requirements 227 Following key requirements for PCECC-SR should be considered when` 228 designing the PCECC based solution: 230 o PCEP speaker supporting this draft MUST have the capability to 231 advertise its PCECC-SR capability to its peers. 233 o PCEP speaker not supporting this draft MUST be able to reject 234 PCECC-SR related message with a reason code that indicates no 235 support for PCECC. 237 o PCEP SHOULD provide a means to update (or cleanup) the label- map 238 entry to the PCC. 240 o PCEP SHOULD provide a means to synchronize the SR labels between 241 PCE to PCC in PCEP messages. 243 5. Procedures for Using the PCE as the Central Controller (PCECC) in 244 Segment Routing 246 5.1. Stateful PCE Model 248 Active stateful PCE is described in [RFC8231]. PCE as a central 249 controller (PCECC) reuses existing Active stateful PCE mechanism as 250 much as possible to control the LSP. 252 5.2. New LSP Functions 254 This document uses the same PCEP messages and its extenstions which 255 are described in [I-D.zhao-pce-pcep-extension-for-pce-controller] for 256 PCECC-SR as well. 258 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send PCECC-SR 259 Reports, LSP setup and LSP update respectively. 261 PCLabelUpd message described in 262 [I-D.zhao-pce-pcep-extension-for-pce-controller] is used to download 263 or cleanup SR Label entry. 265 PCLabelRpt message described in 266 [I-D.zhao-pce-pcep-extension-for-pce-controller] is also used to 267 report the set of SR Label entries from PCC to PCE for which explicit 268 action is required from PCE (update or cleanup or do nothing for 269 these Label entries). 271 [Editor's Note: [I-D.zhao-pce-pcep-extension-for-pce-controller] 272 defines new messages PCLabelUpd and PCLabelRpt. The authors and WG 273 also debated on the use of existing PCEP messages. Further the 274 document also includes an appendix on how the existing messages can 275 be extended to add this functionality. WG needs to decide the final 276 direction i.e. new specific messages are needed or existing PCEP 277 messages can be extended. See See Appendix A to see the extension of 278 existing message for PCECC-SR functionality.] 280 5.3. PCECC Capability Advertisement 282 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 283 advertise their support of PCECC extensions. A PCEP Speaker includes 284 the "PCECC Capability" sub-TLV, described in 285 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 287 A new S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support 288 for PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY sub-TLV and 289 include SR-PCE-CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing]) in 290 OPEN Object (inside the the PATH-SETUP-TYPE-CAPABILITY TLV) to 291 support the PCECC SR extensions defined in this document. If S-bit 292 is set in PCECC-CAPABILITY sub-TLV and SR-PCE-CAPABILITY sub-TLV is 293 not advertised in OPEN Object, PCE SHOULD send a PCErr message with 294 Error-Type=19 (Invalid Operation) and Error-value=TBD(SR capability 295 was not advertised) and terminate the session. 297 5.4. PCEP session IP address and TEDB Router ID 299 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 300 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 301 alternative is offered by BGP-LS [RFC7752] and 302 [I-D.dhodylee-pce-pcep-ls]. 304 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 305 session. It is important to link the session IP address with the 306 Router ID in TEDB for successful PCECC operations. 308 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 309 information. Thus a PCC includes the "Node Attributes TLV" 310 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 311 in the OPEN Object for this purpose. [RFC7752] describes the usage 312 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 313 purposes. If there are more than one auxiliary Router-ID of a given 314 type, then multiple TLVs are used to encode them. 316 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 317 address is directly used for the mapping purpose. 319 5.5. LSP Operations 321 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 322 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 323 identify the PCECC-SR LSP is intended. 325 5.5.1. PCECC Segment Routing (SR) 327 Segment Routing (SR) as described in 328 [I-D.ietf-spring-segment-routing] depends on "segments" that are 329 advertised by Interior Gateway Protocols (IGPs). The SR-node 330 allocates and advertises the SID (node, adj etc) and flood via the 331 IGP. This document proposes a new mechanism where PCE allocates the 332 SID (label) centrally and uses PCEP to advertise the SID. In some 333 deployments PCE (and PCEP) are better suited than IGP because of 334 centralized nature of PCE and direct TCP based PCEP session to the 335 node. 337 5.5.1.1. PCECC SR Node/Prefix Label allocation 339 Each node (PCC) is allocated a node-SID (label) by the PCECC. The 340 PCECC sends PCLabelUpd to update the label map of each node to all 341 the nodes in the domain. The TE router ID is determined from the 342 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 343 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 345 Note: See Appendix A for how we could use PCInitiate message 346 instead.] 348 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 349 different session IP address during TCP session establishment than 350 the node Router ID in TEDB, to make sure that the PCEP session does 351 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 353 If a node (PCC) receives a PCLabelUpd message with a Label, out of 354 the range set aside for the global label, it MUST send a PCErr 355 message with Error-type=TBD (label download failure) and Error- 356 value=TBD (Label out of range) and MUST include the SRP object to 357 specify the error is for the corresponding label update 358 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 360 On receiving the label map, each node (PCC) uses the local 361 information to determine the next-hop and download the label 362 forwarding instructions accordingly. The PCLabelUpd message in this 363 case MUST NOT have LSP object but uses new FEC object. 365 +---------+ +-------+ 366 |PCC | | PCE | 367 |192.0.2.3| +-------+ 368 +------| | | 369 | PCC +---------+ | 370 | 192.0.2.2| | | 371 +------| | | | 372 |PCC +----------+ | | 373 |192.0.2.1| | | | 374 +---------+ | | | 375 | | | | 376 |<------- PCLabelUpd, FEC=192.0.2.1---------------- | Label Map 377 | | | Label=X | update 378 |Find | | | 379 |Nexthop|<------- PCLabelUpd, FEC=192.0.2.1-------- | Label Map 380 |locally| | Label=X | update 381 | | | | 382 | | |<--- PCLabelUpd, FEC=192.0.2.1---- | Label Map 383 | | | Label=X | update 384 | | | | 386 The forwarding behaviour and the end result is similar to IGP based 387 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 388 ECMP-aware shortest-path forwarding of the packet towards the related 389 node. 391 PCE relies on the Node/Prefix Label cleanup using the same PCLabelUpd 392 message. 394 5.5.1.2. PCECC SR Adjacency Label allocation 396 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 397 to compute and initiate SR-TE paths, as well as a PCC to request a 398 path subject to certain constraint(s) and optimization criteria in SR 399 networks. 401 For PCECC SR, apart from node-SID, Adj-SID is used where each 402 adjacency is allocated an Adj-SID (label) by the PCECC. The PCECC 403 sends PCLabelUpd to update the label map of each Adj to the 404 corresponding nodes in the domain. Each node (PCC) download the 405 label forwarding instructions accordingly. Similar to SR Node/Prefix 406 Label allocation, the PCLabelUpd message in this case MUST NOT have 407 LSP object but uses new FEC object. Note: See Appendix A for how we 408 could use PCInitiate message instead.] 409 +---------+ +-------+ 410 |PCC | | PCE | 411 |192.0.2.3| +-------+ 412 +------| | | 413 | PCC +---------+ | 414 | 192.0.2.2| | | 415 +------| | | | 416 |PCC +----------+ | | 417 |192.0.2.1| | | | 418 +---------+ | | | 419 | | | | 420 |<------ PCLabelUpd, FEC=192.0.2.1 / ------------ | Label Map 421 | | | 192.0.2.2 | update 422 | | | Label=A | 423 | | | | 424 | |<----- PCLabelUpd, FEC=192.0.2.2------- | Label Map 425 | | | 192.0.2.1 | update 426 | | | Label=B | 427 | | | | 429 The forwarding behavior and the end result is similar to IGP based 430 "Adj-SID" in SR. 432 The Path Setup Type for segment routing MUST be set for PCECC SR (see 433 Section 7.2). All PCEP procedures and mechanism are similar to 434 [I-D.ietf-pce-segment-routing]. 436 PCE relies on the Adj label cleanup using the same PCLabelUpd 437 message. 439 5.5.1.3. Redundant PCEs 441 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 442 between the stateful PCEs. The SR Labels allocated by a PCE should 443 also be synchronized among PCEs for PCECC SR state synchronization. 444 Note that the SR labels are downloaded independent to the PCECC LSP, 445 and remains intact till any topology change. The redundant PCEs MUST 446 have a common view of all SR labels allocated in the domain. 448 Incase the session to the PCE that allocated the SR labels is down, 449 similar to the LSP re-delegation mechanims, the SR labels are re- 450 delegated to a redundant PCE using the PCLabelRpt message. This is 451 done so that the SR labels remains intact and cosntant in case of 452 session disconnect. 454 5.5.1.4. Session Termination 456 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes the action 457 needed for label provisioned for the Basic PCECC LSP on this 458 terminated session. Similarly actions should be applied for SR 459 Labels as well. 461 Additionally, if PCC has any alternate PCEP session with another PCE, 462 then PCC MUST deligate the SR labels of this session to this 463 alternate PCE in a sequence of PCLabelRpt message. PCE can accept it 464 and can send PCLabelUpd message to update or clean the label. 466 Extensions for PCLabelUpd and PCLabelRpt message for SR label are 467 described in Section 6.1. 469 5.5.1.5. LABEL-DB Synchronization 471 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes LABEL-DB 472 Synchronization procedures needed for the labels provisioned for the 473 Basic PCECC LSP. Same procedures should be applied for SR labels as 474 well. 476 See [I-D.palle-pce-controller-labeldb-sync] for the optimizations for 477 LABEL-DB synchronization procedure. 479 6. PCEP messages 481 As defined in [RFC5440], a PCEP message consists of a common header 482 followed by a variable-length body made of a set of objects that can 483 be either mandatory or optional. An object is said to be mandatory 484 in a PCEP message when the object must be included for the message to 485 be considered valid. For each PCEP message type, a set of rules is 486 defined that specify the set of objects that the message can carry. 487 An implementation MUST form the PCEP messages using the object 488 ordering specified in this document. 490 6.1. Label Operations 492 [Editor's Note: [I-D.zhao-pce-pcep-extension-for-pce-controller] 493 defines new messages PCLabelUpd and PCLabelRpt. The authors and WG 494 also debated on the use of existing PCEP messages. Further the 495 document also includes an appendix on how the existing messages can 496 be extended to add this functionality. WG needs to decide the final 497 direction i.e. new specific messages are needed or existing PCEP 498 messages can be extended. See See Appendix A to see the extension of 499 existing message for PCECC-SR functionality.] 501 6.1.1. The PCLabelUpd message 503 Label Update Message (PCLabelUpd) defined in 504 [I-D.zhao-pce-pcep-extension-for-pce-controller] is extended to 505 update the label map at the PCC. 507 The format of the extended PCLabelUpd message is as follows: 509 ::= 510 511 Where: 512 ::= 513 [] 515 ::= (|) 517 Where: 519 ::= 520