One document matched: draft-palle-pce-stateful-pce-lspdb-sync-03.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-03" 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.ietf@gmail.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="2014" />
<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, i.e., all stateful PCEs
synchronize their LSP states from the network.</t>
<t>When multiple stateful PCEs are operating in the network, they could
be either Primary/Backup or Loadbalanced. In a scenario where
the network operator has deployed backup stateful PCE(s) with only
purpose to be used in the event of failure of the primary PCE,
it makes sense that in such a deployment, PCE should have as latest
LSP states as possible. Further as stateful PCE make changes to
the delegated LSPs, these changes (pending LSPs and sticky
resources) needs to be synchronized to other PCEs as soon as possible.
<xref target="PCE-QUESTIONS"/> describes the synchronization issues
when PCEs are synchronized from the network (PCC) only. </t>
<t>This document specifies the mechanisms of LSP-DB synchronization
between stateful PCEs (in the same domain) to be able to get the latest
LSP state.</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 and 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 and PCC2 delegates LSP1 and 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="">
+----+ +----+ +----+ +----+
|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>
<t><xref target="STATEFUL-LSPSYNC-OPT"/> describes LSP state synchronization
optimizations - PCE triggered synchronization, state synchronization avoidance,
and incremental state synchronization. A Backup PCE
should trigger the state
synchronization with primary PCE first in order to get the full LSP-DB, likewise
when the original primary PCE gets up, it can trigger the state synchronization with
the current stateful PCE first. Further
state synchronization avoidance and incremental state synchronization can optimize
the state synchronization process making sure that the PCEs have the latest LSP-DB
as quickly as possible. </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"/>.
In this case, state synchronization does not happen between PCE1
and PCE2 as they synchronize 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="">
+----+ +----+ +----+ +----+
|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 of this document.</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="Other Considerations" toc="default">
<t> <xref target="STATEFUL-PCE-INTERDOMAIN"/> describes general
considerations for the deployment of stateful PCE(s) in
inter-domain scenarios including inter-area and inter-AS. It
further mentions an alternative approach for state
synchronisation of inter-domain LSP to transit and egress domain PCE,
where each PCE may synchronise the
state with other PCEs in other domain. A mechanism similar to LSP-DB
backup described in this document may be utilized for
this purpose.</t>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not introduce any new security concerns besides those in
<xref target="STATEFUL-PCE"/>.</t>
</section>
<section title="Manageability Considerations" toc="default">
<section title="Control of Function and Policy" toc="default">
<t>A PCE may be deployed to act only as a backup (<xref target="SEC_PB"/>),
an operator SHOULD be able to configure a PCE as backup. </t>
</section>
<section title="Information and Data Models" toc="default">
<t><xref target="PCEP-MIB"/> describes the PCEP MIB, there are no new MIB Objects
for this document.</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 this document do not imply any new operation
verification requirements in addition to those already listed in
<xref target="RFC5440"/>.</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 this document do not have any impact on
network operations in addition to those already listed in
<xref target="RFC5440"/>.</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="October" 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="October" 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="January" year="2014" />
</front>
</reference>
<!--STATEFUL-LSPSYNC-OPT-->
<reference anchor="STATEFUL-LSPSYNC-OPT">
<front>
<title>Optimizations of Label Switched Path State Synchronization Procedures
for a Stateful PCE (draft-minei-pce-stateful-sync-optimizations)</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>
<author initials="X" surname="Zhang" fullname="Xian Zhang">
<organization />
</author>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization />
</author>
<date month="December" year="2013" />
</front>
</reference>
<!--PCEP-MIB-->
<reference anchor="PCEP-MIB">
<front>
<title>PCE communication protocol(PCEP) Management Information Base [draft-ietf-pce-pcep-mib]</title>
<author initials="A S" surname="Kiran Koushik" fullname="Kiran Koushik A S">
<organization />
</author>
<author initials="E" surname="Stephan" fullname="Stephan E">
<organization />
</author>
<author initials="Q" surname="Zhao" fullname="Quintin Zhao">
<organization />
</author>
<author initials="D" surname="King" fullname="Daniel King">
<organization />
</author>
<author initials="J" surname="Hardwick" fullname="John Hardwick">
<organization />
</author>
<date month="January" year="2014" />
</front>
</reference>
<!--STATEFUL-PCE-INTERDOMAIN-->
<reference anchor="STATEFUL-PCE-INTERDOMAIN">
<front>
<title>
Stateful Path Computation Element (PCE) Inter-domain Considerations
</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization/>
</author>
<author initials="X" surname="Zhang" fullname="Xian Zhang">
<organization/>
</author>
<date month="July" day="4" year="2014"/>
<abstract>
<t>
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-dhody-pce-stateful-pce-interdomain-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-dhody-pce-stateful-pce-interdomain-00.txt"/>
</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:11:41 |