draft-ietf-pce-stateful-pce-21.txt   rfc8231.txt 
PCE Working Group E. Crabbe Internet Engineering Task Force (IETF) E. Crabbe
Internet-Draft Oracle Request for Comments: 8231 Oracle
Intended status: Standards Track I. Minei Category: Standards Track I. Minei
Expires: December 21, 2017 Google, Inc. ISSN: 2070-1721 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
June 19, 2017 September 2017
PCEP Extensions for Stateful PCE Path Computation Element Communication Protocol (PCEP)
draft-ietf-pce-stateful-pce-21 Extensions for Stateful PCE
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 Client (PCC) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across control of timing and sequence of path computations within and across
PCEP sessions. This document describes a set of extensions to PCEP PCEP sessions. This document describes a set of extensions to PCEP
to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. to enable stateful control of MPLS-TE and GMPLS Label Switched Paths
(LSPs) via PCEP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 21, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8231.
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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 ....................................................5
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language ......................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................5
3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 3. Motivation and Objectives for Stateful PCE ......................6
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Motivation .................................................6
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Background ..........................................6
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 3.1.2. Why a Stateful PCE? .................................7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 3.1.3. Protocol vs. Configuration ..........................8
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Objectives .................................................9
4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 4. New Functions to Support Stateful PCEs ..........................9
5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 5. Overview of Protocol Extensions ................................10
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership .......................................10
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 5.2. New Messages ..............................................11
5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 5.3. Error Reporting ...........................................11
5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 5.4. Capability Advertisement ..................................11
5.5. IGP Extensions for Stateful PCE Capabilities 5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 Advertisement .............................................12
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.6. State Synchronization .....................................13
5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 5.7. LSP Delegation ............................................16
5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 5.7.1. Delegating an LSP ..................................16
5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 5.7.2. Revoking a Delegation ..............................17
5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 5.7.3. Returning a Delegation .............................19
5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 5.7.4. Redundant Stateful PCEs ............................19
5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 5.7.5. Redelegation on PCE Failure ........................20
5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19 5.8. LSP Operations ............................................21
5.8.1. Passive Stateful PCE Path Computation 5.8.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . 19 Request/Response ...................................21
5.8.2. Switching from Passive Stateful to Active Stateful . 21 5.8.2. Switching from Passive Stateful to Active
5.8.3. Active Stateful PCE LSP Update . . . . . . . . . . . 22 Stateful ...........................................22
5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23 5.8.3. Active Stateful PCE LSP Update .....................23
5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23 5.9. LSP Protection ............................................24
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 5.10. PCEP Sessions ............................................24
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 6. PCEP Messages ..................................................25
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 26 6.1. The PCRpt Message .........................................25
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 28 6.2. The PCUpd Message .........................................27
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29 6.3. The PCErr Message .........................................30
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30 6.4. The PCReq Message .........................................31
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30 6.5. The PCRep Message .........................................31
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30 7. Object Formats .................................................32
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30 7.1. OPEN Object ...............................................32
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33 7.2. SRP Object ................................................33
7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35 7.3. LSP Object ................................................34
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38 7.3.1. LSP-IDENTIFIERS TLVs ...............................36
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39 7.3.2. Symbolic Path Name TLV .............................39
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 40 7.3.3. LSP Error Code TLV .................................40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7.3.4. RSVP Error Spec TLV ................................41
8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 41 8. IANA Considerations ............................................42
8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 8.1. PCE Capabilities in IGP Advertisements ....................42
8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 42 8.2. PCEP Messages .............................................43
8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. PCEP Objects ..............................................43
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 43 8.4. LSP Object ................................................44
8.6. Notification Object . . . . . . . . . . . . . . . . . . . 43 8.5. PCEP-Error Object .........................................45
8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 44 8.6. Notification Object .......................................46
8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 44 8.7. PCEP TLV Type Indicators ..................................46
8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 45 8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
9. Manageability Considerations . . . . . . . . . . . . . . . . 45 8.9. LSP-ERROR-CODE TLV ........................................47
9.1. Control Function and Policy . . . . . . . . . . . . . . . 45 9. Manageability Considerations ...................................48
9.2. Information and Data Models . . . . . . . . . . . . . . . 46 9.1. Control Function and Policy ...............................48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 47 9.2. Information and Data Models ...............................49
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 47 9.3. Liveness Detection and Monitoring .........................49
9.5. Requirements on Other Protocols and Functional Components 47 9.4. Verifying Correct Operation ...............................49
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 47 9.5. Requirements on Other Protocols and Functional
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 Components ................................................50
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 48 9.6. Impact on Network Operation ...............................50
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 48 10. Security Considerations .......................................50
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 49 10.1. Vulnerability ............................................50
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 49 10.2. LSP State Snooping .......................................51
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 49 10.3. Malicious PCE ............................................51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 10.4. Malicious PCC ............................................52
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 11. References ....................................................52
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 11.1. Normative References .....................................52
13.2. Informative References . . . . . . . . . . . . . . . . . 51 11.2. Informative References ...................................53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................57
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 Computation Element (PCE), or Computation Client (PCC) and a Path Computation Element (PCE), or
between PCEs, enabling computation of Multiprotocol Label Switching between PCEs, enabling computation of Multiprotocol Label Switching
(MPLS) for Traffic Engineering Label Switched Path (TE LSP) (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics. Extensions for support of Generalized MPLS (GMPLS) characteristics. Extensions for support of Generalized MPLS (GMPLS)
in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions] in PCEP are defined in [PCEP-GMPLS].
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
stateful control of LSPs within and across PCEP sessions in stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect Label compliance with [RFC4657]. It includes mechanisms to effect Label
Switched Path (LSP) state synchronization between PCCs and PCEs, Switched Path (LSP) State Synchronization between PCCs and PCEs,
delegation of control over LSPs to PCEs, and PCE control of timing delegation of control over LSPs to PCEs, and PCE control of timing
and sequence of path computations within and across PCEP sessions. and sequence of path computations within and across PCEP sessions.
Extensions to permit the PCE to drive creation of an LSP are defined Extensions to permit the PCE to drive creation of an LSP are defined
in [I-D.ietf-pce-pce-initiated-lsp], which specifies PCE-initiated in [PCE-Init-LSP], which specifies PCE-initiated LSP creation.
LSP creation.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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, PCEP Speaker. PCE, PCEP Peer, and PCEP speaker.
This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC4655]: Traffic
Engineering Database (TED).
This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [RFC3031]: LSP.
This document uses the following terms defined in [RFC8051]: Stateful This document uses the following terms defined in [RFC8051]: Stateful
PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP
Database. State Database.
The following terms are defined in this document: The following terms are defined in this document:
Revocation: an operation performed by a PCC on a previously Revocation: an operation performed by a PCC on a previously
delegated LSP. Revocation revokes the rights granted to the PCE delegated LSP. Revocation revokes the rights granted to the PCE
in the delegation operation. in the delegation operation.
Redelegation Timeout Interval: the period of time a PCC waits for, Redelegation Timeout Interval: the period of time a PCC waits for,
when a PCEP session is terminated, before revoking LSP delegation when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the to a PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE. The Redelegation terminated PCEP session to an alternate PCE. The Redelegation
Timeout Interval is a PCC-local value that can be either operator- Timeout Interval is a PCC-local value that can be either operator
configured or dynamically computed by the PCC based on local configured or dynamically computed by the PCC based on local
policy. policy.
State Timeout Interval: the period of time a PCC waits for, when a State Timeout Interval: the period of time a PCC waits for, when a
PCEP session is terminated, before flushing LSP state associated PCEP session is terminated, before flushing LSP state associated
with that PCEP session and reverting to operator-defined default with that PCEP session and reverting to operator-defined default
parameters or behaviors. The State Timeout Interval is a PCC- parameters or behaviors. The State Timeout Interval is a PCC-
local value that can be either operator-configured or dynamically local value that can be either operator configured or dynamically
computed by the PCC based on local policy. computed by the PCC based on local policy.
LSP State Report: an operation to send LSP state (Operational / LSP State Report: an operation to send LSP state (operational/
Admin Status, LSP attributes configured at the PCC and set by a administrative status, LSP attributes configured at the PCC and
PCE, etc.) from a PCC to a PCE. set by a PCE, etc.) from a PCC to a PCE.
LSP Update Request: an operation where an Active Stateful PCE LSP Update Request: an operation where an Active Stateful PCE
requests a PCC to update one or more attributes of an LSP and to requests a PCC to update one or more attributes of an LSP and to
re-signal the LSP with updated attributes. re-signal the LSP with updated attributes.
SRP-ID-number: a number used to correlate errors and LSP State SRP-ID-number: a number used to correlate errors and LSP State
Reports to LSP Update Requests. It is carried in the SRP Reports to LSP Update Requests. It is carried in the Stateful PCE
(Stateful PCE Request Parameters) Object described in Section 7.2. Request Parameter (SRP) object described in Section 7.2.
Within this document, PCEP communications are described through PCC- Within this document, PCEP communications are described through PCC-
PCE relationship. The PCE architecture also supports the PCE-PCE PCE relationships. The PCE architecture also supports PCE-PCE
communication, by having the requesting PCE fill the role of a PCC, communication, by having the requesting PCE fill the role of a PCC,
as usual. as usual.
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 Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE 3. Motivation and Objectives for Stateful PCE
3.1. Motivation 3.1. Motivation
[RFC8051] presents several use cases, demonstrating scenarios that [RFC8051] presents several use cases, demonstrating scenarios that
benefit from the deployment of a stateful PCE. The scenarios apply benefit from the deployment of a stateful PCE. The scenarios apply
equally to MPLS-TE and GMPLS deployments. equally to MPLS-TE and GMPLS deployments.
3.1.1. Background 3.1.1. Background
Traffic engineering has been a goal of the MPLS architecture since Traffic engineering has been a goal of the MPLS architecture since
its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic its inception [RFC2702] [RFC3031] [RFC3346]. In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209] engineering system provided by [RFC3209], [RFC3630], and [RFC5305],
information about network resources utilization is only available as information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis; total reserved capacity by the traffic class on a per-interface
individual LSP state is available only locally on each LER for its basis; individual LSP state is available only locally on each Label
own LSPs. In most cases, this makes good sense, as distribution and Edge Router (LER) for its own LSPs. In most cases, this makes good
retention of total LSP state for all LERs within in the network would sense, as distribution and retention of total LSP state for all LERs
be prohibitively costly. within in the network would be prohibitively costly.
Unfortunately, this visibility in terms of global LSP state may Unfortunately, this visibility in terms of global LSP state may
result in a number of issues for some demand patterns, particularly result in a number of issues for some demand patterns, particularly
within a common setup and hold priority. This issue affects online within a common setup and hold priority. This issue affects online
traffic engineering systems. traffic engineering systems.
A sufficiently over-provisioned system will by definition have no A sufficiently over-provisioned system will by definition have no
issues routing its demand on the shortest path. However, lowering issues routing its demand on the shortest path. However, lowering
the degree to which network over-provisioning is required in order to the degree to which network over-provisioning is required in order to
run a healthy, functioning network is a clear and explicit promise of run a healthy, functioning network is a clear and explicit promise of
MPLS architecture. In particular, it has been a goal of MPLS to MPLS architecture. In particular, it has been a goal of MPLS to
provide mechanisms to alleviate congestion scenarios in which provide mechanisms to alleviate congestion scenarios in which
"traffic streams are inefficiently mapped onto available resources; "traffic streams are inefficiently mapped onto available resources;
causing subsets of network resources to become over-utilized while causing subsets of network resources to become over-utilized while
others remain underutilized" ([RFC2702]). others remain underutilized" [RFC2702].
3.1.2. Why a Stateful PCE? 3.1.2. Why a Stateful PCE?
[RFC4655] defines a stateful PCE to be one in which the PCE maintains [RFC4655] defines a stateful PCE to be one in which the PCE maintains
"strict synchronization between the PCE and not only the network "strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network." set of computed paths and reserved resources in use in the network."
[RFC4655] also expressed a number of concerns with regard to a [RFC4655] also expressed a number of concerns with regard to a
stateful PCE, specifically: stateful PCE, specifically:
o Any reliable synchronization mechanism would result in significant o Any reliable synchronization mechanism would result in significant
control plane overhead control-plane overhead
o Out-of-band TED synchronization would be complex and prone to race o Out-of-band TED synchronization would be complex and prone to race
conditions conditions
o Path calculations incorporating total network state would be o Path calculations incorporating total network state would be
highly complex highly complex
In general, stress on the control plane will be directly proportional In general, stress on the control plane will be directly proportional
to the size of the system being controlled and the tightness of the to the size of the system being controlled and the tightness of the
control loop, and indirectly proportional to the amount of over- control loop and indirectly proportional to the amount of over-
provisioning in terms of both network capacity and reservation provisioning in terms of both network capacity and reservation
overhead. overhead.
Despite these concerns in terms of implementation complexity and Despite these concerns in terms of implementation complexity and
scalability, several TE algorithms exist today that have been scalability, several TE algorithms exist today that have been
demonstrated to be extremely effective in large TE systems, providing demonstrated to be extremely effective in large TE systems, providing
both rapid convergence and significant benefits in terms of both rapid convergence and significant benefits in terms of
optimality of resource usage [MXMN-TE]. All of these systems share optimality of resource usage [MXMN-TE]. All of these systems share
at least two common characteristics: the requirement for both global at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for visibility of a flow (or in this case, a TE LSP) state and for
ordered control of path reservations across devices within the system ordered control of path reservations across devices within the system
being controlled. While some approaches have been suggested in order being controlled. While some approaches have been suggested in order
to remove the requirements for ordered control (See [MPLS-PC]), these to remove the requirements for ordered control (see [MPLS-PC]), these
approaches are highly dependent on traffic distribution, and do not approaches are highly dependent on traffic distribution and do not
allow for multiple simultaneous LSP priorities representing diffserv allow for multiple simultaneous LSP priorities representing Diffserv
classes. classes.
The use cases described in [RFC8051] demonstrate a need for The use cases described in [RFC8051] demonstrate a need for
visibility into global inter-PCC LSP state in PCE path computations, visibility into global inter-PCC LSP state in PCE path computations
and for PCE control of sequence and timing in altering LSP path and for PCE control of sequence and timing in altering LSP path
characteristics within and across PCEP sessions. characteristics within and across PCEP sessions.
3.1.3. Protocol vs. Configuration 3.1.3. Protocol vs. Configuration
Note that existing configuration tools and protocols can be used to Note that existing configuration tools and protocols can be used to
set LSP state, such as a Command Line Interface (CLI) tool. However, set LSP state, such as a Command Line Interface (CLI) tool. However,
this solution has several shortcomings: this solution has several shortcomings:
o Scale & Performance: configuration operations often have o Scale & Performance: configuration operations often have
transactional semantics which are typically heavyweight and often transactional semantics that are typically heavyweight and often
require processing of additional configuration portions beyond the require processing of additional configuration portions beyond the
state being directly acted upon, with corresponding cost in CPU state being directly acted upon, with corresponding cost in CPU
cycles, negatively impacting both PCC stability LSP update rate cycles, negatively impacting both PCC stability LSP Update rate
capacity. capacity.
o Security: when a PCC opens a configuration channel allowing a PCE o Security: when a PCC opens a configuration channel allowing a PCE
to send configuration, a malicious PCE may take advantage of this to send configuration, a malicious PCE may take advantage of this
ability to take over the PCC. In contrast, the PCEP extensions ability to take over the PCC. In contrast, the PCEP extensions
described in this document only allow a PCE control over a very described in this document only allow a PCE control over a very
limited set of LSP attributes. limited set of LSP attributes.
o Interoperability: each vendor has a proprietary information model o Interoperability: each vendor has a proprietary information model
for configuring LSP state, which limits interoperability of a for configuring LSP state, which limits interoperability of a
stateful PCE with PCCs from different vendors. The PCEP stateful PCE with PCCs from different vendors. The PCEP
extensions described in this document allow for a common extensions described in this document allow for a common
information model for LSP state for all vendors. information model for LSP state for all vendors.
o Efficient State Synchronization: configuration channels may be o Efficient State Synchronization: configuration channels may be
heavyweight and unidirectional, therefore efficient state heavyweight and unidirectional; therefore, efficient State
synchronization between a PCC and a PCE may be a problem. Synchronization between a PCC and a PCE may be a problem.
3.2. Objectives 3.2. Objectives
The objectives for the protocol extensions to support stateful PCE The objectives for the protocol extensions to support stateful PCE
described in this document are as follows: described in this document are as follows:
o Allow a single PCC to interact with a mix of stateless and o Allow a single PCC to interact with a mix of stateless and
stateful PCEs simultaneously using the same protocol, i.e. PCEP. stateful PCEs simultaneously using the same protocol, i.e., PCEP.
o Support efficient LSP state synchronization between the PCC and o Support efficient LSP State Synchronization between the PCC and
one or more active or passive stateful PCEs. one or more active or passive stateful PCEs.
o Allow a PCC to delegate control of its LSPs to an active stateful o Allow a PCC to delegate control of its LSPs to an active stateful
PCE such that a given LSP is under the control of a single PCE at PCE such that a given LSP is under the control of a single PCE at
any given time. any given time.
* A PCC may revoke this delegation at any time during the * A PCC may revoke this delegation at any time during the
lifetime of the LSP. If LSP delegation is revoked while the lifetime of the LSP. If LSP delegation is revoked while the
PCEP session is up, the PCC MUST notify the PCE about the PCEP session is up, the PCC MUST notify the PCE about the
revocation. revocation.
* A PCE may return an LSP delegation at any point during the * A PCE may return an LSP delegation at any point during the
lifetime of the PCEP session. If LSP delegation is returned by lifetime of the PCEP session. If LSP delegation is returned by
the PCE while the PCEP session is up, the PCE MUST notify the the PCE while the PCEP session is up, the PCE MUST notify the
PCC about the returned delegation. PCC about the returned delegation.
o Allow a PCE to control computation timing and update timing across o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it. all LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event of a PCE o Enable uninterrupted operation of a PCC's LSPs in the event of a
failure or while control of LSPs is being transferred between PCE failure or while control of LSPs is being transferred between
PCEs. PCEs.
4. New Functions to Support Stateful PCEs 4. New Functions to Support Stateful PCEs
Several new functions are required in PCEP to support stateful PCEs. Several new functions are required in PCEP to support stateful PCEs.
A function can be initiated either from a PCC towards a PCE (C-E) or A function can be initiated either from a PCC towards a PCE (C-E) or
from a PCE towards a PCC (E-C). The new functions are: from a PCE towards a PCC (E-C). The new functions are:
Capability advertisement (E-C,C-E): both the PCC and the PCE must Capability advertisement (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP announce during PCEP session establishment that they support PCEP
Stateful PCE extensions defined in this document. Stateful PCE extensions defined in this document.
LSP state synchronization (C-E): after the session between the PCC LSP State Synchronization (C-E): after the session between the PCC
and a stateful PCE is initialized, the PCE must learn the state of and a stateful PCE is initialized, the PCE must learn the state of
a PCC's LSPs before it can perform path computations or update LSP a PCC's LSPs before it can perform path computations or update LSP
attributes in a PCC. attributes in a PCC.
LSP Update Request (E-C): a PCE requests modification of attributes LSP Update Request (E-C): a PCE requests modification of attributes
on a PCC's LSP. on a PCC's LSP.
LSP State Report (C-E): a PCC sends an LSP state report to a PCE LSP State Report (C-E): a PCC sends an LSP State Report to a PCE
whenever the state of an LSP changes. whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the authoritative source of the LSP's attributes as long as the
delegation is in effect (See Section 5.7); the PCC may withdraw delegation is in effect (see Section 5.7); the PCC may withdraw
the delegation or the PCE may give up the delegation at any time. the delegation or the PCE may give up the delegation at any time.
Similarly to [RFC5440], no assumption is made about the discovery Similarly to [RFC5440], no assumption is made about the discovery
method used by a PCC to discover a set of PCEs (e.g., via static method used by a PCC to discover a set of PCEs (e.g., via static
configuration or dynamic discovery) and on the algorithm used to configuration or dynamic discovery) and on the algorithm used to
select a PCE. select a PCE.
5. Overview of Protocol Extensions 5. Overview of Protocol Extensions
5.1. LSP State Ownership 5.1. LSP State Ownership
In PCEP (defined in [RFC5440]), LSP state and operation are under the In PCEP (defined in [RFC5440]), LSP state and operation are under the
control of a PCC (a PCC may be an LSR or a management station). control of a PCC (a PCC may be a Label Switching Router (LSR) or a
Attributes received from a PCE are subject to PCC's local policy. management station). Attributes received from a PCE are subject to
The PCEP extensions described in this document do not change this PCC's local policy. The PCEP extensions described in this document
behavior. do not change this behavior.
An active stateful PCE may have control of a PCC's LSPs that were An active stateful PCE may have control of a PCC's LSPs that were
delegated to it, but the LSP state ownership is retained by the PCC. delegated to it, but the LSP state ownership is retained by the PCC.
In particular, in addition to specifying values for LSP's attributes, In particular, in addition to specifying values for LSP's attributes,
an active stateful PCE also decides when to make LSP modifications. an active stateful PCE also decides when to make LSP modifications.
Retaining LSP state ownership on the PCC allows for: Retaining LSP state ownership on the PCC allows for:
o a PCC to interact with both stateless and stateful PCEs at the o a PCC to interact with both stateless and stateful PCEs at the
same time same time
o a stateful PCE to only modify a small subset of LSP parameters, o a stateful PCE to only modify a small subset of LSP parameters,
i.e. to set only a small subset of the overall LSP state; other i.e., to set only a small subset of the overall LSP state; other
parameters may be set by the operator, for example through command parameters may be set by the operator, for example, through CLI
line interface (CLI) commands commands
o a PCC to revert delegated LSP to an operator-defined default or to o a PCC to revert delegated LSP to an operator-defined default or to
delegate the LSPs to a different PCE, if the PCC get disconnected delegate the LSPs to a different PCE, if the PCC gets disconnected
from a PCE with currently delegated LSPs from a PCE with currently delegated LSPs
5.2. New Messages 5.2. New Messages
In this document, we define the following new PCEP messages: In this document, we define the following new PCEP messages:
Path Computation State Report (PCRpt): a PCEP message sent by a PCC Path Computation State Report (PCRpt): a PCEP message sent by a PCC
to a PCE to report the status of one or more LSPs. Each LSP State to a PCE to report the status of one or more LSPs. Each LSP State
Report in a PCRpt message MAY contain the actual LSP's path, Report in a PCRpt message MAY contain the actual LSP's path,
bandwidth, operational and administrative status, etc. An LSP bandwidth, operational and administrative status, etc. An LSP
skipping to change at page 10, line 22 skipping to change at page 11, line 42
| State Synchronization (C-E) | PCRpt | | State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt | | LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd | | LSP Update Request (E-C) | PCUpd |
+----------------------------------------+--------------+ +----------------------------------------+--------------+
Table 1: New Function to Message Mapping Table 1: New Function to Message Mapping
5.3. Error Reporting 5.3. Error Reporting
Error reporting is done using the procedures defined in [RFC5440], Error reporting is done using the procedures defined in [RFC5440] and
and reusing the applicable error types and error values of [RFC5440] reusing the applicable error types and error values of [RFC5440]
wherever appropriate. The current document defines new error values wherever appropriate. The current document defines new error values
for several error types to cover failures specific to stateful PCE. for several error types to cover failures specific to stateful PCE.
5.4. Capability Advertisement 5.4. Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During the PCEP initialization phase, PCEP speakers (PCE or PCC)
advertise their support of stateful PCEP extensions. A PCEP Speaker advertise their support of PCEP Stateful PCE extensions. A PCEP
includes the "Stateful PCE Capability" TLV, described in speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in
Section 7.1.1, in the OPEN Object to advertise its support for PCEP Section 7.1.1, in the OPEN object to advertise its support for PCEP
stateful extensions. The Stateful Capability TLV includes the 'LSP Stateful PCE extensions. The STATEFUL-PCE-CAPABILITY TLV includes
Update' Flag that indicates whether the PCEP Speaker supports LSP the 'LSP Update' flag that indicates whether the PCEP speaker
parameter updates. supports LSP parameter updates.
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP extensions for stateful PCEs MUST NOT be used if one or both The PCEP extensions for stateful PCEs MUST NOT be used if one or both
PCEP Speakers have not included the Stateful PCE Capability TLV in PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV in
their respective OPEN message. If the PCEP Speaker on the PCC their respective OPEN message. If the PCEP speaker on the PCC
supports the extensions of this draft but did not advertise this supports the extensions of this specification but did not advertise
capability, then upon receipt of PCUpd message from the PCE, it MUST this capability, then upon receipt of a PCUpd message from the PCE,
generate a PCErr with error-type 19 (Invalid Operation), error-value it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid
2 (Attempted LSP Update Request if the stateful PCE capability was Operation) and error-value 2 (Attempted LSP Update Request if the
not advertised)(see Section 8.5) and it SHOULD terminate the PCEP stateful PCE capability was not advertised)(see Section 8.5), and it
session. If the PCEP Speaker on the PCE supports the extensions of SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE
this draft but did not advertise this capability, then upon receipt supports the extensions of this specification but did not advertise
of a PCRpt message from the PCC, it MUST generate a PCErr with error- this capability, then upon receipt of a PCRpt message from the PCC,
type 19 (Invalid Operation), error-value 5 (Attempted LSP State it MUST generate a PCErr with Error-type=19 (Invalid Operation) and
Report if stateful PCE capability was not advertised) (see error-value 5 (Attempted LSP State Report if stateful PCE capability
Section 8.5) and it SHOULD terminate the PCEP session. was not advertised) (see Section 8.5), and it SHOULD terminate the
PCEP session.
LSP delegation and LSP update operations defined in this document may LSP delegation and LSP Update operations defined in this document may
only be used if both PCEP Speakers set the LSP-UPDATE-CAPABILITY Flag only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag
in the "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'.
If this is not the case and LSP delegation or LSP update operations If this is not the case and LSP delegation or LSP Update operations
are attempted, then a PCErr with error-type 19 (Invalid Operation) are attempted, then a PCErr with Error-type=19 (Invalid Operation)
and error-value 1 (Attempted LSP Update Request for a non-delegated and error-value 1 (Attempted LSP Update Request for a non-delegated
LSP) (see Section 8.5) MUST be generated. Note that, even if one of LSP) (see Section 8.5) MUST be generated. Note that, even if one of
the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its
"Stateful Capability" TLV, a PCE can still operate as a passive STATEFUL-PCE-CAPABILITY TLV, a PCE can still operate as a passive
stateful PCE by accepting LSP State Reports from the PCC in order to stateful PCE by accepting LSP State Reports from the PCC in order to
build and maintain an up to date view of the state of the PCC's LSPs. build and maintain an up-to-date view of the state of the PCC's LSPs.
5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the consists of utilizing IGP advertisements. Extensions for the
advertisement of PCE Discovery Information are defined for OSPF and advertisement of PCE Discovery Information are defined for OSPF and
for IS-IS in [RFC5088] and [RFC5089] respectively. for IS-IS in [RFC5088] and [RFC5089], respectively.
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional
TLV used to advertise PCE capabilities. It MAY be present within the sub-TLV used to advertise PCE capabilities. It MAY be present within
PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS. [RFC5088]
provide the description and processing rules for this sub-TLV when and [RFC5089] provide the description and processing rules for this
carried within OSPF and IS-IS, respectively. sub-TLV when carried within OSPF and IS-IS, respectively.
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
reference: reference:
Type: 5 Type: 5
Length: Multiple of 4. Length: Multiple of 4.
Value: This contains an array of units of 32 bit flags with the most Value: This contains an array of units of 32-bit flags with the most
significant bit as 0. Each bit represents one PCE capability. significant bit as 0. Each bit represents one PCE capability.
PCE capability bits are defined in [RFC5088]. This document defines PCE capability bits are defined in [RFC5088]. This document defines
new capability bits for the stateful PCE as follows: new capability bits for the stateful PCE as follows:
Bit Capability Bit Capability
11 Active Stateful PCE capability --- -------------------------------
12 Passive Stateful PCE capability 11 Active stateful PCE capability
12 Passive stateful PCE capability
Note that while active and passive stateful PCE capabilities may be Note that while active and passive stateful PCE capabilities may be
advertised during discovery, PCEP Speakers that wish to use stateful advertised during discovery, PCEP speakers that wish to use stateful
PCEP MUST negotiate stateful PCEP capabilities during PCEP session PCEP MUST negotiate stateful PCEP capabilities during PCEP session
setup, as specified in the current document. A PCC MAY initiate setup, as specified in the current document. A PCC MAY initiate
stateful PCEP capability negotiation at PCEP session setup even if it stateful PCEP capability negotiation at PCEP session setup even if it
did not receive any IGP PCE capability advertisements. did not receive any IGP PCE capability advertisements.
5.6. State Synchronization 5.6. State Synchronization
The purpose of State Synchronization is to provide a checkpoint-in- The purpose of State Synchronization is to provide a
time state replica of a PCC's LSP state in a PCE. State checkpoint-in-time state replica of a PCC's LSP state in a PCE.
Synchronization is performed immediately after the Initialization State Synchronization is performed immediately after the
phase ([RFC5440]). initialization phase [RFC5440].
During State Synchronization, a PCC first takes a snapshot of the During State Synchronization, a PCC first takes a snapshot of the
state of its LSPs state, then sends the snapshot to a PCE in a state of its LSPs, then it sends the snapshot to a PCE in a sequence
sequence of LSP State Reports. Each LSP State Report sent during of LSP State Reports. Each LSP State Report sent during State
State Synchronization has the SYNC Flag in the LSP Object set to 1. Synchronization has the SYNC flag in the LSP object set to 1. The
The set of LSPs for which state is synchronized with a PCE is set of LSPs for which state is synchronized with a PCE is determined
determined by the PCC's local configuration (see more details in by the PCC's local configuration (see more details in Section 9.1)
Section 9.1) and MAY also be determined by stateful PCEP capabilities and MAY also be determined by stateful PCEP capabilities defined in
defined in other documents, such as other documents, such as [RFC8232].
[I-D.ietf-pce-stateful-sync-optimizations].
The end of synchronization marker is a PCRpt message with the SYNC The end of the synchronization marker is a PCRpt message with the
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved SYNC flag set to 0 for an LSP object with PLSP-ID equal to the
value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT reserved value 0 (see Section 7.3). In this case, the LSP object
include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the
IDENTIFIERS TLV with the special value of all zeroes. The PCRpt LSP-IDENTIFIERS TLV with the special value of all zeroes. The PCRpt
message MUST include an empty ERO as its intended path and SHOULD NOT message MUST include an empty Explicit Route Object (ERO) as its
include the optional RRO object for its actual path. If the PCC has intended path and SHOULD NOT include the optional Record Route Object
no state to synchronize, it SHOULD only send the end of (RRO) for its actual path. If the PCC has no state to synchronize,
synchronization marker. it SHOULD only send the end of the synchronization marker.
A PCE SHOULD NOT send PCUpd messages to a PCC before State A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
Either the PCE or the PCC MAY terminate the session using the PCEP Either the PCE or the PCC MAY terminate the session using the PCEP
session termination procedures during the synchronization phase. If session termination procedures during the synchronization phase. If
the session is terminated, the PCE MUST clean up state it received the session is terminated, the PCE MUST clean up the state it
from this PCC. The session reestablishment MUST be re-attempted per received from this PCC. The session re-establishment MUST be
the procedures defined in [RFC5440], including use of a back-off re-attempted per the procedures defined in [RFC5440], including use
timer. of a backoff timer.
If the PCC encounters a problem which prevents it from completing the If the PCC encounters a problem that prevents it from completing the
LSP state synchronization, it MUST send a PCErr message with error- LSP State Synchronization, it MUST send a PCErr message with
type 20 (LSP State Synchronization Error) and error-value 5 error-type 20 (LSP State Synchronization Error) and error-value 5
(indicating an internal PCC error) to the PCE and terminate the (indicating an internal PCC error) to the PCE and terminate the
session. session.
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgments for properly received
synchronization messages. It MUST respond with a PCErr message with synchronization messages. It MUST respond with a PCErr message with
error-type 20 (LSP State Synchronization Error) and error-value 1 Error-type=20 (LSP State Synchronization Error) and error-value 1
(indicating an error in processing the PCRpt) (see Section 8.5) if it (indicating an error in processing the PCRpt) (see Section 8.5) if it
encounters a problem with the LSP State Report it received from the encounters a problem with the LSP State Report it received from the
PCC and it MUST terminate the session. PCC, and it MUST terminate the session.
A PCE implementing a limit on the resources a single PCC can occupy, A PCE implementing a limit on the resources a single PCC can occupy
MUST send a PCNtf message with Notification Type 4 (Stateful PCE MUST send a PCEP Notify (PCNtf) message with Notification Type 4
resource limit exceeded) and Notification Value 1 (Entering resource (Stateful PCE resource limit exceeded) and Notification Value 1
limit exceeded state) in response to the PCRpt message triggering (Entering resource limit exceeded state) in response to the PCRpt
this condition in the synchronization phase and MUST terminate the message triggering this condition in the synchronization phase and
session. MUST terminate the session.
The successful State Synchronization sequence is shown in Figure 1. The successful State Synchronization sequence is shown in Figure 1.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| (Sync start) |-----PCRpt, SYNC=1----->| (Sync start)
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
skipping to change at page 13, line 49 skipping to change at page 15, line 25
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
| | | |
|-----PCRpt, SYNC=0----->| (End of sync marker |-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report | | LSP State Report
| | for PLSP-ID=0) | | for PLSP-ID=0)
| | (Sync done) | | (Sync done)
Figure 1: Successful state synchronization Figure 1: Successful State Synchronization
The sequence where the PCE fails during the State Synchronization The sequence where the PCE fails during the State Synchronization
phase is shown in Figure 2. phase is shown in Figure 2.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
skipping to change at page 14, line 28 skipping to change at page 15, line 50
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-PCRpt, SYNC=1 | |-PCRpt, SYNC=1 |
| \ ,-PCErr | | \ ,-PCErr |
| \ / | | \ / |
| \/ | | \/ |
| /\ | | /\ |
| / `-------->| (Ignored) | / `-------->| (Ignored)
|<--------` | |<--------` |
Figure 2: Failed state synchronization (PCE failure) Figure 2: Failed State Synchronization (PCE Failure)
The sequence where the PCC fails during the State Synchronization The sequence where the PCC fails during the State Synchronization
phase is shown in Figure 3. phase is shown in Figure 3.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-------- PCErr=? ------>| |-------- PCErr=? ------>|
| | | |
Figure 3: Failed state synchronization (PCC failure) Figure 3: Failed State Synchronization (PCC Failure)
Optimizations to the synchronization procedures and alternate Optimizations to the synchronization procedures and alternate
mechanisms of providing the synchronization function are outside the mechanisms of providing the synchronization function are outside the
scope of this document and are discussed elsewhere (see scope of this document and are discussed elsewhere (see [RFC8232]).
[I-D.ietf-pce-stateful-sync-optimizations]).
5.7. LSP Delegation 5.7. LSP Delegation
If during Capability advertisement both the PCE and the PCC have If during capability advertisement both the PCE and the PCC have
indicated that they support LSP Update, then the PCC may choose to indicated that they support LSP Update, then the PCC may choose to
grant the PCE a temporary right to update (a subset of) LSP grant the PCE a temporary right to update (a subset of) LSP
attributes on one or more LSPs. This is called "LSP Delegation", and attributes on one or more LSPs. This is called "LSP delegation", and
it MAY be performed at any time after the Initialization phase, it MAY be performed at any time after the initialization phase,
including during the State Synchronization phase. including during the State Synchronization phase.
A PCE MAY return an LSP delegation at any time if it no longer wishes A PCE MAY return an LSP delegation at any time if it no longer wishes
to update the LSP's state. A PCC MAY revoke an LSP delegation at any to update the LSP's state. A PCC MAY revoke an LSP delegation at any
time. Delegation, Revocation, and Return are done individually for time. Delegation, Revocation, and Return are done individually for
each LSP. each LSP.
In the event of a delegation being rejected or returned by a PCE, the In the event of a delegation being rejected or returned by a PCE, the
PCC SHOULD react based on local policy. It can, for example, either PCC SHOULD react based on local policy. It can, for example, either
retry delegating to the same PCE using an exponentially increasing retry delegating to the same PCE using an exponentially increasing
timer or delegate to an alternate PCE. timer or delegate to an alternate PCE.
5.7.1. Delegating an LSP 5.7.1. Delegating an LSP
A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP A PCC delegates an LSP to a PCE by setting the Delegate flag in the
State Report to 1. If the PCE does not accept the LSP Delegation, it LSP State Report to 1. If the PCE does not accept the LSP
MUST immediately respond with an empty LSP Update Request which has delegation, it MUST immediately respond with an empty LSP Update
the Delegate flag set to 0. If the PCE accepts the LSP Delegation, Request that has the Delegate flag set to 0. If the PCE accepts the
it MUST set the Delegate flag to 1 when it sends an LSP Update LSP delegation, it MUST set the Delegate flag to 1 when it sends an
Request for the delegated LSP (note that this may occur at a later LSP Update Request for the delegated LSP (note that this may occur at
time). The PCE MAY also immediately acknowledge a delegation by a later time). The PCE MAY also immediately acknowledge a delegation
sending an empty LSP Update Request which has the Delegate flag set by sending an empty LSP Update Request that has the Delegate flag set
to 1. to 1.
The delegation sequence is shown in Figure 4. The delegation sequence is shown in Figure 4.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP Delegated |---PCRpt, Delegate=1--->| LSP delegated
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| . | | . |
| . | | . |
| . | | . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
skipping to change at page 16, line 31 skipping to change at page 17, line 37
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP State Report sent to the PCE. the Delegate flag to 1 on each LSP State Report sent to the PCE.
5.7.2. Revoking a Delegation 5.7.2. Revoking a Delegation
5.7.2.1. Explicit Revocation 5.7.2.1. Explicit Revocation
When a PCC decides that a PCE is no longer permitted to modify an When a PCC decides that a PCE is no longer permitted to modify an
LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke
an LSP delegation at any time during the LSP's life time. A PCC an LSP delegation at any time during the LSP's lifetime. A PCC
revoking an LSP delegation MAY immediately remove the updated revoking an LSP delegation MAY immediately remove the updated
parameters provided by the PCE and revert to the operator-defined parameters provided by the PCE and revert to the operator-defined
parameters, but to avoid traffic loss, it SHOULD do so in a make- parameters, but to avoid traffic loss, it SHOULD do so in a
before-break fashion. If the PCC has received but not yet acted on make-before-break fashion. If the PCC has received but not yet acted
PCUpd messages from the PCE for the LSP whose delegation is being on PCUpd messages from the PCE for the LSP whose delegation is being
revoked, then it SHOULD ignore these PCUpd messages when processing revoked, then it SHOULD ignore these PCUpd messages when processing
the message queue. All effects of all messages for which processing the message queue. All effects of all messages for which processing
started before the revocation took place MUST be allowed to complete started before the revocation took place MUST be allowed to complete,
and the result MUST be given the same treatment as any LSP that had and the result MUST be given the same treatment as any LSP that had
been previously delegated to the PCE (e.g. the state MAY immediately been previously delegated to the PCE (e.g., the state MAY immediately
revert to the operator-defined parameters). revert to the operator-defined parameters).
If a PCEP session with the PCE to which the LSP is delegated exists If a PCEP session with the PCE to which the LSP is delegated exists
in the UP state during the revocation, the PCC MUST notify that PCE in the UP state during the revocation, the PCC MUST notify that PCE
by sending an LSP State Report with the Delegate flag set to 0, as by sending an LSP State Report with the Delegate flag set to 0, as
shown in Figure 5. shown in Figure 5.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
skipping to change at page 17, line 21 skipping to change at page 18, line 26
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| . | | . |
| . | | . |
| . | | . |
|---PCRpt, Delegate=0--->| PCC revokes delegation |---PCRpt, Delegate=0--->| PCC revokes delegation
| | | |
Figure 5: Revoking a Delegation Figure 5: Revoking a Delegation
After an LSP delegation has been revoked, a PCE can no longer update After an LSP delegation has been revoked, a PCE can no longer update
LSP's parameters; an attempt to update parameters of a non-delegated an LSP's parameters; an attempt to update parameters of a
LSP will result in the PCC sending a PCErr message with error-type 19 non-delegated LSP will result in the PCC sending a PCErr message with
(Invalid Operation), error-value 1 (attempted LSP Update Request for Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP
a non-delegated LSP) (see Section 8.5). Update Request for a non-delegated LSP) (see Section 8.5).
5.7.2.2. Revocation on Redelegation Timeout 5.7.2.2. Revocation on Redelegation Timeout
When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
MUST wait the time interval specified in Redelegation Timeout MUST wait the time interval specified in the Redelegation Timeout
Interval before revoking LSP delegations to that PCE and attempting Interval before revoking LSP delegations to that PCE and attempting
to redelegate LSPs to an alternate PCE. If a PCEP session with the to redelegate LSPs to an alternate PCE. If a PCEP session with the
original PCE can be reestablished before the Redelegation Timeout original PCE can be re-established before the Redelegation Timeout
Interval timer expires, LSP delegations to the PCE remain intact. Interval timer expires, LSP delegations to the PCE remain intact.
Likewise, when a PCC's PCEP session with a PCE terminates Likewise, when a PCC's PCEP session with a PCE terminates
unexpectedly, and the PCC does not succeed in redelegating its LSPs, unexpectedly, and the PCC does not succeed in redelegating its LSPs,
the PCC MUST wait for the State Timeout Interval before flushing any the PCC MUST wait for the State Timeout Interval before flushing any
LSP state associated with that PCE. Note that the State Timeout LSP state associated with that PCE. Note that the State Timeout
Interval timer may expire before the PCC has redelegated the LSPs to Interval timer may expire before the PCC has redelegated the LSPs to
another PCE, for example if a PCC is not connected to any active another PCE, for example, if a PCC is not connected to any active
stateful PCE or if no connected active stateful PCE accepts the stateful PCE or if no connected active stateful PCE accepts the
delegation. In this case, the PCC MUST flush any LSP state set by delegation. In this case, the PCC MUST flush any LSP state set by
the PCE upon expiration of the State Timeout Interval and revert to the PCE upon expiration of the State Timeout Interval and revert to
operator-defined default parameters or behaviors. This operation operator-defined default parameters or behaviors. This operation
SHOULD be done in a make-before-break fashion. SHOULD be done in a make-before-break fashion.
The State Timeout Interval MUST be greater than or equal to the The State Timeout Interval MUST be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact). set by the PCE, they will remain intact).
5.7.3. Returning a Delegation 5.7.3. Returning a Delegation
In order to keep a delegation, a PCE MUST set the Delegate flag to 1 In order to keep a delegation, a PCE MUST set the Delegate flag to 1
on each LSP Update Request sent to the PCC. A PCE that no longer on each LSP Update Request sent to the PCC. A PCE that no longer
wishes to update an LSP's parameters SHOULD return the LSP delegation wishes to update an LSP's parameters SHOULD return the LSP delegation
back to the PCC by sending an empty LSP Update Request which has the back to the PCC by sending an empty LSP Update Request that has the
Delegate flag set to 0. If a PCC receives an LSP Update Request with Delegate flag set to 0. If a PCC receives an LSP Update Request with
the Delegate flag set to 0 (whether the LSP Update Request is empty the Delegate flag set to 0 (whether the LSP Update Request is empty
or not), it MUST treat this as a delegation return. or not), it MUST treat this as a delegation return.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP delegated |---PCRpt, Delegate=1--->| LSP delegated
| . | | . |
skipping to change at page 18, line 33 skipping to change at page 19, line 38
|<--PCUpd, Delegate=0----| Delegation returned |<--PCUpd, Delegate=0----| Delegation returned
| | | |
|---PCRpt, Delegate=0--->| No delegation for LSP |---PCRpt, Delegate=0--->| No delegation for LSP
| | | |
Figure 6: Returning a Delegation Figure 6: Returning a Delegation
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC stateful PCE accepts the delegation), the LSP delegation on the PCC
will time out within a configurable Redelegation Timeout Interval and will timeout within a configurable Redelegation Timeout Interval, and
the PCC MUST flush any LSP state set by a PCE at the expiration of the PCC MUST flush any LSP state set by a PCE at the expiration of
the State Timeout Interval and revert to operator-defined default the State Timeout Interval and revert to operator-defined default
parameters or behaviors. parameters or behaviors.
5.7.4. Redundant Stateful PCEs 5.7.4. Redundant Stateful PCEs
In a redundant configuration where one PCE is backing up another PCE, In a redundant configuration where one PCE is backing up another PCE,
the backup PCE may have only a subset of the LSPs in the network the backup PCE may have only a subset of the LSPs in the network
delegated to it. The backup PCE does not update any LSPs that are delegated to it. The backup PCE does not update any LSPs that are
not delegated to it. In order to allow the backup to operate in a not delegated to it. In order to allow the backup to operate in a
hot-standby mode and avoid the need for state synchronization in case hot-standby mode and avoid the need for State Synchronization in case
the primary fails, the backup receives all LSP State Reports from a the primary fails, the backup receives all LSP State Reports from a
PCC. When the primary PCE for a given LSP set fails, after expiry of PCC. When the primary PCE for a given LSP set fails, after expiry of
the Redelegation Timeout Interval, the PCC SHOULD delegate to the the Redelegation Timeout Interval, the PCC SHOULD delegate to the
redundant PCE all LSPs that had been previously delegated to the redundant PCE all LSPs that had been previously delegated to the
failed PCE. Assuming that the State Timeout Interval had been failed PCE. Assuming that the State Timeout Interval had been
configured to be greater than the Redelegation Timeout Interval (as configured to be greater than the Redelegation Timeout Interval (as
MANDATORY), and assuming that the primary and redundant PCEs take MANDATORY), and assuming that the primary and redundant PCEs take
similar decisions, this delegation change will not cause any changes similar decisions, this delegation change will not cause any changes
to the LSP parameters. to the LSP parameters.
5.7.5. Redelegation on PCE Failure 5.7.5. Redelegation on PCE Failure
On failure, the goal is to: 1) avoid any traffic loss on the LSPs On failure, the goal is to: 1) avoid any traffic loss on the LSPs
that were updated by the PCE that crashed 2) minimize the churn in that were updated by the PCE that crashed, 2) minimize the churn in
the network in terms of ownership of the LSPs, 3) not leave any the network in terms of ownership of the LSPs, 3) not leave any
"orphan" (undelegated) LSPs and 4) be able to control when the state "orphan" (undelegated) LSPs, and 4) be able to control when the state
that was set by the PCE can be changed or purged. The values chosen that was set by the PCE can be changed or purged. The values chosen
for the Redelegation Timeout and State Timeout values affect the for the Redelegation Timeout and State Timeout values affect the
ability to accomplish these goals. ability to accomplish these goals.
This section summarizes the behaviour with regards to LSP delegation This section summarizes the behavior with regards to LSP delegation
and LSP state on a PCE failure. and LSP state on a PCE failure.
If the PCE crashes but recovers within the Redelegation Timeout, both If the PCE crashes but recovers within the Redelegation Timeout, both
the delegation state and the LSP state are kept intact. the delegation state and the LSP state are kept intact.
If the PCE crashes but does not recover within the Redelegation If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State redelegate the LSPs to another PCE, then upon expiration of the State
skipping to change at page 20, line 16 skipping to change at page 21, line 21
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) Path computation |----- PCReq message --->| 1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation request sent to | |2) Path computation
PCE | | request received, PCE | | request received,
| | path computed | | path computed
| | | |
|<---- PCRep message ----|3) Computed paths |<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC | (Positive reply) | sent to the PCC
| (Negative reply) | | (Negative reply) |
4) LSP State change | | 4) LSP state change | |
event | | event | |
| | | |
5) LSP State Report |----- PCRpt message --->| 5) LSP State Report |----- PCRpt message --->|
sent to all | . | sent to all | . |
stateful PCEs | . | stateful PCEs | . |
| . | | . |
6) Repeat for each |----- PCRpt message --->| 6) Repeat for each |----- PCRpt message --->|
LSP state change | | LSP state change | |
| | | |
Figure 7: Passive Stateful PCE Path Computation Request/Response Figure 7: Passive Stateful PCE Path Computation Request/Response
Once a PCC has successfully established a PCEP session with a passive Once a PCC has successfully established a PCEP session with a passive
stateful PCE and the PCC's LSP state is synchronized with the PCE stateful PCE and the PCC's LSP state is synchronized with the PCE
(i.e. the PCE knows about all PCC's existing LSPs), if an event is (i.e., the PCE knows about all of the PCC's existing LSPs), if an
triggered that requires the computation of a set of paths, the PCC event is triggered that requires the computation of a set of paths,
sends a path computation request to the PCE ([RFC5440], the PCC sends a path computation request to the PCE ([RFC5440],
Section 4.2.3). The PCReq message MAY contain the LSP Object to Section 4.2.3). The PCReq message MAY contain the LSP object to
identify the LSP for which the path computation is requested. identify the LSP for which the path computation is requested.
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation and returns either a positive or a triggers a path computation and returns either a positive or a
negative reply to the PCC ([RFC5440], Section 4.2.4). negative reply to the PCC ([RFC5440], Section 4.2.4).
Upon receiving a positive path computation reply, the PCC receives a Upon receiving a positive path computation reply, the PCC receives a
set of computed paths and starts to setup the LSPs. For each LSP, it set of computed paths and starts to set up the LSPs. For each LSP,
MAY send an LSP State Report carried on a PCRpt message to the PCE, it MAY send an LSP State Report carried on a PCRpt message to the
indicating that the LSP's status is "Going-up". PCE, indicating that the LSP's status is "Going-up".
Once an LSP is up or active, the PCC MUST send an LSP State Report Once an LSP is up or active, the PCC MUST send an LSP State Report
carried on a PCRpt message to the PCE, indicating that the LSP's carried on a PCRpt message to the PCE, indicating that the LSP's
status is 'Up' or 'Active' respectively. If the LSP could not be set status is 'Up' or 'Active', respectively. If the LSP could not be
up, the PCC MUST send an LSP State Report indicating that the LSP is set up, the PCC MUST send an LSP State Report indicating that the LSP
"Down' and stating the cause of the failure. Note that due to timing is 'Down' and stating the cause of the failure. Note that due to
constraints, the LSP status may change from 'Going-up' to 'Up' (or timing constraints, the LSP status may change from 'Going-up' to 'Up'
'Down') before the PCC has had a chance to send an LSP State Report (or 'Down') before the PCC has had a chance to send an LSP State
indicating that the status is 'Going-up'. In such cases, the PCC MAY Report indicating that the status is 'Going-up'. In such cases, the
choose to only send the PCRpt indicating the latest status ('Active', PCC MAY choose to only send the PCRpt indicating the latest status
'Up' or 'Down'). ('Active', 'Up', or 'Down').
Upon receiving a negative reply from a PCE, a PCC MAY resend a Upon receiving a negative reply from a PCE, a PCC MAY resend a
modified request or take any other appropriate action. For each modified request or take any other appropriate action. For each
requested LSP, it SHOULD also send an LSP State Report carried on a requested LSP, it SHOULD also send an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Down'. PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
There is no direct correlation between PCRep and PCRpt messages. For There is no direct correlation between PCRep and PCRpt messages. For
a given LSP, multiple LSP State Reports will follow a single PCRep a given LSP, multiple LSP State Reports will follow a single PCRep
message, as a PCC notifies a PCE of the LSP's state changes. message, as a PCC notifies a PCE of the LSP's state changes.
skipping to change at page 21, line 36 skipping to change at page 22, line 43
5.8.2. Switching from Passive Stateful to Active Stateful 5.8.2. Switching from Passive Stateful to Active Stateful
This section deals with the scenario of an LSP transitioning from a This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation. When the passive stateful to an active stateful mode of operation. When the
LSP has no working path, prior to delegating the LSP, the PCC MUST LSP has no working path, prior to delegating the LSP, the PCC MUST
first use the procedure defined in Section 5.8.1 to request the first use the procedure defined in Section 5.8.1 to request the
initial path from the PCE. This is required because the action of initial path from the PCE. This is required because the action of
delegating the LSP to a PCE using a PCRpt message is not an explicit delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the PCE to compute a path for the LSP. The only explicit request to the PCE to compute a path for the LSP. The only explicit
way for a PCC to request a path from PCE is to send a PCReq message. way for a PCC to request a path from the PCE is to send a PCReq
The PCRpt message MUST NOT be used by the PCC to attempt to request a message. The PCRpt message MUST NOT be used by the PCC to attempt to
path from the PCE. request a path from the PCE.
When the LSP is delegated after its setup, it may be useful for the When the LSP is delegated after its setup, it may be useful for the
PCC to communicate to the PCE the locally configured intended PCC to communicate to the PCE the locally configured intended
configuration parameters, so that the PCE may reuse them in its configuration parameters, so that the PCE may reuse them in its
computations. Such parameters MAY be acquired through an out of band computations. Such parameters MAY be acquired through an out-of-band
channel, or MAY be communicated in the PCRpt message delegating the channel, or MAY be communicated in the PCRpt message delegating the
LSPs, by including them as part of the intented-attribute-list as LSPs, by including them as part of the intended-attribute-list as
explained in Section 6.1. An implementation MAY allow policies on explained in Section 6.1. An implementation MAY allow policies on
the PCC to determine the configuration parameters to be sent to the the PCC to determine the configuration parameters to be sent to the
PCE. PCE.
5.8.3. Active Stateful PCE LSP Update 5.8.3. Active Stateful PCE LSP Update
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) LSP State |-- PCRpt, Delegate=1 -->| 1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . | Synchronization | . |
| . |2) PCE decides to | . |2) PCE decides to
| . | update the LSP | . | update the LSP
| | | |
|<---- PCUpd message ----|3) PCUpd message sent |<---- PCUpd message ----|3) PCUpd message sent
| | to PCC | | to the PCC
| | | |
| | | |
4) LSP State Report |---- PCRpt message ---->| 4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . | sent(->Going-up) | . |
| . | | . |
| . | | . |
5) LSP State Report |---- PCRpt message ---->| 5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | | sent (->Up|Down) | |
| | | |
Figure 8: Active Stateful PCE Figure 8: Active Stateful PCE
Once a PCC has successfully established a PCEP session with an active Once a PCC has successfully established a PCEP session with an active
stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.,
the PCE knows about all PCC's existing LSPs). After LSPs have been the PCE knows about all of the PCC's existing LSPs). After LSPs have
delegated to the PCE, the PCE can modify LSP parameters of delegated been delegated to the PCE, the PCE can modify LSP parameters of
LSPs. delegated LSPs.
To update an LSP, a PCE MUST send the PCC an LSP Update Request using To update an LSP, a PCE MUST send the PCC an LSP Update Request using
a PCUpd message. The LSP Update Request contains a variety of a PCUpd message. The LSP Update Request contains a variety of
objects that specify the set of constraints and attributes for the objects that specify the set of constraints and attributes for the
LSP's path. Each LSP Update Request MUST have a unique identifier, LSP's path. Each LSP Update Request MUST have a unique identifier,
the SRP-ID-number, carried in the SRP (Stateful PCE Request the SRP-ID-number, carried in the SRP object described in
Parameters) Object described in Section 7.2. The SRP-ID-number is Section 7.2. The SRP-ID-number is used to correlate errors and state
used to correlate errors and state reports to LSP Update Requests. A reports to LSP Update Requests. A single PCUpd message MAY contain
single PCUpd message MAY contain multiple LSP Update Requests. multiple LSP Update Requests.
Upon receiving a PCUpd message the PCC starts to setup LSPs specified Upon receiving a PCUpd message, the PCC starts to set up LSPs
in LSP Update Requests carried in the message. For each LSP, it MAY specified in LSP Update Requests carried in the message. For each
send an LSP State Report carried on a PCRpt message to the PCE, LSP, it MAY send an LSP State Report carried on a PCRpt message to
indicating that the LSP's status is 'Going-up'. If the PCC decides the PCE, indicating that the LSP's status is 'Going-up'. If the PCC
that the LSP parameters proposed in the PCUpd message are decides that the LSP parameters proposed in the PCUpd message are
unacceptable, it MUST report this error by including the LSP-ERROR- unacceptable, it MUST report this error by including the
CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
parameters" in the LSP object in the PCRpt message to the PCE. Based parameters" in the LSP object in the PCRpt message to the PCE. Based
on local policy, it MAY react further to this error by revoking the on local policy, it MAY react further to this error by revoking the
delegation. If the PCC receives a PCUpd message for an LSP object delegation. If the PCC receives a PCUpd message for an LSP object
identified with a PLSP-ID that does not exist on the PCC, it MUST identified with a PLSP-ID that does not exist on the PCC, it MUST
generate a PCErr with error-type 19 (Invalid Operation), error-value generate a PCErr with Error-type=19 (Invalid Operation), error-value
3, (Attempted LSP Update Request for an LSP identified by an unknown 3, (Attempted LSP Update Request for an LSP identified by an unknown
PSP-ID) (see Section 8.5). PSP-ID) (see Section 8.5).
Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt
message) to the PCE, indicating that the LSP's status is 'Up'. If message) to the PCE, indicating that the LSP's status is 'Up'. If
the LSP could not be set up, the PCC MUST send an LSP State Report the LSP could not be set up, the PCC MUST send an LSP State Report
indicating that the LSP is 'Down' and stating the cause of the indicating that the LSP is 'Down' and stating the cause of the
failure. A PCC MAY compress LSP State Reports to only reflect the failure. A PCC MAY compress LSP State Reports to only reflect the
most up to date state, as discussed in the previous section. most up to date state, as discussed in the previous section.
A PCC MUST send each LSP State Report to each stateful PCE that is A PCC MUST send each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
PCErr and PCRpt messages triggered as a result of a PCUpd message PCErr and PCRpt messages triggered as a result of a PCUpd message
MUST include the SRP-ID-number from the PCUpd. This provides MUST include the SRP-ID-number from the PCUpd. This provides
correlation of requests and errors and acknowledgement of state correlation of requests and errors and acknowledgement of state
processing. The PCC MAY compress state when processing PCUpd. In processing. The PCC MAY compress the state when processing PCUpd.
this case, receipt of a higher SRP-ID-number implicitly acknowledges In this case, receipt of a higher SRP-ID-number implicitly
processing all the updates with lower SRP-ID-number for the specific acknowledges processing all the updates with a lower SRP-ID-number
LSP (as per Section 7.2). for the specific LSP (as per Section 7.2).
A PCC MUST NOT send to any PCE a Path Computation Request for a A PCC MUST NOT send to any PCE a path computation request for a
delegated LSP. Should the PCC decide it wants to issue a Path delegated LSP. Should the PCC decide it wants to issue a Path
Computation Request on a delegated LSP, it MUST perform Delegation Computation Request on a delegated LSP, it MUST perform the
Revocation procedure first. Delegation Revocation procedure first.
5.9. LSP Protection 5.9. LSP Protection
LSP protection and interaction with stateful PCE, as well as the LSP protection and interaction with stateful PCE, as well as the
extensions necessary to implement this functionality will be extensions necessary to implement this functionality, will be
discussed in a separate document. discussed in a separate document.
5.10. PCEP Sessions 5.10. PCEP Sessions
A permanent PCEP session MUST be established between a stateful PCE A permanent PCEP session MUST be established between a stateful PCE
and the PCC. In the case of session failure, session reestablishment and the PCC. In the case of session failure, session
MUST be re-attempted per the procedures defined in [RFC5440]. re-establishment MUST be re-attempted per the procedures defined in
[RFC5440].
6. PCEP Messages 6. PCEP Messages
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects. For followed by a variable-length body made of a set of objects. For
each PCEP message type, a set of rules is defined that specify the each PCEP message type, a set of rules is defined that specifies the
set of objects that the message can carry. set of objects that the message can carry.
6.1. The PCRpt Message 6.1. The PCRpt Message
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as a
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is 10. for the PCRpt message is 10.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
skipping to change at page 24, line 36 skipping to change at page 25, line 43
Where: Where:
<path>::= <intended-path> <path>::= <intended-path>
[<actual-attribute-list><actual-path>] [<actual-attribute-list><actual-path>]
<intended-attribute-list> <intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>] <actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>] [<metric-list>]
Where: Where:
<intended-path> is represented by the ERO object defined in <intended-path> is represented by the ERO object defined in
section 7.9 of [RFC5440]. Section 7.9 of [RFC5440].
<actual-attribute-list> consists of the actual computed and <actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> objects signaled values of the <BANDWIDTH> and <metric-lists> objects
defined in [RFC5440]. defined in [RFC5440].
<actual-path> is represented by the RRO object defined in <actual-path> is represented by the RRO object defined in
section 7.10 of [RFC5440]. Section 7.10 of [RFC5440].
<intended-attribute-list> is the attribute-list defined in <intended-attribute-list> is the attribute-list defined in
section 6.5 of [RFC5440] and extended by PCEP extensions. Section 6.5 of [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message
is not in response to a PCupd message, the SRP object MAY be omitted. is not in response to a PCupd message, the SRP object MAY be omitted.
When the PCC does not include the SRP object, the PCE MUST treat this When the PCC does not include the SRP object, the PCE MUST treat this
as an SRP object with an SRP-ID-number equal to the reserved value as an SRP object with an SRP-ID-number equal to the reserved value
0x00000000. The reserved value 0x00000000 indicates that the state 0x00000000. The reserved value 0x00000000 indicates that the state
reported is not as a result of processing a PCUpd message. reported is not a result of processing a PCUpd message.
If the PCRpt message is in response to a PCUpd message, the SRP If the PCRpt message is in response to a PCUpd message, the SRP
object MUST be included and the value of the SRP-ID-number in the SRP object MUST be included and the value of the SRP-ID-number in the SRP
Object MUST be the same as that sent in the PCUpd message that object MUST be the same as that sent in the PCUpd message that
triggered the state that is reported. If the PCC compressed several triggered the state that is reported. If the PCC compressed several
PCUpd messages for the same LSP by only processing the one with the PCUpd messages for the same LSP by only processing the one with the
highest number, then it should use the SRP-ID-number of that request. highest number, then it should use the SRP-ID-number of that request.
No state compression is allowed for state reporting, e.g. PCRpt No state compression is allowed for state reporting, e.g., PCRpt
messages MUST NOT be pruned from the PCC's egress queue even if messages MUST NOT be pruned from the PCC's egress queue even if
subsequent operations on the same LSP have been completed before the subsequent operations on the same LSP have been completed before the
PCRpt message has been sent to the TCP stack. The PCC MUST PCRpt message has been sent to the TCP stack. The PCC MUST
explicitly report state changes (including removal) for paths it explicitly report state changes (including removal) for paths it
manages. manages.
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
in each LSP State Report on the PCRpt message. If the LSP object is in each LSP State Report on the PCRpt message. If the LSP object is
missing, the receiving PCE MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with
type=6 (Mandatory Object missing) and Error-value 8 (LSP object Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object
missing). missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The intended path, represented by the ERO object, is REQUIRED. If The intended path, represented by the ERO object, is REQUIRED. If
the ERO object is missing, the receiving PCE MUST send a PCErr the ERO object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-value message with Error-type=6 (Mandatory Object missing) and Error-value
9 (ERO object missing). The ERO may be empty if the PCE does not 9 (ERO object missing). The ERO may be empty if the PCE does not
have a path for a delegated LSP. have a path for a delegated LSP.
The actual path, represented by the RRO object, SHOULD be included in The actual path, represented by the RRO object, SHOULD be included in
PCRpt by the PCC when the path is up or active, but MAY be omitted if a PCRpt by the PCC when the path is up or active, but it MAY be
the path is down due to a signaling error or another failure. omitted if the path is down due to a signaling error or another
failure.
The intended-attribute-list maps to the attribute-list in Section 6.5 The intended-attribute-list maps to the attribute-list in Section 6.5
of [RFC5440] and is used to convey the requested parameters of the of [RFC5440] and is used to convey the requested parameters of the
LSP path. This is needed in order to support the switch from passive LSP path. This is needed in order to support the switch from passive
to active stateful PCE as described in Section 5.8.2. When included to active stateful PCE as described in Section 5.8.2. When included
as part of the intended-attribute-list, the meaning of the BANDWIDTH as part of the intended-attribute-list, the meaning of the BANDWIDTH
object is the requested bandwidth as intended by the operator. In object is the requested bandwidth as intended by the operator. In
this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly,
to indicate a limiting constraint, the METRIC object SHOULD be to indicate a limiting constraint, the METRIC object SHOULD be
included as part of the intended-attribute-list with the B flag set included as part of the intended-attribute-list with the B flag set
and with a specific metric value. To indicate the optimization and with a specific metric value. To indicate the optimization
metric, the METRIC object SHOULD be included as part of the intended- metric, the METRIC object SHOULD be included as part of the
attribute-list with the B flag unset and the metric value set to intended-attribute-list with the B flag unset and the metric value
zero. Note that the intended-attribute-list is optional and thus may set to zero. Note that the intended-attribute-list is optional and
be omitted. In this case, the PCE MAY use the values in the actual- thus may be omitted. In this case, the PCE MAY use the values in the
attribute-list as the requested parameters for the path. actual-attribute-list as the requested parameters for the path.
The actual-attribute-list consists of the actual computed and The actual-attribute-list consists of the actual computed and
signaled values of the BANDWIDTH and METRIC objects defined in signaled values of the BANDWIDTH and METRIC objects defined in
[RFC5440]. When included as part of the actual-attribute-list, [RFC5440]. When included as part of the actual-attribute-list,
Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and
the C flag SHOULD be set in the METRIC object ([RFC5440]). the C flag SHOULD be set in the METRIC object [RFC5440].
Note that the ordering of intended-path, actual-attribute-list, Note that the ordering of intended-path, actual-attribute-list,
actual-path and intended-attribute-list is chosen to retain actual-path, and intended-attribute-list is chosen to retain
compatibility with implementations of an earlier version of this compatibility with implementations of an earlier version of this
standard. standard.
A PCE may choose to implement a limit on the resources a single PCC A PCE may choose to implement a limit on the resources a single PCC
can occupy. If a PCRpt is received that causes the PCE to exceed can occupy. If a PCRpt is received that causes the PCE to exceed
this limit, the PCE MUST notify the PCC using a PCNtf message with this limit, the PCE MUST notify the PCC using a PCNtf message with
Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Type 4 (Stateful PCE resource limit exceeded) and
Notification Value 1 (Entering resource limit exceeded state) and Notification Value 1 (Entering resource limit exceeded state), and it
MUST terminate the session. MUST terminate the session.
6.2. The PCUpd Message 6.2. The PCUpd Message
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCUpd message is 11. the PCUpd message is 11.
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <intended-path><intended-attribute-list> <path>::= <intended-path><intended-attribute-list>
Where: Where:
<intended-path> is represented by the ERO object defined in <intended-path> is represented by the ERO object defined in
section 7.9 of [RFC5440]. Section 7.9 of [RFC5440].
<intended-attribute-list> is the attribute-list defined in [RFC5440]
and extended by PCEP extensions. <intended-attribute-list> is the attribute-list defined in
[RFC5440] and extended by PCEP extensions.
There are three mandatory objects that MUST be included within each There are three mandatory objects that MUST be included within each
LSP Update Request in the PCUpd message: the SRP Object (see LSP Update Request in the PCUpd message: the SRP object (see
Section 7.2), the LSP object (see Section 7.3) and the ERO object (as Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
defined in [RFC5440], which represents the intended path. If the SRP defined in [RFC5440], which represents the intended path. If the SRP
object is missing, the receiving PCC MUST send a PCErr message with object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
object missing). If the LSP object is missing, the receiving PCC object missing). If the LSP object is missing, the receiving PCC
MUST send a PCErr message with Error-type=6 (Mandatory Object MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=8 (LSP object missing). If the ERO object missing) and Error-value=8 (LSP object missing). If the ERO object
is missing, the receiving PCC MUST send a PCErr message with Error- is missing, the receiving PCC MUST send a PCErr message with
type=6 (Mandatory Object missing) and Error-value=9 (ERO object Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object
missing). missing).
The ERO in the PCUpd may be empty if the PCE cannot find a valid path The ERO in the PCUpd may be empty if the PCE cannot find a valid path
for a delegated LSP. One typical situation resulting in this empty for a delegated LSP. One typical situation resulting in this empty
ERO carried in the PCUpd message is that a PCE can no longer find a ERO carried in the PCUpd message is that a PCE can no longer find a
strict SRLG-disjoint path for a delegated LSP after a link failure. strict SRLG-disjoint path for a delegated LSP after a link failure.
The PCC SHOULD implement a local policy to decide the appropriate The PCC SHOULD implement a local policy to decide the appropriate
action to be taken: either tear down the LSP, or revoke the action to be taken: either tear down the LSP or revoke the delegation
delegation and use a locally computed path, or keep the existing LSP. and use a locally computed path, or keep the existing LSP.
A PCC only acts on an LSP Update Request if permitted by the local A PCC only acts on an LSP Update Request if permitted by the local
policy configured by the network manager. Each LSP Update Request policy configured by the network manager. Each LSP Update Request
that the PCC acts on results in an LSP setup operation. An LSP that the PCC acts on results in an LSP setup operation. An LSP
Update Request MUST contain all LSP parameters that a PCE wishes to Update Request MUST contain all LSP parameters that a PCE wishes to
be set for the LSP. A PCC MAY set missing parameters from locally be set for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Update Request is configured defaults. If the LSP specified in the Update Request is
already up, it will be re-signaled. already up, it will be re-signaled.
The PCC SHOULD minimize the traffic interruption, and MAY use the The PCC SHOULD minimize the traffic interruption and MAY use the
make-before-break procedures described in [RFC3209] in order to make-before-break procedures described in [RFC3209] in order to
achieve this goal. If the make-before-break procedures are used, two achieve this goal. If the make-before-break procedures are used, two
paths will briefly co-exist. The PCC MUST send separate PCRpt paths will briefly coexist. The PCC MUST send separate PCRpt
messages for each, identified by the LSP-IDENTIFIERS TLV. When the messages for each, identified by the LSP-IDENTIFIERS TLV. When the
old path is torn down after the head end switches over the traffic, old path is torn down after the head end switches over the traffic,
this event MUST be reported by sending a PCRpt message with the LSP- this event MUST be reported by sending a PCRpt message with the
IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number LSP-IDENTIFIERS-TLV of the old path and the R bit set. The
that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a SRP-ID-number that the PCC associates with this PCRpt MUST be
make-before-break operation will typically result in at least two 0x00000000. Thus, a make-before-break operation will typically
PCRpt messages, one for the new path and one for the removal of the result in at least two PCRpt messages, one for the new path and one
old path (more messages may be possible if intermediate states are for the removal of the old path (more messages may be possible if
reported). intermediate states are reported).
If the path setup fails due to an RSVP signaling error, the error is If the path setup fails due to an RSVP signaling error, the error is
reported to the PCE. The PCC will not attempt to resignal the path reported to the PCE. The PCC will not attempt to re-signal the path
until it is prompted again by the PCE with a subsequent PCUpd until it is prompted again by the PCE with a subsequent PCUpd
message. message.
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request it processed to indicate the resulting state of the LSP in Request it processed to indicate the resulting state of the LSP in
the network (even if this processing did not result in changing the the network (even if this processing did not result in changing the
state of the LSP). The SRP-ID-number included in the PCRpt MUST state of the LSP). The SRP-ID-number included in the PCRpt MUST
match that in the PCUpd. A PCC MAY respond with multiple LSP State match that in the PCUpd. A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case, Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included for the first message, for the SRP-ID-number MUST be included for the first message; for
subsequent messages the reserved value 0x00000000 SHOULD be used. subsequent messages, the reserved value 0x00000000 SHOULD be used.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests -- for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
If the rate of PCUpd messages sent to a PCC for the same target LSP If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network, exceeds the rate at which the PCC can signal LSPs into the network,
the PCC MAY perform state compression on its ingress queue. The the PCC MAY perform state compression on its ingress queue. The
compression algorithm is based on the fact that each PCUpd request compression algorithm is based on the fact that each PCUpd request
contains the complete LSP state the PCE wishes to be set and works as contains the complete LSP state the PCE wishes to be set and works as
follows: when the PCC starts processing a PCUpd message at the head follows: when the PCC starts processing a PCUpd message at the head
of its ingress queue, it may search the queue forward for more recent of its ingress queue, it may search the queue forward for more recent
PCUpd messages pertaining that particular LSP, prune all but the PCUpd messages pertaining to that particular LSP, prune all but the
latest one from the queue and process only the last one as that latest one from the queue, and process only the last one as that
request contains the most up-to-date desired state for the LSP. The request contains the most up-to-date desired state for the LSP. The
PCC MUST NOT send PCRpt nor PCErr messages for requests which were PCC MUST NOT send PCRpt nor PCErr messages for requests that were
pruned from the queue in this way. This compression step may be pruned from the queue in this way. This compression step may be
performed only while the LSP is not being signaled, e.g. if two PCUpd performed only while the LSP is not being signaled, e.g., if two
arrive for the same LSP in quick succession and the PCC started the PCUpd arrive for the same LSP in quick succession and the PCC started
signaling of the changes relevant to the first PCUpd, then it MUST the signaling of the changes relevant to the first PCUpd, then it
wait until the signaling finishes (and report the new state via a MUST wait until the signaling finishes (and report the new state via
PCRpt) before attempting to apply the changes indicated in the second a PCRpt) before attempting to apply the changes indicated in the
PCUpd. second PCUpd.
Note also that it is up to the PCE to handle inter-LSP dependencies; Note also that it is up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP set-ups is required, the PCE has to for example, if ordering of LSP setups is required, the PCE has to
wait for an LSP State Report for a previous LSP before starting the wait for an LSP State Report for a previous LSP before starting the
update of the next LSP. update of the next LSP.
If the PCUpd cannot be satisfied (for example due to unsupported If the PCUpd cannot be satisfied (for example, due to an unsupported
object or TLV), the PCC MUST respond with a PCErr message indicating object or a TLV), the PCC MUST respond with a PCErr message
the failure (see Section 7.3.3). indicating the failure (see Section 7.3.3).
6.3. The PCErr Message 6.3. The PCErr Message
If the stateful PCE capability has been advertised on the PCEP If the stateful PCE capability has been advertised on the PCEP
session, the PCErr message MAY include the SRP object. If the error session, the PCErr message MAY include the SRP object. If the error
reported is the result of an LSP update request, then the SRP-ID- reported is the result of an LSP Update Request, then the
number MUST be the one from the PCUpd that triggered the error. If SRP-ID-number MUST be the one from the PCUpd that triggered the
the error is unsolicited, the SRP object MAY be omitted. This is error. If the error is unsolicited, the SRP object MAY be omitted.
equivalent to including an SRP object with SRP-ID-number equal to the This is equivalent to including an SRP object with the SRP-ID-number
reserved value 0x00000000. equal to the reserved value 0x00000000.
The format of a PCErr message from [RFC5440] is extended as follows: The format of a PCErr message from [RFC5440] is extended as follows:
<PCErr Message> ::= <Common Header> <PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error> ( <error-obj-list> [<Open>] ) | <error>
[<error-list>] [<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>] <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list> | <stateful-request-id-list>] <error>::=[<request-id-list> | <stateful-request-id-list>]
skipping to change at page 30, line 8 skipping to change at page 31, line 36
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>[<BANDWIDTH>]] [<RRO>[<BANDWIDTH>]]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
6.5. The PCRep Message 6.5. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see A PCE MAY include the LSP object in the PCRep message (see
(Section 7.3) if the stateful PCE capability has been negotiated on a Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was PCEP session between the PCC, and the PCE and the LSP object were
included in the corresponding PCReq message from the PCC. included in the corresponding PCReq message from the PCC.
The definition of the PCRep message from [RFC5440] is extended to The definition of the PCRep message from [RFC5440] is extended to
optionally include the LSP object after the RP object. The encoding optionally include the LSP object after the Request Parameter (RP)
from [RFC5440] will become: object. The encoding from [RFC5440] will become:
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
Where: Where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
[<LSP>] [<LSP>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
[<path-list>] [<path-list>]
7. Object Formats 7. Object Formats
The PCEP objects defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P and I flags of the PCEP
PCEP objects defined in the current document MUST be set to 0 on objects defined in the current document MUST be set to 0 on
transmission and SHOULD be ignored on receipt since the P and I flags transmission and SHOULD be ignored on receipt since they are
are exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines one new optional TLV for use in the OPEN This document defines one new optional TLV for use in the OPEN
Object. object.
7.1.1. Stateful PCE Capability TLV 7.1.1. STATEFUL-PCE-CAPABILITY TLV
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
OPEN Object for stateful PCE capability advertisement. Its format is OPEN object for stateful PCE capability advertisement. Its format is
shown in the following figure: shown in the 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=16 | Length=4 | | Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U| | Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV format Figure 9: STATEFUL-PCE-CAPABILITY TLV Format
The type (16 bits) of the TLV is 16. The length field is 16 bit-long The type (16 bits) of the TLV is 16. The length field is 16 bits
and has a fixed value of 4. long and has a fixed value of 4.
The value comprises a single field - Flags (32 bits): The value comprises a single field -- Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U flag
indicates that the PCC allows modification of LSP parameters; if indicates that the PCC allows modification of LSP parameters; if
set to 1 by a PCE, the U Flag indicates that the PCE is capable of set to 1 by a PCE, the U flag indicates that the PCE is capable of
updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be
advertised by both a PCC and a PCE for PCUpd messages to be advertised by both a PCC and a PCE for PCUpd messages to be
allowed on a PCEP session. allowed on a PCEP session.
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.
A PCEP speaker operating in passive stateful PCE mode advertises the A PCEP speaker operating in passive stateful PCE mode advertises the
stateful PCE capability with the U flag set to 0. A PCEP speaker stateful PCE capability with the U flag set to 0. A PCEP speaker
operating in active stateful PCE mode advertises the stateful PCE operating in active stateful PCE mode advertises the stateful PCE
capability with the U Flag set to 1. capability with the U flag set to 1.
Advertisement of the stateful PCE capability implies support of LSPs Advertisement of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs and that are signaled via RSVP, as well as the objects, TLVs, and
procedures defined in this document. procedures defined in this document.
7.2. SRP Object 7.2. SRP Object
The SRP (Stateful PCE Request Parameters) object MUST be carried The SRP (Stateful PCE Request Parameters) object MUST be carried
within PCUpd messages and MAY be carried within PCRpt and PCErr within PCUpd messages and MAY be carried within PCRpt and PCErr
messages. The SRP object is used to correlate between update messages. The SRP object is used to correlate between update
requests sent by the PCE and the error reports and state reports sent requests sent by the PCE and the error reports and state reports sent
by the PCC. by the PCC.
skipping to change at page 32, line 17 skipping to change at page 33, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The SRP Object format Figure 10: The SRP Object Format
The SRP object body has a variable length and may contain additional The SRP object body has a variable length and may contain additional
TLVs. TLVs.
Flags (32 bits): None defined yet. Flags (32 bits): None defined yet.
SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
current PCEP session uniquely identify the operation that the PCE has current PCEP session uniquely identifies the operation that the PCE
requested the PCC to perform on a given LSP. The SRP-ID-number is has requested the PCC to perform on a given LSP. The SRP-ID-number
incremented each time a new request is sent to the PCC, and may wrap is incremented each time a new request is sent to the PCC, and it may
around. wrap around.
The values 0x00000000 and 0xFFFFFFFF are reserved. The values 0x00000000 and 0xFFFFFFFF are reserved.
Optional TLVs MAY be included within the SRP object body. The Optional TLVs MAY be included within the SRP object body. The
specification of such TLVs is outside the scope of this document. specification of such TLVs is outside the scope of this document.
Every request to update an LSP receives a new SRP-ID-number. This Every request to update an LSP receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an number is unique per PCEP session and is incremented each time an
operation is requested from the PCE. Thus, for a given LSP there may operation is requested from the PCE. Thus, for a given LSP, there
be more than one SRP-ID-number unacknowledged at a given time. The may be more than one SRP-ID-number unacknowledged at a given time.
value of the SRP-ID-number is echoed back by the PCC in PCErr and The value of the SRP-ID-number is echoed back by the PCC in PCErr and
PCRpt messages to allow for correlation between requests made by the PCRpt messages to allow for correlation between requests made by the
PCE and errors or state reports generated by the PCC. If the error PCE and errors or state reports generated by the PCC. If the error
or report were not as a result of a PCE operation (for example in the or report was not a result of a PCE operation (for example, in the
case of a link down event), the reserved value of 0x00000000 is used case of a link down event), the reserved value of 0x00000000 is used
for the SRP-ID-number. The absence of the SRP object is equivalent for the SRP-ID-number. The absence of the SRP object is equivalent
to an SRP object with the reserved value of 0x00000000. An SRP-ID- to an SRP object with the reserved value of 0x00000000. An
number is considered unacknowledged and cannot be reused until a SRP-ID-number is considered unacknowledged and cannot be reused until
PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for
same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number the same LSP. In case of SRP-ID-number wrapping, the last
before the wrapping MUST be explicitly acknowledged, to avoid a SRP-ID-number before the wrapping MUST be explicitly acknowledged, to
situation where SRP-ID-numbers remain unacknowledged after the wrap. avoid a situation where SRP-ID-numbers remain unacknowledged after
the wrap. This means that the PCC may need to issue two PCUpd
This means that the PCC may need to issue two PCUpd messages on messages on detecting a wrap.
detecting a wrap.
7.3. LSP Object 7.3. LSP Object
The LSP object MUST be present within PCRpt and PCUpd messages. The The LSP object MUST be present within PCRpt and PCUpd messages. The
LSP object MAY be carried within PCReq and PCRep messages if the LSP object MAY be carried within PCReq and PCRep messages if the
stateful PCE capability has been negotiated on the session. The LSP stateful PCE capability has been negotiated on the session. The LSP
object contains a set of fields used to specify the target LSP, the object contains a set of fields used to specify the target LSP, the
operation to be performed on the LSP, and LSP Delegation. It also operation to be performed on the LSP, and LSP delegation. It also
contains a flag indicating to a PCE that the LSP state contains a flag indicating to a PCE that the LSP State
synchronization is in progress. This document focuses on LSPs that Synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object are signaled with RSVP; many of the TLVs used with the LSP object
mirror RSVP state. mirror RSVP state.
LSP Object-Class is 32. LSP Object-Class is 32.
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 11: The format of the LSP object body is shown in Figure 11:
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 | Flag | O |A|R|S|D| | PLSP-ID | Flag | O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The LSP Object format Figure 11: The LSP Object Format
PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC
creates a unique PLSP-ID for each LSP that is constant for the creates a unique PLSP-ID for each LSP that is constant for the
lifetime of a PCEP session. The PCC will advertise the same PLSP-ID lifetime of a PCEP session. The PCC will advertise the same PLSP-ID
on all PCEP sessions it maintains at a given times. The mapping of on all PCEP sessions it maintains at a given time. The mapping of
the Symbolic Path Name to PLSP-ID is communicated to the PCE by the symbolic path name to PLSP-ID is communicated to the PCE by
sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All
subsequent PCEP messages then address the LSP by the PLSP-ID. The subsequent PCEP messages then address the LSP by the PLSP-ID. The
values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a
value that is constant for the lifetime of the PCEP session, during value that is constant for the lifetime of the PCEP session, during
which time for an RSVP-signaled LSP there might be a different RSVP which time for an RSVP-signaled LSP there might be different RSVP
identifiers (LSP-id, tunnel-id) allocated to it. identifiers (LSP-id, tunnel-id) allocated to it.
Flags (12 bits), starting from the least significant bit: Flags (12 bits), starting from the least significant bit:
D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 D (Delegate - 1 bit): On a PCRpt message, the D flag set to 1
indicates that the PCC is delegating the LSP to the PCE. On a indicates that the PCC is delegating the LSP to the PCE. On a
PCUpd message, the D flag set to 1 indicates that the PCE is PCUpd message, the D flag set to 1 indicates that the PCE is
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation -- the first PCRpt with the D flag
set to 0 revokes the delegation. To keep the delegation, the PCE set to 0 revokes the delegation. To keep the delegation, the PCE
must set the D flag to 1 on each PCUpd message for the duration of must set the D flag to 1 on each PCUpd message for the duration of
the delegation - the first PCUpd with the D flag set to 0 returns the delegation -- the first PCUpd with the D flag set to 0 returns
the delegation. the delegation.
S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent S (SYNC - 1 bit): The S flag MUST be set to 1 on each PCRpt sent
from a PCC during State Synchronization. The S Flag MUST be set from a PCC during State Synchronization. The S flag MUST be set
to 0 in other messages sent from the PCC. When sending a PCUpd to 0 in other messages sent from the PCC. When sending a PCUpd
message, the PCE MUST set the S Flag to 0. message, the PCE MUST set the S flag to 0.
R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the R (Remove - 1 bit): On PCRpt messages, the R flag indicates that the
LSP has been removed from the PCC and the PCE SHOULD remove all LSP has been removed from the PCC and the PCE SHOULD remove all
state from its database. Upon receiving an LSP State Report with state from its database. Upon receiving an LSP State Report with
the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD the R flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
remove all state for the path identified by the LSP-IDENTIFIERS remove all state for the path identified by the LSP-IDENTIFIERS
TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is
used, the PCE SHOULD remove all state for the PLSP-ID from its used, the PCE SHOULD remove all state for the PLSP-ID from its
database. When sending a PCUpd message, the PCE MUST set the R database. When sending a PCUpd message, the PCE MUST set the R
Flag to 0. flag to 0.
A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates A (Administrative - 1 bit): On PCRpt messages, the A flag indicates
the PCC's target operational status for this LSP. On PCUpd the PCC's target operational status for this LSP. On PCUpd
messages, the A Flag indicates the LSP status that the PCE desires messages, the A flag indicates the LSP status that the PCE desires
for this LSP. In both cases, a value of '1' means that the for this LSP. In both cases, a value of '1' means that the
desired operational state is active, and a value of '0' means that desired operational state is active, and a value of '0' means that
the desired operational state is inactive. A PCC ignores the A the desired operational state is inactive. A PCC ignores the A
flag on a PCUpd message unless the operator's policy allows the flag on a PCUpd message unless the operator's policy allows the
PCE to control the corresponding LSP's administrative state. PCE to control the corresponding LSP's administrative state.
O(Operational - 3 bits): On PCRpt messages, the O Field represents O (Operational - 3 bits): On PCRpt messages, the O field represents
the operational status of the LSP. the operational status of the LSP.
The following values are defined: The following values are defined:
0 - DOWN: not active. 0 - DOWN: not active.
1 - UP: signalled. 1 - UP: signaled.
2 - ACTIVE: up and carrying traffic. 2 - ACTIVE: up and carrying traffic.
3 - GOING-DOWN: LSP is being torn down, resources are being 3 - GOING-DOWN: LSP is being torn down, and resources are being
released. released.
4 - GOING-UP: LSP is being signalled. 4 - GOING-UP: LSP is being signaled.
5-7 - Reserved: these values are reserved for future use. 5-7 - Reserved: these values are reserved for future use.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are reserved for future uses. They MUST be set to 0
transmission and MUST be ignored on receipt. When sending a PCUpd on transmission and MUST be ignored on receipt. When sending a PCUpd
message, the PCE MUST set the O Field to 0. message, the PCE MUST set the O field to 0.
TLVs that may be included in the LSP Object are described in the TLVs that may be included in the LSP object are described in the
following sections. Other optional TLVs, that are not defined in following sections. Other optional TLVs, that are not defined in
this document, MAY also be included within the LSP Object body. this document, MAY also be included within the LSP object body.
7.3.1. LSP-IDENTIFIERS TLVs 7.3.1. LSP-IDENTIFIERS TLVs
The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt
messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will
generate an error with error-type 6 (mandatory object missing) and generate an error with Error-type=6 (Mandatory Object missing) and
error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd
messages for RSVP-signaled LSPs. The special value of all zeros for messages for RSVP-signaled LSPs. The special value of all zeros for
this TLV is used to refer to all paths pertaining to a particular this TLV is used to refer to all paths pertaining to a particular
PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one
for IPv6. for IPv6.
It is the responsibility of the PCC to send to the PCE the It is the responsibility of the PCC to send to the PCE the
identifiers for each RSVP incarnation of the tunnel. For example, in identifiers for each RSVP incarnation of the tunnel. For example, in
a make-before-break scenario, the PCC MUST send a separate PCRpt for a make-before-break scenario, the PCC MUST send a separate PCRpt for
the old and for the reoptimized paths, and explicitly report removal the old and reoptimized paths and explicitly report removal of any of
of any of these paths using the R bit in the LSP object. these paths using the R bit in the LSP object.
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
figure: 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=18 | Length=16 | | Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address | | IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPV4-LSP-IDENTIFIERS TLV format Figure 12: IPV4-LSP-IDENTIFIERS TLV Format
The type (16 bits) of the TLV is 18. The length field is 16 bit-long The type (16 bits) of the TLV is 18. The length field is 16 bits
and has a fixed value of 16. The value contains the following long and has a fixed value of 16. The value contains the following
fields: fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object. A value of 0 MUST be used if the LSP is not yet signaled. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.1 for the identifier defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Session Object. LSP_TUNNEL_IPv4 Session Object.
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4
address, as defined in [RFC3209], Section 4.6.1.1 for the address, as defined in [RFC3209], Section 4.6.1.1, for the
LSP_TUNNEL_IPv4 Sender Template Object. LSP_TUNNEL_IPv4 Sender Template Object.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following
figure: 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=19 | Length=52 | | Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel sender address | | IPv6 Tunnel Sender Address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Extended Tunnel ID | | Extended Tunnel ID |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel endpoint address | | IPv6 Tunnel Endpoint Address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPV6-LSP-IDENTIFIERS TLV format Figure 13: IPV6-LSP-IDENTIFIERS TLV Format
The type (16 bits) of the TLV is 19. The length field is 16 bit-long The type (16 bits) of the TLV is 19. The length field is 16 bits
and has a fixed value of 52. The value contains the following long and has a fixed value of 52. The value contains the following
fields: fields:
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, IPv6 Tunnel Sender Address: contains the sender node's IPv6 address,
as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
Object. A value of 0 MUST be used if the LSP is not yet signaled. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.2 for the identifier defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6
address, as defined in [RFC3209], Section 4.6.1.2 for the address, as defined in [RFC3209], Section 4.6.1.2, for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
The Tunnel ID remains constant over the life time of a tunnel. The Tunnel ID remains constant over the lifetime of a tunnel.
7.3.2. Symbolic Path Name TLV 7.3.2. Symbolic Path Name TLV
Each LSP MUST have a symbolic path name that is unique in the PCC. Each LSP MUST have a symbolic path name that is unique in the PCC.
The symbolic path name is a human-readable string that identifies an The symbolic path name is a human-readable string that identifies an
LSP in the network. The symbolic path name MUST remain constant LSP in the network. The symbolic path name MUST remain constant
throughout an LSP's lifetime, which may span across multiple throughout an LSP's lifetime, which may span across multiple
consecutive PCEP sessions and/or PCC restarts. The symbolic path consecutive PCEP sessions and/or PCC restarts. The symbolic path
name MAY be specified by an operator in a PCC's configuration. If name MAY be specified by an operator in a PCC's configuration. If
the operator does not specify a unique symbolic name for an LSP, then the operator does not specify a unique symbolic name for an LSP, then
skipping to change at page 38, line 40 skipping to change at page 39, line 47
session instances. session instances.
The other protocol identifiers for the LSP cannot reliably be used to The other protocol identifiers for the LSP cannot reliably be used to
identify the LSP across multiple PCEP sessions, for the following identify the LSP across multiple PCEP sessions, for the following
reasons. reasons.
o The PLSP-ID is unique only within the scope of a single PCEP o The PLSP-ID is unique only within the scope of a single PCEP
session. session.
o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs
that are signalled with RSVP-TE, and may change during the that are signaled with RSVP-TE, and it may change during the
lifetime of the LSP. lifetime of the LSP.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
LSP State Report (PCRpt) message when during a given PCEP session an LSP State Report (PCRpt) message when during a given PCEP session an
LSP is first reported to a PCE. A PCC sends to a PCE the first LSP LSP is first reported to a PCE. A PCC sends to a PCE the first LSP
State Report either during State Synchronization, or when a new LSP State Report either during State Synchronization or when a new LSP is
is configured at the PCC. configured at the PCC.
The initial PCRpt creates a binding between the symbolic path name The initial PCRpt creates a binding between the symbolic path name
and the PLSP-ID for the LSP which lasts for the duration of the PCEP and the PLSP-ID for the LSP that lasts for the duration of the PCEP
session. The PCC MAY omit the symbolic path name from subsequent LSP session. The PCC MAY omit the symbolic path name from subsequent LSP
State Reports for that LSP on that PCEP session, and just use the State Reports for that LSP on that PCEP session, and just use the
PLSP-ID. PLSP-ID.
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
figure: 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=17 | Length (variable) | | Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV format Figure 14: SYMBOLIC-PATH-NAME TLV Format
Type (16 bits): The type is 17. Type (16 bits): the type is 17.
Length (16 bits): indicates the total length of the TLV in octets and Length (16 bits): indicates the total length of the TLV in octets and
MUST be greater than 0. The TLV MUST be zero-padded so that the TLV MUST be greater than 0. The TLV MUST be zero-padded so that the TLV
is 4-octet aligned. is 4-octet aligned.
Symbolic Path Name (variable): symbolic name for the LSP, unique in Symbolic Path Name (variable): symbolic name for the LSP, unique in
the PCC. It SHOULD be a string of printable ASCII characters, the PCC. It SHOULD be a string of printable ASCII characters,
without a NULL terminator. without a NULL terminator.
7.3.3. LSP Error Code TLV 7.3.3. LSP Error Code TLV
The LSP Error code TLV is an optional TLV for use in the LSP object The LSP Error Code TLV is an optional TLV for use in the LSP object
to convey error information. When an LSP Update Request fails, an to convey error information. When an LSP Update Request fails, an
LSP State Report MUST be sent to report the current state of the LSP, LSP State Report MUST be sent to report the current state of the LSP,
and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason
the failure. Similarly, when a PCRpt is sent as a result of an LSP for the failure. Similarly, when a PCRpt is sent as a result of an
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD LSP transitioning to non-operational state, the LSP-ERROR-CODE TLV
be included to indicate the reason for the transition. SHOULD be included to indicate the reason for the transition.
The format of the LSP-ERROR-CODE TLV is shown in the following The format of the LSP-ERROR-CODE TLV is shown in the following
figure: 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=20 | Length=4 | | Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV format Figure 15: LSP-ERROR-CODE TLV Format
The type (16 bits) of the TLV is 20. The length field is 16 bit-long The type (16 bits) of the TLV is 20. The length field is 16 bits
and has a fixed value of 4. The value contains an error code that long and has a fixed value of 4. The value contains an error code
indicates the cause of the failure. that indicates the cause of the failure.
The following LSP Error Codes are currently defined: The following LSP Error Codes are currently defined:
Value Meaning Value Description
----- -------------------------------------
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP Update Requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
7.3.4. RSVP Error Spec TLV 7.3.4. RSVP Error Spec TLV
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
to carry RSVP error information. It includes the RSVP ERROR_SPEC or to carry RSVP error information. It includes the RSVP ERROR_SPEC or
USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned
to the PCC from a downstream node. If the set up of an LSP fails at to the PCC from a downstream node. If the setup of an LSP fails at a
a downstream node which returned an ERROR_SPEC to the PCC, the PCC downstream node that returned an ERROR_SPEC to the PCC, the PCC
SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object.
The format of the RSVP-ERROR-SPEC TLV is shown in the following The format of the RSVP-ERROR-SPEC TLV is shown in the following
figure: 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=21 | Length (variable) | | Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object + + RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV format Figure 16: RSVP-ERROR-SPEC TLV Format
Type (16 bits): The type is 21. Type (16 bits): the type is 21.
Length (16 bits): indicates the total length of the TLV in octets. Length (16 bits): indicates the total length of the TLV in octets.
The TLV MUST be zero-padded so that the TLV is 4-octet aligned. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
Object: as specified in [RFC2205] and [RFC5284], including the object object, as specified in [RFC2205] and [RFC5284], including the object
header. header.
8. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the The code points described below have been allocated for the protocol
protocol elements defined in this document. elements defined in this document.
8.1. PCE Capabilities in IGP Advertisements 8.1. PCE Capabilities in IGP Advertisements
IANA is requested to confirm the early allocation of the following The following bits have been registered in the "Path Computation
bits in the OSPF Parameters "PCE Capability Flags" registry, and to Element (PCE) Capability Flags" subregistry of the "Open Shortest
update the reference in the registry to point to this document, when Path First (OSPF) Parameters" registry:
it is an RFC:
Bit Meaning Reference Bit Description Reference
11 Active Stateful PCE This document --- ------------------------------- -------------
capability 11 Active stateful PCE capability This document
12 Passive Stateful PCE This document 12 Passive stateful PCE capability This document
capability
8.2. PCEP Messages 8.2. PCEP Messages
IANA is requested to confirm the early allocation of the following The following message types have been allocated within the "PCEP
message types within the "PCEP Messages" sub-registry of the PCEP Messages" subregistry of the "Path Computation Element Protocol
Numbers registry, and to update the reference in the registry to (PCEP) Numbers" registry:
point to this document, when it is an RFC:
Value Meaning Reference Value Description Reference
10 Report This document ----- ------------ -------------
11 Update This document 10 Report This document
11 Update This document
8.3. PCEP Objects 8.3. PCEP Objects
IANA is requested to confirm the early allocation of the following The following object-class values and object types have been
object-class values and object types within the "PCEP Objects" sub- allocated within the "PCEP Objects" subregistry of the "Path
registry of the PCEP Numbers registry, and to update the reference in Computation Element Protocol (PCEP) Numbers" registry:
the registry to point to this document, when it is an RFC:.
Object-Class Value Name Reference Object-Class Value Name Reference
------------------ ---------------- -------------
32 LSP This document
Object-Type
0: Reserved
1: LSP
32 LSP This document 33 SRP This document
Object-Type Object-Type
1 0: Reserved
33 SRP This document 1: SRP
Object-Type
1
8.4. LSP Object 8.4. LSP Object
This document requests that a new sub-registry, named "LSP Object A new subregistry, named "LSP Object Flag Field", has been created
Flag Field", is created within the "Path Computation Element Protocol within the "Path Computation Element Protocol (PCEP) Numbers"
(PCEP) Numbers" registry to manage the Flag field of the LSP object. registry to manage the Flag field of the LSP object. New values are
New values are to be assigned by Standards Action [RFC5226]. Each assigned by Standards Action [RFC8126]. Each bit should be tracked
bit should be tracked with the following qualities: with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
--- -------------------- -------------
0-4 Reserved This document 0-4 Unassigned This document
5-7 Operational (3 bits) This document 5-7 Operational (3 bits) This document
8 Administrative This document 8 Administrative This document
9 Remove This document 9 Remove This document
10 SYNC This document 10 SYNC This document
11 Delegate This document 11 Delegate This document
8.5. PCEP-Error Object 8.5. PCEP-Error Object
IANA is requested to confirm the early allocation of the following The following error types and error values have been registered
Error Types and Error Values within the "PCEP-ERROR Object Error within the "PCEP-ERROR Object Error Types and Values" subregistry of
Types and Values" sub-registry of the PCEP Numbers registry, and to the "Path Computation Element Protocol (PCEP) Numbers" registry:
update the reference in the registry to point to this document, when
it is an RFC:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing ---------- -------------------------------------------------------
6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value
Error-value=9: ERO Object missing 8: LSP object missing
Error-value=10: SRP Object missing 9: ERO object missing
Error-value=11: LSP-IDENTIFIERS TLV missing 10: SRP object missing
19 Invalid Operation 11: LSP-IDENTIFIERS TLV missing
Error-value=1: Attempted LSP Update Request for a non- 19 Invalid Operation
delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that
identifies the LSP.
Error-value=2: Attempted LSP Update Request if the
stateful PCE capability was not
advertised.
Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID.
Error-value=5: Attempted LSP State Report if stateful
PCE capability was not advertised.
20 LSP State synchronization error.
Error-value=1: A PCE indicates to a PCC that it can Error-value
not process (an otherwise valid) LSP 1: Attempted LSP Update Request for a non-delegated
State Report. The PCEP-ERROR Object is LSP. The PCEP-ERROR object is followed by the LSP
followed by the LSP Object that object that identifies the LSP.
identifies the LSP. 2: Attempted LSP Update Request if the stateful PCE
Error-value=5: A PCC indicates to a PCE that it can capability was not advertised.
not complete the state synchronization, 3: Attempted LSP Update Request for an LSP identified
by an unknown PLSP-ID.
5: Attempted LSP State Report if stateful PCE
capability was not advertised.
20 LSP State Synchronization Error
Error-value
1: A PCE indicates to a PCC that it cannot process (an
otherwise valid) LSP State Report. The PCEP-ERROR
object is followed by the LSP object that
identifies the LSP.
5: A PCC indicates to a PCE that it cannot complete
the State Synchronization.
8.6. Notification Object 8.6. Notification Object
IANA is requested to confirm the early allocation of the following The following Notification Types and Notification Values have been
Notification Types and Notification Values within the "Notification allocated within the "Notification Object" subregistry of the "Path
Object" sub-registry of the PCEP Numbers registry, and to update the Computation Element Protocol (PCEP) Numbers" registry:
reference in the registry to point to this document, when it is an
RFC:
Notification-Type Meaning Notification-Type Name
4 Stateful PCE resource limit exceeded 4 Stateful PCE resource limit exceeded
Notification-value=1: Entering resource limit Notification-value
exceeded state 1: Entering resource limit exceeded state
2: Deprecated
Note to IANA: the early allocation included an additional Note that the early allocation included an additional Notification
Notification value 2 for "Exiting resource limit exceeded state". Value 2 for "Exiting resource limit exceeded state". This
This Notification value is no longer required. Notification Value is no longer required and has been marked as
"Deprecated".
8.7. PCEP TLV Type Indicators 8.7. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following The following TLV Type Indicator values have been registered within
TLV Type Indicator values within the "PCEP TLV Type Indicators" sub- the "PCEP TLV Type Indicators" subregistry of the "Path Computation
registry of the PCEP Numbers registry, and to update the reference in Element Protocol (PCEP) Numbers" registry:
the registry to point to this document, when it is an RFC:
Value Meaning Reference Value Description Reference
----- ----------------------- -------------
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document 18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document 20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
8.8. STATEFUL-PCE-CAPABILITY TLV 8.8. STATEFUL-PCE-CAPABILITY TLV
This document requests that a new sub-registry, named "STATEFUL-PCE- A new subregistry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field",
CAPABILITY TLV Flag Field", is created within the "Path Computation has been created within the "Path Computation Element Protocol (PCEP)
Element Protocol (PCEP) Numbers" registry to manage the Flag field in Numbers" registry to manage the Flag field in the STATEFUL-PCE-
the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). CAPABILITY TLV of the PCEP OPEN object (class = 1). New values are
New values are to be assigned by Standards Action [RFC5226]. Each assigned by Standards Action [RFC8126]. Each bit should be tracked
bit should be tracked with the following qualities: with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Value Description Reference
----- --------------------- -------------
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.9. LSP-ERROR-CODE TLV 8.9. LSP-ERROR-CODE TLV
This document requests that a new sub-registry, named "LSP-ERROR-CODE A new subregistry, named "LSP-ERROR-CODE TLV Error Code Field", has
TLV Error Code Field", is created within the "Path Computation been created within the "Path Computation Element Protocol (PCEP)
Element Protocol (PCEP) Numbers" registry to manage the LSP Error Numbers" registry to manage the LSP Error Code field of the LSP-
code field of the LSP-ERROR-CODE TLV. This field specifies the ERROR-CODE TLV. This field specifies the reason for failure to
reason for failure to update the LSP. update the LSP.
New values are to be assigned by Standards Action [RFC5226]. Each New values are assigned by Standards Action [RFC8126]. Each value
value should be tracked with the following qualities: value, should be tracked with the following qualities: value, meaning, and
description and defining RFC. The following values are defined in defining RFC. The following values are defined in this document:
this document:
Value Meaning Value Meaning
--- -------------------------------------
0 Reserved
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP Update Requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
9. Manageability Considerations 9. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440] All manageability requirements and considerations listed in [RFC5440]
apply to PCEP extensions defined in this document. In addition, apply to the PCEP extensions defined in this document. In addition,
requirements and considerations listed in this section apply. requirements and considerations listed in this section apply.
9.1. Control Function and Policy 9.1. Control Function and Policy
In addition to configuring specific PCEP session parameters, as In addition to configuring specific PCEP session parameters, as
specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
allow configuring the stateful PCEP capability and the LSP Update allow configuring the stateful PCEP capability and the LSP Update
capability. A PCC implementation SHOULD allow the operator to capability. A PCC implementation SHOULD allow the operator to
specify multiple candidate PCEs for and a delegation preference for specify multiple candidate PCEs for and a delegation preference for
each candidate PCE. A PCC SHOULD allow the operator to specify an each candidate PCE. A PCC SHOULD allow the operator to specify an
LSP delegation policy where LSPs are delegated to the most-preferred LSP delegation policy where LSPs are delegated to the most-preferred
online PCE. A PCC MAY allow the operator to specify different LSP online PCE. A PCC MAY allow the operator to specify different LSP
delegation policies. delegation policies.
A PCC implementation which allows concurrent connections to multiple A PCC implementation that allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and it MUST NOT advertise LSP existence and state to a PCE if domains, and it MUST NOT advertise LSP existence and state to a PCE
the LSP is delegated to a PCE in a different group. if the LSP is delegated to a PCE in a different group.
A PCC implementation SHOULD allow the operator to specify whether the A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically controlled by any PCE (for example, LSPs that are statically
configured at the PCC). configured at the PCC).
A PCC implementation SHOULD allow the operator to specify both the A PCC implementation SHOULD allow the operator to specify both the
Redelegation Timeout Interval and the State Timeout Interval. The Redelegation Timeout Interval and the State Timeout Interval. The
default value of the Redelegation Timeout Interval SHOULD be set to default value of the Redelegation Timeout Interval SHOULD be set to
30 seconds. An operator MAY also configure a policy that will 30 seconds. An operator MAY also configure a policy that will
skipping to change at page 46, line 22 skipping to change at page 48, line 48
setting it to zero when the PCC has an established session to a setting it to zero when the PCC has an established session to a
backup PCE. The default value for the State Timeout Interval SHOULD backup PCE. The default value for the State Timeout Interval SHOULD
be set to 60 seconds. be set to 60 seconds.
After the expiration of the State Timeout Interval, the LSP reverts After the expiration of the State Timeout Interval, the LSP reverts
to operator-defined default parameters. A PCC implementation MUST to operator-defined default parameters. A PCC implementation MUST
allow the operator to specify the default LSP parameters. To achieve allow the operator to specify the default LSP parameters. To achieve
a behavior where the LSP retains the parameters set by the PCE until a behavior where the LSP retains the parameters set by the PCE until
such time that the PCC makes a change to them, a State Timeout such time that the PCC makes a change to them, a State Timeout
Interval of infinity SHOULD be used. Any changes to LSP parameters Interval of infinity SHOULD be used. Any changes to LSP parameters
SHOULD be done in make-before-break fashion. SHOULD be done in a make-before-break fashion.
LSP Delegation is controlled by operator-defined policies on a PCC. LSP delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually - different LSPs may be delegated to LSPs are delegated individually -- different LSPs may be delegated to
different PCEs. An LSP is delegated to at most one PCE at any given different PCEs. An LSP is delegated to at most one PCE at any given
point in time. A PCC implementation SHOULD support the delegation point in time. A PCC implementation SHOULD support the delegation
policy, when all PCC's LSPs are delegated to a single PCE at any policy, when all PCC's LSPs are delegated to a single PCE at any
given time. Conversely, the policy revoking the delegation for all given time. Conversely, the policy revoking the delegation for all
PCC's LSPs SHOULD also be supported. PCC's LSPs SHOULD also be supported.
A PCC implementation SHOULD allow the operator to specify delegation A PCC implementation SHOULD allow the operator to specify delegation
priority for PCEs. This effectively defines the primary PCE and one priority for PCEs. This effectively defines the primary PCE and one
or more backup PCEs to which primary PCE's LSPs can be delegated when or more backup PCEs to which a primary PCE's LSPs can be delegated
the primary PCE fails. when the primary PCE fails.
Policies defined for stateful PCEs and PCCs should eventually fit in Policies defined for stateful PCEs and PCCs should eventually fit in
the Policy-Enabled Path Computation Framework defined in [RFC5394], the policy-enabled path computation framework defined in [RFC5394],
and the framework should be extended to support Stateful PCEs. and the framework should be extended to support stateful PCEs.
9.2. Information and Data Models 9.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include The PCEP YANG module [PCEP-YANG] should include:
o advertised stateful capabilities and synchronization status per o advertised stateful capabilities and synchronization status per
PCEP session PCEP session.
o the delegation status of each configured LSP. o the delegation status of each configured LSP.
The PCEP MIB [RFC7420] could also be updated to include this The PCEP MIB [RFC7420] could also be updated to include this
information. information.
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
PCEP extensions defined in this document do not require any new PCEP extensions defined in this document do not require any new
mechanisms beyond those already defined in [RFC5440], Section 8.3. mechanisms beyond those already defined in [RFC5440], Section 8.3.
9.4. Verifying Correct Operation 9.4. Verifying Correct Operation
Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP
extensions defined in this document. In addition to monitoring extensions defined in this document. In addition to monitoring
parameters defined in [RFC5440], a stateful PCC-side PCEP parameters defined in [RFC5440], a stateful PCC-side PCEP
implementation SHOULD provide the following parameters: implementation SHOULD provide the following parameters:
o Total number of LSP updates o Total number of LSP Updates
o Number of successful LSP updates o Number of successful LSP Updates
o Number of dropped LSP updates o Number of dropped LSP Updates
o Number of LSP updates where LSP setup failed o Number of LSP Updates where LSP setup failed
A PCC implementation SHOULD provide a command to show for each LSP A PCC implementation SHOULD provide a command to show for each LSP
whether it is delegated, and if so, to which PCE. whether it is delegated, and if so, to which PCE.
A PCC implementation SHOULD allow the operator to manually revoke LSP A PCC implementation SHOULD allow the operator to manually revoke LSP
delegation. delegation.
9.5. Requirements on Other Protocols and Functional Components 9.5. Requirements on Other Protocols and Functional Components
PCEP extensions defined in this document do not put new requirements PCEP extensions defined in this document do not put new requirements
skipping to change at page 48, line 12 skipping to change at page 50, line 35
LSP Updates to the same LSP to avoid signaling overload discussed in LSP Updates to the same LSP to avoid signaling overload discussed in
Section 10.3. Section 10.3.
10. Security Considerations 10. Security Considerations
10.1. Vulnerability 10.1. Vulnerability
This document defines extensions to PCEP to enable stateful PCEs. This document defines extensions to PCEP to enable stateful PCEs.
The nature of these extensions and the delegation of path control to The nature of these extensions and the delegation of path control to
PCEs results in more information being available for a hypothetical PCEs results in more information being available for a hypothetical
adversary and a number of additional attack surfaces which must be adversary and a number of additional attack surfaces that must be
protected. protected.
The security provisions described in [RFC5440] remain applicable to The security provisions described in [RFC5440] remain applicable to
these extensions. However, because the protocol modifications these extensions. However, because the protocol modifications
outlined in this document allow the PCE to control path computation outlined in this document allow the PCE to control path computation
timing and sequence, the PCE defense mechanisms described in timing and sequence, the PCE defense mechanisms described in
[RFC5440] section 7.2 are also now applicable to PCC security. [RFC5440], Section 7.2 are also now applicable to PCC security.
As a general precaution, it is RECOMMENDED that these PCEP extensions As a general precaution, it is RECOMMENDED that these PCEP extensions
only be activated on authenticated and encrypted sessions across PCEs only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority, using and PCCs belonging to the same administrative authority, using
Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the Transport Layer Security (TLS) [PCEPS], as per the recommendations
recommendations and best current practices in [RFC7525]. and best current practices in [RFC7525].
The following sections identify specific security concerns that may The following sections identify specific security concerns that may
result from the PCEP extensions outlined in this document along with result from the PCEP extensions outlined in this document along with
recommended mechanisms to protect PCEP infrastructure against related recommended mechanisms to protect PCEP infrastructure against related
attacks. attacks.
10.2. LSP State Snooping 10.2. LSP State Snooping
The stateful nature of this extension explicitly requires LSP status The stateful nature of this extension explicitly requires LSP status
updates to be sent from PCC to PCE. While this gives the PCE the updates to be sent from PCC to PCE. While this gives the PCE the
ability to provide more optimal computations to the PCC, it also ability to provide more optimal computations to the PCC, it also
provides an adversary with the opportunity to eavesdrop on decisions provides an adversary with the opportunity to eavesdrop on decisions
made by network systems external to PCE. This is especially true if made by network systems external to PCE. This is especially true if
the PCC delegates LSPs to multiple PCEs simultaneously. the PCC delegates LSPs to multiple PCEs simultaneously.
Adversaries may gain access to this information by eavesdropping on Adversaries may gain access to this information by eavesdropping on
unsecured PCEP sessions, and might then use this information in unsecured PCEP sessions and might then use this information in
various ways to target or optimize attacks on network infrastructure. various ways to target or optimize attacks on network infrastructure,
For example by flexibly countering anti-DDoS measures being taken to for example, by flexibly countering anti-DDoS measures being taken to
protect the network, or by determining choke points in the network protect the network or by determining choke points in the network
where the greatest harm might be caused. where the greatest harm might be caused.
PCC implementations which allow concurrent connections to multiple PCC implementations that allow concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and they MUST NOT advertise LSP existence and state to a PCE domains, and they MUST NOT advertise LSP existence and state to a PCE
if the LSP is delegated to a PCE in a different group. if the LSP is delegated to a PCE in a different group.
10.3. Malicious PCE 10.3. Malicious PCE
The LSP delegation mechanism described in this document allows a PCC The LSP delegation mechanism described in this document allows a PCC
to grant effective control of an LSP to the PCE for the duration of a to grant effective control of an LSP to the PCE for the duration of a
PCEP session. While this enables PCE control of the timing and PCEP session. While this enables PCE control of the timing and
sequence of path computations within and across PCEP sessions, it sequence of path computations within and across PCEP sessions, it
also introduces a new attack vector: an attacker may flood the PCC also introduces a new attack vector: an attacker may flood the PCC
with PCUpd messages at a rate which exceeds either the PCC's ability with PCUpd messages at a rate that exceeds either the PCC's ability
to process them or the network's ability to signal the changes, to process them or the network's ability to signal the changes, by
either by spoofing messages or by compromising the PCE itself. either spoofing messages or compromising the PCE itself.
A PCC is free to revoke an LSP delegation at any time without needing A PCC is free to revoke an LSP delegation at any time without needing
any justification. A defending PCC can do this by enqueueing the any justification. A defending PCC can do this by enqueueing the
appropriate PCRpt message. As soon as that message is enqueued in appropriate PCRpt message. As soon as that message is enqueued in
the session, the PCC is free to drop any incoming PCUpd messages the session, the PCC is free to drop any incoming PCUpd messages
without additional processing. without additional processing.
10.4. Malicious PCC 10.4. Malicious PCC
A stateful session also results in an increased attack surface by A stateful session also results in an increased attack surface by
placing a requirement for the PCE to keep an LSP state replica for placing a requirement for the PCE to keep an LSP state replica for
each PCC. It is RECOMMENDED that PCE implementations provide a limit each PCC. It is RECOMMENDED that PCE implementations provide a limit
on resources a single PCC can occupy. A PCE implementing such a on resources a single PCC can occupy. A PCE implementing such a
limit MUST send a PCNtf message with notification-type 4 (Stateful limit MUST send a PCNtf message with notification-type 4 (Stateful
PCE resource limit exceeded) and notification-value 1 (Entering PCE resource limit exceeded) and notification-value 1 (Entering
resource limit exceeded state) upon receiving an LSP state report resource limit exceeded state) upon receiving an LSP State Report
causing it to exceed this threshold. causing it to exceed this threshold.
Delegation of LSPs can create further strain on PCE resources and a Delegation of LSPs can create further strain on PCE resources and a
PCE implementation MAY preemptively give back delegations if it finds PCE implementation MAY preemptively give back delegations if it finds
itself lacking the resources needed to effectively manage the itself lacking the resources needed to effectively manage the
delegation. Since the delegation state is ultimately controlled by delegation. Since the delegation state is ultimately controlled by
the PCC, PCE implementations SHOULD provide throttling mechanisms to the PCC, PCE implementations SHOULD provide throttling mechanisms to
prevent strain created by flaps of either a PCEP session or an LSP prevent strain created by flaps of either a PCEP session or an LSP
delegation. delegation.
11. Contributing Authors 11. References
Xian Zhang
Huawei Technology
F3-5-B R&D Center
Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
EMail: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.dhody@huawei.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: msiva@cisco.com
12. Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga,
Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky,
Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui,
Stephane Litkowski and Olivier Dugeon for helpful comments and
discussions.
13. References
13.1. Normative References 11.1. Normative References
[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>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
January 2008, <http://www.rfc-editor.org/info/rfc5088>. January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <http://www.rfc-editor.org/info/rfc5089>. January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
RFC 5284, DOI 10.17487/RFC5284, August 2008, RFC 5284, DOI 10.17487/RFC5284, August 2008,
<http://www.rfc-editor.org/info/rfc5284>. <https://www.rfc-editor.org/info/rfc5284>.
[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>. <https://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, <https://www.rfc-editor.org/info/rfc5511>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<http://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
13.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-pce-gmpls-pcep-extensions] 11.2. Informative References
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015.
[I-D.ietf-pce-pce-initiated-lsp] [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global
Information Infrastructure Symposium,
DOI 10.1109/GIIS.2007.4404195, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "A practical
algorithm for balancing the max-min fairness and
throughput objectives in traffic engineering", INFOCOM,
2012 Proceedings IEEE, pp. 846-854,
DOI 10.1109/INFCOM.2012.6195833, March 2012.
[PCE-Init-LSP]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-09 (work in Model", Work in Progress,
progress), March 2017. draft-ietf-pce-pce-initiated-lsp-10, June 2017.
[I-D.ietf-pce-pcep-yang] [PCEP-GMPLS]
Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions
for GMPLS", Work in Progress,
draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.
[PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and j. Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Computation Element Communications Protocol (PCEP)", Work
draft-ietf-pce-pcep-yang-02 (work in progress), March in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
2017.
[I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-14 (work in
progress), May 2017.
[I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-10 (work in
progress), March 2017.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [PCEPS] Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure
programming algorithm for balancing the max-min fairness Transport for PCEP", Work in Progress,
and throughput objectives in traffic engineering", draft-ietf-pce-pceps-18, September 2017.
INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999, RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>. <https://www.rfc-editor.org/info/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
Christian, B., and W. Lai, "Applicability Statement for Christian, B., and W. Lai, "Applicability Statement for
Traffic Engineering with MPLS", RFC 3346, Traffic Engineering with MPLS", RFC 3346,
DOI 10.17487/RFC3346, August 2002, DOI 10.17487/RFC3346, August 2002,
<http://www.rfc-editor.org/info/rfc3346>. <https://www.rfc-editor.org/info/rfc3346>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[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, <https://www.rfc-editor.org/info/rfc4657>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008, DOI 10.17487/RFC5394, December 2008,
<http://www.rfc-editor.org/info/rfc5394>. <https://www.rfc-editor.org/info/rfc5394>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<http://www.rfc-editor.org/info/rfc8232>.
Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria, and Ramon
Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz, and Raveendra Torvi for their comments and suggestions.
Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga,
Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky,
Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui,
Stephane Litkowski, and Olivier Dugeon for helpful comments and
discussions.
Contributors
The following people contributed substantially to the content of this
document and should be considered coauthors:
Xian Zhang
Huawei Technology
F3-5-B R&D Center
Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
Email: dhruv.dhody@huawei.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Oracle Oracle
1501 4th Ave, suite 1800 1501 4th Ave, suite 1800
Seattle, WA 98101 Seattle, WA 98101
US United States of America
Email: edward.crabbe@oracle.com Email: edward.crabbe@oracle.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States of America
Email: inaminei@google.com Email: inaminei@google.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US United States of America
Email: jmedved@cisco.com Email: jmedved@cisco.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
Mlynske Nivy 56 Mlynske Nivy 56
Bratislava 821 05 Bratislava 821 05
Slovakia Slovakia
Email: robert.varga@pantheon.tech Email: robert.varga@pantheon.tech
 End of changes. 290 change blocks. 
725 lines changed or deleted 744 lines changed or added

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