idnits 2.17.1 draft-ietf-pce-stateful-sync-optimizations-09.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 (February 28, 2017) is 2614 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) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-01 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft Oracle 4 Intended status: Standards Track I. Minei 5 Expires: September 1, 2017 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 X. Zhang 11 D. Dhody 12 Huawei Technologies 13 February 28, 2017 15 Optimizations of Label Switched Path State Synchronization Procedures 16 for a Stateful PCE 17 draft-ietf-pce-stateful-sync-optimizations-09 19 Abstract 21 A stateful Path Computation Element (PCE) has access to not only the 22 information disseminated by the network's Interior Gateway Protocol 23 (IGP), but also the set of active paths and their reserved resources 24 for its computation. The additional Label Switched Path (LSP) state 25 information allows the PCE to compute constrained paths while 26 considering individual LSPs and their interactions. This requires a 27 state synchronization mechanism between the PCE and the network, PCE 28 and path computation clients (PCCs), and between cooperating PCEs. 29 The basic mechanism for state synchronization is part of the stateful 30 PCE specification. This document presents motivations for 31 optimizations to the base state synchronization procedure and 32 specifies the required Path Computation Element Communication 33 Protocol (PCEP) extensions. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 1, 2017. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. State Synchronization Avoidance . . . . . . . . . . . . . . . 4 78 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.2. State Synchronization Avoidance Procedure . . . . . . . . 4 80 3.2.1. IP Address change during session re-establishment . . 9 81 3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 10 82 3.3.1. LSP State Database Version Number TLV . . . . . . . . 10 83 3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 11 84 4. Incremental State Synchronization . . . . . . . . . . . . . . 12 85 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.2. Incremental Synchronization Procedure . . . . . . . . . . 13 87 5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 16 88 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 16 89 5.2. PCE-triggered Initial State Synchronization Procedure . . 17 90 6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . 18 91 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 18 92 6.2. PCE-triggered State Re-synchronization Procedure . . . . 18 93 7. Advertising Support of Synchronization Optimizations . . . . 19 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 20 96 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 21 97 8.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 21 98 9. Manageability Considerations . . . . . . . . . . . . . . . . 21 99 9.1. Control of Function and Policy . . . . . . . . . . . . . 21 100 9.2. Information and Data Models . . . . . . . . . . . . . . . 21 101 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 22 102 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 22 103 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 22 104 9.6. Impact On Network Operations . . . . . . . . . . . . . . 22 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 106 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 107 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 110 13.2. Informative References . . . . . . . . . . . . . . . . . 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 path 117 computations in response to Path Computation Clients (PCCs) requests. 119 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 120 provide stateful control. A stateful PCE has access to not only the 121 information carried by the network's Interior Gateway Protocol (IGP), 122 but also the set of active paths and their reserved resources for its 123 computations. The additional state allows the PCE to compute 124 constrained paths while considering individual LSPs and their 125 interactions. This requires a state synchronization mechanism 126 between the PCE and the network, PCE and PCC, and between cooperating 127 PCEs. [I-D.ietf-pce-stateful-pce] describes the basic mechanism for 128 state synchronization. This document specifies following 129 optimizations for state synchronization and the corresponding PCEP 130 procedures and extensions: 132 o State Synchronization Avoidance: To skip state synchronization if 133 the state has survived and not changed during session restart. 134 (See Section 3.) 136 o Incremental State Synchronization: To do incremental (delta) state 137 synchronization when possible. (See Section 4.) 139 o PCE-triggered Initial Synchronization: To let PCE control the 140 timing of the initial state synchronization. (See Section 5.) 142 o PCE-triggered Re-synchronization: To let PCE re-synchronize the 143 state for sanity check. (See Section 6.) 145 Support for each of the synchronization optimization capabilities is 146 advertised during the PCEP initialization phase. See Section 7 for 147 the new flags defined in this document. The handling of each flag is 148 described in the relevant section. 150 2. Terminology 152 This document uses the following terms defined in [RFC5440]: PCC, 153 PCE, PCEP Peer. 155 This document uses the following terms defined in [RFC8051]: Stateful 156 PCE, Delegation, LSP State Database. 158 This document uses the following terms defined in 159 [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State 160 Report, LSP Update Request. 162 Within this document, when describing PCE-PCE communications, one of 163 the PCEs fills the role of a PCC. This provides a saving in 164 documentation without loss of function. 166 3. State Synchronization Avoidance 168 3.1. Motivation 170 The purpose of state synchronization is to provide a checkpoint-in- 171 time state replica of a PCC's LSP state in a stateful PCE. State 172 synchronization is performed immediately after the initialization 173 phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic 174 mechanism for state synchronization. 176 State synchronization is not always necessary following a PCEP 177 session restart. If the state of both PCEP peers did not change, the 178 synchronization phase may be skipped. This can result in significant 179 savings in both control-plane data exchanges and the time it takes 180 for the stateful PCE to become fully operational. 182 3.2. State Synchronization Avoidance Procedure 184 State synchronization MAY be skipped following a PCEP session restart 185 if the state of both PCEP peers did not change during the period 186 prior to session re-initialization. To be able to make this 187 determination, state must be exchanged and maintained by both PCE and 188 PCC during normal operation. This is accomplished by keeping track 189 of the changes to the LSP state database, using a version tracking 190 field called the LSP State Database Version Number. 192 The INCLUDE-DB-VERSION (S) bit in the stateful PCE capability TLV 193 (Section 7) is advertised on a PCEP session during session startup to 194 indicate that the LSP State Database Version Number is to be included 195 when the LSPs are reported to the PCE. The LSP State Database 196 Version Number, carried in LSP-DB-VERSION TLV (see Section 3.3.1), is 197 owned by a PCC and it MUST be incremented by 1 for each successive 198 change in the PCC's LSP state database. The LSP State Database 199 Version Number MUST start at 1 and may wrap around. Values 0 and 200 0xFFFFFFFFFFFFFFFF are reserved. If either of the two values are 201 used during LSP state (re)-synchronization, the PCE speaker receiving 202 this value MUST send back a PCErr with Error-type 20 Error-value TBD6 203 (suggested value - 6) 'Received an invalid LSP DB Version Number', 204 and close the PCEP session. Operations that trigger a change to the 205 local LSP state database include a change in the LSP operational 206 state, delegation of an LSP, removal or setup of an LSP or change in 207 any of the LSP attributes that would trigger a report to the PCE. 209 If the include LSP DB version capability is enabled, a PCC MUST 210 increment its LSP State Database Version Number when the 211 'Redelegation Timeout Interval' timer expires (see 212 [I-D.ietf-pce-stateful-pce] for the use of the Redelegation Timeout 213 Interval). 215 If both PCEP speakers set the S flag in the OPEN object's STATEFUL- 216 PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV 217 in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV 218 is missing in a PCRpt message, the PCE will generate an error with 219 Error-Type 6 (mandatory object missing) and Error-Value TBD1 220 (suggested value - 12) 'LSP-DB-VERSION TLV missing' and close the 221 session. If the include LSP DB version capability has not been 222 enabled on a PCEP session, the PCC SHOULD NOT include the LSP-DB- 223 VERSION TLV in the LSP Object and the PCE MUST ignore it were it to 224 receive one. 226 If a PCE's LSP state database survived the restart of a PCEP session, 227 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 228 the TLV will contain the last LSP State Database Version Number 229 received on an LSP State Report from the PCC in the previous PCEP 230 session. If a PCC's LSP State Database survived the restart of a 231 PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN 232 object and the TLV will contain the latest LSP State Database Version 233 Number. If a PCEP speaker's LSP state database did not survive the 234 restart of a PCEP session or at startup when the database is empty, 235 the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN 236 object. 238 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 239 Object and the TLV values match, the PCC MAY skip state 240 synchronization and the PCE does not wait for the end of 241 synchronization marker [I-D.ietf-pce-stateful-pce]. Otherwise, the 242 PCC MUST perform full state synchronization (see 243 [I-D.ietf-pce-stateful-pce]) or incremental state synchronization 244 (see Section 4 if this capability is advertised) to the stateful PCE. 245 In other words, if the incremental state synchronization capability 246 is not advertised by the peers, based on the LSP database version 247 number match either the state synchronization is skipped or a full 248 state synchronization is performed. If the PCC attempts to skip 249 state synchronization, by setting the SYNC Flag to 0 and PLSP-ID to a 250 non-zero value on the first LSP State Report from the PCC as per 251 [I-D.ietf-pce-stateful-pce], the PCE MUST send back a PCErr with 252 Error-Type 20 Error-Value TBD2 (suggested value - 2) 'LSP Database 253 version mismatch', and close the PCEP session. 255 If state synchronization is required, then prior to completing the 256 initialization phase, the PCE MUST mark any LSPs in the LSP database 257 that were previously reported by the PCC as stale. When the PCC 258 reports an LSP during state synchronization, if the LSP already 259 exists in the LSP database, the PCE MUST update the LSP database and 260 clear the stale marker from the LSP. When it has finished state 261 synchronization, the PCC MUST immediately send an end of 262 synchronization marker. The end of synchronization marker is a Path 263 Computation State Report (PCRpt) message with an LSP object 264 containing a PLSP-ID of 0 and with the SYNC flag set to 0 265 ([I-D.ietf-pce-stateful-pce]). The LSP-DB-VERSION TLV MUST be 266 included in this PCRpt message. On receiving this state report, the 267 PCE MUST purge any LSPs from the LSP database that are still marked 268 as stale. 270 Note that a PCE/PCC MAY force state synchronization by not including 271 the LSP-DB-VERSION TLV in its OPEN object. 273 Since a PCE does not make changes to the LSP State Database Version 274 Number, a PCC should never encounter this TLV in a message from the 275 PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- 276 VERSION TLV, were it to receive one from a PCE. 278 Figure 1 shows an example sequence where the state synchronization is 279 skipped. 281 +-+-+ +-+-+ 282 |PCC| |PCE| 283 +-+-+ +-+-+ 284 | | 285 |--Open--, | 286 | DBv=42 \ ,---Open--| 287 | S=1 \ / DBv=42 | 288 | \/ S=1 | 289 | /\ | 290 | / `-------->| (OK to skip sync) 291 (Skip sync) |<--------` | 292 | . | 293 | . | 294 | . | 295 | | 296 |--PCRpt,DBv=43,SYNC=0-->| (Regular 297 | | LSP State Report) 298 |--PCRpt,DBv=44,SYNC=0-->| (Regular 299 | | LSP State Report) 300 |--PCRpt,DBv=45,SYNC=0-->| 301 | | 303 Figure 1: State Synchronization Skipped 305 Figure 2 shows an example sequence where the state synchronization is 306 performed due to LSP state database version mismatch during the PCEP 307 session setup. Note that the same state synchronization sequence 308 would happen if either the PCC or the PCE would not include the LSP- 309 DB-VERSION TLV in their respective Open messages. 311 +-+-+ +-+-+ 312 |PCC| |PCE| 313 +-+-+ +-+-+ 314 | | 315 |--Open--, | 316 | DBv=46 \ ,---Open--| 317 | S=1 \ / DBv=42 | 318 | \/ S=1 | 319 | /\ | 320 | / `-------->| (Expect sync) 321 (Do sync) |<--------` | 322 | | 323 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 324 | . | 325 | . | 326 | . | 327 |--PCRpt,DBv=46,SYNC=0-->| (Sync done) 328 | . |(Purge LSP State 329 | . | if applicable) 330 | . | 331 |--PCRpt,DBv=47,SYNC=0-->| (Regular 332 | | LSP State Report) 333 |--PCRpt,DBv=48,SYNC=0-->| (Regular 334 | | LSP State Report) 335 |--PCRpt,DBv=49,SYNC=0-->| 336 | | 338 Figure 2: State Synchronization Performed 340 Figure 3 shows an example sequence where the state synchronization is 341 skipped, but because one or both PCEP speakers set the S Flag to 0, 342 the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt 343 messages to the PCE. If the current PCEP session restarts, the PCEP 344 speakers will have to perform state synchronization, since the PCE 345 does not know the PCC's latest LSP State Database Version Number 346 information. 348 +-+-+ +-+-+ 349 |PCC| |PCE| 350 +-+-+ +-+-+ 351 | | 352 |--Open--, | 353 | DBv=42 \ ,---Open--| 354 | S=0 \ / DBv=42 | 355 | \/ S=0 | 356 | /\ | 357 | / `-------->| (OK to skip sync) 358 (Skip sync) |<--------` | 359 | . | 360 | . | 361 | . | 362 |------PCRpt,SYNC=0----->| (Regular 363 | | LSP State Report) 364 |------PCRpt,SYNC=0----->| (Regular 365 | | LSP State Report) 366 |------PCRpt,SYNC=0----->| 367 | | 369 Figure 3: State Synchronization Skipped, no LSP-DB-VERSION TLVs sent 370 from PCC 372 3.2.1. IP Address change during session re-establishment 374 There could be a case during PCEP session re-establishment when the 375 PCC's or PCE's IP address can change. This includes, but is not 376 limited to, the following cases: 378 o A PCC could use a physical interface IP address to connect to the 379 PCE. In this case, if the line card that the PCC connects from 380 changes, then the PCEP session goes down and comes back up again, 381 with a different IP address associated with a new line card. 383 o The PCC or PCE may move in the network, either physically or 384 logically, which may cause its IP address to change. For example, 385 the PCE may be deployed as a virtual network function (VNF) and 386 another virtualized instance of the PCE may be populated with the 387 original PCE instance's state, but be given a different IP 388 address. 390 To ensure that a PCEP peer can recognize a previously connected peer, 391 each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in 392 Section 3.3.2, in the OPEN message. 394 This TLV is used during the state synchronization procedure to 395 identify the PCEP session as a re-establishment of a previous session 396 that went down. Then state synchronization optimizations such as 397 state sync avoidance can be applied to this session. Note that this 398 usage is only applicable within the State Timeout Interval 399 [I-D.ietf-pce-stateful-pce]. After the State Timeout Interval 400 expires, all state associated with the PCEP session is removed, which 401 includes the SPEAKER-ENTITY-ID received. Note that the PCEP session 402 initialization [RFC5440] procedure remains unchanged. 404 3.3. PCEP Extensions 406 A new INCLUDE-DB-VERSION (S) bit is added in the stateful 407 capabilities TLV (see Section 7 for details). 409 3.3.1. LSP State Database Version Number TLV 411 The LSP State Database Version Number (LSP-DB-VERSION) TLV is an 412 optional TLV that MAY be included in the OPEN object and the LSP 413 object. 415 This TLV is included in the LSP object in the PCRpt message to 416 indicate the LSP DB version at the PCC. This TLV SHOULD NOT be 417 included in other PCEP messages (PCUpd, PcReq, PCRep) and MUST be 418 ignored if received. 420 The format of the LSP-DB-VERSION TLV is shown in the following 421 figure: 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type=TBD5 | Length=8 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | LSP State DB Version Number | 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 4: LSP-DB-VERSION TLV format 434 The type of the TLV is TBD5 and it has a fixed length of 8 octets. 435 The value contains a 64-bit unsigned integer, carried in network byte 436 order, representing the LSP State DB Version Number. 438 3.3.2. Speaker Entity Identifier TLV 440 The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional 441 TLV that MAY be included in the OPEN Object when a PCEP speaker 442 wishes to determine if state synchronization can be skipped when a 443 PCEP session is restarted. It contains a unique identifier for the 444 node that does not change during the lifetime of the PCEP speaker. 445 It identifies the PCEP speaker to its peers even if the speaker's IP 446 address is changed. 448 In case of a remote peer IP address change, a PCEP speaker would 449 learn the speaker entity identifier on receiving the open message but 450 it MAY have already sent its open message without realizing that it 451 is a known PCEP peer. In such a case, either a full synchronization 452 is done or PCEP session is terminated. This may be a local policy 453 decision. The new IP address is associated with the speaker entity 454 identifier for future either way. In the latter case when PCEP 455 session is re-established, it would be correctly associated with 456 speaker entity identifier and not be considered as an unknown peer. 458 The format of the SPEAKER-ENTITY-ID TLV is shown in the following 459 figure: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type=TBD13 | Length (variable) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 // Speaker Entity Identifier // 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 5: SPEAKER-ENTITY-ID TLV format 473 The type of the TLV is TBD13 and it has a variable length, which MUST 474 be greater than 0. The Value is padded to 4-octet alignment. The 475 padding is not included in the Length field. The value contains the 476 entity identifier of the speaker transmitting this TLV. This 477 identifier is required to be unique within its scope of visibility, 478 which is usually limited to a single domain. It MAY be configured by 479 the operator. Alternatively, it can be derived automatically from a 480 suitably-stable unique identifier, such as a MAC address, serial 481 number, Traffic Engineering Router ID, or similar. In the case of 482 inter-domain connections, the speaker SHOULD prefix its usual 483 identifier with the domain identifier of its residence, such as 484 Autonomous System number, IGP area identifier, or similar to make 485 sure it remains unique. 487 The relationship between this identifier and entities in the Traffic 488 Engineering database is intentionally left undefined. 490 From a manageability point of view, a PCE or PCC implementation 491 SHOULD allow the operator to configure this Speaker Entity 492 Identifier. 494 If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP 495 session, that matches with an existing alive PCEP session, the PCEP 496 speaker MUST send a PCErr with Error-type 20 Error-value TBD7 497 (suggested value - 7) 'Received an invalid Speaker Entity 498 Identifier', and close the PCEP session. 500 4. Incremental State Synchronization 502 [I-D.ietf-pce-stateful-pce] describes the LSP state synchronization 503 mechanism between PCCs and stateful PCEs. During the state 504 synchronization, a PCC sends the information of all its LSPs (i.e., 505 the full LSP-DB) to the stateful PCE. In order to reduce the state 506 synchronization overhead when there is a small number of LSP state 507 change in the network between PCEP session restart, this section 508 defines a mechanism for incremental (Delta) LSP Database (LSP-DB) 509 synchronization. 511 4.1. Motivation 513 According to [I-D.ietf-pce-stateful-pce], if a PCE restarts and its 514 LSP-DB survived, PCCs with mismatched LSP State Database Version 515 Number will send all their LSPs information (full LSP-DB) to the 516 stateful PCE, even if only a small number of LSPs underwent state 517 change. It can take a long time and consume large communication 518 channel bandwidth. 520 Figure 6 shows an example of LSP state synchronization. 522 +-----+ 523 | PCE | 524 +-----+ 525 / 526 / 527 / 528 / 529 +------+ +------+ 530 | PCC1 |------------| PCC2 | 531 +------+ +------+ 532 | | 533 | | 534 +------+ +------+ 535 | PCC3 |------------| PCC4 | 536 +------+ +------+ 538 Figure 6: Topology Example 540 Assuming there are 320 LSPs in the network, with each PCC having 80 541 LSPs. During the time when the PCEP session is down, 20 LSPs of each 542 PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session 543 restarts, the stateful PCE needs to synchronize 320 LSPs with all 544 PCCs. But actually, 240 LSPs stay the same. If performing full LSP 545 state synchronization, it can take a long time to carry out the 546 synchronization of all LSPs. It is especially true when only a low 547 bandwidth communication channel is available (e.g., in-band control 548 channel for optical transport networks) and there is a substantial 549 number of LSPs in the network. Another disadvantage of full LSP 550 synchronization is that it is a waste of communication bandwidth to 551 perform full LSP synchronization given the fact that the number of 552 LSP changes can be small during the time when PCEP session is down. 554 An incremental (Delta) LSP Database (LSP-DB) state synchronization is 555 described in this section, where only the LSPs underwent state change 556 are synchronized between the session restart. This may include 557 new/modified/deleted LSPs. 559 4.2. Incremental Synchronization Procedure 561 [I-D.ietf-pce-stateful-pce] describes state synchronization and 562 Section 3 of this document, describes state synchronization avoidance 563 by using LSP-DB-VERSION TLV in its OPEN object. This section extends 564 this idea to only synchronize the delta (changes) in case of version 565 mismatch. 567 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 568 object and the LSP-DB-VERSION TLV values match, the PCC MAY skip 569 state synchronization. Otherwise, the PCC MUST perform state 570 synchronization. Incremental State synchronization capability is 571 advertised on a PCEP session during session startup using the DELTA- 572 LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7). 573 Instead of dumping full LSP-DB to the stateful PCE again, the PCC 574 synchronizes the delta (changes) as described in Figure 7 when D flag 575 and S flag is set to 1 by both PCC and PCE. Other combinations of D 576 and S flags setting by PCC and PCE result in full LSP-DB 577 synchronization procedure as described in 578 [I-D.ietf-pce-stateful-pce]. By setting the D flag to zero in the 579 OPEN message, a PCEP speaker can skip the incremental synchronization 580 optimization, resulting in a full LSP DB synchronization. 582 +-+-+ +-+-+ 583 |PCC| |PCE| 584 +-+-+ +-+-+ 585 | | 586 |--Open--, | 587 | DBv=46 \ ,---Open--| 588 | S=1 \ / DBv=42 | 589 | D=1 \/ S=1 | 590 | /\ D=1 | 591 | / \ | 592 | / `-------->| (Expect Delta sync) 593 (Do sync)|<--------` | (DONOT Purge LSP 594 (Delta) | | State) 595 | | 596 (Delta Sync starts) |--PCRpt,DBv=46,SYNC=1-->| 597 | . | 598 | . | 599 | . | 600 | . | 601 |--PCRpt,DBv=46,SYNC=0-->| (Sync done, 602 | | PLSP-ID=0) 603 | | 604 |--PCRpt,DBv=47,SYNC=0-->| (Regular 605 | | LSP State Report) 606 |--PCRpt,DBv=48,SYNC=0-->| (Regular 607 | | LSP State Report) 608 |--PCRpt,DBv=49,SYNC=0-->| 609 | | 611 Figure 7: Incremental Synchronization Procedure 613 As per Section 3, the LSP State Database Version Number is 614 incremented each time a change is made to the PCC's local LSP State 615 Database. Each LSP is associated with the DB version at the time of 616 its state change. This is needed to determine which LSP and what 617 information needs to be synchronized in incremental state 618 synchronization. The incremental state sync is done from the last 619 LSP DB version received by the PCE to the latest DB version at the 620 PCC. Note that the LSP State Database Version Number can wrap 621 around, and in which case the incremental state sync would also wrap 622 till the latest DB version number at the PCC. 624 In order to carry out incremental state synchronization, it is not 625 necessary for a PCC to store a complete history of LSP Database 626 change for all time, but remember the LSP state changes (including 627 LSP modification, setup and deletion), that the PCE did not get to 628 process during the session down. Note that, a PCC would be unaware 629 that a particular LSP report has been processed by the PCE before the 630 session to PCE went down. So a PCC implementation MAY choose to 631 store the LSP State Database Version Number with each LSP at the time 632 its status changed, so that when a session is re-established an 633 incremental synchronization can be attempted based on the PCE's last 634 LSP State Database Version Number. For an LSP that is deleted at the 635 PCC, the PCC implementation would need to remember the deleted LSP in 636 some way to make sure this could be reported as part of incremental 637 synchronization later. The PCC would discard this information based 638 on a local policy, or when it determines that this information is no 639 longer needed with sufficient confidence. In the example shown in 640 Figure 7, the PCC needs to store the LSP state changes that happened 641 between DB Version 43 to 46 and synchronizes these changes, when 642 performing incremental LSP state update. 644 If a PCC finds out it does not have sufficient information to 645 complete incremental synchronization after advertising incremental 646 LSP state synchronization capability, it MUST send a PCErr with 647 Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE that it can 648 not complete the state synchronization' (defined in 649 [I-D.ietf-pce-stateful-pce]) and terminate the session. The PCC 650 SHOULD re-establish the session with the D bit set to 0 in the OPEN 651 message. 653 The other procedures and error checks remain unchanged from the full 654 state synchronization ([I-D.ietf-pce-stateful-pce]). 656 5. PCE-triggered Initial Synchronization 658 5.1. Motivation 660 In networks such as optical transport networks, the control channel 661 between network nodes can be realized through in-band overhead thus 662 has limited bandwidth. With a stateful PCE connected to the network 663 via one network node, it is desirable to control the timing of PCC 664 state synchronization so as not to overload the low communication 665 channel available in the network during the initial synchronization 666 (be it incremental or full) when the session restarts , when there is 667 comparatively large amount of control information needing to be 668 synchronized between the stateful PCE and the network. The method 669 proposed, i.e., allowing PCE to trigger the state synchronization, is 670 similar to the function proposed in Section 6 but is used in 671 different scenarios and for different purposes. 673 5.2. PCE-triggered Initial State Synchronization Procedure 675 Support of PCE-triggered initial state synchronization is advertised 676 during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in 677 the STATEFUL-PCE-CAPABILITY TLV (see Section 7). 679 In order to allow a stateful PCE to control the LSP-DB 680 synchronization after establishing a PCEP session, both PCEP speakers 681 MUST set F bit to 1 in the OPEN message. If the LSP-DB-VERSION TLV 682 is included by both PCEP speakers and the TLV value matches, the 683 state synchronization can be skipped as described in Section 3.2. If 684 the TLV is not included or the LSP-DB Version is mis-matched, the PCE 685 can trigger the state synchronization process by sending a PCUpd 686 message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD 687 include an empty ERO (with no ERO sub-object and object length of 4) 688 as its intended path and SHOULD NOT include the optional objects for 689 its attributes for any parameter update. The PCC MUST ignore such an 690 update when the SYNC flag is set. If the TRIGGERED-INITIAL-SYNC 691 capability is not advertised by a PCE and the PCC receives a PCUpd 692 with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP- 693 ID-number of the PCUpd, Error-Type 20 and Error-Value TBD4 (suggested 694 value - 4) 'Attempt to trigger synchronization when the TRIGGERED- 695 SYNC capability has not been advertised' (see Section 8.1). If the 696 TRIGGERED-INITIAL-SYNC capability is advertised by a PCE and the PCC, 697 the PCC MUST NOT trigger state synchronization on its own. If the 698 PCE receives a PCRpt message before the PCE has triggered the state 699 synchronization, the PCE MUST send a PCErr with Error-Type 20 and 700 Error-Value TBD3 (suggested value - 3) 'Attempt to trigger 701 synchronization before PCE trigger' (see Section 8.1). 703 In this way, the PCE can control the sequence of LSP synchronization 704 among all the PCCs that are re-establishing PCEP sessions with it. 705 When the capability of PCE control is enabled, only after a PCC 706 receives this message, it will start sending information to the PCE. 707 This PCE-triggering capability can be applied to both full and 708 incremental state synchronization. If applied to the latter, the 709 PCCs only send information that PCE does not possess, which is 710 inferred from the LSP-DB version information exchanged in the OPEN 711 message (see Section 4.2 for detailed procedure). 713 Once the initial state synchronization is triggered by the PCE, the 714 procedures and error checks remain unchanged 715 ([I-D.ietf-pce-stateful-pce]). 717 If a PCC implementation that does not implement this extension should 718 not receive a PCUpd message to trigger state synchronization as per 719 the capability advertisement, but if it were to receive it, it will 720 behave as per [I-D.ietf-pce-stateful-pce]. 722 6. PCE-triggered Re-synchronization 724 6.1. Motivation 726 The accuracy of the computations performed by the PCE is tied to the 727 accuracy of the view the PCE has on the state of the LSPs. 728 Therefore, it can be beneficial to be able to re-synchronize this 729 state even after the session has been established. The PCE may use 730 this approach to continuously sanity check its state against the 731 network, or to recover from error conditions without having to tear 732 down sessions. 734 6.2. PCE-triggered State Re-synchronization Procedure 736 Support of PCE-triggered state re-synchronization is advertised by 737 both PCEP speakers during session startup using the TRIGGERED-RESYNC 738 (T) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7). The PCE 739 can choose to re-synchronize its entire LSP database or a single LSP. 741 To trigger re-synchronization for an LSP, the PCE sends a Path 742 Computation State Update (PCUpd) for the LSP, with the SYNC flag in 743 the LSP object set to 1. The PCE SHOULD NOT include any parameter 744 updates for the LSP, and the PCC MUST ignore such an update when the 745 SYNC flag is set. The PCC MUST respond with a PCRpt message with the 746 LSP state, SYNC Flag set to 0 and MUST include the SRP-ID-number of 747 the PCUpd message that triggered the resynchronization. If the PCC 748 cannot find the LSP in its database, PCC MUST also set the R (remove) 749 flag [I-D.ietf-pce-stateful-pce] in the LSP object in the PCRpt 750 message. 752 The PCE can also trigger re-synchronization of the entire LSP 753 database. The PCE MUST first mark all LSPs in the LSP database that 754 were previously reported by the PCC as stale and then send a PCUpd 755 with an LSP object containing a PLSP-ID of 0 and with the SYNC flag 756 set to 1. The PCUpd message MUST include an empty ERO (with no ERO 757 sub-object and object length of 4) as its intended path and SHOULD 758 NOT include the optional objects for its attributes for any parameter 759 update. The PCC MUST ignore such update if the SYNC flag is set. 760 This PCUpd message is the trigger for the PCC to enter the 761 synchronization phase as described in [I-D.ietf-pce-stateful-pce] and 762 start sending PCRpt messages. After the receipt of the end-of- 763 synchronization marker, the PCE will purge LSPs which were not 764 refreshed. The SRP-ID-number of the PCUpd that triggered the re- 765 synchronization SHOULD be included in each of the PCRpt messages. If 766 the PCC cannot re-synchronize the entire LSP database, the PCC MUST 767 respond with PCErr message with Error-type 20 Error-value 5 'cannot 768 complete the state synchronization' [I-D.ietf-pce-stateful-pce], and 769 MAY terminate the session. The PCE MUST remove the stale mark for 770 the LSP that were previously reported by the PCC. Based on the local 771 policy, the PCE MAY reattempt synchronization at a later time. 773 If the TRIGGERED-RESYNC capability is not advertised by a PCE and the 774 PCC receives a PCUpd with the SYNC flag set to 1, it MUST send a 775 PCErr with the SRP-ID-number of the PCUpd, Error-Type 20 and Error- 776 Value TBD4 (suggested value - 4) 'Attempt to trigger synchronization 777 when the TRIGGERED-SYNC capability has not been advertised' (see 778 Section 8.1). 780 Once the state re-synchronization is triggered by the PCE, the 781 procedures and error checks remain unchanged from the full state 782 synchronization ([I-D.ietf-pce-stateful-pce]). This would also 783 include PCE triggering multiple state re-synchronization requests 784 while synchronization is in progress. 786 If a PCC implementation that does not implement this extension should 787 not receive a PCUpd message to trigger re-synchronization as per the 788 capability advertisement, but if it were to receive it, it will 789 behave as per [I-D.ietf-pce-stateful-pce]. 791 7. Advertising Support of Synchronization Optimizations 793 Support for each of the optimizations described in this document 794 requires advertising the corresponding capabilities during session 795 establishment time. 797 The STATEFUL-PCE-CAPABILITY TLV is defined in 798 [I-D.ietf-pce-stateful-pce]. This document defines following new 799 flags in the STATEFUL-PCE-CAPABILITY TLV: 801 Bit Description 802 TBD9 (suggested value 30) S bit (INCLUDE-DB-VERSION) 803 TBD10 (suggested value 27) D bit (DELTA-LSP-SYNC-CAPABILITY) 804 TBD11 (suggested value 26) F bit (TRIGGERED-INITIAL-SYNC) 805 TBD12 (suggested value 28) T bit (TRIGGERED-RESYNC) 807 If the S (INCLUDE-DB-VERSION) bit is set to 1 by both PCEP Speakers, 808 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. See 809 Section 3.2 for details. 811 If the D (DELTA-LSP-SYNC-CAPABILITY) bit is set to 1 by a PCEP 812 speaker, it indicates that the PCEP speaker allows incremental 813 (delta) state synchronization. See Section 4.2 for details. 815 If the F (TRIGGERED-INITIAL-SYNC) bit is set to 1 by both PCEP 816 Speakers, the PCE SHOULD trigger initial (first) state 817 synchronization. See Section 5.2 for details. 819 If the T (TRIGGERED-RESYNC) bit is set to 1 by both PCEP Speakers, 820 the PCE can trigger re-synchronization of LSPs at any point in the 821 life of the session. See Section 6.2 for details. 823 See Section 8.3 for IANA allocations. 825 8. IANA Considerations 827 This document requests IANA actions to allocate code points for the 828 protocol elements defined in this document. 830 8.1. PCEP-Error Object 832 IANA is requested to make the following allocation in the "PCEP-ERROR 833 Object Error Types and Values" registry. 835 Error-Type Meaning Reference 836 6 Mandatory Object missing [RFC5440] 837 Error-Value= TBD1(suggested This document 838 value 12): LSP-DB-VERSION TLV 839 missing 840 20 LSP State synchronization [I-D.ietf-pce-stateful-pce] 841 error 842 Error-Value= TBD2(suggested This document 843 value 2): LSP Database version 844 mismatch. 845 Error-Value=TBD3(suggested This document 846 value 3): Attempt to trigger 847 synchronization before PCE 848 trigger. 849 Error-Value=TBD4(suggested This document 850 value 4): Attempt to trigger a 851 synchronization when the 852 PCE triggered synchronization 853 capability has not been 854 advertised. 855 Error-Value=TBD6(suggested This document 856 value 6): Received an invalid 857 LSP DB Version Number. 858 Error-Value=TBD7(suggested This document 859 value 7): Received an invalid 860 Speaker Entity Identifier. 862 8.2. PCEP TLV Type Indicators 864 IANA is requested to make the following allocation in the "PCEP TLV 865 Type Indicators" registry. 867 Value Meaning Reference 868 TBD5(suggested value 23) LSP-DB-VERSION This document 869 TBD13(suggested value 24) SPEAKER-ENTITY-ID This document 871 8.3. STATEFUL-PCE-CAPABILITY TLV 873 The STATEFUL-PCE-CAPABILITY TLV is defined in 874 [I-D.ietf-pce-stateful-pce] and a registry is requested to be 875 created to manage the flags in the TLV. IANA is requested to make 876 the following allocation in the aforementioned registry. 878 Bit Description Reference 879 TBD11 (suggested value 26) TRIGGERED-INITIAL-SYNC This document 880 TBD10 (suggested value 27) DELTA-LSP-SYNC-CAPABILITY This document 881 TBD12 (suggested value 28) TRIGGERED-RESYNC This document 882 TBD9 (suggested value 30) INCLUDE-DB-VERSION This document 884 9. Manageability Considerations 886 All manageability requirements and considerations listed in [RFC5440] 887 and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions 888 defined in this document. In addition, requirements and 889 considerations listed in this section apply. 891 9.1. Control of Function and Policy 893 A PCE or PCC implementation MUST allow configuring the state 894 synchronization optimization capabilities as described in this 895 document. The implementation SHOULD also allow the operator to 896 configure the Speaker Entity Identifier ( Section 3.3.2). Further, 897 the operator SHOULD be to be allowed to trigger the re- 898 synchronization procedures as per Section 6.2. 900 9.2. Information and Data Models 902 An implementation SHOULD allow the operator to view the stateful 903 capabilities advertised by each peer, and the current synchronization 904 status with each peer. To serve this purpose, the PCEP YANG module 905 [I-D.ietf-pce-pcep-yang] can be extended to include advertised 906 stateful capabilities, and synchronization status. 908 9.3. Liveness Detection and Monitoring 910 Mechanisms defined in this document do not imply any new liveness 911 detection and monitoring requirements in addition to those already 912 listed in [RFC5440]. 914 9.4. Verify Correct Operations 916 Mechanisms defined in this document do not imply any new operation 917 verification requirements in addition to those already listed in 918 [RFC5440] and [I-D.ietf-pce-stateful-pce]. 920 9.5. Requirements On Other Protocols 922 Mechanisms defined in this document do not imply any new requirements 923 on other protocols. 925 9.6. Impact On Network Operations 927 Mechanisms defined in [RFC5440] and [I-D.ietf-pce-stateful-pce] also 928 apply to PCEP extensions defined in this document. 930 The state synchronization optimizations described in this document 931 can result in a reduction of the amount of data exchanged and the 932 time taken for a stateful PCE to be fully operational when a PCEP 933 session is re-established. The ability to trigger re-synchronization 934 by the PCE can be utilized by the operator to sanity check its state 935 and recover from any mismatch in state without tearing down the 936 session. 938 10. Security Considerations 940 The security considerations listed in [I-D.ietf-pce-stateful-pce] 941 apply to this document as well. However, this document also 942 introduces some new attack vectors. An attacker could spoof the 943 SPEAKER-ENTITY-ID and pretend to be another PCEP speaker. An 944 attacker may flood the PCC with triggered re-synchronization request 945 at a rate which exceeds the PCC's ability to process them, either by 946 spoofing messages or by compromising the PCE itself. The PCC can 947 respond with PCErr message as described in Section 6.2 and terminate 948 the session. Thus securing the PCEP session using mechanism like TCP 949 Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security 950 (TLS) [I-D.ietf-pce-pceps] is RECOMMENDED. 952 11. Acknowledgments 954 We would like to thank Young Lee, Sergio Belotti and Cyril Margaria 955 for their comments and discussions. 957 Thanks to Jonathan Hardwick for being the document shepherd and 958 provide comments and guidance. 960 Thanks to Tomonori Takeda for Routing Area Directorate review. 962 Thanks to Adrian Farrel for TSVART review and providing detailed 963 comments and suggestions. 965 12. Contributors 967 Gang Xie 968 Huawei Technologies 969 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 970 Shenzhen, Guangdong, 518129 971 P.R. China 972 Email: xiegang09@huawei.com 974 13. References 976 13.1. Normative References 978 [I-D.ietf-pce-stateful-pce] 979 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 980 Extensions for Stateful PCE", draft-ietf-pce-stateful- 981 pce-18 (work in progress), December 2016. 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, 985 DOI 10.17487/RFC2119, March 1997, 986 . 988 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 989 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 990 DOI 10.17487/RFC5440, March 2009, 991 . 993 13.2. Informative References 995 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 996 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 997 June 2010, . 999 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1000 Stateful Path Computation Element (PCE)", RFC 8051, 1001 DOI 10.17487/RFC8051, January 2017, 1002 . 1004 [I-D.ietf-pce-pcep-yang] 1005 Dhody, D., Hardwick, J., Beeram, V., and j. 1006 jefftant@gmail.com, "A YANG Data Model for Path 1007 Computation Element Communications Protocol (PCEP)", 1008 draft-ietf-pce-pcep-yang-01 (work in progress), October 1009 2016. 1011 [I-D.ietf-pce-pceps] 1012 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1013 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 1014 progress), January 2017. 1016 Authors' Addresses 1018 Edward Crabbe 1019 Oracle 1021 EMail: edward.crabbe@gmail.com 1023 Ina Minei 1024 Google, Inc. 1025 1600 Amphitheatre Parkway 1026 Mountain View, CA 94043 1027 US 1029 EMail: inaminei@google.com 1031 Jan Medved 1032 Cisco Systems, Inc. 1033 170 West Tasman Dr. 1034 San Jose, CA 95134 1035 US 1037 EMail: jmedved@cisco.com 1038 Robert Varga 1039 Pantheon Technologies SRO 1040 Mlynske Nivy 56 1041 Bratislava 821 05 1042 Slovakia 1044 EMail: robert.varga@pantheon.sk 1046 Xian Zhang 1047 Huawei Technologies 1048 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 1049 Shenzhen, Guangdong 518129 1050 P.R.China 1052 EMail: zhang.xian@huawei.com 1054 Dhruv Dhody 1055 Huawei Technologies 1056 Divyashree Techno Park, Whitefield 1057 Bangalore, Karnataka 560066 1058 India 1060 EMail: dhruv.ietf@gmail.com