One document matched: draft-palle-pce-stateful-pce-initiated-p2mp-lsp-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-initiated-p2mp-lsp-03"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en">
<front>
<title abbrev="INITIATED-P2MP">PCEP Extensions for
PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE
Model</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 fullname="Dhruv Dhody"
initials="D"
surname="Dhody">
<organization abbrev="Huawei Technologies">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='Y.T'
surname="Tanaka"
fullname='Yosuke Tanaka'>
<organization abbrev="NTT Communications">NTT Communications
Corporation</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>yosuke.tanaka@ntt.com</email>
</address>
</author>
<author initials='Y.K'
surname="Kamite"
fullname='Yuji Kamite'>
<organization abbrev="NTT Communications">NTT Communications
Corporation</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author initials="Z" surname="Ali" fullname="Zafar Ali">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>zali@cisco.com</email>
</address>
</author>
<date month="July"
year="2014" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element (PCE) has been identified as
an appropriate technology for the determination of the paths
of point-to-multipoint (P2MP) TE LSPs. The extensions
described in
<xref target='I-D.ietf-pce-stateful-pce'></xref> provide
stateful control of Multiprotocol Label Switching (MPLS)
Traffic Engineering Label Switched Paths (TE LSP) via PCE
communication Protocol (PCEP), for a model where the Path
Computation Client (PCC) delegates control over one or more
locally configured LSPs to the PCE. Further
<xref target='I-D.ietf-pce-pce-initiated-lsp'>
</xref> describes the creation and deletion of PCE-initiated
LSPs under the stateful PCE model. This document provides
extensions required for PCEP so as to enable the usage of a
stateful PCE initiation capability in recommending
point-to-multipoint (P2MP) TE LSP instantiation.</t>
</abstract>
</front>
<middle>
<section title="Introduction"
toc="default">
<t>As per
<xref target="RFC4655" />, the Path Computation Element (PCE)
is an entity that is capable of computing a network path or
route based on a network graph, and applying computational
constraints. A Path Computation Client (PCC) may make
requests to a PCE for paths to be computed.</t>
<t>
<xref target="RFC4857" />describes how to set up
point-to-multipoint (P2MP) Traffic Engineering Label Switched
Paths (TE LSPs) for use in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks. The PCE has
been identified as a suitable application for the computation
of paths for P2MP TE LSPs (
<xref target="RFC5671" />).</t>
<t>The PCEP is designed as a communication protocol between
PCCs and PCEs for point-to-point (P2P) path computations and
is defined in
<xref target="RFC5440" />. The extensions of PCEP to request
path computation for P2MP TE LSPs are described in
<xref target="RFC6006" />.</t>
<t>Stateful PCEs are shown to be helpful in many application
scenarios, in both MPLS and GMPLS networks, as illustrated in
<xref target='I-D.ietf-pce-stateful-pce-app'></xref>. These
scenarios apply equally to P2P and P2MP TE LSPs.
<xref target='I-D.ietf-pce-stateful-pce'></xref> provides the
fundamental extensions needed for stateful PCE to support
general functionality for P2P TE LSP. Further
<xref target='I-D.palle-pce-stateful-pce-p2mp'></xref> focuses
on the extensions that are necessary in order for the
deployment of stateful PCEs to support P2MP TE LSPs. It
includes mechanisms to effect P2MP LSP state synchronization
between PCCs and PCEs, delegation of control of P2MP LSPs to
PCEs, and PCE control of timing and sequence of P2MP path
computations within and across PCEP sessions and focuses on a
model where P2MP LSPs are configured on the PCC and control
over them is delegated to the PCE.</t>
<t>
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref> provides
the fundamental extensions needed for stateful PCE-initiated
P2P TE LSP recommended instantiation.</t>
<t>This document describes the setup, maintenance and
teardown of PCE- initiated P2MP LSPs under the stateful PCE
model, without the need for local configuration on the PCC,
thus allowing for a dynamic network that is centrally
controlled and deployed.</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>Terminology used in this document is same as terminology
used in
<xref target='I-D.ietf-pce-stateful-pce'></xref>,
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref> and
<xref target="RFC6006" />.</t>
</section>
<section title="Architectural Overview"
toc="default"
anchor="SEC_M">
<section title="Motivation"
toc="default">
<t>
<xref target='I-D.palle-pce-stateful-pce-p2mp'>
</xref> provides stateful control over P2MP TE LSPs that are
locally configured on the PCC. This model relies on the
Ingress taking an active role in delegating locally
configured P2MP TE LSPs to the PCE, and is well suited in
environments where the P2MP TE LSP placement is fairly
static. However, in environments where the P2MP TE LSP
placement needs to change in response to application
demands, it is useful to support dynamic creation and tear
down of P2MP TE LSPs. The ability for a PCE to trigger the
creation of P2MP TE LSPs on demand can be seamlessly
integrated into a controller-based network architecture,
where intelligence in the controller can determine when and
where to set up paths.</t>
<t>Section 3 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'>
</xref> further describes the motivation behind the
PCE-Initiation capability, which are equally applicable for
P2MP TE LSPs.</t>
</section>
<section title="Operation Overview"
toc="default">
<t>A PCC or PCE indicates its ability to support PCE
provisioned dynamic P2MP LSPs during the
PCEP Initialization Phase via mechanism described in
<xref target="SEC_CA" />.</t>
<t>As per section 5.1 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>, the
PCE sends a Path Computation LSP Initiate Request
(PCInitiate) message to the PCC to suggest instantiation or
deletion of a
P2P TE LSP. This document extends the PCInitiate message to
support P2MP TE LSP (see details in
<xref target="SEC_PCINIT" />).</t>
<t>P2MP TE LSP suggested instantiation and deletion operations are
same as P2P LSP as described in section 5.3
and 5.4 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>. This
document focuses on extensions needed for further handling
of P2MP TE LSP (see details in
<xref target="SEC_INST" />).</t>
</section>
</section>
<section title="Support of PCE Initiated P2MP TE LSPs"
toc="default"
anchor="SEC_CA">
<t>During PCEP Initialization Phase, as per Section 7.1.1
of <xref target='I-D.ietf-pce-stateful-pce'></xref>, PCEP
speakers advertises Stateful capability via Stateful PCE
Capability TLV in open message.
A new flag is defined for the STATEFUL-PCE-CAPABILITY TLV
defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
Its format is shown in the following figure:</t>
<figure align="left"
alt=""
height=""
suppress-title="false"
title="STATEFUL-PCE-CAPABILITY TLV Format"
width=""
anchor="SEC_FIG0">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
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 |P|M|N|D|T|I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The U (LSP-UPDATE-CAPABILITY) bit is defined in
<xref target='I-D.ietf-pce-stateful-pce'></xref>. The I
(LSP-INSTANTIATION-CAPABILITY) bit is defined in
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>.
The S (INCLUDE-DB-VERSION), T (TRIGGERED-SYNC) and D
(DELTA-LSP-SYNC-CAPABILITY) bits are defined in
<xref target='I-D.ietf-pce-stateful-sync-optimizations'></xref>.
The N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) bits
are defined in
<xref target='I-D.palle-pce-stateful-pce-p2mp'></xref>.
A new bit P (P2MP-LSP-INSTANTIATION-CAPABILITY) is added in this
document:</t>
<t>
<list style="hanging">
<t hangText="P (P2MP-LSP-INSTANTIATION-CAPABILITY - 1 bit):">
If set to 1 by a PCC, the P Flag indicates that the PCC
allows suggested instantiation of an P2MP LSP by a PCE. If
set to 1
by a PCE, the P flag indicates that the PCE will suggest
P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-CAPABILITY
flag must be set by both PCC and PCE in order to support
PCE-initiated P2MP LSP instantiation.</t>
</list>
</t>
<t>A PCEP speaker should continue to advertise the basic P2MP
capability via mechanisms as described in
<xref target="RFC6006"/>.</t>
</section>
<section title="PCE-initiated P2MP TE LSP Operations"
toc="default">
<section title="The PCInitiate message"
toc="default"
anchor="SEC_PCINIT">
<t>As defined in section 5.1 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>, PCE
sends a PCInitiate message to a PCC to recommend instantiation
of a P2P TE
LSP, this document extends the format of PCInitiate message
for the creation of P2MP TE LSPs but the creation and
deletion operations of P2MP TE LSP are same to the P2P TE
LSP.</t>
<t>The format of PCInitiate message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG3">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
<end-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>)
[<path>]
<attribute-list> is defined in [RFC5440] and extended
by PCEP extensions.
</artwork>
</figure>
<t>The PCInitiate message with an LSP object with N bit
(P2MP) set is used to convey operation on a P2MP TE LSP.
The SRP object is used to correlate between initiation
requests sent by the PCE and the error reports and state
reports sent by the PCC as described in
<xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
</section>
<section title="P2MP TE LSP Instantiation"
toc="default"
anchor="SEC_INST">
<t>The Instantiation operation of P2MP TE LSP is same as
defined in section 5.3 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>
including handling of PLSP-ID, SYMBOLIC-PATH-NAME etc.
Rules of processing and error codes remains unchanged.
Further, as defined in section 6.1 of
<xref target='I-D.palle-pce-stateful-pce-p2mp'></xref>, N
bit MUST be set in LSP object in PCInitiate message by PCE
to specify the instantiation is for P2MP TE LSP and the PCC
or PCE MUST follow the mechanism defined in
<xref target='I-D.palle-pce-stateful-pce-p2mp'></xref> for
delegation and updation of P2MP TE LSPs.</t>
<t>Though N bit is set in the LSP object,
P2MP-LSP-IDENTIFIER TLV defined in section 6.2 of
<xref target='I-D.palle-pce-stateful-pce-p2mp'></xref> MUST
NOT be included in the LSP object in PCIntiitate message as
it SHOULD be generated by PCC and carried in PCRpt message.</t>
</section>
<section title="P2MP TE LSP Deletion"
toc="default">
<t>The deletion operation of P2MP TE LSP is same as defined
in section 5.4 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref> by
sending an LSP Initiate Message with an LSP object carrying
the PLSP-ID of the LSP to be removed and an SRP object with
the R flag set (LSP-REMOVE as per section 5.2 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>).
Rules of processing and error codes remains unchanged.</t>
</section>
<section title="Adding and Pruning Leaves for the P2MP TE LSP"
toc="default">
<t>Adding of new leaves and Pruning of old Leaves for
the PCE initiated P2MP TE LSP MUST be carried in PCUpd message
and SHOULD refer <xref target='I-D.palle-pce-stateful-pce-p2mp'></xref>
for P2MP TE LSP extensions.
As defined in <xref target='RFC6006'></xref>, leaf type = 1 for
adding of new leaves, leaf type = 2 for pruning of old leaves of
P2MP END-POINTS Object are used in PCUpd message.</t>
<t>PCC MAY use the Incremental State Update mechanims as described
in <xref target='RFC4875'></xref> to signal adding and pruning
of leaves.</t>
</section>
<section title="P2MP TE LSP Delegation and Cleanup"
toc="default">
<t>P2MP TE LSP delegation and cleanup operations are same
as defined in section 6 of
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>.
Rules of processing and error codes remains unchanged.</t>
</section>
</section>
<section title="PCIntiate Message Fragmentation"
toc="default">
<t>The total PCEP message length, including the common
header, is 16 bytes. In certain scenarios the P2MP LSP
Initiate may not fit into a single PCEP message (initial
PCInitiate message). The F-bit is used in the LSP object to
signal that the initial PCInitiate was too large to fit into
a single message and will be fragmented into multiple
messages.</t>
<t>Fragmentation procedure described below for PCInitiate
message is similar to
<xref target="RFC6006"/> which describes request and response
message fragmentation.</t>
<section title="PCIntiate Fragmentation Procedure"
toc="default">
<t>Once the PCE initiates to set up the P2MP TE LSP, a
PCInitiate message is sent to the PCC. If the PCInitiate is
too large to fit into a single PCInitiate message, the PCE
will split the PCInitiate over multiple messages. Each
PCInitiate message sent by the PCE, except the last one,
will have the F-bit set in the LSP object to signify that
the PCInitiate has been fragmented into multiple messages.
In order to identify that a series of PCInitiate messages
represents a single Initiate, each message will use the
same PLSP-ID (in this case 0) and SRP-ID-number.</t>
<t>[Editor Note: P2MP message fragmentation errors
associated with a P2MP path initiation will be defined in
future version].</t>
</section>
</section>
<section title="Non-Support of P2MP TE LSP Instantiation for Stateful PCE"
toc="default">
<t>The PCEP protocol extensions described in this document
for PCC or PCE with instantiation capability for P2MP TE LSPs
MUST NOT be used if PCC or PCE has not advertised its
stateful capability with Instantiation and P2MP capability as
per
<xref target="SEC_CA" />. If this is not the case and
Stateful initiation operations on P2MP TE LSPs are attempted, then a
PCErr with error-type 19 (Invalid Operation) and error-value
TBD needs to be generated.</t>
<t>[Editor Note: more information on exact error value is
needed]</t>
</section>
<section title="Security Considerations"
toc="default">
<t>The stateful operations on P2MP TE LSP are more
CPU-intensive and also utilize more link bandwidth. In the event of
an unauthorized stateful P2MP operations, or a denial of service
attack, the subsequent PCEP operations may be disruptive
to the network. Consequently, it is important that implementations
conform to the relevant security requirements of
<xref target="RFC5440"/>, <xref target="RFC6006"/>,
<xref target='I-D.ietf-pce-stateful-pce'></xref> and
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>.</t>
</section>
<section title="Manageability Considerations"
toc="default">
<t>All manageability requirements and considerations listed in
<xref target="RFC5440"/>, <xref target="RFC6006"/>,
<xref target='I-D.ietf-pce-stateful-pce'></xref> and
<xref target='I-D.ietf-pce-pce-initiated-lsp'></xref>
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
stateful Initiation capability for P2MP LSPs.</t>
</section>
<section title="Information and Data Models"
toc="default">
<t>The PCEP MIB module
SHOULD be extended to include advertised P2MP stateful PCE-Initiation
capability etc.</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"/>, <xref target="RFC6006"/> and
<xref target='I-D.ietf-pce-stateful-pce'></xref>.</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"/>, <xref target="RFC6006"/> and
<xref target='I-D.ietf-pce-stateful-pce'></xref>.</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.
Values shown here are suggested for use by IANA.</t>
<section title="STATEFUL-PCE-CAPABILITY TLV"
toc="default">
<t>The following values are defined in this document for the
Flags field in the STATEFUL-PCE-CAPABILITY-TLV in the OPEN
object:</t>
<figure title=""
suppress-title="true"
align="left"
alt=""
width=""
height="">
<artwork xml:space="preserve"
name=""
type=""
align="left"
alt=""
width=""
height="">
<![CDATA[
Bit Description Reference
25 P2MP-LSP- This.I-D
INSTANTIATION-
CAPABILITY
]]>
</artwork>
</figure>
</section>
</section>
<section title="Acknowledgments"
toc="default">
<t>Thanks to Quintin Zhao and Venugopal Reddy for his comments.</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.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.palle-pce-stateful-pce-p2mp"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.4857.xml" ?>
<?rfc include="reference.RFC.4875.xml" ?>
<?rfc include="reference.RFC.5671.xml" ?>
<?rfc include="reference.RFC.6006.xml" ?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce-app"?>
<?rfc include="reference.I-D.ietf-pce-stateful-sync-optimizations"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:35:09 |