Internet Engineering Task Force (IETF) E. Crabbe Request for Comments: 8232 Oracle Category: Standards Track I. Minei ISSN: 2070-1721 Google, Inc. J. Medved Cisco Systems, Inc. R. Varga Pantheon Technologies SRO X. Zhang D. Dhody Huawei Technologies September 2017 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE
AbstractA stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8232.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................4 1.1. Requirements Language ......................................4 2. Terminology .....................................................5 3. State Synchronization Avoidance .................................5 3.1. Motivation .................................................5 3.2. State Synchronization Avoidance Procedure ..................5 3.2.1. IP Address Change during Session Re-establishment ..10 3.3. PCEP Extensions ...........................................11 3.3.1. LSP-DB Version Number TLV ..........................11 3.3.2. Speaker Entity Identifier TLV ......................12 4. Incremental State Synchronization ..............................13 4.1. Motivation ................................................13 4.2. Incremental Synchronization Procedure .....................14 5. PCE-Triggered Initial Synchronization ..........................17 5.1. Motivation ................................................17 5.2. PCE-Triggered Initial State Synchronization Procedure .....18 6. PCE-Triggered Resynchronization ................................19 6.1. Motivation ................................................19 6.2. PCE-Triggered State Resynchronization Procedure ...........19 7. Advertising Support of Synchronization Optimizations ...........20 8. IANA Considerations ............................................21 8.1. PCEP-Error Object .........................................21 8.2. PCEP TLV Type Indicators ..................................22 8.3. STATEFUL-PCE-CAPABILITY TLV ...............................22 9. Manageability Considerations ...................................22 9.1. Control of Function and Policy ............................22 9.2. Information and Data Models ...............................22 9.3. Liveness Detection and Monitoring .........................23 9.4. Verify Correct Operations .................................23 9.5. Requirements on Other Protocols ...........................23 9.6. Impact on Network Operations ..............................23 10. Security Considerations .......................................23 11. References ....................................................24 11.1. Normative References .....................................24 11.2. Informative References ...................................24 Acknowledgments ...................................................25 Contributors ......................................................25 Authors' Addresses ................................................26
RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and the PCC, and cooperating PCEs. [RFC8231] describes the basic mechanism for State Synchronization. This document specifies following optimizations for State Synchronization and the corresponding PCEP procedures and extensions: o State Synchronization Avoidance: To skip State Synchronization if the state has survived and not changed during session restart. (See Section 3.) o Incremental State Synchronization: To do incremental (delta) State Synchronization when possible. (See Section 4.) o PCE-Triggered Initial Synchronization: To let PCE control the timing of the initial State Synchronization. (See Section 5.) o PCE-Triggered Resynchronization: To let PCE resynchronize the state for sanity check. (See Section 6.) Support for each of the synchronization optimization capabilities is advertised during the PCEP initialization phase. See Section 7 for the new flags defined in this document. The handling of each flag is described in the relevant section. RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
RFC5440]: PCC, PCE, and PCEP Peer. This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation, and LSP State Database (LSP-DB). This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, LSP State Report, and LSP Update Request. Within this document, when describing PCE-PCE communications, the requesting PCE fills the role of a PCC as usual. RFC5440]. [RFC8231] describes the basic mechanism for State Synchronization. State Synchronization is not always necessary following a PCEP session restart. If the state of both PCEP peers did not change, the synchronization phase may be skipped. This can result in significant savings in both control-plane data exchanges and the time it takes for the stateful PCE to become fully operational. Section 7) is advertised on a PCEP session during session startup to indicate that the LSP-DB Version Number is to be included when the LSPs are reported to the PCE. The LSP-DB Version Number, carried in LSP-DB-VERSION TLV (see Section 3.3.1), is owned by a PCC, and it MUST be incremented by 1 for each successive change in the PCC's LSP- DB. The LSP-DB Version Number MUST start at 1 and may wrap around.
Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of the two values are used during LSP State (re)Synchronization, the PCE speaker receiving this value MUST send back a PCEP Error (PCErr) with Error- type=20 and Error-value=6 'Received an invalid LSP-DB Version Number', and close the PCEP session. Operations that trigger a change to the local LSP-DB include a change in the LSP operational state, delegation of an LSP, removal or setup of an LSP, or change in any of the LSP attributes that would trigger a report to the PCE. If the include LSP-DB version capability is enabled, a PCC MUST increment its LSP-DB Version Number when the 'Redelegation Timeout Interval' timer expires (see [RFC8231] for the use of the Redelegation Timeout Interval). If both PCEP speakers set the S flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB- VERSION TLV in each LSP object of the Path Computation LSP State Report (PCRpt) message. If the LSP-DB-VERSION TLV is missing in a PCRpt message, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and Error-value=12 'LSP-DB-VERSION TLV missing', and close the session. If the include LSP-DB version capability has not been enabled on a PCEP session, the PCC SHOULD NOT include the LSP-DB-VERSION TLV in the LSP Object, and the PCE MUST ignore it, were it to receive one. If a PCE's LSP-DB survived the restart of a PCEP session, the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the TLV will contain the last LSP-DB Version Number received on an LSP State Report from the PCC in the previous PCEP session. If a PCC's LSP-DB survived the restart of a PCEP session, the PCC will include the LSP- DB-VERSION TLV in its OPEN object, and the TLV will contain the latest LSP-DB Version Number. If a PCEP speaker's LSP-DB did not survive the restart of a PCEP session or at startup when the database is empty, the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN object. If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the TLV values match, the PCC MAY skip State Synchronization, and the PCE does not wait for the end-of- synchronization marker [RFC8231]. Otherwise, the PCC MUST perform full State Synchronization (see [RFC8231]) or incremental State Synchronization (see Section 4 if this capability is advertised) to the stateful PCE. In other words, if the incremental State Synchronization capability is not advertised by the peers, based on the LSP-DB Version Number match, either the State Synchronization is skipped or a full State Synchronization is performed. If the PCC attempts to skip State Synchronization, by setting the SYNC flag to 0 and PLSP-ID to a non-zero value on the first LSP State Report from
the PCC as per [RFC8231], the PCE MUST send back a PCErr with Error- type=20 and Error-value=2 'LSP-DB version mismatch', and close the PCEP session. If State Synchronization is required, then prior to completing the initialization phase, the PCE MUST mark any LSPs in the LSP-DB that were previously reported by the PCC as stale. When the PCC reports an LSP during State Synchronization, if the LSP already exists in the LSP-DB, the PCE MUST update the LSP-DB and clear the stale marker from the LSP. When it has finished State Synchronization, the PCC MUST immediately send an end-of-synchronization marker. The end-of- synchronization marker is a PCRpt message with an LSP object containing a PLSP-ID of 0 and with the SYNC flag set to 0 [RFC8231]. The LSP-DB-VERSION TLV MUST be included in this PCRpt message. On receiving this state report, the PCE MUST purge any LSPs from the LSP-DB that are still marked as stale. Note that a PCE/PCC MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object. Since a PCE does not make changes to the LSP-DB Version Number, a PCC should never encounter this TLV in a message from the PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB-VERSION TLV, were it to receive one from a PCE. Figure 1 shows an example sequence where the State Synchronization is skipped.
+-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |--Open--, | | DBv=42 \ ,---Open--| | S=1 \ / DBv=42 | | \/ S=1 | | /\ | | / `-------->| (OK to skip sync) (Skip sync) |<--------` | | . | | . | | . | | | |--PCRpt,DBv=43,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=44,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=45,SYNC=0-->| | | Figure 1: State Synchronization Skipped Figure 2 shows an example sequence where the State Synchronization is performed due to LSP-DB version mismatch during the PCEP session setup. Note that the same State Synchronization sequence would happen if either the PCC or the PCE would not include the LSP-DB- VERSION TLV in their respective Open messages.
+-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |--Open--, | | DBv=46 \ ,---Open--| | S=1 \ / DBv=42 | | \/ S=1 | | /\ | | / `-------->| (Expect sync) (Do sync) |<--------` | | | |--PCRpt,DBv=46,SYNC=1-->| (Sync start) | . | | . | | . | |--PCRpt,DBv=46,SYNC=0-->| (Sync done) | . | (Purge LSP state | . | if applicable) | . | |--PCRpt,DBv=47,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=48,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=49,SYNC=0-->| | | Figure 2: State Synchronization Performed Figure 3 shows an example sequence where the State Synchronization is skipped, but because one or both PCEP speakers set the S flag to 0, the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt messages to the PCE. If the current PCEP session restarts, the PCEP speakers will have to perform State Synchronization, since the PCE does not know the PCC's latest LSP-DB Version Number information.
+-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |--Open--, | | DBv=42 \ ,---Open--| | S=0 \ / DBv=42 | | \/ S=0 | | /\ | | / `-------->| (OK to skip sync) (Skip sync) |<--------` | | . | | . | | . | |------PCRpt,SYNC=0----->| (Regular | | LSP State Report) |------PCRpt,SYNC=0----->| (Regular | | LSP State Report) |------PCRpt,SYNC=0----->| | | Figure 3: State Synchronization Skipped; No LSP-DB-VERSION TLVs Sent from the PCC Section 3.3.2 in the OPEN message.
This TLV is used during the State Synchronization procedure to identify the PCEP session as a re-establishment of a previous session that went down. Then State Synchronization optimizations such as state sync avoidance can be applied to this session. Note that this usage is only applicable within the State Timeout Interval [RFC8231]. After the State Timeout Interval expires, all state associated with the PCEP session is removed, which includes the SPEAKER-ENTITY-ID received. Note that the PCEP session initialization [RFC5440] procedure remains unchanged. Section 7 for details). figure: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=23 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-DB Version Number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: LSP-DB-VERSION TLV Format The type of the TLV is 23, and it has a fixed length of 8 octets. The value contains a 64-bit unsigned integer, carried in network byte order, representing the LSP-DB Version Number.
figure: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=24 | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Speaker Entity Identifier // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: SPEAKER-ENTITY-ID TLV Format The type of the TLV is 24, and it has a variable length, which MUST be greater than 0. The value is padded to a 4-octet alignment. The padding is not included in the Length field. The value contains the Speaker Entity Identifier (an identifier of the PCEP speaker transmitting this TLV). This identifier is required to be unique within its scope of visibility, which is usually limited to a single domain. It MAY be configured by the operator. Alternatively, it can be derived automatically from a suitably stable unique identifier,
such as a Media Access Control (MAC) address, serial number, Traffic Engineering Router ID, or similar. In the case of inter-domain connections, the speaker SHOULD prefix its usual identifier with the domain identifier of its residence, such as an Autonomous System number, an IGP area identifier, or similar to make sure it remains unique. The relationship between this identifier and entities in the Traffic Engineering database is intentionally left undefined. From a manageability point of view, a PCE or PCC implementation SHOULD allow the operator to configure this Speaker Entity Identifier. If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP session, that matches with an existing alive PCEP session, the PCEP speaker MUST send a PCErr with Error-type=20 and Error-value=7 'Received an invalid Speaker Entity Identifier', and close the PCEP session. RFC8231] describes the LSP State Synchronization mechanism between PCCs and stateful PCEs. During the State Synchronization, a PCC sends the information of all its LSPs (i.e., the full LSP-DB) to the stateful PCE. In order to reduce the State Synchronization overhead when there is a small number of LSP state changes in the network between the PCEP session restart, this section defines a mechanism for incremental (Delta) LSP-DB synchronization. RFC8231], if a PCE restarts and its LSP-DB survived, PCCs with a mismatched LSP-DB Version Number will send all their LSPs information (full LSP-DB) to the stateful PCE, even if only a small number of LSPs underwent state change. It can take a long time and consume large communication channel bandwidth. Figure 6 shows an example of LSP State Synchronization.
+-----+ | PCE | +-----+ / / / / +------+ +------+ | PCC1 |------------| PCC2 | +------+ +------+ | | | | +------+ +------+ | PCC3 |------------| PCC4 | +------+ +------+ Figure 6: Topology Example Assume that there are 320 LSPs in the network, with each PCC having 80 LSPs. During the time when the PCEP session is down, 20 LSPs of each PCC (i.e., 80 LSPs in total), are changed. Hence, when the PCEP session restarts, the stateful PCE needs to synchronize 320 LSPs with all PCCs. But actually, 240 LSPs stay the same. If performing full LSP State Synchronization, it can take a long time to carry out the synchronization of all LSPs. It is especially true when only a low bandwidth communication channel is available (e.g., in-band control channel for optical transport networks), and there is a substantial number of LSPs in the network. Another disadvantage of full LSP synchronization is that it is a waste of communication bandwidth to perform full LSP synchronization given the fact that the number of LSP changes can be small during the time when the PCEP session is down. An incremental (Delta) LSP-DB State Synchronization is described in this section, where only the LSPs that underwent state change are synchronized between the session restart. This may include new/modified/deleted LSPs. RFC8231] describes State Synchronization and Section 3 of this document describes State Synchronization avoidance by using LSP-DB-VERSION TLV in its OPEN object. This section extends this idea to only synchronize the delta (changes) in case of version mismatch.
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the LSP-DB-VERSION TLV values match, the PCC MAY skip State Synchronization. Otherwise, the PCC MUST perform State Synchronization. Incremental State Synchronization capability is advertised on a PCEP session during session startup using the DELTA-LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7). Instead of dumping full LSP-DB to the stateful PCE again, the PCC synchronizes the delta (changes) as described in Figure 7 when the D and S flags are set to 1 by both the PCC and PCE. Other combinations of D and S flags set by the PCC and PCE result in full LSP-DB synchronization procedures as described in [RFC8231]. By setting the D flag to zero in the OPEN message, a PCEP speaker can skip the incremental synchronization optimization, resulting in a full LSP-DB synchronization.
+-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |--Open--, | | DBv=46 \ ,---Open--| | S=1 \ / DBv=42 | | D=1 \/ S=1 | | /\ D=1 | | / \ | | / `-------->| (Expect delta sync) (Do sync)|<--------` | (DO NOT purge LSP (Delta) | | state) | | (Delta sync starts) |--PCRpt,DBv=46,SYNC=1-->| | . | | . | | . | | . | |--PCRpt,DBv=46,SYNC=0-->| (Sync done, | | PLSP-ID=0) | | |--PCRpt,DBv=47,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=48,SYNC=0-->| (Regular | | LSP State Report) |--PCRpt,DBv=49,SYNC=0-->| | | Figure 7: Incremental Synchronization Procedure As per Section 3, the LSP-DB Version Number is incremented each time a change is made to the PCC's local LSP-DB. Each LSP is associated with the DB version at the time of its state change. This is needed to determine which LSP and what information needs to be synchronized in incremental State Synchronization. The incremental state sync is done from the last LSP-DB version received by the PCE to the latest DB version at the PCC. Note that the LSP-DB Version Number can wrap around, in which case the incremental state sync would also wrap till the latest LSP-DB Version Number at the PCC. In order to carry out incremental State Synchronization, it is not necessary for a PCC to store a complete history of LSP-DB change for all time, but remember the LSP state changes (including LSP modification, setup, and deletion) that the PCE did not get to process during the session down. Note that, a PCC would be unaware that a particular LSP report has been processed by the PCE before the session to the PCE went down. So a PCC implementation MAY choose to
store the LSP-DB Version Number with each LSP at the time its status changed, so that when a session is re-established, an incremental synchronization can be attempted based on the PCE's last LSP-DB Version Number. For an LSP that is deleted at the PCC, the PCC implementation would need to remember the deleted LSP in some way to make sure this could be reported as part of incremental synchronization later. The PCC would discard this information based on a local policy or when it determines that this information is no longer needed with sufficient confidence. In the example shown in Figure 7, the PCC needs to store the LSP state changes that happened between DB Versions 43 to 46 and synchronize these changes, when performing incremental LSP state update. If a PCC finds out it does not have sufficient information to complete incremental synchronization after advertising incremental LSP State Synchronization capability, it MUST send a PCErr with Error-type=20 and Error-value=5 'A PCC indicates to a PCE that it can not complete the State Synchronization' (defined in [RFC8231]), and terminate the session. The PCC SHOULD re-establish the session with the D bit set to 0 in the OPEN message. The other procedures and error checks remain unchanged from the full State Synchronization [RFC8231]. Section 6 but is used in different scenarios and for different purposes.
Section 7). In order to allow a stateful PCE to control the LSP-DB synchronization after establishing a PCEP session, both PCEP speakers MUST set the F bit to 1 in the OPEN message. If the LSP-DB-VERSION TLV is included by both PCEP speakers and the TLV value matches, the State Synchronization can be skipped as described in Section 3.2. If the TLV is not included or the LSP-DB Version is mismatched, the PCE can trigger the State Synchronization process by sending a PCUpd message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD include an empty Explicit Route Object (ERO) (with no ERO sub-object and object length of 4) as its intended path and SHOULD NOT include the optional objects for its attributes for any parameter update. The PCC MUST ignore such an update when the SYNC flag is set. If the TRIGGERED-INITIAL-SYNC capability is not advertised by a PCE and the PCC receives a PCUpd with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1). If the TRIGGERED-INITIAL-SYNC capability is advertised by a PCE and the PCC, the PCC MUST NOT trigger State Synchronization on its own. If the PCE receives a PCRpt message before the PCE has triggered the State Synchronization, the PCE MUST send a PCErr with Error-type=20 and Error-value=3 'Attempt to trigger synchronization before PCE trigger' (see Section 8.1). In this way, the PCE can control the sequence of LSP synchronization among all the PCCs that are re-establishing PCEP sessions with it. When the capability of PCE control is enabled, only after a PCC receives this message, it will start sending information to the PCE. This PCE-triggering capability can be applied to both full and incremental State Synchronization. If applied to the latter, the PCCs only send information that PCE does not possess, which is inferred from the LSP-DB version information exchanged in the OPEN message (see Section 4.2 for a detailed procedure). Once the initial State Synchronization is triggered by the PCE, the procedures and error checks remain unchanged [RFC8231]. If a PCC implementation that does not implement this extension should not receive a PCUpd message to trigger State Synchronization as per the capability advertisement, but if it were to receive it, it will behave as per [RFC8231].
Section 7). The PCE can choose to resynchronize its entire LSP-DB or a single LSP. To trigger resynchronization for an LSP, the PCE sends a Path Computation State Update (PCUpd) for the LSP, with the SYNC flag in the LSP object set to 1. The PCE SHOULD NOT include any parameter updates for the LSP, and the PCC MUST ignore such an update when the SYNC flag is set. The PCC MUST respond with a PCRpt message with the LSP state, SYNC flag set to 0 and MUST include the SRP-ID-number of the PCUpd message that triggered the resynchronization. If the PCC cannot find the LSP in its database, PCC MUST also set the R (remove) flag [RFC8231] in the LSP object in the PCRpt message. The PCE can also trigger resynchronization of the entire LSP-DB. The PCE MUST first mark all LSPs in the LSP-DB that were previously reported by the PCC as stale, and then send a PCUpd with an LSP object containing a PLSP-ID of 0 and with the SYNC flag set to 1. The PCUpd message MUST include an empty ERO (with no ERO sub-object and object length of 4) as its intended path and SHOULD NOT include the optional objects for its attributes for any parameter update. The PCC MUST ignore such update if the SYNC flag is set. This PCUpd message is the trigger for the PCC to enter the synchronization phase as described in [RFC8231] and start sending PCRpt messages. After the receipt of the end-of-synchronization marker, the PCE will purge LSPs that were not refreshed. The SRP-ID-number of the PCUpd that triggered the resynchronization SHOULD be included in each of the PCRpt messages. If the PCC cannot resynchronize the entire LSP-DB, the PCC MUST respond with a PCErr message with Error-type=20 and Error-value=5 'cannot complete the State Synchronization' [RFC8231], and it MAY terminate the session. The PCE MUST remove the stale mark for the LSPs that were previously reported by the PCC. Based on the local policy, the PCE MAY reattempt synchronization at a later time.
If the TRIGGERED-RESYNC capability is not advertised by a PCE and the PCC receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1). Once the state resynchronization is triggered by the PCE, the procedures and error checks remain unchanged from the full state synchronization [RFC8231]. This would also include the PCE triggering multiple state resynchronization requests while synchronization is in progress. If a PCC implementation that does not implement this extension should not receive a PCUpd message to trigger resynchronization as per the capability advertisement, but if it were to receive it, it will behave as per [RFC8231]. RFC8231]. This document defines the following new flags in the STATEFUL-PCE-CAPABILITY TLV: Bit Description ------------------------- --------------------------------- 30 S bit (INCLUDE-DB-VERSION) 27 D bit (DELTA-LSP-SYNC-CAPABILITY) 26 F bit (TRIGGERED-INITIAL-SYNC) 28 T bit (TRIGGERED-RESYNC) If the S bit (INCLUDE-DB-VERSION) is set to 1 by both PCEP speakers, the PCC will include the LSP-DB-VERSION TLV in each LSP object. See Section 3.2 for details. If the D bit (DELTA-LSP-SYNC-CAPABILITY) is set to 1 by a PCEP speaker, it indicates that the PCEP speaker allows incremental (delta) State Synchronization. See Section 4.2 for details. If the F bit (TRIGGERED-INITIAL-SYNC) is set to 1 by both PCEP speakers, the PCE SHOULD trigger initial (first) State Synchronization. See Section 5.2 for details.
If the T bit (TRIGGERED-RESYNC) is set to 1 by both PCEP speakers, the PCE can trigger resynchronization of LSPs at any point in the life of the session. See Section 6.2 for details. See Section 8.3 for IANA allocations. RFC5440] Error-value 12: LSP-DB-VERSION TLV missing This document 20 LSP State Synchronization Error [RFC8231] Error-value 2: LSP-DB version mismatch. This document 3: Attempt to trigger This document synchronization before PCE trigger. 4: Attempt to trigger a This document synchronization when the PCE triggered synchronization capability has not been advertised. 6: Received an invalid This document LSP-DB Version Number. 7: Received an invalid This document Speaker Entity Identifier.
RFC8231]. The "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry has been created to manage the flags in the TLV. IANA has allocated the following values in this registry. Bit Description Reference -------------------------- -------------------------- ------------- 26 TRIGGERED-INITIAL-SYNC This document 27 DELTA-LSP-SYNC-CAPABILITY This document 28 TRIGGERED-RESYNC This document 30 INCLUDE-DB-VERSION This document RFC5440] and [RFC8231] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply. Section 3.3.2). Further, the operator SHOULD be to be allowed to trigger the resynchronization procedures as per Section 6.2. PCEP-YANG] can be extended to include advertised stateful capabilities and synchronization status.
RFC5440]. RFC5440] and [RFC8231]. RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document. The State Synchronization optimizations described in this document can result in a reduction of the amount of data exchanged and the time taken for a stateful PCE to be fully operational when a PCEP session is re-established. The ability to trigger resynchronization by the PCE can be utilized by the operator to sanity check its state and recover from any mismatch in state without tearing down the session. RFC8231] apply to this document as well. However, this document also introduces some new attack vectors. An attacker could spoof the SPEAKER-ENTITY-ID and pretend to be another PCEP speaker. An attacker may flood the PCC with triggered resynchronization requests at a rate that exceeds the PCC's ability to process them by either spoofing messages or compromising the PCE itself. The PCC can respond with a PCErr message as described in Section 6.2 and terminate the session. Thus, securing the PCEP session using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED. An administrator could also expose the Speaker Entity Identifier as part of the certificate, for the peer identity verification.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <http://www.rfc-editor.org/info/rfc8231>. [PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. firstname.lastname@example.org, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017. [PCEPS] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.