One document matched: draft-kondreddy-pce-pcep-ls-sync-optimizations-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-kondreddy-pce-pcep-ls-sync-optimizations-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="PCEP LS SYNC OPT">Optimizations of PCEP Link-State(LS) Synchronization Procedures </title>
<author initials="V" surname="Kondreddy" fullname="Venugopal Reddy Kondreddy">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<email>venugopalreddyk@huawei.com</email>
</address>
</author>
<author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<email>mahendrasingh@huawei.com</email>
</address>
</author>
<date month="October" year="2015" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>For a Path Computation Element (PCE) to perform its computations, it is important that Link-State (and TE) information be complete and accurate each time. This requires a reliable Link-State Synchronization mechanism between the PCE and path computation clients (PCCs), and between cooperating PCEs. The basic mechanism for Link-State Synchronization is part of the PCEP Link-State (and TE) draft. This draft presents motivations for optimizations to the base PCEP Link-State (and TE) procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>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.</t>
<t><xref target='I-D.dhodylee-pce-pcep-ls'/> describes a set of extensions to PCEP to provide Link-State (and TE) distribution. This draft presents motivations for optimizations to the base PCEP Link-State transport procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. This draft specifies following optimizations for Link-State Synchronization and the corresponding PCEP procedures and extensions:</t>
<t>
<list style="symbols">
<t>Link-State Synchronization Avoidance: To skip Link-State (and TE) synchronization if the state has survived and not changed during session restart.(See <xref target="sec_avoid"/>)</t>
<t>Incremental Link-State Synchronization: To do incremental (delta) Link-State (and TE) Synchronization when possible.(See <xref target="sec_inc"/>)</t>
<t>PCE-triggered Initial Synchronization: To let PCE control the timing of the initial Link-State (and TE) Synchronization.(See <xref target="sec_itrig"/>)</t>
<t>PCE-triggered Re-synchronization: To let PCE re-synchronize the Link-State (and TE) information for sanity check.(See <xref target="sec_resync"/>)</t>
</list>
</t>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>This document uses the following terms defined in <xref target='RFC5440'/>: PCC,
PCE, PCEP Peer.</t>
<t>This document uses the following terms defined in
<xref target='I-D.dhodylee-pce-pcep-ls'/>: LSRpt, Link-State (and TE), LS</t>
<t>Link-State (and TE): "LS" is interchangably used for the keyword "Link-State (and TE)".</t>
<t>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.</t>
<t>The following terms are defined in this document:</t>
<t>LS-DB: Link-State (and TE) Database.</t>
<t>LS Sync: LS Synchronization, an operation to send LS information synchronization
request to PCC by LSRpt message with LS-ID 0.</t>
<t>LS-Info: One LS information (i.e. LS Node/Link/Prefix defined in I-D.dhodylee-pce-pcep-ls).</t>
</section>
<section title="LS Synchronization Avoidance" toc="default" anchor="sec_avoid">
<section title="Motivation" toc="default">
<t>The purpose of LS Synchronization is to provide a checkpoint-in-time state replica of a PCC's Link-State (and TE) information in a PCE.
LS Synchronization is performed immediately after the initialization phase (<xref target='RFC5440'/>). <xref target='I-D.dhodylee-pce-pcep-ls'/>
describes the basic mechanism for LS synchronization.</t>
<t>LS Synchronization is not always necessary following a PCEP
session restart. If the Link-State (and TE) information of both PCEP peers did not change,
the synchronization phase may be skipped. This can result in significant
savings in both control-plane data exchanges and the time it takes
for the PCE to become fully operational.</t>
</section>
<section title="LS Synchronization Avoidance Procedure" toc="default" anchor="sec_avoid_proc">
<t>LS Synchronization MAY be skipped following a PCEP session restart
if the Link-State (and TE) information of both PCEP peers did not change during the period
prior to session re-initialization. To be able to make this
determination, LS-DB must be exchanged and maintained by both PCE and
PCC during normal operation. This is accomplished by keeping track
of the changes to the Link-State (and TE) Database (LS-DB), using a version tracking
field called the LS-DB Version Number.</t>
<t>The LS-DB Version Number, carried in LS-DB-VERSION TLV (see <xref target="sec_lsdb"/>),
is owned by a PCC and it MUST be incremented by 1 for each successive change
in the PCC's LS-DB. The LS-DB Version Number MUST start at 1 and may wrap
around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of
the two values are used during LS re-synchronization, the
PCE speaker receiving this node should send back a PCErr with Error-type
TBD1 Error-value 1 'Received an invalid LS-DB Version Number',
and close the PCEP session. Operations that trigger a change to the
local LS-DB include but not limited to - </t>
<t>- a change in the link status or attributes(i.e. bandwidth, metric etc), addition or deletion of link.</t>
<t>- a change in the node attributes, addition or deletion of node.</t>
<t>- a change in the prefix attributes, addition or deletion of prefix.</t>
<t>LS Synchronization avoidance is advertised on a PCEP session
during session startup using the LS-INCLUDE-DB-VERSION (S) bit in
the LS-CAPABILITY TLV (see <xref target="sec_lscap"/>). 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 case of such mobility, each PCEP peer includes
the SPEAKER-ENTITY-ID TLV in the OPEN message. SPEAKER-ENTITY-ID TLV
is described in <xref target='I-D.ietf-pce-stateful-sync-optimizations'/></t>
<t>If both PCEP speakers set the S flag in the OPEN object's LS-CAPABILITY
TLV to 1, the PCC MUST include the LS-DB-VERSION TLV
in each LS object of the LSRpt message. If the LS-DB-VERSION
TLV is missing in a LSRpt message, the PCE will generate an error with
Error-Type 6 (mandatory object missing) and Error-Value TBD2
'LS-DB-VERSION TLV missing' and close the
session. If LS Synchronization avoidance has not been enabled on
a PCEP session, the PCC SHOULD NOT include the LS-DB-VERSION TLV in
the LS object and the PCE SHOULD ignore it, if it were to receive one.</t>
<t>If a PCE's LS-DB survived the restart of a PCEP session,
the PCE will include the LS-DB-VERSION TLV in its OPEN object, and
the TLV will contain the last LS-DB Version Number
received on an LS Report from the PCC in the previous PCEP
session. If a PCC's LS-DB survived the restart of a
PCEP session, the PCC will include the LS-DB-VERSION TLV in its OPEN
object and the TLV will contain the latest LS-DB Version
Number. If a PCEP speaker's LS-DB did not survive the
restart of a PCEP session, the PCEP speaker MUST NOT include the LS-DB-VERSION TLV in the OPEN object.</t>
<t>If both PCEP speakers include the LS-DB-VERSION TLV in the OPEN
Object and the TLV values match, the PCC MAY skip LS Synchronization.
Otherwise, the PCC MUST perform complete LS Synchronization. If the
PCC attempts to skip LS Synchronization (i.e., the SYNC Flag = 0
on the first LS Report from the PCC, the PCE MUST send back a
PCErr with Error-Type TBD1 Error-Value 2 'LS-DB version mismatch',
and close the PCEP session.</t>
<t>If LS Synchronization is required, then prior to completing the
initialization phase, the PCE MUST mark any LS-Infos in the
LS-DB that were previously reported by the PCC as stale.
When the PCC reports a LS-Info during LS Synchronization,
if the LS-Info already exists in the LS-DB, the
PCE MUST update the LS-DB and clear the stale marker from
the LS-Info. When it has finished LS Synchronization, the
PCC MUST immediately send an end of LS Synchronization marker.
The end of synchronization marker is a LS Report (LSRpt) message
with an LS object containing a LS-ID of 0 and with the SYNC
flag set to 0. The LS-DB-VERSION TLV MUST be included in this
LSRpt message. On receiving this LS Report, the PCE MUST purge
any LS-Infos from the LS-DB that are still marked
as stale. It should
be noted that PCE may receive the same Link-state and TE information from multiple PCCs
and the purging should take that into account.</t>
<t>Note that a PCE/PCC MAY force LS Synchronization by not including
the LS-DB-VERSION TLV in its OPEN object.</t>
<t>Since a PCE does not make changes to the LS-DB Version
Number, a PCC should never encounter this TLV in a message from the
PCE (other than the OPEN message). A PCC SHOULD ignore the
LS-DB-VERSION TLV, were it to receive one from a PCE.</t>
<!-- commented by dhruv
<t>If LS Synchronization avoidance is enabled, a PCC MUST increment
its LS-DB Version Number whenever LS-DB changes
till the locally configured timer(i.e. to record LS-DB changes) expires.</t>
-->
<t><xref target="fig1"/> shows an example sequence where the LS synchronization is
skipped.</t>
<figure title="LS Synchronization Skipped" suppress-title="false" align="center" alt="" width="" height="" anchor="fig1">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---Open--, |
|LS-DBv=82 \ ,---Open-----|
| S=1 \ /LS-DBv=82 |
| \/ S=1 |
| /\ |
| / `----------->| (OK to skip
(Skip |<---------` | LS sync)
LS sync)| . |
| . |
| . |
| |
|---LSRpt,LS-DBv=83,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=84,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=85,SYNC=0-->|
| |
]]>
</artwork>
</figure>
<t><xref target="fig2"/> shows an example sequence where the LS Synchronization is
performed due to LS-DB Version mismatch during the PCEP
session setup. Note that the same LS Synchronization sequence
would happen if either the PCC or the PCE would not include the
LS-DB-VERSION TLV in their respective Open messages.</t>
<figure title="LS Synchronization Performed" suppress-title="false" align="center" alt="" width="" height="" anchor="fig2">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---Open--, |
|LS-DBv=86 \ ,---Open-----|
| S=1 \ /LS-DBv=82 |
| \/ S=1 |
| /\ |
| / `----------->| (Expect sync)
(Do |<---------` |
sync) | |
| |
|---LSRpt,LS-DBv=86,SYNC=1-->| (Sync start)
| . |
| . |
| . |
|---LSRpt,LS-DBv=86,SYNC=0-->| (Sync done)
| . |(Purge LS-Info
| . | if applicable)
| . |
|---LSRpt,LS-DBv=87,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=88,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=89,SYNC=0-->|
| |
]]>
</artwork>
</figure>
<t><xref target="fig3"/> shows an example sequence where the LS Synchronization is
skipped, but because one or both PCEP speakers set the S Flag to 0,
the PCC does not send LS-DB-VERSION TLVs in subsequent LSRpt
messages to the PCE. If the current PCEP session restarts, the PCEP
speakers will have to perform LS Synchronization, since the PCE
does not know the PCC's latest LS-DB Version Number
information.</t>
<figure title="LS Synchronization Skipped, no LS-DB-VERSION TLVs sent from PCC" suppress-title="false" align="center" alt="" width="" height="" anchor="fig3">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---Open--, |
|LS-DBv=82 \ ,---Open-----|
| S=0 \ /LS-DBv=82 |
| \/ S=0 |
| /\ |
| / `----------->| (OK to skip
(Skip |<---------` | LS sync)
LS sync)| . |
| . |
| . |
| |
|--------LSRpt,SYNC=0------->| (Regular
| | LS Report)
|--------LSRpt,SYNC=0------->| (Regular
| | LS Report)
|--------LSRpt,SYNC=0------->|
| |
]]>
</artwork>
</figure>
</section>
</section>
<section title="Incremental LS Synchronization" toc="default" anchor="sec_inc">
<t><xref target='I-D.dhodylee-pce-pcep-ls'/> describes the LS
synchronization mechanism during session initialization between PCCs and PCEs.
During the LS synchronization, a PCC sends the information of its
LS-DB to the PCE based on the local policy. In order to reduce the LS Synchronization
overhead when there is a small number of LS-DB
change in the network between PCEP session restart, this section defines a
mechanism for incremental (Delta) LS synchronization.</t>
<section title="Motivation" toc="default">
<t>According to <xref target='I-D.dhodylee-pce-pcep-ls'/>, if a PCEP session restarts,
PCCs send snapshot of LS-DB information to the PCE, though
LS-DB did not change. And as per <xref target="sec_avoid"/> (LS Synchronization
Avoidance Procedure), if there is a change in a small number of LS-Infos.
PCC yet sends complete snapshot of LS-DB information to the PCE,
which takes a long time and consume large communication channel bandwidth.</t>
</section>
<section title="Incremental Synchronization Procedure" toc="default">
<t><xref target="sec_avoid"/> describes LS Synchronization avoidance by using LS-DB-VERSION
TLV in its OPEN object. This section extends this idea to only synchronize
the delta (changes) in case of version mismatch.</t>
<t>If both PCEP speakers include the LS-DB-VERSION TLV in the OPEN
object and the LS-DB-VERSION TLV values match, the PCC MAY skip
LS Synchronization. Otherwise, the PCC MUST perform LS Synchronization.
Incremental LS Synchronization capability is
advertised on a PCEP session during session startup using the
LS-DELTA-SYNC-CAPABILITY (D) bit in the capabilities TLV (see <xref target="sec_lscap"/>).
Instead of dumping full LS-DB to the PCE again, PCC synchronizes
the delta (changes) as described in <xref target="fig4"/> when D flag and S flag is
set to 1 by both PCC and PCE. Other combinations of D and S flags
setting by PCC and PCE result in complete LS Synchronization
procedure as described in <xref target='I-D.dhodylee-pce-pcep-ls'/>.
If a PCC has to force complete LS Synchronization due to reasons including
but not limited: (1) local policy configured at the PCC;
(2) no sufficient LS-DB caches for incremental update, the PCC
can set the D flag to 0. Note a PCC may have to bring down the current
session and force a complete LS Synchronization with D flag set
to 0 in the subsequent open message.</t>
<figure title="Incremental Synchronization Procedure" suppress-title="false" align="center" alt="" width="" height="" anchor="fig4">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---Open--, |
|LS-DBv=86 \ ,---Open-----|
| S=1 \ /LS-DBv=82 |
| D=1 \/ S=1 |
| /\ D=1 |
| / `----------->| (Expect Delta sync)
(Do |<---------` | (Donot purge
Delta | | LS-Infos)
sync) | |
|---LSRpt,LS-DBv=86,SYNC=1-->| (Delta Sync start)
| . |
| . |
| . |
|---LSRpt,LS-DBv=86,SYNC=0-->| (Sync done)
| | LS-ID=0)
| |
|---LSRpt,LS-DBv=87,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=88,SYNC=0-->| (Regular
| | LS Report)
|---LSRpt,LS-DBv=89,SYNC=0-->|
| |
]]>
</artwork>
</figure>
<t>As per <xref target="sec_avoid"/>, the LS-DB Version Number is
incremented each time a change is made to the PCC's local LS-DB.
Each LS-Info is associated with the DB version
at the time of change. This is needed to determine which LS-Info
needs to be synchronized in incremental LS Synchronization.</t>
<t>PCC MAY store a then history of LS-DB change that
happened between the PCEP session(s) restart in order to carry out
incremental LS Synchronization. After the synchronization procedure
finishes, the PCC can dump this history information. In the example shown
in Figure 4, the PCC needs to store the LS-DB changes that happened
between DB Version 83 to 86 and synchronizes these changes only when
performing incremental LS-DB update. So a PCC needs to remember the
LS-DB changes that happened when an existing PCEP session to
a PCE goes down in the hope of doing incremental synchronization when
the session is re-established.</t>
<t>If a PCC finds out it does not have sufficient information to
complete incremental synchronization after advertising incremental
LS Synchronization capability, it MUST send a PCErr with
Error-Type TBD1 and Error-Value 3 'A PCC indicates to a PCE that it can
not complete the LS synchronization' and terminate the session.</t>
</section>
</section>
<section title="PCE-triggered Initial Synchronization" toc="default" anchor="sec_itrig">
<section title="Motivation" toc="default">
<t>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 PCE connected to the network
via one network node, it is desirable to control the timing of PCC
LS 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 PCE and the network. The method
proposed, i.e., allowing PCE to trigger the LS synchronization,
is similar to the function proposed in <xref target="sec_resync"/> but is used in
different scenarios and for different purposes.</t>
</section>
<section title="PCE-triggered Initial LS Synchronization Procedure" toc="default" >
<t>Support of PCE-triggered LS Synchronization is advertised during
session startup using the LS-TRIGGERED-INITIAL-SYNC (F) bit in the
LS-CAPABILITY TLV (see <xref target="sec_lscap"/>).</t>
<t>As per <xref target='I-D.dhodylee-pce-pcep-ls'/>, LSRpt is sent from
PCC to PCE, this document extends the usage of LSRpt to trigger syncronization.
Where a PCC can send a LSRpt (for LS Sync) with an LS object containing a LS-ID of 0 and
with the SYNC flag set to 1. This LSRpt message is the trigger for
the PCC to enter the synchronization phase and start sending LSRpt
messages.</t>
<t>If the LS-TRIGGERED-INITIAL-SYNC capability is not advertised and the
PCC receives a LSRpt with the SYNC flag set to 1, it MUST send a
PCErr for LSRpt(LS Sync from PCE) with Error-Type TBD1 and Error-
Value 4 'Attempt to trigger synchronization when the PCE triggered synchronization
capability has not been advertised'.</t>
<t>A PCE MAY choose to control the LS Synchronization process.
To allow PCE to do so, PCEP speakers MUST set T bit to 1 to indicate
this (as described in <xref target="sec_lscap"/>). If the LS-DB version is
mis-matched, it can send a LSRpt message with LS-ID = 0 and SYNC = 1 in
order to trigger the LS Synchronization process. In this way,
the PCE can control the sequence of LS 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. The PCC SHOULD NOT send LSRpt messages to the PCE before
it triggers the LS Synchronization. This PCE-triggering capability
can be applied to both full and incremental LS Synchronization. If
applied to the later, the PCCs only send information that PCE does
not possess, which is inferred from the LS-DB version information
exchanged in the OPEN message (see <xref target="sec_avoid_proc"/>) for detailed
procedure).</t>
</section>
</section>
<section title="PCE-triggered Re-synchronization" toc="default" anchor="sec_resync">
<section title="Motivation" toc="default">
<t>The accuracy of the computations performed by the PCE is tied to the
accuracy of the view the PCE has on the LS-DB.
Therefore, it can be beneficial to be able to re-synchronize LS-DB
even after the session has been established. The PCE may use
this approach to continuously sanity check its LS-DB against the
network, or to recover from error conditions without having to tear
down sessions.</t>
</section>
<section title="PCE-triggered LS Re-synchronization Procedure" toc="default">
<t>Support of PCE-triggered LS Synchronization is advertised during
session startup using the LS-TRIGGERED-RESYNC (T) bit in the
LS-CAPABILITY TLV (see <xref target="sec_lscap"/>).</t>
<t>The PCE triggers re-synchronization of the entire LS-DB.
The PCE MUST first mark all LS-Infos in the LS-DB
that were previously reported by the PCC as stale and then send a LSRpt (for LS Sync) with an LS object containing a LS-ID of 0 and
with the SYNC flag set to 1. This LSRpt message is the trigger for
the PCC to enter the synchronization phase and start sending LSRpt
messages. After the receipt of the end-of-synchronization marker,
the PCE will purge LS-Infos which were not refreshed.</t>
<t>If the LS-TRIGGERED-RESYNC capability is not advertised and the PCC
receives a LSRpt with the SYNC flag set to 1, it MUST send a PCErr
with Error-Type TBD1 and Error-Value
4 'Attempt to trigger synchronization when the TRIGGERED-SYNC
capability has not been advertised'.</t>
<t>Once the state re-synchronization is triggered by the PCE, the
procedures and error checks remain unchanged from the full state
synchronization (<xref target='I-D.dhodylee-pce-pcep-ls'/>). This would
also include PCE triggering multiple state re-synchronization requests
while synchronization is in progress.</t>
<figure title="PCE Triggered Complete LS re-synchronization" suppress-title="false" align="center" alt="" width="" height="" anchor="fig5">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<----LSRpt, SYNC=1 -----| Trigger
| (LSID=0) | re-sync
| |
|-----LSRpt, SYNC=1----->| (Sync start)
| . |
| . |
| . |
|-----LSRpt, SYNC=1----->|
| . |
| . |
| . |
| |
|-----LSRpt, SYNC=0----->| (End of sync marker
| | LS Report
| | for LS-ID=0)
| | (LS Sync done)
]]>
</artwork>
</figure>
</section>
</section>
<section title="PCEP Extensions" toc="default">
<section title="Link-State(LS) Report Message" toc="default">
<t>A PCEP LS Report message (also referred to as LSRpt message) is a
PCEP message sent by a PCC to a PCE to report the LS information. The definition
of the LSRpt message from <xref target='I-D.dhodylee-pce-pcep-ls'/> is extended to use
LSRpt message with LS-ID = 0 to request LS Synchronization from PCE to PCC.
</t>
<t>If a PCC that does not support extention defined in this document
receives a LSRpt message, it will act according to existing behavior
of receiving invalid message. If a PCC supports the extention,
but did not set the flag T or F, and receives the LSRpt message,
it sends PCErr message as described earlier in section [x] and [y].
If a PCC supports the extention and set the flag T or F, and
receives the LSRpt message without LS-ID as 0 and SYNC flag set,
PCC will send an error message with Error-Type TBD1 Error-Value 6 'Invalid LSRpt message'.</t>
</section>
<section title="Capability Advertisement" toc="default" anchor="sec_lsdb">
<t>The LS-DB Version Number is an carried in optional
LS-DB-VERSION TLV that MAY be included in the OPEN object and the
LS object. This TLV MUST NOT be included if LS-INCLUDE-DB-VERSION bit
in LS-CAPABILITY TLV is not set.</t>
<t>The format of the LS-DB-VERSION TLV is shown in the following
figure:</t>
<figure title="LS-DB-VERSION TLV format" suppress-title="false" align="center" alt="" width="" height="" anchor="fig6">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS-DB Version Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer, representing the LS-DB
Version Number.</t>
</section>
<section title="Advertising Support of Synchronization Optimizations" toc="default" anchor="sec_lscap">
<t>Support for each of the optimizations described in this document
requires advertising the corresponding capabilities during session
establishment.</t>
<t>New flags are defined for the LS-CAPABILITY TLV defined in
<xref target='I-D.dhodylee-pce-pcep-ls'/>.</t>
<figure title="LS-CAPABILITY TLV Format" suppress-title="false" align="center" alt="" width="" height="" anchor="fig7">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height="">
<![CDATA[
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 |F|D|T|S|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>The value comprises a single field - Flags (32 bits):</t>
<t>R (LS-REMOTE-BIT - 1 bit): Defined in <xref target='I-D.dhodylee-pce-pcep-ls'/></t>
<t>S (LS-INCLUDE-DB-VERSION - 1 bit): If set to 1 by both PCEP speakers,
the PCC will include the LS-DB-VERSION TLV in each LS object. See <xref target="sec_avoid"/> for details.</t>
<t>T (LS-TRIGGERED-RESYNC - 1 bit): If set to 1 by both PCEP speakers, the
PCE can trigger re-synchronization of LS-Infos at any point in the
life of the session. See <xref target="sec_resync"/> for details.</t>
<t>D (LS-DELTA-SYNC-CAPABILITY - 1 bit): If set to 1 by a PCEP
speaker, it indicates that the PCEP speaker allows incremental
(delta) state synchronization. See <xref target="sec_inc"/> for details.</t>
<t>F (LS-TRIGGERED-INITIAL-SYNC - 1 bit): If set to 1 by both PCEP
speakers, the PCE SHOULD trigger initial (first) LS
synchronization. See <xref target="sec_itrig"/> for details.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>This document requests IANA actions to allocate code points for the
protocol elements defined in this document.</t>
<section title="PCEP-Error Object" toc="default">
<t>IANA is requested to make the following allocation in the "PCEP-ERROR
Object Error Types and Values" registry.</t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Error-Type Meaning Reference
6 Mandatory Object missing [RFC5440]
Error-Value= TBD2 This document
LS-DB-VERSION TLV missing
TBD1 LS synchronization This document
error
Error-Value= TBD(suggested This document
value 1):Received an invalid
LSDB Version Number
Error-Value= TBD(suggested This document
value 2): LS-DB
version mismatch.
Error-Value=TBD(suggested This document
value 3): PCC indicates to a
PCE that it cannot complete
the LS Synchronization
Error-Value=TBD(suggested This document
value 4): Attempt to trigger a
synchronization when the
PCE triggered synchronization
capability has not been
advertised.
Error-Value=TBD(suggested This document
value 5): LS-DB-VERSION
TLV Missing when LS
synchronization avoidance is
enabled.
Error-Value=TBD(suggested This document
value 6): Invalid LSRpt
message.
]]></artwork>
</figure>
</section>
<section title="PCEP TLV Type Indicators" toc="default">
<t>This document defines the following new PCEP TLVs:</t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Value Meaning Reference
TBD LS-DB-VERSION This document
]]></artwork>
</figure>
</section>
<section title="LS-CAPABILITY Flags" toc="default">
<t>The following values are defined in this document for the Flags field
in the LS-CAPABILITY TLV in the OPEN object:</t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Bit Description Reference
TBD
(Suggested value 30) LS-INCLUDE-DB-VERSION This document
(Suggested value 29) LS-TRIGGERED-RESYNC This document
(Suggested value 28) LS-DELTA-SYNC-CAPABILITY This document
(Suggested value 27) LS-TRIGGERED-INITIAL-SYNC This document
]]></artwork>
</figure>
</section>
</section>
<section title="Manageability Considerations " toc="default">
<t>All manageability requirements and considerations listed in <xref target='RFC5440'/>
and <xref target='I-D.dhodylee-pce-pcep-ls'/> apply to PCEP
protocol extensions defined in this document. In addition, requirements
and considerations listed in this section apply.</t>
<section title="Control of Function and Policy" toc="default">
<t>A PCE or PCC implementation MUST allow configuring the state
synchronization optimization capabilities as described in this
document.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>PCEP session configuration and information in the PCEP MIB module
SHOULD be extended to include advertised LS Capabilities,
LS-DB Version Number and LS synchronization status, Message statistics. </t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in <xref target='RFC5440'/>.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>Mechanisms defined in section 8.4 of <xref target='RFC5440'/> also apply to PCEP
protocol extensions defined in this document. In addition to
monitoring parameters defined in <xref target='RFC5440'/>, a PCEP implementation
with LS-DB SHOULD provide the following parameters:
<list style="symbols">
<t>Total number of LSRpt(Synchronization request) requests</t>
<t>LS-DB Version Number and synchronization status</t>
</list>
</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>Mechanisms defined in this document do not imply any new requirements
on other protocols.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>Mechanisms defined in section 8.6 of <xref target='RFC5440'/> also apply to PCEP
protocol extensions defined in this document.</t>
<t>Additionally, a PCEP implementation SHOULD allow a limit to be placed
on the amount and rate of LSRpt messages sent by a PCEP
speaker and processed by the peer. It SHOULD also allow sending a
notification when a rate threshold is reached.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>The security considerations listed in <xref target='I-D.dhodylee-pce-pcep-ls'/>
apply to this document as well. However, because the protocol
modifications outlined in this document allow the PCE to control
LS Re-synchronization timing and sequence, it also introduces a
new attack vector: an attacker may flood the PCC with triggered re-synchronization request at a rate which exceeds the PCC's ability to
process them, either by spoofing messages or by compromising the PCE
itself. The PCC is free to drop any trigger re-synchronization
request without additional processing.</t>
</section>
<section title="Ackwonoledgement" toc="default">
<t>The document borrows some of the text and structure from <xref target="I-D.ietf-pce-stateful-sync-optimizations"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.I-D.dhodylee-pce-pcep-ls"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-pce-stateful-sync-optimizations"?>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
EMail: dhruv.ietf@gmail.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 12:06:39 |