draft-ietf-pce-stateful-sync-optimizations-10.txt | rfc8232.txt | |||
---|---|---|---|---|
PCE Working Group E. Crabbe | Internet Engineering Task Force (IETF) E. Crabbe | |||
Internet-Draft Oracle | Request for Comments: 8232 Oracle | |||
Intended status: Standards Track I. Minei | Category: Standards Track I. Minei | |||
Expires: September 28, 2017 Google, Inc. | ISSN: 2070-1721 Google, Inc. | |||
J. Medved | J. Medved | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
R. Varga | R. Varga | |||
Pantheon Technologies SRO | Pantheon Technologies SRO | |||
X. Zhang | X. Zhang | |||
D. Dhody | D. Dhody | |||
Huawei Technologies | Huawei Technologies | |||
March 27, 2017 | September 2017 | |||
Optimizations of Label Switched Path State Synchronization Procedures | Optimizations of Label Switched Path State Synchronization | |||
for a Stateful PCE | Procedures for a Stateful PCE | |||
draft-ietf-pce-stateful-sync-optimizations-10 | ||||
Abstract | Abstract | |||
A stateful Path Computation Element (PCE) has access to not only the | A stateful Path Computation Element (PCE) has access to not only the | |||
information disseminated by the network's Interior Gateway Protocol | information disseminated by the network's Interior Gateway Protocol | |||
(IGP), but also the set of active paths and their reserved resources | (IGP) but also the set of active paths and their reserved resources | |||
for its computation. The additional Label Switched Path (LSP) state | for its computation. The additional Label Switched Path (LSP) state | |||
information allows the PCE to compute constrained paths while | information allows the PCE to compute constrained paths while | |||
considering individual LSPs and their interactions. This requires a | considering individual LSPs and their interactions. This requires a | |||
state synchronization mechanism between the PCE and the network, PCE | State Synchronization mechanism between the PCE and the network, the | |||
and path computation clients (PCCs), and between cooperating PCEs. | PCE and Path Computation Clients (PCCs), and cooperating PCEs. The | |||
The basic mechanism for state synchronization is part of the stateful | basic mechanism for State Synchronization is part of the stateful PCE | |||
PCE specification. This document presents motivations for | specification. This document presents motivations for optimizations | |||
optimizations to the base state synchronization procedure and | to the base State Synchronization procedure and specifies the | |||
specifies the required Path Computation Element Communication | required Path Computation Element Communication Protocol (PCEP) | |||
Protocol (PCEP) extensions. | extensions. | |||
Requirements Language | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on September 28, 2017. | 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 Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language ......................................4 | |||
3. State Synchronization Avoidance . . . . . . . . . . . . . . . 4 | 2. Terminology .....................................................5 | |||
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. State Synchronization Avoidance .................................5 | |||
3.2. State Synchronization Avoidance Procedure . . . . . . . . 4 | 3.1. Motivation .................................................5 | |||
3.2.1. IP Address change during session re-establishment . . 9 | 3.2. State Synchronization Avoidance Procedure ..................5 | |||
3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 10 | 3.2.1. IP Address Change during Session Re-establishment ..10 | |||
3.3.1. LSP State Database Version Number TLV . . . . . . . . 10 | 3.3. PCEP Extensions ...........................................11 | |||
3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 11 | 3.3.1. LSP-DB Version Number TLV ..........................11 | |||
4. Incremental State Synchronization . . . . . . . . . . . . . . 12 | 3.3.2. Speaker Entity Identifier TLV ......................12 | |||
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 12 | 4. Incremental State Synchronization ..............................13 | |||
4.2. Incremental Synchronization Procedure . . . . . . . . . . 13 | 4.1. Motivation ................................................13 | |||
5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 16 | 4.2. Incremental Synchronization Procedure .....................14 | |||
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 16 | 5. PCE-Triggered Initial Synchronization ..........................17 | |||
5.2. PCE-triggered Initial State Synchronization Procedure . . 17 | 5.1. Motivation ................................................17 | |||
6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . 18 | 5.2. PCE-Triggered Initial State Synchronization Procedure .....18 | |||
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 18 | 6. PCE-Triggered Resynchronization ................................19 | |||
6.2. PCE-triggered State Re-synchronization Procedure . . . . 18 | 6.1. Motivation ................................................19 | |||
7. Advertising Support of Synchronization Optimizations . . . . 19 | 6.2. PCE-Triggered State Resynchronization Procedure ...........19 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 7. Advertising Support of Synchronization Optimizations ...........20 | |||
8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 20 | 8. IANA Considerations ............................................21 | |||
8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 21 | 8.1. PCEP-Error Object .........................................21 | |||
8.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 21 | 8.2. PCEP TLV Type Indicators ..................................22 | |||
9. Manageability Considerations . . . . . . . . . . . . . . . . 21 | 8.3. STATEFUL-PCE-CAPABILITY TLV ...............................22 | |||
9.1. Control of Function and Policy . . . . . . . . . . . . . 21 | 9. Manageability Considerations ...................................22 | |||
9.2. Information and Data Models . . . . . . . . . . . . . . . 21 | 9.1. Control of Function and Policy ............................22 | |||
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 22 | 9.2. Information and Data Models ...............................22 | |||
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 22 | 9.3. Liveness Detection and Monitoring .........................23 | |||
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 22 | 9.4. Verify Correct Operations .................................23 | |||
9.6. Impact On Network Operations . . . . . . . . . . . . . . 22 | 9.5. Requirements on Other Protocols ...........................23 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 9.6. Impact on Network Operations ..............................23 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. Security Considerations .......................................23 | |||
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 | 11. References ....................................................24 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 11.1. Normative References .....................................24 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 11.2. Informative References ...................................24 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 24 | Acknowledgments ...................................................25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | Contributors ......................................................25 | |||
Authors' Addresses ................................................26 | ||||
1. Introduction | 1. Introduction | |||
The Path Computation Element Communication Protocol (PCEP) provides | The Path Computation Element Communication Protocol (PCEP) provides | |||
mechanisms for Path Computation Elements (PCEs) to perform path | mechanisms for Path Computation Elements (PCEs) to perform path | |||
computations in response to Path Computation Clients (PCCs) requests. | computations in response to Path Computation Client (PCC) requests. | |||
[I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to | [RFC8231] describes a set of extensions to PCEP to provide stateful | |||
provide stateful control. A stateful PCE has access to not only the | control. A stateful PCE has access to not only the information | |||
information carried by the network's Interior Gateway Protocol (IGP), | carried by the network's Interior Gateway Protocol (IGP) but also the | |||
but also the set of active paths and their reserved resources for its | set of active paths and their reserved resources for its | |||
computations. The additional state allows the PCE to compute | computations. The additional state allows the PCE to compute | |||
constrained paths while considering individual LSPs and their | constrained paths while considering individual LSPs and their | |||
interactions. This requires a state synchronization mechanism | interactions. This requires a State Synchronization mechanism | |||
between the PCE and the network, PCE and PCC, and between cooperating | between the PCE and the network, the PCE and the PCC, and cooperating | |||
PCEs. [I-D.ietf-pce-stateful-pce] describes the basic mechanism for | PCEs. [RFC8231] describes the basic mechanism for State | |||
state synchronization. This document specifies following | Synchronization. This document specifies following optimizations for | |||
optimizations for state synchronization and the corresponding PCEP | State Synchronization and the corresponding PCEP procedures and | |||
procedures and extensions: | extensions: | |||
o State Synchronization Avoidance: To skip state synchronization if | o State Synchronization Avoidance: To skip State Synchronization if | |||
the state has survived and not changed during session restart. | the state has survived and not changed during session restart. | |||
(See Section 3.) | (See Section 3.) | |||
o Incremental State Synchronization: To do incremental (delta) state | o Incremental State Synchronization: To do incremental (delta) State | |||
synchronization when possible. (See Section 4.) | Synchronization when possible. (See Section 4.) | |||
o PCE-triggered Initial Synchronization: To let PCE control the | o PCE-Triggered Initial Synchronization: To let PCE control the | |||
timing of the initial state synchronization. (See Section 5.) | timing of the initial State Synchronization. (See Section 5.) | |||
o PCE-triggered Re-synchronization: To let PCE re-synchronize the | o PCE-Triggered Resynchronization: To let PCE resynchronize the | |||
state for sanity check. (See Section 6.) | state for sanity check. (See Section 6.) | |||
Support for each of the synchronization optimization capabilities is | Support for each of the synchronization optimization capabilities is | |||
advertised during the PCEP initialization phase. See Section 7 for | advertised during the PCEP initialization phase. See Section 7 for | |||
the new flags defined in this document. The handling of each flag is | the new flags defined in this document. The handling of each flag is | |||
described in the relevant section. | described in the relevant section. | |||
1.1. Requirements Language | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
"OPTIONAL" in this document are to be interpreted as described in BCP | ||||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
2. Terminology | 2. Terminology | |||
This document uses the following terms defined in [RFC5440]: PCC, | This document uses the following terms defined in [RFC5440]: PCC, | |||
PCE, PCEP Peer. | PCE, and PCEP Peer. | |||
This document uses the following terms defined in [RFC8051]: Stateful | This document uses the following terms defined in [RFC8051]: Stateful | |||
PCE, Delegation, LSP State Database. | PCE, Delegation, and LSP State Database (LSP-DB). | |||
This document uses the following terms defined in | This document uses the following terms defined in [RFC8231]: | |||
[I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State | Redelegation Timeout Interval, LSP State Report, and LSP Update | |||
Report, LSP Update Request. | Request. | |||
Within this document, when describing PCE-PCE communications, one of | Within this document, when describing PCE-PCE communications, the | |||
the PCEs fills the role of a PCC. This provides a saving in | requesting PCE fills the role of a PCC as usual. | |||
documentation without loss of function. | ||||
3. State Synchronization Avoidance | 3. State Synchronization Avoidance | |||
3.1. Motivation | 3.1. Motivation | |||
The purpose of state synchronization is to provide a checkpoint-in- | The purpose of State Synchronization is to provide a | |||
time state replica of a PCC's LSP state in a stateful PCE. State | checkpoint-in-time state replica of a PCC's LSP state in a stateful | |||
synchronization is performed immediately after the initialization | PCE. State Synchronization is performed immediately after the | |||
phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic | initialization phase [RFC5440]. [RFC8231] describes the basic | |||
mechanism for state synchronization. | mechanism for State Synchronization. | |||
State synchronization is not always necessary following a PCEP | State Synchronization is not always necessary following a PCEP | |||
session restart. If the state of both PCEP peers did not change, the | session restart. If the state of both PCEP peers did not change, the | |||
synchronization phase may be skipped. This can result in significant | synchronization phase may be skipped. This can result in significant | |||
savings in both control-plane data exchanges and the time it takes | savings in both control-plane data exchanges and the time it takes | |||
for the stateful PCE to become fully operational. | for the stateful PCE to become fully operational. | |||
3.2. State Synchronization Avoidance Procedure | 3.2. State Synchronization Avoidance Procedure | |||
State synchronization MAY be skipped following a PCEP session restart | State Synchronization MAY be skipped following a PCEP session restart | |||
if the state of both PCEP peers did not change during the period | if the state of both PCEP peers did not change during the period | |||
prior to session re-initialization. To be able to make this | prior to session re-initialization. To be able to make this | |||
determination, state must be exchanged and maintained by both PCE and | determination, state must be exchanged and maintained by both PCE and | |||
PCC during normal operation. This is accomplished by keeping track | PCC during normal operation. This is accomplished by keeping track | |||
of the changes to the LSP state database, using a version tracking | of the changes to the LSP-DB, using a version tracking field called | |||
field called the LSP State Database Version Number. | the LSP-DB Version Number. | |||
The INCLUDE-DB-VERSION (S) bit in the stateful PCE capability TLV | The INCLUDE-DB-VERSION (S) bit in the STATEFUL-PCE-CAPABILITY TLV | |||
(Section 7) is advertised on a PCEP session during session startup to | (Section 7) is advertised on a PCEP session during session startup to | |||
indicate that the LSP State Database Version Number is to be included | indicate that the LSP-DB Version Number is to be included when the | |||
when the LSPs are reported to the PCE. The LSP State Database | LSPs are reported to the PCE. The LSP-DB Version Number, carried in | |||
Version Number, carried in LSP-DB-VERSION TLV (see Section 3.3.1), is | LSP-DB-VERSION TLV (see Section 3.3.1), is owned by a PCC, and it | |||
owned by a PCC and it MUST be incremented by 1 for each successive | MUST be incremented by 1 for each successive change in the PCC's LSP- | |||
change in the PCC's LSP state database. The LSP State Database | DB. The LSP-DB Version Number MUST start at 1 and may wrap around. | |||
Version Number MUST start at 1 and may wrap around. Values 0 and | ||||
0xFFFFFFFFFFFFFFFF are reserved. If either of the two values are | Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of the two | |||
used during LSP state (re)-synchronization, the PCE speaker receiving | values are used during LSP State (re)Synchronization, the PCE speaker | |||
this value MUST send back a PCErr with Error-type 20 Error-value TBD6 | receiving this value MUST send back a PCEP Error (PCErr) with Error- | |||
(suggested value - 6) 'Received an invalid LSP DB Version Number', | type=20 and Error-value=6 'Received an invalid LSP-DB Version | |||
and close the PCEP session. Operations that trigger a change to the | Number', and close the PCEP session. Operations that trigger a | |||
local LSP state database include a change in the LSP operational | 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 | 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. | 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 | If the include LSP-DB version capability is enabled, a PCC MUST | |||
increment its LSP State Database Version Number when the | increment its LSP-DB Version Number when the 'Redelegation Timeout | |||
'Redelegation Timeout Interval' timer expires (see | Interval' timer expires (see [RFC8231] for the use of the | |||
[I-D.ietf-pce-stateful-pce] for the use of the Redelegation Timeout | Redelegation Timeout Interval). | |||
Interval). | ||||
If both PCEP speakers set the S flag in the OPEN object's STATEFUL- | If both PCEP speakers set the S flag in the OPEN object's | |||
PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV | STATEFUL-PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB- | |||
in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV | VERSION TLV in each LSP object of the Path Computation LSP State | |||
is missing in a PCRpt message, the PCE will generate an error with | Report (PCRpt) message. If the LSP-DB-VERSION TLV is missing in a | |||
Error-Type 6 (mandatory object missing) and Error-Value TBD1 | PCRpt message, the PCE will generate an error with Error-type=6 | |||
(suggested value - 12) 'LSP-DB-VERSION TLV missing' and close the | (Mandatory Object missing) and Error-value=12 'LSP-DB-VERSION TLV | |||
session. If the include LSP DB version capability has not been | missing', and close the session. If the include LSP-DB version | |||
enabled on a PCEP session, the PCC SHOULD NOT include the LSP-DB- | capability has not been enabled on a PCEP session, the PCC SHOULD NOT | |||
VERSION TLV in the LSP Object and the PCE MUST ignore it were it to | include the LSP-DB-VERSION TLV in the LSP Object, and the PCE MUST | |||
receive one. | ignore it, were it to receive one. | |||
If a PCE's LSP state database survived the restart of a PCEP session, | If a PCE's LSP-DB survived the restart of a PCEP session, the PCE | |||
the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and | will include the LSP-DB-VERSION TLV in its OPEN object, and the TLV | |||
the TLV will contain the last LSP State Database Version Number | will contain the last LSP-DB Version Number received on an LSP State | |||
received on an LSP State Report from the PCC in the previous PCEP | Report from the PCC in the previous PCEP session. If a PCC's LSP-DB | |||
session. If a PCC's LSP State Database survived the restart of a | survived the restart of a PCEP session, the PCC will include the LSP- | |||
PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN | DB-VERSION TLV in its OPEN object, and the TLV will contain the | |||
object and the TLV will contain the latest LSP State Database Version | latest LSP-DB Version Number. If a PCEP speaker's LSP-DB did not | |||
Number. If a PCEP speaker's LSP state database did not survive the | survive the restart of a PCEP session or at startup when the database | |||
restart of a PCEP session or at startup when the database is empty, | is empty, the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in | |||
the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN | the OPEN object. | |||
object. | ||||
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN | If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN | |||
Object and the TLV values match, the PCC MAY skip state | object and the TLV values match, the PCC MAY skip State | |||
synchronization and the PCE does not wait for the end of | Synchronization, and the PCE does not wait for the end-of- | |||
synchronization marker [I-D.ietf-pce-stateful-pce]. Otherwise, the | synchronization marker [RFC8231]. Otherwise, the PCC MUST perform | |||
PCC MUST perform full state synchronization (see | full State Synchronization (see [RFC8231]) or incremental State | |||
[I-D.ietf-pce-stateful-pce]) or incremental state synchronization | Synchronization (see Section 4 if this capability is advertised) to | |||
(see Section 4 if this capability is advertised) to the stateful PCE. | the stateful PCE. In other words, if the incremental State | |||
In other words, if the incremental state synchronization capability | Synchronization capability is not advertised by the peers, based on | |||
is not advertised by the peers, based on the LSP database version | the LSP-DB Version Number match, either the State Synchronization is | |||
number match either the state synchronization is skipped or a full | skipped or a full State Synchronization is performed. If the PCC | |||
state synchronization is performed. If the PCC attempts to skip | attempts to skip State Synchronization, by setting the SYNC flag to 0 | |||
state synchronization, by setting the SYNC Flag to 0 and PLSP-ID to a | and PLSP-ID to a non-zero value on the first LSP State Report from | |||
non-zero value on the first LSP State Report from the PCC as per | the PCC as per [RFC8231], the PCE MUST send back a PCErr with Error- | |||
[I-D.ietf-pce-stateful-pce], the PCE MUST send back a PCErr with | type=20 and Error-value=2 'LSP-DB version mismatch', and close the | |||
Error-Type 20 Error-Value TBD2 (suggested value - 2) 'LSP Database | PCEP session. | |||
version mismatch', and close the PCEP session. | ||||
If state synchronization is required, then prior to completing the | If State Synchronization is required, then prior to completing the | |||
initialization phase, the PCE MUST mark any LSPs in the LSP database | initialization phase, the PCE MUST mark any LSPs in the LSP-DB that | |||
that were previously reported by the PCC as stale. When the PCC | were previously reported by the PCC as stale. When the PCC reports | |||
reports an LSP during state synchronization, if the LSP already | an LSP during State Synchronization, if the LSP already exists in the | |||
exists in the LSP database, the PCE MUST update the LSP database and | LSP-DB, the PCE MUST update the LSP-DB and clear the stale marker | |||
clear the stale marker from the LSP. When it has finished state | from the LSP. When it has finished State Synchronization, the PCC | |||
synchronization, the PCC MUST immediately send an end of | MUST immediately send an end-of-synchronization marker. The end-of- | |||
synchronization marker. The end of synchronization marker is a Path | synchronization marker is a PCRpt message with an LSP object | |||
Computation State Report (PCRpt) message with an LSP object | containing a PLSP-ID of 0 and with the SYNC flag set to 0 [RFC8231]. | |||
containing a PLSP-ID of 0 and with the SYNC flag set to 0 | The LSP-DB-VERSION TLV MUST be included in this PCRpt message. On | |||
([I-D.ietf-pce-stateful-pce]). The LSP-DB-VERSION TLV MUST be | receiving this state report, the PCE MUST purge any LSPs from the | |||
included in this PCRpt message. On receiving this state report, the | LSP-DB that are still marked as stale. | |||
PCE MUST purge any LSPs from the LSP database that are still marked | ||||
as stale. | ||||
Note that a PCE/PCC MAY force state synchronization by not including | Note that a PCE/PCC MAY force State Synchronization by not including | |||
the LSP-DB-VERSION TLV in its OPEN object. | the LSP-DB-VERSION TLV in its OPEN object. | |||
Since a PCE does not make changes to the LSP State Database Version | Since a PCE does not make changes to the LSP-DB Version Number, a PCC | |||
Number, a PCC should never encounter this TLV in a message from the | should never encounter this TLV in a message from the PCE (other than | |||
PCE (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- | the OPEN message). A PCC SHOULD ignore the LSP-DB-VERSION TLV, were | |||
VERSION TLV, were it to receive one from a PCE. | it to receive one from a PCE. | |||
Figure 1 shows an example sequence where the state synchronization is | Figure 1 shows an example sequence where the State Synchronization is | |||
skipped. | skipped. | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
|PCC| |PCE| | |PCC| |PCE| | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
| | | | | | |||
|--Open--, | | |--Open--, | | |||
| DBv=42 \ ,---Open--| | | DBv=42 \ ,---Open--| | |||
| S=1 \ / DBv=42 | | | S=1 \ / DBv=42 | | |||
| \/ S=1 | | | \/ S=1 | | |||
skipping to change at page 7, line 29 ¶ | skipping to change at page 8, line 29 ¶ | |||
| | | | | | |||
|--PCRpt,DBv=43,SYNC=0-->| (Regular | |--PCRpt,DBv=43,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=44,SYNC=0-->| (Regular | |--PCRpt,DBv=44,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=45,SYNC=0-->| | |--PCRpt,DBv=45,SYNC=0-->| | |||
| | | | | | |||
Figure 1: State Synchronization Skipped | Figure 1: State Synchronization Skipped | |||
Figure 2 shows an example sequence where the state synchronization is | Figure 2 shows an example sequence where the State Synchronization is | |||
performed due to LSP state database version mismatch during the PCEP | performed due to LSP-DB version mismatch during the PCEP session | |||
session setup. Note that the same state synchronization sequence | setup. Note that the same State Synchronization sequence would | |||
would happen if either the PCC or the PCE would not include the LSP- | happen if either the PCC or the PCE would not include the LSP-DB- | |||
DB-VERSION TLV in their respective Open messages. | VERSION TLV in their respective Open messages. | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
|PCC| |PCE| | |PCC| |PCE| | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
| | | | | | |||
|--Open--, | | |--Open--, | | |||
| DBv=46 \ ,---Open--| | | DBv=46 \ ,---Open--| | |||
| S=1 \ / DBv=42 | | | S=1 \ / DBv=42 | | |||
| \/ S=1 | | | \/ S=1 | | |||
| /\ | | | /\ | | |||
| / `-------->| (Expect sync) | | / `-------->| (Expect sync) | |||
(Do sync) |<--------` | | (Do sync) |<--------` | | |||
| | | | | | |||
|--PCRpt,DBv=46,SYNC=1-->| (Sync start) | |--PCRpt,DBv=46,SYNC=1-->| (Sync start) | |||
| . | | | . | | |||
| . | | | . | | |||
| . | | | . | | |||
|--PCRpt,DBv=46,SYNC=0-->| (Sync done) | |--PCRpt,DBv=46,SYNC=0-->| (Sync done) | |||
| . |(Purge LSP State | | . | (Purge LSP state | |||
| . | if applicable) | | . | if applicable) | |||
| . | | | . | | |||
|--PCRpt,DBv=47,SYNC=0-->| (Regular | |--PCRpt,DBv=47,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=48,SYNC=0-->| (Regular | |--PCRpt,DBv=48,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=49,SYNC=0-->| | |--PCRpt,DBv=49,SYNC=0-->| | |||
| | | | | | |||
Figure 2: State Synchronization Performed | Figure 2: State Synchronization Performed | |||
Figure 3 shows an example sequence where the state synchronization is | 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, | 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 | the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt | |||
messages to the PCE. If the current PCEP session restarts, the PCEP | messages to the PCE. If the current PCEP session restarts, the PCEP | |||
speakers will have to perform state synchronization, since the PCE | speakers will have to perform State Synchronization, since the PCE | |||
does not know the PCC's latest LSP State Database Version Number | does not know the PCC's latest LSP-DB Version Number information. | |||
information. | ||||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
|PCC| |PCE| | |PCC| |PCE| | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
| | | | | | |||
|--Open--, | | |--Open--, | | |||
| DBv=42 \ ,---Open--| | | DBv=42 \ ,---Open--| | |||
| S=0 \ / DBv=42 | | | S=0 \ / DBv=42 | | |||
| \/ S=0 | | | \/ S=0 | | |||
| /\ | | | /\ | | |||
skipping to change at page 9, line 26 ¶ | skipping to change at page 10, line 26 ¶ | |||
| . | | | . | | |||
| . | | | . | | |||
| . | | | . | | |||
|------PCRpt,SYNC=0----->| (Regular | |------PCRpt,SYNC=0----->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|------PCRpt,SYNC=0----->| (Regular | |------PCRpt,SYNC=0----->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|------PCRpt,SYNC=0----->| | |------PCRpt,SYNC=0----->| | |||
| | | | | | |||
Figure 3: State Synchronization Skipped, no LSP-DB-VERSION TLVs sent | Figure 3: State Synchronization Skipped; | |||
from PCC | No LSP-DB-VERSION TLVs Sent from the PCC | |||
3.2.1. IP Address change during session re-establishment | 3.2.1. IP Address Change during Session Re-establishment | |||
There could be a case during PCEP session re-establishment when the | There could be a case during PCEP session re-establishment when the | |||
PCC's or PCE's IP address can change. This includes, but is not | PCC's or PCE's IP address can change. This includes, but is not | |||
limited to, the following cases: | limited to, the following cases: | |||
o A PCC could use a physical interface IP address to connect to the | o A PCC could use a physical interface IP address to connect to the | |||
PCE. In this case, if the line card that the PCC connects from | PCE. In this case, if the line card that the PCC connects from | |||
changes, then the PCEP session goes down and comes back up again, | changes, then the PCEP session goes down and comes back up again, | |||
with a different IP address associated with a new line card. | with a different IP address associated with a new line card. | |||
o The PCC or PCE may move in the network, either physically or | o The PCC or PCE may move in the network, either physically or | |||
logically, which may cause its IP address to change. For example, | logically, which may cause its IP address to change. For example, | |||
the PCE may be deployed as a virtual network function (VNF) and | the PCE may be deployed as a virtual network function (VNF), and | |||
another virtualized instance of the PCE may be populated with the | another virtualized instance of the PCE may be populated with the | |||
original PCE instance's state, but be given a different IP | original PCE instance's state, but it may be given a different IP | |||
address. | address. | |||
To ensure that a PCEP peer can recognize a previously connected peer, | To ensure that a PCEP peer can recognize a previously connected peer, | |||
each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in | each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in | |||
Section 3.3.2, in the OPEN message. | Section 3.3.2 in the OPEN message. | |||
This TLV is used during the state synchronization procedure to | This TLV is used during the State Synchronization procedure to | |||
identify the PCEP session as a re-establishment of a previous session | identify the PCEP session as a re-establishment of a previous session | |||
that went down. Then state synchronization optimizations such as | that went down. Then State Synchronization optimizations such as | |||
state sync avoidance can be applied to this session. Note that this | state sync avoidance can be applied to this session. Note that this | |||
usage is only applicable within the State Timeout Interval | usage is only applicable within the State Timeout Interval [RFC8231]. | |||
[I-D.ietf-pce-stateful-pce]. After the State Timeout Interval | After the State Timeout Interval expires, all state associated with | |||
expires, all state associated with the PCEP session is removed, which | the PCEP session is removed, which includes the SPEAKER-ENTITY-ID | |||
includes the SPEAKER-ENTITY-ID received. Note that the PCEP session | received. Note that the PCEP session initialization [RFC5440] | |||
initialization [RFC5440] procedure remains unchanged. | procedure remains unchanged. | |||
3.3. PCEP Extensions | 3.3. PCEP Extensions | |||
A new INCLUDE-DB-VERSION (S) bit is added in the stateful | A new INCLUDE-DB-VERSION (S) bit is added in the stateful | |||
capabilities TLV (see Section 7 for details). | capabilities TLV (see Section 7 for details). | |||
3.3.1. LSP State Database Version Number TLV | 3.3.1. LSP-DB Version Number TLV | |||
The LSP State Database Version Number (LSP-DB-VERSION) TLV is an | The LSP-DB Version Number (LSP-DB-VERSION) TLV is an optional TLV | |||
optional TLV that MAY be included in the OPEN object and the LSP | that MAY be included in the OPEN object and the LSP object. | |||
object. | ||||
This TLV is included in the LSP object in the PCRpt message to | This TLV is included in the LSP object in the PCRpt message to | |||
indicate the LSP DB version at the PCC. This TLV SHOULD NOT be | indicate the LSP-DB version at the PCC. This TLV SHOULD NOT be | |||
included in other PCEP messages (PCUpd, PcReq, PCRep) and MUST be | included in other PCEP messages (Path Computation Update Request | |||
ignored if received. | (PCUpd), Path Computation Request (PCReq), and Path Computation Reply | |||
(PCRep)) and MUST be ignored if received. | ||||
The format of the LSP-DB-VERSION TLV is shown in the following | The format of the LSP-DB-VERSION TLV is shown in the following | |||
figure: | figure: | |||
0 1 2 3 | 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 | 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=TBD5 | Length=8 | | | Type=23 | Length=8 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSP State DB Version Number | | | LSP-DB Version Number | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: LSP-DB-VERSION TLV format | Figure 4: LSP-DB-VERSION TLV Format | |||
The type of the TLV is TBD5 and it has a fixed length of 8 octets. | 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 | The value contains a 64-bit unsigned integer, carried in network byte | |||
order, representing the LSP State DB Version Number. | order, representing the LSP-DB Version Number. | |||
3.3.2. Speaker Entity Identifier TLV | 3.3.2. Speaker Entity Identifier TLV | |||
The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional | The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional | |||
TLV that MAY be included in the OPEN Object when a PCEP speaker | TLV that MAY be included in the OPEN object when a PCEP speaker | |||
wishes to determine if state synchronization can be skipped when a | wishes to determine if State Synchronization can be skipped when a | |||
PCEP session is restarted. It contains a unique identifier for the | PCEP session is restarted. It contains a unique identifier for the | |||
node that does not change during the lifetime of the PCEP speaker. | node that does not change during the lifetime of the PCEP speaker. | |||
It identifies the PCEP speaker to its peers even if the speaker's IP | It identifies the PCEP speaker to its peers even if the speaker's IP | |||
address is changed. | address is changed. | |||
In case of a remote peer IP address change, a PCEP speaker would | In case of a remote peer IP address change, a PCEP speaker would | |||
learn the speaker entity identifier on receiving the open message but | learn the Speaker Entity Identifier on receiving the open message, | |||
it MAY have already sent its open message without realizing that it | but it MAY have already sent its open message without realizing that | |||
is a known PCEP peer. In such a case, either a full synchronization | it is a known PCEP peer. In such a case, either a full | |||
is done or PCEP session is terminated. This may be a local policy | synchronization is done or the PCEP session is terminated. This may | |||
decision. The new IP address is associated with the speaker entity | be a local policy decision. The new IP address is associated with | |||
identifier for future either way. In the latter case when PCEP | the Speaker Entity Identifier for the future either way. In the | |||
session is re-established, it would be correctly associated with | latter case when the PCEP session is re-established, it would be | |||
speaker entity identifier and not be considered as an unknown peer. | correctly associated with the Speaker Entity Identifier and not be | |||
considered as an unknown peer. | ||||
The format of the SPEAKER-ENTITY-ID TLV is shown in the following | The format of the SPEAKER-ENTITY-ID TLV is shown in the following | |||
figure: | figure: | |||
0 1 2 3 | 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 | 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=TBD13 | Length (variable) | | | Type=24 | Length (variable) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// Speaker Entity Identifier // | // Speaker Entity Identifier // | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 5: SPEAKER-ENTITY-ID TLV format | Figure 5: SPEAKER-ENTITY-ID TLV Format | |||
The type of the TLV is TBD13 and it has a variable length, which MUST | The type of the TLV is 24, and it has a variable length, which MUST | |||
be greater than 0. The Value is padded to 4-octet alignment. The | 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 | padding is not included in the Length field. The value contains the | |||
entity identifier of the speaker transmitting this TLV. This | Speaker Entity Identifier (an identifier of the PCEP speaker | |||
identifier is required to be unique within its scope of visibility, | transmitting this TLV). This identifier is required to be unique | |||
which is usually limited to a single domain. It MAY be configured by | within its scope of visibility, which is usually limited to a single | |||
the operator. Alternatively, it can be derived automatically from a | domain. It MAY be configured by the operator. Alternatively, it can | |||
suitably-stable unique identifier, such as a MAC address, serial | be derived automatically from a suitably stable unique identifier, | |||
number, Traffic Engineering Router ID, or similar. In the case of | such as a Media Access Control (MAC) address, serial number, Traffic | |||
inter-domain connections, the speaker SHOULD prefix its usual | Engineering Router ID, or similar. In the case of inter-domain | |||
identifier with the domain identifier of its residence, such as | connections, the speaker SHOULD prefix its usual identifier with the | |||
Autonomous System number, IGP area identifier, or similar to make | domain identifier of its residence, such as an Autonomous System | |||
sure it remains unique. | number, an IGP area identifier, or similar to make sure it remains | |||
unique. | ||||
The relationship between this identifier and entities in the Traffic | The relationship between this identifier and entities in the Traffic | |||
Engineering database is intentionally left undefined. | Engineering database is intentionally left undefined. | |||
From a manageability point of view, a PCE or PCC implementation | From a manageability point of view, a PCE or PCC implementation | |||
SHOULD allow the operator to configure this Speaker Entity | SHOULD allow the operator to configure this Speaker Entity | |||
Identifier. | Identifier. | |||
If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP | If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP | |||
session, that matches with an existing alive PCEP session, the PCEP | session, that matches with an existing alive PCEP session, the PCEP | |||
speaker MUST send a PCErr with Error-type 20 Error-value TBD7 | speaker MUST send a PCErr with Error-type=20 and Error-value=7 | |||
(suggested value - 7) 'Received an invalid Speaker Entity | 'Received an invalid Speaker Entity Identifier', and close the PCEP | |||
Identifier', and close the PCEP session. | session. | |||
4. Incremental State Synchronization | 4. Incremental State Synchronization | |||
[I-D.ietf-pce-stateful-pce] describes the LSP state synchronization | [RFC8231] describes the LSP State Synchronization mechanism between | |||
mechanism between PCCs and stateful PCEs. During the state | PCCs and stateful PCEs. During the State Synchronization, a PCC | |||
synchronization, a PCC sends the information of all its LSPs (i.e., | sends the information of all its LSPs (i.e., the full LSP-DB) to the | |||
the full LSP-DB) to the stateful PCE. In order to reduce the state | stateful PCE. In order to reduce the State Synchronization overhead | |||
synchronization overhead when there is a small number of LSP state | when there is a small number of LSP state changes in the network | |||
change in the network between PCEP session restart, this section | between the PCEP session restart, this section defines a mechanism | |||
defines a mechanism for incremental (Delta) LSP Database (LSP-DB) | for incremental (Delta) LSP-DB synchronization. | |||
synchronization. | ||||
4.1. Motivation | 4.1. Motivation | |||
According to [I-D.ietf-pce-stateful-pce], if a PCE restarts and its | According to [RFC8231], if a PCE restarts and its LSP-DB survived, | |||
LSP-DB survived, PCCs with mismatched LSP State Database Version | PCCs with a mismatched LSP-DB Version Number will send all their LSPs | |||
Number will send all their LSPs information (full LSP-DB) to the | information (full LSP-DB) to the stateful PCE, even if only a small | |||
stateful PCE, even if only a small number of LSPs underwent state | number of LSPs underwent state change. It can take a long time and | |||
change. It can take a long time and consume large communication | consume large communication channel bandwidth. | |||
channel bandwidth. | ||||
Figure 6 shows an example of LSP state synchronization. | Figure 6 shows an example of LSP State Synchronization. | |||
+-----+ | +-----+ | |||
| PCE | | | PCE | | |||
+-----+ | +-----+ | |||
/ | / | |||
/ | / | |||
/ | / | |||
/ | / | |||
+------+ +------+ | +------+ +------+ | |||
| PCC1 |------------| PCC2 | | | PCC1 |------------| PCC2 | | |||
+------+ +------+ | +------+ +------+ | |||
| | | | | | |||
| | | | | | |||
+------+ +------+ | +------+ +------+ | |||
| PCC3 |------------| PCC4 | | | PCC3 |------------| PCC4 | | |||
+------+ +------+ | +------+ +------+ | |||
Figure 6: Topology Example | Figure 6: Topology Example | |||
Assuming there are 320 LSPs in the network, with each PCC having 80 | Assume that there are 320 LSPs in the network, with each PCC having | |||
LSPs. During the time when the PCEP session is down, 20 LSPs of each | 80 LSPs. During the time when the PCEP session is down, 20 LSPs of | |||
PCC (i.e., 80 LSPs in total), are changed. Hence when PCEP session | each PCC (i.e., 80 LSPs in total), are changed. Hence, when the PCEP | |||
restarts, the stateful PCE needs to synchronize 320 LSPs with all | session restarts, the stateful PCE needs to synchronize 320 LSPs with | |||
PCCs. But actually, 240 LSPs stay the same. If performing full LSP | all PCCs. But actually, 240 LSPs stay the same. If performing full | |||
state synchronization, it can take a long time to carry out the | 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 | synchronization of all LSPs. It is especially true when only a low | |||
bandwidth communication channel is available (e.g., in-band control | bandwidth communication channel is available (e.g., in-band control | |||
channel for optical transport networks) and there is a substantial | channel for optical transport networks), and there is a substantial | |||
number of LSPs in the network. Another disadvantage of full LSP | number of LSPs in the network. Another disadvantage of full LSP | |||
synchronization is that it is a waste of communication bandwidth to | synchronization is that it is a waste of communication bandwidth to | |||
perform full LSP synchronization given the fact that the number of | perform full LSP synchronization given the fact that the number of | |||
LSP changes can be small during the time when PCEP session is down. | LSP changes can be small during the time when the PCEP session is | |||
down. | ||||
An incremental (Delta) LSP Database (LSP-DB) state synchronization is | An incremental (Delta) LSP-DB State Synchronization is described in | |||
described in this section, where only the LSPs underwent state change | this section, where only the LSPs that underwent state change are | |||
are synchronized between the session restart. This may include | synchronized between the session restart. This may include | |||
new/modified/deleted LSPs. | new/modified/deleted LSPs. | |||
4.2. Incremental Synchronization Procedure | 4.2. Incremental Synchronization Procedure | |||
[I-D.ietf-pce-stateful-pce] describes state synchronization and | [RFC8231] describes State Synchronization and Section 3 of this | |||
Section 3 of this document, describes state synchronization avoidance | document describes State Synchronization avoidance by using | |||
by using LSP-DB-VERSION TLV in its OPEN object. This section extends | LSP-DB-VERSION TLV in its OPEN object. This section extends this | |||
this idea to only synchronize the delta (changes) in case of version | idea to only synchronize the delta (changes) in case of version | |||
mismatch. | mismatch. | |||
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN | 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 | object and the LSP-DB-VERSION TLV values match, the PCC MAY skip | |||
state synchronization. Otherwise, the PCC MUST perform state | State Synchronization. Otherwise, the PCC MUST perform State | |||
synchronization. Incremental State synchronization capability is | Synchronization. Incremental State Synchronization capability is | |||
advertised on a PCEP session during session startup using the DELTA- | advertised on a PCEP session during session startup using the | |||
LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7). | DELTA-LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see | |||
Instead of dumping full LSP-DB to the stateful PCE again, the PCC | Section 7). Instead of dumping full LSP-DB to the stateful PCE | |||
synchronizes the delta (changes) as described in Figure 7 when D flag | again, the PCC synchronizes the delta (changes) as described in | |||
and S flag is set to 1 by both PCC and PCE. Other combinations of D | Figure 7 when the D and S flags are set to 1 by both the PCC and PCE. | |||
and S flags setting by PCC and PCE result in full LSP-DB | Other combinations of D and S flags set by the PCC and PCE result in | |||
synchronization procedure as described in | full LSP-DB synchronization procedures as described in [RFC8231]. By | |||
[I-D.ietf-pce-stateful-pce]. By setting the D flag to zero in the | setting the D flag to zero in the OPEN message, a PCEP speaker can | |||
OPEN message, a PCEP speaker can skip the incremental synchronization | skip the incremental synchronization optimization, resulting in a | |||
optimization, resulting in a full LSP DB synchronization. | full LSP-DB synchronization. | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
|PCC| |PCE| | |PCC| |PCE| | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
| | | | | | |||
|--Open--, | | |--Open--, | | |||
| DBv=46 \ ,---Open--| | | DBv=46 \ ,---Open--| | |||
| S=1 \ / DBv=42 | | | S=1 \ / DBv=42 | | |||
| D=1 \/ S=1 | | | D=1 \/ S=1 | | |||
| /\ D=1 | | | /\ D=1 | | |||
| / \ | | | / \ | | |||
| / `-------->| (Expect Delta sync) | | / `-------->| (Expect delta sync) | |||
(Do sync)|<--------` | (DONOT Purge LSP | (Do sync)|<--------` | (DO NOT purge LSP | |||
(Delta) | | State) | (Delta) | | state) | |||
| | | | | | |||
(Delta Sync starts) |--PCRpt,DBv=46,SYNC=1-->| | (Delta sync starts) |--PCRpt,DBv=46,SYNC=1-->| | |||
| . | | | . | | |||
| . | | | . | | |||
| . | | | . | | |||
| . | | | . | | |||
|--PCRpt,DBv=46,SYNC=0-->| (Sync done, | |--PCRpt,DBv=46,SYNC=0-->| (Sync done, | |||
| | PLSP-ID=0) | | | PLSP-ID=0) | |||
| | | | | | |||
|--PCRpt,DBv=47,SYNC=0-->| (Regular | |--PCRpt,DBv=47,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=48,SYNC=0-->| (Regular | |--PCRpt,DBv=48,SYNC=0-->| (Regular | |||
| | LSP State Report) | | | LSP State Report) | |||
|--PCRpt,DBv=49,SYNC=0-->| | |--PCRpt,DBv=49,SYNC=0-->| | |||
| | | | | | |||
Figure 7: Incremental Synchronization Procedure | Figure 7: Incremental Synchronization Procedure | |||
As per Section 3, the LSP State Database Version Number is | As per Section 3, the LSP-DB Version Number is incremented each time | |||
incremented each time a change is made to the PCC's local LSP State | a change is made to the PCC's local LSP-DB. Each LSP is associated | |||
Database. Each LSP is associated with the DB version at the time of | with the DB version at the time of its state change. This is needed | |||
its state change. This is needed to determine which LSP and what | to determine which LSP and what information needs to be synchronized | |||
information needs to be synchronized in incremental state | in incremental State Synchronization. The incremental state sync is | |||
synchronization. The incremental state sync is done from the last | done from the last LSP-DB version received by the PCE to the latest | |||
LSP DB version received by the PCE to the latest DB version at the | DB version at the PCC. Note that the LSP-DB Version Number can wrap | |||
PCC. Note that the LSP State Database Version Number can wrap | around, in which case the incremental state sync would also wrap till | |||
around, and in which case the incremental state sync would also wrap | the latest LSP-DB Version Number at the PCC. | |||
till the latest DB version number at the PCC. | ||||
In order to carry out incremental state synchronization, it is not | In order to carry out incremental State Synchronization, it is not | |||
necessary for a PCC to store a complete history of LSP Database | necessary for a PCC to store a complete history of LSP-DB change for | |||
change for all time, but remember the LSP state changes (including | all time, but remember the LSP state changes (including LSP | |||
LSP modification, setup and deletion), that the PCE did not get to | modification, setup, and deletion) that the PCE did not get to | |||
process during the session down. Note that, a PCC would be unaware | 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 | that a particular LSP report has been processed by the PCE before the | |||
session to PCE went down. So a PCC implementation MAY choose to | session to the PCE went down. So a PCC implementation MAY choose to | |||
store the LSP State Database Version Number with each LSP at the time | store the LSP-DB Version Number with each LSP at the time its status | |||
its status changed, so that when a session is re-established an | changed, so that when a session is re-established, an incremental | |||
incremental synchronization can be attempted based on the PCE's last | synchronization can be attempted based on the PCE's last LSP-DB | |||
LSP State Database Version Number. For an LSP that is deleted at the | Version Number. For an LSP that is deleted at the PCC, the PCC | |||
PCC, the PCC implementation would need to remember the deleted LSP in | implementation would need to remember the deleted LSP in some way to | |||
some way to make sure this could be reported as part of incremental | make sure this could be reported as part of incremental | |||
synchronization later. The PCC would discard this information based | synchronization later. The PCC would discard this information based | |||
on a local policy, or when it determines that this information is no | on a local policy or when it determines that this information is no | |||
longer needed with sufficient confidence. In the example shown in | longer needed with sufficient confidence. In the example shown in | |||
Figure 7, the PCC needs to store the LSP state changes that happened | Figure 7, the PCC needs to store the LSP state changes that happened | |||
between DB Version 43 to 46 and synchronizes these changes, when | between DB Versions 43 to 46 and synchronize these changes, when | |||
performing incremental LSP state update. | performing incremental LSP state update. | |||
If a PCC finds out it does not have sufficient information to | If a PCC finds out it does not have sufficient information to | |||
complete incremental synchronization after advertising incremental | complete incremental synchronization after advertising incremental | |||
LSP state synchronization capability, it MUST send a PCErr with | 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 | Error-type=20 and Error-value=5 'A PCC indicates to a PCE that it can | |||
not complete the state synchronization' (defined in | not complete the State Synchronization' (defined in [RFC8231]), and | |||
[I-D.ietf-pce-stateful-pce]) and terminate the session. The PCC | terminate the session. The PCC SHOULD re-establish the session with | |||
SHOULD re-establish the session with the D bit set to 0 in the OPEN | the D bit set to 0 in the OPEN message. | |||
message. | ||||
The other procedures and error checks remain unchanged from the full | The other procedures and error checks remain unchanged from the full | |||
state synchronization ([I-D.ietf-pce-stateful-pce]). | State Synchronization [RFC8231]. | |||
5. PCE-triggered Initial Synchronization | 5. PCE-Triggered Initial Synchronization | |||
5.1. Motivation | 5.1. Motivation | |||
In networks such as optical transport networks, the control channel | In networks such as optical transport networks, the control channel | |||
between network nodes can be realized through in-band overhead thus | between network nodes can be realized through in-band overhead, thus | |||
has limited bandwidth. With a stateful PCE connected to the network | it has limited bandwidth. With a stateful PCE connected to the | |||
via one network node, it is desirable to control the timing of PCC | network via one network node, it is desirable to control the timing | |||
state synchronization so as not to overload the low communication | of PCC State Synchronization so as not to overload the low | |||
channel available in the network during the initial synchronization | communication channel available in the network during the initial | |||
(be it incremental or full) when the session restarts , when there is | synchronization (be it incremental or full) when the session | |||
comparatively large amount of control information needing to be | restarts, when there is a comparatively large amount of control | |||
synchronized between the stateful PCE and the network. The method | information needing to be synchronized between the stateful PCE and | |||
proposed, i.e., allowing PCE to trigger the state synchronization, is | the network. The method proposed, i.e., allowing PCE to trigger the | |||
similar to the function proposed in Section 6 but is used in | State Synchronization, is similar to the function proposed in | |||
different scenarios and for different purposes. | Section 6 but is used in different scenarios and for different | |||
purposes. | ||||
5.2. PCE-triggered Initial State Synchronization Procedure | 5.2. PCE-Triggered Initial State Synchronization Procedure | |||
Support of PCE-triggered initial state synchronization is advertised | Support of PCE-triggered initial State Synchronization is advertised | |||
during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in | during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in | |||
the STATEFUL-PCE-CAPABILITY TLV (see Section 7). | the STATEFUL-PCE-CAPABILITY TLV (see Section 7). | |||
In order to allow a stateful PCE to control the LSP-DB | In order to allow a stateful PCE to control the LSP-DB | |||
synchronization after establishing a PCEP session, both PCEP speakers | synchronization after establishing a PCEP session, both PCEP speakers | |||
MUST set F bit to 1 in the OPEN message. If the LSP-DB-VERSION TLV | MUST set the F bit to 1 in the OPEN message. If the LSP-DB-VERSION | |||
is included by both PCEP speakers and the TLV value matches, the | 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 | State Synchronization can be skipped as described in Section 3.2. If | |||
the TLV is not included or the LSP-DB Version is mis-matched, the PCE | the TLV is not included or the LSP-DB Version is mismatched, the PCE | |||
can trigger the state synchronization process by sending a PCUpd | can trigger the State Synchronization process by sending a PCUpd | |||
message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD | message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD | |||
include an empty ERO (with no ERO sub-object and object length of 4) | include an empty Explicit Route Object (ERO) (with no ERO sub-object | |||
as its intended path and SHOULD NOT include the optional objects for | and object length of 4) as its intended path and SHOULD NOT include | |||
its attributes for any parameter update. The PCC MUST ignore such an | the optional objects for its attributes for any parameter update. | |||
update when the SYNC flag is set. If the TRIGGERED-INITIAL-SYNC | The PCC MUST ignore such an update when the SYNC flag is set. If the | |||
capability is not advertised by a PCE and the PCC receives a PCUpd | TRIGGERED-INITIAL-SYNC capability is not advertised by a PCE and the | |||
with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP- | PCC receives a PCUpd with the SYNC flag set to 1, the PCC MUST send a | |||
ID-number of the PCUpd, Error-Type 20 and Error-Value TBD4 (suggested | PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and | |||
value - 4) 'Attempt to trigger synchronization when the TRIGGERED- | Error-value=4 'Attempt to trigger a synchronization when the PCE | |||
SYNC capability has not been advertised' (see Section 8.1). If the | triggered synchronization capability has not been advertised' (see | |||
TRIGGERED-INITIAL-SYNC capability is advertised by a PCE and the PCC, | Section 8.1). If the TRIGGERED-INITIAL-SYNC capability is advertised | |||
the PCC MUST NOT trigger state synchronization on its own. If the | by a PCE and the PCC, the PCC MUST NOT trigger State Synchronization | |||
PCE receives a PCRpt message before the PCE has triggered the state | on its own. If the PCE receives a PCRpt message before the PCE has | |||
synchronization, the PCE MUST send a PCErr with Error-Type 20 and | triggered the State Synchronization, the PCE MUST send a PCErr with | |||
Error-Value TBD3 (suggested value - 3) 'Attempt to trigger | Error-type=20 and Error-value=3 'Attempt to trigger synchronization | |||
synchronization before PCE trigger' (see Section 8.1). | before PCE trigger' (see Section 8.1). | |||
In this way, the PCE can control the sequence of LSP synchronization | In this way, the PCE can control the sequence of LSP synchronization | |||
among all the PCCs that are re-establishing PCEP sessions with it. | among all the PCCs that are re-establishing PCEP sessions with it. | |||
When the capability of PCE control is enabled, only after a PCC | When the capability of PCE control is enabled, only after a PCC | |||
receives this message, it will start sending information to the PCE. | receives this message, it will start sending information to the PCE. | |||
This PCE-triggering capability can be applied to both full and | This PCE-triggering capability can be applied to both full and | |||
incremental state synchronization. If applied to the latter, the | incremental State Synchronization. If applied to the latter, the | |||
PCCs only send information that PCE does not possess, which is | PCCs only send information that PCE does not possess, which is | |||
inferred from the LSP-DB version information exchanged in the OPEN | inferred from the LSP-DB version information exchanged in the OPEN | |||
message (see Section 4.2 for detailed procedure). | message (see Section 4.2 for a detailed procedure). | |||
Once the initial state synchronization is triggered by the PCE, the | Once the initial State Synchronization is triggered by the PCE, the | |||
procedures and error checks remain unchanged | procedures and error checks remain unchanged [RFC8231]. | |||
([I-D.ietf-pce-stateful-pce]). | ||||
If a PCC implementation that does not implement this extension should | If a PCC implementation that does not implement this extension should | |||
not receive a PCUpd message to trigger state synchronization as per | not receive a PCUpd message to trigger State Synchronization as per | |||
the capability advertisement, but if it were to receive it, it will | the capability advertisement, but if it were to receive it, it will | |||
behave as per [I-D.ietf-pce-stateful-pce]. | behave as per [RFC8231]. | |||
6. PCE-triggered Re-synchronization | 6. PCE-Triggered Resynchronization | |||
6.1. Motivation | 6.1. Motivation | |||
The accuracy of the computations performed by the PCE is tied to the | The accuracy of the computations performed by the PCE is tied to the | |||
accuracy of the view the PCE has on the state of the LSPs. | accuracy of the view the PCE has on the state of the LSPs. | |||
Therefore, it can be beneficial to be able to re-synchronize this | Therefore, it can be beneficial to be able to resynchronize this | |||
state even after the session has been established. The PCE may use | state even after the session has been established. The PCE may use | |||
this approach to continuously sanity check its state against the | this approach to continuously sanity check its state against the | |||
network, or to recover from error conditions without having to tear | network or to recover from error conditions without having to tear | |||
down sessions. | down sessions. | |||
6.2. PCE-triggered State Re-synchronization Procedure | 6.2. PCE-Triggered State Resynchronization Procedure | |||
Support of PCE-triggered state re-synchronization is advertised by | Support of PCE-triggered state resynchronization is advertised by | |||
both PCEP speakers during session startup using the TRIGGERED-RESYNC | both PCEP speakers during session startup using the TRIGGERED-RESYNC | |||
(T) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7). The PCE | (T) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7). The PCE | |||
can choose to re-synchronize its entire LSP database or a single LSP. | can choose to resynchronize its entire LSP-DB or a single LSP. | |||
To trigger re-synchronization for an LSP, the PCE sends a Path | To trigger resynchronization for an LSP, the PCE sends a Path | |||
Computation State Update (PCUpd) for the LSP, with the SYNC flag in | 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 | 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 | 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 | 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 | 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 | the PCUpd message that triggered the resynchronization. If the PCC | |||
cannot find the LSP in its database, PCC MUST also set the R (remove) | cannot find the LSP in its database, PCC MUST also set the R (remove) | |||
flag [I-D.ietf-pce-stateful-pce] in the LSP object in the PCRpt | flag [RFC8231] in the LSP object in the PCRpt message. | |||
message. | ||||
The PCE can also trigger re-synchronization of the entire LSP | The PCE can also trigger resynchronization of the entire LSP-DB. The | |||
database. The PCE MUST first mark all LSPs in the LSP database that | PCE MUST first mark all LSPs in the LSP-DB that were previously | |||
were previously reported by the PCC as stale and then send a PCUpd | reported by the PCC as stale, and then send a PCUpd with an LSP | |||
with an LSP object containing a PLSP-ID of 0 and with the SYNC flag | object containing a PLSP-ID of 0 and with the SYNC flag set to 1. | |||
set to 1. The PCUpd message MUST include an empty ERO (with no ERO | The PCUpd message MUST include an empty ERO (with no ERO sub-object | |||
sub-object and object length of 4) as its intended path and SHOULD | and object length of 4) as its intended path and SHOULD NOT include | |||
NOT include the optional objects for its attributes for any parameter | the optional objects for its attributes for any parameter update. | |||
update. The PCC MUST ignore such update if the SYNC flag is set. | The PCC MUST ignore such update if the SYNC flag is set. This PCUpd | |||
This PCUpd message is the trigger for the PCC to enter the | message is the trigger for the PCC to enter the synchronization phase | |||
synchronization phase as described in [I-D.ietf-pce-stateful-pce] and | as described in [RFC8231] and start sending PCRpt messages. After | |||
start sending PCRpt messages. After the receipt of the end-of- | the receipt of the end-of-synchronization marker, the PCE will purge | |||
synchronization marker, the PCE will purge LSPs which were not | LSPs that were not refreshed. The SRP-ID-number of the PCUpd that | |||
refreshed. The SRP-ID-number of the PCUpd that triggered the re- | triggered the resynchronization SHOULD be included in each of the | |||
synchronization SHOULD be included in each of the PCRpt messages. If | PCRpt messages. If the PCC cannot resynchronize the entire LSP-DB, | |||
the PCC cannot re-synchronize the entire LSP database, the PCC MUST | the PCC MUST respond with a PCErr message with Error-type=20 and | |||
respond with PCErr message with Error-type 20 Error-value 5 'cannot | Error-value=5 'cannot complete the State Synchronization' [RFC8231], | |||
complete the state synchronization' [I-D.ietf-pce-stateful-pce], and | and it MAY terminate the session. The PCE MUST remove the stale mark | |||
MAY terminate the session. The PCE MUST remove the stale mark for | for the LSPs that were previously reported by the PCC. Based on the | |||
the LSP that were previously reported by the PCC. Based on the local | local policy, the PCE MAY reattempt synchronization at a later time. | |||
policy, the PCE MAY reattempt synchronization at a later time. | ||||
If the TRIGGERED-RESYNC capability is not advertised by a PCE and the | 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 | 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- | PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and | |||
Value TBD4 (suggested value - 4) 'Attempt to trigger synchronization | Error-value=4 'Attempt to trigger a synchronization when the PCE | |||
when the TRIGGERED-SYNC capability has not been advertised' (see | triggered synchronization capability has not been advertised' (see | |||
Section 8.1). | Section 8.1). | |||
Once the state re-synchronization is triggered by the PCE, the | Once the state resynchronization is triggered by the PCE, the | |||
procedures and error checks remain unchanged from the full state | procedures and error checks remain unchanged from the full state | |||
synchronization ([I-D.ietf-pce-stateful-pce]). This would also | synchronization [RFC8231]. This would also include the PCE | |||
include PCE triggering multiple state re-synchronization requests | triggering multiple state resynchronization requests while | |||
while synchronization is in progress. | synchronization is in progress. | |||
If a PCC implementation that does not implement this extension should | If a PCC implementation that does not implement this extension should | |||
not receive a PCUpd message to trigger re-synchronization as per the | not receive a PCUpd message to trigger resynchronization as per the | |||
capability advertisement, but if it were to receive it, it will | capability advertisement, but if it were to receive it, it will | |||
behave as per [I-D.ietf-pce-stateful-pce]. | behave as per [RFC8231]. | |||
7. Advertising Support of Synchronization Optimizations | 7. Advertising Support of Synchronization Optimizations | |||
Support for each of the optimizations described in this document | Support for each of the optimizations described in this document | |||
requires advertising the corresponding capabilities during session | requires advertising the corresponding capabilities during session | |||
establishment time. | establishment time. | |||
The STATEFUL-PCE-CAPABILITY TLV is defined in | The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. This | |||
[I-D.ietf-pce-stateful-pce]. This document defines following new | document defines the following new flags in the | |||
flags in the STATEFUL-PCE-CAPABILITY TLV: | STATEFUL-PCE-CAPABILITY TLV: | |||
Bit Description | Bit Description | |||
TBD9 (suggested value 30) S bit (INCLUDE-DB-VERSION) | ------------------------- --------------------------------- | |||
TBD10 (suggested value 27) D bit (DELTA-LSP-SYNC-CAPABILITY) | 30 S bit (INCLUDE-DB-VERSION) | |||
TBD11 (suggested value 26) F bit (TRIGGERED-INITIAL-SYNC) | 27 D bit (DELTA-LSP-SYNC-CAPABILITY) | |||
TBD12 (suggested value 28) T bit (TRIGGERED-RESYNC) | 26 F bit (TRIGGERED-INITIAL-SYNC) | |||
28 T bit (TRIGGERED-RESYNC) | ||||
If the S (INCLUDE-DB-VERSION) bit is set to 1 by both PCEP Speakers, | 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 | the PCC will include the LSP-DB-VERSION TLV in each LSP object. See | |||
Section 3.2 for details. | Section 3.2 for details. | |||
If the D (DELTA-LSP-SYNC-CAPABILITY) bit is set to 1 by a PCEP | If the D bit (DELTA-LSP-SYNC-CAPABILITY) is set to 1 by a PCEP | |||
speaker, it indicates that the PCEP speaker allows incremental | speaker, it indicates that the PCEP speaker allows incremental | |||
(delta) state synchronization. See Section 4.2 for details. | (delta) State Synchronization. See Section 4.2 for details. | |||
If the F (TRIGGERED-INITIAL-SYNC) bit is set to 1 by both PCEP | If the F bit (TRIGGERED-INITIAL-SYNC) is set to 1 by both PCEP | |||
Speakers, the PCE SHOULD trigger initial (first) state | speakers, the PCE SHOULD trigger initial (first) State | |||
synchronization. See Section 5.2 for details. | Synchronization. See Section 5.2 for details. | |||
If the T (TRIGGERED-RESYNC) bit is set to 1 by both PCEP Speakers, | If the T bit (TRIGGERED-RESYNC) is set to 1 by both PCEP speakers, | |||
the PCE can trigger re-synchronization of LSPs at any point in the | the PCE can trigger resynchronization of LSPs at any point in the | |||
life of the session. See Section 6.2 for details. | life of the session. See Section 6.2 for details. | |||
See Section 8.3 for IANA allocations. | See Section 8.3 for IANA allocations. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This document requests IANA actions to allocate code points for the | IANA has allocated code points for the protocol elements defined in | |||
protocol elements defined in this document. | this document. | |||
8.1. PCEP-Error Object | 8.1. PCEP-Error Object | |||
IANA is requested to make the following allocation in the "PCEP-ERROR | IANA has allocated the following values in the "PCEP-ERROR Object | |||
Object Error Types and Values" registry. | Error Types and Values" registry. | |||
Error-Type Meaning Reference | Error-Type Meaning Reference | |||
6 Mandatory Object missing [RFC5440] | ------------------------------------------------------------ | |||
Error-Value= TBD1(suggested This document | 6 Mandatory Object missing [RFC5440] | |||
value 12): LSP-DB-VERSION TLV | ||||
missing | Error-value | |||
20 LSP State synchronization [I-D.ietf-pce-stateful-pce] | 12: LSP-DB-VERSION TLV missing This document | |||
error | ||||
Error-Value= TBD2(suggested This document | 20 LSP State Synchronization Error [RFC8231] | |||
value 2): LSP Database version | ||||
mismatch. | Error-value | |||
Error-Value=TBD3(suggested This document | 2: LSP-DB version mismatch. This document | |||
value 3): Attempt to trigger | ||||
synchronization before PCE | 3: Attempt to trigger This document | |||
trigger. | synchronization before PCE | |||
Error-Value=TBD4(suggested This document | trigger. | |||
value 4): Attempt to trigger a | ||||
synchronization when the | 4: Attempt to trigger a This document | |||
PCE triggered synchronization | synchronization when the | |||
capability has not been | PCE triggered synchronization | |||
advertised. | capability has not been | |||
Error-Value=TBD6(suggested This document | advertised. | |||
value 6): Received an invalid | ||||
LSP DB Version Number. | 6: Received an invalid This document | |||
Error-Value=TBD7(suggested This document | LSP-DB Version Number. | |||
value 7): Received an invalid | ||||
Speaker Entity Identifier. | 7: Received an invalid This document | |||
Speaker Entity Identifier. | ||||
8.2. PCEP TLV Type Indicators | 8.2. PCEP TLV Type Indicators | |||
IANA is requested to make the following allocation in the "PCEP TLV | IANA has allocated the following values in the "PCEP TLV Type | |||
Type Indicators" registry. | Indicators" registry. | |||
Value Meaning Reference | Value Meaning Reference | |||
TBD5(suggested value 23) LSP-DB-VERSION This document | ------------------------- ----------------- ------------- | |||
TBD13(suggested value 24) SPEAKER-ENTITY-ID This document | 23 LSP-DB-VERSION This document | |||
24 SPEAKER-ENTITY-ID This document | ||||
8.3. STATEFUL-PCE-CAPABILITY TLV | 8.3. STATEFUL-PCE-CAPABILITY TLV | |||
The STATEFUL-PCE-CAPABILITY TLV is defined in | The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. The | |||
[I-D.ietf-pce-stateful-pce] and a registry is requested to be | "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry has been created to | |||
created to manage the flags in the TLV. IANA is requested to make | manage the flags in the TLV. IANA has allocated the following values | |||
the following allocation in the aforementioned registry. | in this registry. | |||
Bit Description Reference | Bit Description Reference | |||
TBD11 (suggested value 26) TRIGGERED-INITIAL-SYNC This document | -------------------------- -------------------------- ------------- | |||
TBD10 (suggested value 27) DELTA-LSP-SYNC-CAPABILITY This document | 26 TRIGGERED-INITIAL-SYNC This document | |||
TBD12 (suggested value 28) TRIGGERED-RESYNC This document | 27 DELTA-LSP-SYNC-CAPABILITY This document | |||
TBD9 (suggested value 30) INCLUDE-DB-VERSION This document | 28 TRIGGERED-RESYNC This document | |||
30 INCLUDE-DB-VERSION This document | ||||
9. Manageability Considerations | 9. Manageability Considerations | |||
All manageability requirements and considerations listed in [RFC5440] | All manageability requirements and considerations listed in [RFC5440] | |||
and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions | and [RFC8231] apply to PCEP protocol extensions defined in this | |||
defined in this document. In addition, requirements and | document. In addition, requirements and considerations listed in | |||
considerations listed in this section apply. | this section apply. | |||
9.1. Control of Function and Policy | 9.1. Control of Function and Policy | |||
A PCE or PCC implementation MUST allow configuring the state | A PCE or PCC implementation MUST allow configuring the State | |||
synchronization optimization capabilities as described in this | Synchronization optimization capabilities as described in this | |||
document. The implementation SHOULD also allow the operator to | document. The implementation SHOULD also allow the operator to | |||
configure the Speaker Entity Identifier ( Section 3.3.2). Further, | configure the Speaker Entity Identifier (Section 3.3.2). Further, | |||
the operator SHOULD be to be allowed to trigger the re- | the operator SHOULD be to be allowed to trigger the resynchronization | |||
synchronization procedures as per Section 6.2. | procedures as per Section 6.2. | |||
9.2. Information and Data Models | 9.2. Information and Data Models | |||
An implementation SHOULD allow the operator to view the stateful | An implementation SHOULD allow the operator to view the stateful | |||
capabilities advertised by each peer, and the current synchronization | capabilities advertised by each peer and the current synchronization | |||
status with each peer. To serve this purpose, the PCEP YANG module | status with each peer. To serve this purpose, the PCEP YANG module | |||
[I-D.ietf-pce-pcep-yang] can be extended to include advertised | [PCEP-YANG] can be extended to include advertised stateful | |||
stateful capabilities, and synchronization status. | capabilities and synchronization status. | |||
9.3. Liveness Detection and Monitoring | 9.3. Liveness Detection and Monitoring | |||
Mechanisms defined in this document do not imply any new liveness | Mechanisms defined in this document do not imply any new liveness | |||
detection and monitoring requirements in addition to those already | detection and monitoring requirements in addition to those already | |||
listed in [RFC5440]. | listed in [RFC5440]. | |||
9.4. Verify Correct Operations | 9.4. Verify Correct Operations | |||
Mechanisms defined in this document do not imply any new operation | Mechanisms defined in this document do not imply any new operation | |||
verification requirements in addition to those already listed in | verification requirements in addition to those already listed in | |||
[RFC5440] and [I-D.ietf-pce-stateful-pce]. | [RFC5440] and [RFC8231]. | |||
9.5. Requirements On Other Protocols | 9.5. Requirements on Other Protocols | |||
Mechanisms defined in this document do not imply any new requirements | Mechanisms defined in this document do not imply any new requirements | |||
on other protocols. | on other protocols. | |||
9.6. Impact On Network Operations | 9.6. Impact on Network Operations | |||
Mechanisms defined in [RFC5440] and [I-D.ietf-pce-stateful-pce] also | Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP | |||
apply to PCEP extensions defined in this document. | extensions defined in this document. | |||
The state synchronization optimizations described in this document | The State Synchronization optimizations described in this document | |||
can result in a reduction of the amount of data exchanged and the | 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 | time taken for a stateful PCE to be fully operational when a PCEP | |||
session is re-established. The ability to trigger re-synchronization | session is re-established. The ability to trigger resynchronization | |||
by the PCE can be utilized by the operator to sanity check its state | 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 | and recover from any mismatch in state without tearing down the | |||
session. | session. | |||
10. Security Considerations | 10. Security Considerations | |||
The security considerations listed in [I-D.ietf-pce-stateful-pce] | The security considerations listed in [RFC8231] apply to this | |||
apply to this document as well. However, this document also | document as well. However, this document also introduces some new | |||
introduces some new attack vectors. An attacker could spoof the | attack vectors. An attacker could spoof the SPEAKER-ENTITY-ID and | |||
SPEAKER-ENTITY-ID and pretend to be another PCEP speaker. An | pretend to be another PCEP speaker. An attacker may flood the PCC | |||
attacker may flood the PCC with triggered re-synchronization request | with triggered resynchronization requests at a rate that exceeds the | |||
at a rate which exceeds the PCC's ability to process them, either by | PCC's ability to process them by either spoofing messages or | |||
spoofing messages or by compromising the PCE itself. The PCC can | compromising the PCE itself. The PCC can respond with a PCErr | |||
respond with PCErr message as described in Section 6.2 and terminate | message as described in Section 6.2 and terminate the session. Thus, | |||
the session. Thus securing the PCEP session using Transport Layer | securing the PCEP session using Transport Layer Security (TLS) | |||
Security (TLS) [I-D.ietf-pce-pceps], as per the recommendations and | [PCEPS], as per the recommendations and best current practices in | |||
best current practices in [RFC7525], is RECOMMENDED. An | [RFC7525], is RECOMMENDED. An administrator could also expose the | |||
administrator could also expose the speaker entity id as part of the | Speaker Entity Identifier as part of the certificate, for the peer | |||
certificate, for the peer identity verification. | identity verification. | |||
11. Acknowledgments | ||||
We would like to thank Young Lee, Sergio Belotti and Cyril Margaria | ||||
for their comments and discussions. | ||||
Thanks to Jonathan Hardwick for being the document shepherd and | ||||
provide comments and guidance. | ||||
Thanks to Tomonori Takeda for Routing Area Directorate review. | ||||
Thanks to Adrian Farrel for TSVART review and providing detailed | ||||
comments and suggestions. | ||||
Thanks to Daniel Franke for SECDIR review. | ||||
Thanks to Alvaro Retana, Kathleen Moriarty, and Stephen Farrell for | ||||
comments during the IESG evaluation. | ||||
Thanks to Deborah Brungard for being the responsible AD and guiding | ||||
the authors as needed. | ||||
12. Contributors | ||||
Gang Xie | ||||
Huawei Technologies | ||||
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District | ||||
Shenzhen, Guangdong, 518129 | ||||
P.R. China | ||||
Email: xiegang09@huawei.com | ||||
13. References | ||||
13.1. Normative References | 11. References | |||
[I-D.ietf-pce-stateful-pce] | 11.1. Normative References | |||
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP | ||||
Extensions for Stateful PCE", draft-ietf-pce-stateful- | ||||
pce-18 (work in progress), December 2016. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation | [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation | |||
Element (PCE) Communication Protocol (PCEP)", RFC 5440, | Element (PCE) Communication Protocol (PCEP)", RFC 5440, | |||
DOI 10.17487/RFC5440, March 2009, | DOI 10.17487/RFC5440, March 2009, | |||
<http://www.rfc-editor.org/info/rfc5440>. | <https://www.rfc-editor.org/info/rfc5440>. | |||
13.2. Informative References | [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>. | ||||
11.2. Informative References | ||||
[PCEP-YANG] | ||||
Dhody, D., Hardwick, J., Beeram, V., and j. | ||||
jefftant@gmail.com, "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, | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
"Recommendations for Secure Use of Transport Layer | "Recommendations for Secure Use of Transport Layer | |||
Security (TLS) and Datagram Transport Layer Security | Security (TLS) and Datagram Transport Layer Security | |||
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
2015, <http://www.rfc-editor.org/info/rfc7525>. | 2015, <https://www.rfc-editor.org/info/rfc7525>. | |||
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a | [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a | |||
Stateful Path Computation Element (PCE)", RFC 8051, | Stateful Path Computation Element (PCE)", RFC 8051, | |||
DOI 10.17487/RFC8051, January 2017, | DOI 10.17487/RFC8051, January 2017, | |||
<http://www.rfc-editor.org/info/rfc8051>. | <https://www.rfc-editor.org/info/rfc8051>. | |||
[I-D.ietf-pce-pcep-yang] | Acknowledgments | |||
Dhody, D., Hardwick, J., Beeram, V., and j. | ||||
jefftant@gmail.com, "A YANG Data Model for Path | ||||
Computation Element Communications Protocol (PCEP)", | ||||
draft-ietf-pce-pcep-yang-02 (work in progress), March | ||||
2017. | ||||
[I-D.ietf-pce-pceps] | We would like to thank Young Lee, Sergio Belotti, and Cyril Margaria | |||
Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure | for their comments and discussions. | |||
Transport for PCEP", draft-ietf-pce-pceps-11 (work in | ||||
progress), January 2017. | Thanks to Jonathan Hardwick for being the document shepherd and | |||
providing comments and guidance. | ||||
Thanks to Tomonori Takeda for the Routing Area Directorate review. | ||||
Thanks to Adrian Farrel for the TSVART review and providing detailed | ||||
comments and suggestions. | ||||
Thanks to Daniel Franke for the SECDIR review. | ||||
Thanks to Alvaro Retana, Kathleen Moriarty, and Stephen Farrell for | ||||
comments during the IESG evaluation. | ||||
Thanks to Deborah Brungard for being the responsible AD and guiding | ||||
the authors as needed. | ||||
Contributors | ||||
Gang Xie | ||||
Huawei Technologies | ||||
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District | ||||
Shenzhen, Guangdong, 518129 | ||||
China | ||||
Email: xiegang09@huawei.com | ||||
Authors' Addresses | Authors' Addresses | |||
Edward Crabbe | Edward Crabbe | |||
Oracle | Oracle | |||
Email: edward.crabbe@gmail.com | ||||
EMail: edward.crabbe@gmail.com | ||||
Ina Minei | Ina Minei | |||
Google, Inc. | Google, Inc. | |||
1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
US | United States of America | |||
Email: inaminei@google.com | ||||
EMail: inaminei@google.com | ||||
Jan Medved | Jan Medved | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
170 West Tasman Dr. | 170 West Tasman Dr. | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
US | United States of America | |||
Email: jmedved@cisco.com | ||||
EMail: jmedved@cisco.com | ||||
Robert Varga | Robert Varga | |||
Pantheon Technologies SRO | Pantheon Technologies SRO | |||
Mlynske Nivy 56 | Mlynske Nivy 56 | |||
Bratislava 821 05 | Bratislava 821 05 | |||
Slovakia | Slovakia | |||
Email: robert.varga@pantheon.tech | ||||
EMail: robert.varga@pantheon.tech | ||||
Xian Zhang | Xian Zhang | |||
Huawei Technologies | Huawei Technologies | |||
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District | F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District | |||
Shenzhen, Guangdong 518129 | Shenzhen, Guangdong 518129 | |||
P.R.China | China | |||
Email: zhang.xian@huawei.com | ||||
EMail: zhang.xian@huawei.com | ||||
Dhruv Dhody | Dhruv Dhody | |||
Huawei Technologies | Huawei Technologies | |||
Divyashree Techno Park, Whitefield | Divyashree Techno Park, Whitefield | |||
Bangalore, Karnataka 560066 | Bangalore, Karnataka 560066 | |||
India | India | |||
Email: dhruv.ietf@gmail.com | ||||
EMail: dhruv.ietf@gmail.com | ||||
End of changes. 151 change blocks. | ||||
573 lines changed or deleted | 565 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |