Skip to main content

Optimizations of State Synchronization Procedures for Stateful PCE
draft-minei-pce-stateful-sync-optimizations-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Edward Crabbe , Jan Medved , Ina Minei , Robert Varga , Xian Zhang , Dhruv Dhody
Last updated 2013-10-08
Replaced by draft-ietf-pce-stateful-sync-optimizations, RFC 8232
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-minei-pce-stateful-sync-optimizations-00
PCE Working Group                                              E. Crabbe
Internet-Draft                                              Google, Inc.
Intended status: Standards Track                               J. Medved
Expires: April 11, 2014                              Cisco Systems, Inc.
                                                                I. Minei
                                                  Juniper Networks, Inc.
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                                X. Zhang
                                                                D. Dhody
                                                     Huawei Technologies
                                                         October 8, 2013

   Optimizations of State Synchronization Procedures for Stateful PCE
             draft-minei-pce-stateful-sync-optimizations-00

Abstract

   A stateful Path Computation Element (PCE) has access to not only the
   information carried by the network's IGP, but also to the set of
   active paths and their reserved resources for its computations.  The
   additional state allows the PCE to compute constrained paths while
   considering individual LSPs and their interactions.  This requires
   reliable state synchronization mechanisms between the PCE and the
   network, PCE and path computation clients (PCCs), and between
   cooperating PCEs.  The basic mechanism for state synchronization is
   part of the Stateful PCE specification.  This draft specifies
   optimizations related to state synchronization procedures.

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

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any

Crabbe, et al.           Expires April 11, 2014                 [Page 1]
Internet-Draft   Optimizations of state synchronization     October 2013

   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 11, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Crabbe, et al.           Expires April 11, 2014                 [Page 2]
Internet-Draft   Optimizations of state synchronization     October 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  State synchronization avoidance  . . . . . . . . . . . . . . .  4
     3.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  State Synchronization Avoidance procedures . . . . . . . .  5
     3.3.  LSP State Database Version Number TLV  . . . . . . . . . .  9
       3.3.1.  Use of the LSP-DB-VERSION TLV in the OPEN object . . . 10
       3.3.2.  Use of the LSP-DB-VERSION TLV in the LSP object  . . . 10
     3.4.  Speaker Entity Identifier TLV  . . . . . . . . . . . . . . 10
   4.  PCE-triggered State Synchronization  . . . . . . . . . . . . . 11
     4.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  PCE-triggered State Synchronization Procedures . . . . . . 11
   5.  Incremental State Synchronization  . . . . . . . . . . . . . . 12
     5.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Incremental synchronization procedures . . . . . . . . . . 14
   6.  Advertising support of the synchronization optimizations . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  PCEP-Error Object  . . . . . . . . . . . . . . . . . . . . 17
     7.2.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 17
     7.3.  STATEFUL-PCE-CAPABILITY TLV  . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Crabbe, et al.           Expires April 11, 2014                 [Page 3]
Internet-Draft   Optimizations of state synchronization     October 2013

1.  Introduction

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   [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
   information carried by the network's IGP, but also to the set of
   active paths and their reserved resources for its computations.  The
   additional state allows the PCE to compute constrained paths while
   considering individual LSPs and their interactions.  This requires
   reliable state synchronization mechanisms between the PCE and the
   network, PCE and PCC, and between cooperating PCEs.
   [I-D.ietf-pce-stateful-pce] describes the basic mechanism for state
   synchronization.  This draft specifies optimizations for state
   synchronization.

2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce] : Passive Stateful PCE, Active Stateful
   PCE, Delegation, Delegation Timeout Interval, LSP State Report, LSP
   Update Request, LSP Priority, LSP State Database, Revocation.

   Within this document, when describing PCE-PCE communications, the
   requesting PCE fills the role of a PCC.  This provides a saving in
   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.1.  Motivation

   The purpose of State Synchronization is to provide a checkpoint-in-
   time state replica of a PCC's LSP state in a PCE.  State
   Synchronization is performed immediately after the Initialization
   phase ([RFC5440]).  [I-D.ietf-pce-stateful-pce] describes the basic
   mechanism for state synchronization.

   State synchronization is not always necessary following a PCEP

Crabbe, et al.           Expires April 11, 2014                 [Page 4]
Internet-Draft   Optimizations of state synchronization     October 2013

   session restart.  If the state of both PCEP peers did not change, the
   synchronization phase may be skipped.  This can result in significant
   savings in both control-plane data exchanged and the time it takes
   for the session to become fully operational.

3.2.  State Synchronization Avoidance procedures

   State Synchronization MAY be skipped following a PCEP session restart
   if the state of both PCEP peers did not change during the period
   prior to session re-initialization.  To be able to make this
   determination, state must be exchanged and maintained by both PCE and
   PCC during normal operation.  This is accomplished by keeping track
   of the changes to the LSP State Database, using a version tracking
   field called the LSP State Database Version Number.

   The LSP State Database Version Number is an unsigned 64-bit value
   that MUST be incremented by 1 for each successive change in the LSP
   state database.  The LSP State Database Version Number MUST start at
   1 and may wrap around.  Values 0 and 0xFFFFFFFFFFFFFFFF are reserved.
   The PCC is the owner of the LSP State Database Version Number, which
   is incremented each time a change is made to the PCC's local LSP
   State Database.  Operations that trigger a change to the local LSP
   State database include a change in the LSP operational state,
   delegation of an LSP, removal or addition of an LSP or change in any
   of the LSP attributes that would trigger a report to the PCE.  When
   State Synchronization avoidance is enabled on a PCEP session, a PCC
   includes the LSP-DB-VERSION TLV in the LSP Object on each LSP State
   Report.  The LSP-DB-VERSION TLV contains a PCC's LSP State Database
   version.

   State Synchronization Avoidance is advertised on a PCEP session
   during session startup using the INCLUDE-DB-VERSION bit in the
   capabilities TLV (see Section 6).  The peer may move in the network,
   either physically or logically, which may cause its connectivity
   details and transport-level identity (such as IP address) to change.
   To ensure that a PCEP peer can recognize a previously connected peer
   even in face of such mobility, each PCEP peer includes the SPEAKER-
   ENTITY-ID TLV described in Section 3.4 in the OPEN message.

   If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN
   object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the
   LSP-DB-VERSION TLV in each LSP Object.  The TLV will contain the
   PCC's latest LSP State Database Version Number.

   If a PCE's LSP State Database survived the restart of a PCEP session,
   the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and
   the TLV will contain the last LSP State Database Version Number
   received on an LSP State Report from the PCC in a previous PCEP

Crabbe, et al.           Expires April 11, 2014                 [Page 5]
Internet-Draft   Optimizations of state synchronization     October 2013

   session.  If a PCC's LSP State Database survived the restart of a
   PCEP session, the PCC will include the LSP-DB-VERSION TLV in its OPEN
   object and the TLV will contain the latest LSP State Database Version
   Number sent on an LSP State Report from the PCC in the previous PCEP
   session.  If a PCEP Speaker's LSP State Database did not survive the
   restart of a PCEP session, the PCEP Speaker MUST NOT include the LSP-
   DB-VERSION TLV in the OPEN Object.

   If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN
   Object and the TLV values match, the PCC MAY skip State
   Synchronization.  Otherwise, the PCC MUST perform State
   Synchronization.  If the PCC attempts to skip State Synchronization
   (i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC),
   the PCE MUST send back a PCError with Error-type 20 Error-value 2
   'LSP Database version mismatch', and close the PCEP session.

   If state synchronization is required, then prior to completing the
   Initialization phase, the PCE MUST mark any LSPs in the LSP database
   that were previously reported by the PCC as stale.  When the PCC
   reports an LSP during state synchronization, if the LSP already
   exists in the LSP database, the PCE MUST update the LSP database and
   clear the stale marker from the LSP.  When it has finished state
   synchronization, the PCC MUST immediately send an end of
   synchronization marker.  The end of synchronization marker is a PCRpt
   message with an LSP object containing a PLSP-ID of 0 and with the
   SYNC flag set to 0 ([I-D.ietf-pce-stateful-pce]).  The LSP-DB-VERSION
   TLV MUST be included and contain the PCC's latest LSP State Database
   Version Number.  On receiving this state report, the 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
   the LSP-DB-VERSION TLV in its OPEN object.

   Figure 1 shows an example sequence where State Synchronization is
   skipped.  In the figure, IDB stands for INCLUDE-DB-VERSION.

Crabbe, et al.           Expires April 11, 2014                 [Page 6]
Internet-Draft   Optimizations of state synchronization     October 2013

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |--Open--,               |
                       |  DBv=42 \    ,---Open--|
                       |   IDB=1  \  /   DBv=42 |
                       |           \/     IDB=1 |
                       |           /\           |
                       |          /   `-------->| (OK to skip sync)
           (Skip sync) |<--------`              |
                       |            .           |
                       |            .           |
                       |            .           |
                       |                        |
                       |--PCRpt,DBv=43,SYNC=0-->| (Regular
                       |                        |  LSP State Report)
                       |--PCRpt,DBv=44,SYNC=0-->| (Regular
                       |                        |  LSP State Report)
                       |--PCRpt,DBv=45,SYNC=0-->|
                       |                        |

                  Figure 1: State Synchronization skipped

   Figure 2 shows an example sequence where State Synchronization is
   performed due to LSP State Database version mismatch during the PCEP
   session setup.  Note that the same State Synchronization sequence
   would happen if either the PCC or the PCE would not include the LSP-
   DB-VERSION TLV in their respective Open messages.  In the figure, IDB
   stands for INCLUDE-DB-VERSION.

Crabbe, et al.           Expires April 11, 2014                 [Page 7]
Internet-Draft   Optimizations of state synchronization     October 2013

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |--Open--,               |
                       |  DBv=46 \    ,---Open--|
                       |   IDB=1  \  /   DBv=42 |
                       |           \/     IDB=1 |
                       |           /\           |
                       |          /   `-------->| (Expect sync)
             (Do sync) |<--------`              |
                       |                        |
                       |--PCRpt,DBv=46,SYNC=1-->| (Sync start)
                       |            .           |
                       |            .           |
                       |            .           |
                       |--PCRpt,DBv=46,SYNC=1-->| (Sync done)
                       |            .           |(Purge LSP State)
                       |            .           |
                       |            .           |
                       |--PCRpt,DBv=47,SYNC=0-->| (Regular
                       |                        |  LSP State Report)
                       |--PCRpt,DBv=48,SYNC=0-->| (Regular
                       |                        |  LSP State Report)
                       |--PCRpt,DBv=49,SYNC=0-->|
                       |                        |

                 Figure 2: State Synchronization performed

   Figure 3 shows an example sequence where State Synchronization is
   skipped, but because one or both PCEP Speakers set the INCLUDE-DB-
   VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the
   PCE.  If the current PCEP session restarts, the PCEP Speakers will
   have to perform State Synchronization, since the PCE will not know
   the PCC's latest LSP State Database Version Number.  In the figure
   IDB stands for INCLUDE-DB-VERSION.

Crabbe, et al.           Expires April 11, 2014                 [Page 8]
Internet-Draft   Optimizations of state synchronization     October 2013

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |--Open--,               |
                       |  DBv=42 \    ,---Open--|
                       |   IDB=0  \  /   DBv=42 |
                       |           \/     IDB=0 |
                       |           /\           |
                       |          /   `-------->| (OK to skip sync)
           (Skip sync) |<--------`              |
                       |            .           |
                       |            .           |
                       |            .           |
                       |------PCRpt,SYNC=0----->| (Regular
                       |                        |  LSP State Report)
                       |------PCRpt,SYNC=0----->| (Regular
                       |                        |  LSP State Report)
                       |------PCRpt,SYNC=0----->|
                       |                        |

   Figure 3: State Synchronization skipped, no LSP-DB-VERSION TLVs sent
                                 from PCC

3.3.  LSP State Database Version Number TLV

   The LSP State Database Version Number (LSP-DB-VERSION) TLV is an
   optional TLV that MAY be included in the OPEN object and the LSP
   object.

   The format of the LSP-DB-VERSION TLV is shown in the following
   figure:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |            Length=8           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      LSP State DB Version Number              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: LSP-DB-VERSION TLV format

   The type of the TLV is [TBD] and it has a fixed length of 8 octets.
   The value contains a 64-bit unsigned integer.

Crabbe, et al.           Expires April 11, 2014                 [Page 9]
Internet-Draft   Optimizations of state synchronization     October 2013

3.3.1.  Use of the LSP-DB-VERSION TLV in the OPEN object

   The LSP-DB-VERSION_TLV is included as an optional TLV in the OPEN
   object when a PCEP Speaker wishes to determine if State
   Synchronization can be skipped when a PCEP session is restarted.  If
   sent from a PCE, the TLV contains the local LSP State Database
   Version Number from the last valid LSP State Report received from a
   PCC.  If sent from a PCC, the TLV contains the PCC's local LSP State
   Database Version Number, which is incremented each time the LSP State
   Database is updated.

3.3.2.  Use of the LSP-DB-VERSION TLV in the LSP object

   The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP
   object.

   If State Synchronization Avoidance has been enabled on a PCEP session
   (as described in Section 3.2), a PCC MUST include the LSP-DB-VERSION
   TLV in each LSP Object sent out on the session.  If the TLV is
   missing, the PCE will generate an error with error-type 6 (mandatory
   object missing) and Error Value 12 (LSP-DB-VERSION TLV missing) and
   close the session.  If State Synchronization Avoidance has not been
   enabled on a PCEP session, the PCC SHOULD NOT include the LSP-DB-
   VERSION TLV in the LSP Object and the PCE SHOULD ignore it were it to
   receive one.

   Since a PCE does not make changes to the LSP State Database Version
   Number, a PCC should never encounter this TLV in a message from the
   PCE (other than the OPEN message).  A PCC SHOULD ignore the LSP-DB-
   VERSION TLV, were it to receive one from a PCE.

   If State Synchronization Avoidance is enabled, a PCC MUST increment
   its LSP State Database Version Number when the 'Redelegation Timeout
   Interval' timer expires (see [I-D.ietf-pce-stateful-pce] for the use
   of the Redelegation Timeout Interval).

3.4.  Speaker Entity Identifier TLV

   SPEAKER-ENTITY-ID is an optional TLV that MAY be included in the OPEN
   Object when a PCEP Speaker wishes to determine if State
   Synchronization can be skipped when a PCEP session is restarted.  It
   contains a unique identifier for the node that does not change during
   the life time of the PCEP Speaker.  It identifies the PCEP Speaker to
   its peers if the Speaker's IP address changed.

   The format of the SPEAKER-ENTITY-ID TLV is shown in the following
   figure:

Crabbe, et al.           Expires April 11, 2014                [Page 10]
Internet-Draft   Optimizations of state synchronization     October 2013

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |       Length (variable)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                 Speaker Entity Identifier                    //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: SPEAKER-ENTITY-ID TLV format

   The type of the TLV is [TBD] and it has a a variable length, which
   MUST be greater than 0.  The value contains the entity identifier of
   the speaker transmitting this TLV.  This identifier is required to be
   unique within its scope of visibility, which is usually limited to a
   single domain.  It MAY be configured by the operator.  Alternatively
   it can be derived automatically from a suitably-stable unique
   identifier, such as a MAC address, serial number, Traffic Engineering
   Router ID, or similar.  In the case of inter-domain connections, the
   speaker SHOULD prefix its usual identifier with the domain identifier
   of its residence, such as Autonomous System number, IGP area
   identifier, or similar.

   The relationship between this identifier and entities in the Traffic
   Engineering database is intentionally left undefined.

   From a manageability point of view, a PCE or PCC implementation
   SHOULD allow the operator to configure a SPEAKER-ENTITY-ID.

4.  PCE-triggered 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 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 Procedures

   Support of PCE-triggered state synchronization is advertised on a
   PCEP session during session startup using the TRIGGERED-SYNC (T) bit
   in the capabilities TLV.  The PCE can choose to resynchronize its

Crabbe, et al.           Expires April 11, 2014                [Page 11]
Internet-Draft   Optimizations of state synchronization     October 2013

   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 PCUpd for it, with the SYNC flag 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 reply with a PCRpt and SHOULD include the SRP-ID-number of the
   PCUpd that triggered the report.

   The PCE can also trigger resynchronization of the entire LSP
   database.  The PCE MUST first mark any LSPs in the LSP database that
   were previously reported by the PCC as stale and then send a PCUpd
   for 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 report
   SHOULD be included in each of the PCRpt messages.

   If the TRIGGERED-SYNC capability was 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 LSP state synchronization
   mechanism between PCCs and PCEs for a stateful PCE.  After PCEP
   session set up, PCC compares the LSP State Database version with the
   PCE as described in Section 3.  If the database version is
   mismatched, state synchronization will be performed.  During state
   synchronization, a PCC sends the information of all its LSPs (full
   LSP-DB) to the stateful PCE.  This section proposes a mechanism for
   incremental (Delta) LSP 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

   If a PCE restarts and its LSP-DB survived, all PCCs with mismatched
   LSP State Database version will send all their LSPs information (full
   LSP-DB) to the stateful PCE, even if only a small number of LSPs
   underwent state change.  It can take a long time and consume large
   communication channel bandwidth.  Moreover, the stateful PCE can get
   overloaded with all the PCC performing full synchronization with it
   at the same time.  Figure 6 shows an example of LSP state

Crabbe, et al.           Expires April 11, 2014                [Page 12]
Internet-Draft   Optimizations of state synchronization     October 2013

   synchronization.

                                       +-----+
                                       | PCE |
                                       +-----+
                                      /
                                     /
                                    /
                                   /
                            +------+            +------+
                            | PCC1 |------------| PCC2 |
                            +------+            +------+
                               |                   |
                               |                   |
                            +------+            +------+
                            | PCC3 |------------| PCC4 |
                            +------+            +------+

                        Figure 6: Topology Example

   Assuming there are 320 LSPs in the network, with each PCC having 80
   LSPs.  During the time when the PCEP session is down, 20 LSPs of each
   PCC (i.e., 80 LSPs in total), are changed.  Hence when PCEP session
   restarts, the stateful PCE needs to synchronize 320 LSPs with all
   PCCs.  But actually, 240 LSPs stay the same.  If performing full LSP
   state synchronization, it can take a long time to carry out the
   synchronization of all LSPs.  It is especially true when only a low
   bandwidth communication channel is available and there is a
   substantial number of LSPs in the network.  Another disadvantage of
   full LSP synchronization is that it is a waste of communication
   bandwidth to perform full LSP synchronization given the fact that the
   number of LSP changes can be small during the time when PCEP session
   is down.

   An incremental (Delta) LSP Database (LSP-DB) state synchronization is
   described in this section, where only the LSPs underwent state change
   are synchronized between the session restart.  This may include new/
   modify/deleted LSPs.  Furthermore, to avoid overloading the PCE, 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
   SHOULD allow:

   o  Incremental LSP state synchronization between session restarts.
      Note this does not exclude the need for a stateful PCE to request
      a full LSP DB synchronization.

Crabbe, et al.           Expires April 11, 2014                [Page 13]
Internet-Draft   Optimizations of state synchronization     October 2013

   o  A stateful PCE to control the timing of PCC synchronizing its LSP
      state with the PCE during incremental synchronisation.

5.2.  Incremental synchronization procedures

   [I-D.ietf-pce-stateful-pce] describes state synchronization and
   Section 3 describes state synchronization avoidance by using LSP-DB-
   VERSION TLV in its OPEN object.  This section extends this idea to
   only synchronize the delta (changes) in case of version mismatch as
   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
   Object and the TLV values match, the PCC MAY skip state
   synchronization.  Otherwise, the PCC MUST perform state
   synchronization.  Instead of dumping full LSP-DB to PCE again, the
   PCC synchronizes the delta (changes) as described in Figure 7 when D
   flag is set to 1 by both PCC and PCE.  Other combinations of D flag
   setting by PCC and PCE result in full LSP-DB synchronization
   procedure as described in [I-D.ietf-pce-stateful-pce].

Crabbe, et al.           Expires April 11, 2014                [Page 14]
Internet-Draft   Optimizations of state synchronization     October 2013

                       +-+-+                    +-+-+
                       |PCC|                    |PCE|
                       +-+-+                    +-+-+
                         |                        |
                         |--Open--,               |
                         |  DBv=46 \    ,---Open--|
                         |   IDB=1  \  /   DBv=42 |
                         |   D=1     \/     IDB=1 |
                         |   T=1     /\      T=1  |
                         |          /  \     D=1  |
                         |         /    `-------->| (Expect Delta sync)
                (Do sync)|<--------`              | (Do not Purge LSP
                (Delta)  |                        | State)
   (Wait for PCE to      |                        |
      trigger LSP state  |                        |
      sync)              |                        |
                         |<-----PCUpd, S=1--------| (ask for LSP Sync,
                         |                        |  PLSP-ID =0)
     (Delta Sync starts) |--PCRpt,DBv=43,SYNC=1-->|
                         |            .           |
                         |            .           |
                         |            .           |
                         |            .           |
                         |--PCRpt,DBv=46,SYNC=0-->| (Sync done,
                         |                        | PLSP-ID=0)
                         |                        |
                         |--PCRpt,DBv=47,SYNC=0-->| (Regular
                         |                        |  LSP State Report)
                         |--PCRpt,DBv=48,SYNC=0-->| (Regular
                         |                        |  LSP State Report)
                         |--PCRpt,DBv=49,SYNC=0-->|
                         |                        |

             Figure 7: Incremental synchronization procedures

   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 S = 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 re- establishing PCEP sessions with it.  When the
   capability of PCE control is enable, only after a PCC receives this
   message, it will then start sending information that PCE does not
   possess, which is inferred from the LSP DB Version information
   exchange in the OPEN message.  Note that the PCE should not mark the
   existing LSPs as stale for incremental state synchronisation

Crabbe, et al.           Expires April 11, 2014                [Page 15]
Internet-Draft   Optimizations of state synchronization     October 2013

   procedure.

   As per Section 3, the LSP State Database version is 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 its state
   change.  This is needed to determine which LSP and what information
   needs to be synchronized in incremental state synchronization.

   In the example shown in Figure 7, PCC synchronizes all LSPs that are
   updated between DB Version 43 to 46.  A PCC SHOULD remember the
   deleted LSP as well, so that PCRpt message with deleted status can be
   sent to the stateful PCE.

6.  Advertising support of the synchronization optimizations

   Support for each of the optimizations described in this document
   requires advertising support of the capability at session
   establishment time.

   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
   figure:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Type            |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Flags                   |D|T|I|S|U|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 8: STATEFUL-PCE-CAPABILITY TLV format

   The value comprises a single field - Flags (32 bits):

   U (LSP-UPDATE-CAPABILITY - 1 bit):  defined in
      [I-D.ietf-pce-stateful-pce]

   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.

   I (LSP-INSTANTIATION-CAPABILITY - 1 bit):  defined in
      [I-D.crabbe-pce-pce-initiated-lsp]

Crabbe, et al.           Expires April 11, 2014                [Page 16]
Internet-Draft   Optimizations of state synchronization     October 2013

   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
      of the session.  The flag must be advertised by both PCC and PCE
      for PCUpd messages with the SYNC flag set to be allowed on a PCEP
      session.

   D (DELTA-LSP-SYNC-CAPABILITY - 1 bit):  if set to 1 by a PCEP
      speaker, the D Flag indicates that the PCEP speaker allows delta
      or incremental state synchronization.

7.  IANA Considerations

   This document requests IANA actions to allocate code points for the
   protocol elements defined in this document.  Values shown here are
   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
       20       LSP State synchronization error.
                 Error-value=2:  LSP Database version mismatch.
                 Error-value=3:  The LSP-DB-VERSION TLV Missing when
                                 State Synchronization Avoidance
                                 enabled.
                 Error-value=4:  Attempt to trigger a synchronization
                                 when the TRIGGERED-SYNC capability has
                                 not been advertised.

7.2.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs:

       Value     Meaning                     Reference
         23       LSP-DB-VERSION             This document
         24       SPEAKER-ENTITY-ID          This document

7.3.  STATEFUL-PCE-CAPABILITY TLV

   The following values are defined in this document for the Flags field
   in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN object:

Crabbe, et al.           Expires April 11, 2014                [Page 17]
Internet-Draft   Optimizations of state synchronization     October 2013

      Bit    Description                Reference

       28    DELTA-LSP-SYNC-CAPABILITY  This document
       29    TRIGGERED-SYNC             This document
       30    INCLUDE-DB-VERSION         This document

8.  Security Considerations

   The security considerations listed in [I-D.ietf-pce-stateful-pce]
   apply to this document as well.

9.  Acknowledgements

   We would like to thank Young Lee for his contributions.

10.  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

11.  Normative References

   [I-D.crabbe-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-crabbe-pce-pce-initiated-lsp-02 (work in
              progress), July 2013.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce-06 (work in progress),
              August 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

Crabbe, et al.           Expires April 11, 2014                [Page 18]
Internet-Draft   Optimizations of state synchronization     October 2013

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

Authors' Addresses

   Edward Crabbe
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: edc@google.com

   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: jmedved@cisco.com

   Ina Minei
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: ina@juniper.net

   Robert Varga
   Pantheon Technologies SRO
   Mlynske Nivy 56
   Bratislava  821 05
   Slovakia

   Email: robert.varga@pantheon.sk

Crabbe, et al.           Expires April 11, 2014                [Page 19]
Internet-Draft   Optimizations of state synchronization     October 2013

   Xian Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R.China

   Email: zhang.xian@huawei.com

   Dhruv Dhody
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   Email: dhruv.ietf@gmail.com

Crabbe, et al.           Expires April 11, 2014                [Page 20]