idnits 2.17.1 draft-ietf-pce-stateful-sync-optimizations-04.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 (November 1, 2015) is 3097 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) == Missing Reference: 'TBD' is mentioned on line 424, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-12 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 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 4 Intended status: Standards Track I. Minei 5 Expires: May 4, 2016 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 November 1, 2015 15 Optimizations of Label Switched Path State Synchronization Procedures 16 for a Stateful PCE 17 draft-ietf-pce-stateful-sync-optimizations-04 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 reliable state synchronization mechanism between the PCE and the 28 network, PCE and path computation clients (PCCs), and between 29 cooperating PCEs. The basic mechanism for state synchronization is 30 part of the stateful PCE specification. This draft presents 31 motivations for optimizations to the base state synchronization 32 procedure and specifies the required Path Computation Element 33 Communication 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 May 4, 2016. 58 Copyright Notice 60 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. State Synchronization Avoidance . . . . . . . . . . . . . . . 5 78 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.2. State Synchronization Avoidance Procedure . . . . . . . . 5 80 3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 9 81 3.3.1. LSP State Database Version Number TLV . . . . . . . . 9 82 3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 10 83 4. Incremental State Synchronization . . . . . . . . . . . . . . 11 84 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.2. Incremental Synchronization Procedure . . . . . . . . . . 13 86 5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 15 87 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.2. PCE-triggered Initial State Synchronization Procedure . . 15 89 6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . . 16 90 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 16 91 6.2. PCE-triggered State Re-synchronization Procedure . . . . . 16 92 7. Advertising Support of Synchronization Optimizations . . . . . 17 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 18 95 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 19 96 8.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 19 97 9. Manageability Considerations . . . . . . . . . . . . . . . . . 20 98 9.1. Control of Function and Policy . . . . . . . . . . . . . . 20 99 9.2. Information and Data Models . . . . . . . . . . . . . . . 20 100 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 101 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 102 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 103 9.6. Impact On Network Operations . . . . . . . . . . . . . . . 21 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 106 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 109 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 112 1. Introduction 114 The Path Computation Element Communication Protocol (PCEP) provides 115 mechanisms for Path Computation Elements (PCEs) to perform path 116 computations in response to Path Computation Clients (PCCs) requests. 118 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 119 provide stateful control. A stateful PCE has access to not only the 120 information carried by the network's Interior Gateway Protocol (IGP), 121 but also the set of active paths and their reserved resources for its 122 computations. The additional state allows the PCE to compute 123 constrained paths while considering individual LSPs and their 124 interactions. This requires a reliable state synchronization 125 mechanism between the PCE and the network, PCE and PCC, and between 126 cooperating PCEs. [I-D.ietf-pce-stateful-pce] describes the basic 127 mechanism for state synchronization. This draft specifies following 128 optimizations for state synchronization and the corresponding PCEP 129 procedures and extensions: 131 o State Synchronization Avoidance: To skip state synchronization if 132 the state has survived and not changed during session restart. 133 (See Section 3.) 135 o Incremental State Synchronization: To do incremental (delta) state 136 synchronization when possible. (See Section 4.) 138 o PCE-triggered Initial Synchronization: To let PCE control the 139 timing of the initial state synchronization. (See Section 5.) 141 o PCE-triggered Re-synchronization: To let PCE re-synchronize the 142 state for sanity check. (See Section 6.) 144 2. Terminology 146 This document uses the following terms defined in [RFC5440]: PCC, 147 PCE, PCEP Peer. 149 This document uses the following terms defined in 150 [I-D.ietf-pce-stateful-pce]: Delegation, Redelegation Timeout 151 Interval, LSP State Report, LSP Update Request, LSP State Database. 153 Within this document, when describing PCE-PCE communications, the 154 requesting PCE fills the role of a PCC. This provides a saving in 155 documentation without loss of function. 157 3. State Synchronization Avoidance 159 3.1. Motivation 161 The purpose of state synchronization is to provide a checkpoint-in- 162 time state replica of a PCC's LSP state in a stateful PCE. State 163 synchronization is performed immediately after the initialization 164 phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic 165 mechanism for state synchronization. 167 State synchronization is not always necessary following a PCEP 168 session restart. If the state of both PCEP peers did not change, the 169 synchronization phase may be skipped. This can result in significant 170 savings in both control-plane data exchanges and the time it takes 171 for the stateful PCE to become fully operational. 173 3.2. State Synchronization Avoidance Procedure 175 State synchronization MAY be skipped following a PCEP session restart 176 if the state of both PCEP peers did not change during the period 177 prior to session re-initialization. To be able to make this 178 determination, state must be exchanged and maintained by both PCE and 179 PCC during normal operation. This is accomplished by keeping track 180 of the changes to the LSP state database, using a version tracking 181 field called the LSP State Database Version Number. 183 The LSP State Database Version Number, carried in LSP-DB-VERSION TLV 184 (see Section 3.3.1), is owned by a PCC and it MUST be incremented by 185 1 for each successive change in the PCC's LSP state database. The 186 LSP State Database Version Number MUST start at 1 and may wrap 187 around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of 188 the two values are used during LSP state (re)-synchronization, the 189 PCE speaker receiving this node should send back a PCErr with Error- 190 type 20 Error-value TBD (suggested value - 6) 'Received an invalid 191 LSP DB Version Number', and close the PCEP session. Operations that 192 trigger a change to the local LSP state database include a change in 193 the LSP operational state, delegation of an LSP, removal or setup of 194 an LSP or change in any of the LSP attributes that would trigger a 195 report to the PCE. 197 If state synchronization avoidance is enabled, a PCC MUST increment 198 its LSP State Database Version Number when the 'Redelegation Timeout 199 Interval' timer expires (see [I-D.ietf-pce-stateful-pce]) for the use 200 of the Redelegation Timeout Interval). 202 State synchronization avoidance is advertised on a PCEP session 203 during session startup using the INCLUDE-DB-VERSION (S) bit in the 204 capabilities TLV (see Section 7). The peer may move in the network, 205 either physically or logically, which may cause its connectivity 206 details and transport-level identity (such as IP address) to change. 207 To ensure that a PCEP peer can recognize a previously connected peer 208 even in face of such mobility, each PCEP peer includes the SPEAKER- 209 ENTITY-ID TLV described in Section 3.3.2 in the OPEN message. 211 If both PCEP speakers set the S flag in the OPEN object's STATEFUL- 212 PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV 213 in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV 214 is missing in a PCRpt message, the PCE will generate an error with 215 Error-Type 6 (mandatory object missing) and Error-Value TBD 216 (suggested value - 12) 'LSP-DB-VERSION TLV missing' and close the 217 session. If state synchronization avoidance has not been enabled on 218 a PCEP session, the PCC SHOULD NOT include the LSP-DB-VERSION TLV in 219 the LSP Object and the PCE SHOULD ignore it were it to receive one. 221 If a PCE's LSP state database survived the restart of a PCEP session, 222 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 223 the TLV will contain the last LSP State Database Version Number 224 received on an LSP State Report from the PCC in the previous PCEP 225 session. If a PCC's LSP State Database survived the restart of a 226 PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN 227 object and the TLV will contain the latest LSP State Database Version 228 Number. If a PCEP speaker's LSP state database did not survive the 229 restart of a PCEP session, the PCEP speaker MUST NOT include the LSP- 230 DB-VERSION TLV in the OPEN object. 232 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 233 Object and the TLV values match, the PCC MAY skip state 234 synchronization. Otherwise, the PCC MUST perform full state 235 synchronization (see [I-D.ietf-pce-stateful-pce]) or incremental 236 state synchronization (see Section 4) to the stateful PCE. If the 237 PCC attempts to skip state synchronization, by setting the SYNC Flag 238 to 0 and PLSP-ID to a non-zero value on the first LSP State Report 239 from the PCC as per [I-D.ietf-pce-stateful-pce], the PCE MUST send 240 back a PCErr with Error-Type 20 Error-Value TBD (suggested value - 2) 241 'LSP Database version mismatch', and close the PCEP session. 243 If state synchronization is required, then prior to completing the 244 initialization phase, the PCE MUST mark any LSPs in the LSP database 245 that were previously reported by the PCC as stale. When the PCC 246 reports an LSP during state synchronization, if the LSP already 247 exists in the LSP database, the PCE MUST update the LSP database and 248 clear the stale marker from the LSP. When it has finished state 249 synchronization, the PCC MUST immediately send an end of 250 synchronization marker. The end of synchronization marker is a Path 251 Computation State Report (PCRpt) message with an LSP object 252 containing a PLSP-ID of 0 and with the SYNC flag set to 0 253 ([I-D.ietf-pce-stateful-pce]). The LSP-DB-VERSION TLV MUST be 254 included in this PCRpt message. On receiving this state report, the 255 PCE MUST purge any LSPs from the LSP database that are still marked 256 as stale. 258 Note that a PCE/PCC MAY force state synchronization by not including 259 the LSP-DB-VERSION TLV in its OPEN object. 261 Since a PCE does not make changes to the LSP State Database Version 262 Number, a PCC should never encounter this TLV in a message from the 263 PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- 264 VERSION TLV, were it to receive one from a PCE. 266 Figure 1 shows an example sequence where the state synchronization is 267 skipped. 269 +-+-+ +-+-+ 270 |PCC| |PCE| 271 +-+-+ +-+-+ 272 | | 273 |--Open--, | 274 | DBv=42 \ ,---Open--| 275 | S=1 \ / DBv=42 | 276 | \/ S=1 | 277 | /\ | 278 | / `-------->| (OK to skip sync) 279 (Skip sync) |<--------` | 280 | . | 281 | . | 282 | . | 283 | | 284 |--PCRpt,DBv=43,SYNC=0-->| (Regular 285 | | LSP State Report) 286 |--PCRpt,DBv=44,SYNC=0-->| (Regular 287 | | LSP State Report) 288 |--PCRpt,DBv=45,SYNC=0-->| 289 | | 291 Figure 1: State Synchronization Skipped 293 Figure 2 shows an example sequence where the state synchronization is 294 performed due to LSP state database version mismatch during the PCEP 295 session setup. Note that the same state synchronization sequence 296 would happen if either the PCC or the PCE would not include the LSP- 297 DB-VERSION TLV in their respective Open messages. 299 +-+-+ +-+-+ 300 |PCC| |PCE| 301 +-+-+ +-+-+ 302 | | 303 |--Open--, | 304 | DBv=46 \ ,---Open--| 305 | S=1 \ / DBv=42 | 306 | \/ S=1 | 307 | /\ | 308 | / `-------->| (Expect sync) 309 (Do sync) |<--------` | 310 | | 311 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 312 | . | 313 | . | 314 | . | 315 |--PCRpt,DBv=46,SYNC=0-->| (Sync done) 316 | . |(Purge LSP State 317 | . | if applicable) 318 | . | 319 |--PCRpt,DBv=47,SYNC=0-->| (Regular 320 | | LSP State Report) 321 |--PCRpt,DBv=48,SYNC=0-->| (Regular 322 | | LSP State Report) 323 |--PCRpt,DBv=49,SYNC=0-->| 324 | | 326 Figure 2: State Synchronization Performed 328 Figure 3 shows an example sequence where the state synchronization is 329 skipped, but because one or both PCEP speakers set the S Flag to 0, 330 the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt 331 messages to the PCE. If the current PCEP session restarts, the PCEP 332 speakers will have to perform state synchronization, since the PCE 333 does not know the PCC's latest LSP State Database Version Number 334 information. 336 +-+-+ +-+-+ 337 |PCC| |PCE| 338 +-+-+ +-+-+ 339 | | 340 |--Open--, | 341 | DBv=42 \ ,---Open--| 342 | S=0 \ / DBv=42 | 343 | \/ S=0 | 344 | /\ | 345 | / `-------->| (OK to skip sync) 346 (Skip sync) |<--------` | 347 | . | 348 | . | 349 | . | 350 |------PCRpt,SYNC=0----->| (Regular 351 | | LSP State Report) 352 |------PCRpt,SYNC=0----->| (Regular 353 | | LSP State Report) 354 |------PCRpt,SYNC=0----->| 355 | | 357 Figure 3: State Synchronization Skipped, no LSP-DB-VERSION TLVs sent 358 from PCC 360 3.3. PCEP Extensions 362 A new INCLUDE-DB-VERSION (S) bit is added in the stateful 363 capabilities TLV (see Section 7 for details). 365 3.3.1. LSP State Database Version Number TLV 367 The LSP State Database Version Number (LSP-DB-VERSION) TLV is an 368 optional TLV that MAY be included in the OPEN object and the LSP 369 object. 371 The format of the LSP-DB-VERSION TLV is shown in the following 372 figure: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type=[TBD] | Length=8 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | LSP State DB Version Number | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 4: LSP-DB-VERSION TLV format 385 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 386 The value contains a 64-bit unsigned integer, representing the LSP 387 State DB Version Number. 389 3.3.2. Speaker Entity Identifier TLV 391 The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional 392 TLV that MAY be included in the OPEN Object when a PCEP speaker 393 wishes to determine if state synchronization can be skipped when a 394 PCEP session is restarted. It contains a unique identifier for the 395 node that does not change during the lifetime of the PCEP speaker. 396 It identifies the PCEP speaker to its peers even if the speaker's IP 397 address is changed. 399 In case of a remote peer IP address change, a PCEP speaker would 400 learn the speaker entity identifier on receiving the open message but 401 it MAY have already sent its open message without realizing that it 402 is a known PCEP peer. In such a case, either a full synchronization 403 is done or PCEP session is terminated. This may be a local policy 404 decision. The new IP address is associated with the speaker entity 405 identifier for future either way. In the latter case when PCEP 406 session is re-established, it would be correctly associated with 407 speaker entity identifier and not be considered as an unknown peer. 409 The format of the SPEAKER-ENTITY-ID TLV is shown in the following 410 figure: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type=[TBD] | Length (variable) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 // Speaker Entity Identifier // 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 5: SPEAKER-ENTITY-ID TLV format 424 The type of the TLV is [TBD] and it has a variable length, which MUST 425 be greater than 0. The Value is padded to 4-octet alignment. The 426 padding is not included in the Length field. The value contains the 427 entity identifier of the speaker transmitting this TLV. This 428 identifier is required to be unique within its scope of visibility, 429 which is usually limited to a single domain. It MAY be configured by 430 the operator. Alternatively, it can be derived automatically from a 431 suitably-stable unique identifier, such as a MAC address, serial 432 number, Traffic Engineering Router ID, or similar. In the case of 433 inter-domain connections, the speaker SHOULD prefix its usual 434 identifier with the domain identifier of its residence, such as 435 Autonomous System number, IGP area identifier, or similar. 437 The relationship between this identifier and entities in the Traffic 438 Engineering database is intentionally left undefined. 440 From a manageability point of view, a PCE or PCC implementation 441 SHOULD allow the operator to configure this Speaker Entity 442 Identifier. 444 4. Incremental State Synchronization 446 [I-D.ietf-pce-stateful-pce] describes the LSP state synchronization 447 mechanism between PCCs and stateful PCEs. During the state 448 synchronization, a PCC sends the information of all its LSPs (i.e., 449 the full LSP-DB) to the stateful PCE. In order to reduce the state 450 synchronization overhead when there is a small number of LSP state 451 change in the network between PCEP session restart, this section 452 defines a mechanism for incremental (Delta) LSP Database (LSP-DB) 453 synchronization. 455 4.1. Motivation 457 According to [I-D.ietf-pce-stateful-pce], if a PCE restarts and its 458 LSP-DB survived, PCCs with mismatched LSP State Database Version 459 Number will send all their LSPs information (full LSP-DB) to the 460 stateful PCE, even if only a small number of LSPs underwent state 461 change. It can take a long time and consume large communication 462 channel bandwidth. 464 Figure 6 shows an example of LSP state synchronization. 466 +-----+ 467 | PCE | 468 +-----+ 469 / 470 / 471 / 472 / 473 +------+ +------+ 474 | PCC1 |------------| PCC2 | 475 +------+ +------+ 476 | | 477 | | 478 +------+ +------+ 479 | PCC3 |------------| PCC4 | 480 +------+ +------+ 482 Figure 6: Topology Example 484 Assuming there are 320 LSPs in the network, with each PCC having 80 485 LSPs. During the time when the PCEP session is down, 20 LSPs of each 486 PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session 487 restarts, the stateful PCE needs to synchronize 320 LSPs with all 488 PCCs. But actually, 240 LSPs stay the same. If performing full LSP 489 state synchronization, it can take a long time to carry out the 490 synchronization of all LSPs. It is especially true when only a low 491 bandwidth communication channel is available (e.g., in-band control 492 channel for optical transport networks) and there is a substantial 493 number of LSPs in the network. Another disadvantage of full LSP 494 synchronization is that it is a waste of communication bandwidth to 495 perform full LSP synchronization given the fact that the number of 496 LSP changes can be small during the time when PCEP session is down. 498 An incremental (Delta) LSP Database (LSP-DB) state synchronization is 499 described in this section, where only the LSPs underwent state change 500 are synchronized between the session restart. This may include new/ 501 modified/deleted LSPs. 503 4.2. Incremental Synchronization Procedure 505 [I-D.ietf-pce-stateful-pce] describes state synchronization and 506 Section 3 describes state synchronization avoidance by using LSP-DB- 507 VERSION TLV in its OPEN object. This section extends this idea to 508 only synchronize the delta (changes) in case of version mismatch. 510 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 511 object and the LSP-DB-VERSION TLV values match, the PCC MAY skip 512 state synchronization. Otherwise, the PCC MUST perform state 513 synchronization. Incremental State synchronization capability is 514 advertised on a PCEP session during session startup using the DELTA- 515 LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7). 516 Instead of dumping full LSP-DB to the stateful PCE again, the PCC 517 synchronizes the delta (changes) as described in Figure 7 when D flag 518 and S flag is set to 1 by both PCC and PCE. Other combinations of D 519 and S flags setting by PCC and PCE result in full LSP-DB 520 synchronization procedure as described in 521 [I-D.ietf-pce-stateful-pce]. The PCC MAY force a full LSP DB 522 synchronization by setting the D flag to zero in the OPEN message. 524 +-+-+ +-+-+ 525 |PCC| |PCE| 526 +-+-+ +-+-+ 527 | | 528 |--Open--, | 529 | DBv=46 \ ,---Open--| 530 | S=1 \ / DBv=42 | 531 | D=1 \/ S=1 | 532 | /\ D=1 | 533 | / \ | 534 | / `-------->| (Expect Delta sync) 535 (Do sync)|<--------` | (DONOT Purge LSP 536 (Delta) | | State) 537 | | 538 (Delta Sync starts) |--PCRpt,DBv=46,SYNC=1-->| 539 | . | 540 | . | 541 | . | 542 | . | 543 |--PCRpt,DBv=46,SYNC=0-->| (Sync done, 544 | | PLSP-ID=0) 545 | | 546 |--PCRpt,DBv=47,SYNC=0-->| (Regular 547 | | LSP State Report) 548 |--PCRpt,DBv=48,SYNC=0-->| (Regular 549 | | LSP State Report) 550 |--PCRpt,DBv=49,SYNC=0-->| 551 | | 553 Figure 7: Incremental Synchronization Procedure 555 As per Section 3, the LSP State Database Version Number is 556 incremented each time a change is made to the PCC's local LSP State 557 Database. Each LSP is associated with the DB version at the time of 558 its state change. This is needed to determine which LSP and what 559 information needs to be synchronized in incremental state 560 synchronization. 562 It is not necessary for a PCC to store a complete history of LSP 563 Database change, but rather remember the LSP state changes (including 564 LSP modification, setup and deletion) that happened between the PCEP 565 session(s) restart in order to carry out incremental state 566 synchronization. After the synchronization procedure finishes, the 567 PCC can dump this history information. In the example shown in 568 Figure 7, the PCC needs to store the LSP state changes that happened 569 between DB Version 43 to 46 and synchronizes these changes only when 570 performing incremental LSP state update. So a PCC needs to remember 571 at least the LSP state changes that happened after an existing PCEP 572 session with a stateful PCE goes down to have any chance of doing 573 incremental synchronisation when the session is re-established. 575 If a PCC finds out it does not have sufficient information to 576 complete incremental synchronisation after advertising incremental 577 LSP state synchronization capability, it MUST send a PCErr with 578 Error-Type 20 and Error-Value 5 'A PCC indicates to a PCE that it can 579 not complete the state synchronization' (defined in 580 [I-D.ietf-pce-stateful-pce]) and terminate the session. The PCC 581 SHOULD re-establish the session with the D bit set to 0 in the OPEN 582 message. 584 The other procedures and error checks remain unchanged from the full 585 state synchronization ([I-D.ietf-pce-stateful-pce]). 587 5. PCE-triggered Initial Synchronization 589 5.1. Motivation 591 In networks such as optical transport networks, the control channel 592 between network nodes can be realized through in-band overhead thus 593 has limited bandwidth. With a stateful PCE connected to the network 594 via one network node, it is desirable to control the timing of PCC 595 state synchronization so as not to overload the low communication 596 channel available in the network during the initial synchronization 597 (be it incremental or full) when the session restarts , when there is 598 comparatively large amount of control information needing to be 599 synchronized between the stateful PCE and the network. The method 600 proposed, i.e., allowing PCE to trigger the state synchronization, is 601 similar to the function proposed in Section 6 but is used in 602 different scenarios and for different purposes. 604 5.2. PCE-triggered Initial State Synchronization Procedure 606 Support of PCE-triggered initial state synchronization is advertised 607 during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in 608 the STATEFUL-PCE-CAPABILITY TLV (see Section 7). 610 In order to allow a stateful PCE to control the LSP-DB 611 synchronization after establishing a PCEP session, both PCEP speakers 612 MUST set F bit to 1 in the OPEN message. If the TRIGGERED-INITIAL- 613 SYNC capability is not advertised by a PCE and the PCC receives a 614 PCUpd with the SYNC flag set to 1, it MUST send a PCErr with the SRP- 615 ID-number of the PCUpd, Error-Type 20 and Error-Value TBD (suggested 616 value - 4) 'Attempt to trigger synchronization when the TRIGGERED- 617 SYNC capability has not been advertised' (see Section 8.1). If the 618 LSP-DB Version is mis-matched, it can send a PCUpd message with 619 PLSP-ID = 0 and SYNC = 1 in order to trigger the LSP-DB 620 synchronization process. In this way, the PCE can control the 621 sequence of LSP synchronization among all the PCCs that are re- 622 establishing PCEP sessions with it. When the capability of PCE 623 control is enabled, only after a PCC receives this message, it will 624 start sending information to the PCE. The PCC SHOULD NOT send PCRpt 625 messages to the stateful PCE before it triggers the State 626 Synchronization. This PCE-triggering capability can be applied to 627 both full and incremental state synchronization. If applied to the 628 later, the PCCs only send information that PCE does not possess, 629 which is inferred from the LSP-DB version information exchanged in 630 the OPEN message (see Section 4.2 for detailed procedure). 632 Once the initial state synchronization is triggered by the PCE, the 633 procedures and error checks remain unchanged from the full state 634 synchronization ([I-D.ietf-pce-stateful-pce]). 636 6. PCE-triggered Re-synchronization 638 6.1. Motivation 640 The accuracy of the computations performed by the PCE is tied to the 641 accuracy of the view the PCE has on the state of the LSPs. 642 Therefore, it can be beneficial to be able to re-synchronize this 643 state even after the session has been established. The PCE may use 644 this approach to continuously sanity check its state against the 645 network, or to recover from error conditions without having to tear 646 down sessions. 648 6.2. PCE-triggered State Re-synchronization Procedure 650 Support of PCE-triggered state synchronization is advertised by both 651 PCEP speakers during session startup using the TRIGGERED-RESYNC (T) 652 bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7). The PCE can 653 choose to re-synchronize its entire LSP database or a single LSP. 655 To trigger re-synchronization for an LSP, the PCE MUST first mark the 656 LSP as stale and then send a Path Computation State Update (PCUpd) 657 for it, with the SYNC flag in the LSP object set to 1. The PCE 658 SHOULD NOT include any parameter updates for the LSP, and the PCC 659 SHOULD ignore such updates if the SYNC flag is set. The PCC MUST 660 respond with a PCRpt message with the LSP state, SYNC Flag set to 0 661 and MUST include the SRP-ID-number of the PCUpd message that 662 triggered the resynchronization. 664 The PCE can also trigger re-synchronization of the entire LSP 665 database. The PCE MUST first mark all LSPs in the LSP database that 666 were previously reported by the PCC as stale and then send a PCUpd 667 with an LSP object containing a PLSP-ID of 0 and with the SYNC flag 668 set to 1. This PCUpd message is the trigger for the PCC to enter the 669 synchronization phase as described in [I-D.ietf-pce-stateful-pce] and 670 start sending PCRpt messages. After the receipt of the end-of- 671 synchronization marker, the PCE will purge LSPs which were not 672 refreshed. The SRP-ID-number of the PCUpd that triggered the re- 673 synchronization SHOULD be included in each of the PCRpt messages. 675 If the TRIGGERED-RESYNC capability is not advertised by a PCE and the 676 PCC receives a PCUpd with the SYNC flag set to 1, it MUST send a 677 PCErr with the SRP-ID-number of the PCUpd, Error-Type 20 and Error- 678 Value TBD (suggested value - 4) 'Attempt to trigger synchronization 679 when the TRIGGERED-SYNC capability has not been advertised' (see 680 Section 8.1). 682 Once the state re-synchronization is triggered by the PCE, the 683 procedures and error checks remain unchanged from the full state 684 synchronization ([I-D.ietf-pce-stateful-pce]). This would also 685 include PCE triggering multiple state re-synchronization requests 686 while synchronization is in progress. 688 7. Advertising Support of Synchronization Optimizations 690 Support for each of the optimizations described in this document 691 requires advertising the corresponding capabilities during session 692 establishment time. 694 New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 695 [I-D.ietf-pce-stateful-pce]. Its format is shown in the following 696 figure: 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Type | Length=4 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Flags |F|D|T|I|S|U| 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 8: STATEFUL-PCE-CAPABILITY TLV Format 707 The value comprises a single field - Flags (32 bits): 709 U (LSP-UPDATE-CAPABILITY - 1 bit): defined in 710 [I-D.ietf-pce-stateful-pce]. 712 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 713 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 714 See Section 3.2 for details. 716 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): defined in 717 [I-D.ietf-pce-pce-initiated-lsp]. 719 T (TRIGGERED-RESYNC - 1 bit): if set to 1 by both PCEP Speakers, the 720 PCE can trigger re-synchronization of LSPs at any point in the 721 life of the session. See Section 6.2 for details. 723 D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP 724 speaker, it indicates that the PCEP speaker allows incremental 725 (delta) state synchronization. See Section 4.2 for details. 727 F (TRIGGERED-INITIAL-SYNC - 1 bit): if set to 1 by both PCEP 728 Speakers, the PCE SHOULD trigger initial (first) state 729 synchronization. See Section 5.2 for details. 731 8. IANA Considerations 733 This document requests IANA actions to allocate code points for the 734 protocol elements defined in this document. 736 8.1. PCEP-Error Object 738 IANA is requested to make the following allocation in the "PCEP-ERROR 739 Object Error Types and Values" registry. 741 Error-Type Meaning Reference 742 6 Mandatory Object missing [RFC5440] 743 Error-Value= TBD(suggested This document 744 value 12): LSP-DB-VERSION TLV 745 missing 746 20 LSP State synchronization [I-D.ietf-pce-stateful-pce] 747 error 748 Error-Value= TBD(suggested This document 749 value 2): LSP Database version 750 mismatch. 751 Error-Value=TBD(suggested This document 752 value 3): The LSP-DB-VERSION 753 TLV Missing when state 754 synchronization avoidance is 755 enabled. 756 Error-Value=TBD(suggested This document 757 value 4): Attempt to trigger a 758 synchronization when the 759 PCE triggered synchronization 760 capability has not been 761 advertised. 762 Error-Value=TBD(suggested This document 763 value 6): No sufficient LSP 764 change information for 765 incremental LSP state 766 synchronization. 767 Error-Value=TBD(suggested This document 768 value 7): Received an invalid 769 LSP DB Version Number 771 8.2. PCEP TLV Type Indicators 773 IANA is requested to make the following allocation in the "PCEP TLV 774 Type Indicators" registry. 776 Value Meaning Reference 777 TBD(suggested value 23) LSP-DB-VERSION This document 778 TBD(suggested value 24) SPEAKER-ENTITY-ID This document 780 8.3. STATEFUL-PCE-CAPABILITY TLV 782 The STATEFUL-PCE-CAPABILITY TLV is defined in 783 [I-D.ietf-pce-stateful-pce] and a registry is requested to be created 784 to manage the flags in the TLV. IANA is requested to make the 785 following allocation in the aforementioned registry. 787 Bit Description Reference 788 TBD(suggested value 26) TRIGGERED-INITIAL-SYNC This document 789 TBD(suggested value 27) DELTA-LSP-SYNC-CAPABILITY This document 790 TBD(suggested value 28) TRIGGERED-RESYNC This document 791 TBD(suggested value 30) INCLUDE-DB-VERSION This document 793 9. Manageability Considerations 795 All manageability requirements and considerations listed in [RFC5440] 796 and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions 797 defined in this document. In addition, requirements and 798 considerations listed in this section apply. 800 9.1. Control of Function and Policy 802 A PCE or PCC implementation MUST allow configuring the state 803 synchronization optimization capabilities as described in this 804 document. The implementation SHOULD also allow the operator to 805 configure the Speaker Entity Identifier ( Section 3.3.2). 807 9.2. Information and Data Models 809 An implementation SHOULD allow the operator to view the stateful 810 capabilities advertised by each peer, and the current synchronization 811 status with each peer. To serve this purpose, the PCEP MIB module 812 can be extended to include advertised stateful capabilities, and 813 synchronization status. 815 9.3. Liveness Detection and Monitoring 817 Mechanisms defined in this document do not imply any new liveness 818 detection and monitoring requirements in addition to those already 819 listed in [RFC5440]. 821 9.4. Verify Correct Operations 823 Mechanisms defined in this document do not imply any new operation 824 verification requirements in addition to those already listed in 825 [RFC5440] and [I-D.ietf-pce-stateful-pce]. 827 9.5. Requirements On Other Protocols 829 Mechanisms defined in this document do not imply any new requirements 830 on other protocols. 832 9.6. Impact On Network Operations 834 Mechanisms defined in this document do not have any impact on network 835 operations in addition to those already listed in [RFC5440] and 836 [I-D.ietf-pce-stateful-pce]. 838 10. Security Considerations 840 The security considerations listed in [I-D.ietf-pce-stateful-pce] 841 apply to this document as well. However, because the protocol 842 modifications outlined in this document allow the PCE to control 843 state (re)-synchronization timing and sequence, it also introduces a 844 new attack vector: an attacker may flood the PCC with triggered re- 845 synchronization request at a rate which exceeds the PCC's ability to 846 process them, either by spoofing messages or by compromising the PCE 847 itself. The PCC is free to drop any trigger re-synchronization 848 request without additional processing. 850 11. Acknowledgements 852 We would like to thank Young Lee, Jonathan Hardwick, Sergio Belotti 853 and Cyril Margaria for their comments and discussions. 855 12. Contributors 857 Gang Xie 858 Huawei Technologies 859 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 860 Shenzhen, Guangdong, 518129 861 P.R. China 862 Email: xiegang09@huawei.com 864 13. References 866 13.1. Normative References 868 [I-D.ietf-pce-stateful-pce] 869 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 870 Extensions for Stateful PCE", 871 draft-ietf-pce-stateful-pce-12 (work in progress), 872 October 2015. 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 876 RFC2119, March 1997, 877 . 879 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 880 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 881 DOI 10.17487/RFC5440, March 2009, 882 . 884 13.2. Informative References 886 [I-D.ietf-pce-pce-initiated-lsp] 887 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 888 Extensions for PCE-initiated LSP Setup in a Stateful PCE 889 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 890 progress), October 2015. 892 Authors' Addresses 894 Edward Crabbe 896 Email: edward.crabbe@gmail.com 898 Ina Minei 899 Google, Inc. 900 1600 Amphitheatre Parkway 901 Mountain View, CA 94043 902 US 904 Email: inaminei@google.com 906 Jan Medved 907 Cisco Systems, Inc. 908 170 West Tasman Dr. 909 San Jose, CA 95134 910 US 912 Email: jmedved@cisco.com 913 Robert Varga 914 Pantheon Technologies SRO 915 Mlynske Nivy 56 916 Bratislava 821 05 917 Slovakia 919 Email: robert.varga@pantheon.sk 921 Xian Zhang 922 Huawei Technologies 923 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 924 Shenzhen, Guangdong 518129 925 P.R.China 927 Email: zhang.xian@huawei.com 929 Dhruv Dhody 930 Huawei Technologies 931 Divyashree Techno Park, Whitefield 932 Bangalore, Karnataka 560037 933 India 935 Email: dhruv.ietf@gmail.com