PCE Working Group E. Crabbe
Internet-Draft I. Minei
Intended status: Standards Track Google, Inc.
Expires: December 8, 2014 S. Sivabalan
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
June 6, 2014
PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
draft-ietf-pce-pce-initiated-lsp-01
Abstract
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.
The extensions described in [I-D.ietf-pce-stateful-pce] 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.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2014.
Crabbe, et al. Expires December 8, 2014 [Page 1]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Operation overview . . . . . . . . . . . . . . . . . . . 4
4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 5
4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 6
5. PCE-initiated LSP instantiation and deletion . . . . . . . . 6
5.1. The LSP Initiate Message . . . . . . . . . . . . . . . . 6
5.2. The R flag in the SRP Object . . . . . . . . . . . . . . 7
5.3. LSP instantiation . . . . . . . . . . . . . . . . . . . . 8
5.3.1. The Create flag . . . . . . . . . . . . . . . . . . . 10
5.4. LSP deletion . . . . . . . . . . . . . . . . . . . . . . 10
6. LSP delegation and cleanup . . . . . . . . . . . . . . . . . 11
7. Implementation status . . . . . . . . . . . . . . . . . . . . 12
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 12
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Crabbe, et al. Expires December 8, 2014 [Page 2]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
1. Introduction
[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.
Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
extensions to PCEP to enable stateful control of TE LSPs between and
across PCEP sessions in compliance with [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.
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.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation
Timeout, State Timeout Interval LSP State Report, LSP Update Request.
The following terms are defined in this document:
PCE-initiated LSP: LSP that is instantiated as a result of a request
from the PCE.
The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Architectural Overview
3.1. Motivation
[I-D.ietf-pce-stateful-pce] 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
Crabbe, et al. Expires December 8, 2014 [Page 3]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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.
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.
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.
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.
3.2. Operation overview
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 Section 4.1).
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.
For an instantiation operation, the PCE MUST include the ERO and END-
POINTS object and may include various attributes as per [RFC5440].
The PCC creates the LSP using the attributes communicated by the PCE,
Crabbe, et al. Expires December 8, 2014 [Page 4]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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
Section 5.3.1), 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 Section 5.3.
Once instantiated, the delegation procedures for PCE-initiated LSPs
are the same as for PCC initiated LSPs as described in
[I-D.ietf-pce-stateful-pce]. 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 [I-D.ietf-pce-stateful-pce]. 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 Section 6. A PCE may return a delegation to the PCC in
order to facilitate re-delegation of its LSPs to an alternate PCE.
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 Section 5.4.
4. Support of PCE-initiated LSPs
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
[I-D.ietf-pce-stateful-pce]. 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.
Crabbe, et al. Expires December 8, 2014 [Page 5]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
4.1. Stateful PCE Capability TLV
The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
following figure:
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
Figure 1: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it
has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits). The U and S
bits are defined in [I-D.ietf-pce-stateful-pce].
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.
Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
5. PCE-initiated LSP instantiation and deletion
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.
5.1. The LSP Initiate Message
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 [I-D.ietf-pce-stateful-pce]. LSP instantiation is done
by sending an LSP Initiate Message with an LSP object with the
Crabbe, et al. Expires December 8, 2014 [Page 6]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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 Section 5.2).
The format of a PCInitiate message for LSP instantiation is as
follows:
<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.
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 [I-D.ietf-pce-stateful-pce].
5.2. The R flag in the SRP Object
The format of the SRP object is shown Figure 2:
Crabbe, et al. Expires December 8, 2014 [Page 7]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SRP Object format
The type object is defined in [I-D.ietf-pce-stateful-pce].
A new flag is defined to indicate a delete operation initiated by the
PCE:
R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request
initiated by the PCE.
5.3. LSP instantiation
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.
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).
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).
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).
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
Crabbe, et al. Expires December 8, 2014 [Page 8]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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 Section 6).
The PCE MAY include various attributes as per [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.
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).
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 [I-D.ietf-pce-stateful-pce].
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.
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
Crabbe, et al. Expires December 8, 2014 [Page 9]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
closing the session or removing all its LSPs) if this limit is
reached.
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.
5.3.1. The Create flag
The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
here for easy reference.
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The LSP Object format
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).
5.4. LSP deletion
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 ([I-D.ietf-pce-stateful-pce]). 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 [I-D.ietf-pce-stateful-pce]. The SRP
Crabbe, et al. Expires December 8, 2014 [Page 10]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
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.
6. LSP delegation and cleanup
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.
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
([I-D.ietf-pce-stateful-pce]).
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.
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 [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked
based on local policy, and can result either in LSP removal, or into
reverting to operator-defined default parameters.
Crabbe, et al. Expires December 8, 2014 [Page 11]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
7. Implementation status
This section to be removed by the RFC editor.
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.
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".
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.
8. IANA considerations
8.1. PCEP Messages
This document defines the following new PCEP messages:
Value Meaning Reference
12 Initiate This document
8.2. LSP Object
The following values are defined in this document for the Flags field
in the LSP Object.
Bit Description Reference
24 Create This document
Crabbe, et al. Expires December 8, 2014 [Page 12]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
8.3. PCEP-Error Object
This document defines new Error-Type and Error-Value for the
following new error conditions:
Error-Type Meaning
6 Mandatory Object missing
Error-value=13: LSP cleanup TLV missing
Error-value=14: SYMBOLIC-PATH-NAME TLV missing
19 Invalid operation
Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in LSP initiation
request
23 Bad parameter value
Error-value=1: SYMBOLIC-PATH-NAME in use
24 LSP instantiation error
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: RSVP signaling error
9. Security Considerations
The security considerations described in [I-D.ietf-pce-stateful-pce]
apply to the extensions described in this document. Additional
considerations related to a malicious PCE are introduced.
9.1. Malicious PCE
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.
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
Crabbe, et al. Expires December 8, 2014 [Page 13]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
to drop any incoming PCInitiate messages for LSP instantiation
without additional processing.
Rapid flaps triggered by the PCE can also be an attack vector. This
will be discussed in a future version of this document.
9.2. Malicious PCC
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.
10. Acknowledgements
We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas,
Dhruv Dhody, and Raveendra Trovi for their contributions to this
document.
11. References
11.1. Normative References
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-08 (work in progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
Crabbe, et al. Expires December 8, 2014 [Page 14]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
11.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
Christian, B., and W. Lai, "Applicability Statement for
Traffic Engineering with MPLS", RFC 3346, August 2002.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
Crabbe, et al. Expires December 8, 2014 [Page 15]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July
2013.
Authors' Addresses
Edward Crabbe
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: edc@google.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.com
Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: msiva@cisco.com
Crabbe, et al. Expires December 8, 2014 [Page 16]
Internet-Draft Stateful PCE - PCE-initiated LSP June 2014
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Crabbe, et al. Expires December 8, 2014 [Page 17]
