idnits 2.17.1 draft-kondreddy-pce-pcep-ls-sync-optimizations-00.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 (October 9, 2015) is 3093 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 600, but not defined == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-00 ** Downref: Normative reference to an Experimental draft: draft-dhodylee-pce-pcep-ls (ref. 'I-D.dhodylee-pce-pcep-ls') == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group V. Kondreddy 3 Internet-Draft M. Negi 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 11, 2016 October 9, 2015 7 Optimizations of PCEP Link-State(LS) Synchronization Procedures 8 draft-kondreddy-pce-pcep-ls-sync-optimizations-00 10 Abstract 12 For a Path Computation Element (PCE) to perform its computations, it 13 is important that Link-State (and TE) information be complete and 14 accurate each time. This requires a reliable Link-State 15 Synchronization mechanism between the PCE and path computation 16 clients (PCCs), and between cooperating PCEs. The basic mechanism 17 for Link-State Synchronization is part of the PCEP Link-State (and 18 TE) draft. This draft presents motivations for optimizations to the 19 base PCEP Link-State (and TE) procedure and specifies the required 20 Path Computation Element Communication Protocol (PCEP) extensions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 11, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. LS Synchronization Avoidance . . . . . . . . . . . . . . . . 4 60 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. LS Synchronization Avoidance Procedure . . . . . . . . . 4 62 4. Incremental LS Synchronization . . . . . . . . . . . . . . . 8 63 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Incremental Synchronization Procedure . . . . . . . . . . 9 65 5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 11 66 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.2. PCE-triggered Initial LS Synchronization Procedure . . . 11 68 6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . 12 69 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.2. PCE-triggered LS Re-synchronization Procedure . . . . . . 12 71 7. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Link-State(LS) Report Message . . . . . . . . . . . . . . 13 73 7.2. Capability Advertisement . . . . . . . . . . . . . . . . 14 74 7.3. Advertising Support of Synchronization Optimizations . . 14 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 77 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 16 78 8.3. LS-CAPABILITY Flags . . . . . . . . . . . . . . . . . . . 16 79 9. Manageability Considerations . . . . . . . . . . . . . . . . 17 80 9.1. Control of Function and Policy . . . . . . . . . . . . . 17 81 9.2. Information and Data Models . . . . . . . . . . . . . . . 17 82 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 83 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17 84 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 85 9.6. Impact On Network Operations . . . . . . . . . . . . . . 18 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 11. Ackwonoledgement . . . . . . . . . . . . . . . . . . . . . . 18 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 12.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 The Path Computation Element Communication Protocol (PCEP) provides 97 mechanisms for Path Computation Elements (PCEs) to perform path 98 computations in response to Path Computation Clients (PCCs) requests. 100 [I-D.dhodylee-pce-pcep-ls] describes a set of extensions to PCEP to 101 provide Link-State (and TE) distribution. This draft presents 102 motivations for optimizations to the base PCEP Link-State transport 103 procedure and specifies the required Path Computation Element 104 Communication Protocol (PCEP) extensions. This draft specifies 105 following optimizations for Link-State Synchronization and the 106 corresponding PCEP procedures and extensions: 108 o Link-State Synchronization Avoidance: To skip Link-State (and TE) 109 synchronization if the state has survived and not changed during 110 session restart.(See Section 3) 112 o Incremental Link-State Synchronization: To do incremental (delta) 113 Link-State (and TE) Synchronization when possible.(See Section 4) 115 o PCE-triggered Initial Synchronization: To let PCE control the 116 timing of the initial Link-State (and TE) Synchronization.(See 117 Section 5) 119 o PCE-triggered Re-synchronization: To let PCE re-synchronize the 120 Link-State (and TE) information for sanity check.(See Section 6) 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Terminology 130 This document uses the following terms defined in [RFC5440]: PCC, 131 PCE, PCEP Peer. 133 This document uses the following terms defined in 134 [I-D.dhodylee-pce-pcep-ls]: LSRpt, Link-State (and TE), LS 136 Link-State (and TE): "LS" is interchangably used for the keyword 137 "Link-State (and TE)". 139 Within this document, when describing PCE-PCE communications, the 140 requesting PCE fills the role of a PCC. This provides a saving in 141 documentation without loss of function. 143 The following terms are defined in this document: 145 LS-DB: Link-State (and TE) Database. 147 LS Sync: LS Synchronization, an operation to send LS information 148 synchronization request to PCC by LSRpt message with LS-ID 0. 150 LS-Info: One LS information (i.e. LS Node/Link/Prefix defined in I- 151 D.dhodylee-pce-pcep-ls). 153 3. LS Synchronization Avoidance 155 3.1. Motivation 157 The purpose of LS Synchronization is to provide a checkpoint-in-time 158 state replica of a PCC's Link-State (and TE) information in a PCE. 159 LS Synchronization is performed immediately after the initialization 160 phase ([RFC5440]). [I-D.dhodylee-pce-pcep-ls] describes the basic 161 mechanism for LS synchronization. 163 LS Synchronization is not always necessary following a PCEP session 164 restart. If the Link-State (and TE) information of both PCEP peers 165 did not change, the synchronization phase may be skipped. This can 166 result in significant savings in both control-plane data exchanges 167 and the time it takes for the PCE to become fully operational. 169 3.2. LS Synchronization Avoidance Procedure 171 LS Synchronization MAY be skipped following a PCEP session restart if 172 the Link-State (and TE) information of both PCEP peers did not change 173 during the period prior to session re-initialization. To be able to 174 make this determination, LS-DB must be exchanged and maintained by 175 both PCE and PCC during normal operation. This is accomplished by 176 keeping track of the changes to the Link-State (and TE) Database (LS- 177 DB), using a version tracking field called the LS-DB Version Number. 179 The LS-DB Version Number, carried in LS-DB-VERSION TLV (see 180 Section 7.2), is owned by a PCC and it MUST be incremented by 1 for 181 each successive change in the PCC's LS-DB. The LS-DB Version Number 182 MUST start at 1 and may wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF 183 are reserved. If either of the two values are used during LS re- 184 synchronization, the PCE speaker receiving this node should send back 185 a PCErr with Error-type TBD1 Error-value 1 'Received an invalid LS-DB 186 Version Number', and close the PCEP session. Operations that trigger 187 a change to the local LS-DB include but not limited to - 189 - a change in the link status or attributes(i.e. bandwidth, metric 190 etc), addition or deletion of link. 192 - a change in the node attributes, addition or deletion of node. 194 - a change in the prefix attributes, addition or deletion of prefix. 196 LS Synchronization avoidance is advertised on a PCEP session during 197 session startup using the LS-INCLUDE-DB-VERSION (S) bit in the LS- 198 CAPABILITY TLV (see Section 7.3). The peer may move in the network, 199 either physically or logically, which may cause its connectivity 200 details and transport-level identity (such as IP address) to change. 201 To ensure that a PCEP peer can recognize a previously connected peer 202 even in case of such mobility, each PCEP peer includes the SPEAKER- 203 ENTITY-ID TLV in the OPEN message. SPEAKER-ENTITY-ID TLV is 204 described in [I-D.ietf-pce-stateful-sync-optimizations] 206 If both PCEP speakers set the S flag in the OPEN object's LS- 207 CAPABILITY TLV to 1, the PCC MUST include the LS-DB-VERSION TLV in 208 each LS object of the LSRpt message. If the LS-DB-VERSION TLV is 209 missing in a LSRpt message, the PCE will generate an error with 210 Error-Type 6 (mandatory object missing) and Error-Value TBD2 'LS-DB- 211 VERSION TLV missing' and close the session. If LS Synchronization 212 avoidance has not been enabled on a PCEP session, the PCC SHOULD NOT 213 include the LS-DB-VERSION TLV in the LS object and the PCE SHOULD 214 ignore it, if it were to receive one. 216 If a PCE's LS-DB survived the restart of a PCEP session, the PCE will 217 include the LS-DB-VERSION TLV in its OPEN object, and the TLV will 218 contain the last LS-DB Version Number received on an LS Report from 219 the PCC in the previous PCEP session. If a PCC's LS-DB survived the 220 restart of a PCEP session, the PCC will include the LS-DB-VERSION TLV 221 in its OPEN object and the TLV will contain the latest LS-DB Version 222 Number. If a PCEP speaker's LS-DB did not survive the restart of a 223 PCEP session, the PCEP speaker MUST NOT include the LS-DB-VERSION TLV 224 in the OPEN object. 226 If both PCEP speakers include the LS-DB-VERSION TLV in the OPEN 227 Object and the TLV values match, the PCC MAY skip LS Synchronization. 228 Otherwise, the PCC MUST perform complete LS Synchronization. If the 229 PCC attempts to skip LS Synchronization (i.e., the SYNC Flag = 0 on 230 the first LS Report from the PCC, the PCE MUST send back a PCErr with 231 Error-Type TBD1 Error-Value 2 'LS-DB version mismatch', and close the 232 PCEP session. 234 If LS Synchronization is required, then prior to completing the 235 initialization phase, the PCE MUST mark any LS-Infos in the LS-DB 236 that were previously reported by the PCC as stale. When the PCC 237 reports a LS-Info during LS Synchronization, if the LS-Info already 238 exists in the LS-DB, the PCE MUST update the LS-DB and clear the 239 stale marker from the LS-Info. When it has finished LS 240 Synchronization, the PCC MUST immediately send an end of LS 241 Synchronization marker. The end of synchronization marker is a LS 242 Report (LSRpt) message with an LS object containing a LS-ID of 0 and 243 with the SYNC flag set to 0. The LS-DB-VERSION TLV MUST be included 244 in this LSRpt message. On receiving this LS Report, the PCE MUST 245 purge any LS-Infos from the LS-DB that are still marked as stale. It 246 should be noted that PCE may receive the same Link-state and TE 247 information from multiple PCCs and the purging should take that into 248 account. 250 Note that a PCE/PCC MAY force LS Synchronization by not including the 251 LS-DB-VERSION TLV in its OPEN object. 253 Since a PCE does not make changes to the LS-DB Version Number, a PCC 254 should never encounter this TLV in a message from the PCE (other than 255 the OPEN message). A PCC SHOULD ignore the LS-DB-VERSION TLV, were 256 it to receive one from a PCE. 258 Figure 1 shows an example sequence where the LS synchronization is 259 skipped. 261 +-+-+ +-+-+ 262 |PCC| |PCE| 263 +-+-+ +-+-+ 264 | | 265 |---Open--, | 266 |LS-DBv=82 \ ,---Open-----| 267 | S=1 \ /LS-DBv=82 | 268 | \/ S=1 | 269 | /\ | 270 | / `----------->| (OK to skip 271 (Skip |<---------` | LS sync) 272 LS sync)| . | 273 | . | 274 | . | 275 | | 276 |---LSRpt,LS-DBv=83,SYNC=0-->| (Regular 277 | | LS Report) 278 |---LSRpt,LS-DBv=84,SYNC=0-->| (Regular 279 | | LS Report) 280 |---LSRpt,LS-DBv=85,SYNC=0-->| 281 | | 283 Figure 1: LS Synchronization Skipped 285 Figure 2 shows an example sequence where the LS Synchronization is 286 performed due to LS-DB Version mismatch during the PCEP session 287 setup. Note that the same LS Synchronization sequence would happen 288 if either the PCC or the PCE would not include the LS-DB-VERSION TLV 289 in their respective Open messages. 291 +-+-+ +-+-+ 292 |PCC| |PCE| 293 +-+-+ +-+-+ 294 | | 295 |---Open--, | 296 |LS-DBv=86 \ ,---Open-----| 297 | S=1 \ /LS-DBv=82 | 298 | \/ S=1 | 299 | /\ | 300 | / `----------->| (Expect sync) 301 (Do |<---------` | 302 sync) | | 303 | | 304 |---LSRpt,LS-DBv=86,SYNC=1-->| (Sync start) 305 | . | 306 | . | 307 | . | 308 |---LSRpt,LS-DBv=86,SYNC=0-->| (Sync done) 309 | . |(Purge LS-Info 310 | . | if applicable) 311 | . | 312 |---LSRpt,LS-DBv=87,SYNC=0-->| (Regular 313 | | LS Report) 314 |---LSRpt,LS-DBv=88,SYNC=0-->| (Regular 315 | | LS Report) 316 |---LSRpt,LS-DBv=89,SYNC=0-->| 317 | | 319 Figure 2: LS Synchronization Performed 321 Figure 3 shows an example sequence where the LS Synchronization is 322 skipped, but because one or both PCEP speakers set the S Flag to 0, 323 the PCC does not send LS-DB-VERSION TLVs in subsequent LSRpt messages 324 to the PCE. If the current PCEP session restarts, the PCEP speakers 325 will have to perform LS Synchronization, since the PCE does not know 326 the PCC's latest LS-DB Version Number information. 328 +-+-+ +-+-+ 329 |PCC| |PCE| 330 +-+-+ +-+-+ 331 | | 332 |---Open--, | 333 |LS-DBv=82 \ ,---Open-----| 334 | S=0 \ /LS-DBv=82 | 335 | \/ S=0 | 336 | /\ | 337 | / `----------->| (OK to skip 338 (Skip |<---------` | LS sync) 339 LS sync)| . | 340 | . | 341 | . | 342 | | 343 |--------LSRpt,SYNC=0------->| (Regular 344 | | LS Report) 345 |--------LSRpt,SYNC=0------->| (Regular 346 | | LS Report) 347 |--------LSRpt,SYNC=0------->| 348 | | 350 Figure 3: LS Synchronization Skipped, no LS-DB-VERSION TLVs sent from 351 PCC 353 4. Incremental LS Synchronization 355 [I-D.dhodylee-pce-pcep-ls] describes the LS synchronization mechanism 356 during session initialization between PCCs and PCEs. During the LS 357 synchronization, a PCC sends the information of its LS-DB to the PCE 358 based on the local policy. In order to reduce the LS Synchronization 359 overhead when there is a small number of LS-DB change in the network 360 between PCEP session restart, this section defines a mechanism for 361 incremental (Delta) LS synchronization. 363 4.1. Motivation 365 According to [I-D.dhodylee-pce-pcep-ls], if a PCEP session restarts, 366 PCCs send snapshot of LS-DB information to the PCE, though LS-DB did 367 not change. And as per Section 3 (LS Synchronization Avoidance 368 Procedure), if there is a change in a small number of LS-Infos. PCC 369 yet sends complete snapshot of LS-DB information to the PCE, which 370 takes a long time and consume large communication channel bandwidth. 372 4.2. Incremental Synchronization Procedure 374 Section 3 describes LS Synchronization avoidance by using LS-DB- 375 VERSION TLV in its OPEN object. This section extends this idea to 376 only synchronize the delta (changes) in case of version mismatch. 378 If both PCEP speakers include the LS-DB-VERSION TLV in the OPEN 379 object and the LS-DB-VERSION TLV values match, the PCC MAY skip LS 380 Synchronization. Otherwise, the PCC MUST perform LS Synchronization. 381 Incremental LS Synchronization capability is advertised on a PCEP 382 session during session startup using the LS-DELTA-SYNC-CAPABILITY (D) 383 bit in the capabilities TLV (see Section 7.3). Instead of dumping 384 full LS-DB to the PCE again, PCC synchronizes the delta (changes) as 385 described in Figure 4 when D flag and S flag is set to 1 by both PCC 386 and PCE. Other combinations of D and S flags setting by PCC and PCE 387 result in complete LS Synchronization procedure as described in 388 [I-D.dhodylee-pce-pcep-ls]. If a PCC has to force complete LS 389 Synchronization due to reasons including but not limited: (1) local 390 policy configured at the PCC; (2) no sufficient LS-DB caches for 391 incremental update, the PCC can set the D flag to 0. Note a PCC may 392 have to bring down the current session and force a complete LS 393 Synchronization with D flag set to 0 in the subsequent open message. 395 +-+-+ +-+-+ 396 |PCC| |PCE| 397 +-+-+ +-+-+ 398 | | 399 |---Open--, | 400 |LS-DBv=86 \ ,---Open-----| 401 | S=1 \ /LS-DBv=82 | 402 | D=1 \/ S=1 | 403 | /\ D=1 | 404 | / `----------->| (Expect Delta sync) 405 (Do |<---------` | (Donot purge 406 Delta | | LS-Infos) 407 sync) | | 408 |---LSRpt,LS-DBv=86,SYNC=1-->| (Delta Sync start) 409 | . | 410 | . | 411 | . | 412 |---LSRpt,LS-DBv=86,SYNC=0-->| (Sync done) 413 | | LS-ID=0) 414 | | 415 |---LSRpt,LS-DBv=87,SYNC=0-->| (Regular 416 | | LS Report) 417 |---LSRpt,LS-DBv=88,SYNC=0-->| (Regular 418 | | LS Report) 419 |---LSRpt,LS-DBv=89,SYNC=0-->| 420 | | 422 Figure 4: Incremental Synchronization Procedure 424 As per Section 3, the LS-DB Version Number is incremented each time a 425 change is made to the PCC's local LS-DB. Each LS-Info is associated 426 with the DB version at the time of change. This is needed to 427 determine which LS-Info needs to be synchronized in incremental LS 428 Synchronization. 430 PCC MAY store a then history of LS-DB change that happened between 431 the PCEP session(s) restart in order to carry out incremental LS 432 Synchronization. After the synchronization procedure finishes, the 433 PCC can dump this history information. In the example shown in 434 Figure 4, the PCC needs to store the LS-DB changes that happened 435 between DB Version 83 to 86 and synchronizes these changes only when 436 performing incremental LS-DB update. So a PCC needs to remember the 437 LS-DB changes that happened when an existing PCEP session to a PCE 438 goes down in the hope of doing incremental synchronization when the 439 session is re-established. 441 If a PCC finds out it does not have sufficient information to 442 complete incremental synchronization after advertising incremental LS 443 Synchronization capability, it MUST send a PCErr with Error-Type TBD1 444 and Error-Value 3 'A PCC indicates to a PCE that it can not complete 445 the LS synchronization' and terminate the session. 447 5. PCE-triggered Initial Synchronization 449 5.1. Motivation 451 In networks such as optical transport networks, the control channel 452 between network nodes can be realized through in-band overhead thus 453 has limited bandwidth. With a PCE connected to the network via one 454 network node, it is desirable to control the timing of PCC LS 455 Synchronization so as not to overload the low communication channel 456 available in the network during the initial synchronization (be it 457 incremental or full) when the session restarts, when there is 458 comparatively large amount of control information needing to be 459 synchronized between the PCE and the network. The method proposed, 460 i.e., allowing PCE to trigger the LS synchronization, is similar to 461 the function proposed in Section 6 but is used in different scenarios 462 and for different purposes. 464 5.2. PCE-triggered Initial LS Synchronization Procedure 466 Support of PCE-triggered LS Synchronization is advertised during 467 session startup using the LS-TRIGGERED-INITIAL-SYNC (F) bit in the 468 LS-CAPABILITY TLV (see Section 7.3). 470 As per [I-D.dhodylee-pce-pcep-ls], LSRpt is sent from PCC to PCE, 471 this document extends the usage of LSRpt to trigger syncronization. 472 Where a PCC can send a LSRpt (for LS Sync) with an LS object 473 containing a LS-ID of 0 and with the SYNC flag set to 1. This LSRpt 474 message is the trigger for the PCC to enter the synchronization phase 475 and start sending LSRpt messages. 477 If the LS-TRIGGERED-INITIAL-SYNC capability is not advertised and the 478 PCC receives a LSRpt with the SYNC flag set to 1, it MUST send a 479 PCErr for LSRpt(LS Sync from PCE) with Error-Type TBD1 and Error- 480 Value 4 'Attempt to trigger synchronization when the PCE triggered 481 synchronization capability has not been advertised'. 483 A PCE MAY choose to control the LS Synchronization process. To allow 484 PCE to do so, PCEP speakers MUST set T bit to 1 to indicate this (as 485 described in Section 7.3). If the LS-DB version is mis-matched, it 486 can send a LSRpt message with LS-ID = 0 and SYNC = 1 in order to 487 trigger the LS Synchronization process. In this way, the PCE can 488 control the sequence of LS Synchronization among all the PCCs that 489 are re-establishing PCEP sessions with it. When the capability of 490 PCE control is enabled, only after a PCC receives this message, it 491 will start sending information to the PCE. The PCC SHOULD NOT send 492 LSRpt messages to the PCE before it triggers the LS Synchronization. 493 This PCE-triggering capability can be applied to both full and 494 incremental LS Synchronization. If applied to the later, the PCCs 495 only send information that PCE does not possess, which is inferred 496 from the LS-DB version information exchanged in the OPEN message (see 497 Section 3.2) for detailed procedure). 499 6. PCE-triggered Re-synchronization 501 6.1. Motivation 503 The accuracy of the computations performed by the PCE is tied to the 504 accuracy of the view the PCE has on the LS-DB. Therefore, it can be 505 beneficial to be able to re-synchronize LS-DB even after the session 506 has been established. The PCE may use this approach to continuously 507 sanity check its LS-DB against the network, or to recover from error 508 conditions without having to tear down sessions. 510 6.2. PCE-triggered LS Re-synchronization Procedure 512 Support of PCE-triggered LS Synchronization is advertised during 513 session startup using the LS-TRIGGERED-RESYNC (T) bit in the LS- 514 CAPABILITY TLV (see Section 7.3). 516 The PCE triggers re-synchronization of the entire LS-DB. The PCE 517 MUST first mark all LS-Infos in the LS-DB that were previously 518 reported by the PCC as stale and then send a LSRpt (for LS Sync) with 519 an LS object containing a LS-ID of 0 and with the SYNC flag set to 1. 520 This LSRpt message is the trigger for the PCC to enter the 521 synchronization phase and start sending LSRpt messages. After the 522 receipt of the end-of-synchronization marker, the PCE will purge LS- 523 Infos which were not refreshed. 525 If the LS-TRIGGERED-RESYNC capability is not advertised and the PCC 526 receives a LSRpt with the SYNC flag set to 1, it MUST send a PCErr 527 with Error-Type TBD1 and Error-Value 4 'Attempt to trigger 528 synchronization when the TRIGGERED-SYNC capability has not been 529 advertised'. 531 Once the state re-synchronization is triggered by the PCE, the 532 procedures and error checks remain unchanged from the full state 533 synchronization ([I-D.dhodylee-pce-pcep-ls]). This would also 534 include PCE triggering multiple state re-synchronization requests 535 while synchronization is in progress. 537 +-+-+ +-+-+ 538 |PCC| |PCE| 539 +-+-+ +-+-+ 540 | | 541 |<----LSRpt, SYNC=1 -----| Trigger 542 | (LSID=0) | re-sync 543 | | 544 |-----LSRpt, SYNC=1----->| (Sync start) 545 | . | 546 | . | 547 | . | 548 |-----LSRpt, SYNC=1----->| 549 | . | 550 | . | 551 | . | 552 | | 553 |-----LSRpt, SYNC=0----->| (End of sync marker 554 | | LS Report 555 | | for LS-ID=0) 556 | | (LS Sync done) 558 Figure 5: PCE Triggered Complete LS re-synchronization 560 7. PCEP Extensions 562 7.1. Link-State(LS) Report Message 564 A PCEP LS Report message (also referred to as LSRpt message) is a 565 PCEP message sent by a PCC to a PCE to report the LS information. 566 The definition of the LSRpt message from [I-D.dhodylee-pce-pcep-ls] 567 is extended to use LSRpt message with LS-ID = 0 to request LS 568 Synchronization from PCE to PCC. 570 If a PCC that does not support extention defined in this document 571 receives a LSRpt message, it will act according to existing behavior 572 of receiving invalid message. If a PCC supports the extention, but 573 did not set the flag T or F, and receives the LSRpt message, it sends 574 PCErr message as described earlier in section [x] and [y]. If a PCC 575 supports the extention and set the flag T or F, and receives the 576 LSRpt message without LS-ID as 0 and SYNC flag set, PCC will send an 577 error message with Error-Type TBD1 Error-Value 6 'Invalid LSRpt 578 message'. 580 7.2. Capability Advertisement 582 The LS-DB Version Number is an carried in optional LS-DB-VERSION TLV 583 that MAY be included in the OPEN object and the LS object. This TLV 584 MUST NOT be included if LS-INCLUDE-DB-VERSION bit in LS-CAPABILITY 585 TLV is not set. 587 The format of the LS-DB-VERSION TLV is shown in the following figure: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type=[TBD] | Length=8 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | LS-DB Version Number | 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Figure 6: LS-DB-VERSION TLV format 600 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 601 The value contains a 64-bit unsigned integer, representing the LS-DB 602 Version Number. 604 7.3. Advertising Support of Synchronization Optimizations 606 Support for each of the optimizations described in this document 607 requires advertising the corresponding capabilities during session 608 establishment. 610 New flags are defined for the LS-CAPABILITY TLV defined in 611 [I-D.dhodylee-pce-pcep-ls]. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length=4 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Flags |F|D|T|S|R| 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 7: LS-CAPABILITY TLV Format 623 The value comprises a single field - Flags (32 bits): 625 R (LS-REMOTE-BIT - 1 bit): Defined in [I-D.dhodylee-pce-pcep-ls] 627 S (LS-INCLUDE-DB-VERSION - 1 bit): If set to 1 by both PCEP speakers, 628 the PCC will include the LS-DB-VERSION TLV in each LS object. See 629 Section 3 for details. 631 T (LS-TRIGGERED-RESYNC - 1 bit): If set to 1 by both PCEP speakers, 632 the PCE can trigger re-synchronization of LS-Infos at any point in 633 the life of the session. See Section 6 for details. 635 D (LS-DELTA-SYNC-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, 636 it indicates that the PCEP speaker allows incremental (delta) state 637 synchronization. See Section 4 for details. 639 F (LS-TRIGGERED-INITIAL-SYNC - 1 bit): If set to 1 by both PCEP 640 speakers, the PCE SHOULD trigger initial (first) LS synchronization. 641 See Section 5 for details. 643 8. IANA Considerations 645 This document requests IANA actions to allocate code points for the 646 protocol elements defined in this document. 648 8.1. PCEP-Error Object 650 IANA is requested to make the following allocation in the "PCEP-ERROR 651 Object Error Types and Values" registry. 653 Error-Type Meaning Reference 654 6 Mandatory Object missing [RFC5440] 655 Error-Value= TBD2 This document 656 LS-DB-VERSION TLV missing 657 TBD1 LS synchronization This document 658 error 659 Error-Value= TBD(suggested This document 660 value 1):Received an invalid 661 LSDB Version Number 662 Error-Value= TBD(suggested This document 663 value 2): LS-DB 664 version mismatch. 665 Error-Value=TBD(suggested This document 666 value 3): PCC indicates to a 667 PCE that it cannot complete 668 the LS Synchronization 669 Error-Value=TBD(suggested This document 670 value 4): Attempt to trigger a 671 synchronization when the 672 PCE triggered synchronization 673 capability has not been 674 advertised. 675 Error-Value=TBD(suggested This document 676 value 5): LS-DB-VERSION 677 TLV Missing when LS 678 synchronization avoidance is 679 enabled. 680 Error-Value=TBD(suggested This document 681 value 6): Invalid LSRpt 682 message. 684 8.2. PCEP TLV Type Indicators 686 This document defines the following new PCEP TLVs: 688 Value Meaning Reference 689 TBD LS-DB-VERSION This document 691 8.3. LS-CAPABILITY Flags 693 The following values are defined in this document for the Flags field 694 in the LS-CAPABILITY TLV in the OPEN object: 696 Bit Description Reference 697 TBD 698 (Suggested value 30) LS-INCLUDE-DB-VERSION This document 699 (Suggested value 29) LS-TRIGGERED-RESYNC This document 700 (Suggested value 28) LS-DELTA-SYNC-CAPABILITY This document 701 (Suggested value 27) LS-TRIGGERED-INITIAL-SYNC This document 703 9. Manageability Considerations 705 All manageability requirements and considerations listed in [RFC5440] 706 and [I-D.dhodylee-pce-pcep-ls] apply to PCEP protocol extensions 707 defined in this document. In addition, requirements and 708 considerations listed in this section apply. 710 9.1. Control of Function and Policy 712 A PCE or PCC implementation MUST allow configuring the state 713 synchronization optimization capabilities as described in this 714 document. 716 9.2. Information and Data Models 718 PCEP session configuration and information in the PCEP MIB module 719 SHOULD be extended to include advertised LS Capabilities, LS-DB 720 Version Number and LS synchronization status, Message statistics. 722 9.3. Liveness Detection and Monitoring 724 Mechanisms defined in this document do not imply any new liveness 725 detection and monitoring requirements in addition to those already 726 listed in [RFC5440]. 728 9.4. Verify Correct Operations 730 Mechanisms defined in section 8.4 of [RFC5440] also apply to PCEP 731 protocol extensions defined in this document. In addition to 732 monitoring parameters defined in [RFC5440], a PCEP implementation 733 with LS-DB SHOULD provide the following parameters: 735 o Total number of LSRpt(Synchronization request) requests 737 o LS-DB Version Number and synchronization status 739 9.5. Requirements On Other Protocols 741 Mechanisms defined in this document do not imply any new requirements 742 on other protocols. 744 9.6. Impact On Network Operations 746 Mechanisms defined in section 8.6 of [RFC5440] also apply to PCEP 747 protocol extensions defined in this document. 749 Additionally, a PCEP implementation SHOULD allow a limit to be placed 750 on the amount and rate of LSRpt messages sent by a PCEP speaker and 751 processed by the peer. It SHOULD also allow sending a notification 752 when a rate threshold is reached. 754 10. Security Considerations 756 The security considerations listed in [I-D.dhodylee-pce-pcep-ls] 757 apply to this document as well. However, because the protocol 758 modifications outlined in this document allow the PCE to control LS 759 Re-synchronization timing and sequence, it also introduces a new 760 attack vector: an attacker may flood the PCC with triggered re- 761 synchronization request at a rate which exceeds the PCC's ability to 762 process them, either by spoofing messages or by compromising the PCE 763 itself. The PCC is free to drop any trigger re-synchronization 764 request without additional processing. 766 11. Ackwonoledgement 768 The document borrows some of the text and structure from 769 [I-D.ietf-pce-stateful-sync-optimizations]. 771 12. References 773 12.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 781 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 782 DOI 10.17487/RFC5440, March 2009, 783 . 785 [I-D.dhodylee-pce-pcep-ls] 786 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 787 Distribution of Link-State and TE Information.", draft- 788 dhodylee-pce-pcep-ls-00 (work in progress), September 789 2015. 791 12.2. Informative References 793 [I-D.ietf-pce-stateful-sync-optimizations] 794 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 795 and D. Dhody, "Optimizations of Label Switched Path State 796 Synchronization Procedures for a Stateful PCE", draft- 797 ietf-pce-stateful-sync-optimizations-03 (work in 798 progress), October 2015. 800 Appendix A. Contributor Addresses 802 Dhruv Dhody 803 Huawei Technologies 804 Divyashree Techno Park, Whitefield 805 Bangalore, Karnataka 560037 806 India 808 EMail: dhruv.ietf@gmail.com 810 Authors' Addresses 812 Venugopal Reddy Kondreddy 813 Huawei Technologies 814 Divyashree Techno Park, Whitefield 815 Bangalore, Karnataka 560037 816 India 818 EMail: venugopalreddyk@huawei.com 820 Mahendra Singh Negi 821 Huawei Technologies 822 Divyashree Techno Park, Whitefield 823 Bangalore, Karnataka 560037 824 India 826 EMail: mahendrasingh@huawei.com