idnits 2.17.1 draft-minei-pce-stateful-sync-optimizations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2014) is 3669 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 388, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-08 Summary: 0 errors (**), 0 flaws (~~), 3 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 Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: September 4, 2014 Cisco Systems, Inc. 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 X. Zhang 11 D. Dhody 12 Huawei Technologies 13 March 3, 2014 15 Optimizations of Label Switched Path State Synchronization Procedures 16 for a Stateful PCE 17 draft-minei-pce-stateful-sync-optimizations-02 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 September 4, 2014. 58 Copyright Notice 60 Copyright (c) 2014 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 . . . . . . . . . . . . . . . 4 78 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 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. PCE-triggered State Synchronization . . . . . . . . . . . . . 11 84 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 85 4.2. PCE-triggered State Synchronization Procedure . . . . . . 11 86 5. Incremental State Synchronization . . . . . . . . . . . . . . 11 87 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.2. Incremental Synchronization Procedure . . . . . . . . . . 13 89 6. Advertising Support of Synchronization Optimizations . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 92 7.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 17 93 7.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 17 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 The Path Computation Element Communication Protocol (PCEP) provides 105 mechanisms for Path Computation Elements (PCEs) to perform path 106 computations in response to Path Computation Clients (PCCs) requests. 108 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 109 provide stateful control. A stateful PCE has access to not only the 110 information carried by the network's Interior Gateway Protocol (IGP), 111 but also the set of active paths and their reserved resources for its 112 computations. The additional state allows the PCE to compute 113 constrained paths while considering individual LSPs and their 114 interactions. This requires a reliable state synchronization 115 mechanism between the PCE and the network, PCE and PCC, and between 116 cooperating PCEs. [I-D.ietf-pce-stateful-pce] describes the basic 117 mechanism for state synchronization. This draft specifies 118 optimizations for state synchronization and the correspoding PCEP 119 extensions. 121 2. Terminology 123 This document uses the following terms defined in [RFC5440]: PCC, 124 PCE, PCEP Peer. 126 This document uses the following terms defined in 127 [I-D.ietf-pce-stateful-pce] : Delegation, Redelegation Timeout 128 Interval, LSP State Report, LSP Update Request, LSP State Database. 130 Within this document, when describing PCE-PCE communications, the 131 requesting PCE fills the role of a PCC. This provides a saving in 132 documentation without loss of function. 134 The message formats in this document are specified using Routing 135 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 137 3. State Synchronization Avoidance 139 3.1. Motivation 141 The purpose of state synchronization is to provide a checkpoint-in- 142 time state replica of a PCC's LSP state in a stateful PCE. State 143 synchronization is performed immediately after the initialization 144 phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic 145 mechanism for state synchronization. 147 State synchronization is not always necessary following a PCEP 148 session restart. If the state of both PCEP peers did not change, the 149 synchronization phase may be skipped. This can result in significant 150 savings in both control-plane data exchanges and the time it takes 151 for the stateful PCE to become fully operational. 153 3.2. State Synchronization Avoidance Procedure 155 State synchronization MAY be skipped following a PCEP session restart 156 if the state of both PCEP peers did not change during the period 157 prior to session re-initialization. To be able to make this 158 determination, state must be exchanged and maintained by both PCE and 159 PCC during normal operation. This is accomplished by keeping track 160 of the changes to the LSP state database, using a version tracking 161 field called the LSP State Database Version Number. 163 The LSP State Database Version Number, carried in LSP-DB-VERSION TLV 164 (see Section 3.3.1), is owned by a PCC and it MUST be incremented by 165 1 for each successive change in the PCC's LSP state database. The 166 LSP State Database Version Number MUST start at 1 and may wrap 167 around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of 168 the two values are used during LSP state (re)-synchronization, the 169 PCE speaker receiving this node should send back a PCErr with Error- 170 type 20 Error-value 6 'Received an invalid LSP DB Version Number', 171 and close the PCEP session. Operations that trigger a change to the 172 local LSP state database include a change in the LSP operational 173 state, delegation of an LSP, removal or setup of an LSP or change in 174 any of the LSP attributes that would trigger a report to the PCE. 176 State synchronization avoidance is advertised on a PCEP session 177 during session startup using the INCLUDE-DB-VERSION (IDB) bit in the 178 capabilities TLV (see Section 6). The peer may move in the network, 179 either physically or logically, which may cause its connectivity 180 details and transport-level identity (such as IP address) to change. 181 To ensure that a PCEP peer can recognize a previously connected peer 182 even in face of such mobility, each PCEP peer includes the SPEAKER- 183 ENTITY-ID TLV described in Section 3.3.2 in the OPEN message. 185 If both PCEP speakers set the IDB flag in the OPEN object's STATEFUL- 186 PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV 187 in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV 188 is missing in a PCRpt message, the PCE will generate an error with 189 error-type 6 (mandatory object missing) and Error Value 12 (LSP-DB- 190 VERSION TLV missing) and close the session. If state synchronization 191 avoidance has not been enabled on a PCEP session, the PCC SHOULD NOT 192 include the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD 193 ignore it were to receive one. 195 If a PCE's LSP state database survived the restart of a PCEP session, 196 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 197 the TLV will contain the last LSP State Database Version Number 198 received on an LSP State Report from the PCC in the previous PCEP 199 session. If a PCC's LSP State Database survived the restart of a 200 PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN 201 object and the TLV will contain the latest LSP State Database Version 202 Number. If a PCEP speaker's LSP state database did not survive the 203 restart of a PCEP session, the PCEP speaker MUST NOT include the LSP- 204 DB-VERSION TLV in the OPEN object. 206 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 207 Object and the TLV values match, the PCC MAY skip state 208 synchronization. Otherwise, the PCC MUST perform state 209 synchronization to the stateful PCE. If the PCC attempts to skip 210 state synchronization (i.e., the SYNC Flag = 0 on the first LSP State 211 Report from the PCC as per [I-D.ietf-pce-stateful-pce]), the PCE MUST 212 send back a PCErr with Error-type 20 Error-value 2 'LSP Database 213 version mismatch', and close the PCEP session. 215 If state synchronization is required, then prior to completing the 216 initialization phase, the PCE MUST mark any LSPs in the LSP database 217 that were previously reported by the PCC as stale. When the PCC 218 reports an LSP during state synchronization, if the LSP already 219 exists in the LSP database, the PCE MUST update the LSP database and 220 clear the stale marker from the LSP. When it has finished state 221 synchronization, the PCC MUST immediately send an end of 222 synchronization marker. The end of synchronization marker is a Path 223 Computation State Report (PCRpt) message with an LSP object 224 containing a PLSP-ID of 0 and with the SYNC flag set to 0 225 ([I-D.ietf-pce-stateful-pce]). The LSP-DB-VERSION TLV MUST be 226 included in this PCRpt message. On receiving this state report, the 227 PCE MUST purge any LSPs from the LSP database that are still marked 228 as stale. 230 Note that a PCE/PCC MAY force state synchronization by not including 231 the LSP-DB-VERSION TLV in its OPEN object. 233 Since a PCE does not make changes to the LSP State Database Version 234 Number, a PCC should never encounter this TLV in a message from the 235 PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- 236 VERSION TLV, were it to receive one from a PCE. 238 If state synchronization avoidance is enabled, a PCC MUST increment 239 its LSP State Database Version Number when the 'Redelegation Timeout 240 Interval' timer expires (see [I-D.ietf-pce-stateful-pce]) for the use 241 of the Redelegation Timeout Interval). 243 Figure 1 shows an example sequence where the state synchronization is 244 skipped. 246 +-+-+ +-+-+ 247 |PCC| |PCE| 248 +-+-+ +-+-+ 249 | | 250 |--Open--, | 251 | DBv=42 \ ,---Open--| 252 | IDB=1 \ / DBv=42 | 253 | \/ IDB=1 | 254 | /\ | 255 | / `-------->| (OK to skip sync) 256 (Skip sync) |<--------` | 257 | . | 258 | . | 259 | . | 260 | | 261 |--PCRpt,DBv=43,SYNC=0-->| (Regular 262 | | LSP State Report) 263 |--PCRpt,DBv=44,SYNC=0-->| (Regular 264 | | LSP State Report) 265 |--PCRpt,DBv=45,SYNC=0-->| 266 | | 268 Figure 1: State Synchronization Skipped 270 Figure 2 shows an example sequence where the state synchronization is 271 performed due to LSP state database version mismatch during the PCEP 272 session setup. Note that the same state synchronization sequence 273 would happen if either the PCC or the PCE would not include the LSP- 274 DB-VERSION TLV in their respective Open messages. 276 +-+-+ +-+-+ 277 |PCC| |PCE| 278 +-+-+ +-+-+ 279 | | 280 |--Open--, | 281 | DBv=46 \ ,---Open--| 282 | IDB=1 \ / DBv=42 | 283 | \/ IDB=1 | 284 | /\ | 285 | / `-------->| (Expect sync) 286 (Do sync) |<--------` | 287 | | 288 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 289 | . | 290 | . | 291 | . | 292 |--PCRpt,DBv=46,SYNC=0-->| (Sync done) 293 | . |(Purge LSP State 294 | . | if applicable) 295 | . | 296 |--PCRpt,DBv=47,SYNC=0-->| (Regular 297 | | LSP State Report) 298 |--PCRpt,DBv=48,SYNC=0-->| (Regular 299 | | LSP State Report) 300 |--PCRpt,DBv=49,SYNC=0-->| 301 | | 303 Figure 2: State Synchronization Performed 305 Figure 3 shows an example sequence where the state synchronization is 306 skipped, but because one or both PCEP speakers set the IDB Flag to 0, 307 the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt 308 messages to the PCE. If the current PCEP session restarts, the PCEP 309 speakers will have to perform state synchronization, since the PCE 310 does not know the PCC's latest LSP State Database Version Number 311 information. 313 +-+-+ +-+-+ 314 |PCC| |PCE| 315 +-+-+ +-+-+ 316 | | 317 |--Open--, | 318 | DBv=42 \ ,---Open--| 319 | IDB=0 \ / DBv=42 | 320 | \/ IDB=0 | 321 | /\ | 322 | / `-------->| (OK to skip sync) 323 (Skip sync) |<--------` | 324 | . | 325 | . | 326 | . | 327 |------PCRpt,SYNC=0----->| (Regular 328 | | LSP State Report) 329 |------PCRpt,SYNC=0----->| (Regular 330 | | LSP State Report) 331 |------PCRpt,SYNC=0----->| 332 | | 334 Figure 3: State Synchronization Skipped, no LSP-DB-VERSION TLVs sent 335 from PCC 337 3.3. PCEP Extensions 339 3.3.1. LSP State Database Version Number TLV 341 The LSP State Database Version Number (LSP-DB-VERSION) TLV is an 342 optional TLV that MAY be included in the OPEN object and the LSP 343 object. 345 The format of the LSP-DB-VERSION TLV is shown in the following 346 figure: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type=[TBD] | Length=8 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | LSP State DB Version Number | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 4: LSP-DB-VERSION TLV format 359 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 360 The value contains a 64-bit unsigned integer, representing the LSP 361 State DB Version Number. 363 3.3.2. Speaker Entity Identifier TLV 365 The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional 366 TLV that MAY be included in the OPEN Object when a PCEP speaker 367 wishes to determine if state synchronization can be skipped when a 368 PCEP session is restarted. It contains a unique identifier for the 369 node that does not change during the lifetime of the PCEP speaker. 370 It identifies the PCEP speaker to its peers even if the speaker's IP 371 address is changed. 373 The format of the SPEAKER-ENTITY-ID TLV is shown in the following 374 figure: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type=[TBD] | Length (variable) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 // Speaker Entity Identifier // 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 5: SPEAKER-ENTITY-ID TLV format 388 The type of the TLV is [TBD] and it has a a variable length, which 389 MUST be greater than 0 and padded to 4-octet alignment (, and padding 390 is not included in the Length field). The value contains the entity 391 identifier of the speaker transmitting this TLV. This identifier is 392 required to be unique within its scope of visibility, which is 393 usually limited to a single domain. It MAY be configured by the 394 operator. Alternatively, it can be derived automatically from a 395 suitably-stable unique identifier, such as a MAC address, serial 396 number, Traffic Engineering Router ID, or similar. In the case of 397 inter-domain connections, the speaker SHOULD prefix its usual 398 identifier with the domain identifier of its residence, such as 399 Autonomous System number, IGP area identifier, or similar. 401 The relationship between this identifier and entities in the Traffic 402 Engineering database is intentionally left undefined. 404 From a manageability point of view, a PCE or PCC implementation 405 SHOULD allow the operator to configure this Speaker Entity 406 Identifier. 408 4. PCE-triggered State Synchronization 410 4.1. Motivation 412 The accuracy of the computations performed by the PCE is tied to the 413 accuracy of the view the PCE has on the state of the LSPs. 414 Therefore, it can be beneficial to be able to resynchronize this 415 state even after the session has been established. The PCE may use 416 this approach to continuously sanity check its state against the 417 network, or to recover from error conditions without having to tear 418 down sessions. 420 4.2. PCE-triggered State Synchronization Procedure 422 Support of PCE-triggered state synchronization is advertised during 423 session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE- 424 CAPABILITY TLV (see Section 6). The PCE can choose to resynchronize 425 its entire LSP database or a single LSP. 427 To trigger resynchronization for an LSP, the PCE MUST first mark the 428 LSP as stale and then send a Path Computation State Update (PCUpd) 429 for it, with the SYNC flag in the LSP object set to 1. The PCE 430 SHOULD NOT include any parameter updates for the LSP, and the PCC 431 SHOULD ignore such updates if the SYNC flag is set. The PCC MUST 432 respond with a PCRpt message and SHOULD include the SRP-ID-number of 433 the PCUpd that triggered the resynchronization. 435 The PCE can also trigger resynchronization of the entire LSP 436 database. The PCE MUST first mark all LSPs in the LSP database that 437 were previously reported by the PCC as stale and then send a PCUpd 438 with an LSP object containing a PLSP-ID of 0 and with the SYNC flag 439 set to 1. This PCUpd message is the trigger for the PCC to enter the 440 synchronization phase as described in [I-D.ietf-pce-stateful-pce] and 441 start sending PCRpt messages. After the receipt of the end-of- 442 synchronization marker, the PCE will purge LSPs which were not 443 refreshed. The SRP-ID-number of the PCUpd that triggered the 444 resynchronization SHOULD be included in each of the PCRpt messages. 446 If the TRIGGERED-SYNC capability is not advertised and the PCC 447 receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr 448 with the SRP-ID-number of the PCUpd, error-type 20 and error-value 449 4.(see Section 7.1) 451 5. Incremental State Synchronization 453 [I-D.ietf-pce-stateful-pce] describes the LSP state synchronization 454 mechanism between PCCs and stateful PCEs. During the state 455 synchronization, a PCC sends the information of all its LSPs (full 456 LSP-DB) to the stateful PCE. In order to save the state 457 synchronization overhead when there is a small number of LSP state 458 change in the network between PCEP session restart as well as 459 avoiding overloading a PCE during state (re-)synchronization phase, 460 this section proposes a mechanism for incremental (Delta) LSP 461 Database (LSP-DB) synchronization as well as allowing PCE to control 462 the timing of the LSP-DB synchronization process during incremental 463 syncronization. 465 5.1. Motivation 467 According to [I-D.ietf-pce-stateful-pce] , if a PCE restarts and its 468 LSP-DB survived, PCCs with mismatched LSP State Database Version 469 Number will send all their LSPs information (full LSP-DB) to the 470 stateful PCE, even if only a small number of LSPs underwent state 471 change. It can take a long time and consume large communication 472 channel bandwidth. Moreover, the stateful PCE can get overloaded 473 with all the PCC performing full synchronization with it at the same 474 time. 476 Figure 6 shows an example of LSP state synchronization. 478 +-----+ 479 | PCE | 480 +-----+ 481 / 482 / 483 / 484 / 485 +------+ +------+ 486 | PCC1 |------------| PCC2 | 487 +------+ +------+ 488 | | 489 | | 490 +------+ +------+ 491 | PCC3 |------------| PCC4 | 492 +------+ +------+ 494 Figure 6: Topology Example 496 Assuming there are 320 LSPs in the network, with each PCC having 80 497 LSPs. During the time when the PCEP session is down, 20 LSPs of each 498 PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session 499 restarts, the stateful PCE needs to synchronize 320 LSPs with all 500 PCCs. But actually, 240 LSPs stay the same. If performing full LSP 501 state synchronization, it can take a long time to carry out the 502 synchronization of all LSPs. It is especially true when only a low 503 bandwidth communication channel is available and there is a 504 substantial number of LSPs in the network. Another disadvantage of 505 full LSP synchronization is that it is a waste of communication 506 bandwidth to perform full LSP synchronization given the fact that the 507 number of LSP changes can be small during the time when PCEP session 508 is down. 510 An incremental (Delta) LSP Database (LSP-DB) state synchronization is 511 described in this section, where only the LSPs underwent state change 512 are synchronized between the session restart. This may include new/ 513 modified/deleted LSPs. Furthermore, to avoid overloading the PCE, 514 the proposed method enable a stateful PCE to trigger the LSP 515 synchronization (similar to Section 4). 517 PCEP extensions for stateful PCEs to perform LSP synchronization 518 SHOULD allow: 520 o Incremental LSP state synchronization between session restarts. 521 Note this does not exclude the need for a stateful PCE to request 522 a full LSP DB synchronization. 524 o A stateful PCE to control the timing of PCC synchronizing its LSP 525 state with the PCE during incremental synchronisation. 527 5.2. Incremental Synchronization Procedure 529 [I-D.ietf-pce-stateful-pce] describes state synchronization and 530 Section 3 describes state synchronization avoidance by using LSP-DB- 531 VERSION TLV in its OPEN object. This section extends this idea to 532 only synchronize the delta (changes) in case of version mismatch as 533 well as to allow a stateful PCE to control the timing of this 534 process. 536 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 537 object and the LSP-DB-VERSION TLV values match, the PCC MAY skip 538 state synchronization. Otherwise, the PCC MUST perform state 539 synchronization. Instead of dumping full LSP-DB to PCE again, the 540 PCC synchronizes the delta (changes) as described in Figure 7 when 541 DELTA-LSP-SYNC-CAPABILITY (D flag) is set to 1 by both PCC and PCE 542 (see Section 6). Other combinations of D flag setting by PCC and PCE 543 result in full LSP-DB synchronization procedure as described in 544 [I-D.ietf-pce-stateful-pce]. If a PCC has to force full LSP DB 545 synchronization due to reasons including but not limited: (1) local 546 policy configured at the PCC; (2) no sufficient LSP state caches for 547 incremental update, the PCC can set the D flag to 0. Note a PCC may 548 have to bring down the current session and force a full LSPDB 549 synchronization with D flag set to 0 in the subsequent open message. 551 +-+-+ +-+-+ 552 |PCC| |PCE| 553 +-+-+ +-+-+ 554 | | 555 |--Open--, | 556 | DBv=46 \ ,---Open--| 557 | IDB=1 \ / DBv=42 | 558 | D=1 \/ IDB=1 | 559 | T=1 /\ D=1 | 560 | / \ T=1 | 561 | / `-------->| (Expect Delta sync) 562 (Do sync)|<--------` | (DONOT Purge LSP 563 (Delta) | | State) 564 (Wait for PCE to | | 565 trigger LSP state | | 566 sync) | | 567 |<----PCUpd, SYNC=1------| (ask for LSP Sync, 568 | | PLSP-ID =0) 569 (Delta Sync starts) |--PCRpt,DBv=43,SYNC=1-->| 570 | . | 571 | . | 572 | . | 573 | . | 574 |--PCRpt,DBv=46,SYNC=0-->| (Sync done, 575 | | PLSP-ID=0) 576 | | 577 |--PCRpt,DBv=47,SYNC=0-->| (Regular 578 | | LSP State Report) 579 |--PCRpt,DBv=48,SYNC=0-->| (Regular 580 | | LSP State Report) 581 |--PCRpt,DBv=49,SYNC=0-->| 582 | | 584 Figure 7: Incremental Synchronization Procedure 586 A stateful PCE MAY choose to control the LSP-DB synchronization 587 process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to 588 indicate this (as described in Section 4). If the LSP-DB Version is 589 mis-matched, it can send a PCUpd message with PLSP-ID = 0 and SYNC = 590 1 in order to trigger the LSP-DB synchronization process. In this 591 way, the PCE can control the sequence of LSP synchronization among 592 all the PCCs that are re-establishing PCEP sessions with it. When 593 the capability of PCE control is enabled, only after a PCC receives 594 this message, it will start sending information that PCE does not 595 possess, which is inferred from the LSP-DB version information 596 exchanged in the OPEN message. Note that the PCE should not mark the 597 existing LSPs as stale for incremental state synchronisation 598 procedure. 600 As per Section 3, the LSP State Database Version Number is 601 incremented each time a change is made to the PCC's local LSP State 602 Database. Each LSP is associated with the DB version at the time of 603 its state change. This is needed to determine which LSP and what 604 information needs to be synchronized in incremental state 605 synchronization. 607 It is not necessary for a PCC to store a complete history of LSP 608 Database change, but rather remember the LSP state changes (including 609 LSP modification, setup and deletion) that happend between the PCEP 610 session(s) restart in order to carry out incremental state 611 synchronization. After the synchronization procedure finishes, the 612 PCC can dump this history information. In the example shown in 613 Figure 7, the PCC needs to store the LSP state changes that happend 614 between DB Version 43 to 46 and synchronizes these changes only when 615 performing incremental LSP state update. So a PCC needs to remember 616 the LSP state changes that happened when an existing PCEP session to 617 a stateful PCE goes down in the hope of doing incremental 618 synchronisation when the session is re-established. 620 If a PCC finds out it does not have sufficient information to 621 complete incremental synchronisation after advertising incremental 622 LSP state synchronization capability, it MUST send a PCErr with 623 error-type 20 and error-value 5(see Section 7.1) and terminate the 624 session. 626 6. Advertising Support of Synchronization Optimizations 628 Support for each of the optimizations described in this document 629 requires advertising the corresponding capabilities during session 630 establishment time. 632 New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 633 [I-D.ietf-pce-stateful-pce]. Its format is shown in the following 634 figure: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length=4 | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Flags |D|T|I|S|U| 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 8: STATEFUL-PCE-CAPABILITY TLV Format 646 The value comprises a single field - Flags (32 bits): 648 U (LSP-UPDATE-CAPABILITY - 1 bit): defined in 649 [I-D.ietf-pce-stateful-pce]. 651 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 652 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 654 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): defined in 655 [I-D.crabbe-pce-pce-initiated-lsp]. 657 T (TRIGGERED-SYNC - 1 bit): if set to 1 by both PCEP Speakers, the 658 PCE can trigger synchronization of LSPs at any point in the life 659 of the session. 661 D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP 662 speaker, it indicates that the PCEP speaker allows incremental 663 state synchronization. 665 7. IANA Considerations 667 This document requests IANA actions to allocate code points for the 668 protocol elements defined in this document. Values shown here are 669 suggested for use by IANA. 671 7.1. PCEP-Error Object 673 This document defines new Error-Value values for the LSP state 674 synchronization error defined in [I-D.ietf-pce-stateful-pce]. 676 Error-Type Meaning 677 6 Mandatory Object missing 678 Error-value=12: LSP-DB-VERSION TLV missing 679 20 LSP State synchronization error 680 Error-value=2: LSP Database version mismatch. 681 Error-value=3: The LSP-DB-VERSION TLV Missing when 682 state synchronization avoidance is 683 enabled. 684 Error-value=4: Attempt to trigger a synchronization 685 when the TRIGGERED-SYNC capability has 686 not been advertised. 687 Error-value=5: No sufficient LSP change information 688 for incremental LSP state 689 synchronization. 691 Error-value=6: Received an invalid LSP DB Version 692 Number 694 7.2. PCEP TLV Type Indicators 696 This document defines the following new PCEP TLVs: 698 Value Meaning Reference 699 23 LSP-DB-VERSION This document 700 24 SPEAKER-ENTITY-ID This document 702 7.3. STATEFUL-PCE-CAPABILITY TLV 704 The following values are defined in this document for the Flags field 705 in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object: 707 Bit Description Reference 709 28 DELTA-LSP-SYNC-CAPABILITY This document 710 29 TRIGGERED-SYNC This document 711 30 INCLUDE-DB-VERSION This document 713 8. Security Considerations 715 The security considerations listed in [I-D.ietf-pce-stateful-pce] 716 apply to this document as well. 718 9. Acknowledgements 720 We would like to thank Young Lee for his contributions. 722 10. Contributors 724 Gang Xie 725 Huawei Technologies 726 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 727 Shenzhen, Guangdong, 518129 728 P.R. China 729 Email: xiegang09@huawei.com 731 11. References 732 11.1. Normative References 734 [I-D.ietf-pce-stateful-pce] 735 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 736 Extensions for Stateful PCE", 737 draft-ietf-pce-stateful-pce-08 (work in progress), 738 February 2014. 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 744 (PCE) Communication Protocol (PCEP)", RFC 5440, 745 March 2009. 747 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 748 Used to Form Encoding Rules in Various Routing Protocol 749 Specifications", RFC 5511, April 2009. 751 11.2. Informative References 753 [I-D.crabbe-pce-pce-initiated-lsp] 754 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 755 Extensions for PCE-initiated LSP Setup in a Stateful PCE 756 Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in 757 progress), October 2013. 759 Authors' Addresses 761 Edward Crabbe 762 Google, Inc. 763 1600 Amphitheatre Parkway 764 Mountain View, CA 94043 765 US 767 Email: edc@google.com 769 Jan Medved 770 Cisco Systems, Inc. 771 170 West Tasman Dr. 772 San Jose, CA 95134 773 US 775 Email: jmedved@cisco.com 776 Ina Minei 777 Google, Inc. 778 1600 Amphitheatre Parkway 779 Mountain View, CA 94043 780 US 782 Email: inaminei@google.com 784 Robert Varga 785 Pantheon Technologies SRO 786 Mlynske Nivy 56 787 Bratislava 821 05 788 Slovakia 790 Email: robert.varga@pantheon.sk 792 Xian Zhang 793 Huawei Technologies 794 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 795 Shenzhen, Guangdong 518129 796 P.R.China 798 Email: zhang.xian@huawei.com 800 Dhruv Dhody 801 Huawei Technologies 802 Leela Palace 803 Bangalore, Karnataka 560008 804 INDIA 806 Email: dhruv.ietf@gmail.com