draft-ietf-pce-stateful-pce-05.txt   draft-ietf-pce-stateful-pce-06.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: January 1, 2014 Cisco Systems, Inc. Expires: February 20, 2014 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
June 30, 2013 August 19, 2013
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-05 draft-ietf-pce-stateful-pce-06
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 January 1, 2014. This Internet-Draft will expire on February 20, 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . 7 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 7
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 8 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 8
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 9
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 10
5. Architectural Overview of Protocol Extensions . . . . . . . . 17 5. Architectural Overview of Protocol Extensions . . . . . . . . 10
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 17 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 10
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 12
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 15
5.4.2. PCE-triggered State Synchronization . . . . . . . . . 25 5.4.2. PCE-triggered State Synchronization . . . . . . . . . 19
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 19
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 20
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 27 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 21
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 28 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 22
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 29 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 23
5.5.5. Redelegation on PCE failure . . . . . . . . . . . . . 29 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 23
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 30 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 24
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 30 Request/Response . . . . . . . . . . . . . . . . . . . 24
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 32 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 26
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 33 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 27
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 33 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 27
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 33 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 34 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 28
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 35 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 29
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 36 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 31
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 37 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 31
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 37 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 31
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 38 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 38 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 32
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 39 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 33
7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 40 7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 34
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 44 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 38
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 46 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 40
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 47 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 41
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 48 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 42
7.3.5. LSP State Database Version TLV . . . . . . . . . . . . 48 7.3.5. LSP State Database Version TLV . . . . . . . . . . . . 42
7.3.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 49 7.3.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 43
7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 49 7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 43
7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 49 7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 49 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 43
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 50 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 50 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 50 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 44
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 51 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 45
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 52 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46
8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 52 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 46
8.8. LSP-SIG-TYPE field in the LSP object . . . . . . . . . . . 52 8.8. LSP-SIG-TYPE field in the LSP object . . . . . . . . . . . 46
9. Manageability Considerations . . . . . . . . . . . . . . . . . 53 9. Manageability Considerations . . . . . . . . . . . . . . . . . 47
9.1. Control Function and Policy . . . . . . . . . . . . . . . 53 9.1. Control Function and Policy . . . . . . . . . . . . . . . 47
9.2. Information and Data Models . . . . . . . . . . . . . . . 54 9.2. Information and Data Models . . . . . . . . . . . . . . . 48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 54 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 54 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 54 Components . . . . . . . . . . . . . . . . . . . . . . . . 49
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 55 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 55 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 55 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 56 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 56 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
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 Computation Element (PCE), or between PCEs, enabling
enabling computation of Multiprotocol Label Switching (MPLS) for computation of Multiprotocol Label Switching (MPLS) for Traffic
Traffic Engineering Label Switched Path (TE LSP) characteristics. Engineering Label Switched Path (TE LSP) characteristics. Extensions
Extensions for support of GMPLS in PCEP are defined in for support of Generalized MPLS (GMPLS) in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
stateful control of LSPs between and across PCEP sessions in stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect LSP compliance with [RFC4657]. It includes mechanisms to effect 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, PCEP Speaker.
This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [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 Stateful PCE: has access to not only the network state, but also to
the set of active paths and their reserved resources for its the set of active paths and their reserved resources for its
skipping to change at page 6, line 11 skipping to change at page 6, line 11
which the PCE may issue recommendations to the network. For which the PCE may issue recommendations to the network. For
example, an active stateful PCE may utilize the Delegation example, an active stateful PCE may utilize the Delegation
mechanism to update LSP parameters in those PCCs that delegated mechanism to update LSP parameters in those PCCs that delegated
control over their LSPs to the PCE. control over their LSPs to the PCE.
Delegation: An operation to grant a PCE temporary rights to modify a Delegation: An operation to grant a PCE temporary rights to modify a
subset of LSP parameters on one or more PCC's LSPs. LSPs are subset of LSP parameters on one or more PCC's LSPs. LSPs are
delegated from a PCC to a PCE, and are referred to as delegated delegated from a PCC to a PCE, and are referred to as delegated
LSPs. The PCC who owns the PCE state for the LSP has the right to LSPs. The PCC 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. For intra-domain LSPs, this PCC SHOULD be the PCC of the
LSP head end.
Revocation An operation performed by a PCC on a previously delegated Revocation: An operation performed by a PCC on a previously
LSP. Revocation revokes the rights granted to the PCE in the delegated LSP. Revocation revokes the rights granted to the PCE
delegation operation. in the delegation operation.
Redelegation 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 and attempting to redelegate LSPs associated with the PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE. The Redelegation terminated PCEP session to an alternate PCE. The Redelegation
Timeout Interval is a PCC-local value that can be either operator- Timeout Interval is a PCC-local value that can be either operator-
configured or dynamically computed by the PCC based on local configured or dynamically computed by the PCC based on local
policy. policy.
State Timeout Interval: when a PCEP session is terminated, a PCC State Timeout Interval: when a PCEP session is terminated, a PCC
waits for this time period before flushing LSP state associated waits for this time period before flushing LSP state associated
with that PCEP session and reverting to operator-defined default with that PCEP session and reverting to operator-defined default
parameters. The state will not be flushed in two cases: a) the parameters. The State Timeout Interval is a PCC-local value that
LSP is redelegated to another PCE before the expiration of the can be either operator-configured or dynamically computed by the
State Timeout Interval or b)the PCC makes changes to the LSP PCC based on local policy.
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
as defined in [RFC3209]. as defined in [RFC3209].
LSP State Database: information about and attributes of all LSPs LSP State Database: information about all LSPs and their attributes.
that are being reported to one or more PCEs via LSP State Reports.
Minimum Cut Set: the minimum set of links for a specific source Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, result in a destination pair which, when removed from the network, result in a
specific source being completely isolated from specific specific source being completely isolated from specific
destination. The summed capacity of these links is equivalent to destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the the maximum capacity from the source to the destination by the
max-flow min-cut theorem. max-flow min-cut theorem.
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, [I-D.ietf-pce-stateful-pce-app] presents several use cases,
showcasing scenarios that benefit from the deployment of a stateful demonstrating scenarios that benefit from the deployment of a
PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments. stateful 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 its 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
skipping to change at page 9, line 6 skipping to change at page 8, line 38
optimality of resource usage [MXMN-TE]. All of these systems share optimality of resource usage [MXMN-TE]. All of these systems share
at least two common characteristics: the requirement for both global at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for visibility of a flow (or in this case, a TE LSP) state and for
ordered control of path reservations across devices within the system ordered control of path reservations across devices within the system
being controlled. While some approaches have been suggested in order being controlled. While some approaches have been suggested in order
to remove the requirements for ordered control (See [MPLS-PC]), these to remove the requirements for ordered control (See [MPLS-PC]), these
approaches are highly dependent on traffic distribution, and do not approaches are highly dependent on traffic distribution, and do not
allow for multiple simultaneous LSP priorities representing diffserv allow for multiple simultaneous LSP priorities representing diffserv
classes. classes.
The following use cases demonstrate a need for visibility into global The use cases described in [I-D.ietf-pce-stateful-pce-app]
inter-PCC LSP state in PCE path computations, and for a PCE control demonstrate a need for visibility into global inter-PCC LSP state in
of sequence and timing in altering LSP path characteristics within PCE path computations, and for PCE control of sequence and timing in
and across PCEP sessions. Reference topologies for the use cases altering LSP path characteristics within and across PCEP sessions.
described later in this section are shown in Figures 1 and 2.
Unless otherwise cited, use cases assume that all LSPs listed exist
at the same LSP priority.
+-------+
| A |
| |
+-------+
\
+-------+ +-------+
| C |-------------------------| E |
| | | |
+-------+ +-------+ +-------+
/ \ | D | /
+-------+ ------| |------
| B | +-------+
| |
+-------+
Figure 1: Reference topology 1
+-------+ +-------+ +-------+
| A | | B | | C |
| | | | | |
+---+---+ +---+---+ +---+---+
| | |
| | |
+---+---+ +---+---+ +---+---+
| E | | F | | G |
| +--------+ +--------+ |
+-------+ +-------+ +-------+
Figure 2: Reference topology 2
3.1.2.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by PCReq
messages under control of a PCC's local timers, the sequence of RSVP
reservation arrivals occurring in the network will be randomized.
This, coupled with a lack of global LSP state visibility on the part
of a stateless PCE may result in suboptimal throughput in a given
network topology.
Reference topology 2 in Figure 2 and Tables 1 and 2 show an example
in which throughput is at 50% of optimal as a result of lack of
visibility and synchronized control across PCC's. In this scenario,
the decision must be made as to whether to route any portion of the
E-G demand, as any demand routed for this source and destination will
decrease system throughput.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+
Table 1: Link parameters for Throughput use case
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+
Table 2: Throughput use case demand time series
In many cases throughput maximization becomes a bin packing problem.
While bin packing itself is an NP-hard problem, a number of common
heuristics which run in polynomial time can provide significant
improvements in throughput over random reservation event
distribution, especially when traversing links which are members of
the minimum cut set for a large subset of source destination pairs.
Tables 3 and 4 show a simple use case using Reference Topology 1 in
Figure 1, where LSP state visibility and control of reservation order
across PCCs would result in significant improvement in total
throughput.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 3: Link parameters for Bin Packing use case
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 4: Bin Packing use case demand time series
3.1.2.2. Deadlock
Most existing RSVP-TE implementations will not tear down established
LSPs in the event of the failure of the bandwidth increase procedure
detailed in [RFC3209]. This behavior is directly implied to be
correct in [RFC3209] and is often desirable from an operator's
perspective, because either a) the destination prefixes are not
reachable via any means other than MPLS or b) this would result in
significant packet loss as demand is shifted to other LSPs in the
overlay mesh.
In addition, there are currently few implementations offering ingress
admission control at the LSP level. Again, having ingress admission
control on a per LSP basis is not necessarily desirable from an
operational perspective, as a) one must over-provision LSPs
significantly in order to avoid deleterious effects resulting from
stacked transport and flow control systems and b) there is currently
no efficient commonly available northbound interface for dynamic
configuration of per LSP ingress admission control (such an interface
could easily be defined using the extensions present in this spec,
but it beyond the scope of the current document).
Lack of ingress admission control coupled with the behavior in
[RFC3209] effectively results in mis-signaled LSPs during periods of
contention for network capacity between LSPs in a given LSP priority.
This in turn causes information loss in the TED with regard to actual
network state, resulting in LSPs sharing common network interfaces
with mis-signaled LSPs operating in a degraded state for significant
periods of time, even when unused network capacity may potentially be
available.
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case
that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are
signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E
respectively. At a later time, the demand of LSP 1 increases to 20.
Under such a demand, the LSP cannot be resignaled. However, the
existing LSP will not be torn down. In the absence of ingress
policing, traffic on LSP 1 will cause degradation for traffic of LSP
2 (due to oversubscription on the links C-D and D-E), as well as
information loss in the TED with regard to the actual network state.
The problem could be easily ameliorated by global visibility of LSP
state coupled with PCC- external demand measurements and placement of
two LSPs on disjoint links. Note that while the demand of 20 for LSP
1 could never be satisfied in the given topology, what could be
achieved would be isolation from the ill-effects of the
(unsatisfiable) increased demand.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 5: Link parameters for the 'Deadlock' example
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 6: Deadlock LSP and demand time series
3.1.2.3. Minimum Perturbation
As a result of both the lack of visibility into global LSP state and
the lack of control over event ordering across PCE sessions,
unnecessary perturbations may be introduced into the network by a
stateless PCE. Tables 7 and 8 show an example of an unnecessary
network perturbation using Reference Topology 1 in Figure 1. In this
case an unimportant (high LSP priority value) LSP (LSP1) is first set
up along the shortest path. At time 2, which is assumed to be
relatively close to time 1, a second more important (lower LSP-
priority value) LSP is established, preempting LSP 1 and shifting it
to the longer A-C-E path.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 7: Link parameters for the 'Minimum-Perturbation' example
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+
Table 8: Minimum-Perturbation LSP and demand time series
3.1.2.4. Predictability
Randomization of reservation events caused by lack of control over
event ordering across PCE sessions results in poor predictability in
LSP routing. An offline system applying a consistent optimization
method will produce predictable results to within either the boundary
of forecast error when reservations are over-provisioned by
reasonable margins or to the variability of the signal and the
forecast error when applying some hysteresis in order to minimize
churn.
Reference Topology 1 and Tables 9, 10 and 11 show the impact of event
ordering and predictability of LSP routing.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 9: Link parameters for the 'Predictability' example
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 10: Predictability LSP and demand time series 1
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 11: Predictability LSP and demand time series 2
3.1.2.5. Global Concurrent Optimization
Global Concurrent Optimization (GCO) defined in [RFC5557] is a
network optimization mechanism that is able to simultaneously
consider the entire topology of the network and the complete set of
existing TE LSPs and their existing constraints, and look to optimize
or reoptimize the entire network to satisfy all constraints for all
TE LSPs. It allows for bulk path computations in order to avoid
blocking problems and to achieve more optimal network-wide solutions.
Global control of LSP operation sequence in [RFC5557] is predicated
on the use of what is effectively a stateful (or semi-stateful) NMS.
The NMS can be either not local to the switch, in which case another
northbound interface is required for LSP attribute changes, or local/
collocated, in which case there are significant issues with
efficiency in resource usage. Stateful PCE adds a few features that:
o Roll the NMS visibility into the PCE and remove the requirement
for an additional northbound interface
o Allow the PCE to determine when re-optimization is needed
o Allow the PCE to determine which LSPs should be re-optimized
o Allow a PCE to control the sequence of events across multiple
PCCs, allowing for bulk (and truly global) optimization, LSP
shuffling etc.
3.1.3. Protocol vs. Configuration 3.1.3. Protocol vs. Configuration
Note that existing configuration tools and protocols can be used to Note that existing configuration tools and protocols can be used to
set LSP state. However, this solution has several shortcomings: set LSP state. However, this solution has several shortcomings:
o Scale & Performance: configuration operations often require o Scale & Performance: configuration operations often require
processing of additional configuration portions beyond the state processing of additional configuration portions beyond the state
being directly acted upon, with corresponding cost in CPU cycles, being directly acted upon, with corresponding cost in CPU cycles,
negatively impacting both PCC stability LSP update rate capacity. negatively impacting both PCC stability LSP update rate capacity.
skipping to change at page 16, line 19 skipping to change at page 9, line 47
PCE such that a single LSP is under the control a single PCE at PCE such that a single LSP is under the control a single PCE at
any given time. A PCC may revoke this delegation at any time any given time. A PCC may revoke this delegation at any time
during the lifetime of the LSP. If LSP delegation is revoked during the lifetime of the LSP. If LSP delegation is revoked
while the PCEP session is up, the PCC MUST notify the PCE about while the PCEP session is up, the PCC MUST notify the PCE about
the revocation. A PCE may return an LSP delegation at any point the revocation. A PCE may return an LSP delegation at any point
during the lifetime of the PCEP session. during the lifetime of the PCEP session.
o Allow a PCE to control computation timing and update timing across o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it. all LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event PCE o Enable uninterrupted operation of PCC's LSPs in the event of a PCE
failure or while control of LSPs is being transferred between failure or while control of LSPs is being transferred between
PCEs. PCEs.
4. New Functions to Support Stateful PCEs 4. New Functions to Support Stateful PCEs
Several new functions will be required in PCEP to support stateful Several new functions are required in PCEP to support stateful PCEs.
PCEs. A function can be initiated either from a PCC towards a PCE A function can be initiated either from a PCC towards a PCE (C-E) or
(C-E) or from a PCE towards a PCC (E-C). The new functions are: from a PCE towards a PCC (E-C). The new functions are:
Capability negotiation (E-C,C-E): both the PCC and the PCE must Capability negotiation (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP announce during PCEP session establishment that they support PCEP
Stateful PCE extensions defined in this document. Stateful PCE extensions defined in this document.
LSP state synchronization (C-E): after the session between the PCC LSP state synchronization (C-E): after the session between the PCC
and a stateful PCE is initialized, the PCE must learn the state of and a stateful PCE is initialized, the PCE must learn the state of
a PCC's LSPs before it can perform path computations or update LSP a PCC's LSPs before it can perform path computations or update LSP
attributes in a PCC. attributes in a PCC.
skipping to change at page 17, line 28 skipping to change at page 11, line 10
particular, in addition to specifying values for LSP's attributes, an particular, in addition to specifying values for LSP's attributes, an
active stateful PCE also decides when to make LSP modifications. active stateful PCE also decides when to make LSP modifications.
Retaining LSP state ownership on the PCC allows for: Retaining LSP state ownership on the PCC allows for:
o a PCC to interact with both stateless and stateful PCEs at the o a PCC to interact with both stateless and stateful PCEs at the
same time same time
o a stateful PCE to only modify a small subset of LSP parameters, o a stateful PCE to only modify a small subset of LSP parameters,
i.e. to set only a small subset of the overall LSP state; other i.e. to set only a small subset of the overall LSP state; other
parameters may be set by the operator through CLI commands parameters may be set by the operator through command line
interface (CLI) commands
o a PCC to revert delegated LSP to an operator-defined default or to o a PCC to revert delegated LSP to an operator-defined default or to
delegate the LSPs to a different PCE, if the PCC get disconnected delegate the LSPs to a different PCE, if the PCC get disconnected
from a PCE with currently delegated LSPs from a PCE with currently delegated LSPs
5.2. New Messages 5.2. New Messages
In this document, we define the following new PCEP messages: In this document, we define the following new PCEP messages:
Path Computation State Report (PCRpt): a PCEP message sent by a PCC Path Computation State Report (PCRpt): a PCEP message sent by a PCC
skipping to change at page 18, line 23 skipping to change at page 12, line 4
| Capability Negotiation (E-C,C-E) | Open | | Capability Negotiation (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt | | State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt | | LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd | | LSP Update Request (E-C) | PCUpd |
| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS |
| | sub-TLV | | | sub-TLV |
| OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, |
| | PCE-CAP-FLAGS sub-TLV | | | PCE-CAP-FLAGS sub-TLV |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
Table 1: New Function to Message Mapping
Table 12: New Function to Message Mapping
5.3. Capability Negotiation 5.3. Capability Negotiation
During PCEP Initialization Phase, PCEP Speakers (PCE pr PCC) During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
negotiate the use of stateful PCEP extensions. A PCEP Speaker negotiate the use of stateful PCEP extensions. A PCEP Speaker
includes the "Stateful PCE Capability" TLV, described in includes the "Stateful PCE Capability" TLV, described in
Section 7.1.1, in the OPEN Object to advertise its support for PCEP Section 7.1.1, in the OPEN Object to advertise its support for PCEP
stateful extensions. The Stateful Capability TLV includes the 'LSP stateful extensions. The Stateful Capability TLV includes the 'LSP
Update' Flag that indicates whether the PCEP Speaker supports LSP Update' Flag that indicates whether the PCEP Speaker supports LSP
parameter updates. parameter updates.
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the Stateful PCE Capability TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP protocol extensions for stateful PCEs MUST NOT be used if The PCEP 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 but did not negotiate
"Stateful PCE capability not negotiated" (see Section 8.4) will be this capability, then a PCErr with code "Stateful PCE capability not
generated and the PCEP session will be terminated. negotiated" (see Section 8.4) will be 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)'. If this "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this
is not the case and LSP delegation or LSP update operations are is not the case and LSP delegation or LSP update operations are
attempted, then a PCErr with code "Delegation not negotiated" (see attempted, then a PCErr with code "Delegation not negotiated" (see
Section 8.4) SHOULD be generated. Note that even if the update 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.
skipping to change at page 19, line 34 skipping to change at page 13, line 15
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. If both PCEP speakers had set the INCLUDE-DB-VERSION 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- 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 DB-VERSION TLV MUST be included and contain the PCC's latest LSP
State Database version. State Database version. If the PCC has no state to synchronize, it
will only send the end of synchronization marker.
A PCE SHOULD NOT send PCUpd messages to a PCC before State A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
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.
skipping to change at page 20, line 10 skipping to change at page 13, line 40
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.
The successful State Synchronization sequence is shown in Figure 3. The successful State Synchronization sequence is shown in Figure 1.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| (Sync start) |-----PCRpt, SYNC=1----->| (Sync start)
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-----PCRpt, SYNC=1----->| (Sync done) |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
| | | |
|-----PCRpt, SYNC=0----->| (End of sync marker |-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report | | LSP State Report
| | for PLSP-ID=0) | | for PLSP-ID=0)
| | (Sync done)
Figure 3: Successful state synchronization Figure 1: Successful state synchronization
The sequence where the PCE fails during the State Synchronization The sequence where the PCE fails during the State Synchronization
phase is shown in Figure 4. phase is shown in Figure 2.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
skipping to change at page 21, line 25 skipping to change at page 14, line 50
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-PCRpt, SYNC=1 | |-PCRpt, SYNC=1 |
| \ ,-PCErr=?-| | \ ,-PCErr=?-|
| \ / | | \ / |
| \/ | | \/ |
| /\ | | /\ |
| / `-------->| (Ignored) | / `-------->| (Ignored)
|<--------` | |<--------` |
Figure 4: Failed state synchronization (PCE failure) Figure 2: Failed state synchronization (PCE failure)
The sequence where the PCC fails during the State Synchronization The sequence where the PCC fails during the State Synchronization
phase is shown in Figure 5. phase is shown in Figure 3.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-------- PCErr=? ------>| |-------- PCErr=? ------>|
| | | |
Figure 5: Failed state synchronization (PCC failure) Figure 3: Failed state synchronization (PCC failure)
5.4.1. State Synchronization Avoidance 5.4.1. State Synchronization Avoidance
State Synchronization MAY be skipped following a PCEP session restart State Synchronization MAY be skipped following a PCEP session restart
if the state of both PCEP peers did not change during the period if the state of both PCEP peers did not change during the period
prior to session re-initialization. To be able to make this prior to session re-initialization. To be able to make this
determination, state must be exchanged and maintained by both PCE and determination, state must be exchanged and maintained by both PCE and
PCC during normal operation. This is accomplished by keeping track PCC during normal operation. This is accomplished by keeping track
of the changes to the LSP State Database, using a database version of the changes to the LSP State Database, using a database version
called the LSP State Database Version. called the LSP State Database Version.
skipping to change at page 22, line 17 skipping to change at page 15, line 44
be incremented by 1 for each successive change in the LSP state be incremented by 1 for each successive change in the LSP state
database. The LSP State Database version MUST start at 1 and may database. The LSP State Database version MUST start at 1 and may
wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. The PCC wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. The PCC
is the owner of the LSP State Database version, which is incremented is the owner of the LSP State Database version, which is incremented
each time a change is made to the PCC's local LSP State Database. each time a change is made to the PCC's local LSP State Database.
Operations that trigger a change to the local LSP State database Operations that trigger a change to the local LSP State database
include a change in the LSP operational state, delegation of an LSP, include a change in the LSP operational state, delegation of an LSP,
removal or addition of an LSP or change in any of the LSP attributes removal or addition of an LSP or change in any of the LSP attributes
that would trigger a report to the PCE. When State Synchronization that would trigger a report to the PCE. When State Synchronization
avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- avoidance is enabled on a PCEP session, a PCC includes the LSP-DB-
VERSION TLV as an optional TLV in the LSP Object on each LSP State VERSION TLV in the LSP Object on each LSP State Report. The LSP-DB-
Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database VERSION TLV contains a PCC's LSP State Database version.
version.
State Synchronization Avoidance is negotiated on a PCEP session State Synchronization Avoidance is negotiated on a PCEP session
during session startup. To make sure that a PCEP peer can recognize during session startup using the INCLUDE-DB-VERSION (IDB) bit in the
a previously connected peer even if its IP address changed, each PCEP capabilities TLV. To ensure that a PCEP peer can recognize a
previously connected peer even if its IP address changed, each PCEP
peer includes the PREDUNDANCY-GROUP-ID TLV in the OPEN message. peer includes the PREDUNDANCY-GROUP-ID TLV in the OPEN message.
If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN
object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the
LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the
PCC's latest LSP State Database version. PCC's latest LSP State Database version.
If a PCE's LSP State Database survived the restart of a PCEP session, If a PCE's LSP State Database survived the restart of a PCEP session,
the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and
the TLV will contain the last LSP State Database version received on the TLV will contain the last LSP State Database version received on
an LSP State Report from the PCC in a previous PCEP session. If a an LSP State Report from the PCC in a previous PCEP session. If a
PCC's LSP State Database survived the restart, the PCC will include PCC's LSP State Database survived the restart of a PCEP session, the
the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain PCC will include the LSP-DB-VERSION TLV in its OPEN object and the
the last LSP State Database version sent on an LSP State Report from TLV will contain the latest LSP State Database version sent on an LSP
the PCC in the previous PCEP session. If a PCEP Speaker's LSP State State Report from the PCC in the previous PCEP session. If a PCEP
Database did not survive the restart of a PCEP session, the PCEP Speaker's LSP State Database did not survive the restart of a PCEP
Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. session, the PCEP 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 prior to completing the If state synchronization is required, then prior to completing the
skipping to change at page 23, line 15 skipping to change at page 16, line 43
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.
Note that a PCE MAY force State Synchronization by not including the Note that a PCE/PCC MAY force State Synchronization by not including
LSP-DB-VERSION TLV in its OPEN object. the LSP-DB-VERSION TLV in its OPEN object.
Figure 6 shows an example sequence where State Synchronization is Figure 4 shows an example sequence where State Synchronization is
skipped. skipped.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|--Open--, | |--Open--, |
| DBv=42 \ ,---Open--| | DBv=42 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
skipping to change at page 23, line 43 skipping to change at page 17, line 27
| . | | . |
| . | | . |
| | | |
|--PCRpt,DBv=43,SYNC=0-->| (Regular |--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Report) | | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular |--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report) | | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->| |--PCRpt,DBv=45,SYNC=0-->|
| | | |
Figure 6: State Synchronization skipped Figure 4: State Synchronization skipped
Figure 7 shows an example sequence where State Synchronization is Figure 5 shows an example sequence where State Synchronization is
performed due to LSP State Database version mismatch during the PCEP performed due to LSP State Database version mismatch during the PCEP
session setup. Note that the same State Synchronization sequence session setup. Note that the same State Synchronization sequence
would happen if either the PCC or the PCE would not include the LSP- would happen if either the PCC or the PCE would not include the LSP-
DB-VERSION TLV in their respective Open messages. DB-VERSION TLV in their respective Open messages.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|--Open--, | |--Open--, |
| DBv=46 \ ,---Open--| | DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
| /\ | | /\ |
| / `-------->| (Expect sync) | / `-------->| (Expect sync)
(Do sync) |<--------` | (Purge LSP State) (Do sync) |<--------` |
| | | |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start) |--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . | | . |
| . | | . |
| . | | . |
|--PCRpt,DBv=46,SYNC=1-->| (Sync done) |--PCRpt,DBv=46,SYNC=1-->| (Sync done)
| . | | . |(Purge LSP State)
| . | | . |
| . | | . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular |--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report) | | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular |--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report) | | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->| |--PCRpt,DBv=49,SYNC=0-->|
| | | |
Figure 7: State Synchronization performed Figure 5: State Synchronization performed
Figure 8 shows an example sequence where State Synchronization is Figure 6 shows an example sequence where State Synchronization is
skipped, but because one or both PCEP Speakers set the INCLUDE-DB- skipped, but because one or both PCEP Speakers set the INCLUDE-DB-
VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the
PCE. If the current PCEP session restarts, the PCEP Speakers will PCE. If the current PCEP session restarts, the PCEP Speakers will
have to perform State Synchronization, since the PCE will not know have to perform State Synchronization, since the PCE will not know
the PCC's latest LSP State Database version. the PCC's latest LSP State Database version.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 25, line 26 skipping to change at page 19, line 26
| . | | . |
| . | | . |
| . | | . |
|------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 6: State Synchronization skipped, no LSP-DB-VERSION TLVs sent
from PCC from PCC
5.4.2. PCE-triggered State Synchronization 5.4.2. PCE-triggered State Synchronization
Because the accuracy of the computations performed by the PCE is tied 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 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 can be beneficial to be able to resynchronize this state even after
the session has established. The PCE may use this approach to the session has established. The PCE may use this approach to
continuously sanity check its state against the network, or to continuously sanity check its state against the network, or to
recover from error conditions without having to tear down sessions. recover from error conditions without having to tear down sessions.
skipping to change at page 26, line 35 skipping to change at page 20, line 35
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. If the PCE does not accept the LSP Delegation, it State Report to 1. If the PCE does not accept the LSP Delegation, it
MUST immediately respond with an empty LSP Update Request which has MUST immediately respond with an empty LSP Update Request which has
the Delegate flag set to 0. If the PCE accepts the LSP Delegation, the Delegate flag set to 0. If the PCE accepts the LSP Delegation,
it confirms this when it sends the first LSP Update Request for the it confirms this when it sends the first LSP Update Request for the
delegated LSP to the PCC by setting the Delegate flag to 1 (note that delegated LSP to the PCC by setting the Delegate flag to 1 (note that
this may occur at a later time). this may occur at a later time).
The delegation sequence is shown in Figure 9. The delegation sequence is shown in Figure 7.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP Delegated |---PCRpt, Delegate=1--->| LSP Delegated
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| . | | . |
| . | | . |
| . | | . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
Figure 9: Delegating an LSP Figure 7: Delegating an LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE. the Delegate flag to 1 on each LSP Status Report sent to the PCE.
5.5.2. Revoking a Delegation 5.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
skipping to change at page 27, line 29 skipping to change at page 21, line 29
the message queue. All effects of all messages for which processing the message queue. All effects of all messages for which processing
started before the revocation took place MUST be allowed to complete started before the revocation took place MUST be allowed to complete
and the result MUST be given the same treatment as any LSP that had and the result MUST be given the same treatment as any LSP that had
been previously delegated to the PCE (e.g. the state MAY be been previously delegated to the PCE (e.g. the state MAY be
immediately cleared). Any further PCUpd messages from the PCE are immediately cleared). Any further PCUpd messages from the PCE are
handled according to the PCUpd procedures described in this document. 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 8.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| . | | . |
| . | | . |
| . | | . |
|---PCRpt, Delegate=0--->| PCC revokes delegation |---PCRpt, Delegate=0--->| PCC revokes delegation
| | | |
Figure 10: Revoking a Delegation Figure 8: 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 unexpectedly, the PCC When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
MUST wait the time interval specified in Redelegation Timeout MUST wait the time interval specified in Redelegation Timeout
Interval before revoking LSP delegations to that PCE and attempting Interval before revoking LSP delegations to that PCE and attempting
to redelegate LSPs to an alternate PCE. If a PCEP session with the to redelegate LSPs to an alternate PCE. If a PCEP session with the
skipping to change at page 28, line 51 skipping to change at page 22, line 51
| | | |
|---PCRpt, Delegate=1--->| LSP delegated |---PCRpt, Delegate=1--->| LSP delegated
| . | | . |
| . | | . |
| . | | . |
|<--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 9: Returning a Delegation
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC stateful PCE accepts the delegation), the LSP delegation on the PCC
will time out within a configurable Redelegation Timeout Interval and will time out within a configurable Redelegation Timeout Interval and
the PCC MUST flush any LSP state set by a PCE at the expiration of the PCC MUST flush any LSP state set by a PCE at the expiration of
the State Timeout Interval. the State Timeout Interval.
5.5.4. Redundant Stateful PCEs 5.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 a subset of the LSPs in the network delegated to it. The
not update any LSPs that are not delegated to it, but receives all backup PCE does not update any LSPs that are not delegated to it. In
LSP State Reports from a PCC. When the primary PCE for a given LSP order to allow the backup to operate in a hot-standby mode and avoid
set fails, after expiry of the Redelegation Timeout Interval, the PCC the need for state synchronization in case the primary fails, the
SHOULD delegate to the redundant PCE all LSPs that had been backup receives all LSP State Reports from a PCC. When the primary
previously delegated to the failed PCE. Assuming that the State PCE for a given LSP set fails, after expiry of the Redelegation
Timeout Interval had been configured to be larger than the Timeout Interval, the PCC SHOULD delegate to the redundant PCE all
Redelegation Timeout Interval (as recommended), this delegation LSPs that had been 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. change will not cause any changes to the LSP parameters.
5.5.5. Redelegation on PCE failure 5.5.5. Redelegation on PCE Failure
On failure, the goal is to: 1) avoid any traffic loss on the LSPs On failure, the goal is to: 1) avoid any traffic loss on the LSPs
that were updated by the PCE that crashed 2) minimize the churn in that were updated by the PCE that crashed 2) minimize the churn in
the network in terms of ownership of the LSPs, 3) not leave any the network in terms of ownership of the LSPs, 3) not leave any
"orphan" (undelegated) LSPs and 4) be able to control when the state "orphan" (undelegated) LSPs and 4) be able to control when the state
that was set by the PCE can be changed or purged. The values chosen that was set by the PCE can be changed or purged. The values chosen
for the Redelegation Timeout and State Timeout values affect the for the Redelegation Timeout and State Timeout values affect the
ability to accomplish these goals. ability to accomplish these goals.
This section summarizes the behaviour with regards to LSP delegation This section summarizes the behaviour with regards to LSP delegation
and LSP state on a PCE failure. and LSP state on a PCE failure.
If the PCE crashses but recovers within the Redelegation Timeout, If the PCE crashes but recovers within the Redelegation Timeout, both
both the delegation state and the LSP state are kept intact. the delegation state and the LSP state are kept intact.
If the PCE crashes but does not recover within the Redelegation If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is flushed, which may Timeout Interval, the state set by the PCE is flushed, which may
cause change in the LSP state. Note that an operator may choose to cause change in the LSP state. Note that an operator may choose to
use an infinite State Timeout Interval if he wishes to maintain the use an infinite State Timeout Interval if he wishes to maintain the
PCE state indefinetely. Note also that flushing the state should be PCE state indefinetely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss. implemented using make-before-break to avoid traffic loss.
If there is a hot-standby PCE, the Redelegation Timeout may be set to If there is a standby PCE, the Redelegation Timeout may be set to 0
0 through policy on the PCC, causing the LSPs to be redelegated through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the immediately to the PCC, which can delegate them immediately to the
hot-standby PCE. Assuming the State Timeout Interval is larger than standby PCE. Assuming the State Timeout Interval is larger than the
the Redelegation Timeout, the LSP state will be kept intact. 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 --->|
skipping to change at page 30, line 38 skipping to change at page 24, line 39
event | | event | |
| | | |
5) LSP Status Report|----- PCRpt message --->| 5) LSP Status Report|----- PCRpt message --->|
sent to all | . | sent to all | . |
stateful PCEs | . | stateful PCEs | . |
| . | | . |
6) Repeat for each |----- PCRpt message --->| 6) Repeat for each |----- PCRpt message --->|
LSP status change| | LSP status change| |
| | | |
Figure 12: Passive Stateful PCE Path Computation Request/Response Figure 10: Passive Stateful PCE Path Computation Request/Response
Once a PCC has successfully established a PCEP session with a passive Once a PCC has successfully established a PCEP session with a passive
stateful PCE and the PCC's LSP state is synchronized with the PCE stateful PCE and the PCC's LSP state is synchronized with the PCE
(i.e. the PCE knows about all PCC's existing LSPs), if an event is (i.e. the PCE knows about all PCC's existing LSPs), if an event is
triggered that requires the computation of a set of paths, the PCC triggered that requires the computation of a set of paths, the PCC
sends a path computation request to the PCE ([RFC5440], Section sends a path computation request to the PCE ([RFC5440], Section
4.2.3). The PCReq message MAY contain the LSP Object to identify the 4.2.3). The PCReq message MAY contain the LSP Object to identify the
LSP for which the path computation is requested. LSP for which the path computation is requested.
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
skipping to change at page 31, line 24 skipping to change at page 25, line 26
chance to send an LSP State Report indicating that the status is chance to send an LSP State Report indicating that the status is
'Pending'. In such cases, the PCC may choose to only send the PCRpt 'Pending'. In such cases, the PCC may choose to only send the PCRpt
indicating the latest status ('Up' or 'Down'). indicating the latest status ('Up' or 'Down').
Upon receiving a negative reply from a PCE, a PCC may decide to Upon receiving a negative reply from a PCE, a PCC may decide to
resend a modified request or take any other appropriate action. For resend a modified request or take any other appropriate action. For
each requested LSP, it also sends an LSP State Report carried on a each requested LSP, it also sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Down'. PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
There is no direct correlation between PCRep and PCRpt messages. For There is no direct correlation between PCRep and PCRpt messages. For
a given LSP, multiple LSP State Reports will follow a single PC a given LSP, multiple LSP State Reports will follow a single PCRep
Reply, as a PCC notifies a PCE of the LSP's state changes. message, as a PCC notifies a PCE of the LSP's state changes.
A PCC sends each LSP State Report to each stateful PCE that is A PCC sends each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
Note that a single PCRpt message MAY contain multiple LSP State Note that a single PCRpt message MAY contain multiple LSP State
Reports. Reports.
The passive stateful PCE is the model for stateful PCEs is described The passive stateful PCE is the model for stateful PCEs is described
in [RFC4655], Section 6.8. in [RFC4655], Section 6.8.
skipping to change at page 32, line 28 skipping to change at page 26, line 28
| | | |
| | | |
4) LSP Status Report|---- PCRpt message ---->| 4) LSP Status Report|---- PCRpt message ---->|
sent(->Pending) | . | sent(->Pending) | . |
| . | | . |
| . | | . |
5) LSP Status Report|---- PCRpt message ---->| 5) LSP Status Report|---- PCRpt message ---->|
sent (->Up|Down) | | sent (->Up|Down) | |
| | | |
Figure 13: Active Stateful PCE Figure 11: Active Stateful PCE
Once a PCC has successfully established a PCEP session with an active Once a PCC has successfully established a PCEP session with an active
stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.
the PCE knows about all PCC's existing LSPs) and LSPs have been the PCE knows about all PCC's existing LSPs) 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.
skipping to change at page 32, line 51 skipping to change at page 26, line 51
in Section 7.2. The SRP-ID-number is used to correlate errors and 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 state reports to LSP Update Requests. A single PCUpd message MAY
contain multiple LSP Update Requests. 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 indicating that the LSP's status is 'Pending'. If the PCC decides
that the LSP parameters proposed in the PCUpd message are that the LSP parameters proposed in the PCUpd message are
unacceptable, it MUST report this error by including the LSP-ERROR- unacceptable, it MUST report this error by including the LSP-ERROR-
CODE TLV (Section 7.3.3) with LSP error value="Unacceptable PCUpd CODE TLV (Section 7.3.3) with LSP error value="Unacceptable
parameters" in the LSP object in the PCRpt message to the PCE. Based parameters" in the LSP object in the PCRpt message to the PCE. Based
on local policy, it MAY react further to this error by revoking the on local policy, it MAY react further to this error by revoking the
delegation. If the PCC receives a PCUpd message for an LSP object delegation. If the PCC receives a PCUpd message for an LSP object
identified with a PLSP-ID that does not exist on the PCC, it MUST identified with a PLSP-ID that does not exist on the PCC, it MUST
generate a PCErr with error type 19, error value 3, "Unknown PLSP-ID" generate a PCErr with error type 19, error value 3, "Unknown PLSP-ID"
(see Section 8.4). (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
skipping to change at page 33, line 40 skipping to change at page 27, line 40
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].
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
skipping to change at page 34, line 20 skipping to change at page 28, 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-list> ::= <state-report>[<state-report-list>]
<state-report> ::= <SRP> <state-report> ::= <SRP>
<LSP> <LSP>
<path> <path>
Where:
<path>::= <ERO><attribute-list>
Where: Where:
<path> is defined in [RFC5440] and extended by PCEP extensions. <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is mandatory, and it MUST be The SRP object (see Section 7.2) is mandatory, and it MUST be
included for each LSP State Report in the PCRpt message. The value 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 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 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 the reserved value 0x00000000 if the state is not as a result of
processing a PCUpd message. If the PCC compressed several PCUpd processing a PCUpd message. If the PCC compressed several PCUpd
messages for the same LSP by only processing the latest one, then it 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 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- missing, the receiving PCE MUST send a PCErr message with Error-
skipping to change at page 36, line 5 skipping to change at page 30, line 8
missing) and Error-value=[TBD] (ERO object missing). 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 minimize the traffic interruption, and MAY use the
[RFC3209] in the re-signaling operation. During this process, two make-before-break procedures described in [RFC3209] in order to
achieve this goal. If the make-before-break procedures are used, two
paths will briefly co-exist. The PCC MUST send separate PCRpt paths will briefly co-exist. The PCC MUST send separate PCRpt
messages for each, identified by the LSP-IDENTIFIERS TLV. When the messages for each, identified by the LSP-IDENTIFIERS TLV. When the
old path is torn down after the head end switches over the traffic, old path is torn down after the head end switches over the traffic,
this event MUST be reported by sending a PCRpt message with the LSP- this event MUST be reported by sending a PCRpt message with the LSP-
IDENTIFIERS-TLV or the old path, and the R bit set. Thus, a make- IDENTIFIERS-TLV of the old path, and the R bit set. In this case,
before-break operation will typically result in at least two PCRpt the SRP object will have an SRP-id of 0. Thus, a make-before-break
messages, one for the new path and one for the removal of the old operation will typically result in at least two PCRpt messages, one
path (more messages may be possible if intermediate states are for the new path and one for the removal of the old path (more
reported). 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 it processed to indicate the resulting state of the LSP in Request it processed to indicate the resulting state of the LSP in
the network (even if this processing did not result in changing the the network (even if this processing did not result in changing the
state of the LSP). The SRP-ID-number included in the PCRpt MUST state of the LSP). The SRP-ID-number included in the PCRpt MUST
match that in the PCUpd. A PCC MAY respond with multiple LSP State match that in the PCUpd. A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case, Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included while the state of the LSP is the SRP-ID-number MUST be included for the first message, for
"pending", afterwards the reserved value 0x00000000 SHOULD be used.. subsequent messages the reserved value 0x00000000 SHOULD be used.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
If the rate of PCUpd messages sent to a PCC for the same target LSP If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network, exceeds the rate at which the PCC can signal LSPs into the network,
the PCC MAY perform state compression and only signal the last the PCC MAY perform state compression and only signal the last
modification in its queue, as the last PCUpd contains the most up-to- modification in its queue, as the last PCUpd contains the most up-to-
skipping to change at page 36, line 46 skipping to change at page 30, line 50
in quick succession and the PCC started the signaling of the changes in quick succession and the PCC started the signaling of the changes
relevant to the first PCUpd, then it MUST wait until the signaling relevant to the first PCUpd, then it MUST wait until the signaling
finishes (and report the new state via a PCRpt) before attempting to finishes (and report the new state via a PCRpt) before attempting to
apply the changes indicated in the second PCUpd. apply the changes indicated in the second PCUpd.
Note also that it is up to the PCE to handle inter-LSP dependencies; Note also that it is up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP set-ups is required, the PCE has to for example, if ordering of LSP 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 a PCErr message indicating the failure (see Section 7.3.3).
6.3. The PCErr Message 6.3. The PCErr Message
If the stateful PCE capability has been negotiated on the PCEP If the stateful PCE capability has been negotiated on the PCEP
session, the PCErr message MUST include the SRP object. If the error 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- reported is the result of an LSP update request, then the SRP-ID-
number MUST be the one from the PCUpd that triggered the error. If number MUST be the one from the PCUpd that triggered the error. If
it is unsolicited, the SRP-ID-number MUST be the reserved value it is unsolicited, the SRP-ID-number MUST be the reserved value
0x00000000. 0x00000000.
6.4. The PCReq Message 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.3) if the stateful PCE capability has been negotiated on a Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and a PCE. PCEP session between the PCC and a PCE.
The definition of the PCReq message from [RFC5440] and The definition of the PCReq message from [RFC5440] is extended to
[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally optionally include the LSP object after the END-POINTS object. The
include the LSP object after the END-POINTS object. For illustration encoding from [RFC5440] will become:
purposes, the encoding from [RFC5440] will become:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
Where: Where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
skipping to change at page 37, line 45 skipping to change at page 31, line 50
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
6.5. The PCRep Message 6.5. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see A PCE MAY include the LSP object in the PCRep message (see
(Section 7.3) if the stateful PCE capability has been negotiated on a (Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was PCEP session between the PCC and the PCE and the LSP object was
included in the corresponding PCReq message from the PCC. included in the corresponding PCReq message from the PCC.
The definition of the PCRep message from [RFC5440] and The definition of the PCRep message from [RFC5440] is extended to
[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally optionally include the LSP object after the RP object. The encoding
include the LSP object after the RP object. For illustration from [RFC5440] will become:
purposes, the encoding from [RFC5440] will become:
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
Where: Where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
[<LSP>] <--- New Object [<LSP>] <--- New Object
skipping to change at page 38, line 45 skipping to change at page 32, line 45
shown in the following figure: shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|U| | Flags |S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: STATEFUL-PCE-CAPABILITY TLV format Figure 12: STATEFUL-PCE-CAPABILITY 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 comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag
indicates that the PCC allows modification of LSP parameters; if indicates that the PCC allows modification of LSP parameters; if
set to 1 by a PCE, the U Flag indicates that the PCE is capable of set to 1 by a PCE, the U Flag indicates that the PCE is capable of
updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be
advertised by both a PCC and a PCE for PCUpd messages to be advertised by both a PCC and a PCE for PCUpd messages to be
skipping to change at page 39, line 45 skipping to change at page 33, line 45
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=8 | | Type=[TBD] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP State DB Version | | LSP State DB Version |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-DB-VERSION TLV format Figure 13: LSP-DB-VERSION TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer. The value contains a 64-bit unsigned integer.
7.1.3. PCE Redundancy Group Identifier TLV 7.1.3. PCE Redundancy Group Identifier TLV
PREDUNDANCY-GROUP-ID is an optional TLV that MAY be included in the PREDUNDANCY-GROUP-ID is an optional TLV that MAY be included in the
OPEN Object when a PCEP Speaker wishes to determine if State OPEN Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. It Synchronization can be skipped when a PCEP session is restarted. It
contains a unique identifier for the node that does not change during contains a unique identifier for the node that does not change during
skipping to change at page 40, line 27 skipping to change at page 34, line 27
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// PCE redundancy group Identifier // // PCE redundancy group Identifier //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: PREDUNDANCY-GROUP-ID TLV format Figure 14: 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. SRP Object 7.2. SRP Object
The SRP (Stateful PCE Request Parameters) object MUST be carried The SRP (Stateful PCE Request Parameters) object MUST be carried
within each PCUpd and PCRpt message and MAY be carried within PCNtf within each PCUpd and PCRpt message and MAY be carried within PCNtf
and PCEerr messages. The SRP object is used to correlate between and PCErr messages. The SRP object is used to correlate between
update requests sent by the PCE and the error reports and state 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 reports sent by the PCC.
the SRP object MUST be set to 0.
SRP Object-Class is [TBD]. SRP Object-Class is [TBD].
SRP Object-Type is 1. SRP Object-Type is 1.
The format of the SRP object body is shown in Figure 17: The format of the SRP object body is shown in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The SRP Object format Figure 15: The SRP Object format
The SRP object body has a variable length and may contain additional The SRP object body has a variable length and may contain additional
TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the
optional TLVs. optional TLVs.
Flags (32 bits): None defined yet. Flags (32 bits): None defined yet.
SRP-ID-number (32 bits): The SRP-ID-number value combined with the 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 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 operation that the PCE has requested the PCC to perform on a given
skipping to change at page 42, line 15 skipping to change at page 36, line 15
operation to be performed on the LSP, and LSP Delegation. It also operation to be performed on the LSP, and LSP Delegation. It also
contains a flag indicating to a PCE that the LSP state contains a flag indicating to a PCE that the LSP state
synchronization is in progress. This document focuses on LSPs that synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object are signaled with RSVP, many of the TLVs used with the LSP object
mirror RSVP state. mirror RSVP state.
LSP Object-Class is [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 18: The format of the LSP object body is shown in Figure 16:
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 | O|A|R|S|D| | PLSP-ID | Flags | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-sig-type | | Reserved | LSP-sig-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: The LSP Object format Figure 16: The LSP Object format
PLSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC
PLSP-ID for each LSP that is constant for the life time of a PCEP creates a unique PLSP-ID for each LSP that is constant for the life
session. The mapping of the Symbolic Path Name to PLSP-ID is time of a PCEP session. The mapping of the Symbolic Path Name to
communicated to the PCE by sending a PCRpt message containing the PLSP-ID is communicated to the PCE by sending a PCRpt message
SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages then address containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages
the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are reserved. then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are
Note that the PLSP-ID is a value that is constant for the life time reserved. Note that the PLSP-ID is a value that is constant for the
of the PCEP session, during which time for an RSVP-signaled LSP there life time of the PCEP session, during which time for an RSVP-signaled
might be a different RSVP identifiers (LSP-id, tunnel-id) allocated LSP there might be a different RSVP identifiers (LSP-id, tunnel-id)
it. 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 PCRpt sent
Report sent from a PCC during State Synchronization. The S Flag from a PCC during State Synchronization. The S Flag MUST be set
MUST be set to 0 otherwise. to 0 in other PCRpt messages sent from the PCC. The S flag MAY be
set to 1 in a PCUpd sent by the PCE (see section Section 5.4.2).
R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the
LSP has been removed from the PCC and the PCE SHOULD remove all LSP has been removed from the PCC and the PCE SHOULD remove all
state from its database. Upon receiving an LSP State Report with state from its database. Upon receiving an LSP State Report with
the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
remove all state for the path identified by the LSP Identifiers remove all state for the path identified by the LSP Identifiers
TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is
used, the PCE SHOULD remove all state for the PLSP-ID from its used, the PCE SHOULD remove all state for the PLSP-ID from its
database. database.
skipping to change at page 43, line 44 skipping to change at page 37, line 45
1 - UP: signalled. 1 - UP: signalled.
2 - ACTIVE: up and carrying traffic. 2 - ACTIVE: up and carrying traffic.
3 - GOING-DOWN: LSP is being torn down, resources are being 3 - GOING-DOWN: LSP is being torn down, resources are being
released. released.
4 - GOING-UP: LSP is being signalled. 4 - GOING-UP: LSP is being signalled.
5-7 - Reserved: these values MUST be set to 0 on transmission and 5-7 - Reserved: these values are reserved for future use.
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.
LSP-sig-type (8 bits) - identifies the method used for signaling the LSP-sig-type (8 bits) - identifies the method used for signaling the
LSP. If a PCEP speaker receives an LSP object with LSP-sig-type that 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 had not been previously negotiated, a PCErr with error type 19, error
value 5, "Unsupported LSP signaling type", (see Section 8.4) MUST be 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 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, particular LSP between the PCEP speakers, a PCErr with error type 19,
skipping to change at page 44, line 47 skipping to change at page 38, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 19: IPV4-LSP-IDENTIFIERS TLV format Figure 17: 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
skipping to change at page 45, line 48 skipping to change at page 39, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Extended Tunnel ID | | Extended Tunnel ID |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: IPV6-LSP-IDENTIFIERS TLV format Figure 18: 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 47, line 15 skipping to change at page 41, 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 21: SYMBOLIC-PATH-NAME TLV format Figure 19: 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.3.3. LSP Error Code TLV 7.3.3. LSP Error Code TLV
The LSP Error code TLV is an optional TLV for use in the LSP object The LSP Error code TLV is an optional TLV for use in the LSP object
to convey error information. When an LSP Update Request fails, an to convey error information. When an LSP Update Request fails, an
LSP State Report MUST be sent to report the current state of the LSP, LSP State Report MUST be sent to report the current state of the LSP,
and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for
skipping to change at page 47, line 41 skipping to change at page 41, line 41
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: LSP-ERROR-CODE TLV format Figure 20: 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 an error code that indicates the cause of the The value contains an error code that indicates the cause of the
failure. failure.
The following LSP Error Codes are defined: The following LSP Error Codes are defined:
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable PCUpd parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
7.3.4. RSVP Error Spec TLV 7.3.4. RSVP Error Spec TLV
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
to carry RSVP error information. It includes the RSVP ERROR_SPEC or to carry RSVP error information. It includes the RSVP ERROR_SPEC or
USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned
skipping to change at page 48, line 39 skipping to change at page 42, line 39
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object + + RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: RSVP-ERROR-SPEC TLV format Figure 21: RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a variable length. The value The type of the TLV is [TBD] and it has a variable length. The value
contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the
object header. object header.
7.3.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
is missing, the PCE will generate an error with error-type 6 is missing, the PCE will generate an error with error-type 6
(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 make changes to the LSP State Database Version,
encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were a PCC should never encounter this TLV in a message from the PCE
it to receive one from a PCE. (other than the OPEN message). A PCC SHOULD ignore the LSP-DB-
VERSION TLV, were it to receive one from a PCE.
7.3.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.4. Optional TLVs for the LSPA Object 7.4. Optional TLVs for the LSPA Object
skipping to change at page 51, line 48 skipping to change at page 46, line 4
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document 18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document 20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
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
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
(IDB)
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.7. LSP-ERROR-CODE TLV 8.7. LSP-ERROR-CODE TLV
This document requests that a registry is created to manage the value 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 of the LSP error code field in this TLV. This field specifies the
reason for failure to update the LSP. reason for failure to update the LSP.
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable PCUpd parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
8.8. LSP-SIG-TYPE field in the LSP object 8.8. LSP-SIG-TYPE field in the LSP object
This document requests that a registry is created to manage the value 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 of the LSP type field in the LSP object, which defines the technology
used for LSP setup. used for LSP setup.
skipping to change at page 57, line 19 skipping to change at page 51, line 27
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] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in
progress), October 2012. progress), July 2013.
[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
skipping to change at page 58, line 19 skipping to change at page 52, line 28
[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-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path
Computation Element (PCE)",
draft-ietf-pce-stateful-pce-app-00 (work in progress),
August 2013.
[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-02 (work in progress),
April 2013. July 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.
 End of changes. 96 change blocks. 
531 lines changed or deleted 244 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/