Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEOracle1501 4th Ave, suite 1800SeattleWA98101United States of Americaedward.crabbe@oracle.comGoogle, Inc.1600 Amphitheatre ParkwayMountain ViewCA94043United States of Americainaminei@google.comCisco Systems, Inc.170 West Tasman Dr.San JoseCA95134United States of Americajmedved@cisco.comPantheon Technologies SROMlynske Nivy 56Bratislava821 05Slovakiarobert.varga@pantheon.techPCE Working GroupThe Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information
available to the PCE, it also makes no provisions for
PCE control of timing and sequence of path computations within and across
PCEP sessions. This document describes a set of extensions to PCEP to
enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. describes the Path Computation Element
Communication Protocol (PCEP). PCEP defines 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 Path (TE LSP) characteristics. Extensions for
support of Generalized MPLS (GMPLS) in PCEP are defined in . This document specifies a set of extensions to PCEP to enable stateful
control of LSPs within and across PCEP sessions in compliance with
. It includes mechanisms to effect Label Switched
Path (LSP) State
Synchronization between PCCs and PCEs, delegation of control over LSPs to
PCEs, and PCE control of timing and sequence of path computations within
and across PCEP sessions.Extensions to permit the PCE to drive creation of an LSP are defined
in , which specifies
PCE-initiated LSP creation. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
This document uses the following terms defined in : PCC, PCE, PCEP Peer, and PCEP speaker.This document uses the following terms defined in : Traffic Engineering Database (TED).This document uses the following terms defined in : LSP. This document uses the following terms defined in
:
Stateful PCE, Passive Stateful PCE, Active Stateful PCE,
Delegation, and LSP State Database. The following terms are defined in this document:
an operation performed by a PCC on a
previously delegated LSP. Revocation revokes the rights granted to the
PCE in the delegation operation. the period of time
a PCC waits
for, when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the
terminated
PCEP session to an alternate PCE. The Redelegation
Timeout Interval is a PCC-local value that can be either
operator configured or dynamically computed by the PCC based on local
policy. the period of time a PCC waits
for,
when a PCEP session is terminated, before flushing LSP state associated
with that PCEP session and reverting to operator-defined default
parameters or behaviors. The State
Timeout Interval is a PCC-local value that can be either
operator configured or dynamically computed by the PCC based on local
policy. an operation to send LSP state
(operational/administrative status, LSP attributes configured at the
PCC and set by a PCE, etc.) from a PCC to a PCE. an operation where an Active
Stateful PCE requests a
PCC to update one or more attributes of an LSP and to re-signal the LSP
with updated attributes.a number used to correlate errors and
LSP State Reports to LSP Update Requests.
It is carried in the Stateful PCE Request Parameter (SRP) object described in
.
Within this document, PCEP communications are described through
PCC-PCE relationships. The PCE architecture also supports PCE-PCE
communication, by having the requesting PCE fill the role of a PCC, as usual. The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in . presents several use cases,
demonstrating scenarios that benefit from the deployment of a stateful
PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments.
Traffic engineering has been a goal of the MPLS architecture since
its inception . In the traffic engineering system provided
by , , and , information about network resources utilization is
only available as total reserved capacity by the traffic class on a per-interface
basis; individual LSP state is available only locally on
each Label Edge Router (LER) for its own LSPs. In most cases, this makes good sense, as
distribution and retention of total LSP state for all LERs within in
the network would be prohibitively costly.Unfortunately, this visibility in terms of global LSP state may
result in a number of issues for some demand patterns, particularly
within a common setup and hold priority. This issue affects online
traffic engineering systems.A sufficiently over-provisioned system will by definition have no
issues routing its demand on the shortest path. However, lowering the
degree to which network over-provisioning is required in order to run
a healthy, functioning network is a clear and explicit promise of MPLS
architecture. In particular, it has been a goal of MPLS to provide
mechanisms to alleviate congestion scenarios in which "traffic streams
are inefficiently mapped onto available resources; causing subsets of
network resources to become over-utilized while others remain
underutilized" . defines a stateful PCE to be one in which
the PCE maintains "strict synchronization between the PCE and not only
the network states (in term of topology and resource information), but
also the set of computed paths and reserved resources in use in the
network." also expressed a number of concerns
with regard to a stateful PCE, specifically:
Any reliable synchronization mechanism would result in
significant control-plane overheadOut-of-band TED synchronization would be complex and prone to
race conditionsPath calculations incorporating total network state would be
highly complexIn general, stress on the control plane will be directly
proportional to the size of the system being controlled and the
tightness of the control loop and indirectly proportional to the
amount of over-provisioning in terms of both network capacity and
reservation overhead.Despite these concerns in terms of implementation complexity and
scalability, several TE algorithms exist today that have been
demonstrated to be extremely effective in large TE systems, providing
both rapid convergence and significant benefits in terms of optimality
of resource usage . All of these systems share
at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for ordered
control of path reservations across devices within the system being
controlled. While some approaches have been suggested in order to
remove the requirements for ordered control (see ), these approaches are highly dependent on traffic
distribution and do not allow for multiple simultaneous LSP
priorities representing diffserv classes.The use cases described in
demonstrate a need for visibility into
global inter-PCC LSP state in PCE path computations and for PCE
control of sequence and timing in altering LSP path characteristics
within and across PCEP sessions. Note that existing configuration tools and protocols can be used to
set LSP state, such as a Command Line Interface (CLI) tool. However,
this solution has several shortcomings:
Scale & Performance: configuration operations often have
transactional semantics that are typically heavyweight and often
require
processing of additional configuration portions beyond the state
being directly acted upon, with corresponding cost in CPU cycles,
negatively impacting both PCC stability LSP Update rate
capacity. Security: when a PCC opens a configuration channel allowing a PCE
to send configuration, a malicious PCE may take advantage of this ability to
take over the PCC. In contrast, the PCEP extensions described in
this document only allow a PCE control over a very limited set of
LSP attributes.Interoperability: each vendor has a proprietary information model
for configuring LSP state, which limits interoperability of a
stateful PCE
with PCCs from different vendors. The PCEP extensions described in
this document allow for a common information model for LSP state for
all vendors. Efficient State Synchronization: configuration channels may be
heavyweight and unidirectional; therefore, efficient State
Synchronization between a PCC and a PCE may be a problem.The objectives for the protocol extensions to support stateful PCE
described in this document are as follows:
Allow a single PCC to interact with a mix of stateless and stateful
PCEs simultaneously using the same protocol, i.e., PCEP.Support efficient LSP State Synchronization between the PCC and one
or more active or passive stateful PCEs.Allow a PCC to delegate control of its LSPs to an active stateful
PCE such that a given LSP is under the control of a single PCE at any
given time.
A PCC may revoke this delegation at any time during the
lifetime of the LSP. If LSP delegation is revoked while the PCEP
session is up, the PCC MUST notify the PCE about the revocation.A PCE may return an LSP delegation at any point during the lifetime of the
PCEP session. If LSP delegation is returned by the PCE while the PCEP
session is up, the PCE MUST notify the PCC about the returned delegation.Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it.Enable uninterrupted operation of a PCC's LSPs in the event of a PCE
failure or while control of LSPs is being transferred between
PCEs.Several new functions are required in PCEP to support stateful
PCEs. A function can be initiated either from a PCC towards a PCE (C-E) or
from a PCE towards a PCC (E-C). The new functions are:
both the PCC and the
PCE must announce during PCEP session establishment that they support
PCEP Stateful PCE extensions defined in this document. after the session
between the PCC and a stateful PCE is initialized, the PCE must learn
the state of a PCC's LSPs before it can perform path computations or
update LSP attributes in a PCC.
a PCE requests modification of
attributes on a PCC's LSP. a PCC sends an LSP State Report
to a PCE whenever the state of an LSP changes. a PCC grants to a PCE
the right to update LSP attributes on one or more LSPs; the PCE becomes
the authoritative source of the LSP's attributes as long as the
delegation is in effect (see ); the PCC may
withdraw the delegation or the PCE may give up the delegation at any
time. Similarly to , no assumption is made about the
discovery method used by a PCC to discover a set of PCEs (e.g., via static
configuration or dynamic discovery) and on the algorithm used to select a PCE.
In PCEP (defined in ), LSP state
and operation are under the control of a PCC (a PCC may be a Label Switching Router (LSR) or a
management station). Attributes received from a PCE are subject to PCC's
local policy. The PCEP extensions described in this document do
not change this behavior.An active stateful PCE may have control of a PCC's LSPs that were delegated
to it, but the LSP state ownership is retained by the PCC. In
particular, in addition to specifying values for LSP's attributes, an
active stateful PCE also decides when to make LSP modifications.Retaining LSP state ownership on the PCC allows for:
a PCC to interact with both stateless and stateful PCEs at the same
timea stateful PCE to only modify a small subset of LSP parameters,
i.e., to set only a small subset of the overall LSP state; other
parameters may be set by the operator, for example,
through CLI commandsa PCC to revert delegated LSP to an operator-defined default or to
delegate the LSPs to a different PCE, if the PCC gets disconnected from
a PCE with currently delegated LSPsIn this document, we define the following new PCEP messages:
a PCEP message
sent by a PCC to a PCE to report the status of one or more LSPs. Each
LSP State Report in a PCRpt message MAY contain the actual LSP's
path, bandwidth, operational and administrative status, etc. An LSP
Status Report carried on a PCRpt message is also used in delegation or
revocation of control of an LSP to/from a PCE. The PCRpt message is
described in . a PCEP message
sent by a PCE to a PCC to update LSP parameters, on one or more LSPs.
Each LSP Update Request on a PCUpd message MUST contain all LSP
parameters that a PCE wishes to be set for a given LSP. An LSP Update
Request carried on a PCUpd message is also used to return LSP
delegations if at any point PCE no longer desires control of an LSP.
The PCUpd message is described in .The new functions defined in are mapped
onto the new messages as shown in the following table. FunctionMessageCapability Advertisement (E-C,C-E)OpenState Synchronization (C-E)PCRptLSP State Report (C-E)PCRptLSP Control Delegation (C-E,E-C)PCRpt, PCUpdLSP Update Request (E-C)PCUpd
Error reporting is done using the procedures defined in
and reusing the applicable error types
and error values
of wherever appropriate. The current document
defines new error values for several error types to cover failures
specific to stateful PCE.
During the PCEP initialization phase, PCEP speakers (PCE or PCC)
advertise their support of PCEP Stateful PCE extensions. A PCEP speaker includes
the "STATEFUL-PCE-CAPABILITY TLV", described in , in the OPEN object to advertise its support
for PCEP Stateful PCE extensions.
The STATEFUL-PCE-CAPABILITY TLV includes the
'LSP Update' flag that indicates whether the PCEP speaker supports LSP
parameter updates.The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object
indicates that the PCC is willing to send LSP State Reports whenever LSP
parameters or operational status changes.The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes.The PCEP extensions for stateful PCEs MUST NOT be used if
one or both PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV
in their respective OPEN message. If the PCEP speaker on the PCC supports the
extensions of this specification but did not advertise this capability, then upon receipt
of a PCUpd message from the PCE, it MUST generate a PCEP Error (PCErr) with
Error-type=19 (Invalid Operation) and error-value 2 (Attempted LSP Update Request if
the stateful PCE capability was not advertised)(see ), and it SHOULD terminate the PCEP session. If the PCEP
Speaker on the PCE supports the extensions of this specification but did not
advertise this capability,
then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr
with Error-type=19
(Invalid Operation) and error-value 5 (Attempted LSP State Report if
stateful PCE capability was
not advertised) (see ), and it SHOULD
terminate the PCEP session.LSP delegation and LSP Update operations defined in this document may
only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag in the
STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'. If this is
not the case and LSP delegation or LSP Update operations are attempted,
then a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted
LSP Update Request for a non-delegated LSP) (see ) MUST be generated. Note that, even if one of
the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its STATEFUL-PCE-CAPABILITY TLV,
a PCE can still operate as a passive stateful PCE by accepting LSP
State Reports from the PCC in order to build and maintain an up-to-date view of
the state of the PCC's LSPs.
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the advertisement
of PCE Discovery Information are defined for OSPF and for
IS-IS in and
, respectively.
The PCE-CAP-FLAGS sub-TLV, defined in ,
is an optional sub&nbhy;TLV used to advertise
PCE capabilities. It MAY be present within the PCE Discovery (PCED) sub-TLV carried
by OSPF or IS-IS. and
provide the description
and processing rules for this sub&nbhy;TLV when carried within OSPF and
IS-IS, respectively.
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference:
5 Multiple of 4.This contains an array of units of
32-bit flags with the most significant bit as 0.
Each bit represents one PCE capability.
PCE capability bits are defined in . This document defines
new capability bits for the stateful PCE as follows:
BitCapability ----------------------------------11 Active stateful PCE capability12 Passive stateful PCE capability
Note that while active and passive stateful PCE capabilities may be
advertised during discovery, PCEP speakers that wish to use stateful
PCEP MUST negotiate stateful PCEP capabilities during PCEP session
setup, as specified in the current document.
A PCC MAY initiate stateful PCEP capability negotiation at PCEP
session setup even if it did not receive any IGP PCE capability
advertisements.
The purpose of State Synchronization is to provide a
checkpoint&nbhy;in&nbhy;time state replica of a PCC's LSP state in a PCE. State
Synchronization is performed immediately after the initialization phase
. During State Synchronization, a PCC first takes a snapshot of the state of its LSPs, then it sends the snapshot to a PCE in a sequence
of LSP State Reports. Each LSP State Report sent during State
Synchronization has the SYNC flag in the LSP object set to 1. The set of
LSPs for which state is synchronized with a PCE is determined by
the PCC's local configuration (see more details in )
and MAY also be determined by stateful PCEP capabilities defined
in other documents, such as . The end of the synchronization marker is a PCRpt message with the SYNC
flag set to 0 for an LSP object with PLSP-ID equal to the reserved value
0 (see ).
In this case, the LSP object SHOULD NOT include the
SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP-IDENTIFIERS TLV
with the special value of all zeroes. The PCRpt message MUST include
an empty Explicit Route Object (ERO) as its intended path and SHOULD NOT include the
optional Record Route Object (RRO) for its actual path.
If the PCC has no state to synchronize, it SHOULD only send the
end of the synchronization marker. A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a
PCE before State Synchronization is complete. This is to allow the PCE
to get the best possible view of the network before it starts computing
new paths. Either the PCE or the PCC MAY terminate the session using the PCEP
session termination procedures during the synchronization phase.
If the session is terminated, the PCE MUST clean up the state it received
from this PCC. The session re-establishment MUST be re&nbhy;attempted per the procedures
defined in , including use of a backoff timer.If the PCC encounters a problem that prevents it from completing the
LSP State Synchronization, it MUST send a PCErr message with error&nbhy;type 20 (LSP
State Synchronization Error) and error-value 5 (indicating an internal
PCC error) to the PCE and terminate the session. The PCE does not send positive acknowledgments for properly received
synchronization messages. It MUST respond with a PCErr message with
Error-type=20 (LSP State Synchronization Error) and error-value 1
(indicating an error in processing the PCRpt)
(see )
if it encounters a problem with the LSP State Report it received
from the PCC, and
it MUST terminate the session. A PCE implementing a limit on the resources a single PCC can
occupy
MUST send a PCEP Notify (PCNtf) message with Notification Type 4
(Stateful PCE resource limit exceeded) and Notification Value 1
(Entering resource limit exceeded state)
in response to the PCRpt message triggering
this condition in the synchronization phase and MUST terminate
the session. The successful State Synchronization sequence is shown in .The sequence where the PCE fails during the State Synchronization
phase is shown in .The sequence where the PCC fails during the State Synchronization
phase is shown in . Optimizations to the synchronization procedures and alternate
mechanisms of providing the synchronization function are outside the scope
of this document and are discussed elsewhere
(see ).If during capability advertisement both the PCE and the PCC have
indicated that they support LSP Update, then the PCC may choose to grant
the PCE a temporary right to update (a subset of) LSP attributes on one
or more LSPs. This is called "LSP delegation", and it MAY be performed
at any time after the initialization phase, including during the State
Synchronization phase.A PCE MAY return an LSP delegation at any time if it no longer wishes to
update the LSP's state. A PCC MAY revoke an LSP delegation at any time.
Delegation, Revocation, and Return are done individually for each
LSP. In the event of a delegation being rejected or returned by a PCE,
the PCC SHOULD react based on local policy. It can, for example, either
retry delegating to the same PCE using an exponentially increasing timer
or delegate to an alternate PCE. A PCC delegates an LSP to a PCE by setting the Delegate flag in the LSP
State Report to 1. If the PCE does not accept the LSP delegation, it
MUST immediately respond with an empty LSP Update Request that has
the Delegate flag set to 0. If the PCE accepts the LSP delegation, it
MUST set the Delegate flag to 1 when it sends an LSP Update Request for the
delegated LSP (note that this may occur at a later time). The PCE
MAY also
immediately acknowledge a delegation
by sending an empty LSP Update Request that has the Delegate
flag set to 1. The delegation sequence is shown in .Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP State Report sent to the PCE.When a PCC decides that a PCE is no longer permitted to modify an
LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke an
LSP delegation at any time during the LSP's lifetime. A PCC revoking
an LSP delegation MAY immediately remove the updated parameters provided
by the PCE and revert to the operator-defined parameters,
but to avoid traffic loss, it SHOULD do so in a make&nbhy;before&nbhy;break
fashion. If the PCC has received but not yet acted on PCUpd messages
from the PCE for the LSP whose delegation is being revoked, then it
SHOULD ignore these PCUpd messages when processing the message
queue. All effects of all messages for which processing started before
the revocation took place MUST be allowed to complete, and the result
MUST be given the same treatment as any LSP that had been previously
delegated to the PCE (e.g., the state MAY immediately revert to the
operator-defined parameters).If a PCEP session with the PCE to which the LSP is delegated exists
in the UP state during the revocation, the PCC MUST notify that PCE by
sending an LSP State Report with the Delegate flag set to 0, as shown
in .After an LSP delegation has been revoked, a PCE can no longer
update an LSP's parameters; an attempt to update parameters of a
non&nbhy;delegated LSP will result in the PCC sending a PCErr message
with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update
Request for a non-delegated LSP) (see ).When a PCC's PCEP session with a PCE terminates unexpectedly, the
PCC MUST wait the time interval specified in the Redelegation Timeout
Interval before revoking LSP delegations to that PCE and attempting to
redelegate LSPs to an alternate PCE. If a PCEP session with the
original PCE can be re-established before the Redelegation Timeout
Interval timer expires, LSP delegations to the PCE remain intact.
Likewise, when a PCC's PCEP session with a PCE terminates
unexpectedly, and the PCC does not succeed in redelegating its LSPs,
the PCC MUST wait for the State Timeout Interval before
flushing any LSP state associated with that PCE. Note that the State
Timeout Interval timer may expire before the PCC has redelegated the
LSPs to another PCE, for example, if a PCC is not connected to any
active stateful PCE or if no connected active stateful PCE accepts the
delegation. In this case, the PCC MUST flush any LSP state set by the
PCE upon expiration of the State Timeout Interval and revert to
operator-defined default parameters or behaviors. This operation SHOULD be done in
a make-before-break fashion.
The State Timeout Interval MUST be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning that
until the PCC specifically takes action to change the parameters set
by the PCE, they will remain intact).
In order to keep a delegation, a PCE MUST set the Delegate
flag to 1 on each LSP Update Request sent to the PCC.
A PCE that no longer wishes to update an LSP's parameters SHOULD
return the LSP delegation back to the PCC by sending an empty LSP
Update Request that has the Delegate flag set to 0. If a PCC
receives an LSP Update Request with the Delegate flag set to 0
(whether the LSP Update Request is empty or not), it MUST
treat this as a delegation return.
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC
will timeout within a configurable Redelegation Timeout Interval, and
the PCC MUST flush any LSP state set by a PCE at the expiration of the
State Timeout Interval and revert to
operator-defined default parameters or behaviors.In a redundant
configuration where one PCE is backing up another PCE, the backup PCE
may have only a subset of the LSPs in the network delegated to it. The backup PCE does
not update any LSPs that are not delegated to it. In order to
allow the backup to operate in a hot-standby mode and avoid the need
for State Synchronization in case the primary fails, the backup receives all LSP
State Reports from a PCC. When the primary PCE for a given LSP set
fails, after expiry of the Redelegation Timeout Interval, the PCC
SHOULD delegate to the redundant PCE all LSPs that had been previously
delegated to the failed PCE. Assuming that the State Timeout Interval
had been configured to be greater than the Redelegation Timeout
Interval (as MANDATORY), and assuming that the primary and redundant PCEs
take similar decisions, this delegation change will not cause any
changes to the LSP parameters.
On failure, the goal is to: 1) avoid any traffic loss on the LSPs
that were updated by the PCE that crashed, 2) minimize the churn in the
network in terms of ownership of the LSPs, 3) not leave any "orphan"
(undelegated) LSPs, and 4) be able to control when the state that was
set by the PCE can be changed or purged. The values chosen for the
Redelegation Timeout and State Timeout values affect the ability to
accomplish these goals.
This section summarizes the behavior with regards to LSP
delegation and LSP state on a PCE failure. If the PCE crashes but recovers within the Redelegation Timeout,
both the delegation state and the LSP state are kept intact.If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is removed and the LSP
reverts to operator-defined parameters, which may cause a
change in the LSP state. Note that an operator may choose to use an
infinite State Timeout Interval if he wishes to maintain the PCE state
indefinitely. Note also that flushing the state should be implemented
using make-before-break to avoid traffic loss. If there is a standby PCE, the Redelegation Timeout may be set
to 0 through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the
standby PCE. Assuming that the PCC can redelegate the LSP to the
standby PCE within the State Timeout Interval, and assuming the
standby PCE takes similar decisions as the failed PCE, the LSP state
will be kept intact. Once a PCC has successfully established a PCEP session with a
passive stateful PCE and the PCC's LSP state is synchronized with the
PCE (i.e., the PCE knows about all of the PCC's existing LSPs), if an event is
triggered that requires the computation of a set of paths, the PCC
sends a path computation request to the PCE (,
Section 4.2.3). The PCReq message MAY contain the LSP object to
identify the LSP for which the path computation is requested.Upon receiving a path computation request from a PCC, the PCE
triggers a path computation and returns either a positive or a
negative reply to the PCC (, Section
4.2.4).Upon receiving a positive path computation reply, the PCC receives
a set of computed paths and starts to set up the LSPs. For each LSP, it
MAY send an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is "Going-up".Once an LSP is up or active, the PCC
MUST send an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Up' or
'Active', respectively. If the LSP could not be set up, the PCC
MUST send an LSP State Report
indicating that the LSP is 'Down' and stating the cause of the
failure. Note that due to timing constraints, the LSP status may
change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a
chance to send an LSP State Report indicating that the status is
'Going-up'. In such cases, the PCC MAY choose to only send the PCRpt
indicating the latest status ('Active', 'Up', or 'Down').Upon receiving a negative reply from a PCE, a PCC MAY
resend a modified request or take any other appropriate action. For
each requested LSP, it SHOULD also send an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is
'Down'.There is no direct correlation between PCRep and PCRpt messages.
For a given LSP, multiple LSP State Reports will follow a single
PCRep message, as a PCC notifies a PCE of the LSP's state changes.A PCC MUST send each LSP State Report to each stateful PCE that is
connected to the PCC.Note that a single PCRpt message MAY contain multiple LSP State
Reports.The passive stateful model for stateful PCEs is
described in , Section 6.8. This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation.
When the LSP has no working path, prior to delegating the LSP, the
PCC MUST first use the procedure defined in to
request the initial path from the PCE. This is required because the action
of delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the PCE to compute a path for the LSP. The only explicit way for a
PCC to request a path from the PCE is to send a PCReq message. The PCRpt message
MUST NOT be used by the PCC to attempt to request a path from the PCE.
When the LSP is delegated after its setup, it may be useful for the PCC
to communicate to the PCE the locally configured intended configuration parameters,
so that the PCE may reuse them in its computations. Such
parameters MAY be acquired through an out-of-band channel, or MAY be
communicated in the PCRpt message delegating the LSPs, by including them
as part of the intended&nbhy;attribute&nbhy;list as explained in .
An implementation MAY allow policies on the PCC to determine the configuration
parameters to be sent to the PCE.
Once a PCC has successfully established a PCEP session with an
active stateful PCE, the PCC's LSP state is synchronized with the PCE
(i.e., the PCE knows about all of the PCC's existing LSPs). After LSPs have been
delegated to the PCE, the PCE can modify LSP parameters of delegated
LSPs.To update an LSP, a PCE MUST send the PCC an LSP Update Request using
a PCUpd message. The LSP Update Request contains a variety of objects
that specify
the set of constraints and attributes for the LSP's path. Each LSP
Update Request MUST have a unique identifier, the SRP-ID-number, carried in
the SRP object described in . The SRP-ID-number is used to correlate
errors and state reports to LSP Update Requests. A single PCUpd
message MAY contain multiple LSP Update Requests.Upon receiving a PCUpd message, the PCC starts to set up LSPs
specified in LSP Update Requests carried in the message. For each LSP,
it MAY send an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Going-up'.
If the PCC decides that
the LSP parameters proposed in the PCUpd message are unacceptable, it
MUST report this error by including the LSP&nbhy;ERROR&nbhy;CODE TLV () with LSP error-value="Unacceptable
parameters" in the LSP object in the PCRpt message to the PCE. Based
on local policy, it MAY react further to this error by revoking the
delegation. If the PCC receives a PCUpd message for an LSP object
identified with a PLSP-ID that does not exist on the PCC, it MUST
generate a PCErr with Error-type=19 (Invalid Operation), error-value 3,
(Attempted LSP Update Request for an LSP identified by an unknown PSP-ID)
(see ).
Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt
message) to the PCE, indicating that the LSP's status is 'Up'. If the
LSP could not be set up, the PCC MUST send an LSP State Report
indicating
that the LSP is 'Down' and stating the cause of the failure. A PCC MAY
compress LSP State Reports to only reflect the most up to
date state, as discussed in the previous section.A PCC MUST send each LSP State Report to each stateful PCE that is
connected to the PCC. PCErr and PCRpt messages triggered as a result of a PCUpd message
MUST include the SRP-ID-number from the PCUpd. This provides
correlation of requests and errors and acknowledgement of state
processing. The PCC MAY compress the state when processing
PCUpd. In this case, receipt of a higher SRP-ID-number implicitly
acknowledges processing all the updates with a lower SRP-ID-number
for the specific LSP (as per ). A PCC MUST NOT send to any PCE a path computation request for a
delegated LSP. Should the PCC decide it wants to issue a Path
Computation Request on a delegated LSP, it MUST perform the Delegation
Revocation procedure first. LSP protection and interaction with stateful PCE, as well as the
extensions necessary to implement this functionality, will be discussed
in a separate document. A permanent PCEP session MUST be established between a stateful PCE
and the PCC. In the case of session failure, session re&nbhy;establishment
MUST be re-attempted per the procedures defined in . As defined in , a PCEP message consists of a
common header followed by a variable-length body made of a set of objects.
For each PCEP message type, a set of rules
is defined that specifies the set of objects that the message can carry.A Path Computation LSP State Report message (also referred to as
a PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response to
an LSP Update Request from a PCE or asynchronously when the state of an
LSP changes. The Message-Type field of the PCEP common header for the
PCRpt message is 10.The format of the PCRpt message is as follows:The SRP object (see ) is OPTIONAL.
If the PCRpt message is not in response to a PCupd message, the SRP object MAY
be omitted. When the PCC does not include the SRP object, the PCE MUST treat
this as an SRP object with an SRP-ID-number equal to the reserved value 0x00000000.
The reserved value 0x00000000 indicates that the state reported is not a result
of processing a PCUpd message.If the PCRpt message is in response to a PCUpd message, the SRP
object MUST be included and the value of the SRP-ID-number in
the SRP object MUST be the same as that sent in the PCUpd message that
triggered the state that is reported. If the PCC compressed several PCUpd
messages for the same LSP by only processing the one with the highest
number, then it should
use the SRP-ID-number of that request. No state compression is allowed for
state reporting, e.g., PCRpt messages MUST NOT be pruned from the PCC's
egress queue even if subsequent operations on the same LSP have been
completed before the PCRpt message has been sent to the TCP stack. The PCC
MUST explicitly report state changes (including removal) for paths it
manages.The LSP object (see ) is REQUIRED,
and it MUST be included in each LSP State Report on the PCRpt message.
If the LSP object is missing, the receiving PCE MUST send a PCErr
message with Error&nbhy;type=6 (Mandatory Object missing) and
Error-value 8 (LSP object missing).If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV () with the
relevant LSP Error Code to report the error to the PCE. The intended path, represented by the ERO object,
is REQUIRED. If the
ERO object is missing, the receiving PCE MUST send a PCErr
message with Error&nbhy;type=6 (Mandatory Object missing) and
Error-value 9 (ERO object missing).
The ERO may be empty if the PCE does not have a path for
a delegated LSP.
The actual path, represented by the RRO object,
SHOULD be included in a PCRpt by the PCC when the
path is up or active, but it MAY be
omitted if the path is down due to a signaling error or another
failure. The intended-attribute-list maps to the attribute-list in
Section 6.5 of and is used to convey the
requested parameters of the LSP path. This is needed in order to
support the switch from passive to active stateful PCE as described
in . When included as part of
the intended&nbhy;attribute&nbhy;list, the meaning of the BANDWIDTH object
is the requested bandwidth as intended by
the operator. In this case, the BANDWIDTH Object-Type of 1 SHOULD
be used. Similarly, to indicate a limiting constraint, the METRIC object
SHOULD be included as part of the intended-attribute-list with the B flag
set and with a specific metric value. To indicate the optimization metric,
the METRIC object SHOULD be included as part of the intended&nbhy;attribute&nbhy;list
with the B flag unset and the metric value set to zero. Note that the
intended-attribute-list is optional and thus may be omitted. In this
case, the PCE MAY use the values in the actual&nbhy;attribute&nbhy;list as the
requested parameters for the path.
The actual-attribute-list consists of the actual computed and signaled
values of the BANDWIDTH and METRIC objects defined in .
When included as part of the actual-attribute-list,
Object-Type 2 SHOULD be used for the BANDWIDTH
object, and the C flag SHOULD be set in the METRIC object
.
Note that the ordering of intended-path, actual-attribute-list, actual-path,
and intended-attribute-list is chosen to retain compatibility with
implementations of an earlier version of this standard. A PCE may choose to implement a limit on the resources a single
PCC can occupy.
If a PCRpt is received that causes the PCE to exceed this limit,
the PCE
MUST notify the PCC using a PCNtf message with Notification Type 4
(Stateful PCE resource limit exceeded) and Notification
Value 1 (Entering resource limit exceeded state), and it MUST
terminate the session. A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP Update
Request. The Message-Type field of the PCEP common header for the PCUpd
message is 11.The format of a PCUpd message is as follows:There are three mandatory objects that MUST be included within each
LSP Update Request in the PCUpd message: the SRP object (see ), the LSP object (see ) and the ERO object (as defined in , which represents the intended path.
If the SRP object is missing, the receiving PCC MUST
send a PCErr message with Error&nbhy;type=6 (Mandatory Object missing) and
Error-value=10 (SRP object missing). If the LSP object is missing,
the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory
Object missing) and Error-value=8 (LSP object missing). If the ERO
object is missing, the receiving PCC MUST send a PCErr message with
Error&nbhy;type=6 (Mandatory Object missing) and Error-value=9 (ERO
object missing).
The ERO in the PCUpd may be empty if the PCE cannot find a
valid path for a delegated LSP. One typical situation resulting
in this empty ERO carried in the PCUpd message is that a PCE
can no longer find a strict SRLG-disjoint path for a delegated
LSP after a link failure. The PCC SHOULD implement a local
policy to decide the appropriate action to be taken:
either tear down the LSP or revoke the delegation and use
a locally computed path, or keep the existing LSP. A PCC only acts on an LSP Update Request if permitted by the local
policy configured by the network manager. Each LSP Update Request
that the PCC acts on results in an LSP setup operation.
An LSP Update Request MUST contain all LSP parameters that a PCE
wishes to be set for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Update Request is already
up, it will be re-signaled. The PCC SHOULD minimize the traffic interruption and MAY
use the make-before-break procedures described in
in order to achieve this goal. If the
make-before-break procedures are used,
two paths will briefly coexist. The PCC MUST send separate
PCRpt messages for each, identified by the LSP-IDENTIFIERS TLV. When the
old path is torn down after the head end switches over the traffic, this
event MUST be reported by sending a PCRpt message with the
LSP&nbhy;IDENTIFIERS&nbhy;TLV of the old path and the R bit set. The SRP&nbhy;ID&nbhy;number
that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a
make-before-break operation will typically result in at least two PCRpt
messages, one for the new path and one for the removal of the old path
(more messages may be possible if intermediate states are reported).
If the path setup fails due to an RSVP signaling error, the error is reported
to the PCE. The PCC will not attempt to re-signal the path until it is
prompted again by the PCE with a subsequent PCUpd message.A PCC MUST respond with an LSP State Report to each LSP Update
Request it processed to indicate the resulting state of the LSP in the
network (even if this processing did not result in changing the state of
the LSP). The SRP-ID-number included in the PCRpt MUST match that in
the PCUpd. A PCC MAY respond with multiple LSP State Reports to report
LSP setup progress of a single LSP. In that case, the SRP-ID-number MUST
be included for the first message; for subsequent messages, the
reserved value 0x00000000 SHOULD be used.Note that a PCC MUST process all LSP Update Requests -- for example,
an LSP Update Request is sent when a PCE returns delegation or puts an
LSP into non-operational state. The protocol relies on TCP for
message-level flow control.If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network, the
PCC MAY perform state compression on its ingress queue. The compression
algorithm is based on the fact that each PCUpd request contains the complete
LSP state the PCE wishes to be set and works as follows: when the PCC
starts processing a PCUpd message at the head of its ingress queue, it may
search the queue forward for more recent PCUpd messages pertaining to that
particular LSP, prune all but the latest one from the queue, and process
only the last one as that request contains the most up-to-date desired state
for the LSP. The PCC MUST NOT send PCRpt nor PCErr messages for requests
that were pruned from the queue in this way. This compression step may be
performed only while the LSP is not being signaled, e.g., if two PCUpd arrive
for the same LSP in quick succession and the PCC started the signaling of
the changes relevant to the first PCUpd, then it MUST wait until the
signaling finishes (and report the new state via a PCRpt) before attempting
to apply the changes indicated in the second PCUpd.Note also that it is up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP setups is required, the PCE has to wait
for an LSP State Report for a previous LSP before starting the update of
the next LSP.If the PCUpd cannot be satisfied (for example, due to an
unsupported object or a TLV), the PCC MUST respond with a PCErr
message indicating the failure (see ). If the stateful PCE capability has been advertised on the PCEP
session, the PCErr message MAY include the SRP object. If the error
reported is the result of an LSP Update Request, then the SRP&nbhy;ID&nbhy;number
MUST be the one from the PCUpd that triggered the error. If the error is
unsolicited, the SRP object MAY be omitted. This is equivalent to including
an SRP object with the SRP-ID-number equal to the reserved value 0x00000000. The format of a PCErr message from is extended as follows:A PCC MAY include the LSP object in the PCReq message (see ) if the stateful PCE capability has been
negotiated on a PCEP session between the PCC and a PCE.
The definition of the PCReq message from is extended
to optionally include the LSP object after the END-POINTS object. The encoding
from will become:A PCE MAY include the LSP object in the PCRep message (see ) if the stateful PCE capability has been
negotiated on a PCEP session between the PCC, and the PCE and the LSP
object were included in the corresponding PCReq message from the PCC.The definition of the PCRep message from
is extended to optionally include the LSP object after the Request Parameter (RP) object.
The encoding from will become:The PCEP objects defined in this document are compliant with the PCEP
object format defined in . The P and I
flags of the PCEP objects defined in the current document MUST be set to 0
on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests.This document defines one new optional TLV for use in the OPEN
object.The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
OPEN object for stateful PCE capability advertisement. Its format is
shown in the following figure:The type (16 bits) of the TLV is 16.
The length field is 16 bits long and has a fixed value of 4.
The value comprises a single field -- Flags (32 bits):
if set to 1 by a
PCC, the U flag indicates that the PCC allows modification of LSP
parameters; if set to 1 by a PCE, the U flag indicates that the PCE
is capable of updating LSP parameters. The LSP-UPDATE-CAPABILITY
flag must be advertised by both a PCC and a PCE for PCUpd messages
to be allowed on a PCEP session.
Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. A PCEP speaker operating in passive stateful PCE mode advertises
the stateful PCE capability with the
U flag set to 0. A PCEP speaker operating in active stateful PCE mode
advertises the stateful PCE
capability with the U flag set to 1. Advertisement of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs, and
procedures defined in this document.
The SRP (Stateful PCE Request Parameters) object MUST be carried
within PCUpd messages and MAY be carried within PCRpt and
PCErr messages. The SRP object is used to correlate between update
requests sent by the PCE and the error reports and state reports sent by
the PCC. SRP Object-Class is 33.SRP Object-Type is 1.The format of the SRP object body is shown in :The SRP object body has a variable length and may contain additional
TLVs.Flags (32 bits): None defined yet. SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the current
PCEP session uniquely identifies the operation
that the PCE has requested the PCC to perform on a given LSP. The
SRP-ID-number is incremented each time a new request is sent to the PCC,
and it may wrap around. The values 0x00000000 and 0xFFFFFFFF are reserved.Optional TLVs MAY be included within the SRP object body. The
specification of such TLVs is outside the scope of this document. Every request to update an LSP receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an
operation is requested from the PCE. Thus, for a given LSP, there may be
more than one SRP-ID-number unacknowledged at a given time. The value of
the SRP-ID-number is 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. If the error or report was not a
result of a PCE operation (for example, in the case of a link down
event), the reserved value of 0x00000000 is used for the SRP-ID-number. The
absence of the SRP object is equivalent to an SRP object with the reserved value
of 0x00000000. An SRP&nbhy;ID&nbhy;number is considered unacknowledged and cannot be
reused until a
PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the
same LSP. In case of SRP-ID-number wrapping, the last SRP&nbhy;ID&nbhy;number
before the wrapping
MUST be explicitly acknowledged, to avoid a situation where SRP-ID-numbers
remain
unacknowledged after the wrap. This means that the PCC may need to issue
two PCUpd messages on detecting a wrap.
The LSP object MUST be present within PCRpt and PCUpd messages.
The LSP object MAY be carried within PCReq and PCRep messages if the
stateful PCE capability has been negotiated on the session. The LSP
object contains a set of fields used to specify the target LSP, the
operation to be performed on the LSP, and LSP delegation. It also
contains a flag indicating to a PCE that the LSP State Synchronization
is in progress. This document focuses on LSPs that are signaled with
RSVP; many of the TLVs used with the LSP object mirror RSVP state.
LSP Object-Class is 32.LSP Object-Type is 1.The format of the LSP object body is shown in :PLSP-ID (20 bits): A PCEP-specific identifier for the LSP.
A PCC creates a unique
PLSP-ID for each LSP that is constant for the lifetime of a PCEP
session. The PCC will advertise the same PLSP-ID on all PCEP sessions it
maintains at a given time.
The mapping of the symbolic path name to PLSP-ID is
communicated to the PCE by sending a PCRpt message containing the
SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages then address the
LSP by the PLSP-ID. The values of 0 and 0xFFFFF are reserved. Note that
the PLSP-ID is a value that is constant for the lifetime of the PCEP
session, during which time for an RSVP-signaled LSP there might be
different RSVP identifiers (LSP-id, tunnel-id) allocated to it.Flags (12 bits), starting from the least significant bit:
On a PCRpt message, the D flag set
to 1 indicates that the PCC is delegating the LSP to the PCE. On a
PCUpd message, the D flag set to 1 indicates that the PCE is
confirming the LSP delegation. To keep an LSP delegated to the PCE,
the PCC must set the D flag to 1 on each PCRpt message for the
duration of the delegation -- the first PCRpt with the D flag set to 0
revokes the delegation. To keep the delegation, the PCE must set the D
flag to 1 on each PCUpd message for the duration of the delegation --
the first PCUpd with the D flag set to 0 returns the delegation. The S flag MUST be set to 1 on each
PCRpt sent from a PCC during State Synchronization. The S
flag MUST be set to 0 in other messages sent from the PCC. When sending
a PCUpd message, the PCE MUST set the S flag to 0. On PCRpt messages, the R flag
indicates that the LSP has been removed from the PCC and the PCE
SHOULD remove all state from its database. Upon receiving an LSP State
Report with the R flag set to 1 for an RSVP-signaled LSP, the PCE
SHOULD remove all state for the path identified by the LSP-IDENTIFIERS
TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is
used, the PCE SHOULD remove all state for the PLSP-ID from its
database. When sending a PCUpd message, the PCE MUST set the R flag
to 0. On PCRpt messages, the A
flag indicates the PCC's target operational status for this LSP. On
PCUpd messages, the A flag indicates the LSP status that the PCE
desires for this LSP. In both cases, a value of '1' means that the
desired operational state is active, and a value of '0' means that the
desired operational state is inactive. A PCC ignores the A flag on a
PCUpd message unless the operator's policy allows the PCE to control
the corresponding LSP's administrative state. On PCRpt messages, the O field
represents the operational status of the LSP. The following values are defined:
not active.signaled.up and carrying traffic. LSP is being torn down, and resources are
being released.LSP is being signaled.these values are reserved for future use.
Unassigned bits are reserved for future uses. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
When sending a PCUpd message, the PCE MUST set the O field to 0.
TLVs that may be included in the LSP object are described
in the following sections. Other optional TLVs, that are not defined in
this document, MAY also be included within the LSP object body. The LSP-IDENTIFIERS TLV MUST be included in the LSP object in
PCRpt messages for RSVP-signaled LSPs. If the TLV is missing, the PCE
will generate an error with Error-type=6 (Mandatory Object missing)
and error-value 11 (LSP-IDENTIFIERS TLV missing) and close the
session. The LSP-IDENTIFIERS TLV MAY be included in the LSP object in
PCUpd messages for RSVP-signaled LSPs. The special value of all zeros
for this TLV is used to refer to all paths pertaining to a particular
PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one for
IPv6. It is the responsibility of the PCC to send to the PCE the
identifiers for each RSVP incarnation of the tunnel. For example, in a
make-before-break scenario, the PCC MUST send a separate PCRpt for the
old and reoptimized paths and explicitly report removal of
any of these paths using the R bit in the LSP object.The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
figure:The type (16 bits) of the TLV is 18.
The length field is 16 bits long and has a fixed value of 16.
The value contains the following fields:
contains the sender
node's IPv4 address, as defined in , Section
4.6.2.1, for the LSP_TUNNEL_IPv4 Sender Template Object. contains the 16-bit 'LSP ID' identifier
defined in , Section 4.6.2.1 for the
LSP_TUNNEL_IPv4 Sender Template Object. A value of 0 MUST be
used if the LSP is not yet signaled. contains the 16-bit 'Tunnel ID' identifier
defined in , Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Session Object. contains the 32-bit 'Extended
Tunnel ID' identifier defined in , Section
4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. contains the egress
node's IPv4 address, as defined in , Section
4.6.1.1, for the LSP_TUNNEL_IPv4 Sender Template Object.The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following
figure:The type (16 bits) of the TLV is 19.
The length field is 16 bits long and has a fixed value of 52.
The value contains the following fields:
contains the sender
node's IPv6 address, as defined in , Section
4.6.2.2, for the LSP_TUNNEL_IPv6 Sender Template Object. contains the 16-bit 'LSP ID' identifier
defined in , Section 4.6.2.2 for the
LSP_TUNNEL_IPv6 Sender Template Object. A value of 0 MUST be
used if the LSP is not yet signaled. contains the 16-bit 'Tunnel ID' identifier
defined in , Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. contains the 128-bit 'Extended
Tunnel ID' identifier defined in , Section
4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. contains the
egress node's
IPv6 address, as defined in , Section
4.6.1.2, for the LSP_TUNNEL_IPv6 Session Object.
The Tunnel ID remains constant over the
lifetime of a tunnel.
Each LSP MUST have a symbolic path name that is unique in the PCC.
The symbolic path name is a human-readable string that identifies an
LSP in the network. The symbolic path name MUST remain constant
throughout an LSP's lifetime, which may span across multiple
consecutive PCEP sessions and/or PCC restarts. The symbolic path
name MAY be specified by an operator in a PCC's configuration. If the
operator does not specify a unique symbolic name for an LSP, then the
PCC MUST auto-generate one.The PCE uses the symbolic path name as a stable identifier for the LSP.
If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates
the LSP to a different PCE, the symbolic path name for the LSP remains
constant and can be used to correlate across the PCEP session instances.The other protocol identifiers for the LSP cannot reliably be used to
identify the LSP across multiple PCEP sessions, for the following reasons.
The PLSP-ID is unique only within the scope of a single PCEP session.The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs
that are signaled with RSVP-TE, and it may change during the lifetime of the LSP.The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
LSP State Report (PCRpt) message when during a given PCEP session an
LSP is first reported to a PCE. A PCC sends to a PCE the first LSP
State Report either during State Synchronization or when a new LSP
is configured at the PCC.The initial PCRpt creates a binding between the symbolic path name and
the PLSP-ID for the LSP that lasts for the duration of the PCEP session.
The PCC MAY omit the symbolic path name from subsequent LSP State
Reports for that LSP on that PCEP session, and just use the PLSP-ID.The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
figure:Type (16 bits): the type is 17.Length (16 bits): indicates the total length of the
TLV in octets and MUST be greater than 0. The TLV MUST
be zero-padded so that the TLV is 4-octet aligned. Symbolic Path Name (variable): symbolic name for the LSP, unique in
the PCC. It SHOULD be a string of printable ASCII characters, without a
NULL terminator.The LSP Error Code TLV is an optional TLV for use in the LSP object
to convey error information. When an LSP Update Request fails, an LSP
State Report MUST be sent to report the current state of the LSP, and
it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for the
failure. Similarly, when a PCRpt is sent as a result of an LSP
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD
be included to indicate the reason for the transition. The format of the LSP-ERROR-CODE TLV is shown in the following
figure:The type (16 bits) of the TLV is 20.
The length field is 16 bits long and has a fixed value of 4.
The value contains an error code
that indicates the cause of the failure. The following LSP Error Codes are currently defined: ValueDescription ------------------------------------------1 Unknown reason 2 Limit reached for PCE-controlled LSPs3 Too many pending LSP Update Requests4 Unacceptable parameters5 Internal error6 LSP administratively brought down7 LSP preempted8 RSVP signaling errorThe RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP
object to carry RSVP error information. It includes the RSVP
ERROR_SPEC or USER_ERROR_SPEC object ( and
), which were returned to the PCC from a
downstream node. If the setup of an LSP fails at a downstream node
that returned an ERROR_SPEC to the PCC, the PCC SHOULD include in the
PCRpt for this LSP the LSP-ERROR-CODE TLV with LSP Error Code = "RSVP
signaling error" and the RSVP-ERROR-SPEC TLV with the relevant RSVP
ERROR-SPEC or USER_ERROR_SPEC object.
The format of the RSVP-ERROR-SPEC TLV is shown in the following
figure:Type (16 bits): the type is 21.Length (16 bits): indicates the total length of the
TLV in octets. The TLV MUST be zero-padded so that the
TLV is 4-octet aligned.Value (variable): contains the
RSVP ERROR_SPEC or USER_ERROR_SPEC object, as specified in
and , including the object header. The code points described below have been allocated for the
protocol elements defined in this document.
The following bits have been reigstered in the "Path Computation Element
(PCE) Capability Flags" subregistry of the "Open Shortest Path First (OSPF) Parameters" registry:
BitDescription Reference -----------------------------------------------11 Active stateful PCE capabilityThis document12 Passive stateful PCE capabilityThis documentThe following message types have been allocated
within the "PCEP Messages" subregistry of the "Path Computation Element
Protocol (PCEP) Numbers" registry:
ValueDescription Reference ------------------------------10 ReportThis document11 UpdateThis documentThe following object-class values
and object types have been allocated within the "PCEP Objects" subregistry
of the "Path Computation Element Protocol (PCEP) Numbers" registry:
Object-Class Value Name Reference -----------------------------------------------32LSPThis documentObject-Type 0: Reserved 1: LSP33SRPThis documentObject-Type 0: Reserved 1: SRPA new subregistry, named "LSP Object Flag Field", has been created
within the "Path Computation Element Protocol (PCEP) Numbers" registry
to manage the Flag field of the LSP object. New values are
assigned by Standards Action . Each bit should
be tracked with the following qualities:
Bit number (counting from bit 0 as the most significant bit)Capability descriptionDefining RFCThe following values are defined in this document:BitDescription Reference ------------------------------------0-4UnassignedThis document5-7Operational (3 bits)This document8AdministrativeThis document9RemoveThis document10SYNCThis document11DelegateThis document
The following error types
and error values have been registered within the "PCEP-ERROR Object
Error Types and Values" subregistry of the "Path Computation Element
Protocol (PCEP) Numbers" registry:
Meaning-------------------------------------------------------Mandatory Object missing
LSP object missingERO object missingSRP object missingLSP-IDENTIFIERS TLV missingInvalid Operation
Attempted LSP Update Request for a
non&nbhy;delegated LSP. The PCEP-ERROR object is followed by the LSP
object that identifies the LSP.Attempted LSP Update Request if the
stateful PCE capability was not advertised.Attempted LSP Update Request for an
LSP identified by an unknown PLSP-ID.Attempted LSP State Report if
stateful PCE capability was not advertised.LSP State Synchronization Error
A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. The PCEP-ERROR
object is followed by the LSP object that identifies the LSP.A PCC indicates to a PCE that it cannot complete the State Synchronization.The following Notification Types and Notification Values have been
allocated within the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
NameStateful PCE resource limit exceeded
Entering resource limit exceeded state Deprecated
Note that the early allocation included an additional Notification Value 2
for "Exiting resource limit exceeded state". This Notification Value is no
longer required and has been marked as "Deprecated".
The following TLV Type Indicator
values have been regisered within the "PCEP TLV Type Indicators" subregistry
of the "Path Computation Element Protocol (PCEP) Numbers" registry:ValueDescription Reference -----------------------------------------16 STATEFUL-PCE-CAPABILITYThis document17 SYMBOLIC-PATH-NAMEThis document18 IPV4-LSP-IDENTIFIERSThis document19 IPV6-LSP-IDENTIFIERSThis document20 LSP-ERROR-CODEThis document21 RSVP-ERROR-SPECThis document
A new subregistry, named
"STATEFUL&nbhy;PCE&nbhy;CAPABILITY TLV Flag Field", has been created within the
"Path Computation Element Protocol (PCEP) Numbers" registry to manage
the Flag field in the STATEFUL-PCE-CAPABILITY TLV of the PCEP
OPEN object (class = 1).
New values
are assigned by Standards Action . Each
bit should be tracked with the following qualities:
Bit number (counting from bit 0 as the most significant bit)Capability descriptionDefining RFCThe following values are defined in this document:ValueDescription Reference ---------------------------------------31LSP-UPDATE-CAPABILITYThis documentA new subregistry, named "LSP-ERROR-CODE TLV Error Code Field",
has been created within the
"Path Computation Element Protocol (PCEP) Numbers" registry to
manage the LSP Error Code field of the LSP-ERROR-CODE TLV.
This field specifies the reason for failure to update the LSP.
New values are assigned by Standards Action
. Each
value should be tracked with the following qualities: value,
meaning, and defining RFC. The following values are defined
in this document:
ValueMeaning ----------------------------------------0 Reserved 1 Unknown reason 2 Limit reached for PCE-controlled LSPs3 Too many pending LSP Update Requests4 Unacceptable parameters5 Internal error6 LSP administratively brought down7 LSP preempted8 RSVP signaling errorAll manageability requirements and considerations listed in apply to the PCEP extensions defined in this
document. In addition, requirements and considerations listed in this
section apply.In addition to configuring specific PCEP session parameters, as
specified in , Section 8.1, a PCE or PCC
implementation MUST allow configuring the stateful PCEP capability and
the LSP Update capability. A PCC implementation SHOULD allow the
operator to specify multiple candidate PCEs for and a delegation
preference for each candidate PCE. A PCC SHOULD allow the operator to
specify an LSP delegation policy where LSPs are delegated to the
most-preferred online PCE. A PCC MAY allow the operator to specify
different LSP delegation policies.A PCC implementation that allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative
domains, and it MUST NOT advertise LSP existence and state to a PCE if the
LSP is delegated to a PCE in a different group.A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically configured
at the PCC).A PCC implementation SHOULD allow the operator to specify both the
Redelegation Timeout Interval and the State Timeout Interval. The
default value of the Redelegation Timeout Interval SHOULD be set to 30
seconds. An operator MAY also configure a policy that will dynamically
adjust the Redelegation Timeout Interval, for example setting it to zero
when the PCC has an established session to a backup PCE. The default
value for the State Timeout Interval SHOULD be set to 60 seconds.
After the expiration of the State Timeout Interval, the LSP reverts
to operator-defined default parameters. A PCC implementation MUST allow
the operator to specify the default LSP parameters. To achieve a
behavior where the LSP retains the parameters set by the PCE until such
time that the PCC makes a change to them, a State Timeout Interval of
infinity SHOULD be used. Any changes to LSP parameters SHOULD be done in
a make-before-break fashion. LSP delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually -- different LSPs may be delegated to
different PCEs. An LSP is delegated to at most one PCE at any given
point in time. A PCC implementation SHOULD support the delegation
policy, when all PCC's LSPs are delegated
to a single PCE at any given time.
Conversely, the policy revoking the delegation
for all PCC's LSPs SHOULD also be supported.A PCC implementation SHOULD allow the operator to specify delegation
priority for PCEs. This effectively defines the primary PCE and one or
more backup PCEs to which a primary PCE's LSPs can be delegated when the
primary PCE fails.Policies defined for stateful PCEs and PCCs should eventually fit in
the policy-enabled path computation framework defined in , and the framework should be extended to support
stateful PCEs.The PCEP YANG module should include:
advertised stateful capabilities and synchronization status per PCEP session.the delegation status of each configured LSP.
The PCEP MIB could also be updated to include this information.
PCEP extensions defined in this document do not require any
new mechanisms beyond those already defined in ,
Section 8.3.Mechanisms defined in , Section 8.4 also apply
to PCEP extensions defined in this document. In addition to
monitoring parameters defined in , a stateful
PCC-side PCEP implementation SHOULD provide the following parameters:
Total number of LSP UpdatesNumber of successful LSP UpdatesNumber of dropped LSP UpdatesNumber of LSP Updates where LSP setup failedA PCC implementation SHOULD provide a command to show for each LSP
whether it is delegated, and if so, to which PCE.A PCC implementation SHOULD allow the operator to manually revoke LSP
delegation.
PCEP extensions defined in this document do not put new
requirements on other protocols.Mechanisms defined in , Section 8.6 also
apply to PCEP extensions defined in this document.Additionally, a PCEP implementation SHOULD allow a limit to be placed
on the number of LSPs delegated to the PCE and
on the rate of PCUpd and PCRpt messages sent by a PCEP speaker and
processed from a peer. It SHOULD also allow sending a notification when
a rate threshold is reached.
A PCC implementation SHOULD allow a limit to be placed on the rate of
LSP Updates to the same LSP to avoid signaling overload discussed in
.This document defines extensions to PCEP to enable stateful PCEs. The
nature of these extensions and the delegation of path control to PCEs
results in more information being available for a hypothetical adversary
and a number of additional attack surfaces that must be protected.The security provisions described in remain
applicable to these extensions. However, because the protocol
modifications outlined in this document allow the PCE to control path
computation timing and sequence, the PCE defense mechanisms described in
, Section 7.2 are also now applicable to PCC
security.As a general precaution, it is RECOMMENDED that these PCEP extensions
only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority, using Transport Layer
Security (TLS) , as per the recommendations and
best current practices in .The following sections identify specific security concerns that may
result from the PCEP extensions outlined in this document along with
recommended mechanisms to protect PCEP infrastructure against related
attacks.The stateful nature of this extension explicitly requires LSP status
updates to be sent from PCC to PCE. While this gives the PCE the ability
to provide more optimal computations to the PCC, it also provides an
adversary with the opportunity to eavesdrop on decisions made by network
systems external to PCE. This is especially true if the PCC delegates
LSPs to multiple PCEs simultaneously.Adversaries may gain access to this information by eavesdropping on
unsecured PCEP sessions and might then use this information in various
ways to target or optimize attacks on network infrastructure, for example,
by flexibly countering anti-DDoS measures being taken to protect the
network or by determining choke points in the network where the greatest
harm might be caused.PCC implementations that allow concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative
domains, and they MUST NOT advertise LSP existence and state to a PCE if
the LSP is delegated to a PCE in a different group.The LSP delegation mechanism described in this document allows a PCC
to grant effective control of an LSP to the PCE for the duration of a
PCEP session. While this enables PCE control of the timing and sequence
of path computations within and across PCEP sessions, it also introduces
a new attack vector: an attacker may flood the PCC with PCUpd messages at
a rate that exceeds either the PCC's ability to process them or the
network's ability to signal the changes, by either spoofing messages or
compromising the PCE itself.A PCC is free to revoke an LSP delegation at any time without needing
any justification. A defending PCC can do this by enqueueing the
appropriate PCRpt message. As soon as that message is enqueued in the
session, the PCC is free to drop any incoming PCUpd messages without
additional processing.A stateful session also results in an increased attack surface
by placing
a requirement for the PCE to keep an LSP state replica for each PCC. It
is RECOMMENDED that PCE implementations provide a limit on resources a
single PCC can occupy. A PCE implementing such a limit MUST send a PCNtf
message with notification-type 4 (Stateful PCE resource limit
exceeded) and notification-value 1 (Entering resource limit
exceeded state) upon receiving an LSP State Report causing it to
exceed this threshold.Delegation of LSPs can create further strain on PCE resources and a
PCE implementation MAY preemptively give back delegations if it finds
itself lacking the resources needed to effectively manage the delegation.
Since the delegation state is ultimately controlled by the PCC, PCE
implementations SHOULD provide throttling mechanisms to prevent strain
created by flaps of either a PCEP session or an LSP delegation.
>
PCEP extensions for GMPLSThis memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane.Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCEPCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE ModelA YANG Data Model for Path Computation Element Communications Protocol (PCEP)Secure Transport for PCEPA practical algorithm for balancing the max-min
fairness and throughput objectives in traffic engineeringGoogle, Inc.Google, Inc.Google, Inc.Improved MPLS-TE LSP Path Computation using PreemptionFrance Telecom R&DFrance Telecom R&DIRISA, Universite de RennesWe would like to thank Adrian Farrel, Cyril Margaria, and Ramon Casellas
for their contributions to this document.We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz, and Raveendra Torvi for their comments and suggestions.
Thanks also to Jon Hardwick, Oscar Gonzales
de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Spanik, Jon
Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Calvin Ying,
Mustapha Aissaoui, Stephane Litkowski, and
Olivier Dugeon for helpful comments and discussions.The following people contributed substantially to the content of this
document and should be considered co-authors:
Xian Zhang
Huawei Technology
F3-5-B R&D Center
Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
Email: dhruv.dhody@huawei.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com