One document matched: draft-ietf-pce-pce-initiated-lsp-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pce-pce-initiated-lsp-01" ipr="trust200902">
<front>
<title abbrev="Stateful PCE - PCE-initiated LSP">
PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model</title>
<author fullname="Edward Crabbe" initials="E." surname="Crabbe">
<organization>Google, Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>edc@google.com</email>
</address>
</author>
<author fullname="Ina Minei" initials="I." surname="Minei">
<organization>Google, Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>inaminei@google.com</email>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>msiva@cisco.com</email>
</address>
</author>
<author fullname="Robert Varga" initials="R." surname="Varga">
<organization>Pantheon Technologies SRO</organization>
<address>
<postal>
<street>Mlynske Nivy 56</street>
<city>Bratislava</city>
<code>821 05</code>
<country>Slovakia</country>
</postal>
<email>robert.varga@pantheon.sk</email>
</address>
</author>
<date day="6" month="June" year="2014" />
<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>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 PCEP, for a model where
the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes
the creation and deletion of PCE-initiated LSPs under the stateful PCE model. </t>
</abstract>
<note title="Requirements Language">
<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>
</note>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC5440"/> describes the Path Computation Element
Protocol PCEP. PCEP defines the communication between a Path Computation
Client (PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP) characteristics.
</t>
<t><xref target='I-D.ietf-pce-stateful-pce'>Stateful pce</xref> specifies a
set of extensions to PCEP to enable stateful
control of TE LSPs between and across PCEP sessions in compliance with
<xref target="RFC4657"/>. It includes mechanisms to effect LSP state
synchronization between PCCs and PCEs, delegation of control of LSPs to
PCEs, and PCE control of timing and sequence of path computations within
and across PCEP sessions and focuses on a model where LSPs are configured on the PCC
and control over them is delegated to the PCE.
</t>
<t> This document describes the setup, maintenance and teardown of PCE-initiated
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> <!-- Introduction -->
<section title="Terminology">
<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.ietf-pce-stateful-pce'></xref>: Stateful PCE,
Delegation, Redelegation Timeout, State Timeout Interval LSP State Report, LSP
Update Request.
</t>
<t>The following terms are defined in this document:
<list style="hanging">
<t hangText="PCE-initiated LSP:"> LSP that is instantiated as a result of a request from the PCE.</t>
</list>
</t>
<t>The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in <xref
target="RFC5511"/>.
</t>
</section> <!-- Terminology -->
<section anchor="Overview" title="Architectural Overview">
<section anchor="Motivation" title="Motivation">
<t><xref target='I-D.ietf-pce-stateful-pce'></xref> provides stateful control over LSPs
that are locally configured on the PCC. This model relies on the LER taking an active role
in delegating locally configured LSPs to the PCE, and is well suited in environments where
the LSP placement is fairly static. However, in environments where the LSP placement needs to change in response to
application demands, it is useful to support dynamic creation and tear down of LSPs.
The ability for a PCE to trigger the creation of LSPs on demand can make possible agile
software-driven network operation, and 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>A possible use case is one of a software-driven network, where applications request
network resources and paths from the network infrastructure. For example, an application can
request a path with certain constraints between two LSRs by contacting the PCE. The PCE can
compute a path satisfying the constraints, and instruct
the head end LSR to instantiate and signal it. When the path is no longer required by the application,
the PCE can request its teardown.</t>
<t> Another use case is one of dynamically adjusting aggregate bandwidth between two points
in the network using multiple LSPs. This functionality is very similar to auto-bandwidth, but
allows for providing the desired capacity through multiple LSPs. This approach overcomes two of
the limitations auto-bandwidth can experience: 1) growing the capacity between the endpoints
beyond the capacity of individual links in the path and 2) achieving good bin-packing through
use of several small LSPs instead of a single large one. The number of LSPs varies based on
the demand, and LSPs are created and deleted dynamically to satisfy the bandwidth requirements.</t>
<t> Another use case is that of demand engineering, where a PCE with visibility into both the network state and the
demand matrix can anticipate and optimize how traffic is distributed across the infrastructure. Such optimizations may
require creating new paths across the infrastructure. </t>
</section><!-- Motivation -->
<section anchor="Operation-overview" title="Operation overview">
<t>A PCC or PCE indicates its ability to support PCE provisioned dynamic LSPs during the PCEP
Initialization Phase via a new flag in the STATEFUL-PCE-CAPABILITY TLV (see details in
<xref target="Capability-TLV"/>).
</t>
<t>The decision when to instantiate or delete a PCE-initiated LSP is out of the scope of this document.
To instantiate or delete an LSP, the PCE sends a new message, the Path Computation
LSP Initiate Request (PCInitiate)
message to the PCC. The LSP Initiate Request MUST include the SRP and LSP objects, and the LSP object
MUST include the Symbolic Path Name TLV and MUST have a PLSP-ID of 0. </t>
<t>For an instantiation operation, the PCE MUST include the ERO and END-POINTS object and may include
various attributes as per <xref target="RFC5440"/>. The PCC creates the LSP using
the attributes communicated by the
PCE, and local values for the unspecified parameters. It assigns a unique PLSP-ID for the
LSP and automatically delegates the LSP to the PCE. It also generates
an LSP State Report (PCRpt) for the LSP, carrying the newly assigned PLSP-ID and
indicating the delegation via the Delegate flag in the LSP object. In addition to the
Delegate flag, the PCC also sets the Create flag in the LSP object (see <xref target="create-flag"/>),
to indicate that the LSP was created as a result of a PCinitiate message.
This PCRpt message MUST include the SRP object,
with the SRP-id-number used in the SRP object of the PCInitate message.
The PCE may update the attributes of the LSP via subsequent PCUpd messages.
Subsequent LSP State Report and LSP Update Request for the LSP
will carry the PCC-assigned PLSP-ID, which uniquely identifies the LSP.
See details in <xref target="lsp-instantiation"/>.
</t>
<t> Once instantiated, the delegation procedures for PCE-initiated LSPs are the same as for PCC
initiated LSPs as described in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
This applies to the case of a PCE failure as well. In order to allow for
network cleanup without manual intervention, the PCC SHOULD support removal of PCE-initiated LSPs
as one of the behaviors applied on expiration of the State Timeout Interval
<xref target='I-D.ietf-pce-stateful-pce'></xref>. The behavior SHOULD be picked based on local
policy, and can result either in LSP removal, or into reverting to operator-defined
default parameters. See details in <xref target="Delegation-and-cleanup"/>. A PCE may return a
delegation to the PCC in order to facilitate re-delegation of its LSPs to an alternate PCE.
</t>
<t>To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a
PCUpd message. As a
result of the deletion request, the PCC MUST remove all state related to the LSP, and send
a PCRpt with the R flag set in the LSP object for the removed state.
See details in <xref target="lsp-deletion"/>.
</t>
</section><!-- Operation overview -->
</section><!-- Overview -->
<section anchor="Capability-negotiation" title="Support of PCE-initiated LSPs">
<t>A PCC indicates its ability to support PCE provisioned dynamic LSPs during the
PCEP Initialization phase. The Open Object in the Open message contains the "Stateful
PCE Capability" TLV, defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag is introduced to indicate support
for instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only
for PCCs that advertised this capability and a PCC will follow the procedures described
in this document only on sessions where the PCE advertised the I flag. </t>
<section anchor="Capability-TLV" title="Stateful PCE Capability TLV">
<t>The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
following figure:</t>
<figure anchor="Capability-TLV-Fmt" title="STATEFUL-PCE-CAPABILITY TLV format">
<artwork><![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=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
]]></artwork>
</figure>
<t>The type of the TLV is defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>
and it has a fixed length of 4 octets.</t>
<t>The value comprises a single field - Flags (32 bits). The U and S
bits are defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
<list style="hanging">
<t hangText="I (LSP-INSTANTIATION-CAPABILITY - 1 bit):"> If set to 1 by a
PCC, the I Flag indicates that the PCC allows instantiation of an LSP
by a PCE. If set to 1 by a PCE, the I flag indicates that the PCE will
attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY flag must be
set by both PCC and PCE in order to support PCE-initiated LSP instantiation.
</t>
</list>
</t>
<t>Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
</t>
</section> <!-- Capability TLV -->
</section> <!-- Capability negotiation -->
<section anchor="PCE-initiated-LSP-instantiation-deletion" title="PCE-initiated LSP instantiation and deletion">
<t> To initiate an LSP, a PCE sends a PCInitiate message to a PCC.
The message format, objects and TLVs are discussed separately below for the creation and
the deletion cases. </t>
<section anchor="LSP-initiate" title ="The LSP Initiate Message">
<t>A Path Computation LSP Initiate Message (also referred to as
PCInitiate message) is a PCEP message sent by a PCE to a PCC to trigger LSP
instantiation or deletion. The Message-Type field of the PCEP common header for the PCInitiate
message is set to [TBD]. The PCInitiate message MUST include the SRP and the LSP objects,
and may contain other objects, as discussed later in this section. If either the SRP or the
LSP object is missing, the PCC MUST send a PCErr as described in
<xref target='I-D.ietf-pce-stateful-pce'></xref>.
LSP instantiation is done by sending an LSP Initiate Message with an LSP object with the
reserved PLSP-ID 0. LSP deletion is done 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 (see <xref target="SRP-R-flag"/>). </t>
<t>The format of a PCInitiate message for LSP instantiation is as follows:</t>
<figure>
<artwork><![CDATA[
<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-POINTS>
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
]]></artwork>
</figure>
<t> 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. Every request
from the PCE receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an
operation (initiation, update, etc) is requested from the PCE. The value of
the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt messages
to allow for correlation between requests made by the PCE and errors or
state reports generated by the PCC. Details of the SRP object and its use can be found in
<xref target='I-D.ietf-pce-stateful-pce'></xref>.</t>
</section> <!-- LSP initiate message -->
<section anchor="SRP-R-flag" title ="The R flag in the SRP Object">
<t>The format of the SRP object is shown <xref target="SRP-Object-Fmt"/>:</t>
<figure anchor="SRP-Object-Fmt" title="The SRP Object format">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The type object is defined in <xref target='I-D.ietf-pce-stateful-pce'></xref>. </t>
<t>A new flag is defined to indicate a delete operation initiated by the PCE:
<list style="hanging">
<t hangText="R (LSP-REMOVE - 1 bit):">
If set to 1, it indicates a removal request initiated by the PCE.
</t>
</list>
</t>
</section> <!-- SRP-R-flag -->
<section anchor="lsp-instantiation" title ="LSP instantiation">
<t>LSP instantiation is done by sending an LSP Initiate Message with an LSP object with the
reserved PLSP-ID 0. The LSP is set up using RSVP-TE, extensions for other setup methods
are outside the scope of this draft.</t>
<t>Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R flag
in the SRP object set to zero results in a PCErr message of type 19
(Invalid Operation) and value 8 (non-zero PLSP-ID in LSP initiation request).</t>
<t>The END-POINTS Object is mandatory for an instantiation request of an RSVP-signaled LSP.
It contains the source and destination addresses for provisioning the LSP.
If the END-POINTS Object is missing, the PCC MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=3 (END-POINTS Object missing). </t>
<t>The ERO Object is mandatory for an instantiation request. It contains the ERO for the LSP.
If the ERO Object is missing, the PCC MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=9 (ERO Object missing). </t>
<t>The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be used to correlate between the
PCC-assigned PLSP-ID and the LSP.
If the TLV is missing, the PCC MUST send a PCErr message with Error-type=6(Mandatory object missing)
and Error-value=14 (SYMBOLIC-PATH-NAME TLV missing). The symbolic name used for provisioning PCE-initiated
LSPs must not
have conflict with the LSP name of any existing LSP in the PCC. (Existing LSPs may be either statically
configured, or initiated by another PCE). If there is conflict with the LSP name, the PCC MUST send a
PCErr message with Error-type=23 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The
only exception to this rule is for LSPs for which the State timeout timer is running
(see <xref target="Delegation-and-cleanup"/>).</t>
<t> The PCE MAY include various attributes as per <xref target="RFC5440"/>. The PCC MUST use these
values in the LSP instantiation, and local values for unspecified parameters. After the LSP setup,
the PCC MUST send a PCRpt to the PCE, reflecting these values. The SRP object in the PCRpt message
MUST echo the value of the PCInitiate message that triggered the setup. LSPs that were instantiated
as a result of a PCInitiate message MUST have the C flag set in the LSP object. </t>
<t> If the PCC determines that the LSP parameters proposed in the PCInitiate message are
unacceptable, it MUST trigger a PCErr with error-type=TBD (PCE instantiation error)
and error-value=1 (Unacceptable instantiation parameters).
If the PCC encounters an internal error during the processing of the PCInitiate message, it MUST
trigger a PCErr with error-type=TBD (PCE instantiation error) and error-value=2 (Internal error).</t>
<t> A PCC MUST relay to the PCE errors it encounters in the setup of PCE-initiated LSP by sending
a PCErr with error-type=TBD (PCE instantiation error) and error-value=3 (RSVP signaling error).
The PCErr MUST echo the SRP-id-number of the PCInitiate message. The PCEP-ERROR object
SHOULD include the RSVP Error Spec TLV (if an ERROR SPEC was returned to the PCC by a downstream node).
After the LSP is set up, errors in RSVP signaling are reported in PCRpt messages, as described in
<xref target='I-D.ietf-pce-stateful-pce'></xref>. </t>
<t>A PCC SHOULD be able to place a limit on either the
number of LSPs or the percentage of resources that are allocated to honor PCE-initiated
LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message
of type 19 (Invalid Operation) and value TBD "PCE-initiated limit reached"
and is free to drop any incoming PCInitiate messages without additional processing.</t>
<t>Similarly, the PCE SHOULD be able to place a limit on either the number of LSP initiation requests
pending for a particular PCC, or on the time it waits for a response (positive or negative) to a PCInitiate
request from a PCC and MAY take further action (such as closing the session or removing all its
LSPs) if this limit is reached. </t>
<t>On succesful completion of the LSP instantiation, the PCC assigns a PLSP-ID, and immediately
delegates the LSP to the PCE by sending a PCRpt with the Delegate flag set.
The PCRpt MUST include the SRP-ID-number of the PCInitiate request that
triggered its creation. PCE-initiated LSPs are identified with the Create flag in the LSP Object.
</t>
<section anchor="create-flag" title ="The Create flag">
<t> The LSP object is defined in <xref target='I-D.ietf-pce-stateful-pce'></xref> and
included here for easy reference. </t>
<figure anchor="LSP-Object-Fmt" title="The LSP Object format">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flags |C| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> A new flag, the Create (C) flag is introduced. On a PCRpt message, the
C Flag set to 1 indicates that this LSP was created via a PCInitiate message. The
C Flag MUST be set to 1 on each PCRpt message for the duration of existence of
the LSP. The Create flag allows PCEs to be aware of which LSPs were PCE-initiated (a state
that would otherwise only be known by the PCC and the PCE that initiated them). </t>
</section> <!-- The create flag -->
</section> <!-- LSP instantiation -->
<section anchor="lsp-deletion" title ="LSP deletion">
<t>PCE-initiated removal of a PCE-initiated LSP is done by setting the R (remove) flag
in the SRP Object in the PCInitiate message from the PCE. The LSP is identified by the PLSP-ID
in the LSP object. If the PLSP-ID is unknown, the PCC MUST
generate a PCErr with error type 19, error value 3, "Unknown PLSP-ID". A PLSP-ID of zero removes
all LSPs that were initiated by the PCE. If the PLSP-ID specified in the PCInitiate message is not
delegated to the PCE, the PCC MUST send a PCErr message indicating "LSP is not delegated" (Error code
19, error value 1 (<xref target='I-D.ietf-pce-stateful-pce'></xref>). If the PLSP-ID specified in the
PCInitiate message was not created by the PCE, the PCC MUST send a PCErr message indicating "LSP is not
PCE initiated" (Error code 19, error value TBD).
Following the removal of the LSP,
the PCC MUST send a PCRpt as described in <xref target='I-D.ietf-pce-stateful-pce'></xref>.
The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that
triggered the removal. The R flag in the SRP object SHOULD be set. </t>
</section> <!-- LSP deletion -->
</section> <!-- lsp initiation and deletion -->
<section anchor="Delegation-and-cleanup" title="LSP delegation and cleanup">
<t>PCE-initiated LSPs are automatically delegated by the PCC to the PCE upon instantiation.
The PCC MUST delegate the LSP to the PCE by setting the delegation bit to 1 in the PCRpt
that includes the assigned PLSP-ID. All subsequent messages from the PCC must have the
delegation bit set to 1. The PCC cannot revoke the delegation for PCE-initiated LSPs
for an active PCEP session. Sending a PCRpt message with the delegation bit set to
0 results in a PCErr message of type 19 (Invalid Operation) and value TBD
"Delegation for PCE-initiated LSP cannot be revoked". The PCE MAY further react by closing
the session. </t>
<t> A PCE MAY return a delegation to the PCC, to allow for LSP transfer between PCEs. Doing so
MUST trigger the State Timeout Interval timer (<xref target='I-D.ietf-pce-stateful-pce'></xref>).
</t>
<t> In case of PCEP session failure, control over PCE-initiated LSPs reverts to the PCC
at the expiration of the redelegation timeout. To obtain control of a PCE-initiated LSP,
a PCE (either the original or one of its backups) sends
a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID of the LSP
it wants to take control of. Receipt of a PCInitiate message with a non-zero PLSP-ID normally
results in the generation of a PCErr. If the State Timeout timer is running, the PCC MUST NOT
generate an error and redelegate the LSP to the PCE. The State Timeout timer is stopped upon the
redelegation. After obtaining control of the LSP, the PCE may remove it using the procedures described
in this document. </t>
<t>The State Timeout timer ensures that a PCE crash does not result in automatic and immediate
disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not be removed
immediately upon PCE failure. Instead, they are cleaned
up on the expiration of this timer. This allows for network cleanup without manual intervention.
The PCC SHOULD support removal of PCE-initiated LSPs
as one of the behaviors applied on expiration of the State Timeout Interval
<xref target='I-D.ietf-pce-stateful-pce'></xref>. The behavior SHOULD be picked based on local
policy, and can result either in LSP removal, or into reverting to operator-defined
default parameters.</t>
</section><!--Delegation-and-cleanup -->
<section anchor="Implementation-status" title="Implementation status">
<t> This section to be removed by the RFC editor. </t>
<t>
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in RFC
6982. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.
</t>
<t>
According to RFC 6982, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".
</t>
<t>
Two vendors are implementing the extensions described in this draft and
have included the functionality in releases that will be shipping in the near
future. An additional entity is working on implementing these extensions in the
scope of research projects.
</t>
</section>
<section anchor="IANA-considerations" title="IANA considerations">
<section anchor="PCEP-Msg-Codepoints" title="PCEP Messages">
<t>This document defines the following new PCEP messages:</t>
<texttable anchor="PCEP-New-Msg-CP" style="none" suppress-title="true">
<ttcol align="center" width='20%'>Value</ttcol>
<ttcol align="left" width='30%'>Meaning </ttcol>
<ttcol align="left" width='50%'>Reference </ttcol>
<c>12</c><c> Initiate</c><c>This document</c>
</texttable>
</section>
<section anchor="LSP-Object-CP" title="LSP Object">
<t>The following values are defined in this document for the Flags field in the
LSP Object. </t>
<texttable anchor="LSP-Object-Flags" style="none" suppress-title="true">
<ttcol align="center" width='15%'>Bit</ttcol>
<ttcol align="left" width='30%'>Description </ttcol>
<ttcol align="left" width='55%'>Reference </ttcol>
<c></c><c> </c><c></c>
<c>24</c><c>Create</c><c>This document</c>
</texttable>
</section> <!-- LSP object code point -->
<section anchor="PCEP-Error-Object" title="PCEP-Error Object">
<t>This document defines new Error-Type and Error-Value for the following
new error conditions:
<vspace blankLines="1" />
<?rfc subcompact="yes"?>
<list style="hanging" hangIndent="13">
<t hangText=" Error-Type">Meaning</t>
<t hangText=" 6">Mandatory Object missing
<list style="hanging" hangIndent="17">
<t hangText=" Error-value=13:">LSP cleanup TLV missing</t>
<t hangText=" Error-value=14:">SYMBOLIC-PATH-NAME TLV missing</t>
</list>
</t>
<t hangText=" 19">Invalid operation
<list style="hanging" hangIndent="17">
<t hangText=" Error-value=6:"> PCE-initiated LSP limit reached</t>
<t hangText=" Error-value=7:"> Delegation for PCE-initiated LSP cannot be revoked</t>
<t hangText=" Error-value=8:"> Non-zero PLSP-ID in LSP initiation request</t>
</list>
</t>
<t hangText=" 23">Bad parameter value
<list style="hanging" hangIndent="17">
<t hangText=" Error-value=1:">SYMBOLIC-PATH-NAME in use</t>
</list>
</t>
<t hangText=" 24">LSP instantiation error
<list style="hanging" hangIndent="17">
<t hangText=" Error-value=1:">Unacceptable instantiation parameters </t>
<t hangText=" Error-value=2:">Internal error </t>
<t hangText=" Error-value=3:">RSVP signaling error </t>
</list>
</t>
</list>
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t> The security considerations described in <xref target='I-D.ietf-pce-stateful-pce'></xref>
apply to the extensions described in this document. Additional considerations
related to a malicious PCE are introduced. </t>
<section anchor="Malicious-PCE" title="Malicious PCE">
<t> The LSP instantiation mechanism described in this document allows a PCE to
generate state on the PCC and throughout the network. As a result, it
introduces a new attack vector: an attacker may flood the PCC with LSP
instantiation requests and consume network and LSR resources, either by spoofing messages or
by compromising the PCE itself.</t>
<t>A PCC can protect itself from such an attack by imposing a limit on either the
number of LSPs or the percentage of resources that are allocated to honor PCE-initiated
LSP requests. As soon as that limit is reached, the PCC MUST send a PCErr message
of type 19 (Invalid Operation) and value 3 "PCE-initiated LSP limit reached"
and is free to drop any incoming PCInitiate messages for LSP instantiation without additional processing.</t>
<t> Rapid flaps triggered by the PCE can also be an attack vector. This will be discussed
in a future version of this document.</t>
</section><!-- Malicious PCE -->
<section anchor="Malicious-PCC" title="Malicious PCC">
<t> The LSP instantiation mechanism described in this document requires the PCE to keep state
for LSPs that it instantiates and relies on the PCC responding (with either a state report or
an error message) to requests for LSP instantiation. A malicious PCC or one that reached the limit
of the number of PCE-initiated LSPs, can ignore PCE requests and
consume PCE resources. A PCE can protect itself by imposing a limit on the number of requests
pending, or by setting a timeout and it MAY take further action such as closing the session or
removing all the LSPs it initiated.</t>
</section><!-- Malicious PCC-->
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, Dhruv Dhody, and Raveendra Trovi for
their contributions to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5088.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5089.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3346.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5394.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5557.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:51:13 |