draft-ietf-pce-stateful-sync-optimizations-00.txt   draft-ietf-pce-stateful-sync-optimizations-01.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Google, Inc. Internet-Draft I. Minei
Intended status: Standards Track J. Medved Intended status: Standards Track Google, Inc.
Expires: September 14, 2014 Cisco Systems, Inc. Expires: December 29, 2014 J. Medved
I. Minei Cisco Systems, Inc.
Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
X. Zhang X. Zhang
D. Dhody D. Dhody
Huawei Technologies Huawei Technologies
March 13, 2014 June 27, 2014
Optimizations of Label Switched Path State Synchronization Procedures Optimizations of Label Switched Path State Synchronization Procedures
for a Stateful PCE for a Stateful PCE
draft-ietf-pce-stateful-sync-optimizations-00 draft-ietf-pce-stateful-sync-optimizations-01
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
reliable state synchronization mechanism between the PCE and the reliable state synchronization mechanism between the PCE and the
skipping to change at page 2, line 12 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2014. This Internet-Draft will expire on December 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://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
skipping to change at page 2, line 39 skipping to change at page 2, line 37
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. State Synchronization Avoidance . . . . . . . . . . . . . . . 3 3. State Synchronization Avoidance . . . . . . . . . . . . . . . 3
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. State Synchronization Avoidance Procedure . . . . . . . . 4 3.2. State Synchronization Avoidance Procedure . . . . . . . . 4
3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 8 3.3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. LSP State Database Version Number TLV . . . . . . . . 8 3.3.1. LSP State Database Version Number TLV . . . . . . . . 8
3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 9 3.3.2. Speaker Entity Identifier TLV . . . . . . . . . . . . 9
4. PCE-triggered State Synchronization . . . . . . . . . . . . . 10 4. Incremental State Synchronization . . . . . . . . . . . . . . 10
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. PCE-triggered State Synchronization Procedure . . . . . . 10 4.2. Incremental Synchronization Procedure . . . . . . . . . . 11
5. Incremental State Synchronization . . . . . . . . . . . . . . 10 5. PCE-triggered Initial Synchronization . . . . . . . . . . . . 13
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Incremental Synchronization Procedure . . . . . . . . . . 12 5.2. PCE-triggered Initial State Synchronization Procedure . . 13
6. Advertising Support of Synchronization Optimizations . . . . 14 6. PCE-triggered Re-synchronization . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 6.2. PCE-triggered State Re-synchronization Procedure . . . . 14
7.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 16 7. Advertising Support of Synchronization Optimizations . . . . 15
7.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 Clients (PCCs) requests.
[I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
provide stateful control. A stateful PCE has access to not only the provide stateful control. A stateful PCE has access to not only the
information carried by the network's Interior Gateway Protocol (IGP), information carried by the network's Interior Gateway Protocol (IGP),
but also the set of active paths and their reserved resources for its but also the 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 reliable state synchronization interactions. This requires a reliable state synchronization
mechanism between the PCE and the network, PCE and PCC, and between mechanism between the PCE and the network, PCE and PCC, and between
cooperating PCEs. [I-D.ietf-pce-stateful-pce] describes the basic cooperating PCEs. [I-D.ietf-pce-stateful-pce] describes the basic
mechanism for state synchronization. This draft specifies mechanism for state synchronization. This draft specifies
optimizations for state synchronization and the correspoding PCEP optimizations for state synchronization and the corresponding PCEP
extensions. extensions.
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, PCEP Peer.
This document uses the following terms defined in This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce] : Delegation, Redelegation Timeout [I-D.ietf-pce-stateful-pce] : Delegation, Redelegation Timeout
Interval, LSP State Report, LSP Update Request, LSP State Database. Interval, LSP State Report, LSP Update Request, LSP State Database.
Within this document, when describing PCE-PCE communications, the Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
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 checkpoint-in-
time state replica of a PCC's LSP state in a stateful PCE. State time state replica of a PCC's LSP state in a stateful PCE. State
synchronization is performed immediately after the initialization synchronization is performed immediately after the initialization
phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic phase ([RFC5440]). [I-D.ietf-pce-stateful-pce] describes the basic
mechanism for state synchronization. mechanism for state synchronization.
skipping to change at page 4, line 38 skipping to change at page 4, line 36
the two values are used during LSP state (re)-synchronization, the the two values are used during LSP state (re)-synchronization, the
PCE speaker receiving this node should send back a PCErr with Error- PCE speaker receiving this node should send back a PCErr with Error-
type 20 Error-value 6 'Received an invalid LSP DB Version Number', type 20 Error-value 6 'Received an invalid LSP DB Version Number',
and close the PCEP session. Operations that trigger a change to the and close the PCEP session. Operations that trigger a change to the
local LSP state database include a change in the LSP operational local LSP state database 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.
State synchronization avoidance is advertised on a PCEP session State synchronization avoidance is advertised on a PCEP session
during session startup using the INCLUDE-DB-VERSION (IDB) bit in the during session startup using the INCLUDE-DB-VERSION (IDB) bit in the
capabilities TLV (see Section 6). The peer may move in the network, capabilities TLV (see Section 7). The peer may move in the network,
either physically or logically, which may cause its connectivity either physically or logically, which may cause its connectivity
details and transport-level identity (such as IP address) to change. details and transport-level identity (such as IP address) to change.
To ensure that a PCEP peer can recognize a previously connected peer To ensure that a PCEP peer can recognize a previously connected peer
even in face of such mobility, each PCEP peer includes the SPEAKER- even in face of such mobility, each PCEP peer includes the SPEAKER-
ENTITY-ID TLV described in Section 3.3.2 in the OPEN message. ENTITY-ID TLV described in Section 3.3.2 in the OPEN message.
If both PCEP speakers set the IDB flag in the OPEN object's STATEFUL- If both PCEP speakers set the IDB flag in the OPEN object's STATEFUL-
PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV
in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV in each LSP object of the PCRpt message. If the LSP-DB-VERSION TLV
is missing in a PCRpt message, the PCE will generate an error with is missing in a PCRpt message, the PCE will generate an error with
skipping to change at page 9, line 19 skipping to change at page 9, line 19
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
learn the speaker entity identifier on receiving the open message but
it MAY have already sent its open message without realizing that it
is a known PCEP peer. In such a case, either a full synchronization
is done or PCEP session is terminated. This may be a local policy
decision. The new IP address is associated with the speaker entity
identifier for future either way. In the latter case when PCEP
session is re-established, it would be correctly associated with
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=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Speaker Entity Identifier // // Speaker Entity Identifier //
skipping to change at page 10, line 5 skipping to change at page 10, line 15
identifier with the domain identifier of its residence, such as identifier with the domain identifier of its residence, such as
Autonomous System number, IGP area identifier, or similar. Autonomous System number, IGP area identifier, or similar.
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.
4. PCE-triggered State Synchronization 4. Incremental State Synchronization
4.1. Motivation
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.
Therefore, it can be beneficial to be able to resynchronize this
state even after the session has been established. The PCE may use
this approach to continuously sanity check its state against the
network, or to recover from error conditions without having to tear
down sessions.
4.2. PCE-triggered State Synchronization Procedure
Support of PCE-triggered state synchronization is advertised during
session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE-
CAPABILITY TLV (see Section 6). The PCE can choose to resynchronize
its entire LSP database or a single LSP.
To trigger resynchronization for an LSP, the PCE MUST first mark the
LSP as stale and then send a Path Computation State Update (PCUpd)
for it, with the SYNC flag in the LSP object set to 1. The PCE
SHOULD NOT include any parameter updates for the LSP, and the PCC
SHOULD ignore such updates if the SYNC flag is set. The PCC MUST
respond with a PCRpt message and SHOULD include the SRP-ID-number of
the PCUpd that triggered the resynchronization.
The PCE can also trigger resynchronization of the entire LSP
database. The PCE MUST first mark all LSPs in the LSP database that
were previously reported by the PCC as stale and then send a PCUpd
with an LSP object containing a PLSP-ID of 0 and with the SYNC flag
set to 1. This PCUpd message is the trigger for the PCC to enter the
synchronization phase as described in [I-D.ietf-pce-stateful-pce] and
start sending PCRpt messages. After the receipt of the end-of-
synchronization marker, the PCE will purge LSPs which were not
refreshed. The SRP-ID-number of the PCUpd that triggered the
resynchronization SHOULD be included in each of the PCRpt messages.
If the TRIGGERED-SYNC capability is not advertised and the PCC
receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr
with the SRP-ID-number of the PCUpd, error-type 20 and error-value
4.(see Section 7.1)
5. Incremental State Synchronization
[I-D.ietf-pce-stateful-pce] describes the LSP state synchronization [I-D.ietf-pce-stateful-pce] describes the LSP state synchronization
mechanism between PCCs and stateful PCEs. During the state mechanism between PCCs and stateful PCEs. During the state
synchronization, a PCC sends the information of all its LSPs (full synchronization, a PCC sends the information of all its LSPs (i.e.,
LSP-DB) to the stateful PCE. In order to save the state the full LSP-DB) to the stateful PCE. In order to reduce the state
synchronization overhead when there is a small number of LSP state synchronization overhead when there is a small number of LSP state
change in the network between PCEP session restart as well as change in the network between PCEP session restart, this section
avoiding overloading a PCE during state (re-)synchronization phase, proposes a mechanism for incremental (Delta) LSP Database (LSP-DB)
this section proposes a mechanism for incremental (Delta) LSP synchronization.
Database (LSP-DB) synchronization as well as allowing PCE to control
the timing of the LSP-DB synchronization process during incremental
syncronization.
5.1. Motivation 4.1. Motivation
According to [I-D.ietf-pce-stateful-pce] , if a PCE restarts and its According to [I-D.ietf-pce-stateful-pce] , if a PCE restarts and its
LSP-DB survived, PCCs with mismatched LSP State Database Version LSP-DB survived, PCCs with mismatched LSP State Database Version
Number will send all their LSPs information (full LSP-DB) to the Number will send all their LSPs information (full LSP-DB) to the
stateful PCE, even if only a small number of LSPs underwent state stateful PCE, even if only a small number of LSPs underwent state
change. It can take a long time and consume large communication change. It can take a long time and consume large communication
channel bandwidth. Moreover, the stateful PCE can get overloaded channel bandwidth.
with all the PCC performing full synchronization with it at the same
time.
Figure 6 shows an example of LSP state synchronization. Figure 6 shows an example of LSP state synchronization.
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
/ /
/ /
/ /
/ /
skipping to change at page 12, line 12 skipping to change at page 11, line 39
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 and there is a bandwidth communication channel is available and there is a
substantial number of LSPs in the network. Another disadvantage of substantial number of LSPs in the network. Another disadvantage of
full LSP synchronization is that it is a waste of communication full LSP synchronization is that it is a waste of communication
bandwidth to perform full LSP synchronization given the fact that the bandwidth to perform full LSP synchronization given the fact that the
number of LSP changes can be small during the time when PCEP session number of LSP changes can be small during the time when PCEP session
is down. is down.
An incremental (Delta) LSP Database (LSP-DB) state synchronization is An incremental (Delta) LSP Database (LSP-DB) state synchronization is
described in this section, where only the LSPs underwent state change described in this section, where only the LSPs underwent state change
are synchronized between the session restart. This may include new/ are synchronized between the session restart. This may include
modified/deleted LSPs. Furthermore, to avoid overloading the PCE, new/modified/deleted LSPs.
the proposed method enable a stateful PCE to trigger the LSP
synchronization (similar to Section 4).
PCEP extensions for stateful PCEs to perform LSP synchronization PCEP extensions for stateful PCEs to perform LSP synchronization
SHOULD allow: SHOULD allow: incremental LSP state synchronization between session
restarts. Note this does not exclude the need for a stateful PCE to
o Incremental LSP state synchronization between session restarts. request a full LSP DB synchronization.
Note this does not exclude the need for a stateful PCE to request
a full LSP DB synchronization.
o A stateful PCE to control the timing of PCC synchronizing its LSP
state with the PCE during incremental synchronisation.
5.2. Incremental Synchronization Procedure 4.2. Incremental Synchronization Procedure
[I-D.ietf-pce-stateful-pce] describes state synchronization and [I-D.ietf-pce-stateful-pce] describes state synchronization and
Section 3 describes state synchronization avoidance by using LSP-DB- Section 3 describes state synchronization avoidance by using LSP-DB-
VERSION TLV in its OPEN object. This section extends this idea to VERSION TLV in its OPEN object. This section extends this idea to
only synchronize the delta (changes) in case of version mismatch as only synchronize the delta (changes) in case of version mismatch.
well as to allow a stateful PCE to control the timing of this
process.
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. Instead of dumping full LSP-DB to PCE again, the synchronization. Instead of dumping full LSP-DB to the stateful PCE
PCC synchronizes the delta (changes) as described in Figure 7 when again, the PCC synchronizes the delta (changes) as described in
DELTA-LSP-SYNC-CAPABILITY (D flag) is set to 1 by both PCC and PCE Figure 7 when DELTA-LSP-SYNC-CAPABILITY (D flag) is set to 1 by both
(see Section 6). Other combinations of D flag setting by PCC and PCE PCC and PCE (see Section 7). Other combinations of D flag setting by
result in full LSP-DB synchronization procedure as described in PCC and PCE result in full LSP-DB synchronization procedure as
[I-D.ietf-pce-stateful-pce]. If a PCC has to force full LSP DB described in [I-D.ietf-pce-stateful-pce]. If a PCC has to force full
synchronization due to reasons including but not limited: (1) local LSP DB synchronization due to reasons including but not limited: (1)
policy configured at the PCC; (2) no sufficient LSP state caches for local policy configured at the PCC; (2) no sufficient LSP state
incremental update, the PCC can set the D flag to 0. Note a PCC may caches for incremental update, the PCC can set the D flag to 0. Note
have to bring down the current session and force a full LSPDB a PCC may have to bring down the current session and force a full
synchronization with D flag set to 0 in the subsequent open message. LSP-DB synchronization with D flag set to 0 in the subsequent open
message.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|--Open--, | |--Open--, |
| DBv=46 \ ,---Open--| | DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| D=1 \/ IDB=1 | | T=1 \/ IDB=1 |
| T=1 /\ D=1 | | /\ T=1 |
| / \ T=1 | | / \ |
| / `-------->| (Expect Delta sync) | / `-------->| (Expect Delta sync)
(Do sync)|<--------` | (DONOT Purge LSP (Do sync)|<--------` | (DONOT Purge LSP
(Delta) | | State) (Delta) | | State)
(Wait for PCE to | | | |
trigger LSP state | | (Delta Sync starts) |--PCRpt,DBv=46,SYNC=1-->|
sync) | |
|<----PCUpd, SYNC=1------| (ask for LSP Sync,
| | PLSP-ID =0)
(Delta Sync starts) |--PCRpt,DBv=43,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
A stateful PCE MAY choose to control the LSP-DB synchronization
process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to
indicate this (as described in Section 4). If the LSP-DB Version is
mis-matched, it can send a PCUpd message with PLSP-ID = 0 and SYNC =
1 in order to trigger the LSP-DB synchronization process. In this
way, the PCE can control the sequence of LSP synchronization among
all the PCCs that are re-establishing PCEP sessions with it. When
the capability of PCE control is enabled, only after a PCC receives
this message, it will start sending information that PCE does not
possess, which is inferred from the LSP-DB version information
exchanged in the OPEN message. Note that the PCE should not mark the
existing LSPs as stale for incremental state synchronisation
procedure.
As per Section 3, the LSP State Database Version Number is As per Section 3, the LSP State Database Version Number is
incremented each time a change is made to the PCC's local LSP State incremented each time a change is made to the PCC's local LSP State
Database. Each LSP is associated with the DB version at the time of Database. Each LSP is associated with the DB version at the time of
its state change. This is needed to determine which LSP and what its state change. This is needed to determine which LSP and what
information needs to be synchronized in incremental state information needs to be synchronized in incremental state
synchronization. synchronization.
It is not necessary for a PCC to store a complete history of LSP It is not necessary for a PCC to store a complete history of LSP
Database change, but rather remember the LSP state changes (including Database change, but rather remember the LSP state changes (including
LSP modification, setup and deletion) that happend between the PCEP LSP modification, setup and deletion) that happend between the PCEP
skipping to change at page 14, line 30 skipping to change at page 13, line 28
Figure 7, the PCC needs to store the LSP state changes that happend Figure 7, the PCC needs to store the LSP state changes that happend
between DB Version 43 to 46 and synchronizes these changes only when between DB Version 43 to 46 and synchronizes these changes only when
performing incremental LSP state update. So a PCC needs to remember performing incremental LSP state update. So a PCC needs to remember
the LSP state changes that happened when an existing PCEP session to the LSP state changes that happened when an existing PCEP session to
a stateful PCE goes down in the hope of doing incremental a stateful PCE goes down in the hope of doing incremental
synchronisation when the session is re-established. synchronisation when the session is re-established.
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 synchronisation after advertising incremental complete incremental synchronisation 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(see Section 7.1) and terminate the error-type 20 and error-value 5(see Section 8.1) and terminate the
session. session.
6. Advertising Support of Synchronization Optimizations 5. PCE-triggered Initial Synchronization
5.1. Motivation
In networks such as optical transport networks, the control channel
between network nodes can be realized through in-band overhead thus
has limited bandwidth. With a stateful PCE connected to the network
via one network node, it is desirable to control the timing of PCC
state synchronization so as not to overload the low communication
channel available in the network during the initial synchronization
(be it incremental or full) when the session restarts , when there is
comparatively large amount of control information needing to be
synchronized between the stateful PCE and the network. The method
proposed, i.e., allowing PCE to trigger the state synchronization, is
similar to the function proposed in Section 6 but is used in
different scenarios and for different purposes.
5.2. PCE-triggered Initial State Synchronization Procedure
Support of PCE-triggered state synchronization is advertised during
session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE-
CAPABILITY TLV (see Section 7).
A stateful PCE MAY choose to control the LSP-DB synchronization
process. To allow PCE to do so, PCEP speakers MUST set T bit to 1 to
indicate this (as described in Section 6). If the LSP-DB Version is
mis-matched, it can send a PCUpd message with PLSP-ID = 0 and SYNC =
1 in order to trigger the LSP-DB synchronization process. In this
way, the PCE can control the sequence of LSP synchronization among
all the PCCs that are re-establishing PCEP sessions with it. When
the capability of PCE control is enabled, only after a PCC receives
this message, it will start sending information to the PCE. This
PCE-triggering capability can be applied to both full and incremental
state synchronization. If applied to the later, the PCCs only send
information that PCE does not possess, which is inferred from the
LSP-DB version information exchanged in the OPEN message (see
Section 4.2 for detailed procedure).
6. PCE-triggered Re-synchronization
6.1. Motivation
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.
Therefore, it can be beneficial to be able to resynchronize this
state even after the session has been established. The PCE may use
this approach to continuously sanity check its state against the
network, or to recover from error conditions without having to tear
down sessions.
6.2. PCE-triggered State Re-synchronization Procedure
Support of PCE-triggered state synchronization is advertised during
session startup using the TRIGGERED-SYNC (T) bit in the STATEFUL-PCE-
CAPABILITY TLV (see Section 7). The PCE can choose to resynchronize
its entire LSP database or a single LSP.
To trigger resynchronization for an LSP, the PCE MUST first mark the
LSP as stale and then send a Path Computation State Update (PCUpd)
for it, with the SYNC flag in the LSP object set to 1. The PCE
SHOULD NOT include any parameter updates for the LSP, and the PCC
SHOULD ignore such updates if the SYNC flag is set. The PCC MUST
respond with a PCRpt message and SHOULD include the SRP-ID-number of
the PCUpd that triggered the resynchronization.
The PCE can also trigger resynchronization of the entire LSP
database. The PCE MUST first mark all LSPs in the LSP database that
were previously reported by the PCC as stale and then send a PCUpd
with an LSP object containing a PLSP-ID of 0 and with the SYNC flag
set to 1. This PCUpd message is the trigger for the PCC to enter the
synchronization phase as described in [I-D.ietf-pce-stateful-pce] and
start sending PCRpt messages. After the receipt of the end-of-
synchronization marker, the PCE will purge LSPs which were not
refreshed. The SRP-ID-number of the PCUpd that triggered the
resynchronization SHOULD be included in each of the PCRpt messages.
If the TRIGGERED-SYNC capability is not advertised and the PCC
receives a PCUpd with the SYNC flag set to 1, it MUST send a PCErr
with the SRP-ID-number of the PCUpd, error-type 20 and error-value
4.(see Section 8.1)
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.
New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in
[I-D.ietf-pce-stateful-pce]. Its format is shown in the following [I-D.ietf-pce-stateful-pce]. Its format is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
skipping to change at page 15, line 13 skipping to change at page 15, line 42
Figure 8: STATEFUL-PCE-CAPABILITY TLV Format Figure 8: STATEFUL-PCE-CAPABILITY TLV Format
The value comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): defined in U (LSP-UPDATE-CAPABILITY - 1 bit): defined in
[I-D.ietf-pce-stateful-pce]. [I-D.ietf-pce-stateful-pce].
S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers,
the PCC will include the LSP-DB-VERSION TLV in each LSP Object. the PCC will include the LSP-DB-VERSION TLV in each LSP Object.
I (LSP-INSTANTIATION-CAPABILITY - 1 bit): defined in [I-D.crabbe-pce I (LSP-INSTANTIATION-CAPABILITY - 1 bit): defined in [I-D.ietf-pce-p
-pce-initiated-lsp]. ce-initiated-lsp].
T (TRIGGERED-SYNC - 1 bit): if set to 1 by both PCEP Speakers, the T (TRIGGERED-SYNC - 1 bit): if set to 1 by both PCEP Speakers, the
PCE can trigger synchronization of LSPs at any point in the life PCE can trigger (re)-synchronization of LSPs at any point in the
of the session. life of the session.
D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP D (DELTA-LSP-SYNC-CAPABILITY - 1 bit): if set to 1 by a PCEP
speaker, it indicates that the PCEP speaker allows incremental speaker, it indicates that the PCEP speaker allows incremental
state synchronization. state synchronization.
7. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. Values shown here are protocol elements defined in this document.
suggested for use by IANA.
7.1. PCEP-Error Object
This document defines new Error-Value values for the LSP state
synchronization error defined in [I-D.ietf-pce-stateful-pce].
Error-Type Meaning
6 Mandatory Object missing
Error-value=12: LSP-DB-VERSION TLV missing 8.1. PCEP-Error Object
20 LSP State synchronization error
Error-value=2: LSP Database version mismatch. IANA is requested to make the following allocation in the "PCEP-ERROR
Error-value=3: The LSP-DB-VERSION TLV Missing when Object Error Types and Values" registry.
state synchronization avoidance is
enabled.
Error-value=4: Attempt to trigger a synchronization
when the TRIGGERED-SYNC capability has
not been advertised.
Error-value=5: No sufficient LSP change information
for incremental LSP state
synchronization.
Error-value=6: Received an invalid LSP DB Version Error-Type Meaning Reference
Number 6 Mandatory Object missing [RFC5440]
Error-value= TBD(suggested This document
value 12): LSP-DB-VERSION TLV
missing
20 LSP State synchronization [I-D.ietf-pce-stateful-pce]
error
Error-value= TBD(suggested This document
value 2): LSP Database version
mismatch.
Error-value=TBD(suggested This document
value 3): The LSP-DB-VERSION
TLV Missing when state
synchronization avoidance is
enabled.
Error-value=TBD(suggested This document
value 4): Attempt to trigger a
synchronization when the
TRIGGERED-SYNC capability has
not been advertised.
Error-value=TBD(suggested This document
value 6): No sufficient LSP
change information for
incremental LSP state
synchronization.
Error-value=TBD(suggested This document
value 7): Received an invalid
LSP DB Version Number
7.2. PCEP TLV Type Indicators 8.2. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
23 LSP-DB-VERSION This document TBD(suggested value LSP-DB-VERSION This document
24 SPEAKER-ENTITY-ID This document 23)
TBD(suggested value SPEAKER-ENTITY-ID This document
24)
7.3. STATEFUL-PCE-CAPABILITY TLV 8.3. STATEFUL-PCE-CAPABILITY TLV
The following values are defined in this document for the Flags field The following values are defined in this document for the Flags field
in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object: in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object:
Bit Description Reference Bit Description Reference
28 DELTA-LSP-SYNC-CAPABILITY This document TBD(suggested value DELTA-LSP-SYNC-CAPABILITY This document
29 TRIGGERED-SYNC This document 28)
30 INCLUDE-DB-VERSION This document TBD(suggested value TRIGGERED-SYNC This document
29)
TBD(suggested value INCLUDE-DB-VERSION This document
30)
8. Security Considerations 9. Security Considerations
The security considerations listed in [I-D.ietf-pce-stateful-pce] The security considerations listed in [I-D.ietf-pce-stateful-pce]
apply to this document as well. apply to this document as well.
9. Acknowledgements 10. Acknowledgements
We would like to thank Young Lee for his contributions. We would like to thank Young Lee and Jonathan Hardwick for their
comments and discussions.
10. Contributors 11. Contributors
Gang Xie Gang Xie
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 P.R. China
Email: xiegang09@huawei.com Email: xiegang09@huawei.com
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-08 (work in progress), February 2014. pce-09 (work in progress), June 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March (PCE) Communication Protocol (PCEP)", RFC 5440, March
2009. 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 12.2. Informative References
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
11.2. Informative References
[I-D.crabbe-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in Model", draft-ietf-pce-pce-initiated-lsp-01 (work in
progress), October 2013. progress), June 2014.
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: edc@google.com Email: edc@google.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
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 US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.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.sk Email: robert.varga@pantheon.sk
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 P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
 End of changes. 52 change blocks. 
201 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/