draft-ietf-pce-stateful-pce-06.txt   draft-ietf-pce-stateful-pce-07.txt 
Network Working Group E. Crabbe PCE 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: February 20, 2014 Cisco Systems, Inc. Expires: April 11, 2014 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
August 19, 2013 October 8, 2013
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-06 draft-ietf-pce-stateful-pce-07
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 February 20, 2014. This Internet-Draft will expire on April 11, 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 15 skipping to change at page 3, line 15
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? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 8 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 8
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 9
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 10 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 9
5. Architectural Overview of Protocol Extensions . . . . . . . . 10 5. Architectural Overview of Protocol Extensions . . . . . . . . 10
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 10 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 10
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 12 5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 12
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 15 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. PCE-triggered State Synchronization . . . . . . . . . 19 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 16
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 19 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 20 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 18
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 21 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 22 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 23 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 19
5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 23
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 24
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 24 Request/Response . . . . . . . . . . . . . . . . . . . 20
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 26 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 21
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 27 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 23
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 27 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 27 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 28 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 29 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 31 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 31 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 31 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 32 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 32 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 33 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 32
7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 34 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 34 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 38 7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 36
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 40 7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 37
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 42 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37
7.3.5. LSP State Database Version TLV . . . . . . . . . . . . 42 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 43 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37
7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 43 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38
7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 43 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 43 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44 9. Manageability Considerations . . . . . . . . . . . . . . . . . 39
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Control Function and Policy . . . . . . . . . . . . . . . 40
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 44 9.2. Information and Data Models . . . . . . . . . . . . . . . 41
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 45 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41
8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 46
8.8. LSP-SIG-TYPE field in the LSP object . . . . . . . . . . . 46
9. Manageability Considerations . . . . . . . . . . . . . . . . . 47
9.1. Control Function and Policy . . . . . . . . . . . . . . . 47
9.2. Information and Data Models . . . . . . . . . . . . . . . 48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 49 Components . . . . . . . . . . . . . . . . . . . . . . . . 41
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 42
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 43
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 50 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 12.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
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 Computation Element (PCE), or between PCEs, enabling (PCC) and a Path Computation Element (PCE), or between PCEs, enabling
computation of Multiprotocol Label Switching (MPLS) for Traffic computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP) characteristics. Extensions Engineering Label Switched Path (TE LSP) characteristics. Extensions
for support of Generalized MPLS (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]
skipping to change at page 6, line 41 skipping to change at page 6, line 41
PCC based on local policy. PCC based on local policy.
LSP State Report: an operation to send LSP state (Operational / LSP State Report: an operation to send LSP state (Operational /
Admin Status, LSP attributes configured 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
as defined in [RFC3209].
LSP State Database: information about all LSPs and their attributes. LSP State Database: information about all LSPs and their attributes.
Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, result in a
specific source being completely isolated from specific
destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the
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
3.1. Motivation 3.1. Motivation
skipping to change at page 10, line 11 skipping to change at page 10, line 5
o Enable uninterrupted operation of PCC's LSPs in the event of a 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 are required in PCEP to support stateful PCEs. Several new functions are required in PCEP to support stateful PCEs.
A function can be initiated either from a PCC towards a PCE (C-E) or A function can be initiated either from a PCC towards a PCE (C-E) or
from a PCE towards a PCC (E-C). The new functions are: from a PCE towards a PCC (E-C). The new functions are:
Capability negotiation (E-C,C-E): both the PCC and the PCE must Capability advertisement (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP announce during PCEP session establishment that they support PCEP
Stateful PCE extensions defined in this document. Stateful PCE extensions defined in this document.
LSP state synchronization (C-E): after the session between the PCC LSP state synchronization (C-E): after the session between the PCC
and a stateful PCE is initialized, the PCE must learn the state of and a stateful PCE is initialized, the PCE must learn the state of
a PCC's LSPs before it can perform path computations or update LSP a PCC's LSPs before it can perform path computations or update LSP
attributes in a PCC. attributes in a PCC.
LSP Update Request (E-C): A PCE requests modification of attributes LSP Update Request (E-C): A PCE requests modification of attributes
on a PCC's LSP. on a PCC's LSP.
skipping to change at page 11, line 24 skipping to change at page 11, line 18
delegate the LSPs to a different PCE, if the PCC get disconnected delegate the LSPs to a different PCE, if the PCC get disconnected
from a PCE with currently delegated LSPs from a PCE with currently delegated LSPs
5.2. New Messages 5.2. New Messages
In this document, we define the following new PCEP messages: In this document, we define the following new PCEP messages:
Path Computation State Report (PCRpt): a PCEP message sent by a PCC Path Computation State Report (PCRpt): a PCEP message sent by a PCC
to a PCE to report the status of one or more LSPs. Each LSP to a PCE to report the status of one or more LSPs. Each LSP
Status Report in a PCRpt message can contain the actual LSP's Status Report in a PCRpt message can contain the actual LSP's
path,bandwidth, operational and administrative status, etc. An path, bandwidth, operational and administrative status, etc. An
LSP Status Report carried on a PCRpt message is also used in LSP Status Report carried on a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. The delegation or revocation of control of an LSP to/from a PCE. The
PCRpt message is described in Section 6.1. PCRpt message is described in Section 6.1.
Path Computation Update Request (PCUpd): a PCEP message sent by a Path Computation Update Request (PCUpd): a PCEP message sent by a
PCE to a PCC to update LSP parameters, on one or more LSPs. Each PCE to a PCC to update LSP parameters, on one or more LSPs. Each
LSP Update Request on a PCUpd message MUST contain all LSP LSP Update Request on a PCUpd message MUST contain all LSP
parameters that a PCE wishes to set for a given LSP. An LSP parameters that a PCE wishes to be set for a given LSP. An LSP
Update Request carried on a PCUpd message is also used to return Update Request carried on a PCUpd message is also used to return
LSP delegations if at any point PCE no longer desires control of LSP delegations if at any point PCE no longer desires control of
an LSP. The PCUpd message is described in Section 6.2. an LSP. The PCUpd message is described in Section 6.2.
The new functions defined in Section 4 are mapped onto the new The new functions defined in Section 4 are mapped onto the new
messages as shown in the following table. messages as shown in the following table.
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| Function | Message | | Function | Message |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| Capability Negotiation (E-C,C-E) | Open | | Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt | | State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt | | LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd | | LSP Update Request (E-C) | PCUpd |
| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | | 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 1: New Function to Message Mapping
5.3. Capability Negotiation 5.3. Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
negotiate the use of stateful PCEP extensions. A PCEP Speaker advertise their support of stateful PCEP extensions. A PCEP Speaker
includes the "Stateful PCE Capability" TLV, described in includes the "Stateful PCE Capability" TLV, described in
Section 7.1.1, in the OPEN Object to advertise its support for PCEP Section 7.1.1, in the OPEN Object to advertise its support for PCEP
stateful extensions. The Stateful Capability TLV includes the 'LSP stateful extensions. The Stateful Capability TLV includes the 'LSP
Update' Flag that indicates whether the PCEP Speaker supports LSP Update' Flag that indicates whether the PCEP Speaker supports LSP
parameter updates. parameter updates.
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the Stateful PCE Capability TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP protocol extensions for stateful PCEs MUST NOT be used if The PCEP 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 but did not negotiate Speakers support the extensions of this draft but did not advertise
this capability, then a PCErr with code "Stateful PCE capability not this capability, then a PCErr with error-type 19 (Invalid Operation),
negotiated" (see Section 8.4) will be generated and the PCEP session error-value 2 (Attempted LSP Update Request if active stateful PCE
will be terminated. capability was not advertised)(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 error-type 19 (Invalid Operation) and
Section 8.4) SHOULD be generated. Note that even if the update error-value 1 (Attempted LSP Update Request for a non-delegated
capability has not been negotiated, a PCE can still receive LSP LSP).(see Section 8.4) SHOULD be generated. Note that even if the
Status Reports from a PCC and build and maintain an up to date view update capability has not been advertised, a PCE can still receive
of the state of the PCC's LSPs. LSP Status Reports from a PCC and build and maintain an up to date
view of the state of the PCC's LSPs.
5.4. State Synchronization 5.4. State Synchronization
The purpose of State Synchronization is to provide a checkpoint-in- The purpose of State Synchronization is to provide a checkpoint-in-
time state replica of a PCC's LSP state in a PCE. State time state replica of a PCC's LSP state in a PCE. State
Synchronization is performed immediately after the Initialization Synchronization is performed immediately after the Initialization
phase ([RFC5440]). phase ([RFC5440]).
During State Synchronization, a PCC first takes a snapshot of the During State Synchronization, a PCC first takes a snapshot of the
state of its LSPs state, then sends the snapshot to a PCE in a state of its LSPs state, then sends the snapshot to a PCE in a
sequence of LSP State Reports. Each LSP State Report sent during sequence of LSP State Reports. Each LSP State Report sent during
State Synchronization has the SYNC Flag in the LSP Object set to 1. State Synchronization has the SYNC Flag in the LSP Object set to 1.
The set of LSPs for which state is synchronized with a PCE is The set of LSPs for which state is synchronized with a PCE is
determined by negotiated stateful PCEP capabilities and PCC's local determined by advertised stateful PCEP capabilities and PCC's local
configuration (see more details in Section 9.1). configuration (see more details in Section 9.1).
The end of synchronization marker is a PCRpt message with the SYNC The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV value 0. 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 the PCC has no state to synchronize, it will only
Flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV, then the LSP- send the end of synchronization marker.
DB-VERSION TLV MUST be included and contain the PCC's latest LSP
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 Either the PCE or the PCC MAY terminate the session using the PCEP
state transfer, it MUST send a PCErr message to the PCE and terminate session termination procedures during the synchronization phase. If
the session using the PCEP session termination procedure. the session is terminated, the PCE MUST clean up state it received
from this PCC. The session reestablishment MUST be re-attempted per
the procedures defined in [RFC5440], including use of a back-off
timer.
In the event of a PCC resetting the session during synchronization, If the PCC encounters a problem which prevents it from completing the
the PCE MUST clean up state it received from this PCC. Session state transfer, it MUST send a PCErr message with error-type 20 (LSP
reestablishment MUST be re-attempted per the procedures defined in State Synchronization Error) and error-value 5 (indicating an
[RFC5440]. internal PCC error) to the PCE and terminate the session.
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgements for properly received
synchronization messages. It MUST respond with a PCErr message synchronization messages. It MUST respond with a PCErr message with
indicating "PCRpt error" (see Section 8.4) if it encounters a problem error-type 20 (LSP State Synchronization Error) and error-value 1
with the LSP State Report it received from the PCC. Either the PCE (indicating an error in processing the PCRpt) (see Section 8.4) if it
or the PCC MAY terminate the session if the PCE encounters a problem encounters a problem with the LSP State Report it received from the
during the synchronization. PCC and it MUST terminate the session.
A PCE implementing a limit on the resources a single PCC can occupy,
MUST send a PCErr message with error-type 19 (invalid operation) and
error-value 4 (indicating resource limit exceeded) in response to the
PCRpt message triggering this condition in the synchronization phase
and MUST terminate the session.
The successful State Synchronization sequence is shown in Figure 1. The successful State Synchronization sequence is shown in Figure 1.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| (Sync start) |-----PCRpt, SYNC=1----->| (Sync start)
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
skipping to change at page 15, line 23 skipping to change at page 15, line 23
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-------- PCErr=? ------>| |-------- PCErr=? ------>|
| | | |
Figure 3: Failed state synchronization (PCC failure) Figure 3: Failed state synchronization (PCC failure)
5.4.1. State Synchronization Avoidance Optimizations to the synchronization procedures and alternate
mechanisms of providing the synchronization function are outside the
State Synchronization MAY be skipped following a PCEP session restart scope of this document and are discussed elsewhere (see
if the state of both PCEP peers did not change during the period [I-D.minei-pce-stateful-sync-optimizations]).
prior to session re-initialization. To be able to make this
determination, state must be exchanged and maintained by both PCE and
PCC during normal operation. This is accomplished by keeping track
of the changes to the LSP State Database, using a database version
called the LSP State Database Version.
The LSP State Database version is an unsigned 64-bit value that MUST
be incremented by 1 for each successive change in the LSP state
database. The LSP State Database version MUST start at 1 and may
wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. The PCC
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.
Operations that trigger a change to the local LSP State database
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
that would trigger a report to the PCE. When State Synchronization
avoidance is enabled on a PCEP session, a PCC includes the LSP-DB-
VERSION TLV in the LSP Object on each LSP State Report. The LSP-DB-
VERSION TLV contains a PCC's LSP State Database version.
State Synchronization Avoidance is negotiated on a PCEP session
during session startup using the INCLUDE-DB-VERSION (IDB) bit in the
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.
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
LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the
PCC's latest LSP State Database version.
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 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
PCC's LSP State Database survived the restart of a PCEP session, the
PCC will include the LSP-DB-VERSION TLV in its OPEN object and the
TLV will contain the latest LSP State Database version sent on an LSP
State Report from the PCC in the previous PCEP session. If a PCEP
Speaker's LSP State Database did not survive the restart of a PCEP
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
Object and the TLV values match, the PCC MAY skip State
Synchronization. Otherwise, the PCC MUST perform State
Synchronization. If the PCC attempts to skip State Synchronization
(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
'LSP Database version mismatch', and close the PCEP session.
If state synchronization is required, then prior to completing the
Initialization phase, the PCE MUST mark any LSPs in the LSP database
that were previously reported by the PCC as stale. When the PCC
reports an LSP during state synchronization, if the LSP already
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
synchronization, the PCC MUST immediately send a PCRpt message
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
report indicates to the PCE that state synchronization has completed.
On receiving this state report, the PCE MUST purge any LSPs from the
LSP database that are still marked as stale.
Note that a PCE/PCC MAY force State Synchronization by not including
the LSP-DB-VERSION TLV in its OPEN object.
Figure 4 shows an example sequence where State Synchronization is
skipped.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| IDB=1 \ / DBv=42 |
| \/ IDB=1 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
| |
|--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->|
| |
Figure 4: State Synchronization skipped
Figure 5 shows an example sequence where State Synchronization is
performed due to LSP State Database version mismatch during the PCEP
session setup. Note that the same State Synchronization sequence
would happen if either the PCC or the PCE would not include the LSP-
DB-VERSION TLV in their respective Open messages.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 |
| \/ IDB=1 |
| /\ |
| / `-------->| (Expect sync)
(Do sync) |<--------` |
| |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=1-->| (Sync done)
| . |(Purge LSP State)
| . |
| . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 5: State Synchronization performed
Figure 6 shows an example sequence where State Synchronization is
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
PCE. If the current PCEP session restarts, the PCEP Speakers will
have to perform State Synchronization, since the PCE will not know
the PCC's latest LSP State Database version.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| IDB=0 \ / DBv=42 |
| \/ IDB=0 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->|
| |
Figure 6: State Synchronization skipped, no LSP-DB-VERSION TLVs sent
from PCC
5.4.2. PCE-triggered State Synchronization
Because the accuracy of the computations performed by the PCE is tied
to the accuracy of the view the PCE has on the state of the LSPs, it
can be beneficial to be able to resynchronize this state even after
the session has established. The PCE may use this approach to
continuously sanity check its state against the network, or to
recover from error conditions without having to tear down sessions.
To trigger a resynchronization with a PCC, the PCE MUST first mark
any LSPs in the LSP database that were previously reported by the PCC
as stale and then send a PCUpd for an LSP object containing a PLSP-ID
of 0 and with the SYNC flag set to 1. This PCUpd message is the
trigger for the PCC to enter the synchronization phase as described
in Section 5.4.1 and start sending PCRpt messages. After the receipt
of the end-of-synchronization marker, the PCE will purge LSPs which
were not refreshed.
5.5. LSP Delegation 5.5. LSP Delegation
If during Capability negotiation both the PCE and the PCC have If during Capability advertisement both the PCE and the PCC have
indicated that they support LSP Update, then the PCC may choose to indicated that they support LSP Update, then the PCC may choose to
grant the PCE a temporary right to update (a subset of) LSP grant the PCE a temporary right to update (a subset of) LSP
attributes on one or more LSPs. This is called "LSP Delegation", and attributes on one or more LSPs. This is called "LSP Delegation", and
it MAY be performed at any time after the Initialization phase, it MAY be performed at any time after the Initialization phase,
including during the State Synchronization phase. including during the State Synchronization phase.
LSP Delegation is controlled by operator-defined policies on a PCC. LSP Delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually - different LSPs may be delegated to LSPs are delegated individually - different LSPs may be delegated to
different PCEs. An LSP is delegated to at most one PCE at any given different PCEs. An LSP is delegated to at most one PCE at any given
point in time. The delegation policy, when all PCC's LSPs are point in time. The delegation policy, when all PCC's LSPs are
delegated to a single PCE at any given time, SHOULD be supported by delegated to a single PCE at any given time, SHOULD be supported by
all delegation-capable PCCs. Conversely, the policy revoking the all delegation-capable PCCs. Conversely, the policy revoking the
delegation for all PCC's LSPs SHOULD also be supported delegation for all PCC's LSPs SHOULD also be supported.
A PCE may return LSP delegation at any time if it no longer wishes to A PCE may return LSP delegation at any time if it no longer wishes to
update the LSP's state. A PCC may revoke LSP delegation at any time. update the LSP's state. A PCC may revoke LSP delegation at any time.
Delegation, Revocation, and Return are done individually for each Delegation, Revocation, and Return are done individually for each
LSP. LSP.
In the event of an delegation being rejected or returned by a PCE, In the event of an delegation being rejected or returned by a PCE,
the PCC should react based on local policy. It can, for example, the PCC should react based on local policy. It can, for example,
either retry delegating to the same PCE using an exponentially either retry delegating to the same PCE using an exponentially
increasing timer or delegate to an alternate PCE. increasing timer or delegate to an alternate PCE.
skipping to change at page 20, line 35 skipping to change at page 16, line 16
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 7. The delegation sequence is shown in Figure 4.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP Delegated |---PCRpt, Delegate=1--->| LSP Delegated
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| . | | . |
| . | | . |
| . | | . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
Figure 7: Delegating an LSP
Figure 4: Delegating an LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE. the Delegate flag to 1 on each LSP Status Report sent to the PCE.
5.5.2. Revoking a Delegation 5.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 21, line 29 skipping to change at page 17, line 10
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 8. shown in Figure 5.
+-+-+ +-+-+ +-+-+ +-+-+
|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 8: Revoking a Delegation Figure 5: Revoking a Delegation
After an LSP delegation has been revoked, a PCE can no longer update After an LSP delegation has been revoked, a PCE can no longer update
LSP's parameters; an attempt to update parameters of a non-delegated LSP's parameters; an attempt to update parameters of a non-delegated
LSP will result in the PCC sending a PCErr message indicating "LSP is LSP will result in the PCC sending a PCErr message with error-type 19
not delegated" (see Section 8.4). (Invalid Operation), error-value 1 (attempted LSP Update Request for
a non-delegated LSP) (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
original PCE can be reestablished before the Redelegation Timeout original PCE can be reestablished before the Redelegation Timeout
Interval timer expires, LSP delegations to the PCE remain intact. Interval timer expires, LSP delegations to the PCE remain intact.
Likewise, when a PCC's PCEP session with a PCE terminates Likewise, when a PCC's PCEP session with a PCE terminates
unexpectedly, the PCC MUST wait for the State Timeout Interval before unexpectedly, the PCC MUST wait for the State Timeout Interval before
skipping to change at page 22, line 26 skipping to change at page 18, line 8
the delegation. In this case, the PCC SHALL flush any LSP state set the delegation. In this case, the PCC SHALL flush any LSP state set
by the PCE upon expiration of the State Timeout Interval and revert by the PCE upon expiration of the State Timeout Interval and revert
to operator-defined default parameters. This operation SHOULD be to operator-defined default parameters. This operation SHOULD be
done in a make-before-break fashion. done in a make-before-break fashion.
The State Timeout Interval SHOULD be greater than or equal to the The State Timeout Interval SHOULD be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact). set by the PCE, they will remain intact).
If State Synchronization Avoidance is enabled, a PCC MUST increment
its LSP State Database version when the 'Redelegation Timeout
Interval' timer expires.
5.5.3. Returning a Delegation 5.5.3. Returning a Delegation
A PCE that no longer wishes to update an LSP's parameters SHOULD A PCE that no longer wishes to update an LSP's parameters SHOULD
return the LSP delegation back to the PCC by sending an empty LSP return the LSP delegation back to the PCC by sending an empty LSP
Update Request which has the Delegate flag set to 0. Note that in Update Request which has the Delegate flag set to 0. Note that in
order to keep a delegation, the PCE MUST set the Delegate flag to 1 order to keep a delegation, the PCE MUST set the Delegate flag to 1
on each LSP Update Request sent to the PCC. on each LSP Update Request sent to the PCC.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
skipping to change at page 22, line 51 skipping to change at page 18, line 29
| | | |
|---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 9: Returning a Delegation Figure 6: Returning a Delegation
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC stateful PCE accepts the delegation), the LSP delegation on the PCC
will time out within a configurable Redelegation Timeout Interval and will time out within a configurable Redelegation Timeout Interval and
the PCC MUST flush any LSP state set by a PCE at the expiration of the PCC MUST flush any LSP state set by a PCE at the expiration of
the State Timeout Interval. the State Timeout Interval.
5.5.4. Redundant Stateful PCEs 5.5.4. Redundant Stateful PCEs
Note that a PCE may not have any delegated LSPs: in a redundant In a redundant configuration where one PCE is backing up another PCE,
configuration where one PCE is backing up another PCE, the backup PCE the backup PCE may have only a subset of the LSPs in the network
may have a subset of the LSPs in the network delegated to it. The delegated to it. The backup PCE does not update any LSPs that are
backup PCE does not update any LSPs that are not delegated to it. In not delegated to it. In order to allow the backup to operate in a
order to allow the backup to operate in a hot-standby mode and avoid hot-standby mode and avoid the need for state synchronization in case
the need for state synchronization in case the primary fails, the the primary fails, the backup receives all LSP State Reports from a
backup receives all LSP State Reports from a PCC. When the primary PCC. When the primary PCE for a given LSP set fails, after expiry of
PCE for a given LSP set fails, after expiry of the Redelegation the Redelegation Timeout Interval, the PCC SHOULD delegate to the
Timeout Interval, the PCC SHOULD delegate to the redundant PCE all redundant PCE all LSPs that had been previously delegated to the
LSPs that had been previously delegated to the failed PCE. Assuming failed PCE. Assuming that the State Timeout Interval had been
that the State Timeout Interval had been configured to be larger than configured to be larger than the Redelegation Timeout Interval (as
the Redelegation Timeout Interval (as recommended), this delegation recommended), this delegation change will not cause any changes to
change will not cause any changes to the LSP parameters. 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.
skipping to change at page 24, line 39 skipping to change at page 20, line 29
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 10: Passive Stateful PCE Path Computation Request/Response Figure 7: Passive Stateful PCE Path Computation Request/Response
Once a PCC has successfully established a PCEP session with a passive Once a PCC has successfully established a PCEP session with a passive
stateful PCE and the PCC's LSP state is synchronized with the PCE stateful PCE and the PCC's LSP state is synchronized with the PCE
(i.e. the PCE knows about all PCC's existing LSPs), if an event is (i.e. the PCE knows about all 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).
LSP for which the path computation is requested.
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation and returns either a positive or a triggers a path computation and returns either a positive or a
negative reply to the PCC ([RFC5440], Section 4.2.4). negative reply to the PCC ([RFC5440], Section 4.2.4).
Upon receiving a positive path computation reply, the PCC receives a Upon receiving a positive path computation reply, the PCC receives a
set of computed paths and starts to setup the LSPs. For each LSP, it set of computed paths and starts to setup the LSPs. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Pending'. indicating that the LSP's status is 'Pending'.
skipping to change at page 26, line 28 skipping to change at page 21, line 50
| | | |
| | | |
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 11: Active Stateful PCE Figure 8: Active Stateful PCE
Once a PCC has successfully established a PCEP session with an active Once a PCC has successfully established a PCEP session with an active
stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.
the PCE knows about all PCC's existing LSPs) and LSPs have been the PCE knows about all PCC's existing LSPs) 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 26, line 51 skipping to change at page 22, line 26
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 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 (Invalid Operation), error-value
(see Section 8.4). 3, (Attempted LSP Update Request for an LSP identified by an unknown
PSP-ID) (see Section 8.4).
Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
to the PCE, indicating that the LSP's status is 'Up'. If the LSP to the PCE, indicating that the LSP's status is 'Up'. If the LSP
could not be set up, the PCC sends an LSP State Report indicating could not be set up, the PCC sends an LSP State Report indicating
that the LSP is 'Down' and stating the cause of the failure. A PCC that the LSP is 'Down' and stating the cause of the failure. A PCC
may choose to compress LSP State Reports to only reflect the most up may choose to compress LSP State Reports to only reflect the most up
to date state, as discussed in the previous section. to date state, as discussed in the previous section.
A PCC sends each LSP State Report to each stateful PCE that is A PCC sends each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
skipping to change at page 28, line 26 skipping to change at page 24, line 11
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: Where:
<path>::= <ERO><attribute-list> <path>::= <ERO><attribute-list>[<RRO>]
Where: Where:
<attribute-list> 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 optional. If the PCRpt message
included for each LSP State Report in the PCRpt message. The value is not in response to a PCupd message, the SRP object MAY be omitted.
of the SRP-ID-number in the SRP Object MUST be the same as that sent When the PCC does not include the SRP object, the PCE treats this as
in the PCUpd message that triggered the state that is reported, or an SRP object with an SRP-ID-number equal to the reserved value
the reserved value 0x00000000 if the state is not as a result of 0x00000000. The reserved value 0x00000000 indicates that the state
processing a PCUpd message. If the PCC compressed several PCUpd reported is not as a result of processing a PCUpd message.
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 If the PCRpt message is in response to a PCUpd message, the SRP
missing, the receiving PCE MUST send a PCErr message with Error- object SHOULD be included and the value of the SRP-ID-number in the
type=6 (Mandatory Object missing) and Error-value=[TBD] (SRP object SRP Object MUST be the same as that sent in the PCUpd message that
missing). No state compression is allowed for state reporting. The triggered the state that is reported. If the PCC compressed several
PCC MUST explicitly report state changes (including removal) for PCUpd messages for the same LSP by only processing the latest one,
paths it manages. then it should use the SRP-ID-number of that request. No state
compression is allowed for state reporting, e.g. PCRpt messages MUST
NOT be pruned from the PCC's egress queue even if subsequent
operations on the same LSP have been completed before the PCRpt
message has been sent to the TCP stack. The PCC MUST explicitly
report state changes (including removal) for paths it manages.
The LSP object (see Section 7.3) is mandatory, and it MUST be The LSP object (see Section 7.3) is mandatory, and it MUST be
included in each LSP State Report on the PCRpt message. If the LSP included in each LSP State Report on the PCRpt message. If the LSP
object is missing, the receiving PCE MUST send a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP
object missing). object missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The RRO SHOULD be included by the PCC when the path is up, but MAY be
omitted if the path is down due to a signaling error or another
failure.
A PCE may choose to implement a limit on the resources a single PCC
can occupy. If a PCRpt is received that causes the PCE to exceed
this limit, it MUST send a PCErr message with error-type 19 (invalid
operation) and error-value 4 (indicating resource limit exceeded) in
response to the PCRpt message triggering this condition and MAY
terminate the session.
6.2. The PCUpd Message 6.2. The PCUpd Message
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCUpd message is set to [TBD]. the PCUpd message is set to [TBD].
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
skipping to change at page 29, line 41 skipping to change at page 25, line 42
<path>::= <ERO><attribute-list> <path>::= <ERO><attribute-list>
Where: Where:
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions. <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
There are three mandatory objects that MUST be included within each There are three mandatory objects that MUST be included within each
LSP Update Request in the PCUpd message: the SRP Object (see LSP Update Request in the PCUpd message: the SRP Object (see
Section 7.2), the LSP object (see Section 7.3) and the ERO object (as Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
defined in [RFC5440]. If the SRP object is missing, the receiving defined in [RFC5440]. If the SRP object is missing, the receiving
PCC MUST send a PCErr message with Error-type=6 (Mandatory Object PCC MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=[TBD] (SRP object missing). If the LSP missing) and Error-value=10 (SRP object missing). If the LSP object
object is missing, the receiving PCC MUST send a PCErr message with is missing, the receiving PCC MUST send a PCErr message with Error-
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP type=6 (Mandatory Object missing) and Error-value=8 (LSP object
object missing). If the ERO object is missing, the receiving PCC missing). If the ERO object is missing, the receiving PCC MUST send
MUST send a PCErr message with Error-type=6 (Mandatory Object a PCErr message with Error-type=6 (Mandatory Object missing) and
missing) and Error-value=[TBD] (ERO object missing). Error-value=9(ERO object missing).
A PCC only acts on an LSP Update Request if permitted by the local A PCC only acts on an LSP Update Request if permitted by the local
policy configured by the network manager. Each LSP Update Request policy configured by the network manager. Each LSP Update Request
that the PCC acts on results in an LSP setup operation. An LSP that the PCC acts on results in an LSP setup operation. An LSP
Update Request MUST contain all LSP parameters that a PCE wishes to Update Request MUST contain all LSP parameters that a PCE wishes to
set for the LSP. A PCC MAY set missing parameters from locally be set for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Update Request is configured defaults. If the LSP specified in the Update Request is
already up, it will be re-signaled. already up, it will be re-signaled.
The PCC SHOULD minimize the traffic interruption, and MAY use the The PCC SHOULD minimize the traffic interruption, and MAY use the
make-before-break procedures described in [RFC3209] in order to make-before-break procedures described in [RFC3209] in order to
achieve this goal. If the make-before-break procedures are used, two achieve this goal. If the make-before-break procedures are used, two
paths will briefly co-exist. The PCC MUST send separate PCRpt paths will briefly co-exist. The PCC MUST send separate PCRpt
messages for each, identified by the LSP-IDENTIFIERS TLV. When the messages for each, identified by the LSP-IDENTIFIERS TLV. When the
old path is torn down after the head end switches over the traffic, old path is torn down after the head end switches over the traffic,
this event MUST be reported by sending a PCRpt message with the LSP- this event MUST be reported by sending a PCRpt message with the LSP-
IDENTIFIERS-TLV of the old path, and the R bit set. In this case, IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number
the SRP object will have an SRP-id of 0. Thus, a make-before-break that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a
operation will typically result in at least two PCRpt messages, one make-before-break operation will typically result in at least two
for the new path and one for the removal of the old path (more PCRpt messages, one for the new path and one for the removal of the
messages may be possible if intermediate states are reported). old path (more messages may be possible if intermediate states are
reported).
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request it processed to indicate the resulting state of the LSP in Request it processed to indicate the resulting state of the LSP in
the network (even if this processing did not result in changing the the network (even if this processing did not result in changing the
state of the LSP). The SRP-ID-number included in the PCRpt MUST state of the LSP). The SRP-ID-number included in the PCRpt MUST
match that in the PCUpd. A PCC MAY respond with multiple LSP State match that in the PCUpd. A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case, Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included for the first message, for the SRP-ID-number MUST be included for the first message, for
subsequent messages the reserved value 0x00000000 SHOULD be used. subsequent messages the reserved value 0x00000000 SHOULD be used.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
If the rate of PCUpd messages sent to a PCC for the same target LSP If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network, exceeds the rate at which the PCC can signal LSPs into the network,
the PCC MAY perform state compression and only signal the last the PCC MAY perform state compression on its ingress queue. The
modification in its queue, as the last PCUpd contains the most up-to- compression algorithm is based on the fact that each PCUpd request
date desired state for the LSP. If two PCUpd arrive for the same LSP contains the complete LSP state the PCE wishes to be set and works as
in quick succession and the PCC started the signaling of the changes follows: when the PCC starts processing a PCUpd message at the head
relevant to the first PCUpd, then it MUST wait until the signaling of its ingress queue, it may search the queue forward for more recent
finishes (and report the new state via a PCRpt) before attempting to PCUpd messages pertaining that particular LSP, prune all but the
apply the changes indicated in the second PCUpd. latest one from the queue and process only the last one as that
request contains the most up-to-date desired state for the LSP. The
PCC MUST NOT send PCRpt nor PCErr messages for requests which were
pruned from the queue in this way. This compression step may be
performed only while the LSP is not being signaled, e.g. if two PCUpd
arrive for the same LSP in quick succession and the PCC started the
signaling of the changes relevant to the first PCUpd, then it MUST
wait until the signaling finishes (and report the new state via a
PCRpt) before attempting to apply the changes indicated in the second
PCUpd.
Note also that it is up to the PCE to handle inter-LSP dependencies; 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
a PCErr message indicating the failure (see Section 7.3.3). 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 advertised on the PCEP
session, the PCErr message MUST include the SRP object. If the error session, the PCErr message MAY include the SRP object. If the error
reported is the result of an LSP update request, then the SRP-ID- reported is the result of an LSP update request, then the SRP-ID-
number MUST be the one from the PCUpd that triggered the error. If number MUST be the one from the PCUpd that triggered the error. If
it is unsolicited, the SRP-ID-number MUST be the reserved value the error is unsolicited, the SRP object MAY be omitted. This is
0x00000000. equivalent to including an SRP object with SRP-ID-number equal to the
reserved value 0x00000000.
6.4. The PCReq Message
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
PCEP session between the PCC and a PCE.
The definition of the PCReq message from [RFC5440] is extended to
optionally include the LSP object after the END-POINTS object. The
encoding from [RFC5440] will become:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>] <--- New Object
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
6.5. The PCRep Message The format of a PCErr message from [RFC5440] is extended as follows:
A PCE MAY include the LSP object in the PCRep message (see <PCErr Message> ::= <Common Header>
(Section 7.3) if the stateful PCE capability has been negotiated on a ( <error-obj-list> [<Open>] ) | <error>
PCEP session between the PCC and the PCE and the LSP object was [<error-list>]
included in the corresponding PCReq message from the PCC.
The definition of the PCRep message from [RFC5440] is extended to <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
optionally include the LSP object after the RP object. The encoding
from [RFC5440] will become:
<PCRep Message> ::= <Common Header> <error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new
<response-list> <error-obj-list>
Where: <request-id-list>::=<RP>[<request-id-list>]
<response-list>::=<response>[<response-list>] <stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new
<response>::=<RP> <error-list>::=<error>[<error-list>]
[<LSP>] <--- New Object
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
7. Object Formats 7. Object Formats
The PCEP objects defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document MUST always be set to 0 on PCEP objects defined in this document MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST be ignored on receipt since these flags are
exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines two new optional TLVs for use in the OPEN This document defines two new optional TLVs for use in the OPEN
Object. Object.
7.1.1. Stateful PCE Capability TLV 7.1.1. Stateful PCE Capability TLV
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
OPEN Object for stateful PCE capability negotiation. Its format is OPEN Object for stateful PCE capability advertisement. Its format is
shown in the following figure: shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|U| | Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: STATEFUL-PCE-CAPABILITY TLV format Figure 9: 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
allowed on a PCEP session. allowed on a PCEP session.
S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers,
the PCC will include the LSP-DB-VERSION TLV in each LSP Object.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
Negotiation of the stateful PCE capability implies support of LSPs Advertisement of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs and that are signaled via RSVP, as well as the objects, TLVs and
procedures defined in this document. procedures defined in this document.
7.1.2. LSP State Database Version TLV
LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN
Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. If
sent from a PCE, the TLV contains the local LSP State Database
version from the last valid LSP State Report received from a PCC. If
sent from a PCC, the TLV contains the PCC's local LSP State Database
version, which is incremented each time the LSP State Database is
updated.
The format of the LSP-DB-VERSION TLV is shown in the following
figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP State DB Version |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: LSP-DB-VERSION TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer.
7.1.3. PCE Redundancy Group Identifier TLV
PREDUNDANCY-GROUP-ID is an optional TLV that MAY be included in the
OPEN Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. It
contains a unique identifier for the node that does not change during
the life time of the PCEP Speaker. It identifies the PCEP Speaker to
its peers if the Speaker's IP address changed.
The format of the PREDUNDANCY-GROUP-ID TLV is shown in the following
figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE redundancy group Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PREDUNDANCY-GROUP-ID TLV format
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 unique in the network. The node identifier MAY be configured
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
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 PCUpd messages and MAY be carried within PCRpt, PCNtf and
and PCErr messages. The SRP object is used to correlate between PCErr messages. The SRP object is used to correlate between update
update requests sent by the PCE and the error reports and state requests sent by the PCE and the error reports and state reports sent
reports sent by the PCC. by the PCC.
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 15: The format of the SRP object body is shown in Figure 10:
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 15: The SRP Object format Figure 10: The SRP Object format
The SRP object body has a variable length and may contain additional The SRP object body has a variable length and may contain additional
TLVs. 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 in the scope of the
source IP address of the PCC and the PCE uniquely identify the current PCEP session uniquely identify the operation that the PCE has
operation that the PCE has requested the PCC to perform on a given requested the PCC to perform on a given LSP. The SRP-ID-number is
LSP. The SRP-ID-number is incremented each time a new request is incremented each time a new request is sent to the PCC, and may wrap
sent to the PCC, and may wrap around. around.
The values 0x00000000 and 0xFFFFFFFF are reserved. The values 0x00000000 and 0xFFFFFFFF are reserved.
Every request to update an LSP receives a new SRP-ID-number. This Every request to update an LSP receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an number is unique per PCEP session and is incremented each time an
operation is requested from the PCE. Thus, for a given LSP there may operation is requested from the PCE. Thus, for a given LSP there may
be more than one SRP-id-number unacknowledged at a given time. The be more than one SRP-id-number unacknowledged at a given time. The
value of the SRP-ID-number is echoed back by the PCC in PCErr and value of the SRP-ID-number is echoed back by the PCC in PCErr and
PCRpt messages to allow for correlation between requests made by the PCRpt messages to allow for correlation between requests made by the
PCE and errors or state reports generated by the PCC. If the error PCE and errors or state reports generated by the PCC. If the error
or report were not as a result of a PCE operation (for example in the or report were not as a result of a PCE operation (for example in the
case of a link down event), then the reserved value of 0x00000000 is case of a link down event), the reserved value of 0x00000000 is used
used instead. An SRP-ID-number is considered unacknowledged and for the SRP-ID-number. The absence of the SRP object is equivalent
cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number to an SRP object with the reserved value of 0x00000000. An SRP-ID-
equal or higher for the same LSP. A PCRpt with state "Pending" is number is considered unacknowledged and cannot be reused until a
not considered as an acknowledgement. PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the
same LSP. A PCRpt with state "Pending" is not considered as an
acknowledgement.
7.3. LSP Object 7.3. LSP Object
The LSP object MUST be present within PCRpt and PCUpd messages. The The LSP object MUST be present within PCRpt and PCUpd messages. The
LSP object MAY be carried within PCReq and PCRep messages if the LSP object contains a set of fields used to specify the target LSP,
stateful PCE capability has been negotiated on the session. The LSP the operation to be performed on the LSP, and LSP Delegation. It
object contains a set of fields used to specify the target LSP, the also contains a flag indicating to a PCE that the LSP state
operation to be performed on the LSP, and LSP Delegation. It also
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 16: The format of the LSP object body is shown in Figure 11:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flags | O|A|R|S|D| | PLSP-ID | Flags | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-sig-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The LSP Object format Figure 11: The LSP Object format
PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC
creates a unique PLSP-ID for each LSP that is constant for the life creates a unique PLSP-ID for each LSP that is constant for the life
time of a PCEP session. The mapping of the Symbolic Path Name to time of a PCEP session. The mapping of the Symbolic Path Name to
PLSP-ID is communicated to the PCE by sending a PCRpt message PLSP-ID is communicated to the PCE by sending a PCRpt message
containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages
then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are
reserved. Note that the PLSP-ID is a value that is constant for the reserved. Note that the PLSP-ID is a value that is constant for the
life time of the PCEP session, during which time for an RSVP-signaled life time of the PCEP session, during which time for an RSVP-signaled
LSP there might be a different RSVP identifiers (LSP-id, tunnel-id) LSP there might be a different RSVP identifiers (LSP-id, tunnel-id)
skipping to change at page 37, line 8 skipping to change at page 31, line 9
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP Delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation - the first PCRpt with the D flag
set to 0 revokes the delegation. To keep the delegation, the PCE set to 0 revokes the delegation. To keep the delegation, the PCE
must set the D flag to 1 on each PCUpd message for the duration of must set the D flag to 1 on each PCUpd message for the duration of
the delegation - the first PCUpd with the D flag set to 0 returns the delegation - the first PCUpd with the D flag set to 0 returns
the delegation. the delegation.
S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent
from a PCC during State Synchronization. The S Flag MUST be set from a PCC during State Synchronization. The S Flag MUST be set
to 0 in other PCRpt messages sent from the PCC. The S flag MAY be to 0 in other PCRpt messages sent from the PCC.
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 37, line 50 skipping to change at page 31, line 50
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 are reserved for future use. 5-7 - Reserved: these values are reserved for future use.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
LSP-sig-type (8 bits) - identifies the method used for signaling the TLVs that may be included in the LSP Object are described in the
LSP. If a PCEP speaker receives an LSP object with LSP-sig-type that following sections.
had not been previously negotiated, a PCErr with error type 19, error
value 5, "Unsupported LSP signaling type", (see Section 8.4) MUST be
sent. If there is a mismatch in the LSP signaling type for a
particular LSP between the PCEP speakers, a PCErr with error type 19,
error value 4, "Mismatched LSP signaling type" (see Section 8.4) MUST
be sent by the party identifying the mismatch.
Optional TLVs that may be included in the LSP Object are described in
the following sections.
7.3.1. LSP Identifiers TLVs 7.3.1. LSP Identifiers TLVs
The LSP Identifiers TLV MUST be included in the LSP object in PCRpt The LSP Identifiers TLV MUST be included in the LSP object in PCRpt
messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will
generate an error with error-type 6 (mandatory object missing) and generate an error with error-type 6 (mandatory object missing) and
Error Value 11 (LSP-IDENTIFIERS TLV missing) and close the session. error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
The LSP Identifiers TLV MAY be included in the LSP object in PCUpd The LSP Identifiers TLV MAY be included in the LSP object in PCUpd
messages for RSVP-signaled LSPs. The special value of all zeros for messages for RSVP-signaled LSPs. The special value of all zeros for
this TLV is used to refer to all paths pertaining to a particular this TLV is used to refer to all paths pertaining to a particular
PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one
for IPv6. for IPv6.
It is the responsibility of the PCC to send to the PCE the It is the responsibility of the PCC to send to the PCE the
identifiers for each RSVP incarnation of the tunnel. For exmple, in identifiers for each RSVP incarnation of the tunnel. For exmple, in
a make-before-break scenario, the PCC MUST send a separate PCRpt for a make-before-break scenario, the PCC MUST send a separate PCRpt for
the old and for the reoptimized paths, and explicitly report removal the old and for the reoptimized paths, and explicitly report removal
skipping to change at page 38, line 46 skipping to change at page 32, line 37
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=12 | | Type=[TBD] | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IPV4-LSP-IDENTIFIERS TLV format Figure 12: IPV4-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 12 octets. The type of the TLV is [TBD] and it has a fixed length of 12 octets.
The value contains the following fields: The value contains the following fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object. Object.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.1 for the identifier defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Session Object. LSP_TUNNEL_IPv4 Session Object.
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4
address, as defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Sender Template Object.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=36 | | Type=[TBD] | Length=36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 39, line 47 skipping to change at page 33, line 43
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Extended Tunnel ID | | Extended Tunnel ID |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel endpoint address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: IPV6-LSP-IDENTIFIERS TLV format Figure 13: 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 40, line 25 skipping to change at page 34, line 28
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa). switches over from primary LSP to secondary LSP (or vice versa).
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.2 for the identifier defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
IPv6 Tunnel Endpoint Address: contains the egress node's IPv6
address, as defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object.
7.3.2. Symbolic Path Name TLV 7.3.2. Symbolic Path Name TLV
Each LSP (path) MUST have a symbolic name that is unique in the PCC. Each LSP (path) MUST have a symbolic name that is unique in the PCC.
This symbolic path name MUST remain constant throughout a path's This symbolic path name MUST remain constant throughout a path's
lifetime, which may span across multiple consecutive PCEP sessions lifetime, which may span across multiple consecutive PCEP sessions
and/or PCC restarts. The symbolic path name MAY be specified by an and/or PCC restarts. The symbolic path name MAY be specified by an
operator in a PCC's configuration. If the operator does not specify operator in a PCC's configuration. If the operator does not specify
a unique symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
skipping to change at page 41, line 15 skipping to change at page 35, 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 19: SYMBOLIC-PATH-NAME TLV format Figure 14: 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 41, line 41 skipping to change at page 35, 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 20: LSP-ERROR-CODE TLV format Figure 15: 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
skipping to change at page 42, line 39 skipping to change at page 36, 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 21: RSVP-ERROR-SPEC TLV format Figure 16: 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
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
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
message are listed.
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-
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
(mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV
missing) and close the session. If State Synchronization Avoidance
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
were it to receive one.
Since a PCE does not make changes to the LSP State Database Version,
a PCC should never encounter this TLV in a message from the 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
Multiple delegation parameters, such as sub-delegation permissions,
authentication parameters, etc. need to be communicated from a PCC to
a PCE during the delegation operation. Delegation parameters will be
carried in multiple delegation parameter TLVs, which will be defined
in future revisions of this document.
7.4. Optional TLVs for the LSPA Object 7.4. Optional TLVs for the LSPA Object
TLVs that may be included in the LSPA Object are described in the TLVs that may be included in the LSPA Object are described in the
following sections and in separate technology-specific documents. following sections and in separate technology-specific documents.
7.4.1. Symbolic Path Name TLV 7.4.1. Symbolic Path Name TLV
See section Section 7.3.2. See section Section 7.3.2.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 45, line 11 skipping to change at page 38, line 24
This document defines new Error-Type and Error-Value for the This document defines new Error-Type and Error-Value for the
following new error conditions: following new error conditions:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=9: ERO Object missing
Error-value=10: SRP Object missing Error-value=10: SRP Object missing
Error-value=11: LSP-IDENTIFIERS TLV missing Error-value=11: LSP-IDENTIFIERS TLV missing
Error-value=12: LSP-DB-VERSION TLV missing
19 Invalid Operation 19 Invalid Operation
Error-value=1: Attempted LSP Update Request for a non- Error-value=1: Attempted LSP Update Request for a non-
delegated LSP. The PCEP-ERROR Object delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that is followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: Attempted LSP Update Request if active Error-value=2: Attempted LSP Update Request if active
stateful PCE capability was not stateful PCE capability was not
negotiated active PCE. advertised.
Error-value=3: Attempted LSP Update Request for an LSP Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID. identified by an unknown PLSP-ID.
Error-value=4: Mismatched LSP signaling type. Error-value=4: A PCE indicates to a PCC that it has
Error-value=5: Unsupported LSP signaling type. exceeded the resource limit allocated
for its state, and thus it cannot
accept and process its LSP State Report
message.
20 LSP State synchronization error. 20 LSP State synchronization error.
Error-value=1: A PCE indicates to a PCC that it can Error-value=1: A PCE indicates to a PCC that it can
not process (an otherwise valid) LSP not process (an otherwise valid) LSP
State Report. The PCEP-ERROR Object is State Report. The PCEP-ERROR Object is
followed by the LSP Object that followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: LSP Database version mismatch. Error-value=5: A PCC indicates to a PCE that it can
Error-value=3: The LSP-DB-VERSION TLV Missing when not complete the state synchronization,
State Synchronization Avoidance
enabled.
8.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document 18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document 20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
23 LSP-DB-VERSION This document
24 PREDUNDANCY-GROUP-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
(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 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
This document requests that a registry is created to manage the value
of the LSP type field in the LSP object, which defines the technology
used for LSP setup.
Value Meaning
0 RSVP
9. Manageability Considerations 9. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440] All manageability requirements and considerations listed in [RFC5440]
apply to PCEP protocol extensions defined in this document. In apply to PCEP protocol extensions defined in this document. In
addition, requirements and considerations listed in this section addition, requirements and considerations listed in this section
apply. apply.
9.1. Control Function and Policy 9.1. Control Function and Policy
In addition to configuring specific PCEP session parameters, as In addition to configuring specific PCEP session parameters, as
specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
allow configuring the stateful PCEP capability and the LSP Update allow configuring the stateful PCEP capability and the LSP Update
capability. A PCC implementation SHOULD allow the operator to capability. A PCC implementation SHOULD allow the operator to
specify multiple candidate PCEs for and a delegation preference for specify multiple candidate PCEs for and a delegation preference for
each candidate PCE. A PCC SHOULD allow the operator to specify an each candidate PCE. A PCC SHOULD allow the operator to specify an
LSP delegation policy where LSPs are delegated to the most-preferred LSP delegation policy where LSPs are delegated to the most-preferred
online PCE. A PCC MAY allow the operator to specify different LSP online PCE. A PCC MAY allow the operator to specify different LSP
delegation policies. delegation policies.
A PCE or PCC implementation SHOULD allow the operator to configure a
PREDUNDANCY-GROUP-ID (Section 7.1.3).
A PCC implementation which allows concurrent connections to multiple A PCC implementation which allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and it MUST NOT advertise LSP existence and state to a PCE if domains and it MUST NOT advertise LSP existence and state to a PCE if
the LSP is delegated to a PCE in a different group. the LSP is delegated to a PCE in a different group.
A PCC implementation SHOULD allow the operator to specify whether the A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically controlled by any PCE (for example, LSPs that are statically
configured at the PCC). configured at the PCC).
skipping to change at page 48, line 21 skipping to change at page 41, line 10
or more backup PCEs to which primary PCE's LSPs can be delegated when or more backup PCEs to which primary PCE's LSPs can be delegated when
the primary PCE fails. the primary PCE fails.
Policies defined for stateful PCEs and PCCs should eventually fit in Policies defined for stateful PCEs and PCCs should eventually fit in
the Policy-Enabled Path Computation Framework defined in [RFC5394], the Policy-Enabled Path Computation Framework defined in [RFC5394],
and the framework should be extended to support Stateful PCEs. and the framework should be extended to support Stateful PCEs.
9.2. Information and Data Models 9.2. Information and Data Models
PCEP session configuration and information in the PCEP MIB module PCEP session configuration and information in the PCEP MIB module
SHOULD be extended to include negotiated stateful capabilities, SHOULD be extended to include advertised stateful capabilities,
synchronization status, and delegation status (at the PCC list PCEs synchronization status, and delegation status (at the PCC list PCEs
with delegated LSPs). with delegated LSPs).
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
PCEP protocol extensions defined in this document do not require any PCEP protocol extensions defined in this document do not require any
new mechanisms beyond those already defined in [RFC5440], Section new mechanisms beyond those already defined in [RFC5440], Section
8.3. 8.3.
9.4. Verifying Correct Operation 9.4. Verifying Correct Operation
skipping to change at page 49, line 16 skipping to change at page 42, line 4
PCEP protocol extensions defined in this document do not put new PCEP protocol extensions defined in this document do not put new
requirements on other protocols. requirements on other protocols.
9.6. Impact on Network Operation 9.6. Impact on Network Operation
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
protocol extensions defined in this document. protocol extensions defined in this document.
Additionally, a PCEP implementation SHOULD allow a limit to be placed Additionally, a PCEP implementation SHOULD allow a limit to be placed
on the rate PCUpd and PCRpt messages sent by a PCEP speaker and on the number of LSPs delegated to the PcE and on the rate of PCUpd
processed from a peer. It SHOULD also allow sending a notification and PCRpt messages sent by a PCEP speaker and processed from a peer.
when a rate threshold is reached. It SHOULD also allow sending a notification when a rate threshold is
reached.
A PCC implementation SHOULD allow a limit to be placed on the rate of A PCC implementation SHOULD allow a limit to be placed on the rate of
LSP Updates to the same LSP to avoid signaling overload discussed in LSP Updates to the same LSP to avoid signaling overload discussed in
Section 10.3. Section 10.3.
10. Security Considerations 10. Security Considerations
10.1. Vulnerability 10.1. Vulnerability
This document defines extensions to PCEP to enable stateful PCEs. This document defines extensions to PCEP to enable stateful PCEs.
skipping to change at page 50, line 48 skipping to change at page 43, line 34
any justification. A defending PCC can do this by enqueueing the any justification. A defending PCC can do this by enqueueing the
appropriate PCRpt message. As soon as that message is enqueued in appropriate PCRpt message. As soon as that message is enqueued in
the session, the PCC is free to drop any incoming PCUpd messages the session, the PCC is free to drop any incoming PCUpd messages
without additional processing. without additional processing.
10.4. Malicious PCC 10.4. Malicious PCC
A stateful session also result in increased attack surface by placing A stateful session also result in increased attack surface by placing
a requirement for the PCE to keep an LSP state replica for each PCC. a requirement for the PCE to keep an LSP state replica for each PCC.
It is RECOMMENDED that PCE implementations provide a limit on It is RECOMMENDED that PCE implementations provide a limit on
resources a single PCC can occupy. resources a single PCC can occupy. A PCE implementing such a limit
MUST send a PCErr message with error-type 19 (invalid operation) and
error-value 4 (indicating resource limit exceeded) upon receiving an
LSP state report causing it to exceed this threshold.
Delegation of LSPs can create further strain on PCE resources and a Delegation of LSPs can create further strain on PCE resources and a
PCE implementation MAY preemptively give back delegations if it finds PCE implementation MAY preemptively give back delegations if it finds
itself lacking the resources needed to effectively manage the itself lacking the resources needed to effectively manage the
delegation. Since the delegation state is ultimately controlled by delegation. Since the delegation state is ultimately controlled by
the PCC, PCE implementations SHOULD provide throttling mechanisms to the PCC, PCE implementations SHOULD provide throttling mechanisms to
prevent strain created by flaps of either a PCEP session or an LSP prevent strain created by flaps of either a PCEP session or an LSP
delegation. delegation.
11. Acknowledgements 11. Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria and Ramon We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon
Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin
Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin
Calvin Ying and Xian Zhang for helpful comments and discussions. Sampath, 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-08 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in
progress), July 2013. progress), July 2013.
skipping to change at page 52, line 31 skipping to change at page 45, line 21
[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] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path Zhang, X. and I. Minei, "Applicability of Stateful Path
Computation Element (PCE)", Computation Element (PCE)",
draft-ietf-pce-stateful-pce-app-00 (work in progress), draft-ietf-pce-stateful-pce-app-01 (work in progress),
August 2013. September 2013.
[I-D.minei-pce-stateful-sync-optimizations]
Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of State Synchronization
Procedures for Stateful PCE",
draft-minei-pce-stateful-sync-optimizations-00 (work in
progress), October 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-02 (work in progress), draft-sivabalan-pce-disco-stateful-02 (work in progress),
July 2013. July 2013.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre- and throughput objectives in traffic engineering", pre-
print, 2011. print, 2011.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET- Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004. Networking, June 2004.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
 End of changes. 101 change blocks. 
585 lines changed or deleted 296 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/