< draft-ietf-pce-pce-initiated-lsp-09.txt   draft-ietf-pce-pce-initiated-lsp-10.txt >
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Individual Contributor Internet-Draft Individual Contributor
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: September 8, 2017 Google, Inc. Expires: December 24, 2017 Google, Inc.
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
March 7, 2017 June 22, 2017
PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
draft-ietf-pce-pce-initiated-lsp-09 draft-ietf-pce-pce-initiated-lsp-10
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The extensions for stateful PCE provide active control of The extensions for stateful PCE provide active control of
Multiprotocol Label Switching (MPLS) Traffic Engineering Label Multiprotocol Label Switching (MPLS) Traffic Engineering Label
Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2017. This Internet-Draft will expire on December 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 5
4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 6 4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 5
4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 6 4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 6
5. PCE-initiated LSP Instantiation and Deletion . . . . . . . . 7 5. PCE-initiated LSP Instantiation and Deletion . . . . . . . . 6
5.1. The LSP Initiate Message . . . . . . . . . . . . . . . . 7 5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 6
5.2. The R flag in the SRP Object . . . . . . . . . . . . . . 8 5.2. The R flag in the SRP Object . . . . . . . . . . . . . . 7
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 9 5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 8
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 11 5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 10
5.3.2. The SPEAKER-IDENTITY-ID TLV . . . . . . . . . . . . . 11 5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 11
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 12 5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 11
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 12 6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 11
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 13
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 14 9.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 9.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Communication [RFC5440] describes the Path Computation Element Communication
Protocol (PCEP). PCEP defines the communication between a Path Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between Computation Client (PCC) and a Path Computation Element (PCE), or
PCE and PCE, enabling computation of Multiprotocol Label Switching between PCE and PCE, enabling computation of Multiprotocol Label
(MPLS) for Traffic Engineering Label Switched Path (TE LSP) Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics. characteristics.
Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to
extensions to PCEP to enable stateful control of TE LSPs between and enable stateful control of TE LSPs between and across PCEP sessions
across PCEP sessions in compliance with [RFC4657]. It includes 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 o mechanisms to effect LSP state synchronization between PCCs and
sequence of path computations within and across PCEP sessions and PCEs
focuses on a model where LSPs are configured on the PCC and control o delegation of control of LSPs to PCEs
over them is delegated to the PCE. o PCE control of timing and sequence of path computations within and
across PCEP sessions
It 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- This document describes the setup, maintenance and teardown of PCE-
initiated LSPs under the stateful PCE model, without the need for initiated LSPs under the stateful PCE model, without the need for
local configuration on the PCC, thus allowing for a dynamic network local configuration on the PCC, thus allowing for a dynamic network
that is centrally controlled and deployed. that is centrally controlled and deployed.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer. PCE, PCEP Peer.
skipping to change at page 3, line 48 skipping to change at page 4, line 6
This document uses the following terms defined in This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, State [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, State
Timeout Interval, LSP State Report, LSP Update Request. Timeout Interval, LSP State Report, LSP Update Request.
The following terms are defined in this document: The following terms are defined in this document:
PCE-initiated LSP: LSP that is instantiated as a result of a request PCE-initiated LSP: LSP that is instantiated as a result of a request
from the PCE. from the PCE.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
3. Architectural Overview 3. Architectural Overview
3.1. Motivation 3.1. Motivation
[I-D.ietf-pce-stateful-pce] provides active control over LSPs that [I-D.ietf-pce-stateful-pce] provides active control over LSPs that
are locally configured on the PCC. This model relies on the Label are locally configured on the PCC. This model relies on the Label
Edge Router (LER) taking an active role in delegating locally Edge Router (LER) taking an active role in delegating locally
configured LSPs to the PCE, and is well suited in environments where 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 is fairly static. However, in environments where
the LSP placement needs to change in response to application demands, the LSP placement needs to change in response to application demands,
it is useful to support dynamic creation and tear down of LSPs. The 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 ability for a PCE to trigger the creation of LSPs on demand can be
possible agile software-driven network operation, and can be
seamlessly integrated into a controller-based network architecture, seamlessly integrated into a controller-based network architecture,
where intelligence in the controller can determine when and where to where intelligence in the controller can determine when and where to
set up paths. set up paths.
A possible use case is a software-driven network, where applications A possible use case is a software-driven network, where applications
request network resources and paths from the network infrastructure. request network resources and paths from the network infrastructure.
For example, an application can request a path with certain For example, an application can request a path with certain
constraints between two LSRs by contacting the PCE. The PCE can constraints between two LSRs by contacting the PCE. The PCE can
compute a path satisfying the constraints, and instruct the head end compute a path satisfying the constraints, and instruct the head end
LSR to instantiate and signal it. When the path is no longer LSR to instantiate and signal it. When the path is no longer
skipping to change at page 4, line 49 skipping to change at page 5, line 7
satisfy the bandwidth requirements. satisfy the bandwidth requirements.
Another use case is demand engineering, where a PCE with visibility Another use case is demand engineering, where a PCE with visibility
into both the network state and the demand matrix can anticipate and into both the network state and the demand matrix can anticipate and
optimize how traffic is distributed across the infrastructure. Such optimize how traffic is distributed across the infrastructure. Such
optimizations may require creating new paths across the optimizations may require creating new paths across the
infrastructure. infrastructure.
3.2. Operation Overview 3.2. Operation Overview
A PCC or PCE indicates its ability to support PCE-provisioned dynamic This document defines the new I flag in the STATEFUL-PCE-CAPABILITY
LSPs during the PCEP Initialization Phase via a new flag in the TLV to indicate that the sender supports PCE-initiated LSPs (see
STATEFUL-PCE-CAPABILITY TLV (see details in Section 4.1). details in Section 4.1). A PCC or PCE sets this flag in the Open
message during the PCEP Initialization Phase to indicate that it
The decision when to instantiate or delete a PCE-initiated LSP is out supports the procedures of this document.
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 ([I-D.ietf-pce-stateful-pce]), and
the LSP object MUST include the Symbolic Path Name TLV and MUST have
a PLSP-ID ([I-D.ietf-pce-stateful-pce]) of 0.
For an instantiation operation, the PCE MUST include the ERO and END- This document defines a new PCEP message, the LSP Initiate Request
POINTS object and may include various attributes as per [RFC5440]. (PCInitiate) message, which a PCE can send to a PCE to request the
The PCC creates the LSP using the attributes communicated by the PCE, initiaton or deletion of an LSP. The decision when to instantiate or
and local values for the unspecified parameters. It assigns a unique delete a PCE-initiated LSP is out of the scope of this document.
PLSP-ID for the LSP and automatically delegates the LSP to the PCE.
It MUST also generate 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 MUST also set 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 and SHOULD include the optional SPEAKER-IDENTITY-
ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations]
identifying the PCE that requested the LSP creation. 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 The PCE sends a PCInitiate message to the PCC to request the
are the same as for PCC-initiated LSPs as described in initiation of an LSP. The PCC creates the LSP using the attributes
[I-D.ietf-pce-stateful-pce], with the exception that the PCC cannot communicated by the PCE and local values for any unspecified
revoke a delegation for a PCE-initiated LSP. This applies to the parameters. The PCC generates an LSP State Report (PCRpt) for the
case of a PCE failure as well. In order to allow for network cleanup LSP, carrying a newly assigned PLSP-ID for the LSP and delegating the
without manual intervention, the PCC SHOULD support removal of PCE- LSP to the PCE via the Delegate flag in the LSP object.
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 new R flag in The PCE can update the attributes of the LSP by sending subsequent
the SRP object in a PCInitiate message as described in Section 5.2. PCUpd messages. Subsequent LSP State Report (PCRpt) and LSP Update
As a result of the deletion request, the PCC MUST remove all state Request (PCUpd) messages that the PCC and PCE, respectively, send for
related to the LSP, and send a PCRpt with the R flag set in the LSP the LSP will carry the PCC-assigned PLSP-ID, which uniquely
object for the removed state. See details in Section 5.4. identifies the LSP. See details in Section 5.3.
LSP State Synchronization procedures are described in section 5.4 of The PCE sends a PCInitiate message to the PCC to request the deletion
[I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC of an LSP. To indicate a delete operation, this document defines the
reports the state of its LSPs to the PCE using PCRpt messages and new R flag in the SRP object in the PCInitiate message, as described
setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the in Section 5.2. As a result of the deletion request, the PCC removes
PCC MUST also include the Create Flag in the LSP Object and SHOULD all state related to the LSP and sends a PCRpt for the removed state.
include the SPEAKER-IDENTITY-ID TLV identifying the PCE that See details in Section 5.4.
requested the LSP creation. At the end of state synchronization, the
PCE SHOULD do a sanity check between the reported PCE-Initiated LSPs
and local configurations at PCE to initiate LSPs. For any mismatch,
the PCE SHOULD send a PCInitiate message to either initiate (again)
or remove the LSP.
4. Support of PCE-initiated LSPs 4. Support of PCE-initiated LSPs
A PCEP speaker indicates its ability to support PCE-provisioned A PCEP speaker indicates its ability to support PCE-initiated LSPs
dynamic LSPs during the PCEP Initialization phase. The Open Object during the PCEP Initialization phase, as follows. When the PCEP
in the Open message contains the "Stateful PCE Capability" TLV, session is created, it sends an Open message with an OPEN object that
defined in [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP- contains the "Stateful PCE Capability" TLV, defined in
INSTANTIATION-CAPABILITY) flag is introduced to indicate support for [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP-INSTANTIATION-
CAPABILITY) flag, is introduced to this TLV to indicate support for
instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only
for PCCs that advertised this capability and a PCC will follow the for PCCs that advertised this capability. A PCC will follow the
procedures described in this document only on sessions where the PCE procedures described in this document only on sessions where the PCE
advertised the I flag. advertised the I flag.
4.1. Stateful PCE Capability TLV 4.1. STATEFUL-PCE-CAPABILITY TLV
The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
following figure: following figure:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=4 | | Type | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U| | Flags |I|S|U|
skipping to change at page 7, line 4 skipping to change at page 6, line 29
The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it
has a fixed length of 4 octets. has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits). The U and S The value comprises a single field - Flags (32 bits). The U and S
bits are defined in [I-D.ietf-pce-stateful-pce] and bits are defined in [I-D.ietf-pce-stateful-pce] and
[I-D.ietf-pce-stateful-sync-optimizations] respectively. [I-D.ietf-pce-stateful-sync-optimizations] respectively.
I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 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 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 may PCE. If set to 1 by a PCE, the I flag indicates that the PCE
attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY
flag must be set by both PCC and PCE in order to support PCE- flag must be set by both PCC and PCE in order to enable PCE-
initiated LSP instantiation. initiated LSP instantiation.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
5. PCE-initiated LSP Instantiation and Deletion 5. PCE-initiated LSP Instantiation and Deletion
To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The
message format, objects and TLVs are discussed separately below for message format, objects and TLVs are discussed separately below for
the creation and the deletion cases. the creation and the deletion cases.
5.1. The LSP Initiate Message 5.1. The LSP Initiate Request
A Path Computation LSP Initiate Message is referred to as PCInitiate An LSP Initiate Request (PCInitiate) message is a PCEP message sent
message. It is a PCEP message sent by a PCE to a PCC to trigger LSP by a PCE to a PCC to trigger LSP instantiation or deletion. The
instantiation or deletion. The Message-Type field of the PCEP common Message-Type field of the PCEP common header for the PCInitiate
header for the PCInitiate message is set to 12 (suggested value, to message is set to 12. The PCInitiate message MUST include the SRP
be assigned by IANA). The PCInitiate message MUST include the SRP
and the LSP objects, and MAY contain other objects, as discussed and the LSP objects, and MAY contain other objects, as discussed
later in this section. Missing SRP and LSP objects in the PCInitiate later in this section.
message MUST trigger the same PCErr procedures as specified in
[I-D.ietf-pce-stateful-pce] for PCUpd. LSP instantiation is done by
sending a PCInitiate message with an LSP object with the reserved
PLSP-ID 0. LSP deletion is done by sending a PCInitiate 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 The format of a PCInitiate message is as follows:
follows:
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<Common Header> is defined in [RFC5440]
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>| <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP> <PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<ERO> <ERO>
[<attribute-list>] [<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP> <PCE-initiated-lsp-deletion> ::= <SRP>
<LSP> <LSP>
Where: Where:
<attribute-list> is defined in [RFC5440] and extended by <attribute-list> is defined in [RFC5440] and extended by
PCEP extensions. PCEP extensions.
The SRP object is used to correlate between initiation requests sent The SRP object is defined in [I-D.ietf-pce-stateful-pce]. The SRP
by the PCE and the error reports and state reports sent by the PCC. Object contains an SRP-ID-number which is unique within a PCEP
Every request from the PCE receives a new SRP-ID-number. This number session. The PCE increments the last-used SRP-ID-number before it
is unique per PCEP session and is incremented each time an operation sends each PCInitiate message. The PCC MUST echo the value of the
(initiation, update, etc) is requested from the PCE. The value of SRP-ID-number in PCErr and PCRpt messages that it sends as a result
the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt of the PCInitiate to allow the PCE to correlate them with the
messages to allow for correlation between requests made by the PCE corresponding PCInitiate message.
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 5.2. The R flag in the SRP Object
The format of the SRP object is shown Figure 2: The format of the SRP object is shown in Figure 2:
0 1 2 3 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 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| | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SRP Object format 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 A new flag is defined to indicate a delete operation initiated by the
PCE: PCE:
R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request R (LSP-REMOVE - 1 bit): If set to 0, it indicates a request to
initiated by the PCE. create an LSP. If set to 1, it indicates a request to remove an
LSP.
5.3. LSP Instantiation 5.3. LSP Instantiation
LSP instantiation is done by sending an PCInitiate Message with an The LSP is instantiated by sending a PCInitiate message. The LSP is
LSP object with the reserved PLSP-ID 0. The LSP is set up using set up using RSVP-TE. Extensions for other setup methods are outside
RSVP-TE, extensions for other setup methods are outside the scope of the scope of this draft.
this draft.
Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R The PCInitiate message, when used to instantiate an LSP, MUST contain
flag in the SRP object set to zero MUST result in a PCErr message of an LSP object with the reserved PLSP-ID 0. The LSP Object MUST
type 19 (Invalid Operation) and value to be assigned by IANA, include the SYMBOLIC-PATH-NAME TLV, which is used to correlate
suggested value 8 (Non-zero PLSP-ID in LSP initiation request). between the PCC-assigned PLSP-ID and the LSP.
The PCInitiate message, when used to instantiate an LSP, MUST contain
an Explicit Route Object (ERO) for the LSP.
For an instantiation request of an RSVP-signaled LSP, the destination For an instantiation request of an RSVP-signaled LSP, the destination
address may be needed. The PCC may determine it from a provided address may be needed. The PCC MAY determine it from a provided
object (e.g., ERO) or a local decision. Alternatively, the END- object (e.g., ERO) or a local decision. Alternatively, the END-
POINTS object MAY be included to explicitly convey the destination POINTS object MAY be included to explicitly convey the destination
addresses to be used in the RSVP-TE signaling. The source address addresses to be used in the RSVP-TE signaling. The source address
may be either specified or left up to the PCC decision using the MAY be either specified or left up to the PCC decision using the
0.0.0.0 value. For LSPs to be setup by other means, the END-POINTS 0.0.0.0 value. For LSPs to be setup by other means, the END-POINTS
object MAY be omitted; the exact behavior for other types of LSPs object MAY be omitted; the exact behavior for other types of LSPs
will be specified in further documents. will be specified in further documents.
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
the TLV is missing, the PCC MUST send a PCErr message with Error-
type=10 (Invalid object) and Error-value to be assigned by IANA,
suggested value 8, (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 to be assigned by IANA, suggested value 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 The PCE MAY include various attributes as per [RFC5440]. The PCC
MUST use these values in the LSP instantiation, and local values for MUST use these values in the LSP instantiation, and local values for
unspecified parameters. After the LSP setup, the PCC MUST send a unspecified parameters. After the LSP setup, the PCC MUST send a
PCRpt to the PCE, reflecting these values. The SRP object in the PCRpt to the PCE, reflecting these values. The SRP object in the
PCRpt message MUST echo the value of the PCInitiate message that PCRpt message MUST echo the value of the PCInitiate message that
triggered the setup. LSPs that were instantiated as a result of a triggered the setup. LSPs that were instantiated as a result of a
PCInitiate message MUST have the Create flag (Section 5.3.1) set in PCInitiate message MUST have the Create flag (Section 5.3.1) set in
the LSP object. the LSP object.
If the PCC receives a PCInitiate message with a non-zero PLSP-ID and
the R flag in the SRP object set to zero, then it MUST send a PCErr
message with Error-type=19 (Invalid Operation) and Error-value=8
(Non-zero PLSP-ID in the PCInitiate message).
If the PCC receives a PCInitiate message without an ERO and the R
flag in the SRP object set to zero, then it MUST send a PCErr message
with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO
Object missing).
If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME
TLV, then it MUST send a PCErr message with Error-type=10 (Invalid
object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV missing).
The PCE MUST NOT provide a symbolic path name that conflicts with the
symbolic path name of any existing LSP in the PCC. (Existing LSPs
may be either statically configured, or initiated by another PCE).
If there is a conflict with the symbolic path name of an existing
LSP, 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
Interval timer is running (see Section 6).
If the PCC determines that the LSP parameters proposed in the If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST trigger a PCErr with PCInitiate message are unacceptable, it MUST send a PCErr message
error-type to be assigned by IANA, suggested value 24 (PCE with Error-type=24 (PCE instantiation error) and Error-value=1
instantiation error) and error-value=1 (Unacceptable instantiation (Unacceptable instantiation parameters). If the PCC encounters an
parameters). If the PCC encounters an internal error during the internal error during the processing of the PCInitiate message, it
processing of the PCInitiate message, it MUST trigger a PCErr with MUST send a PCErr message with Error-type=24 (PCE instantiation
error-type to be assigned by IANA, suggested vlaue 24 (PCE error) and Error-value=2 (Internal error).
instantiation error) and error-value=2 (Internal error).
A PCC MUST relay to the PCE errors it encounters in the setup of PCE- A PCC MUST relay to the PCE errors it encounters in the setup of PCE-
initiated LSP by sending a PCErr with error-type to be assigned by initiated LSP by sending a PCErr message with Error-type=24 (PCE
IANA, suggeseted value 24 (PCE instantiation error) and error-value=3 instantiation error) and Error-value=3 (Signaling error). The PCErr
(Signaling error). The PCErr MUST echo the SRP-ID-number of the message MUST echo the SRP-ID-number of the PCInitiate message. The
PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP
Error Spec TLV (if an ERROR SPEC was returned to the PCC by a ERROR_SPEC object was returned to the PCC by a downstream node).
downstream node). After the LSP is set up, errors in RSVP signaling After the LSP is set up, errors in RSVP signaling are reported in
are reported in PCRpt messages, as described in PCRpt messages, as described in [I-D.ietf-pce-stateful-pce].
[I-D.ietf-pce-stateful-pce].
On successful completion of the LSP instantiation, the PCC MUST send
a PCRpt message. The LSP object message MUST contain a non-zero
PLSP-ID that uniquely identifies the LSP within this PCC, and MUST
have the Create flag (Section 5.3.1) and Delegate flag set. The SRP
object MUST contain an SRP-ID-number that echoes the value from the
PCInitiate message that triggered the setup. The PCRpt MUST include
the attributes that the PCC used to instantiate the LSP.
A PCC SHOULD be able to place a limit on either the number of LSPs or 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 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 LSP requests. As soon as that limit is reached, the PCC MUST send a
PCErr message of type 19 (Invalid Operation) and value to be assigned PCErr message with Error-type=19 (Invalid Operation) and Error-
by IANA (PCE-initiated limit reached) and is free to drop any value=6 (PCE-initiated LSP limit reached) and is free to drop any
incoming PCInitiate messages without additional processing. incoming PCInitiate messages without additional processing.
Similarly, the PCE SHOULD be able to place a limit on either the 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 number of PCInitiate messages pending for a particular PCC, or on the
the time it waits for a response (positive or negative) to a time it waits for a response (positive or negative) to a PCInitiate
PCInitiate request from a PCC and MAY take further action (such as message from a PCC and MAY take further action (such as closing the
closing the session or removing all its LSPs) if this limit is session or removing all its LSPs) if this limit is reached.
reached.
On successful 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.
5.3.1. The Create Flag 5.3.1. The Create Flag
The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
here for easy reference. here for easy reference.
0 1 2 3 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 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| | PLSP-ID |Flags |C| O |A|R|S|D|
skipping to change at page 11, line 43 skipping to change at page 11, line 5
Figure 3: The LSP Object format Figure 3: The LSP Object format
A new flag, the Create (C) flag is introduced. On a PCRpt message, 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 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 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 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 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 that would otherwise only be known by the PCC and the PCE that
initiated them). initiated them).
5.3.2. The SPEAKER-IDENTITY-ID TLV 5.3.2. The SPEAKER-ENTITY-ID TLV
The optional SPEAKER-IDENTITY-ID TLV defined in The optional SPEAKER-ENTITY-ID TLV defined in
[I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP
object in a PCRpt message, as an optional TLV for LSPs for which the object in a PCRpt message, as an optional TLV for LSPs for which the
C flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE which C flag is 1. The SPEAKER-ENTITY-ID TLV identifies the PCE which
initiated the creation of the LSP on all PCEP sessions, a state that initiated the creation of the LSP on all PCEP sessions, a state that
would otherwise only be known by the PCC and the PCE that initiated would otherwise only be known by the PCC and the PCE that initiated
the LSP. If the TLV appears in a PCRpt for an LSP for which the C the LSP. If the TLV appears in a PCRpt for an LSP for which the C
flag is 0, the TLV MUST be ignored the and the PCE MUST send a PCErr flag is 0, the LSP MUST be ignored and the PCE MUST send a PCErr
message with Error-type 23 ("Bad parameter value") and error value 2 message with Error-type=23 ("Bad parameter value") and Error-value=2
("Speaker identity included for an LSP that is not PCE-initiated"). ("Speaker identity included for an LSP that is not PCE-initiated").
5.4. LSP Deletion 5.4. LSP Deletion
PCE-initiated removal of a PCE-initiated LSP is done by setting the R A PCE can initiate the removal of a PCE-initiated LSP by sending a
(remove) flag in the SRP Object in the PCInitiate message from the PCInitiate message with an LSP object carrying the PLSP-ID of the LSP
PCE. The LSP is identified by the PLSP-ID in the LSP object. If the to be removed and an SRP object with the R flag set (see
PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, Section 5.2). A PLSP-ID of zero removes all LSPs that were initiated
error value 3, "Unknown PLSP-ID" ([I-D.ietf-pce-stateful-pce]). A by the PCE.
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 If the PLSP-ID is unknown, the PCC MUST send a PCErr message with
the PCE, the PCC MUST send a PCErr message indicating "LSP is not Error-type=19 ("Invalid operation") and Error-value=3 ("Unknown PLSP-
delegated" (Error code 19, error value 1 as per ID") ([I-D.ietf-pce-stateful-pce]).
[I-D.ietf-pce-stateful-pce]). If the PLSP-ID specified in the
PCInitiate message was not created by a PCE, the PCC MUST send a If the PLSP-ID specified in the PCInitiate message is not delegated
PCErr message indicating that the LSP is not PCE-initiated, Error to the PCE, the PCC MUST send a PCErr message with Error-type=19
code 19, error value to be assigned by IANA, suggested value 9 (LSP ("Invalid operation") and Error-value=1 ("LSP is not delegated")
is not PCE-initiated). Following the removal of the LSP, the PCC ([I-D.ietf-pce-stateful-pce]).
MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The
SRP object in the PCRpt MUST include the SRP-ID-number from the If the PLSP-ID specified in the PCInitiate message was not created by
PCInitiate message that triggered the removal. The R flag in the SRP a PCE, the PCC MUST send a PCErr message with Error-type=19 ("Invalid
object MUST be set. operation") and Error-value=9 ("LSP is not PCE-initiated").
Following the removal of the LSP, the PCC MUST send a PCRpt as
described in [I-D.ietf-pce-stateful-pce]. The SRP object in the
PCRpt MUST include the SRP-ID-number from the PCInitiate message that
triggered the removal. The R flag in the SRP object MUST be set.
6. LSP Delegation and Cleanup 6. LSP Delegation and Cleanup
PCE-initiated LSPs are automatically delegated by the PCC to the PCE The PCC MUST delegate PCE-initiated LSPs to the PCE upon
upon instantiation. The PCC MUST set the delegation bit to 1 in the instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt
PCRpt that includes the assigned PLSP-ID. All subsequent messages that includes the assigned PLSP-ID.
from the PCC to the PCE that initiated the LSP 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 to the PCE that initiated
the LSP results in a PCErr message of type 19 (Invalid Operation) and
error-value value to be assigned by IANA, suggested value 7,
(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 The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an
between PCEs. Doing so MUST trigger the State Timeout Interval timer active PCEP session. Therefore, all PCRpt messages from the PCC to
([I-D.ietf-pce-stateful-pce]) for that particular LSP. the PCE that owns the delegation MUST have the delegation bit set to
1. If the PCE that owns the delegation receives a PCRpt message with
the delegation bit set to 0 then it MUST send a PCErr message with
Error-type=19 ("Invalid Operation") and Error-value=7 ("Delegation
for PCE-initiated LSP cannot be revoked"). The PCE MAY further react
by closing the session.
In case of PCEP session failure, control over PCE-initiated LSPs Control over a PCE-initiated LSP can revert to the PCC in two ways.
reverts to the PCC at the expiration of the redelegation timeout. At A PCE MAY return a delegation to the PCC to allow for LSP transfer
this point, the LSP is an "orphan" until the expiration of the State between PCEs. Alternatively, the PCC gains control an LSP if the
Timeout timer. To obtain control of a PCE-initiated LSP, a PCE PCEP session that it was delegated on fails and the Redelegation
(either the original or one of its backups) sends a PCInitiate Timeout Interval timer expires. In both cases, the LSP becomes an
orphan until the expiration of the State Timeout Interval timer
([I-D.ietf-pce-stateful-pce]).
The PCC MAY attempt to redelegate an orphaned LSP by following the
procedures of [I-D.ietf-pce-stateful-pce]. Alternatively, if the
orphaned LSP was PCE-initiated, then a PCE MAY obtain control over
it, as follows.
A PCE (either the original or one of its backups) sends a PCInitiate
message, including just the SRP and LSP objects, and carrying the message, including just the SRP and LSP objects, and carrying the
PLSP-ID of the LSP it wants to take control of. On receipt of a PLSP-ID of the LSP it wants to take control of. If the PCC receives
PCInitiate message with a PLSP-ID pointing to an orphan LSP, the PCC a PCInitiate message with a PLSP-ID pointing to an orphaned PCE-
MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST initiated LSP, then it MUST redelegate that LSP to the PCE. Any
result in the generation of a PCErr. The State Timeout timer for the other non-zero PLSP-ID MUST result in the generation of a PCErr
LSP is stopped upon the redelegation. After obtaining control of the message using the rules described in Section 5.4. The State Timeout
LSP, the PCE may remove it using the procedures described in this Interval timer for the LSP is stopped upon the redelegation. After
document. 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 The State Timeout Interval timer ensures that a PCE crash does not
automatic and immediate disruption for the services using PCE- result in automatic and immediate disruption for the services using
initiated LSPs. PCE-initiated LSPs are not be removed immediately PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately
upon PCE failure. Instead, they are cleaned up on the expiration of upon PCE failure. Instead, they are cleaned up on the expiration of
this timer. This allows for network cleanup without manual this timer. This allows for network cleanup without manual
intervention. The PCC SHOULD support removal of PCE-initiated LSPs intervention. The PCC SHOULD support removal of PCE-initiated LSPs
as one of the behaviors applied on expiration of the State Timeout as one of the behaviors applied on expiration of the State Timeout
Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked Interval timer. The behavior SHOULD be picked based on local policy,
based on local policy, and can result either in LSP removal, or into and can result either in LSP removal, or in reverting to operator-
reverting to operator-defined default parameters. defined default parameters.
7. Implementation Status 7. LSP State Synchronization
LSP State Synchronization procedures are described in section 5.4 of
[I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC
reports the state of its LSPs to the PCE using PCRpt messages,
setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the
PCC MUST also set the Create Flag in the LSP Object and MAY include
the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
creation. At the end of state synchronization, the PCE SHOULD
compare the reported PCE-Initiated LSPs with its configuration. For
any mismatch, the PCE SHOULD send a PCInitiate message to initiate
any missing LSPs and/or remove any LSPs that are not wanted.
8. Implementation Status
This section to be removed by the RFC editor. This section to be removed by the RFC editor.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
skipping to change at page 14, line 5 skipping to change at page 13, line 39
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
Two vendors are implementing the extensions described in this draft Two vendors are implementing the extensions described in this draft
and have included the functionality in releases that will be shipping and have included the functionality in releases that will be shipping
in the near future. An additional entity is working on implementing in the near future. An additional entity is working on implementing
these extensions in the scope of research projects. these extensions in the scope of research projects.
8. IANA Considerations 9. IANA Considerations
8.1. PCEP Messages This document requests IANA actions to allocate code points for the
protocol elements defined in this document.
IANA is requested to allocate a new message type within the "PCEP 9.1. PCEP Messages
Messages" sub-registry of the PCEP Numbers registry, as follows:
IANA is requested to confirm the early allocation of the following
new message type within the "PCEP Messages" sub-registry of the PCEP
Numbers registry, and to update the reference in the registry to
point to this document, when it is an RFC:
Value Meaning Reference Value Meaning Reference
12 Initiate This document 12 LSP Initiate Request This document
8.2. LSP Object Note to IANA: The early allocation was done for a message called
"Initiate". This name has changed to "LSP Initiate Request" as
above.
9.2. LSP Object
[I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that [I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that
IANA creates a registry to manage the value of the LSP Object's Flag IANA creates a registry to manage the value of the LSP Object's Flag
field. IANA is requested to allocate a new bit in the LSP Object field. IANA is requested to allocate a new bit in the LSP Object
Flag Field registry, as follows: Flag Field registry, as follows:
Bit Description Reference Bit Description Reference
4 Create This document 4 Create This document
8.3. SRP object 9.3. SRP object
This document requests that a new sub-registry, named "SRP Object This document requests that a new sub-registry, named "SRP Object
Flag Field", is created within the "Path Computation Element Protocol Flag Field", is created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Flag field of the SRP object. (PCEP) Numbers" registry to manage the Flag field of the SRP object.
New values are to be assigned by Standards Action [RFC5226]. Each New values are to be assigned by Standards Action [RFC5226]. Each
bit should be tracked with the following qualities: bit number bit should be tracked with the following qualities: bit number
(counting from bit 0 as the most significant bit), description and (counting from bit 0 as the most significant bit), description and
defining RFC. defining RFC.
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
31 LSP-Remove This document 31 LSP-Remove This document
8.4. STATEFUL-PCE-CAPABILITY TLV 9.4. STATEFUL-PCE-CAPABILITY TLV
[I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV [I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV
and requests that IANA creates a registry to manage the value of the and requests that IANA creates a registry to manage the value of the
STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to
allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field
registry, as follows: registry, as follows:
Bit Description Reference Bit Description Reference
29 I (LSP-INSTANTIATION- This document 29 I (LSP-INSTANTIATION- This document
CAPABILITY) CAPABILITY)
8.5. PCEP-Error Object 9.5. PCEP-Error Object
IANA is requested to allocate new error types and error values within IANA is requested to confirm the early allocation of the following
the "PCEP-ERROR Object Error Types and Values" sub-registry of the new error types and error values within the "PCEP-ERROR Object Error
PCEP Numbers registry, as follows: Types and Values" sub-registry of the PCEP Numbers registry, and to
update the reference in the registry to point to this document, when
it is an RFC:
Error-Type Meaning Error-Type Meaning
10 Invalid Object 10 Invalid Object
Error-value=8: SYMBOLIC-PATH-NAME TLV missing Error-value=8: SYMBOLIC-PATH-NAME TLV missing
19 Invalid operation 19 Invalid operation
Error-value=6: PCE-initiated LSP limit reached Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked be revoked
Error-value=8: Non-zero PLSP-ID in LSP initiation Error-value=8: Non-zero PLSP-ID in PCInitiate message
request
Error-value=9: LSP is not PCE-initiated Error-value=9: LSP is not PCE-initiated
Error-value=10: PCE-initiated operation-frequency limit Error-value=10: PCE-initiated operation-frequency limit
reached reached
23 Bad parameter value 23 Bad parameter value
Error-value=1: SYMBOLIC-PATH-NAME in use Error-value=1: SYMBOLIC-PATH-NAME in use
Error-value=2: Speaker identity included for an LSP Error-value=2: Speaker identity included for an LSP
that is not PCE-initiated that is not PCE-initiated
24 LSP instantiation error 24 LSP instantiation error
Error-value=1: Unacceptable instantiation parameters Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error Error-value=2: Internal error
Error-value=3: Signaling error Error-value=3: Signaling error
9. Security Considerations 10. Security Considerations
The security considerations described in [I-D.ietf-pce-stateful-pce] The security considerations described in [I-D.ietf-pce-stateful-pce]
apply to the extensions described in this document. Additional apply to the extensions described in this document. Additional
considerations related to a malicious PCE are introduced. considerations related to a malicious PCE are introduced.
9.1. Malicious PCE 10.1. Malicious PCE
The LSP instantiation mechanism described in this document allows a The LSP instantiation mechanism described in this document allows a
PCE to generate state on the PCC and throughout the network. As 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 result, it introduces a new attack vector: an attacker may flood the
PCC with LSP instantiation requests and consume network and LSR PCC with LSP instantiation requests and consume network and LSR
resources, either by spoofing messages or by compromising the PCE resources, either by spoofing messages or by compromising the PCE
itself. itself.
A PCC can protect itself from such an attack by imposing a limit on 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 either the number of LSPs or the percentage of resources that are
allocated to honor PCE-initiated LSP requests. As soon as that limit 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 is reached, the PCC MUST send a PCErr message with Error-type=19
Operation) and value to be assigned by IANA, suggested value 6 (PCE- ("Invalid Operation") and Error-value=6 ("PCE-initiated LSP limit
initiated LSP limit reached) and is free to drop any incoming reached") and is free to drop any incoming PCInitiate messages for
PCInitiate messages for LSP instantiation without additional LSP instantiation without additional processing.
processing.
Rapid flaps triggered by the PCE can also be an attack vector. A PCC Rapid flaps triggered by the PCE can also be an attack vector. A PCC
can protect itself from such an attack by imposing a limit on the can protect itself from such an attack by imposing a limit on the
number of flaps per unit of time that it allows a PCE to generate. number of flaps per unit of time that it allows a PCE to generate.
As soon as that limit is reached, a PCC MUST send a PCErr message of As soon as that limit is reached, a PCC MUST send a PCErr message
type 19 (Invalid Operation) and value to be assigned by IANA, with Error-type=19 ("Invalid Operation") and Error-value=10 ("PCE-
suggested value 10 (PCE-initiated operation frequency reached) and is initiated operation frequency reached") and is free to treat the
free to treat the session as having reached the limit in terms of session as having reached the limit in terms of resources allocated
resources allocated to honor PCE-initiated LSP requests, either to honor PCE-initiated LSP requests, either permanently or for a
permanently or for a locally-defined cool-off period. locally-defined cool-off period.
9.2. Malicious PCC 10.2. Malicious PCC
The LSP instantiation mechanism described in this document requires The LSP instantiation mechanism described in this document requires
the PCE to keep state for LSPs that it instantiates and relies on the 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 PCC responding (with either a state report or an error message) to
requests for LSP instantiation. A malicious PCC or one that reached requests for LSP instantiation. A malicious PCC or one that reached
the limit of the number of PCE-initiated LSPs, can ignore PCE the limit of the number of PCE-initiated LSPs, can ignore PCE
requests and consume PCE resources. A PCE can protect itself by requests and consume PCE resources. A PCE can protect itself by
imposing a limit on the number of requests pending, or by setting a 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 timeout and it MAY take further action such as closing the session or
removing all the LSPs it initiated. removing all the LSPs it initiated.
10. Acknowledgements 11. Acknowledgements
We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas,
Cyril Margaria, Dhruv Dhody, and Raveendra Trovi for their Cyril Margaria, Dhruv Dhody, Raveendra Trovi and Jon Hardwick for
contributions to this document. their contributions to this document.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-18 (work in progress), December 2016. pce-21 (work in progress), June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <http://www.rfc-editor.org/info/rfc5511>. 2009, <http://www.rfc-editor.org/info/rfc5511>.
11.2. Informative References 12.2. Informative References
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-09 (work in ietf-pce-stateful-sync-optimizations-10 (work in
progress), February 2017. progress), March 2017.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <http://www.rfc-editor.org/info/rfc4657>. 2006, <http://www.rfc-editor.org/info/rfc4657>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
 End of changes. 71 change blocks. 
289 lines changed or deleted 292 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/