idnits 2.17.1 draft-ietf-pce-stateful-sync-optimizations-01.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 (June 27, 2014) is 3563 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 397, but not defined == Unused Reference: 'I-D.ietf-pce-pce-initiated-lsp' is defined on line 781, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-09 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-01 Summary: 0 errors (**), 0 flaws (~~), 5 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 I. Minei 4 Intended status: Standards Track Google, Inc. 5 Expires: December 29, 2014 J. Medved 6 Cisco Systems, Inc. 7 R. Varga 8 Pantheon Technologies SRO 9 X. Zhang 10 D. Dhody 11 Huawei Technologies 12 June 27, 2014 14 Optimizations of Label Switched Path State Synchronization Procedures 15 for a Stateful PCE 16 draft-ietf-pce-stateful-sync-optimizations-01 18 Abstract 20 A stateful Path Computation Element (PCE) has access to not only the 21 information disseminated by the network's Interior Gateway Protocol 22 (IGP), but also the set of active paths and their reserved resources 23 for its computation. The additional Label Switched Path (LSP) state 24 information allows the PCE to compute constrained paths while 25 considering individual LSPs and their interactions. This requires a 26 reliable state synchronization mechanism between the PCE and the 27 network, PCE and path computation clients (PCCs), and between 28 cooperating PCEs. The basic mechanism for state synchronization is 29 part of the stateful PCE specification. This draft presents 30 motivations for optimizations to the base state synchronization 31 procedure and specifies the required Path Computation Element 32 Communication Protocol (PCEP) extensions. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 29, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. State Synchronization Avoidance . . . . . . . . . . . . . . . 3 77 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 78 3.2. State Synchronization Avoidance Procedure . . . . . . . . 4 79 3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 8 80 3.3.1. LSP State Database Version Number TLV . . . . . . . . 8 81 3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 9 82 4. Incremental State Synchronization . . . . . . . . . . . . . . 10 83 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 10 84 4.2. Incremental Synchronization Procedure . . . . . . . . . . 11 85 5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 13 86 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.2. PCE-triggered Initial State Synchronization Procedure . . 13 88 6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . 14 89 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 14 90 6.2. PCE-triggered State Re-synchronization Procedure . . . . 14 91 7. Advertising Support of Synchronization Optimizations . . . . 15 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 93 8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 94 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 16 95 8.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 17 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 101 12.2. Informative References . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 104 1. Introduction 106 The Path Computation Element Communication Protocol (PCEP) provides 107 mechanisms for Path Computation Elements (PCEs) to perform path 108 computations in response to Path Computation Clients (PCCs) requests. 110 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 111 provide stateful control. A stateful PCE has access to not only the 112 information carried by the network's Interior Gateway Protocol (IGP), 113 but also the set of active paths and their reserved resources for its 114 computations. The additional state allows the PCE to compute 115 constrained paths while considering individual LSPs and their 116 interactions. This requires a reliable state synchronization 117 mechanism between the PCE and the network, PCE and PCC, and between 118 cooperating PCEs. [I-D.ietf-pce-stateful-pce] describes the basic 119 mechanism for state synchronization. This draft specifies 120 optimizations for state synchronization and the corresponding PCEP 121 extensions. 123 2. Terminology 125 This document uses the following terms defined in [RFC5440]: PCC, 126 PCE, PCEP Peer. 128 This document uses the following terms defined in 129 [I-D.ietf-pce-stateful-pce] : Delegation, Redelegation Timeout 130 Interval, LSP State Report, LSP Update Request, LSP State Database. 132 Within this document, when describing PCE-PCE communications, the 133 requesting PCE fills the role of a PCC. This provides a saving in 134 documentation without loss of function. 136 3. State Synchronization Avoidance 138 3.1. Motivation 140 The purpose of state synchronization is to provide a checkpoint-in- 141 time state replica of a PCC's LSP state in a stateful PCE. State 142 synchronization is performed immediately after the initialization 143 phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic 144 mechanism for state synchronization. 146 State synchronization is not always necessary following a PCEP 147 session restart. If the state of both PCEP peers did not change, the 148 synchronization phase may be skipped. This can result in significant 149 savings in both control-plane data exchanges and the time it takes 150 for the stateful PCE to become fully operational. 152 3.2. State Synchronization Avoidance Procedure 154 State synchronization MAY be skipped following a PCEP session restart 155 if the state of both PCEP peers did not change during the period 156 prior to session re-initialization. To be able to make this 157 determination, state must be exchanged and maintained by both PCE and 158 PCC during normal operation. This is accomplished by keeping track 159 of the changes to the LSP state database, using a version tracking 160 field called the LSP State Database Version Number. 162 The LSP State Database Version Number, carried in LSP-DB-VERSION TLV 163 (see Section 3.3.1), is owned by a PCC and it MUST be incremented by 164 1 for each successive change in the PCC's LSP state database. The 165 LSP State Database Version Number MUST start at 1 and may wrap 166 around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of 167 the two values are used during LSP state (re)-synchronization, the 168 PCE speaker receiving this node should send back a PCErr with Error- 169 type 20 Error-value 6 'Received an invalid LSP DB Version Number', 170 and close the PCEP session. Operations that trigger a change to the 171 local LSP state database include a change in the LSP operational 172 state, delegation of an LSP, removal or setup of an LSP or change in 173 any of the LSP attributes that would trigger a report to the PCE. 175 State synchronization avoidance is advertised on a PCEP session 176 during session startup using the INCLUDE-DB-VERSION (IDB) bit in the 177 capabilities TLV (see Section 7). The peer may move in the network, 178 either physically or logically, which may cause its connectivity 179 details and transport-level identity (such as IP address) to change. 180 To ensure that a PCEP peer can recognize a previously connected peer 181 even in face of such mobility, each PCEP peer includes the SPEAKER- 182 ENTITY-ID TLV described in Section 3.3.2 in the OPEN message. 184 If both PCEP speakers set the IDB flag in the OPEN object's STATEFUL- 185 PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV 186 in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV 187 is missing in a PCRpt message, the PCE will generate an error with 188 error-type 6 (mandatory object missing) and Error Value 12 (LSP-DB- 189 VERSION TLV missing) and close the session. If state synchronization 190 avoidance has not been enabled on a PCEP session, the PCC SHOULD NOT 191 include the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD 192 ignore it were to receive one. 194 If a PCE's LSP state database survived the restart of a PCEP session, 195 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 196 the TLV will contain the last LSP State Database Version Number 197 received on an LSP State Report from the PCC in the previous PCEP 198 session. If a PCC's LSP State Database survived the restart of a 199 PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN 200 object and the TLV will contain the latest LSP State Database Version 201 Number. If a PCEP speaker's LSP state database did not survive the 202 restart of a PCEP session, the PCEP speaker MUST NOT include the LSP- 203 DB-VERSION TLV in the OPEN object. 205 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 206 Object and the TLV values match, the PCC MAY skip state 207 synchronization. Otherwise, the PCC MUST perform state 208 synchronization to the stateful PCE. If the PCC attempts to skip 209 state synchronization (i.e., the SYNC Flag = 0 on the first LSP State 210 Report from the PCC as per [I-D.ietf-pce-stateful-pce]), the PCE MUST 211 send back a PCErr with Error-type 20 Error-value 2 'LSP Database 212 version mismatch', and close the PCEP session. 214 If state synchronization is required, then prior to completing the 215 initialization phase, the PCE MUST mark any LSPs in the LSP database 216 that were previously reported by the PCC as stale. When the PCC 217 reports an LSP during state synchronization, if the LSP already 218 exists in the LSP database, the PCE MUST update the LSP database and 219 clear the stale marker from the LSP. When it has finished state 220 synchronization, the PCC MUST immediately send an end of 221 synchronization marker. The end of synchronization marker is a Path 222 Computation State Report (PCRpt) message with an LSP object 223 containing a PLSP-ID of 0 and with the SYNC flag set to 0 224 ([I-D.ietf-pce-stateful-pce]). The LSP-DB-VERSION TLV MUST be 225 included in this PCRpt message. On receiving this state report, the 226 PCE MUST purge any LSPs from the LSP database that are still marked 227 as stale. 229 Note that a PCE/PCC MAY force state synchronization by not including 230 the LSP-DB-VERSION TLV in its OPEN object. 232 Since a PCE does not make changes to the LSP State Database Version 233 Number, a PCC should never encounter this TLV in a message from the 234 PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- 235 VERSION TLV, were it to receive one from a PCE. 237 If state synchronization avoidance is enabled, a PCC MUST increment 238 its LSP State Database Version Number when the 'Redelegation Timeout 239 Interval' timer expires (see [I-D.ietf-pce-stateful-pce]) for the use 240 of the Redelegation Timeout Interval). 242 Figure 1 shows an example sequence where the state synchronization is 243 skipped. 245 +-+-+ +-+-+ 246 |PCC| |PCE| 247 +-+-+ +-+-+ 248 | | 249 |--Open--, | 250 | DBv=42 \ ,---Open--| 251 | IDB=1 \ / DBv=42 | 252 | \/ IDB=1 | 253 | /\ | 254 | / `-------->| (OK to skip sync) 255 (Skip sync) |<--------` | 256 | . | 257 | . | 258 | . | 259 | | 260 |--PCRpt,DBv=43,SYNC=0-->| (Regular 261 | | LSP State Report) 262 |--PCRpt,DBv=44,SYNC=0-->| (Regular 263 | | LSP State Report) 264 |--PCRpt,DBv=45,SYNC=0-->| 265 | | 267 Figure 1: State Synchronization Skipped 269 Figure 2 shows an example sequence where the state synchronization is 270 performed due to LSP state database version mismatch during the PCEP 271 session setup. Note that the same state synchronization sequence 272 would happen if either the PCC or the PCE would not include the LSP- 273 DB-VERSION TLV in their respective Open messages. 275 +-+-+ +-+-+ 276 |PCC| |PCE| 277 +-+-+ +-+-+ 278 | | 279 |--Open--, | 280 | DBv=46 \ ,---Open--| 281 | IDB=1 \ / DBv=42 | 282 | \/ IDB=1 | 283 | /\ | 284 | / `-------->| (Expect sync) 285 (Do sync) |<--------` | 286 | | 287 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 288 | . | 289 | . | 290 | . | 291 |--PCRpt,DBv=46,SYNC=0-->| (Sync done) 292 | . |(Purge LSP State 293 | . | if applicable) 294 | . | 295 |--PCRpt,DBv=47,SYNC=0-->| (Regular 296 | | LSP State Report) 297 |--PCRpt,DBv=48,SYNC=0-->| (Regular 298 | | LSP State Report) 299 |--PCRpt,DBv=49,SYNC=0-->| 300 | | 302 Figure 2: State Synchronization Performed 304 Figure 3 shows an example sequence where the state synchronization is 305 skipped, but because one or both PCEP speakers set the IDB Flag to 0, 306 the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt 307 messages to the PCE. If the current PCEP session restarts, the PCEP 308 speakers will have to perform state synchronization, since the PCE 309 does not know the PCC's latest LSP State Database Version Number 310 information. 312 +-+-+ +-+-+ 313 |PCC| |PCE| 314 +-+-+ +-+-+ 315 | | 316 |--Open--, | 317 | DBv=42 \ ,---Open--| 318 | IDB=0 \ / DBv=42 | 319 | \/ IDB=0 | 320 | /\ | 321 | / `-------->| (OK to skip sync) 322 (Skip sync) |<--------` | 323 | . | 324 | . | 325 | . | 326 |------PCRpt,SYNC=0----->| (Regular 327 | | LSP State Report) 328 |------PCRpt,SYNC=0----->| (Regular 329 | | LSP State Report) 330 |------PCRpt,SYNC=0----->| 331 | | 333 Figure 3: State Synchronization Skipped, no LSP-DB-VERSION TLVs sent 334 from PCC 336 3.3. PCEP Extensions 338 3.3.1. LSP State Database Version Number TLV 340 The LSP State Database Version Number (LSP-DB-VERSION) TLV is an 341 optional TLV that MAY be included in the OPEN object and the LSP 342 object. 344 The format of the LSP-DB-VERSION TLV is shown in the following 345 figure: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type=[TBD] | Length=8 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | LSP State DB Version Number | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 4: LSP-DB-VERSION TLV format 358 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 359 The value contains a 64-bit unsigned integer, representing the LSP 360 State DB Version Number. 362 3.3.2. Speaker Entity Identifier TLV 364 The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional 365 TLV that MAY be included in the OPEN Object when a PCEP speaker 366 wishes to determine if state synchronization can be skipped when a 367 PCEP session is restarted. It contains a unique identifier for the 368 node that does not change during the lifetime of the PCEP speaker. 369 It identifies the PCEP speaker to its peers even if the speaker's IP 370 address is changed. 372 In case of a remote peer IP address change, a PCEP speaker would 373 learn the speaker entity identifier on receiving the open message but 374 it MAY have already sent its open message without realizing that it 375 is a known PCEP peer. In such a case, either a full synchronization 376 is done or PCEP session is terminated. This may be a local policy 377 decision. The new IP address is associated with the speaker entity 378 identifier for future either way. In the latter case when PCEP 379 session is re-established, it would be correctly associated with 380 speaker entity identifier and not be considered as an unknown peer. 382 The format of the SPEAKER-ENTITY-ID TLV is shown in the following 383 figure: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type=[TBD] | Length (variable) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 // Speaker Entity Identifier // 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 5: SPEAKER-ENTITY-ID TLV format 397 The type of the TLV is [TBD] and it has a a variable length, which 398 MUST be greater than 0 and padded to 4-octet alignment (, and padding 399 is not included in the Length field). The value contains the entity 400 identifier of the speaker transmitting this TLV. This identifier is 401 required to be unique within its scope of visibility, which is 402 usually limited to a single domain. It MAY be configured by the 403 operator. Alternatively, it can be derived automatically from a 404 suitably-stable unique identifier, such as a MAC address, serial 405 number, Traffic Engineering Router ID, or similar. In the case of 406 inter-domain connections, the speaker SHOULD prefix its usual 407 identifier with the domain identifier of its residence, such as 408 Autonomous System number, IGP area identifier, or similar. 410 The relationship between this identifier and entities in the Traffic 411 Engineering database is intentionally left undefined. 413 From a manageability point of view, a PCE or PCC implementation 414 SHOULD allow the operator to configure this Speaker Entity 415 Identifier. 417 4. Incremental State Synchronization 419 [I-D.ietf-pce-stateful-pce] describes the LSP state synchronization 420 mechanism between PCCs and stateful PCEs. During the state 421 synchronization, a PCC sends the information of all its LSPs (i.e., 422 the full LSP-DB) to the stateful PCE. In order to reduce the state 423 synchronization overhead when there is a small number of LSP state 424 change in the network between PCEP session restart, this section 425 proposes a mechanism for incremental (Delta) LSP Database (LSP-DB) 426 synchronization. 428 4.1. Motivation 430 According to [I-D.ietf-pce-stateful-pce] , if a PCE restarts and its 431 LSP-DB survived, PCCs with mismatched LSP State Database Version 432 Number will send all their LSPs information (full LSP-DB) to the 433 stateful PCE, even if only a small number of LSPs underwent state 434 change. It can take a long time and consume large communication 435 channel bandwidth. 437 Figure 6 shows an example of LSP state synchronization. 439 +-----+ 440 | PCE | 441 +-----+ 442 / 443 / 444 / 445 / 446 +------+ +------+ 447 | PCC1 |------------| PCC2 | 448 +------+ +------+ 449 | | 450 | | 451 +------+ +------+ 452 | PCC3 |------------| PCC4 | 453 +------+ +------+ 455 Figure 6: Topology Example 457 Assuming there are 320 LSPs in the network, with each PCC having 80 458 LSPs. During the time when the PCEP session is down, 20 LSPs of each 459 PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session 460 restarts, the stateful PCE needs to synchronize 320 LSPs with all 461 PCCs. But actually, 240 LSPs stay the same. If performing full LSP 462 state synchronization, it can take a long time to carry out the 463 synchronization of all LSPs. It is especially true when only a low 464 bandwidth communication channel is available and there is a 465 substantial number of LSPs in the network. Another disadvantage of 466 full LSP synchronization is that it is a waste of communication 467 bandwidth to perform full LSP synchronization given the fact that the 468 number of LSP changes can be small during the time when PCEP session 469 is down. 471 An incremental (Delta) LSP Database (LSP-DB) state synchronization is 472 described in this section, where only the LSPs underwent state change 473 are synchronized between the session restart. This may include 474 new/modified/deleted LSPs. 476 PCEP extensions for stateful PCEs to perform LSP synchronization 477 SHOULD allow: incremental LSP state synchronization between session 478 restarts. Note this does not exclude the need for a stateful PCE to 479 request a full LSP DB synchronization. 481 4.2. Incremental Synchronization Procedure 483 [I-D.ietf-pce-stateful-pce] describes state synchronization and 484 Section 3 describes state synchronization avoidance by using LSP-DB- 485 VERSION TLV in its OPEN object. This section extends this idea to 486 only synchronize the delta (changes) in case of version mismatch. 488 If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN 489 object and the LSP-DB-VERSION TLV values match, the PCC MAY skip 490 state synchronization. Otherwise, the PCC MUST perform state 491 synchronization. Instead of dumping full LSP-DB to the stateful PCE 492 again, the PCC synchronizes the delta (changes) as described in 493 Figure 7 when DELTA-LSP-SYNC-CAPABILITY (D flag) is set to 1 by both 494 PCC and PCE (see Section 7). Other combinations of D flag setting by 495 PCC and PCE result in full LSP-DB synchronization procedure as 496 described in [I-D.ietf-pce-stateful-pce]. If a PCC has to force full 497 LSP DB synchronization due to reasons including but not limited: (1) 498 local policy configured at the PCC; (2) no sufficient LSP state 499 caches for incremental update, the PCC can set the D flag to 0. Note 500 a PCC may have to bring down the current session and force a full 501 LSP-DB synchronization with D flag set to 0 in the subsequent open 502 message. 504 +-+-+ +-+-+ 505 |PCC| |PCE| 506 +-+-+ +-+-+ 507 | | 508 |--Open--, | 509 | DBv=46 \ ,---Open--| 510 | IDB=1 \ / DBv=42 | 511 | T=1 \/ IDB=1 | 512 | /\ T=1 | 513 | / \ | 514 | / `-------->| (Expect Delta sync) 515 (Do sync)|<--------` | (DONOT Purge LSP 516 (Delta) | | State) 517 | | 518 (Delta Sync starts) |--PCRpt,DBv=46,SYNC=1-->| 519 | . | 520 | . | 521 | . | 522 | . | 523 |--PCRpt,DBv=46,SYNC=0-->| (Sync done, 524 | | PLSP-ID=0) 525 | | 526 |--PCRpt,DBv=47,SYNC=0-->| (Regular 527 | | LSP State Report) 528 |--PCRpt,DBv=48,SYNC=0-->| (Regular 529 | | LSP State Report) 530 |--PCRpt,DBv=49,SYNC=0-->| 531 | | 533 Figure 7: Incremental Synchronization Procedure 535 As per Section 3, the LSP State Database Version Number is 536 incremented each time a change is made to the PCC's local LSP State 537 Database. Each LSP is associated with the DB version at the time of 538 its state change. This is needed to determine which LSP and what 539 information needs to be synchronized in incremental state 540 synchronization. 542 It is not necessary for a PCC to store a complete history of LSP 543 Database change, but rather remember the LSP state changes (including 544 LSP modification, setup and deletion) that happend between the PCEP 545 session(s) restart in order to carry out incremental state 546 synchronization. After the synchronization procedure finishes, the 547 PCC can dump this history information. In the example shown in 548 Figure 7, the PCC needs to store the LSP state changes that happend 549 between DB Version 43 to 46 and synchronizes these changes only when 550 performing incremental LSP state update. So a PCC needs to remember 551 the LSP state changes that happened when an existing PCEP session to 552 a stateful PCE goes down in the hope of doing incremental 553 synchronisation when the session is re-established. 555 If a PCC finds out it does not have sufficient information to 556 complete incremental synchronisation after advertising incremental 557 LSP state synchronization capability, it MUST send a PCErr with 558 error-type 20 and error-value 5(see Section 8.1) and terminate the 559 session. 561 5. PCE-triggered Initial Synchronization 563 5.1. Motivation 565 In networks such as optical transport networks, the control channel 566 between network nodes can be realized through in-band overhead thus 567 has limited bandwidth. With a stateful PCE connected to the network 568 via one network node, it is desirable to control the timing of PCC 569 state synchronization so as not to overload the low communication 570 channel available in the network during the initial synchronization 571 (be it incremental or full) when the session restarts , when there is 572 comparatively large amount of control information needing to be 573 synchronized between the stateful PCE and the network. The method 574 proposed, i.e., allowing PCE to trigger the state synchronization, is 575 similar to the function proposed in Section 6 but is used in 576 different scenarios and for different purposes. 578 5.2. PCE-triggered Initial State Synchronization Procedure 580 Support of PCE-triggered state synchronization is advertised during 581 session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE- 582 CAPABILITY TLV (see Section 7). 584 A stateful PCE MAY choose to control the LSP-DB synchronization 585 process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to 586 indicate this (as described in Section 6). If the LSP-DB Version is 587 mis-matched, it can send a PCUpd message with PLSP-ID = 0 and SYNC = 588 1 in order to trigger the LSP-DB synchronization process. In this 589 way, the PCE can control the sequence of LSP synchronization among 590 all the PCCs that are re-establishing PCEP sessions with it. When 591 the capability of PCE control is enabled, only after a PCC receives 592 this message, it will start sending information to the PCE. This 593 PCE-triggering capability can be applied to both full and incremental 594 state synchronization. If applied to the later, the PCCs only send 595 information that PCE does not possess, which is inferred from the 596 LSP-DB version information exchanged in the OPEN message (see 597 Section 4.2 for detailed procedure). 599 6. PCE-triggered Re-synchronization 601 6.1. Motivation 603 The accuracy of the computations performed by the PCE is tied to the 604 accuracy of the view the PCE has on the state of the LSPs. 605 Therefore, it can be beneficial to be able to resynchronize this 606 state even after the session has been established. The PCE may use 607 this approach to continuously sanity check its state against the 608 network, or to recover from error conditions without having to tear 609 down sessions. 611 6.2. PCE-triggered State Re-synchronization Procedure 613 Support of PCE-triggered state synchronization is advertised during 614 session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE- 615 CAPABILITY TLV (see Section 7). The PCE can choose to resynchronize 616 its entire LSP database or a single LSP. 618 To trigger resynchronization for an LSP, the PCE MUST first mark the 619 LSP as stale and then send a Path Computation State Update (PCUpd) 620 for it, with the SYNC flag in the LSP object set to 1. The PCE 621 SHOULD NOT include any parameter updates for the LSP, and the PCC 622 SHOULD ignore such updates if the SYNC flag is set. The PCC MUST 623 respond with a PCRpt message and SHOULD include the SRP-ID-number of 624 the PCUpd that triggered the resynchronization. 626 The PCE can also trigger resynchronization of the entire LSP 627 database. The PCE MUST first mark all LSPs in the LSP database that 628 were previously reported by the PCC as stale and then send a PCUpd 629 with an LSP object containing a PLSP-ID of 0 and with the SYNC flag 630 set to 1. This PCUpd message is the trigger for the PCC to enter the 631 synchronization phase as described in [I-D.ietf-pce-stateful-pce] and 632 start sending PCRpt messages. After the receipt of the end-of- 633 synchronization marker, the PCE will purge LSPs which were not 634 refreshed. The SRP-ID-number of the PCUpd that triggered the 635 resynchronization SHOULD be included in each of the PCRpt messages. 637 If the TRIGGERED-SYNC capability is not advertised and the PCC 638 receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr 639 with the SRP-ID-number of the PCUpd, error-type 20 and error-value 640 4.(see Section 8.1) 642 7. Advertising Support of Synchronization Optimizations 644 Support for each of the optimizations described in this document 645 requires advertising the corresponding capabilities during session 646 establishment time. 648 New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 649 [I-D.ietf-pce-stateful-pce]. Its format is shown in the following 650 figure: 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length=4 | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Flags |D|T|I|S|U| 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 8: STATEFUL-PCE-CAPABILITY TLV Format 662 The value comprises a single field - Flags (32 bits): 664 U (LSP-UPDATE-CAPABILITY - 1 bit): defined in 665 [I-D.ietf-pce-stateful-pce]. 667 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 668 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 670 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): defined in [I-D.ietf-pce-p 671 ce-initiated-lsp]. 673 T (TRIGGERED-SYNC - 1 bit): if set to 1 by both PCEP Speakers, the 674 PCE can trigger (re)-synchronization of LSPs at any point in the 675 life of the session. 677 D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP 678 speaker, it indicates that the PCEP speaker allows incremental 679 state synchronization. 681 8. IANA Considerations 683 This document requests IANA actions to allocate code points for the 684 protocol elements defined in this document. 686 8.1. PCEP-Error Object 688 IANA is requested to make the following allocation in the "PCEP-ERROR 689 Object Error Types and Values" registry. 691 Error-Type Meaning Reference 692 6 Mandatory Object missing [RFC5440] 693 Error-value= TBD(suggested This document 694 value 12): LSP-DB-VERSION TLV 695 missing 696 20 LSP State synchronization [I-D.ietf-pce-stateful-pce] 697 error 698 Error-value= TBD(suggested This document 699 value 2): LSP Database version 700 mismatch. 701 Error-value=TBD(suggested This document 702 value 3): The LSP-DB-VERSION 703 TLV Missing when state 704 synchronization avoidance is 705 enabled. 706 Error-value=TBD(suggested This document 707 value 4): Attempt to trigger a 708 synchronization when the 709 TRIGGERED-SYNC capability has 710 not been advertised. 711 Error-value=TBD(suggested This document 712 value 6): No sufficient LSP 713 change information for 714 incremental LSP state 715 synchronization. 716 Error-value=TBD(suggested This document 717 value 7): Received an invalid 718 LSP DB Version Number 720 8.2. PCEP TLV Type Indicators 722 This document defines the following new PCEP TLVs: 724 Value Meaning Reference 725 TBD(suggested value LSP-DB-VERSION This document 726 23) 727 TBD(suggested value SPEAKER-ENTITY-ID This document 728 24) 730 8.3. STATEFUL-PCE-CAPABILITY TLV 732 The following values are defined in this document for the Flags field 733 in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object: 735 Bit Description Reference 737 TBD(suggested value DELTA-LSP-SYNC-CAPABILITY This document 738 28) 739 TBD(suggested value TRIGGERED-SYNC This document 740 29) 741 TBD(suggested value INCLUDE-DB-VERSION This document 742 30) 744 9. Security Considerations 746 The security considerations listed in [I-D.ietf-pce-stateful-pce] 747 apply to this document as well. 749 10. Acknowledgements 751 We would like to thank Young Lee and Jonathan Hardwick for their 752 comments and discussions. 754 11. Contributors 756 Gang Xie 757 Huawei Technologies 758 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 759 Shenzhen, Guangdong, 518129 760 P.R. China 761 Email: xiegang09@huawei.com 763 12. References 765 12.1. Normative References 767 [I-D.ietf-pce-stateful-pce] 768 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 769 Extensions for Stateful PCE", draft-ietf-pce-stateful- 770 pce-09 (work in progress), June 2014. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 776 (PCE) Communication Protocol (PCEP)", RFC 5440, March 777 2009. 779 12.2. Informative References 781 [I-D.ietf-pce-pce-initiated-lsp] 782 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 783 Extensions for PCE-initiated LSP Setup in a Stateful PCE 784 Model", draft-ietf-pce-pce-initiated-lsp-01 (work in 785 progress), June 2014. 787 Authors' Addresses 789 Edward Crabbe 790 Google, Inc. 791 1600 Amphitheatre Parkway 792 Mountain View, CA 94043 793 US 795 Email: edc@google.com 797 Ina Minei 798 Google, Inc. 799 1600 Amphitheatre Parkway 800 Mountain View, CA 94043 801 US 803 Email: inaminei@google.com 805 Jan Medved 806 Cisco Systems, Inc. 807 170 West Tasman Dr. 808 San Jose, CA 95134 809 US 811 Email: jmedved@cisco.com 813 Robert Varga 814 Pantheon Technologies SRO 815 Mlynske Nivy 56 816 Bratislava 821 05 817 Slovakia 819 Email: robert.varga@pantheon.sk 820 Xian Zhang 821 Huawei Technologies 822 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 823 Shenzhen, Guangdong 518129 824 P.R.China 826 Email: zhang.xian@huawei.com 828 Dhruv Dhody 829 Huawei Technologies 830 Leela Palace 831 Bangalore, Karnataka 560008 832 INDIA 834 Email: dhruv.ietf@gmail.com