One document matched: draft-palle-pce-stateful-pce-lspdb-sync-01.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-palle-pce-stateful-pce-lspdb-sync-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="LSPDB-SYNC">LSP-DB Synchronization between Stateful PCEs</title>
<author initials="U" surname="Palle" fullname="Udayasree Palle">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>udayasree.palle@huawei.com</email>
</address>
</author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
<author initials="X" surname="Zhang" fullname="Xian Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<region></region>
<code>518129</code>
<country>P.R.China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</author>
<date month="July" year="2013" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<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="STATEFUL-PCE"/> specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP and maintaining of these LSPs at the stateful PCE. This document describes the mechanisms of LSP Database (LSP-DB) synchronization between stateful PCEs.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t><xref target="RFC5440"/> describes the Path Computation Element Protocol (PCEP) as the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Paths (TE LSPs).</t>
<t><xref target="STATEFUL-PCE"/> specifies a set of extensions to PCEP to enable stateful control of LSPs in compliance with <xref target="RFC4655"/>. It includes mechanisms for LSP state synchronization between a PCC and a PCE.</t>
<t>This document specifies the mechanisms of LSP-DB synchronization between stateful PCEs in the same domain.</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>The terminology is as per <xref target="RFC5440"/> and <xref target="STATEFUL-PCE"/>.</t>
<t>
<list style="hanging">
<t hangText="LSP-DB:">A database of LSPs that are active in the network as maintained by a stateful PCE.</t>
<t hangText="Sticky Resources:">The temporarily assigned resources that are allocated to a pending LSP and are provisionally blocked.</t>
</list>
</t>
</section>
<section title="Motivation & Use" toc="default">
<t>"Distributed computation model" (<xref target="RFC4655"/>) refers to a domain or network that may include multiple PCEs where computation of paths is shared among the PCEs, this is further clarified in <xref target="PCE-QUESTIONS"/>.</t>
<t>When multiple stateful PCEs are operating in the network, they could be either - </t>
<t>
<list style="hanging">
<t hangText="Primary or Backup PCE:">A backup PCE exists to perform functions in the network, only in the event of a failure of the primary PCE. In this case, all LSPs to be delegated are under primary stateful PCE control while other PCEs in the domain act as backup. The backup PCE should have the same view of LSP-DB as primary stateful PCE. The LSP-DB of a backup PCE can be synchronized via the primary stateful PCE or collected from multiple network nodes (PCC). In case of latter only, the backup PCE may face synchronization issues as described in <xref target="PCE-QUESTIONS"/>. Thus it is suggested that backup PCE can be synchronized via the primary stateful PCE, this mechanism is described in <xref target="SEC_PB"/>. Note that backup PCE MAY use synchronization from network as a mechanism to cross-check the LSP-DB.</t>
<t hangText="Load-Balanced 'Backup' PCE:">Load-Balanced PCEs share the computation load all the time as well as act backup to each other. One PCE MAY serve a set of PCCs as the primary computation server, and only addresses requests from other PCCs in the event of the failure of some other PCE. Delegated LSPs are thus distributed among stateful PCEs. It is suggested that in this case each load-balanced stateful PCE should build their LSP-DB independently from the network (PCCs) (via mechanism described in <xref target="STATEFUL-PCE"/>) during initial LSP state synchronization and not from other stateful PCEs. But it is important that these load-balanced stateful PCEs needs to be synchronized to have a similar view of pending LSPs and sticky resources, this mechanism is described in <xref target="SEC_PP"/>.</t>
</list>
</t>
</section>
<section title="Functions to Support LSP-DB Synchronization" toc="default" anchor="SEC_F">
<t><xref target="STATEFUL-PCE"/> specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).</t>
<t>
<list style="symbols">
<t>Capability negotiation (E-C,C-E)</t>
<t>LSP state synchronization (C-E)</t>
<t>LSP update request (E-C)</t>
<t>LSP state report (C-E)</t>
<t>LSP control delegation (C-E,E-C)</t>
<t>Stateful PCE discovery via <xref target="STATEFUL-PCE-DISC"/></t>
</list>
</t>
<t>This document extends some of these functions to support LSP-DB synchronization. Some are initiated either from a PCE towards another PCE (E-E) or specifically from primary to backup PCE (PE-BE). </t>
<t>
<list style="hanging">
<t hangText="Capability negotiation (E-E):">both the PCEs must announce during PCEP session establishment that they support PCEP Stateful PCE extensions defined in <xref target="STATEFUL-PCE"/>. It should also declare whether it has primary or backup stateful PCE capability. This is done via Open message.</t>
<t hangText="LSP state synchronization (PE-BE):">after the session between the stateful PCEs is initialized, the backup PCE must learn the state of LSPs from the primary PCE. This is done via PCRpt message.</t>
<t hangText="LSP update request (E-E):">When a PCE requests modification of attributes of a delegated LSP, this information should also be sent to other PCEs. This is done via PCUpd message. This is needed to synchronize the pending LSPs and sticky resources.</t>
<t hangText="Stateful PCE discovery:"> PCE can advertise its primary or backup capability via IGP.</t>
</list>
</t>
</section>
<section title="Architectural Overview" toc="default">
<t>LSP-DB synchronization function is defined in section 5.4 of <xref target="STATEFUL-PCE"/> between PCC and PCEs. This document extends the LSP state synchronization between stateful PCEs.</t>
<section title="LSP-DB Synchronization between Primary and Backup Stateful PCEs" toc="default" anchor="SEC_PB">
<t>As shown in <xref target="FIG_1"/>, PCE1 is the primary stateful PCE and PCE2 is the backup stateful PCE. PCC1 and PCC2 synchronize the LSP-DB with the primary stateful PCE1 after session initialization phase. And primary stateful PCE1 synchronizes LSP-DB with its backup stateful PCE2 after session initialization phase. This is LSP state synchronization as described in <xref target="SEC_F"/> and uses PCRpt message.</t>
<t>PCC1 & PCC2 delegates LSP1 & LSP2 to the primary PCE1. Whenever there is an update in LSP, PCE1 sends a PCUpd message to corresponding PCC and also to backup PCE2. This is LSP update request as described in <xref target="SEC_F"/> and uses PCUpd message. This makes sure that the pending LSP changes and sticky resources are backed up. The PCC sends a PCRpt message to the primary PCE, indicating the LSP's status, the primary PCE further synchronizes the state with backup PCEs via PCRpt message.</t>
<figure title="LSP-DB synchronization between primary and backup stateful PCEs" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_1">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----+ +----+ +----+ +----+
|PCC1| |PCC2| |PCE1| |PCE2|
+-+--+ +-+--+ +-+--+ +-+--+
| | | |
|---- LSP SYNC ---+----------------->| |
| |---- LSP SYNC --->| |
| | |---- LSP SYNC----->|
| |---- LSP SYNC ----+------------------>|
|---- LSP SYNC ---+------------------+------------------>|
| | | |
|-- PCRpt,lsp1,D -+----------------->| |
|<----------------+----PCUpd,lsp1 ---| |
| | |--- PCUpd,lsp1 --->|
|-- PCRpt,lsp1,up-+----------------->| |
|-- PCRpt,lsp1,up-+------------------+------------------>|
| | |----PCRpt,lsp1,up->|
| | | |
| |-- PCRpt,lsp2,D ->| |
| |<---PCUpd,lsp2 ---| |
| | |--- PCUpd,lsp2---->|
| |-- PCRpt,lsp2,up->| |
| |-- PCRpt,lsp2,up--+------------------>|
| | |----PCRpt,lsp2,up->|
| | | |
]]></artwork>
</figure>
<t>In this case LSP state synchronization is done via primary stateful PCE. The backup PCE MAY choose to cross-check the LSP-DB with the state learned from the network (PCCs).</t>
<t>The backup PCE is used only in case the primary PCE fails. At the time of failure of primary PCE (PCE1), the backup PCE (PCE2) act as a primary. In case of multiple backup PCEs, a selection mechanism (e.g. least IP address among backup PCEs) may be used. When PCE1 recovers from failure, the acting primary PCE (PCE2) should backup using the mechanism as described in this section and restart all its PCEP sessions, thus making sure all PCEP speakers now considers PCE1 as primary.</t>
</section>
<section title="LSP-DB Synchronization between Load-Balanced Stateful PCEs" toc="default" anchor="SEC_PP">
<t>As shown in <xref target="FIG_2"/>, PCE1 and PCE2 are load-balanced stateful PCEs and share the computation load as well as act as backup to each other. PCC1 and PCC2 synchronize their LSP-DB with both PCEs after session initialization phase as per <xref target="STATEFUL-PCE"/>. Note that there is no need of LSP-DB state synchronization between PCE1 and PCE2 after session initialization phase as they are load-balanced PCEs and synchronizes the LSP-DB with the network (PCCs).</t>
<t>PCC1 delegates LSP1 to PCE1. Whenever there is an update in LSP1, PCE1 sends the PCUpd message to PCC1 and other stateful PCEs (PCE2). Similarly, PCC2 delegates LSP2 to PCE2. Whenever there is an update in LSP2, PCE2 sends the PCUpd message to PCC2 and other stateful PCEs (PCE1). This is LSP update request as described in <xref target="SEC_F"/> and it makes sure that the pending LSP changes and sticky resources are synchronized. The PCC sends an PCRpt message to the all load-balanced PCEs as per <xref target="STATEFUL-PCE"/>, indicating the LSP's status.</t>
<t>Note that the PCUpd message are exchanged between load-balanced PCEs for pending LSP changes and sticky resources. And the status of the LSPs are received from the network (PCC) via PCRpt message as described in <xref target="STATEFUL-PCE"/> as well as from the PCE.</t>
<figure title="LSP-DB synchronization between load-balanced stateful PCEs" suppress-title="false" align="left" alt="" width="" height="" anchor="FIG_2">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----+ +----+ +----+ +----+
|PCC1| |PCC2| |PCE1| |PCE2|
+-+--+ +-+--+ +-+--+ +-+--+
| | | |
|---- LSP SYNC ---+----------------->| |
|---- LSP SYNC ---+------------------+------------------>|
| |---- LSP SYNC --->| |
| |---- LSP SYNC ----+------------------>|
| | | |
|-- PCRpt,lsp1,D -+----------------->| |
|<----------------+----PCUpd, lsp1---| |
| | |--- PCUpd, lsp1--->|
|-- PCRpt,lsp1,up-+----------------->| |
|-- PCRpt,lsp1,up-+------------------+------------------>|
| | |----PCRpt,lsp1,up->|
| | | |
| | | |
| |-- PCRpt,lsp2,D --+------------------>|
| |<---PCUpd, lsp2---|-------------------|
| | |<--- PCUpd, lsp2 --|
| |-- PCRpt,lsp2,up->| |
| |-- PCRpt,lsp2,up--+------------------>|
| | |<---PCRpt,lsp1,up--|
| | | |
]]></artwork>
</figure>
<t>At the time of failure of one of the PCEs (say PCE1), the other PCE (PCE2) may take up the load. When PCE1 recovers from failure, the load can be redistributed again among the PCEs.</t>
</section>
<section title="Other Considerations" toc="default">
<t>
<list style="symbols">
<t>This document does not tackle the issue about TED synchronization which is described in detail in <xref target="PCE-QUESTIONS"/>.</t>
<t>The computation mechanism and how PCE chooses to handle the sticky resources during computation is out of scope.</t>
<t>Mechanism for incremental sync or PCE control of timing will be handled in future versions.</t>
</list>
</t>
</section>
</section>
<section title="PCEP Messages" toc="default">
<section title="The PCRpt Message" toc="default">
<t>The format of PCRpt message is defined in <xref target="STATEFUL-PCE"/>. It specifies the PCRpt message is sent from PCC to PCE in reporting the LSP state. This document extends the usage of PCRpt message between primary and backup stateful PCEs for LSP synchronization as described in <xref target="SEC_PB"/>. </t>
</section>
<section title="The PCUpd Message" toc="default">
<t>The format of PCUpd Message is defined in <xref target="STATEFUL-PCE"/>. It specifies the PCUpd message is sent from PCE to PCC to request changes in LSP attributes. This document extends the usage of PCUpd message between stateful PCEs for LSP synchronization of pending LSPs and sticky resources as described in <xref target="SEC_PP"/>. Whenever there is a PCUpd message sent from PCE to PCC, PCE should also send it to other PCEs (backup or load-balanced).</t>
</section>
</section>
<section title="TLVs" toc="default">
<section title="Stateful PCE Capability TLV" toc="default" anchor="SEC_C">
<t>As per <xref target="STATEFUL-PCE"/>, STATEFUL-PCE-CAPABILITY TLV can be used in the OPEN object for stateful PCE capability negotiation. A stateful PCE must announce during PCEP session establishment that they support PCEP stateful PCE extensions defined in <xref target="STATEFUL-PCE"/>. A new flag is added - </t>
<t>
<list style="hanging">
<t hangText="B (BACKUP - 1 bit):"> if set to 1 by PCE, the PCE should act as a backup. It MAY become an 'acting primary PCE' only in case of failure or unavailability of primary PCE. In case of PCC, this bit has no meaning and is simply ignored.</t>
</list>
</t>
</section>
<section title="PCE Redundancy Group Identifier TLV" toc="default">
<t><xref target="STATEFUL-PCE"/> defines a PREDUNDANCY-GROUP-ID TLV which is an unique identifier of a PCC and carried in OPEN object, <xref target="STATEFUL-PCE"/> also specifies PLSP-ID in LSP object and SYMBOLIC-PATH-NAME TLV which is used to identify the originating PCC.</t>
<t>To uniquely identify LSP across stateful PCEs, PREDUNDANCY-GROUP-ID TLV MUST be encoded along with LSP object when PCRpt message is sent from primary to backup stateful PCE. This way the backup stateful PCE will also learn the unique identifier for the PCC that does not change. </t>
<t>The existing PREDUNDANCY-GROUP-ID TLV MAYBE encoded in LSP object's optional TLV to identify the originating PCC.</t>
</section>
<section title="PCE-CAP-FLAGS sub-TLV " toc="default">
<t><xref target="RFC5088"/> and <xref target="RFC5089"/> describe the mechanism to advertise the PCE Discovery information via OSPF and IS-IS respectively along with processing rules for the sub-TLVs. <xref target="STATEFUL-PCE-DISC"/> further enhances the optional PCE-CAP-FLAGS sub-TLV used to advertise PCE stateful capabilities.</t>
<t>Further a new bit is added - </t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Capabilities
TBD Backup Stateful PCE
]]></artwork>
</figure>
</t>
<t>If this bit is set to 1, the PCE should act as a backup. It MAY become an 'acting primary PCE' only in case of failure or unavailability of primary PCE.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>TBD.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>TBD.</t>
</section>
<section title="Information and Data Models" toc="default">
<t>TBD.</t>
</section>
<section title="Liveness Detection and Monitoring" toc="default">
<t>TBD.</t>
</section>
<section title="Verify Correct Operations" toc="default">
<t>TBD.</t>
</section>
<section title="Requirements On Other Protocols" toc="default">
<t>TBD.</t>
</section>
<section title="Impact On Network Operations" toc="default">
<t>TBD.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="STATEFUL-PCE-CAPABILITY TLV" toc="default">
<t>As discussed in <xref target="SEC_C"/>, a new STATEFUL-PCE-CAPABILITY TLV Flag Field has been defined. IANA has made the following allocation from the PCEP "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Description Reference
TBD BACKUP [This I.D.]
]]></artwork>
</figure>
</t>
</section>
<section title="PCE-CAP-FLAGS sub-TLV" toc="default">
<t>As discussed in <xref target="SEC_C"/>, a new bit is added, IANA is requested to allocate a new bit in "PCE Capability Flags" registry for backup stateful PCE capability as follows:</t>
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Bit Description Reference
TBD BACKUP [This I.D.]
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Acknowledgments" toc="default">
<t>Thanks to Adrian Farrel and Daniel King for writing <xref target="PCE-QUESTIONS"/>.</t>
<t>We would like to thank Avantika Kumar for her useful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5088.xml" ?>
<?rfc include="reference.RFC.5089.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<!--STATEFUL-PCE-->
<reference anchor="STATEFUL-PCE">
<front>
<title>PCEP Extensions for Stateful PCE (draft-ietf-pce-stateful-pce)</title>
<author initials="E" surname="Crabbe" fullname="Crabbe E">
<organization />
</author>
<author initials="J" surname="Medved" fullname="Medved J">
<organization />
</author>
<author initials="I" surname="Minei" fullname="Minei I">
<organization />
</author>
<author initials="R" surname="Varga," fullname="Varga R">
<organization />
</author>
<date month="June" year="2013" />
</front>
</reference>
<!--PCE-QUESTIONS-->
<reference anchor="PCE-QUESTIONS">
<front>
<title>Unanswered Questions in the Path Computation Element Architecture (draft-ietf-pce-questions)</title>
<author initials="A" surname="Farrel" fullname="Adrian Farrel">
<organization />
</author>
<author initials="D" surname="King" fullname="Daniel King">
<organization />
</author>
<date month="July" year="2013" />
</front>
</reference>
<!--STATEFUL-PCE-DISC-->
<reference anchor="STATEFUL-PCE-DISC">
<front>
<title>IGP Extensions for Stateful PCE Discovery (draft-sivabalan-pce-disco-stateful-01)</title>
<author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
<organization />
</author>
<author initials="J" surname="Medved" fullname="Jan Medved">
<organization />
</author>
<author initials="X" surname="Zhang" fullname="Xian Zhang">
<organization />
</author>
<date month="April" year="2013" />
</front>
</reference>
</references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: leeyoung@huawei.com
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:10:36 |