draft-ietf-pce-stateful-pce-12.txt   draft-ietf-pce-stateful-pce-13.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Internet-Draft Individual Contributor
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: April 21, 2016 Google, Inc. Expires: June 3, 2016 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
October 19, 2015 December 1, 2015
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-12 draft-ietf-pce-stateful-pce-13
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016. This Internet-Draft will expire on June 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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? . . . . . . . . . . . . . . . . . 6
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8
4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8
5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Capability Advertisement . . . . . . . . . . . . . . . . 10 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 14 5.5. IGP Extensions for Stateful PCE Capabilities
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . 17 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 18 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18
5.6.1. Passive Stateful PCE Path Computation 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18
Request/Response . . . . . . . . . . . . . . . . . . 18 5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . 20 5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . 22 5.8.1. Passive Stateful PCE Path Computation
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 Request/Response . . . . . . . . . . . . . . . . . . 19
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 5.8.2. Active Stateful PCE LSP Update . . . . . . . . . . . 21
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22 5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 26 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 27 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 29
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 29 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 29
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 29
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . 32 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 29
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 35 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 30
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 36 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 32
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 37
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 38
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 37 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 38
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 39
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 39 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 40
8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 40 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 40
9. Manageability Considerations . . . . . . . . . . . . . . . . 40 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41
9.1. Control Function and Policy . . . . . . . . . . . . . . . 40 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 41
9.2. Information and Data Models . . . . . . . . . . . . . . . 41 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 42
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 42 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 42
9.5. Requirements on Other Protocols and Functional Components 42 9. Manageability Considerations . . . . . . . . . . . . . . . . 43
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 42 9.1. Control Function and Policy . . . . . . . . . . . . . . . 43
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9.2. Information and Data Models . . . . . . . . . . . . . . . 44
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 42 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 43 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 43 9.5. Requirements on Other Protocols and Functional Components 45
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 44 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 45
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 45
12.1. Normative References . . . . . . . . . . . . . . . . . . 44 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 46
12.2. Informative References . . . . . . . . . . . . . . . . . 45 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 47
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 47
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . 48
13.2. Informative References . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP). [RFC5440] describes the Path Computation Element Communication
PCEP defines the communication between a Path Computation Client Protocol (PCEP). PCEP defines the communication between a Path
(PCC) and a Path Computation Element (PCE), or between PCEs, enabling Computation Client (PCC) and a Path Computation Element (PCE), or
computation of Multiprotocol Label Switching (MPLS) for Traffic between PCEs, enabling computation of Multiprotocol Label Switching
Engineering Label Switched Path (TE LSP) characteristics. Extensions (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
for support of Generalized MPLS (GMPLS) in PCEP are defined in characteristics. Extensions for support of Generalized MPLS (GMPLS)
[I-D.ietf-pce-gmpls-pcep-extensions] in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions]
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 LSP compliance with [RFC4657]. It includes mechanisms to effect Label
state synchronization between PCCs and PCEs, delegation of control Switched Path (LSP) state synchronization between PCCs and PCEs,
over LSPs to PCEs, and PCE control of timing and sequence of path delegation of control over LSPs to PCEs, and PCE control of timing
computations within and across PCEP sessions. and sequence of path computations within and across PCEP sessions.
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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, PCEP Speaker.
This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [RFC3031]: LSP.
The following terms are defined in this document: The following terms are defined in this document:
Stateful PCE: has access to not only the network state, but also to Stateful PCE: a PCE that has access to not only the network state,
the set of active paths and their reserved resources for its but also to the set of active paths and their reserved resources
computations. A stateful PCE might also retain information for its computations. A stateful PCE might also retain
regarding LSPs under construction in order to reduce churn and information regarding LSPs under construction in order to reduce
resource contention. The additional state allows the PCE to churn and resource contention. The additional state allows the
compute constrained paths while considering individual LSPs and PCE to compute constrained paths while considering individual LSPs
their interactions. Note that this requires reliable state and their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE synchronization mechanisms between the PCE and the network, PCE
and PCC, and between cooperating PCEs. and PCC, and between cooperating PCEs.
Passive Stateful PCE: uses LSP state information learned from PCCs Passive Stateful PCE: a PCE that uses LSP state information learned
to optimize path computations. It does not actively update LSP from PCCs to optimize path computations. It does not actively
state. A PCC maintains synchronization with the PCE. update LSP state. A PCC maintains synchronization with the PCE.
Active Stateful PCE: is an extension of Passive Stateful PCE, in Active Stateful PCE: a PCE that may issue recommendations to the
which the PCE may issue recommendations to the network. For network.For example, an Active Stateful PCE may utilize the
example, an active stateful PCE may utilize the Delegation Delegation mechanism to update LSP parameters in those PCCs that
mechanism to update LSP parameters in those PCCs that delegated delegated control over their LSPs to the PCE.
control over their LSPs to the PCE.
Delegation: An operation to grant a PCE temporary rights to modify a Delegation: an operation to grant a PCE temporary rights to modify a
subset of LSP parameters on one or more PCC's LSPs. LSPs are subset of LSP parameters on one or more PCC's LSPs. LSPs are
delegated from a PCC to a PCE, and are referred to as delegated delegated from a PCC to a PCE, and are referred to as delegated
LSPs. The PCC who owns the PCE state for the LSP has the right to LSPs. The PCC that owns the PCE state for the LSP has the right
delegate it. An LSP is owned by a single PCC at any given point to delegate it. An LSP is owned by a single PCC at any given
in time. For intra-domain LSPs, this PCC SHOULD be the LSP head point in time. For intra-domain LSPs, this PCC should be the LSP
end. head end.
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: when a PCEP session is terminated, a Redelegation Timeout Interval: the period of time a PCC waits for,
PCC waits for this time period before revoking LSP delegation to a when a PCEP session is terminated, before revoking LSP delegation
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: when a PCEP session is terminated, a PCC State Timeout Interval: the period of time a PCE waits for, when a
waits for this time period 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 Admin Status, LSP attributes configured at the PCC and set by a
PCE, etc.) from a PCC to a PCE. 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
Reports to LSP Update Requests. It is carried in the SRP
(Stateful PCE Request Parameters) Object described in Section 7.2.
LSP State Database: information about all LSPs and their attributes. LSP State Database: information about all LSPs and their attributes.
Within this document, PCE-PCE communications are described by having Within this document, PCEP communications are described through PCC-
the requesting PCE fill the role of a PCC. This provides a saving in PCE relationship. The PCE architecture also supports the PCE-PCE
documentation without loss of function. communication, by having the requesting PCE fill the role of a PCC,
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
[I-D.ietf-pce-stateful-pce-app] presents several use cases, [I-D.ietf-pce-stateful-pce-app] presents several use cases,
demonstrating scenarios that benefit from the deployment of a demonstrating scenarios that benefit from the deployment of a
skipping to change at page 7, line 24 skipping to change at page 7, line 41
The use cases described in [I-D.ietf-pce-stateful-pce-app] The use cases described in [I-D.ietf-pce-stateful-pce-app]
demonstrate a need for visibility into global inter-PCC LSP state in demonstrate a need for visibility into global inter-PCC LSP state in
PCE path computations, and for PCE control of sequence and timing in PCE path computations, and for PCE control of sequence and timing in
altering LSP path characteristics within and across PCEP sessions. altering LSP path 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. However, this solution has several shortcomings: set LSP state. However, this solution has several shortcomings:
o Scale & Performance: configuration operations often require
processing of additional configuration portions beyond the state
being directly acted upon, with corresponding cost in CPU cycles,
negatively impacting both PCC stability LSP update rate capacity.
o Scale & Performance: configuration operations often have o Scale & Performance: configuration operations often have
transactional semantics which are typically heavyweight and transactional semantics which are typically heavyweight and often
require additional CPU cycles, negatively impacting PCC update require processing of additional configuration portions beyond the
rate capacity. state being directly acted upon, with corresponding cost in CPU
cycles, negatively impacting both PCC stability LSP update rate
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 prevents interoperability of a for configuring LSP state, which limits interoperability of a
PCE with PCCs from different vendors. The PCEP extensions stateful PCE with PCCs from different vendors. The PCEP
described in this document allow for a common information model extensions described in this document allow for a common
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 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. A PCC may revoke this delegation at any time any given time. A PCC may revoke this delegation at any time
during the lifetime of the LSP. If LSP delegation is revoked during the lifetime of the LSP. If LSP delegation is revoked
while the PCEP session is up, the PCC MUST notify the PCE about while the PCEP session is up, the PCC MUST notify the PCE about
the revocation. A PCE may return an LSP delegation at any point the revocation. A PCE may return an LSP delegation at any point
skipping to change at page 8, line 46 skipping to change at page 9, line 7
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.5); 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.
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to Similarly to [RFC5440], no assumption is made about the discovery
support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or method used by a PCC to discover a set of PCEs (e.g., via static
IS-IS ([RFC5089]) for PCE discovery. configuration or dynamic discovery) and on the algorithm used to
select a PCE.
5. Overview of Protocol Extensions 5. Overview of Protocol Extensions
5.1. LSP State Ownership 5.1. LSP State Ownership
In the PCEP protocol (defined in [RFC5440]), LSP state and operation In PCEP (defined in [RFC5440]), LSP state and operation are under the
are under the control of a PCC (a PCC may be an LSR or a management control of a PCC (a PCC may be an LSR or a management station).
station). Attributes received from a PCE are subject to PCC's local Attributes received from a PCE are subject to PCC's local policy.
policy. The PCEP protocol extensions described in this document do The PCEP extensions described in this document do not change this
not change this behavior. 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 through command line parameters may be set by the operator, for example through command
interface (CLI) commands line interface (CLI) 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 get 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 to a PCE to report the status of one or more LSPs. Each LSP
Status Report in a PCRpt message can contain the actual LSP's Status Report in a PCRpt message MAY contain the actual LSP's
path, bandwidth, operational and administrative status, etc. An path, bandwidth, operational and administrative status, etc. An
LSP Status Report carried on a PCRpt message is also used in LSP Status Report carried on a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. The delegation or revocation of control of an LSP to/from a PCE. The
PCRpt message is described in Section 6.1. PCRpt message is described in Section 6.1.
Path Computation Update Request (PCUpd): a PCEP message sent by a Path Computation Update Request (PCUpd): a PCEP message sent by a
PCE to a PCC to update LSP parameters, on one or more LSPs. Each PCE to a PCC to update LSP parameters, on one or more LSPs. Each
LSP Update Request on a PCUpd message MUST contain all LSP LSP Update Request on a PCUpd message MUST contain all LSP
parameters that a PCE wishes to be set for a given LSP. An LSP parameters that a PCE wishes to be set for a given LSP. An LSP
Update Request carried on a PCUpd message is also used to return Update Request carried on a PCUpd message is also used to return
LSP delegations if at any point PCE no longer desires control of LSP delegations if at any point PCE no longer desires control of
an LSP. The PCUpd message is described in Section 6.2. an LSP. The PCUpd message is described in Section 6.2.
The new functions defined in Section 4 are mapped onto the new The new functions defined in Section 4 are mapped onto the new
messages as shown in the following table. messages as shown in the following table.
+----------------------------------------+--------------------------+ +----------------------------------------+--------------+
| Function | Message | | Function | Message |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------+
| Capability Advertisement (E-C,C-E) | Open | | Capability Advertisement (E-C,C-E) | Open |
| 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 |
| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS sub- | +----------------------------------------+--------------+
| | TLV |
| OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, |
| | PCE-CAP-FLAGS sub-TLV |
+----------------------------------------+--------------------------+
Table 1: New Function to Message Mapping Table 1: New Function to Message Mapping
5.3. Capability Advertisement 5.3. Error Reporting
Error reporting is done using the procedures defined in [RFC5440],
and reusing the applicable error types and error values of [RFC5440]
wherever appropriate. The current document defines new error values
for several error types to cover failures specific to stateful PCE.
5.4. Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of stateful PCEP extensions. A PCEP Speaker advertise their support of stateful PCEP extensions. A PCEP Speaker
includes the "Stateful PCE Capability" TLV, described in 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 extensions. The Stateful Capability TLV includes the 'LSP
Update' Flag that indicates whether the PCEP Speaker supports LSP Update' Flag that indicates whether the PCEP Speaker supports LSP
parameter updates. 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 protocol extensions for stateful PCEs MUST NOT be used if The PCEP extensions for stateful PCEs MUST NOT be used if one or both
one or both PCEP Speakers have not included the Stateful PCE PCEP Speakers have not included the Stateful PCE Capability TLV in
Capability TLV in their respective OPEN message. If the PCEP Speaker their respective OPEN message. If the PCEP Speaker on the PCC
on the PCC supports the extensions of this draft but did not
advertise this capability, then upon receipt of PCUpd message from
the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid
Operation), error-value 2 (Attempted LSP Update Request if the
stateful PCE capability was not advertised)(see Section 8.4) and it
will terminate the PCEP session. If the PCEP Speaker on the PCE
supports the extensions of this draft but did not advertise this supports the extensions of this draft but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it capability, then upon receipt of PCUpd message from the PCE, it MUST
SHOULD generate a PCErr with error-type 19 (Invalid Operation), generate a PCErr with error-type 19 (Invalid Operation), error-value
error-value 5 (Attempted LSP State Report if active stateful PCE 2 (Attempted LSP Update Request if the stateful PCE capability was
capability was not advertised) (see Section 8.4) and it will not advertised)(see Section 8.5) and it SHOULD terminate the PCEP
terminate the PCEP session. session. If the PCEP Speaker on the PCE supports the extensions of
this draft but did not advertise this capability, then upon receipt
of a PCRpt message from the PCC, it MUST generate a PCErr with error-
type 19 (Invalid Operation), error-value 5 (Attempted LSP State
Report if active stateful PCE capability 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 Flag in the only be used if both PCEP Speakers set the LSP-UPDATE Flag in the
"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this
is not the case and LSP delegation or LSP update operations are is not the case and LSP delegation or LSP update operations are
attempted, then a PCErr with error-type 19 (Invalid Operation) and attempted, then a PCErr with error-type 19 (Invalid Operation) and
error-value 1 (Attempted LSP Update Request for a non-delegated error-value 1 (Attempted LSP Update Request for a non-delegated LSP)
LSP).(see Section 8.4) SHOULD be generated. Note that even if the (see Section 8.5) MUST be generated. Note that even if the update
update capability has not been advertised, a PCE can still receive capability has not been advertised, a PCE can still accept LSP Status
LSP Status Reports from a PCC and build and maintain an up to date Reports from a PCC and build and maintain an up to date view of the
view of the state of the PCC's LSPs. state of the PCC's LSPs.
5.4. State Synchronization 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the
advertisement of PCE Discovery Information are defined for OSPF and
for IS-IS in [RFC5088] and [RFC5089] respectively.
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-
TLV used to advertise PCE capabilities. It MAY be present within the
PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089]
provide the description and processing rules for this sub-TLV when
carried within OSPF and IS-IS, respectively.
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
reference:
Type: 5
Length: Multiple of 4.
Value: This contains an array of units of 32 bit flags with the most
significant bit as 0. Each bit represents one PCE capability.
PCE capability bits are defined in [RFC5088]. This document defines
new capability bits for the stateful PCE as follows:
Bit Capability
TBD Active Stateful PCE capability
TBD Passive Stateful PCE capability
Note that while active and passive stateful PCE capabilities may be
advertised during discovery, PCEP Speakers that wish to use stateful
PCEP MUST negotiate stateful PCEP capabilities during PCEP session
setup, as specified in the current document. A PCC MAY initiate
stateful PCEP capability negotiation at PCEP session setup even if it
did not receive any IGP PCE capability advertisements.
5.6. State Synchronization
The purpose of State Synchronization is to provide a checkpoint-in- The purpose of State Synchronization is to provide a checkpoint-in-
time state replica of a PCC's LSP state in a PCE. State time state replica of a PCC's LSP state in a PCE. State
Synchronization is performed immediately after the Initialization Synchronization is performed immediately after the Initialization
phase ([RFC5440]). 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 state, then sends the snapshot to a PCE in a
sequence of LSP State Reports. Each LSP State Report sent during sequence of LSP State Reports. Each LSP State Report sent during
State Synchronization has the SYNC Flag in the LSP Object set to 1. State Synchronization has the SYNC Flag in the LSP Object set to 1.
The set of LSPs for which state is synchronized with a PCE is The set of LSPs for which state is synchronized with a PCE is
determined by advertised stateful PCEP capabilities and PCC's local determined by advertised stateful PCEP capabilities and PCC's local
configuration (see more details in Section 9.1). configuration (see more details in Section 9.1).
The end of synchronization marker is a PCRpt message with the SYNC The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV value 0 (see Section 7.3). The LSP Object does not include the
in this case, and it will include an empty ERO in its path. If the SYMBOLIC-PATH-NAME TLV in this case, it will include an empty ERO as
PCC has no state to synchronize, it will only send the end of its intended path and will not include the optional RRO object in the
synchronization marker. path. If the PCC has no state to synchronize, it will only send the
end of 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 state it received
skipping to change at page 12, line 26 skipping to change at page 13, line 30
timer. timer.
If the PCC encounters a problem which prevents it from completing the If the PCC encounters a problem which prevents it from completing the
state transfer, it MUST send a PCErr message with error-type 20 (LSP state transfer, it MUST send a PCErr message with error-type 20 (LSP
State Synchronization Error) and error-value 5 (indicating an State Synchronization Error) and error-value 5 (indicating an
internal PCC error) to the PCE and terminate the session. internal PCC error) to the PCE and terminate the session.
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgements 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.4) 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 PCErr message with error-type 19 (invalid operation) and MUST send a PCNtf message with Notification Type to be allocated by
error-value 4 (indicating resource limit exceeded) in response to the IANA (Stateful PCE resource limit exceeded) and Notification Value to
PCRpt message triggering this condition in the synchronization phase be allocated by IANA (Entering resource limit exceeded state) in
and MUST terminate the session. response to the PCRpt message triggering this condition in the
synchronization phase and MUST terminate the session.
The successful State Synchronization sequence is shown in 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 14, line 28 skipping to change at page 15, line 28
|-------- 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
[I-D.ietf-pce-stateful-sync-optimizations]). [I-D.ietf-pce-stateful-sync-optimizations]).
5.5. 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.
LSP Delegation is controlled by operator-defined policies on a PCC. A PCE MAY return an LSP delegation at any time if it no longer wishes
LSPs are delegated individually - different LSPs may be delegated to to update the LSP's state. A PCC MAY revoke an LSP delegation at any
different PCEs. An LSP is delegated to at most one PCE at any given time. Delegation, Revocation, and Return are done individually for
point in time. The delegation policy, when all PCC's LSPs are each LSP.
delegated to a single PCE at any given time, SHOULD be supported by
all delegation-capable PCCs. Conversely, the policy revoking the
delegation for all PCC's LSPs SHOULD also be supported.
A PCE may return LSP delegation at any time if it no longer wishes to
update the LSP's state. A PCC may revoke LSP delegation at any time.
Delegation, Revocation, and Return are done individually for each
LSP.
In the event of an delegation being rejected or returned by a PCE, In the event of a delegation being rejected or returned by a PCE, the
the PCC should react based on local policy. It can, for example, PCC SHOULD react based on local policy. It can, for example, either
either retry delegating to the same PCE using an exponentially retry delegating to the same PCE using an exponentially increasing
increasing timer or delegate to an alternate PCE. timer or delegate to an alternate PCE.
5.5.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 LSP
State Report to 1. If the PCE does not accept the LSP Delegation, it State Report to 1. If the PCE does not accept the LSP Delegation, it
MUST immediately respond with an empty LSP Update Request which has MUST immediately respond with an empty LSP Update Request which has
the Delegate flag set to 0. If the PCE accepts the LSP Delegation, the Delegate flag set to 0. If the PCE accepts the LSP Delegation,
it confirms this when it sends the first LSP Update Request for the it MUST set the Delegate flag to 1 when it sends an LSP Update
delegated LSP to the PCC by setting the Delegate flag to 1 (note that Request for the delegated LSP (note that this may occur at a later
this may occur at a later time). time). The PCE MAY also immediately acknowledge a delegation by
sending an empty LSP Update Request which has the Delegate flag set
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--->|
skipping to change at page 15, line 39 skipping to change at page 16, line 32
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
Figure 4: Delegating an LSP Figure 4: Delegating an LSP
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 Status Report sent to the PCE. the Delegate flag to 1 on each LSP Status Report sent to the PCE.
5.5.2. Revoking a Delegation 5.7.2. Revoking a Delegation
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 life time. A PCC
revoking an LSP delegation MAY immediately clear the LSP state revoking an LSP delegation MAY immediately clear the LSP state
provided by the PCE, but to avoid traffic loss, it SHOULD do so in a provided by the PCE, but to avoid traffic loss, it SHOULD do so in a
make-before-break fashion. If the PCC has received but not yet acted make-before-break fashion. If the PCC has received but not yet acted
on 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
skipping to change at page 16, line 32 skipping to change at page 17, line 29
| . | | . |
|---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 LSP's parameters; an attempt to update parameters of a non-delegated
LSP will result in the PCC sending a PCErr message with error-type 19 LSP will result in the PCC sending a PCErr message with error-type 19
(Invalid Operation), error-value 1 (attempted LSP Update Request for (Invalid Operation), error-value 1 (attempted LSP Update Request for
a non-delegated LSP) (see Section 8.4). a non-delegated LSP) (see Section 8.5).
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 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 reestablished 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, the PCC MUST wait for the State Timeout Interval before unexpectedly, the PCC MUST wait for the State Timeout Interval before
flushing any LSP state associated with that PCE. Note that the State flushing any LSP state associated with that PCE. Note that the State
Timeout Interval timer may expire before the PCC has redelegated the Timeout Interval timer may expire before the PCC has redelegated the
LSPs to another PCE, for example if a PCC is not connected to any LSPs to another PCE, for example if a PCC is not connected to any
active stateful PCE or if no connected active stateful PCE accepts active stateful PCE or if no connected active stateful PCE accepts
the delegation. In this case, the PCC SHALL flush any LSP state set the delegation. In this case, the PCC MUST flush any LSP state set
by the PCE upon expiration of the State Timeout Interval and revert by the PCE upon expiration of the State Timeout Interval and revert
to operator-defined default parameters or behaviors. This operation to 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 SHOULD 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.5.3. Returning a Delegation 5.7.3. Returning a Delegation
A PCE that no longer wishes to update an LSP's parameters SHOULD In order to keep a delegation, a PCE MUST set the Delegate flag to 1
return the LSP delegation back to the PCC by sending an empty LSP on each LSP Update Request sent to the PCC. A PCE that no longer
Update Request which has the Delegate flag set to 0. Note that in wishes to update an LSP's parameters SHOULD return the LSP delegation
order to keep a delegation, the PCE MUST set the Delegate flag to 1 back to the PCC by sending an empty LSP Update Request which has the
on each LSP Update Request sent to the PCC. Delegate flag set to 0. If a PCC receives a non-empty LSP Update
Request with the Delegate flag set to 0, it MUST treat this as a
delegation return.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP delegated |---PCRpt, Delegate=1--->| LSP delegated
| . | | . |
| . | | . |
| . | | . |
|<--PCUpd, Delegate=0----| Delegation returned |<--PCUpd, Delegate=0----| Delegation returned
skipping to change at page 17, line 40 skipping to change at page 18, line 39
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 time out 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. the State Timeout Interval.
5.5.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 larger than the Redelegation Timeout Interval (as configured to be greater than the Redelegation Timeout Interval (as
recommended), this delegation change will not cause any changes to MANDATORY), and assuming that the primary and redundant PCEs take
the LSP parameters. similar decisions, this delegation change will not cause any changes
to the LSP parameters.
5.5.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 behaviour with regards to LSP delegation
skipping to change at page 18, line 37 skipping to change at page 19, line 38
redelegate the LSPs to another PCE, then upon expiration of the State redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is flushed, which may Timeout Interval, the state set by the PCE is flushed, which may
cause change in the LSP state. Note that an operator may choose to cause change in the LSP state. Note that an operator may choose to
use an infinite State Timeout Interval if he wishes to maintain the use an infinite State Timeout Interval if he wishes to maintain the
PCE state indefinetely. Note also that flushing the state should be PCE state indefinetely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss. implemented using make-before-break to avoid traffic loss.
If there is a standby PCE, the Redelegation Timeout may be set to 0 If there is a standby PCE, the Redelegation Timeout may be set to 0
through policy on the PCC, causing the LSPs to be redelegated through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the immediately to the PCC, which can delegate them immediately to the
standby PCE. Assuming the State Timeout Interval is larger than the standby PCE. Assuming the State Timeout Interval is greater than the
Redelegation Timeout, the LSP state will be kept intact. Redelegation Timeout, and assuming the standby PCE takes similar
decisions as the failed PCE, the LSP state will be kept intact.
5.6. LSP Operations 5.8. LSP Operations
5.6.1. Passive Stateful PCE Path Computation Request/Response 5.8.1. Passive Stateful PCE Path Computation Request/Response
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
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
skipping to change at page 19, line 43 skipping to change at page 20, line 43
sends a path computation request to the PCE ([RFC5440], 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 setup the LSPs. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, MAY send an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is "Going-up". indicating that the LSP's status is "Going-up".
Once an LSP is up or active, the PCC sends 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 set
up, the PCC sends an LSP State Report indicating that the LSP is up, the PCC MUST send an LSP State Report indicating that the LSP is
"Down' and stating the cause of the failure. Note that due to timing "Down' and stating the cause of the failure. Note that due to timing
constraints, the LSP status may change from 'Going-up' to 'Up' (or constraints, the LSP status may change from 'Going-up' to 'Up' (or
'Down') before the PCC has had a chance to send an LSP State Report 'Down') before the PCC has had a chance to send an LSP State Report
indicating that the status is 'Going-up'. In such cases, the PCC may indicating that the status is 'Going-up'. In such cases, the PCC MAY
choose to only send the PCRpt indicating the latest status ('Active', choose to only send the PCRpt indicating the latest status ('Active',
'Up' or 'Down'). 'Up' or 'Down').
Upon receiving a negative reply from a PCE, a PCC may decide to Upon receiving a negative reply from a PCE, a PCC MAY resend a
resend a modified request or take any other appropriate action. For modified request or take any other appropriate action. For each
each requested LSP, it also sends 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.
A PCC sends 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.
Note that a single PCRpt message MAY contain multiple LSP State Note that a single PCRpt message MAY contain multiple LSP State
Reports. Reports.
The passive stateful PCE is the model for stateful PCEs is described The passive stateful PCE is the model for stateful PCEs is described
in [RFC4655], Section 6.8. in [RFC4655], Section 6.8.
5.6.2. Active Stateful PCE LSP Update 5.8.2. Active Stateful PCE LSP Update
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) LSP State |-- PCRpt, Delegate=1 -->| 1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . | Synchronization | . |
or add new LSP | . |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 PCC
| | | |
| | | |
4) LSP Status Report|---- PCRpt message ---->| 4) LSP Status Report|---- PCRpt message ---->|
sent(->Going-up) | . | sent(->Going-up) | . |
| . | | . |
| . | | . |
5) LSP Status Report|---- PCRpt message ---->| 5) LSP Status 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) and LSPs have been the PCE knows about all PCC's existing LSPs). After LSPs have been
delegated to the PCE, the PCE can modify LSP parameters of delegated delegated to the PCE, the PCE can modify LSP parameters of delegated
LSPs. LSPs.
A PCE sends an LSP Update Request carried on a PCUpd message to the To update an LSP, a PCE MUST send the PCC an LSP Update Request using
PCC. The LSP Update Request contains a variety of objects that a PCUpd message. The LSP Update Request contains a variety of
specify the set of constraints and attributes for the LSP's path. objects that specify the set of constraints and attributes for the
Each LSP Update Request has a unique identifier, the SRP-ID-number, LSP's path. Each LSP Update Request MUST have a unique identifier,
carried in the SRP (Stateful PCE Request Parameters) Object described the SRP-ID-number, carried in the SRP (Stateful PCE Request
in Section 7.2. The SRP-ID-number is used to correlate errors and Parameters) Object described in Section 7.2. The SRP-ID-number is
state reports to LSP Update Requests. A single PCUpd message MAY used to correlate errors and state reports to LSP Update Requests. A
contain multiple LSP Update Requests. single PCUpd message MAY contain 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 setup LSPs specified
in LSP Update Requests carried in the message. For each LSP, it in LSP Update Requests carried in the message. For each LSP, it MAY
sends an LSP State Report carried on a PCRpt message to the PCE, send an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Going-up'. If the PCC decides indicating that the LSP's status is 'Going-up'. If the PCC decides
that the LSP parameters proposed in the PCUpd message are 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 LSP-ERROR-
CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 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.4). PSP-ID) (see Section 8.5).
Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt
to the PCE, indicating that the LSP's status is 'Up'. If the LSP message) to the PCE, indicating that the LSP's status is 'Up'. If
could not be set up, the PCC sends an LSP State Report indicating the LSP could not be set up, the PCC MUST send an LSP State Report
that the LSP is 'Down' and stating the cause of the failure. A PCC indicating that the LSP is 'Down' and stating the cause of the
may choose to compress LSP State Reports to only reflect the most up failure. A PCC MAY compress LSP State Reports to only reflect the
to date state, as discussed in the previous section. most up to date state, as discussed in the previous section.
A PCC sends 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 choose to compress state when processing processing. The PCC MAY compress state when processing PCUpd. In
PCUpd. In this case, receipt of a higher SRP-ID-number implicitly this case, receipt of a higher SRP-ID-number implicitly acknowledges
acknowledges processing all the earlier updates for the specific LSP. processing all the updates with lower SRP-ID-number 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 Delegation
Revocation procedure first. Revocation procedure first.
5.7. 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 draft. discussed in a separate document.
5.8. Transport 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 reestablishment
MUST be re-attempted per the procedures defined in [RFC5440]. 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 that can followed by a variable-length body made of a set of objects. For
be either mandatory or optional. An object is said to be mandatory each PCEP message type, a set of rules is defined that specify the
in a PCEP message when the object must be included for the message to set of objects that the message can carry.
be considered valid. For each PCEP message type, a set of rules is
defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object
ordering specified in this document.
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
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 to be assigned by IANA. for the PCRpt message is to be assigned by IANA.
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>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <ERO><attribute-list>[<RRO>] <path>::= <intended_path><attribute-list>[<actual_path>]
Where: Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions. <intended_path> is represented by the ERO object defined in
section 7.9 of [RFC5440].
<attribute-list> is defined in [RFC5440] and extended by
PCEP extensions.
<actual_path> is represented by the RRO object defined in
section 7.10 of [RFC5440].
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 treats this as When the PCC does not include the SRP object, the PCE MUST treat this
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 as 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 latest one, PCUpd messages for the same LSP by only processing the one with the
then it should use the SRP-ID-number of that request. No state highest number, then it should use the SRP-ID-number of that request.
compression is allowed for state reporting, e.g. PCRpt messages MUST No state compression is allowed for state reporting, e.g. PCRpt
NOT be pruned from the PCC's egress queue even if subsequent messages MUST NOT be pruned from the PCC's egress queue even if
operations on the same LSP have been completed before the PCRpt subsequent operations on the same LSP have been completed before the
message has been sent to the TCP stack. The PCC MUST explicitly PCRpt message has been sent to the TCP stack. The PCC MUST
report state changes (including removal) for paths it manages. explicitly report state changes (including removal) for paths it
manages.
The LSP object (see Section 7.3) is mandatory, and it MUST be The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
included in each LSP State Report on the PCRpt message. If the LSP in each LSP State Report on the PCRpt message. If the LSP object is
object is missing, the receiving PCE MUST send a PCErr message with missing, the receiving PCE MUST send a PCErr message with Error-
Error-type=6 (Mandatory Object missing) and Error-value to be type=6 (Mandatory Object missing) and Error-value to be assigned by
assigned by IANA (LSP object missing). IANA (LSP object 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 RRO SHOULD be included by the PCC when the path is up or active, The actual path, represented by the RRO object, SHOULD be included in
but MAY be omitted if the path is down due to a signaling error or PCRpt by the PCC when the path is up or active, but MAY be omitted if
another failure. the path is down due to a signaling error or another failure.
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, it MUST send a PCErr message with error-type 19 (invalid this limit, the PCE MUST notify the PCC using a PCNtf message with
operation) and error-value 4 (indicating resource limit exceeded) in Notification Type to be allocated by IANA (Stateful PCE resource
response to the PCRpt message triggering this condition and MAY limit exceeded) and Notification Value to be allocated by IANA
terminate the session. (Entering resource limit exceeded state) and MAY 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 to be assigned by IANA. the PCUpd message is to be assigned by IANA.
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>::= <ERO><attribute-list> <path>::= <intended_path><attribute-list>
Where: Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions. <intended_path> is represented by the ERO object defined in
section 7.9 of [RFC5440].
<attribute-list> is 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]. If the SRP object is missing, the receiving defined in [RFC5440], which represents the intended path. If the SRP
PCC MUST send a PCErr message with Error-type=6 (Mandatory Object object is missing, the receiving PCC MUST send a PCErr message with
missing) and Error-value=10 (SRP object missing). If the LSP object Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
object missing). If the LSP object is missing, the receiving PCC
MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=8 (LSP object missing). If the ERO object
is missing, the receiving PCC MUST send a PCErr message with Error- is missing, the receiving PCC MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=8 (LSP object type=6 (Mandatory Object missing) and Error-value=9 (ERO object
missing). If the ERO object is missing, the receiving PCC MUST send missing).
a PCErr message with Error-type=6 (Mandatory Object missing) and
Error-value=9(ERO object missing).
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 co-exist. 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 LSP-
IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number
that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a
make-before-break operation will typically result in at least two make-before-break operation will typically result in at least two
PCRpt messages, one for the new path and one for the removal of the PCRpt messages, one for the new path and one for the removal of the
old path (more messages may be possible if intermediate states are old path (more messages may be possible if intermediate states are
reported). 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 resignal 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.
skipping to change at page 26, line 15 skipping to change at page 27, line 29
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 PCUpd
arrive for the same LSP in quick succession and the PCC started the arrive for the same LSP in quick succession and the PCC started the
signaling of the changes relevant to the first PCUpd, then it MUST signaling of the changes relevant to the first PCUpd, then it MUST
wait until the signaling finishes (and report the new state via a wait until the signaling finishes (and report the new state via a
PCRpt) before attempting to apply the changes indicated in the second PCRpt) before attempting to apply the changes indicated in the second
PCUpd. 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 set-ups 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. If the PCUpd cannot be satisfied (for update of the next LSP.
example due to unsupported object or TLV), the PCC MUST respond with
a PCErr message indicating the failure (see Section 7.3.3). If the PCUpd cannot be satisfied (for example due to unsupported
object or TLV), the PCC MUST respond with a PCErr message 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 SRP-ID-
number MUST be the one from the PCUpd that triggered the error. If number MUST be the one from the PCUpd that triggered the error. If
the error is unsolicited, the SRP object MAY be omitted. This is the error is unsolicited, the SRP object MAY be omitted. This is
equivalent to including an SRP object with SRP-ID-number equal to the equivalent to including an SRP object with SRP-ID-number equal to the
reserved value 0x00000000. reserved value 0x00000000.
skipping to change at page 28, line 9 skipping to change at page 29, line 33
<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 flag and the I flag of the
PCEP objects defined in this document SHOULD always be set to 0 on PCEP objects defined in the current document MUST be set to 0 on
transmission and SHOULD be ignored on receipt since these flags are transmission and SHOULD be ignored on receipt since the P and I flags
exclusively related to path computation requests. are exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines one new optional TLVs for use in the OPEN This document defines one new optional TLVs 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
skipping to change at page 28, line 34 skipping to change at page 30, line 15
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=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U| | Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV format Figure 9: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is to be assigned by IANA and it has a fixed The type (16 bits) of the TLV is to be assigned by IANA. The length
length of 4 octets. field is 16 bit-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.
skipping to change at page 29, line 50 skipping to change at page 31, line 36
current PCEP session uniquely identify the operation that the PCE has current PCEP session uniquely identify the operation that the PCE has
requested the PCC to perform on a given LSP. The SRP-ID-number is requested the PCC to perform on a given LSP. The SRP-ID-number is
incremented each time a new request is sent to the PCC, and may wrap incremented each time a new request is sent to the PCC, and may wrap
around. around.
The values 0x00000000 and 0xFFFFFFFF are reserved. The values 0x00000000 and 0xFFFFFFFF are reserved.
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 may
be more than one SRP-id-number unacknowledged at a given time. The be more than one SRP-ID-number unacknowledged at a given time. The
value of the SRP-ID-number is echoed back by the PCC in PCErr and 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 were not as 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 SRP-ID-
number is considered unacknowledged and cannot be reused until a number is considered unacknowledged and cannot be reused until a
PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the
same LSP. In case of SRP-ID wrapping the last SRP-ID before the same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number
wrapping MUST be explicitly acknowledged, to avoid a situation where before the wrapping MUST be explicitly acknowledged, to avoid a
SRP-IDs remain unacknowledged after the wrap. This means that the situation where SRP-ID-numbers remain unacknowledged after the wrap.
PCC may need to issue two PCUpd messages on detecting a wrap. This means that the PCC may need to issue two PCUpd messages on
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
skipping to change at page 31, line 8 skipping to change at page 32, line 44
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 times. 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 a different RSVP
identifiers (LSP-id, tunnel-id) allocated it. identifiers (LSP-id, tunnel-id) allocated to it.
Flags (12 bits): 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 PCRpt messages sent from the PCC. to 0 in other messages sent from the PCC.
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. database.
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
skipping to change at page 32, line 22 skipping to change at page 34, line 8
4 - GOING-UP: LSP is being signalled. 4 - GOING-UP: LSP is being signalled.
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 considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
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. following sections.
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 exmple, 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 for the reoptimized paths, and explicitly report removal
of any of these paths using the R bit in the LSP object. of any of these paths using the R bit in the LSP object.
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 21 skipping to change at page 34, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 of the TLV is to be assigned by IANA and it has a fixed The type (16 bits) of the TLV is to be assigned by IANA. The length
length of 16 octets. The value contains the following fields: field is 16 bit-long and has a fixed value of 16. The value contains
the following 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.
Tunnel ID remains constant over the life time of a tunnel.
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 l 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=[TBD] | Length=52 | | Type=[TBD] | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
skipping to change at page 34, line 39 skipping to change at page 36, line 39
+ + + +
| 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 of the TLV is to be assigned by IANA and it has a fixed The type (16 bits) of the TLV is to be assigned by IANA. The length
length of 52 octets. The value contains the following fields: field is 16 bit-long and has a fixed value of 52. The value contains
the following 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.
Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa).
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.
7.3.2. Symbolic Path Name TLV 7.3.2. Symbolic Path Name TLV
Each LSP (path) MUST have a symbolic name that is unique in the PCC. Each LSP (path) MUST have a symbolic name that is unique in the PCC.
This symbolic path name MUST remain constant throughout a path's This symbolic path name MUST remain constant throughout an LSP's
lifetime, which may span across multiple consecutive PCEP sessions lifetime, which may span across multiple consecutive PCEP sessions
and/or PCC restarts. The symbolic path name MAY be specified by an and/or PCC restarts. The symbolic path name MAY be specified by an
operator in a PCC's configuration. If the operator does not specify operator in a PCC's configuration. If the operator does not specify
a unique symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
when during a given PCEP session an LSP is first reported to a PCE. LSP State Report (PCRpt) message when during a given PCEP session an
A PCC sends to a PCE the first LSP State Report either during State LSP is first reported to a PCE. A PCC sends to a PCE the first LSP
Synchronization, or when a new LSP is configured at the PCC. The State Report either during State Synchronization, or when a new LSP
symbolic path name MAY be included in subsequent LSP State Reports is configured at the PCC. The symbolic path name MAY be included in
for the LSP. the LSP object in subsequent LSP State Reports for the LSP.
The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
and the SRP Object.
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=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV format Figure 14: SYMBOLIC-PATH-NAME TLV format
The type of the TLV is to be assigned by IANA and it has a variable Type (16 bits): to be assigned by IANA.
length, which MUST be greater than 0.
Length (16 bits): indicates the total length of the TLV in octets and
MUST be greater than 0. The TLV MUST be zero-padded so that the TLV
is 4-octet aligned.
Symbolic Path Name (variable): symbolic name for the LSP, unique in
the PCC.
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 SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for
the failure. Similarly, when a PCRpt is sent as a result of an LSP the failure. Similarly, when a PCRpt is sent as a result of an LSP
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD
be included to indicate the reason for the transition. be included to indicate the reason for the transition.
skipping to change at page 36, line 31 skipping to change at page 38, line 31
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=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV format Figure 15: LSP-ERROR-CODE TLV format
The type of the TLV is to be assigned by IANA and it has a fixed The type (16 bits) of the TLV is to be assigned by IANA. The length
length of 4 octets. The value contains an error code that indicates field is 16 bit-long and has a fixed value of 4. The value contains
the cause of the failure. an error code 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 Meaning
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
skipping to change at page 37, line 24 skipping to change at page 39, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=[TBD] | 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
The type of the TLV is to be assigned by IANA and it has a variable Type (16 bits):to be assigned by IANA.
length. The value contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
object, including the object header. Length (16 bits): indicates the total length of the TLV in octets.
The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
Object: as specified in [RFC2205] and [RFC5284], including the object
header.
8. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. Values shown here are protocol elements defined in this document. Values shown here are
suggested for use by IANA. suggested for use by IANA.
8.1. PCEP Messages 8.1. PCE Capabilities in IGP Advertisements
IANA is requested to allocate new bits in "PCE Capability Flags"
registry for stateful PCE capability as follows:
Bit Meaning Reference
11 Active Stateful PCE This document
capability
12 Passive Stateful PCE This document
capability
8.2. PCEP Messages
This document defines the following new PCEP messages: This document defines the following new PCEP messages:
Value Meaning Reference Value Meaning Reference
10 Report This document 10 Report This document
11 Update This document 11 Update This document
8.2. PCEP Objects 8.3. PCEP Objects
This document defines the following new PCEP Object-classes and This document defines the following new PCEP Object-classes and
Object-values: Object-values:
Object-Class Value Name Reference Object-Class Value Name Reference
32 LSP This document 32 LSP This document
Object-Type Object-Type
1 1
33 SRP This document 33 SRP This document
Object-Type Object-Type
1 1
8.3. LSP Object 8.4. LSP Object
This document requests that a registry is created to manage the Flags This document requests that a new sub-registry, named "LSP Object
field of the LSP object. New values are to be assigned by Standards Flag Field", is created within the "Path Computation Element Protocol
Action [RFC5226]. Each bit should be tracked with the following (PCEP) Numbers" registry to manage the Flag field of the LSP
qualities: object.New values are to be assigned by Standards Action [RFC5226].
Each bit should be tracked 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 Reserved 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.4. PCEP-Error Object 8.5. PCEP-Error Object
This document defines new Error-Type and Error-Value for the This document defines new Error-Type and Error-Value for the
following new error conditions: following new error conditions:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=9: ERO Object missing
Error-value=10: SRP Object missing Error-value=10: SRP Object missing
skipping to change at page 39, line 4 skipping to change at page 41, line 18
following new error conditions: following new error conditions:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=9: ERO Object missing
Error-value=10: SRP Object missing Error-value=10: SRP Object missing
Error-value=11: LSP-IDENTIFIERS TLV missing Error-value=11: LSP-IDENTIFIERS TLV missing
19 Invalid Operation 19 Invalid Operation
Error-value=1: Attempted LSP Update Request for a non- Error-value=1: Attempted LSP Update Request for a non-
delegated LSP. The PCEP-ERROR Object delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that is followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: Attempted LSP Update Request if the Error-value=2: Attempted LSP Update Request if the
stateful PCE capability was not stateful PCE capability was not
advertised. advertised.
Error-value=3: Attempted LSP Update Request for an LSP Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID. identified by an unknown PLSP-ID.
Error-value=4: A PCE indicates to a PCC that it has
exceeded the resource limit allocated
for its state, and thus it cannot
accept and process its LSP State Report
message.
Error-value=5: Attempted LSP State Report if active Error-value=5: Attempted LSP State Report if active
stateful PCE capability was not stateful PCE capability was not
advertised. advertised.
20 LSP State synchronization error. 20 LSP State synchronization error.
Error-value=1: A PCE indicates to a PCC that it can Error-value=1: A PCE indicates to a PCC that it can
not process (an otherwise valid) LSP not process (an otherwise valid) LSP
State Report. The PCEP-ERROR Object is State Report. The PCEP-ERROR Object is
followed by the LSP Object that followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=5: A PCC indicates to a PCE that it can Error-value=5: A PCC indicates to a PCE that it can
not complete the state synchronization, not complete the state synchronization,
8.5. PCEP TLV Type Indicators 8.6. Notification Object
IANA is requested to allocate new Notification Types and Notification
Values in the "PCEP Notification Object" registry as follows:
Notification-Type Meaning
4 Stateful PCE resource limit exceeded
Notification-value=1: Entering resource limit
exceeded state
Notification-value=2: Exiting resource limit exceeded
state
8.7. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning 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.6. STATEFUL-PCE-CAPABILITY TLV 8.8. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a new sub-registry, named "STATEFUL-PCE-
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New CAPABILITY TLV Flag Field", is created within the "Path Computation
values are to be assigned by Standards Action [RFC5226]. Each bit Element Protocol (PCEP) Numbers" registry to manage the Flag field in
should be tracked with the following qualities: the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1).
New values are to be assigned by Standards Action [RFC5226]. Each
bit should be tracked 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
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
skipping to change at page 40, line 14 skipping to change at page 42, line 41
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
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.7. LSP-ERROR-CODE TLV 8.9. LSP-ERROR-CODE TLV
This document requests that a registry is created to manage the value This document requests that a new sub-registry, named "LSP-ERROR-CODE
of the LSP error code field in this TLV. This field specifies the TLV Error Code Field", is created within the "Path Computation
Element Protocol (PCEP) Numbers" registry to manage the LSP Error
code field of the LSP-ERROR-CODE TLV. This field specifies the
reason for failure to update the LSP. reason for failure to update the LSP.
Value Meaning Value Meaning
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 protocol extensions defined in this document. In apply to PCEP extensions defined in this document. In addition,
addition, requirements and considerations listed in this section requirements and considerations listed in this section apply.
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
skipping to change at page 41, line 29 skipping to change at page 44, line 13
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 make-before-break fashion.
LSP Delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually - different LSPs may be delegated to
different PCEs. An LSP is delegated to at most one PCE at any given
point in time. A PCC implementation SHOULD support the delegation
policy, when all PCC's LSPs are delegated to a single PCE at any
given time. Conversely, the policy revoking the delegation for all
PCC's LSPs SHOULD also be supported.
A PCC implementation SHOULD allow the operator to specify delegation 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 primary PCE's LSPs can be delegated when
the primary PCE fails. 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
PCEP session configuration and information in the PCEP MIB module PCEP session configuration and information in the PCEP MIB module
SHOULD be extended to include advertised stateful capabilities, SHOULD be extended to include advertised stateful capabilities,
synchronization status, and delegation status (at the PCC list PCEs synchronization status, and delegation status (at the PCC list PCEs
with delegated LSPs). with delegated LSPs).
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
PCEP protocol extensions defined in this document do not require any PCEP extensions defined in this document do not require any new
new mechanisms beyond those already defined in [RFC5440], mechanisms beyond those already defined in [RFC5440], Section 8.3.
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
protocol extensions defined in this document. In addition to extensions defined in this document. In addition to monitoring
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.
skipping to change at page 42, line 28 skipping to change at page 45, line 16
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 protocol extensions defined in this document do not put new PCEP extensions defined in this document do not put new requirements
requirements on other protocols. on other protocols.
9.6. Impact on Network Operation 9.6. Impact on Network Operation
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
protocol extensions defined in this document. extensions defined in this document.
Additionally, a PCEP implementation SHOULD allow a limit to be placed Additionally, a PCEP implementation SHOULD allow a limit to be placed
on the number of LSPs delegated to the PCE and on the rate of PCUpd on the number of LSPs delegated to the PCE and on the rate of PCUpd
and PCRpt messages sent by a PCEP speaker and processed from a peer. and PCRpt messages sent by a PCEP speaker and processed from a peer.
It SHOULD also allow sending a notification when a rate threshold is It SHOULD also allow sending a notification when a rate threshold is
reached. reached.
A PCC implementation SHOULD allow a limit to be placed on the rate of A PCC implementation SHOULD allow a limit to be placed on the rate of
LSP Updates to the same LSP to avoid signaling overload discussed in LSP Updates to the same LSP to avoid signaling overload discussed in
Section 10.3. Section 10.3.
skipping to change at page 44, line 15 skipping to change at page 47, line 7
either by spoofing messages or by compromising the PCE itself. either by spoofing messages or by 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 result in increased attack surface by placing A stateful session also results in an increased attack surface by
a requirement for the PCE to keep an LSP state replica for each PCC. placing a requirement for the PCE to keep an LSP state replica for
It is RECOMMENDED that PCE implementations provide a limit on each PCC. It is RECOMMENDED that PCE implementations provide a limit
resources a single PCC can occupy. A PCE implementing such a limit on resources a single PCC can occupy. A PCE implementing such a
MUST send a PCErr message with error-type 19 (invalid operation) and limit MUST send a PCNtf message with notification-type to be assigned
error-value 4 (indicating resource limit exceeded) upon receiving an by IANA (Stateful PCE resource limit exceeded) and notification-value
LSP state report causing it to exceed this threshold. to be assigned by IANA (Entering resource limit exceeded state) upon
receiving an LSP state report causing it to exceed this threshold.
Delegation of LSPs can create further strain on PCE resources and a 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. Acknowledgements 11. Contributing Authors
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 We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga,
Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky,
Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Ambrose Kwong, Ashwin Sampath and Calvin Ying for helpful comments
Sampath, Calvin Ying and Xian Zhang for helpful comments and and discussions.
discussions.
12. References 13. References
12.1. Normative References 13.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>. <http://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, <http://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 45, line 25 skipping to change at page 48, line 41
[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, <http://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, <http://www.rfc-editor.org/info/rfc5089>.
[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>.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <http://www.rfc-editor.org/info/rfc5511>. 2009, <http://www.rfc-editor.org/info/rfc5511>.
12.2. Informative References 13.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-pce-stateful-pce-app] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of a Stateful Path Zhang, X. and I. Minei, "Applicability of a Stateful Path
Computation Element (PCE)", draft-ietf-pce-stateful-pce- Computation Element (PCE)", draft-ietf-pce-stateful-pce-
app-04 (work in progress), April 2015. app-05 (work in progress), October 2015.
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-03 (work in ietf-pce-stateful-sync-optimizations-04 (work in
progress), October 2015. progress), November 2015.
[I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", draft-sivabalan-pce-disco-
stateful-03 (work in progress), January 2014.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", and throughput objectives in traffic engineering",
INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
skipping to change at page 47, line 15 skipping to change at page 50, line 20
[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>. <http://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, <http://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, <http://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>. <http://www.rfc-editor.org/info/rfc5394>.
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Individual Contributor
Email: edward.crabbe@gmail.com Email: edward.crabbe@gmail.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: inaminei@google.com Email: inaminei@google.com
 End of changes. 152 change blocks. 
425 lines changed or deleted 547 lines changed or added

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