draft-ietf-pce-stateful-pce-04.txt   draft-ietf-pce-stateful-pce-05.txt 
Network Working Group E. Crabbe Network Working Group E. Crabbe
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: November 9, 2013 Cisco Systems, Inc. Expires: January 1, 2014 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
May 8, 2013 June 30, 2013
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-04 draft-ietf-pce-stateful-pce-05
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 information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path synchronization or PCE control of timing and sequence of path
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 9, 2013. This Internet-Draft will expire on January 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 6 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 7
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 8
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16
5. Architectural Overview of Protocol Extensions . . . . . . . . 16 5. Architectural Overview of Protocol Extensions . . . . . . . . 17
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 17
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21
5.4.2. PCE-triggered State Synchronization . . . . . . . . . 25
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 26 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 27
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 27 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 28
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 28 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 29
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 28 5.5.5. Redelegation on PCE failure . . . . . . . . . . . . . 29
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 30
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 29 Request/Response . . . . . . . . . . . . . . . . . . . 30
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 30 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 32
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 31 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 33
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 33
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 32 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 32 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 34
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 33 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 35
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 36
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 34 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 37
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 37
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 35 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 35 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 38
7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 36 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 39
7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 40
7.2.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 38 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 41 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 41 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 44
7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 42 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 46
7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 43 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 47
7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 43 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 48
7.3. Optional TLVs for the LSPA Object . . . . . . . . . . . . 44 7.3.5. LSP State Database Version TLV . . . . . . . . . . . . 48
7.3.1. Tunnel ID TLV . . . . . . . . . . . . . . . . . . . . 44 7.3.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 49
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 44 7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 49
7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 44 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 49
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 45 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 50
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 45 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 50
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 46 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 51
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 52
9. Manageability Considerations . . . . . . . . . . . . . . . . . 47 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 52
9.1. Control Function and Policy . . . . . . . . . . . . . . . 47 8.8. LSP-SIG-TYPE field in the LSP object . . . . . . . . . . . 52
9.2. Information and Data Models . . . . . . . . . . . . . . . 48 9. Manageability Considerations . . . . . . . . . . . . . . . . . 53
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48 9.1. Control Function and Policy . . . . . . . . . . . . . . . 53
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48 9.2. Information and Data Models . . . . . . . . . . . . . . . 54
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 54
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 54
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 49 Components . . . . . . . . . . . . . . . . . . . . . . . . 54
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 55
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 55
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 55
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 56
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 50 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 56
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 12.2. Informative References . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP. [RFC5440] describes the Path Computation Element Protocol (PCEP.
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE, (PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for enabling computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP) characteristics. Traffic Engineering Label Switched Path (TE LSP) characteristics.
Extensions for support of GMPLS in PCEP are defined in Extensions for support of GMPLS in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
skipping to change at page 5, line 27 skipping to change at page 5, line 27
compliance with [RFC4657]. It includes mechanisms to effect LSP compliance with [RFC4657]. It includes mechanisms to effect LSP
state synchronization between PCCs and PCEs, delegation of control state synchronization between PCCs and PCEs, delegation of control
over LSPs to PCEs, and PCE control of timing and sequence of path over LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer. PCE, PCEP Peer.
This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [RFC4090]: MPLS TE This document uses the following terms defined in [RFC4090]: MPLS TE
Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.
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
the set of active paths and their reserved resources for its
computations. A stateful PCE might also retain information
regarding LSPs under construction in order to reduce churn and
resource contention. The additional state allows the PCE to
compute constrained paths while considering individual LSPs and
their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE
and PCC, and between cooperating PCEs.
Passive Stateful PCE: uses LSP state information learned from PCCs Passive Stateful PCE: uses LSP state information learned from PCCs
to optimize path computations. It does not actively update LSP to optimize path computations. It does not actively update LSP
state. A PCC maintains synchronization with the PCE. state. A PCC maintains synchronization with the PCE.
Active Stateful PCE: is an extension of Passive Stateful PCE, which Active Stateful PCE: is an extension of Passive Stateful PCE, in
utilizes the Delegation mechanism to update LSP parameters in which the PCE may issue recommendations to the network. For
those PCCs that delegated control over their LSPs to the PCE. example, an active stateful PCE may utilize the Delegation
mechanism to update LSP parameters in those PCCs that delegated
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 who owns the PCE state for the LSP has the right to
delegate it. An LSP is owned by a single PCC at any given point delegate it. An LSP is owned by a single PCC at any given point
in time. in time.
Revocation An operation performed by a PCC on a previously delegated Revocation An operation performed by a PCC on a previously delegated
LSP. Revocation revokes the rights granted to the PCE in the LSP. Revocation revokes the rights granted to the PCE in the
delegation operation. delegation operation.
Delegation Timeout Interval: when a PCEP session is terminated, a Redelegation Timeout Interval: when a PCEP session is terminated, a
PCC waits for this time period before revoking LSP delegation to a PCC waits for this time period before revoking LSP delegation to a
PCE. The delegation timeout interval is a PCC-local value that PCE and attempting to redelegate LSPs associated with the
can be either operator-configured or dynamically computed by the terminated PCEP session to an alternate PCE. The Redelegation
PCC based on local policy. Timeout Interval is a PCC-local value that can be either operator-
configured or dynamically computed by the PCC based on local
policy.
State Timeout Interval: when a PCEP session is terminated, a PCC
waits for this time period before flushing LSP state associated
with that PCEP session and reverting to operator-defined default
parameters. The state will not be flushed in two cases: a) the
LSP is redelegated to another PCE before the expiration of the
State Timeout Interval or b)the PCC makes changes to the LSP
state. The State Timeout Interval is a PCC-local value that can
be either operator-configured or dynamically computed by the PCC
based on local policy. The State Timeout Interval value SHOULD be
greater than or equal to the Redelegation Timeout Interval value
in order to allow for redelegation of LSPs without unnecessary
churn in or loss of state.
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 and set by a PCE, etc.) Admin Status, LSP attributes configured and set by a PCE, etc.)
from a PCC to a PCE. 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.
LSP Priority: a specific pair of MPLS setup and hold priority values LSP Priority: a specific pair of MPLS setup and hold priority values
skipping to change at page 6, line 41 skipping to change at page 7, line 24
Within this document, PCE-PCE communications are described by having Within this document, PCE-PCE communications are described by having
the requesting PCE fill the role of a PCC. This provides a saving in the requesting PCE fill the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
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
Editor's note: the content in this section is duplicated in
[I-D.zhang-pce-stateful-pce-app]. To avoid loss of information, the
use cases will be removed from this document only after
[I-D.zhang-pce-stateful-pce-app] becomes a working group document.
In the meantime, changes and updates to the use cases are reflected
in [I-D.zhang-pce-stateful-pce-app].
3.1. Motivation 3.1. Motivation
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful showcasing scenarios that benefit from the deployment of a stateful
PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments. PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments.
3.1.1. Background 3.1.1. Background
Traffic engineering has been a goal of the MPLS architecture since Traffic engineering has been a goal of the MPLS architecture since
its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209] engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis; total reserved capacity by traffic class on a per interface basis;
individual LSP state is available only locally on each LER for it's individual LSP state is available only locally on each LER for its
own LSPs. In most cases, this makes good sense, as distribution and own LSPs. In most cases, this makes good sense, as distribution and
retention of total LSP state for all LERs within in the network would retention of total LSP state for all LERs within in the network would
be prohibitively costly. be prohibitively costly.
Unfortunately, this visibility in terms of global LSP state may Unfortunately, this visibility in terms of global LSP state may
result in a number of issues for some demand patterns, particularly result in a number of issues for some demand patterns, particularly
within a common setup and hold priority. This issue affects online within a common setup and hold priority. This issue affects online
traffic engineering systems. traffic engineering systems.
A sufficiently over-provisioned system will by definition have no A sufficiently over-provisioned system will by definition have no
skipping to change at page 7, line 38 skipping to change at page 8, line 28
[RFC4655] defines a stateful PCE to be one in which the PCE maintains [RFC4655] defines a stateful PCE to be one in which the PCE maintains
"strict synchronization between the PCE and not only the network "strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network." set of computed paths and reserved resources in use in the network."
[RFC4655] also expressed a number of concerns with regard to a [RFC4655] also expressed a number of concerns with regard to a
stateful PCE, specifically: stateful PCE, specifically:
o Any reliable synchronization mechanism would result in significant o Any reliable synchronization mechanism would result in significant
control plane overhead control plane overhead
o Out-of-band ted synchronization would be complex and prone to race o Out-of-band TED synchronization would be complex and prone to race
conditions conditions
o Path calculations incorporating total network state would be o Path calculations incorporating total network state would be
highly complex highly complex
In general, stress on the control plane will be directly proportional In general, stress on the control plane will be directly proportional
to the size of the system being controlled and the tightness of the to the size of the system being controlled and the tightness of the
control loop, and indirectly proportional to the amount of over- control loop, and indirectly proportional to the amount of over-
provisioning in terms of both network capacity and reservation provisioning in terms of both network capacity and reservation
overhead. overhead.
skipping to change at page 18, line 33 skipping to change at page 19, line 5
The PCEP protocol extensions for stateful PCEs MUST NOT be used if The PCEP protocol extensions for stateful PCEs MUST NOT be used if
one or both PCEP Speakers have not included the Stateful PCE one or both PCEP Speakers have not included the Stateful PCE
Capability TLV in their respective OPEN message. If the PCEP Capability TLV in their respective OPEN message. If the PCEP
Speakers support the extensions of this draft, then a PCErr with code Speakers support the extensions of this draft, then a PCErr with code
"Stateful PCE capability not negotiated" (see Section 8.4) will be "Stateful PCE capability not negotiated" (see Section 8.4) will be
generated and the PCEP session will be terminated. generated and the PCEP session will be terminated.
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)', "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this
otherwise a PCErr with code "Delegation not negotiated" (see is not the case and LSP delegation or LSP update operations are
Section 8.4) will be generated. Note that even if the update attempted, then a PCErr with code "Delegation not negotiated" (see
Section 8.4) SHOULD be generated. Note that even if the update
capability has not been negotiated, a PCE can still receive LSP capability has not been negotiated, a PCE can still receive LSP
Status Reports from a PCC and build and maintain an up to date view Status Reports from a PCC and build and maintain an up to date view
of the state of the PCC's LSPs. of the state of the PCC's LSPs.
5.4. State Synchronization 5.4. 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]).
skipping to change at page 19, line 9 skipping to change at page 19, line 30
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 negotiated stateful PCEP capabilities and PCC's local determined by negotiated 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. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV
in this case. in this case. If both PCEP speakers had set the INCLUDE-DB-VERSION
Flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV, then the LSP-
DB-VERSION TLV MUST be included and contain the PCC's latest LSP
State Database version.
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.
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 to the PCE and terminate state transfer, it MUST send a PCErr message to the PCE and terminate
the session using the PCEP session termination procedure. the session using the PCEP session termination procedure.
In the event of a PCC resetting the session during resynchronization, In the event of a PCC resetting the session during synchronization,
the PCE MUST clean up state it received from this PCC. Session the PCE MUST clean up state it received from this PCC. Session
reestablishment MUST be re-attempted per the procedures defined in reestablishment MUST be re-attempted per the procedures defined in
[RFC5440]. [RFC5440].
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 synchronization messages. It MUST respond with a PCErr message
indicating "PCRpt error" (see Section 8.4) if it encounters a problem indicating "PCRpt error" (see Section 8.4) if it encounters a problem
with the LSP State Report it received from the PCC. Either the PCE with the LSP State Report it received from the PCC. Either the PCE
or the PCC MAY terminate the session if the PCE encounters a problem or the PCC MAY terminate the session if the PCE encounters a problem
during the synchronization. during the synchronization.
skipping to change at page 22, line 27 skipping to change at page 22, line 50
Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object.
If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN
Object and the TLV values match, the PCC MAY skip State Object and the TLV values match, the PCC MAY skip State
Synchronization. Otherwise, the PCC MUST perform State Synchronization. Otherwise, the PCC MUST perform State
Synchronization. If the PCC attempts to skip State Synchronization Synchronization. If the PCC attempts to skip State Synchronization
(i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC), (i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC),
the PCE MUST send back a PCError with Error-type 20 Error-value 2 the PCE MUST send back a PCError with Error-type 20 Error-value 2
'LSP Database version mismatch', and close the PCEP session. 'LSP Database version mismatch', and close the PCEP session.
If state synchronization is required, then after the Initialization If state synchronization is required, then prior to completing the
phase has completed, the PCE MUST mark any LSPs in the LSP database Initialization phase, the PCE MUST mark any LSPs in the LSP database
that were previously reported by the PCC as stale. When the PCC that were previously reported by the PCC as stale. When the PCC
reports an LSP during state synchronization, if the LSP already reports an LSP during state synchronization, if the LSP already
exists in the LSP database, the PCE MUST update the LSP database and exists in the LSP database, the PCE MUST update the LSP database and
clear the stale marker from the LSP. When it has finished state clear the stale marker from the LSP. When it has finished state
synchronization, the PCC MUST immediately send a PCRpt message synchronization, the PCC MUST immediately send a PCRpt message
containing a state report with an LSP object containing an PLSP-ID of containing a state report with an LSP object containing an PLSP-ID of
0 and with the SYNC flag set to 0 (see Section 5.4). This state 0 and with the SYNC flag set to 0 (see Section 5.4). This state
report indicates to the PCE that state synchronization has completed. report indicates to the PCE that state synchronization has completed.
On receiving this state report, the PCE MUST purge any LSPs from the On receiving this state report, the PCE MUST purge any LSPs from the
LSP database that are still marked as stale. LSP database that are still marked as stale.
skipping to change at page 25, line 29 skipping to change at page 25, line 29
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Report) | | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Report) | | LSP State Report)
|------PCRpt,SYNC=0----->| |------PCRpt,SYNC=0----->|
| | | |
Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent
from PCC from PCC
5.4.2. PCE-triggered State Synchronization
Because the accuracy of the computations performed by the PCE is tied
to the accuracy of the view the PCE has on the state of the LSPs, it
can be beneficial to be able to resynchronize this state even after
the session has established. The PCE may use this approach to
continuously sanity check its state against the network, or to
recover from error conditions without having to tear down sessions.
To trigger a resynchronization with a PCC, the PCE MUST first mark
any LSPs in the LSP database that were previously reported by the PCC
as stale and then send a PCUpd for an LSP object containing a PLSP-ID
of 0 and with the SYNC flag set to 1. This PCUpd message is the
trigger for the PCC to enter the synchronization phase as described
in Section 5.4.1 and start sending PCRpt messages. After the receipt
of the end-of-synchronization marker, the PCE will purge LSPs which
were not refreshed.
5.5. LSP Delegation 5.5. LSP Delegation
If during Capability negotiation both the PCE and the PCC have If during Capability negotiation 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 Synchronization phase. including during the State Synchronization phase.
LSP Delegation is controlled by operator-defined policies on a PCC. LSP Delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually - different LSPs may be delegated to LSPs are delegated individually - different LSPs may be delegated to
different PCEs. An LSP is delegated to at most one PCE at any given different PCEs. An LSP is delegated to at most one PCE at any given
point in time. The delegation policy, when all PCC's LSPs are point in time. The delegation policy, when all PCC's LSPs are
delegated to a single PCE at any given time, SHOULD be supported by delegated to a single PCE at any given time, SHOULD be supported by
all delegation-capable PCCs. Conversely, the policy revoking the all delegation-capable PCCs. Conversely, the policy revoking the
delegation for all PCC's LSPs SHOULD also be supported 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 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. update the LSP's state. A PCC may revoke LSP delegation at any time.
Delegation, Revocation, and Return are done individually for each Delegation, Revocation, and Return are done individually for each
LSP. LSP.
In the event of an delegation being rejected or returned by a PCE, In the event of an delegation being rejected or returned by a PCE,
the PCC should react based on local policy. It could either retry the PCC should react based on local policy. It can, for example,
delegating to the same PCE using an exponentially increasing timer or either retry delegating to the same PCE using an exponentially
delegate to an alternate PCE. increasing timer or delegate to an alternate PCE.
5.5.1. Delegating an LSP 5.5.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. A PCE confirms the delegation when it sends the State Report to 1. If the PCE does not accept the LSP Delegation, it
first LSP Update Request for the delegated LSP to the PCC by setting MUST immediately respond with an empty LSP Update Request which has
the Delegate flag to 1. Note that a PCE does not immediately confirm the Delegate flag set to 0. If the PCE accepts the LSP Delegation,
to the PCC the acceptance of LSP Delegation; Delegation acceptance is it confirms this when it sends the first LSP Update Request for the
confirmed when the PCE wishes to update the LSP via the LSP Update delegated LSP to the PCC by setting the Delegate flag to 1 (note that
Request. If a PCE does not accept the LSP Delegation, it MUST this may occur at a later time).
immediately respond with an empty LSP Update Request which has the
Delegate flag set to 0.
The delegation sequence is shown in Figure 9. The delegation sequence is shown in Figure 9.
+-+-+ +-+-+ +-+-+ +-+-+
|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 26, line 47 skipping to change at page 27, line 15
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.5.2. Revoking a Delegation
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. If the PCC has received but not yet acted on provided by the PCE, but to avoid traffic loss, it SHOULD do so in a
PCUpd messages from the PCE for the LSP whose delegation is being 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
revoked, then it SHOULD ignore these PCUpd messages when processing revoked, then it SHOULD ignore these PCUpd messages when processing
the message queue. Any further PCUpd messages are handled according the message queue. All effects of all messages for which processing
to the PCUpd procedures described in this document. started before the revocation took place MUST be allowed to complete
and the result MUST be given the same treatment as any LSP that had
been previously delegated to the PCE (e.g. the state MAY be
immediately cleared). Any further PCUpd messages from the PCE are
handled according to the PCUpd procedures described in this document.
If a PCEP session with the PCE to which the LSP is delegated exists If a PCEP session with the PCE to which the LSP is delegated exists
in the UP state during the revocation, the PCC MUST notify that PCE in the UP state during the revocation, the PCC MUST notify that PCE
by sending an LSP State Report with the Delegate flag set to 0, as by sending an LSP State Report with the Delegate flag set to 0, as
shown in Figure 10. shown in Figure 10.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 27, line 30 skipping to change at page 27, line 51
|---PCRpt, Delegate=0--->| PCC revokes delegation |---PCRpt, Delegate=0--->| PCC revokes delegation
| | | |
Figure 10: Revoking a Delegation Figure 10: 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 indicating "LSP is LSP will result in the PCC sending a PCErr message indicating "LSP is
not delegated" (see Section 8.4). not delegated" (see Section 8.4).
When a PCC's PCEP session with a PCE terminates, the PCC MUST wait a When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
time interval specified in 'Delegation Timeout Interval' before MUST wait the time interval specified in Redelegation Timeout
revoking LSP delegations to the PCE. If a new PCEP session with the Interval before revoking LSP delegations to that PCE and attempting
PCE can be established before the 'Delegation Timeout' timer expires, to redelegate LSPs to an alternate PCE. If a PCEP session with the
LSP delegations to the PCE remain intact. If, after expiry of the original PCE can be reestablished before the Redelegation Timeout
'Delegation Timeout' timer, a PCC can not delegate an LSP to another Interval timer expires, LSP delegations to the PCE remain intact.
PCE (for example, if a PCC is not connected to any active stateful
PCE or if no connected active stateful PCE accepts the delegation), Likewise, when a PCC's PCEP session with a PCE terminates
the PCC SHALL flush any LSP state set by the PCE. unexpectedly, the PCC MUST wait for the State Timeout Interval before
flushing any LSP state associated with that PCE. Note that the State
Timeout Interval timer may expire before the PCC has redelegated the
LSPs to another PCE, for example if a PCC is not connected to any
active stateful PCE or if no connected active stateful PCE accepts
the delegation. In this case, the PCC SHALL flush any LSP state set
by the PCE upon expiration of the State Timeout Interval and revert
to operator-defined default parameters. This operation SHOULD be
done in a make-before-break fashion.
The State Timeout Interval SHOULD be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact).
If State Synchronization Avoidance is enabled, a PCC MUST increment If State Synchronization Avoidance is enabled, a PCC MUST increment
its LSP State Database version when the 'Delegation Timeout' timer its LSP State Database version when the 'Redelegation Timeout
expires. Interval' timer expires.
5.5.3. Returning a Delegation 5.5.3. Returning a Delegation
A PCE that no longer wishes to update an LSP's parameters SHOULD A PCE that no longer wishes to update an LSP's parameters SHOULD
return the LSP delegation back to the PCC by sending an empty LSP return the LSP delegation back to the PCC by sending an empty LSP
Update Request which has the Delegate flag set to 0. Note that in Update Request which has the Delegate flag set to 0. Note that in
order to keep a delegation, the PCE MUST set the Delegate flag to 1 order to keep a delegation, the PCE MUST set the Delegate flag to 1
on each LSP Update Request sent to the PCC. on each LSP Update Request sent to the PCC.
+-+-+ +-+-+ +-+-+ +-+-+
skipping to change at page 28, line 20 skipping to change at page 29, line 5
| . | | . |
| . | | . |
| . | | . |
|<--PCUpd, Delegate=0----| Delegation returned |<--PCUpd, Delegate=0----| Delegation returned
| | | |
|---PCRpt, Delegate=0--->| No delegation for LSP |---PCRpt, Delegate=0--->| No delegation for LSP
| | | |
Figure 11: Returning a Delegation Figure 11: Returning a Delegation
If a PCC can not 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 Delegation Timeout Interval and will time out within a configurable Redelegation Timeout Interval and
the PCC MUST flush any LSP state set by a PCE. the PCC MUST flush any LSP state set by a PCE at the expiration of
the State Timeout Interval.
5.5.4. Redundant Stateful PCEs 5.5.4. Redundant Stateful PCEs
Note that a PCE may not have any delegated LSPs: in a redundant Note that a PCE may not have any delegated LSPs: in a redundant
configuration where one PCE is backing up another PCE, the backup PCE configuration where one PCE is backing up another PCE, the backup PCE
may have only a subset of LSPs delegated to it. The backup PCE does may have only a subset of LSPs delegated to it. The backup PCE does
not update any LSPs that are not delegated to it, but receives all not update any LSPs that are not delegated to it, but receives all
LSP State Reports from a PCC. When the primary PCE for a given LSP LSP State Reports from a PCC. When the primary PCE for a given LSP
set fails, after expiry of the delegation timeout, that PCC will set fails, after expiry of the Redelegation Timeout Interval, the PCC
delegate to the redundant PCE all LSPs that had been previously SHOULD delegate to the redundant PCE all LSPs that had been
delegated to the failed PCE. previously delegated to the failed PCE. Assuming that the State
Timeout Interval had been configured to be larger than the
Redelegation Timeout Interval (as recommended), this delegation
change will not cause any changes to the LSP parameters.
5.5.5. Redelegation on PCE failure
On failure, the goal is to: 1) avoid any traffic loss on the LSPs
that were updated by the PCE that crashed 2) minimize the churn in
the network in terms of ownership of the LSPs, 3) not leave any
"orphan" (undelegated) LSPs and 4) be able to control when the state
that was set by the PCE can be changed or purged. The values chosen
for the Redelegation Timeout and State Timeout values affect the
ability to accomplish these goals.
This section summarizes the behaviour with regards to LSP delegation
and LSP state on a PCE failure.
If the PCE crashses but recovers within the Redelegation Timeout,
both the delegation state and the LSP state are kept intact.
If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is flushed, which may
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
PCE state indefinetely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss.
If there is a hot-standby PCE, the Redelegation Timeout may be set to
0 through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the
hot-standby PCE. Assuming the State Timeout Interval is larger than
the Redelegation Timeout, the LSP state will be kept intact.
5.6. LSP Operations 5.6. LSP Operations
5.6.1. Passive Stateful PCE Path Computation Request/Response 5.6.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
skipping to change at page 31, line 14 skipping to change at page 32, line 39
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) and 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 A PCE sends an LSP Update Request carried on a PCUpd message to the
PCC. The LSP Update Request contains a variety of objects that PCC. The LSP Update Request contains a variety of objects that
specify the set of constraints and attributes for the LSP's path. specify the set of constraints and attributes for the LSP's path.
Additionally, the PCC may specify the urgency of such request by Each LSP Update Request has a unique identifier, the SRP-ID-number,
assigning a request priority. A single PCUpd message MAY contain carried in the SRP (Stateful PCE Request Parameters) Object described
multiple LSP Update Requests. in Section 7.2. The SRP-ID-number is used to correlate errors and
state reports to LSP Update Requests. A single PCUpd message MAY
contain multiple LSP Update Requests.
Upon receiving a PCUpd message the PCC starts to 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
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Pending'.If the PCC decides that indicating that the LSP's status is 'Pending'. If the PCC decides
the LSP parameters proposed in the PCUpd message are unacceptable, it that the LSP parameters proposed in the PCUpd message are
MAY revoke the delegation. Error reporting for this condition will unacceptable, it MUST report this error by including the LSP-ERROR-
be defined in a future version of this draft. CODE TLV (Section 7.3.3) with LSP error value="Unacceptable PCUpd
parameters" in the LSP object in the PCRpt message to the PCE. Based
on local policy, it MAY react further to this error by revoking the
delegation. If the PCC receives a PCUpd message for an LSP object
identified with a PLSP-ID that does not exist on the PCC, it MUST
generate a PCErr with error type 19, error value 3, "Unknown PLSP-ID"
(see Section 8.4).
Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
to the PCE, indicating that the LSP's status is 'Up'. If the LSP to the PCE, indicating that the LSP's status is 'Up'. If the LSP
could not be set up, the PCC sends an LSP State Report indicating could not be set up, the PCC sends an LSP State Report indicating
that the LSP is 'Down' and stating the cause of the failure. A PCC that the LSP is 'Down' and stating the cause of the failure. A PCC
may choose to compress LSP State Reports to only reflect the most up may choose to compress LSP State Reports to only reflect the most up
to date state, as discussed in the previous section. to date state, as discussed in the previous section.
A PCC sends each LSP State Report to each stateful PCE that is A PCC sends 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
MUST include the SRP-ID-number from the PCUpd. This provides
correlation of requests and errors and acknowledgement of state
processing. The PCC may choose to compress state when processing
PCUpd. In this case, receipt of a higher SRP-ID-number implicitly
acknowledges processing all the earlier updates for the specific LSP.
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.7. 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 draft.
5.8. Transport 5.8. Transport
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].
State cleanup after session termination, as well as session setup
failures will be described in a later version of this document.
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 that can
be either mandatory or optional. An object is said to be mandatory be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to in a PCEP message when the object must be included for the message to
be considered valid. For each PCEP message type, a set of rules is 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. defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object An implementation MUST form the PCEP messages using the object
ordering specified in this document. ordering specified in this document.
skipping to change at page 32, line 31 skipping to change at page 34, line 20
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 set to [TBD]. for the PCRpt message is set to [TBD].
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> ::= <LSP> <state-report-list> ::= <state-report>[<state-report-list>]
[<path-list>]
Where: <state-report> ::= <SRP>
<LSP>
<path>
<path-list>::=<path>[<path-list>] Where:
<path> is defined in [RFC5440] and extended by PCEP extensions.
Where: The SRP object (see Section 7.2) is mandatory, and it MUST be
<path-list> is defined in [RFC5440] and extended by PCEP extensions. included for each LSP State Report in the PCRpt message. The value
of the SRP-ID-number in the SRP Object MUST be the same as that sent
in the PCUpd message that triggered the state that is reported, or
the reserved value 0x00000000 if the state is not as a result of
processing a PCUpd message. If the PCC compressed several PCUpd
messages for the same LSP by only processing the latest one, then it
should use the SRP-ID-number of that request. If the SRP object is
missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=[TBD] (SRP object
missing). No state compression is allowed for state reporting. The
PCC MUST explicitly report state changes (including removal) for
paths it manages.
The LSP object (see Section 7.2) is mandatory, and it MUST be The LSP object (see Section 7.3) is mandatory, and it MUST be
included in each LSP State Report on the PCRpt message. If the LSP included in each LSP State Report on the PCRpt message. If the LSP
object is missing, the receiving PCE MUST send a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP
object missing). object missing).
The path descriptor is described in separate technology-specific If the LSP transitioned to non-operational state, the PCC SHOULD
documents according to the LSP type. include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE.
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 PCRpt message is set to [TBD]. the PCUpd message is set to [TBD].
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>
<udpate-request-list> <udpate-request-list>
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <LSP> <update-request-list> ::= <update-request>[<update-request-list>]
[<path-list>]
Where: <update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <ERO><attribute-list>
<path-list>::=<path>[<path-list>] Where:
Where: <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
<path> is defined in technology-specific documents per LSP type
There is one mandatory object that MUST be included within each LSP There are three mandatory objects that MUST be included within each
Update Request in the PCUpd message: the LSP object (see LSP Update Request in the PCUpd message: the SRP Object (see
Section 7.2). If the LSP object is missing, the receiving PCE MUST Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
send a PCErr message with Error-type=6 (Mandatory Object missing) and defined in [RFC5440]. If the SRP object is missing, the receiving
Error-value=[TBD] (LSP object missing). PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=[TBD] (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=[TBD] (LSP
object missing). If the ERO object is missing, the receiving PCC
MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=[TBD] (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
set for the LSP. A PCC MAY set missing parameters from locally 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 use the make-before-break procedures described in The PCC SHOULD use the make-before-break procedures described in
[RFC3209] in the re-signaling operation. When traffic switchover to [RFC3209] in the re-signaling operation. During this process, two
the updated path and teardown of the old path are under the control paths will briefly co-exist. The PCC MUST send separate PCRpt
of PCC, no extensions are necessary. The PCC MUST send a PCrpt messages for each, identified by the LSP-IDENTIFIERS TLV. When the
message with the new path attributes to the PCE only after traffic old path is torn down after the head end switches over the traffic,
has been switched over. In some situations, it may be desirable for this event MUST be reported by sending a PCRpt message with the LSP-
the PCE to control the timing of traffic switchover. This mode of IDENTIFIERS-TLV or the old path, and the R bit set. Thus, a make-
operation and the extensions necessary to support it are left for before-break operation will typically result in at least two PCRpt
further study. In either case, resignaling of the path, label messages, one for the new path and one for the removal of the old
allocation, and RSVP id allocations are under the control of the PCC. path (more messages may be possible if intermediate states are
reported).
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request to indicate the resulting state of the LSP in the network. A Request it processed to indicate the resulting state of the LSP in
PCC MAY respond with multiple LSP State Reports to report LSP setup the network (even if this processing did not result in changing the
progress of a single LSP. state of the LSP). The SRP-ID-number included in the PCRpt MUST
match that in the PCUpd. A PCC MAY respond with multiple LSP State
If the rate of PCUpd messages sent to a PCC for the same target LSP Reports to report LSP setup progress of a single LSP. In that case,
exceeds the rate at which the PCC can signal LSPs into the network, the SRP-ID-number MUST be included while the state of the LSP is
the PCC MAY perform state compression and only re-signal the last "pending", afterwards the reserved value 0x00000000 SHOULD be used..
modification in its queue.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
Note also that it's up to the PCE to handle inter-LSP dependencies; If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network,
the PCC MAY perform state compression and only signal the last
modification in its queue, as the last PCUpd contains the most up-to-
date desired state for the LSP. If two PCUpd arrive for the same LSP
in quick succession and the PCC started the signaling of the changes
relevant to the first PCUpd, then it MUST wait until the signaling
finishes (and report the new state via a PCRpt) before attempting to
apply the changes indicated in the second PCUpd.
Note also that it is up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP 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. If the PCUpd cannot be satisfied (for
example due to unsupported object or TLV), the PCC MUST respond with example due to unsupported object or TLV), the PCC MUST respond with
an PCErr message an PCErr message
6.3. The PCReq Message 6.3. The PCErr Message
If the stateful PCE capability has been negotiated on the PCEP
session, the PCErr message MUST include the SRP object. If the error
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
it is unsolicited, the SRP-ID-number MUST be the reserved value
0x00000000.
6.4. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see A PCC MAY include the LSP object in the PCReq message (see
Section 7.2) if stateful PCE capability has been negotiated on a PCEP Section 7.3) if the stateful PCE capability has been negotiated on a
session between the PCC and a PCE. The extensions to the PCReq PCEP session between the PCC and a PCE.
message are described in technology-specific documents for MPLS and
GMPLS.
6.4. The PCRep Message The definition of the PCReq message from [RFC5440] and
[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally
include the LSP object after the END-POINTS object. For illustration
purposes, the encoding from [RFC5440] will become:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>] <--- New Object
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
6.5. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see A PCE MAY include the LSP object in the PCRep message (see
(Section 7.2) if stateful PCE capability has been negotiated on a (Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was PCEP session between the PCC and the PCE and the LSP object was
included in the corresponding PCReq message from the PCC. The included in the corresponding PCReq message from the PCC.
extensions to the PCRep message are described in technology-specific
documents for MPLS and GMPLS. The definition of the PCRep message from [RFC5440] and
[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally
include the LSP object after the RP object. For illustration
purposes, the encoding from [RFC5440] will become:
<PCRep Message> ::= <Common Header>
<response-list>
Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>] <--- New Object
[<NO-PATH>]
[<attribute-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 MUST always be set to 0 on PCEP objects defined in this document MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST be ignored on receipt since these flags are
exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
skipping to change at page 35, line 47 skipping to change at page 39, line 18
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.
S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers,
the PCC will include the LSP-DB-VERSION TLV in each LSP Object. the PCC will include the LSP-DB-VERSION TLV in each LSP Object.
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.
Negotiation of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs and
procedures defined in this document.
7.1.2. LSP State Database Version TLV 7.1.2. LSP State Database Version TLV
LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN
Object when a PCEP Speaker wishes to determine if State Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. If Synchronization can be skipped when a PCEP session is restarted. If
sent from a PCE, the TLV contains the local LSP State Database sent from a PCE, the TLV contains the local LSP State Database
version from the last valid LSP State Report received from a PCC. If version from the last valid LSP State Report received from a PCC. If
sent from a PCC, the TLV contains the PCC's local LSP State Database sent from a PCC, the TLV contains the PCC's local LSP State Database
version, which is incremented each time the LSP State Database is version, which is incremented each time the LSP State Database is
updated. updated.
skipping to change at page 37, line 10 skipping to change at page 40, line 36
Figure 16: PREDUNDANCY-GROUP-ID TLV format Figure 16: PREDUNDANCY-GROUP-ID TLV format
The type of the TLV is [TBD] and it has a a variable length, which The type of the TLV is [TBD] and it has a a variable length, which
MUST be greater than 0. The value contains a node identifier that MUST be greater than 0. The value contains a node identifier that
MUST be unique in the network. The node identifier MAY be configured MUST be unique in the network. The node identifier MAY be configured
by an operator. If the node identifier is not configured by the by an operator. If the node identifier is not configured by the
operator, it can be derived from a PCC's MAC address or serial operator, it can be derived from a PCC's MAC address or serial
number. number.
7.2. LSP Object 7.2. SRP Object
The SRP (Stateful PCE Request Parameters) object MUST be carried
within each PCUpd and PCRpt message and MAY be carried within PCNtf
and PCEerr messages. The SRP object is used to correlate between
update requests sent by the PCE and the error reports and state
reports sent by the PCC. The P flag in the common object header of
the SRP object MUST be set to 0.
SRP Object-Class is [TBD].
SRP Object-Type is 1.
The format of the SRP object body is shown in Figure 17:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The SRP Object format
The SRP object body has a variable length and may contain additional
TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the
optional TLVs.
Flags (32 bits): None defined yet.
SRP-ID-number (32 bits): The SRP-ID-number value combined with the
source IP address of the PCC and the PCE uniquely identify the
operation that the PCE has requested the PCC to perform on a given
LSP. The SRP-ID-number is incremented each time a new request is
sent to the PCC, and may wrap around.
The values 0x00000000 and 0xFFFFFFFF are reserved.
Every request to update an LSP receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an
operation is requested from the PCE. Thus, for a given LSP there may
be more than one SRP-id-number unacknowledged at a given time. The
value of the SRP-ID-number is echoed back by the PCC in PCErr and
PCRpt messages to allow for correlation between requests made by the
PCE and errors or state reports generated by the PCC. If the error
or report were not as a result of a PCE operation (for example in the
case of a link down event), then the reserved value of 0x00000000 is
used instead. An SRP-ID-number is considered unacknowledged and
cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number
equal or higher for the same LSP. A PCRpt with state "Pending" is
not considered as an acknowledgement.
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. synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object
mirror RSVP state.
LSP Object-Class is [TBD]. LSP Object-Class is [TBD].
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 17: The format of the LSP object body is shown in Figure 18:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flags |R|O|S|D| | PLSP-ID | Flags | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Reserved | LSP-sig-type |
// Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The LSP Object format Figure 18: The LSP Object format
The LSP object body has a variable length and may contain additional
TLVs.
PLSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique PLSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique
PLSP-ID for each LSP that is constant for the life time of a PCEP PLSP-ID for each LSP that is constant for the life time of a PCEP
session. The mapping of the Symbolic Path Name to PLSP-ID is session. The mapping of the Symbolic Path Name to PLSP-ID is
communicated to the PCE by sending a PCRpt message containing the communicated to the PCE by sending a PCRpt message containing the
'Symbolic Path Name' TLV. All subsequent PCEP messages then address SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages then address
the LSP by the PLSP-ID. The values of 0 and 0xFFFF are reserved. the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are reserved.
Note that the PLSP-ID is a value that is constant for the life time
of the PCEP session, during which time for an RSVP-signaled LSP there
might be a different RSVP identifiers (LSP-id, tunnel-id) allocated
it.
Flags (12 bits): Flags (12 bits):
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 LSP State S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State
Report sent from a PCC during State Synchronization. The S Flag Report sent from a PCC during State Synchronization. The S Flag
MUST be set to 0 otherwise. MUST be set to 0 otherwise.
O (Operational - 1 bit): On PCRpt messages the O Flag indicates the R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the
LSP status. Value of '1' means that the LSP is operational, i.e. LSP has been removed from the PCC and the PCE SHOULD remove all
it is either being signaled or it is active. Value of '0' means state from its database. Upon receiving an LSP State Report with
that the LSP is not operational, i.e it is de-routed and the PCC the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
is not attempting to set it up. On PCUpd messages the flag remove all state for the path identified by the LSP Identifiers
indicates the desired status for the LSP. Value of '1' means that TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is
the desired LSP state is operational, value of '0' means that the used, the PCE SHOULD remove all state for the PLSP-ID from its
target LSP should be non-operational. Setting the LSP status from database.
the PCE SHALL NOT override the operator: if a pce-controlled LSP
has been configured to be non-operational, setting the LSP's
status to '1' from an PCE will not make it operational.
R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates
LSP has been removed from the PCC. Upon receiving an LSP State the PCC's target operational status for this LSP. On PCUpd
Report with the R Flag set to 1, the PCE SHOULD remove all state messages, the A Flag indicates the LSP status that the PCE desires
related to the LSP from its database. for this LSP. In both cases, a value of '1' means that the
desired operational state is active, and a value of '0' means that
the desired operational state is inactive. A PCC ignores the A
flag on a PCUpd message unless the operator's policy allows the
PCE to control the corresponding LSP's administrative state.
O(Operational - 3 bits): On PCRpt messages, the O Field represents
the operational status of the LSP.
The following values are defined:
0 - DOWN: not active.
1 - UP: signalled.
2 - ACTIVE: up and carrying traffic.
3 - GOING-DOWN: LSP is being torn down, resources are being
released.
4 - GOING-UP: LSP is being signalled.
5-7 - Reserved: these values MUST be set to 0 on transmission and
MUST be ignored on receipt.
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 LSP-sig-type (8 bits) - identifies the method used for signaling the
following sections and in separate technology-specific documents. LSP. If a PCEP speaker receives an LSP object with LSP-sig-type that
had not been previously negotiated, a PCErr with error type 19, error
value 5, "Unsupported LSP signaling type", (see Section 8.4) MUST be
sent. If there is a mismatch in the LSP signaling type for a
particular LSP between the PCEP speakers, a PCErr with error type 19,
error value 4, "Mismatched LSP signaling type" (see Section 8.4) MUST
be sent by the party identifying the mismatch.
7.2.1. LSP Identifiers TLVs Optional TLVs that may be included in the LSP Object are described in
the following sections.
Whenever the value of an LSP identifier changes, a PCC MUST send out 7.3.1. LSP Identifiers TLVs
an LSP State Report, where the LSP Object carries the LSP Identifiers
TLV that contains the new value. The LSP Identifiers TLV MUST also The LSP Identifiers TLV MUST be included in the LSP object in PCRpt
be included in the LSP object during state synchronization. There messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will
are two LSP Identifiers TLVs, one for IPv4 and one for IPv6. generate an error with error-type 6 (mandatory object missing) and
Error Value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
The LSP Identifiers TLV MAY be included in the LSP object in PCUpd
messages for RSVP-signaled LSPs. The special value of all zeros for
this TLV is used to refer to all paths pertaining to a particular
PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one
for IPv6.
It is the responsibility of the PCC to send to the PCE the
identifiers for each RSVP incarnation of the tunnel. For exmple, in
a make-before-break scenario, the PCC MUST send a separate PCRpt for
the old and for the reoptimized paths, and explicitly report removal
of any of these paths using the R bit in the LSP object.
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=12 | | Type=[TBD] | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: IPV4-LSP-IDENTIFIERS TLV format Figure 19: IPV4-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 12 octets. The type of the TLV is [TBD] and it has a fixed length of 12 octets.
The value contains the following fields: 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. Object.
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. 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 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.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l 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 40, line 29 skipping to change at page 45, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Extended Tunnel ID | | Extended Tunnel ID |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: IPV6-LSP-IDENTIFIERS TLV format Figure 20: IPV6-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 36 octets. The type of the TLV is [TBD] and it has a fixed length of 36 octets.
The value contains the following fields: 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
skipping to change at page 41, line 9 skipping to change at page 46, line 25
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa). 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.
7.2.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 a path'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 State Report
when during a given PCEP session an LSP is first reported to a PCE. when during a given PCEP session an LSP is first reported to a PCE.
skipping to change at page 41, line 41 skipping to change at page 47, 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 (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: SYMBOLIC-PATH-NAME TLV format Figure 21: SYMBOLIC-PATH-NAME TLV format
The type of the TLV is [TBD] and it has a variable length, which MUST The type of the TLV is [TBD] and it has a variable length, which MUST
be greater than 0. be greater than 0.
7.2.3. LSP Error Code TLV 7.3.3. LSP Error Code TLV
If an LSP Update Request failed, an LSP State Report MUST be sent to The LSP Error code TLV is an optional TLV for use in the LSP object
all connected stateful PCEs. LSP State Report MUST contain the LSP to convey error information. When an LSP Update Request fails, an
Error Code TLV, indicating the cause of the failure. 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
the failure. Similarly, when a PCRpt is sent as a result of an LSP
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD
be included to indicate the reason for the transition.
The format of the LSP-ERROR-CODE TLV is shown in the following The format of the LSP-ERROR-CODE TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LSP-ERROR-CODE TLV format Figure 22: LSP-ERROR-CODE TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets. The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value contains the error code that indicates the cause of the The value contains an error code that indicates the cause of the
failure. Error codes will be defined in a later revision of this failure.
document.
7.2.4. RSVP ERROR_SPEC TLVs
If the set up of an LSP failed at a downstream node which returned an
ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP
State Report. Depending on whether RSVP signaling was performed over
IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or
an IPV6-ERROR_SPEC TLV.
The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following The following LSP Error Codes are defined:
figure:
0 1 2 3 Value Meaning
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 1 Unknown reason
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 Limit reached for PCE-controlled LSPs
| Type=[TBD] | Length=8 | 3 Too many pending LSP update requests
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 Unacceptable PCUpd parameters
| | 5 Internal error
+ IPv4 ERROR_SPEC object (rfc2205) + 6 LSP administratively brought down
| | 7 LSP preempted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 RSVP signaling error
Figure 22: IPV4-RSVP-ERROR-SPEC TLV format 7.3.4. RSVP Error Spec TLV
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
The value contains the RSVP IPv4 ERROR_SPEC object defined in to carry RSVP error information. It includes the RSVP ERROR_SPEC or
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned
in [RFC2205], [RFC3209] and [RFC3473].. to the PCC from a downstream node. If the set up of an LSP fails at
a downstream node which returned an ERROR_SPEC to the PCC, the PCC
SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object.
The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following The format of the RSVP-ERROR-SPEC TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=20 | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IPv6 ERROR_SPEC object (rfc2205) // + RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: IPV6-RSVP-ERROR-SPEC TLV format Figure 23: RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a fixed length of 20 octets. The type of the TLV is [TBD] and it has a variable length. The value
The value contains the RSVP IPv6 ERROR_SPEC object defined in contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined object header.
in [RFC2205], [RFC3209] and [RFC3473].
7.2.5. LSP State Database Version TLV 7.3.5. LSP State Database Version TLV
The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP
object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which
covers state synchronization avoidance. The format of the TLV is covers state synchronization avoidance. The format of the TLV is
described in Section 7.1.2, where the details of its use in the OPEN described in Section 7.1.2, where the details of its use in the OPEN
message are listed. message are listed.
If State Synchronization Avoidance has been enabled on a PCEP session If State Synchronization Avoidance has been enabled on a PCEP session
(as described in Section 5.4.1) , a PCC MUST include the LSP-DB- (as described in Section 5.4.1) , a PCC MUST include the LSP-DB-
VERSION TLV in each LSP Object sent out on the session. If the TLV VERSION TLV in each LSP Object sent out on the session. If the TLV
skipping to change at page 43, line 44 skipping to change at page 49, line 19
(mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV
missing) and close the session. If State Synchronization Avoidance missing) and close the session. If State Synchronization Avoidance
has not been enabled on a PCEP session, the PCC SHOULD NOT include has not been enabled on a PCEP session, the PCC SHOULD NOT include
the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it
were it to receive one. were it to receive one.
Since a PCE does not send LSP updates to a PCC, a PCC should never Since a PCE does not send LSP updates to a PCC, a PCC should never
encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were
it to receive one from a PCE. it to receive one from a PCE.
7.2.6. Delegation Parameters TLVs 7.3.6. Delegation Parameters TLVs
Multiple delegation parameters, such as sub-delegation permissions, Multiple delegation parameters, such as sub-delegation permissions,
authentication parameters, etc. need to be communicated from a PCC to authentication parameters, etc. need to be communicated from a PCC to
a PCE during the delegation operation. Delegation parameters will be a PCE during the delegation operation. Delegation parameters will be
carried in multiple delegation parameter TLVs, which will be defined carried in multiple delegation parameter TLVs, which will be defined
in future revisions of this document. in future revisions of this document.
7.3. Optional TLVs for the LSPA Object 7.4. Optional TLVs for the LSPA Object
TLVs that may be included in the LSPA Object are described in the TLVs that may be included in the LSPA Object are described in the
following sections and in separate technology-specific documents. following sections and in separate technology-specific documents.
7.3.1. Tunnel ID TLV 7.4.1. Symbolic Path Name TLV
The Tunnel ID TLV MAY be included in the LSPA object.
The format of the TUNNEL TLV is shown in the following figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Tunnel-ID TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value contains a single field:
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 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.
7.3.2. Symbolic Path Name TLV
See section Section 7.2.2. See section Section 7.3.2.
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. PCEP Messages
This document defines the following new PCEP messages: This document defines the following new PCEP messages:
skipping to change at page 45, line 19 skipping to change at page 50, line 19
8.2. PCEP Objects 8.2. 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
Object-Type
1
8.3. LSP Object 8.3. LSP Object
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field of the LSP object. New values are to be assigned by Standards field of the LSP object. New values are to be assigned by Standards
Action [RFC5226]. Each bit should be tracked with the following Action [RFC5226]. Each bit should be tracked with the following
qualities: 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
28 Remove This document 25-27 Operational (3 bits) This document
29 Operational This document 28 Administrative This document
29 Remove This document
30 SYNC This document 30 SYNC This document
31 Delegate This document 31 Delegate This document
8.4. PCEP-Error Object 8.4. 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=10: SRP Object missing
Error-value=11: LSP-IDENTIFIERS TLV missing
Error-value=12: LSP-DB-VERSION TLV missing Error-value=12: LSP-DB-VERSION 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 active Error-value=2: Attempted LSP Update Request if active
stateful PCE capability was not stateful PCE capability was not
negotiated active PCE. negotiated active PCE.
Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID.
Error-value=4: Mismatched LSP signaling type.
Error-value=5: Unsupported LSP signaling type.
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=2: LSP Database version mismatch. Error-value=2: LSP Database version mismatch.
Error-value=3: The LSP-DB-VERSION TLV Missing when Error-value=3: The LSP-DB-VERSION TLV Missing when
State Synchronization Avoidance State Synchronization Avoidance
enabled. enabled.
skipping to change at page 46, line 35 skipping to change at page 51, line 45
8.5. PCEP TLV Type Indicators 8.5. 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 IPV4-RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
22 IPV6-RSVP-ERROR-SPEC This document
23 LSP-DB-VERSION This document 23 LSP-DB-VERSION This document
24 PREDUNDANCY-GROUP-ID This document 24 PREDUNDANCY-GROUP-ID This document
25 TUNNEL-ID This document 25 TUNNEL-ID This document
8.6. STATEFUL-PCE-CAPABILITY TLV 8.6. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
values are to be assigned by Standards Action [RFC5226]. Each bit values are to be assigned by Standards Action [RFC5226]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
skipping to change at page 47, line 4 skipping to change at page 52, line 15
8.6. STATEFUL-PCE-CAPABILITY TLV 8.6. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
values are to be assigned by Standards Action [RFC5226]. Each bit values are to be assigned by Standards Action [RFC5226]. Each bit
should be tracked with the following qualities: 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
30 INCLUDE-DB-VERSION This document 30 INCLUDE-DB-VERSION This document
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.7. LSP-ERROR-CODE TLV
This document requests that a registry is created to manage the value
of the LSP error code field in this TLV. This field specifies the
reason for failure to update the LSP.
Value Meaning
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests
4 Unacceptable PCUpd parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error
8.8. LSP-SIG-TYPE field in the LSP object
This document requests that a registry is created to manage the value
of the LSP type field in the LSP object, which defines the technology
used for LSP setup.
Value Meaning
0 RSVP
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 protocol extensions defined in this document. In
addition, requirements and considerations listed in this section addition, 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
skipping to change at page 47, line 45 skipping to change at page 53, line 37
A PCC implementation which allows concurrent connections to multiple A PCC implementation which allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and it MUST NOT advertise LSP existence and state to a PCE if domains and it MUST NOT advertise LSP existence and state to a PCE if
the LSP is delegated to a PCE in a different group. the LSP is delegated to a PCE in a different group.
A PCC implementation SHOULD allow the operator to specify whether the A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically controlled by any PCE (for example, LSPs that are statically
configured at the PCC). configured at the PCC).
A PCC implementation SHOULD allow the operator to specify the A PCC implementation SHOULD allow the operator to specify both the
Delegation Timeout Interval. The default value of the Delegation Redelegation Timeout Interval and the State Timeout Interval. The
Timeout Interval SHOULD be set to 30 seconds. An operator MAY also default value of the Redelegation Timeout Interval SHOULD be set to
configure a policy that will dynamically adjust the Delegation 30 seconds. An operator MAY also configure a policy that will
Timeout, for example setting it to zero when the PCC has an dynamically adjust the Redelegation Timeout Interval, for example
established session to a backup PCE. setting it to zero when the PCC has an established session to a
backup PCE. The default value for the State Timeout Interval SHOULD
be set to 60 seconds.
When an LSP can no longer be delegated to a PCE, after the expiration After the expiration of the State Timeout Interval, the LSP reverts
of the Delegation Timeout Interval, the LSP MAY either: 1) retain its to operator-defined default parameters. A PCC implementation MUST
current parameters or 2) revert to operator-defined default LSP allow the operator to specify the default LSP parameters. To achieve
parameters. This behavior SHOULD be configurable and in the case a behavior where the LSP retains the parameters set by the PCE until
when (2) is supported, a PCC implementation MUST allow the operator such time that the PCC makes a change to them, a State Timeout
to specify the default LSP parameters. Interval of infinity SHOULD be used. Any changes to LSP parameters
SHOULD be done in make-before-break fashion.
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.
skipping to change at page 51, line 25 skipping to change at page 57, line 17
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, Oscar Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar
Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej
Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath,
Calvin Ying and Xian Zhang for helpful comments and discussions. Calvin Ying and Xian Zhang for helpful comments and discussions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in
progress), October 2012.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., 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, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
skipping to change at page 52, line 10 skipping to change at page 58, line 6
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008. (PCE) Discovery", RFC 5089, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
RFC 5284, August 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[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, April 2009. Specifications", RFC 5511, April 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in
progress), October 2012.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", for Stateful PCE Discovery",
draft-sivabalan-pce-disco-stateful-01 (work in progress), draft-sivabalan-pce-disco-stateful-01 (work in progress),
April 2013. April 2013.
[I-D.zhang-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path
Computation Element (PCE)",
draft-zhang-pce-stateful-pce-app-04 (work in progress),
May 2013.
[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", pre- and throughput objectives in traffic engineering", pre-
print, 2011. print, 2011.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
 End of changes. 110 change blocks. 
320 lines changed or deleted 642 lines changed or added

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