draft-ietf-pce-stateful-pce-18.txt   draft-ietf-pce-stateful-pce-19.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: June 5, 2017 Google, Inc. Expires: November 18, 2017 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
December 2, 2016 May 17, 2017
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-18 draft-ietf-pce-stateful-pce-19
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across control of timing and sequence of path computations within and across
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2017. This Internet-Draft will expire on November 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7
4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8
5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 8 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10
5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10
5.5. IGP Extensions for Stateful PCE Capabilities 5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 13 skipping to change at page 3, line 13
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29
6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 39 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 40 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 41
8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41
8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 41 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 42
8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 41 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 42
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 43
8.6. Notification Object . . . . . . . . . . . . . . . . . . . 42 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 43
8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 43 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 44
8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 44
8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 43 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 45
9. Manageability Considerations . . . . . . . . . . . . . . . . 44 9. Manageability Considerations . . . . . . . . . . . . . . . . 45
9.1. Control Function and Policy . . . . . . . . . . . . . . . 44 9.1. Control Function and Policy . . . . . . . . . . . . . . . 45
9.2. Information and Data Models . . . . . . . . . . . . . . . 45 9.2. Information and Data Models . . . . . . . . . . . . . . . 46
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 45 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 47
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 47
9.5. Requirements on Other Protocols and Functional Components 46 9.5. Requirements on Other Protocols and Functional Components 47
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 46 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 46 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 48
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 47 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 48
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 47 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 49
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 48 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 49
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 48 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 50 13.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Communication [RFC5440] describes the Path Computation Element Communication
Protocol (PCEP). PCEP defines the communication between a Path Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or Computation Client (PCC) and a Path Computation Element (PCE), or
between PCEs, enabling computation of Multiprotocol Label Switching between PCEs, enabling computation of Multiprotocol Label Switching
(MPLS) for Traffic Engineering Label Switched Path (TE LSP) (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics. Extensions for support of Generalized MPLS (GMPLS) characteristics. Extensions for support of Generalized MPLS (GMPLS)
in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions] in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions]
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
stateful control of LSPs within and across PCEP sessions in stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect Label compliance with [RFC4657]. It includes mechanisms to effect Label
Switched Path (LSP) state synchronization between PCCs and PCEs, Switched Path (LSP) state synchronization between PCCs and PCEs,
delegation of control over LSPs to PCEs, and PCE control of timing delegation of control over LSPs to PCEs, and PCE control of timing
and sequence of path computations within and across PCEP sessions. and sequence of path computations within and across PCEP sessions.
The extensions that this document describes do not permit the PCE to
drive creation of an LSP. The companion document
[I-D.ietf-pce-pce-initiated-lsp] specifies PCE-initiated LSP
creation.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer, PCEP Speaker. PCE, PCEP Peer, PCEP Speaker.
This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [RFC3031]: LSP.
This document uses the following terms defined in This document uses the following terms defined in [RFC8051]: Stateful
[I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE, PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State
Active Stateful PCE, Delegation, LSP State Database. Database.
The following terms are defined in this document: The following terms are defined in this document:
Revocation: an operation performed by a PCC on a previously Revocation: an operation performed by a PCC on a previously
delegated LSP. Revocation revokes the rights granted to the PCE delegated LSP. Revocation revokes the rights granted to the PCE
in the delegation operation. in the delegation operation.
Redelegation Timeout Interval: the period of time a PCC waits for, Redelegation Timeout Interval: the period of time a PCC waits for,
when a PCEP session is terminated, before revoking LSP delegation when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the to a PCE and attempting to redelegate LSPs associated with the
skipping to change at page 5, line 29 skipping to change at page 5, line 32
communication, by having the requesting PCE fill the role of a PCC, communication, by having the requesting PCE fill the role of a PCC,
as usual. as usual.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE 3. Motivation and Objectives for Stateful PCE
3.1. Motivation 3.1. Motivation
[I-D.ietf-pce-stateful-pce-app] presents several use cases, [RFC8051] presents several use cases, demonstrating scenarios that
demonstrating scenarios that benefit from the deployment of a benefit from the deployment of a stateful PCE. The scenarios apply
stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS equally to MPLS-TE and GMPLS deployments.
deployments.
3.1.1. Background 3.1.1. Background
Traffic engineering has been a goal of the MPLS architecture since Traffic engineering has been a goal of the MPLS architecture since
its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209] engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis; total reserved capacity by traffic class on a per interface basis;
individual LSP state is available only locally on each LER for its individual LSP state is available only locally on each LER for its
own LSPs. In most cases, this makes good sense, as distribution and own LSPs. In most cases, this makes good sense, as distribution and
skipping to change at page 6, line 50 skipping to change at page 7, line 5
optimality of resource usage [MXMN-TE]. All of these systems share optimality of resource usage [MXMN-TE]. All of these systems share
at least two common characteristics: the requirement for both global at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for visibility of a flow (or in this case, a TE LSP) state and for
ordered control of path reservations across devices within the system ordered control of path reservations across devices within the system
being controlled. While some approaches have been suggested in order being controlled. While some approaches have been suggested in order
to remove the requirements for ordered control (See [MPLS-PC]), these to remove the requirements for ordered control (See [MPLS-PC]), these
approaches are highly dependent on traffic distribution, and do not approaches are highly dependent on traffic distribution, and do not
allow for multiple simultaneous LSP priorities representing diffserv allow for multiple simultaneous LSP priorities representing diffserv
classes. classes.
The use cases described in [I-D.ietf-pce-stateful-pce-app] The use cases described in [RFC8051] demonstrate a need for
demonstrate a need for visibility into global inter-PCC LSP state in visibility into global inter-PCC LSP state in PCE path computations,
PCE path computations, and for PCE control of sequence and timing in and for PCE control of sequence and timing in altering LSP path
altering LSP path characteristics within and across PCEP sessions. characteristics within and across PCEP sessions.
3.1.3. Protocol vs. Configuration 3.1.3. Protocol vs. Configuration
Note that existing configuration tools and protocols can be used to Note that existing configuration tools and protocols can be used to
set LSP state. However, this solution has several shortcomings: set LSP state, such as a Command Line Interface (CLI) tool. However,
this solution has several shortcomings:
o Scale & Performance: configuration operations often have o Scale & Performance: configuration operations often have
transactional semantics which are typically heavyweight and often transactional semantics which are typically heavyweight and often
require processing of additional configuration portions beyond the require processing of additional configuration portions beyond the
state being directly acted upon, with corresponding cost in CPU state being directly acted upon, with corresponding cost in CPU
cycles, negatively impacting both PCC stability LSP update rate cycles, negatively impacting both PCC stability LSP update rate
capacity. capacity.
o Security: when a PCC opens a configuration channel allowing a PCE o Security: when a PCC opens a configuration channel allowing a PCE
to send configuration, a malicious PCE may take advantage of this to send configuration, a malicious PCE may take advantage of this
skipping to change at page 7, line 48 skipping to change at page 7, line 52
described in this document are as follows: described in this document are as follows:
o Allow a single PCC to interact with a mix of stateless and o Allow a single PCC to interact with a mix of stateless and
stateful PCEs simultaneously using the same protocol, i.e. PCEP. stateful PCEs simultaneously using the same protocol, i.e. PCEP.
o Support efficient LSP state synchronization between the PCC and o Support efficient LSP state synchronization between the PCC and
one or more active or passive stateful PCEs. one or more active or passive stateful PCEs.
o Allow a PCC to delegate control of its LSPs to an active stateful o Allow a PCC to delegate control of its LSPs to an active stateful
PCE such that a given LSP is under the control of a single PCE at PCE such that a given LSP is under the control of a single PCE at
any given time. A PCC may revoke this delegation at any time any given time.
during the lifetime of the LSP. If LSP delegation is revoked
while the PCEP session is up, the PCC MUST notify the PCE about * A PCC may revoke this delegation at any time during the
the revocation. A PCE may return an LSP delegation at any point lifetime of the LSP. If LSP delegation is revoked while the
during the lifetime of the PCEP session. PCEP session is up, the PCC MUST notify the PCE about the
revocation.
* A PCE may return an LSP delegation at any point during the
lifetime of the PCEP session. If LSP delegation is returned by
the PCE while the PCEP session is up, the PCE MUST notify the
PCC about the returned delegation.
o Allow a PCE to control computation timing and update timing across o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it. all LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event of a PCE o Enable uninterrupted operation of 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
skipping to change at page 9, line 36 skipping to change at page 9, line 39
o a PCC to revert delegated LSP to an operator-defined default or to o a PCC to revert delegated LSP to an operator-defined default or to
delegate the LSPs to a different PCE, if the PCC get disconnected delegate the LSPs to a different PCE, if the PCC get disconnected
from a PCE with currently delegated LSPs from a PCE with currently delegated LSPs
5.2. New Messages 5.2. New Messages
In this document, we define the following new PCEP messages: In this document, we define the following new PCEP messages:
Path Computation State Report (PCRpt): a PCEP message sent by a PCC Path Computation State Report (PCRpt): a PCEP message sent by a PCC
to a PCE to report the status of one or more LSPs. Each LSP to a PCE to report the status of one or more LSPs. Each LSP State
Status Report in a PCRpt message MAY contain the actual LSP's Report in a PCRpt message MAY contain the actual LSP's path,
path, bandwidth, operational and administrative status, etc. An bandwidth, operational and administrative status, etc. An LSP
LSP Status Report carried on a PCRpt message is also used in Status Report carried on a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. The delegation or revocation of control of an LSP to/from a PCE. The
PCRpt message is described in Section 6.1. PCRpt message is described in Section 6.1.
Path Computation Update Request (PCUpd): a PCEP message sent by a Path Computation Update Request (PCUpd): a PCEP message sent by a
PCE to a PCC to update LSP parameters, on one or more LSPs. Each PCE to a PCC to update LSP parameters, on one or more LSPs. Each
LSP Update Request on a PCUpd message MUST contain all LSP LSP Update Request on a PCUpd message MUST contain all LSP
parameters that a PCE wishes to be set for a given LSP. An LSP parameters that a PCE wishes to be set for a given LSP. An LSP
Update Request carried on a PCUpd message is also used to return Update Request carried on a PCUpd message is also used to return
LSP delegations if at any point PCE no longer desires control of LSP delegations if at any point PCE no longer desires control of
an LSP. The PCUpd message is described in Section 6.2. an LSP. The PCUpd message is described in Section 6.2.
skipping to change at page 11, line 8 skipping to change at page 11, line 8
their respective OPEN message. If the PCEP Speaker on the PCC their respective OPEN message. If the PCEP Speaker on the PCC
supports the extensions of this draft but did not advertise this supports the extensions of this draft but did not advertise this
capability, then upon receipt of PCUpd message from the PCE, it MUST capability, then upon receipt of PCUpd message from the PCE, it MUST
generate a PCErr with error-type 19 (Invalid Operation), error-value generate a PCErr with error-type 19 (Invalid Operation), error-value
2 (Attempted LSP Update Request if the stateful PCE capability was 2 (Attempted LSP Update Request if the stateful PCE capability was
not advertised)(see Section 8.5) and it SHOULD terminate the PCEP not advertised)(see Section 8.5) and it SHOULD terminate the PCEP
session. If the PCEP Speaker on the PCE supports the extensions of session. If the PCEP Speaker on the PCE supports the extensions of
this draft but did not advertise this capability, then upon receipt this draft but did not advertise this capability, then upon receipt
of a PCRpt message from the PCC, it MUST generate a PCErr with error- of a PCRpt message from the PCC, it MUST generate a PCErr with error-
type 19 (Invalid Operation), error-value 5 (Attempted LSP State type 19 (Invalid Operation), error-value 5 (Attempted LSP State
Report if active stateful PCE capability was not advertised) (see Report if stateful PCE capability was not advertised) (see
Section 8.5) and it SHOULD terminate the PCEP session. Section 8.5) and it SHOULD terminate the PCEP session.
LSP delegation and LSP update operations defined in this document may LSP delegation and LSP update operations defined in this document may
only be used if both PCEP Speakers set the LSP-UPDATE Flag in the only be used if both PCEP Speakers set the LSP-UPDATE-CAPABILITY Flag
"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this in the "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'.
is not the case and LSP delegation or LSP update operations are If this is not the case and LSP delegation or LSP update operations
attempted, then a PCErr with error-type 19 (Invalid Operation) and are attempted, then a PCErr with error-type 19 (Invalid Operation)
error-value 1 (Attempted LSP Update Request for a non-delegated LSP) and error-value 1 (Attempted LSP Update Request for a non-delegated
(see Section 8.5) MUST be generated. Note that even if the update LSP) (see Section 8.5) MUST be generated. Note that, even if one of
capability has not been advertised, a PCE can still accept LSP Status the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its
Reports from a PCC and build and maintain an up to date view of the "Stateful Capability" TLV, a PCE can still operate as a passive
state of the PCC's LSPs. stateful PCE by accepting LSP State Reports from the PCC in order to
build and maintain an up to date view of the state of the PCC's LSPs.
5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the consists of utilizing IGP advertisements. Extensions for the
advertisement of PCE Discovery Information are defined for OSPF and advertisement of PCE Discovery Information are defined for OSPF and
for IS-IS in [RFC5088] and [RFC5089] respectively. for IS-IS in [RFC5088] and [RFC5089] respectively.
skipping to change at page 12, line 6 skipping to change at page 12, line 6
Length: Multiple of 4. Length: Multiple of 4.
Value: This contains an array of units of 32 bit flags with the most Value: This contains an array of units of 32 bit flags with the most
significant bit as 0. Each bit represents one PCE capability. significant bit as 0. Each bit represents one PCE capability.
PCE capability bits are defined in [RFC5088]. This document defines PCE capability bits are defined in [RFC5088]. This document defines
new capability bits for the stateful PCE as follows: new capability bits for the stateful PCE as follows:
Bit Capability Bit Capability
TBD Active Stateful PCE capability 11 Active Stateful PCE capability
TBD Passive Stateful PCE capability 12 Passive Stateful PCE capability
Note that while active and passive stateful PCE capabilities may be Note that while active and passive stateful PCE capabilities may be
advertised during discovery, PCEP Speakers that wish to use stateful advertised during discovery, PCEP Speakers that wish to use stateful
PCEP MUST negotiate stateful PCEP capabilities during PCEP session PCEP MUST negotiate stateful PCEP capabilities during PCEP session
setup, as specified in the current document. A PCC MAY initiate setup, as specified in the current document. A PCC MAY initiate
stateful PCEP capability negotiation at PCEP session setup even if it stateful PCEP capability negotiation at PCEP session setup even if it
did not receive any IGP PCE capability advertisements. did not receive any IGP PCE capability advertisements.
5.6. State Synchronization 5.6. State Synchronization
The purpose of State Synchronization is to provide a checkpoint-in- The purpose of State Synchronization is to provide a checkpoint-in-
time state replica of a PCC's LSP state in a PCE. State time state replica of a PCC's LSP state in a PCE. State
Synchronization is performed immediately after the Initialization Synchronization is performed immediately after the Initialization
phase ([RFC5440]). phase ([RFC5440]).
During State Synchronization, a PCC first takes a snapshot of the During State Synchronization, a PCC first takes a snapshot of the
state of its LSPs state, then sends the snapshot to a PCE in a state of its LSPs state, then sends the snapshot to a PCE in a
sequence of LSP State Reports. Each LSP State Report sent during sequence of LSP State Reports. Each LSP State Report sent during
State Synchronization has the SYNC Flag in the LSP Object set to 1. State Synchronization has the SYNC Flag in the LSP Object set to 1.
The set of LSPs for which state is synchronized with a PCE is The set of LSPs for which state is synchronized with a PCE is
determined by advertised stateful PCEP capabilities and PCC's local determined by the PCC's local configuration (see more details in
configuration (see more details in Section 9.1). Section 9.1) and MAY also be determined by stateful PCEP capabilities
defined in other documents, such as
[I-D.ietf-pce-stateful-sync-optimizations].
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 (see Section 7.3). In this case, the LSP Object SHOULD NOT value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT
include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP-
IDENTIFIERS TLV with the special value of all zeroes. The PCRpt IDENTIFIERS TLV with the special value of all zeroes. The PCRpt
message MUST include an empty ERO as its intended path and SHOULD NOT message MUST include an empty ERO as its intended path and SHOULD NOT
include the optional RRO object for its actual path. If the PCC has include the optional RRO object for its actual path. If the PCC has
no state to synchronize, it SHOULD only send the end of no state to synchronize, it SHOULD only send the end of
synchronization marker. synchronization marker.
skipping to change at page 13, line 6 skipping to change at page 13, line 8
computing new paths. computing new paths.
Either the PCE or the PCC MAY terminate the session using the PCEP Either the PCE or the PCC MAY terminate the session using the PCEP
session termination procedures during the synchronization phase. If session termination procedures during the synchronization phase. If
the session is terminated, the PCE MUST clean up state it received the session is terminated, the PCE MUST clean up state it received
from this PCC. The session reestablishment MUST be re-attempted per from this PCC. The session reestablishment MUST be re-attempted per
the procedures defined in [RFC5440], including use of a back-off the procedures defined in [RFC5440], including use of a back-off
timer. timer.
If the PCC encounters a problem which prevents it from completing the If the PCC encounters a problem which prevents it from completing the
state transfer, it MUST send a PCErr message with error-type 20 (LSP LSP state synchronization, it MUST send a PCErr message with error-
State Synchronization Error) and error-value 5 (indicating an type 20 (LSP State Synchronization Error) and error-value 5
internal PCC error) to the PCE and terminate the session. (indicating an internal PCC error) to the PCE and terminate the
session.
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgements for properly received
synchronization messages. It MUST respond with a PCErr message with synchronization messages. It MUST respond with a PCErr message with
error-type 20 (LSP State Synchronization Error) and error-value 1 error-type 20 (LSP State Synchronization Error) and error-value 1
(indicating an error in processing the PCRpt) (see Section 8.5) if it (indicating an error in processing the PCRpt) (see Section 8.5) if it
encounters a problem with the LSP State Report it received from the encounters a problem with the LSP State Report it received from the
PCC and it MUST terminate the session. PCC and it MUST terminate the session.
A PCE implementing a limit on the resources a single PCC can occupy, A PCE implementing a limit on the resources a single PCC can occupy,
MUST send a PCNtf message with Notification Type to be allocated by MUST send a PCNtf message with Notification Type 4 (Stateful PCE
IANA (Stateful PCE resource limit exceeded) and Notification Value to resource limit exceeded) and Notification Value 1 (Entering resource
be allocated by IANA (Entering resource limit exceeded state) in limit exceeded state) in response to the PCRpt message triggering
response to the PCRpt message triggering this condition in the this condition in the synchronization phase and MUST terminate the
synchronization phase and MUST terminate the session. 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 16, line 23 skipping to change at page 16, line 23
| . | | . |
| . | | . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
Figure 4: Delegating an LSP Figure 4: Delegating an LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE. the Delegate flag to 1 on each LSP State Report sent to the PCE.
5.7.2. Revoking a Delegation 5.7.2. Revoking a Delegation
5.7.2.1. Explicit Revocation 5.7.2.1. Explicit Revocation
When a PCC decides that a PCE is no longer permitted to modify an When a PCC decides that a PCE is no longer permitted to modify an
LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke
an LSP delegation at any time during the LSP's life time. A PCC an LSP delegation at any time during the LSP's life time. A PCC
revoking an LSP delegation MAY immediately clear the LSP state revoking an LSP delegation MAY immediately remove the updated
provided by the PCE, but to avoid traffic loss, it SHOULD do so in a parameters provided by the PCE and revert to the operator-defined
make-before-break fashion. If the PCC has received but not yet acted parameters, but to avoid traffic loss, it SHOULD do so in a make-
on PCUpd messages from the PCE for the LSP whose delegation is being before-break fashion. If the PCC has received but not yet acted on
PCUpd messages from the PCE for the LSP whose delegation is being
revoked, then it SHOULD ignore these PCUpd messages when processing revoked, then it SHOULD ignore these PCUpd messages when processing
the message queue. 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 immediately
immediately cleared). Any further PCUpd messages from the PCE are revert to the operator-defined parameters).
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 5. shown in Figure 5.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 17, line 36 skipping to change at page 17, line 36
5.7.2.2. Revocation on Redelegation Timeout 5.7.2.2. Revocation on Redelegation Timeout
When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
MUST wait the time interval specified in Redelegation Timeout MUST wait the time interval specified in 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, and the PCC does not succeed in redelegating its LSPs,
flushing any LSP state associated with that PCE. Note that the State the PCC MUST wait for the State Timeout Interval before flushing any
Timeout Interval timer may expire before the PCC has redelegated the LSP state associated with that PCE. Note that the State Timeout
LSPs to another PCE, for example if a PCC is not connected to any Interval timer may expire before the PCC has redelegated the LSPs to
active stateful PCE or if no connected active stateful PCE accepts another PCE, for example if a PCC is not connected to any active
the delegation. In this case, the PCC MUST flush any LSP state set stateful PCE or if no connected active stateful PCE accepts the
by the PCE upon expiration of the State Timeout Interval and revert delegation. In this case, the PCC MUST flush any LSP state set by
to operator-defined default parameters or behaviors. This operation the PCE upon expiration of the State Timeout Interval and revert to
operator-defined default parameters or behaviors. This operation
SHOULD be done in a make-before-break fashion. SHOULD be done in a make-before-break fashion.
The State Timeout Interval MUST be greater than or equal to the The State Timeout Interval MUST be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact). set by the PCE, they will remain intact).
5.7.3. Returning a Delegation 5.7.3. Returning a Delegation
In order to keep a delegation, a PCE MUST set the Delegate flag to 1 In order to keep a delegation, a PCE MUST set the Delegate flag to 1
skipping to change at page 18, line 35 skipping to change at page 18, line 35
|---PCRpt, Delegate=0--->| No delegation for LSP |---PCRpt, Delegate=0--->| No delegation for LSP
| | | |
Figure 6: Returning a Delegation Figure 6: Returning a Delegation
If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC stateful PCE accepts the delegation), the LSP delegation on the PCC
will time out within a configurable Redelegation Timeout Interval and will 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 and revert to operator-defined default
parameters or behaviors.
5.7.4. Redundant Stateful PCEs 5.7.4. Redundant Stateful PCEs
In a redundant configuration where one PCE is backing up another PCE, In a redundant configuration where one PCE is backing up another PCE,
the backup PCE may have only a subset of the LSPs in the network the backup PCE may have only a subset of the LSPs in the network
delegated to it. The backup PCE does not update any LSPs that are delegated to it. The backup PCE does not update any LSPs that are
not delegated to it. In order to allow the backup to operate in a not delegated to it. In order to allow the backup to operate in a
hot-standby mode and avoid the need for state synchronization in case hot-standby mode and avoid the need for state synchronization in case
the primary fails, the backup receives all LSP State Reports from a the primary fails, the backup receives all LSP State Reports from a
PCC. When the primary PCE for a given LSP set fails, after expiry of PCC. When the primary PCE for a given LSP set fails, after expiry of
skipping to change at page 19, line 26 skipping to change at page 19, line 28
and LSP state on a PCE failure. and LSP state on a PCE failure.
If the PCE crashes but recovers within the Redelegation Timeout, both If the PCE crashes but recovers within the Redelegation Timeout, both
the delegation state and the LSP state are kept intact. the delegation state and the LSP state are kept intact.
If the PCE crashes but does not recover within the Redelegation If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is flushed, which may Timeout Interval, the state set by the PCE is removed and the LSP
cause change in the LSP state. Note that an operator may choose to reverts to operator-defined parameters, which may cause a change in
use an infinite State Timeout Interval if he wishes to maintain the the LSP state. Note that an operator may choose to use an infinite
PCE state indefinitely. Note also that flushing the state should be State Timeout Interval if he wishes to maintain the PCE state
indefinitely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss. implemented using make-before-break to avoid traffic loss.
If there is a standby PCE, the Redelegation Timeout may be set to 0 If there is a standby PCE, the Redelegation Timeout may be set to 0
through policy on the PCC, causing the LSPs to be redelegated through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the immediately to the PCC, which can delegate them immediately to the
standby PCE. Assuming the State Timeout Interval is greater than the standby PCE. Assuming that the PCC can redelegate the LSP to the
Redelegation Timeout, and assuming the standby PCE takes similar standby PCE within the State Timeout Interval, and assuming the
decisions as the failed PCE, the LSP state will be kept intact. standby PCE takes similar decisions as the failed PCE, the LSP state
will be kept intact.
5.8. LSP Operations 5.8. LSP Operations
5.8.1. Passive Stateful PCE Path Computation Request/Response 5.8.1. Passive Stateful PCE Path Computation Request/Response
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) Path computation |----- PCReq message --->| 1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation request sent to | |2) Path computation
PCE | | request received, PCE | | request received,
| | path computed | | path computed
| | | |
|<---- PCRep message ----|3) Computed paths |<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC | (Positive reply) | sent to the PCC
| (Negative reply) | | (Negative reply) |
4) LSP Status change| | 4) LSP State change | |
event | | event | |
| | | |
5) LSP Status Report|----- PCRpt message --->| 5) LSP State Report |----- PCRpt message --->|
sent to all | . | sent to all | . |
stateful PCEs | . | stateful PCEs | . |
| . | | . |
6) Repeat for each |----- PCRpt message --->| 6) Repeat for each |----- PCRpt message --->|
LSP status change| | LSP state change | |
| | | |
Figure 7: Passive Stateful PCE Path Computation Request/Response Figure 7: Passive Stateful PCE Path Computation Request/Response
Once a PCC has successfully established a PCEP session with a passive Once a PCC has successfully established a PCEP session with a passive
stateful PCE and the PCC's LSP state is synchronized with the PCE stateful PCE and the PCC's LSP state is synchronized with the PCE
(i.e. the PCE knows about all PCC's existing LSPs), if an event is (i.e. the PCE knows about all 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], sends a path computation request to the PCE ([RFC5440],
Section 4.2.3). The PCReq message MAY contain the LSP Object to Section 4.2.3). The PCReq message MAY contain the LSP Object to
skipping to change at page 21, line 24 skipping to change at page 21, line 24
There is no direct correlation between PCRep and PCRpt messages. For There is no direct correlation between PCRep and PCRpt messages. For
a given LSP, multiple LSP State Reports will follow a single PCRep a given LSP, multiple LSP State Reports will follow a single PCRep
message, as a PCC notifies a PCE of the LSP's state changes. message, as a PCC notifies a PCE of the LSP's state changes.
A PCC MUST send each LSP State Report to each stateful PCE that is A PCC MUST send each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
Note that a single PCRpt message MAY contain multiple LSP State Note that a single PCRpt message MAY contain multiple LSP State
Reports. Reports.
The passive stateful PCE is the model for stateful PCEs is described The passive stateful model for stateful PCEs is described in
in [RFC4655], Section 6.8. [RFC4655], Section 6.8.
5.8.2. Switching from Passive Stateful to Active Stateful 5.8.2. Switching from Passive Stateful to Active Stateful
This section deals with the scenario of an LSP transitioning from a This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation. When the passive stateful to an active stateful mode of operation. When the
LSP has no working path, prior to delegating the LSP, the PCC MUST LSP has no working path, prior to delegating the LSP, the PCC MUST
first use the procedure defined in Section 5.8.1 to request the first use the procedure defined in Section 5.8.1 to request the
initial path from the PCE. This is required because the action of initial path from the PCE. This is required because the action of
delegating the LSP to a PCE using a PCRpt message is not an explicit delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the PCE to compute a path for the LSP. The only explicit request to the PCE to compute a path for the LSP. The only explicit
skipping to change at page 22, line 20 skipping to change at page 22, line 20
| | | |
1) LSP State |-- PCRpt, Delegate=1 -->| 1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . | Synchronization | . |
| . |2) PCE decides to | . |2) PCE decides to
| . | update the LSP | . | update the LSP
| | | |
|<---- PCUpd message ----|3) PCUpd message sent |<---- PCUpd message ----|3) PCUpd message sent
| | to PCC | | to PCC
| | | |
| | | |
4) LSP Status Report|---- PCRpt message ---->| 4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . | sent(->Going-up) | . |
| . | | . |
| . | | . |
5) LSP Status Report|---- PCRpt message ---->| 5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | | sent (->Up|Down) | |
| | | |
Figure 8: Active Stateful PCE Figure 8: Active Stateful PCE
Once a PCC has successfully established a PCEP session with an active Once a PCC has successfully established a PCEP session with an active
stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.
the PCE knows about all PCC's existing LSPs). After LSPs have been the PCE knows about all PCC's existing LSPs). After LSPs have been
delegated to the PCE, the PCE can modify LSP parameters of delegated delegated to the PCE, the PCE can modify LSP parameters of delegated
LSPs. LSPs.
skipping to change at page 24, line 13 skipping to change at page 24, line 13
set of objects that the message can carry. set of objects that the message can carry.
6.1. The PCRpt Message 6.1. The PCRpt Message
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE, or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is to be assigned by IANA. for the PCRpt message is 10.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <intended_path> <path>::= <intended-path>
[<actual_attribute_list><actual_path>] [<actual-attribute-list><actual-path>]
<intended_attribute_list> <intended-attribute-list>
<actual_attribute-list>::=[<BANDWIDTH>] <actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>] [<metric-list>]
Where: Where:
<intended_path> is represented by the ERO object defined in <intended-path> is represented by the ERO object defined in
section 7.9 of [RFC5440]. section 7.9 of [RFC5440].
<actual_attribute_list> consists of the actual computed and <actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> objects signaled values of the <BANDWIDTH> and <metric-lists> objects
defined in [RFC5440]. defined in [RFC5440].
<actual_path> is represented by the RRO object defined in <actual-path> is represented by the RRO object defined in
section 7.10 of [RFC5440]. section 7.10 of [RFC5440].
<intended_attribute_list> is the attribute-list defined in <intended-attribute-list> is the attribute-list defined in
section 6.5 of [RFC5440] and extended by PCEP extensions. section 6.5 of [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message
is not in response to a PCupd message, the SRP object MAY be omitted. is not in response to a PCupd message, the SRP object MAY be omitted.
When the PCC does not include the SRP object, the PCE MUST treat this When the PCC does not include the SRP object, the PCE MUST treat this
as an SRP object with an SRP-ID-number equal to the reserved value as an SRP object with an SRP-ID-number equal to the reserved value
0x00000000. The reserved value 0x00000000 indicates that the state 0x00000000. The reserved value 0x00000000 indicates that the state
reported is not as a result of processing a PCUpd message. reported is not as a result of processing a PCUpd message.
If the PCRpt message is in response to a PCUpd message, the SRP If the PCRpt message is in response to a PCUpd message, the SRP
skipping to change at page 25, line 21 skipping to change at page 25, line 21
No state compression is allowed for state reporting, e.g. PCRpt No state compression is allowed for state reporting, e.g. PCRpt
messages MUST NOT be pruned from the PCC's egress queue even if messages MUST NOT be pruned from the PCC's egress queue even if
subsequent operations on the same LSP have been completed before the subsequent operations on the same LSP have been completed before the
PCRpt message has been sent to the TCP stack. The PCC MUST PCRpt message has been sent to the TCP stack. The PCC MUST
explicitly report state changes (including removal) for paths it explicitly report state changes (including removal) for paths it
manages. manages.
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
in each LSP State Report on the PCRpt message. If the LSP object is in each LSP State Report on the PCRpt message. If the LSP object is
missing, the receiving PCE MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value to be assigned by type=6 (Mandatory Object missing) and Error-value 8 (LSP object
IANA (LSP object missing). missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The intended path, represented by the ERO object, is REQUIRED. If The intended path, represented by the ERO object, is REQUIRED. If
the ERO object is missing, the receiving PCE MUST send a PCErr the ERO object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-value message with Error-type=6 (Mandatory Object missing) and Error-value
to be assigned by IANA (ERO object missing). The ERO may be empty if 9 (ERO object missing). The ERO may be empty if the PCE does not
the PCE does not have a path for a delegated LSP. have a path for a delegated LSP.
The actual path, represented by the RRO object, SHOULD be included in The actual path, represented by the RRO object, SHOULD be included in
PCRpt by the PCC when the path is up or active, but MAY be omitted if PCRpt by the PCC when the path is up or active, but MAY be omitted if
the path is down due to a signaling error or another failure. the path is down due to a signaling error or another failure.
The intended_attribute_list maps to the attribute_list in Section 6.5 The intended-attribute-list maps to the attribute-list in Section 6.5
of [RFC5440] and is used to convey the requested parameters of the of [RFC5440] and is used to convey the requested parameters of the
LSP path. This is needed in order to support the switch from passive LSP path. This is needed in order to support the switch from passive
to active stateful PCE as described in Section 5.8.2. When included to active stateful PCE as described in Section 5.8.2. When included
as part of the intended_attribute_list, the meaning of the BANDWIDTH as part of the intended-attribute-list, the meaning of the BANDWIDTH
object is the requested bandwidth as intended by the operator. In object is the requested bandwidth as intended by the operator. In
this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly,
to indicate a limiting constraint, the METRIC object SHOULD be to indicate a limiting constraint, the METRIC object SHOULD be
included as part of the intended_attribute_list with the B flag set included as part of the intended-attribute-list with the B flag set
and with a specific metric value. To indicate the optimization and with a specific metric value. To indicate the optimization
metric, the METRIC object SHOULD be included as part of the metric, the METRIC object SHOULD be included as part of the intended-
intended_attribute_list with the B flag unset and the metric value attribute-list with the B flag unset and the metric value set to
set to zero. Note that the intended_attribute_list is optional and zero. Note that the intended-attribute-list is optional and thus may
thus may be omitted. In this case, the PCE MAY use the values in the be omitted. In this case, the PCE MAY use the values in the actual-
actual_attribute_list as the requested parameters for the path. attribute-list as the requested parameters for the path.
The actual_attribute_list consists of the actual computed and The actual-attribute-list consists of the actual computed and
signaled values of the BANDWIDTH and METRIC objects defined in signaled values of the BANDWIDTH and METRIC objects defined in
[RFC5440]. When included as part of the actual_attribute_list, [RFC5440]. When included as part of the actual-attribute-list,
Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and
the C flag SHOULD be set in the METRIC object ([RFC5440]). the C flag SHOULD be set in the METRIC object ([RFC5440]).
A PCE may choose to implement a limit on the resources a single PCC A PCE may choose to implement a limit on the resources a single PCC
can occupy. If a PCRpt is received that causes the PCE to exceed can occupy. If a PCRpt is received that causes the PCE to exceed
this limit, the PCE MUST notify the PCC using a PCNtf message with this limit, the PCE MUST notify the PCC using a PCNtf message with
Notification Type to be allocated by IANA (Stateful PCE resource Notification Type 4 (Stateful PCE resource limit exceeded) and
limit exceeded) and Notification Value to be allocated by IANA Notification Value 1 (Entering resource limit exceeded state) and
(Entering resource limit exceeded state) and MAY terminate the MUST terminate the session.
session.
6.2. The PCUpd Message 6.2. The PCUpd Message
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCUpd message is to be assigned by IANA. the PCUpd message is 11.
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <intended_path><attribute-list> <path>::= <intended-path><intended-attribute-list>
Where: Where:
<intended_path> is represented by the ERO object defined in <intended-path> is represented by the ERO object defined in
section 7.9 of [RFC5440]. section 7.9 of [RFC5440].
<attribute-list> is defined in [RFC5440] and extended by <intended-attribute-list> is the attribute-list defined in [RFC5440]
PCEP extensions. and extended by PCEP extensions.
There are three mandatory objects that MUST be included within each There are three mandatory objects that MUST be included within each
LSP Update Request in the PCUpd message: the SRP Object (see LSP Update Request in the PCUpd message: the SRP Object (see
Section 7.2), the LSP object (see Section 7.3) and the ERO object (as Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
defined in [RFC5440], which represents the intended path. If the SRP defined in [RFC5440], which represents the intended path. If the SRP
object is missing, the receiving PCC MUST send a PCErr message with object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
object missing). If the LSP object is missing, the receiving PCC object missing). If the LSP object is missing, the receiving PCC
MUST send a PCErr message with Error-type=6 (Mandatory Object MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=8 (LSP object missing). If the ERO object missing) and Error-value=8 (LSP object missing). If the ERO object
skipping to change at page 30, line 39 skipping to change at page 30, line 39
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 the current document MUST be set to 0 on PCEP objects defined in the current document MUST be set to 0 on
transmission and SHOULD be ignored on receipt since the P and I flags transmission and SHOULD be ignored on receipt since the P and I flags
are exclusively related to path computation requests. are exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines one new optional TLVs for use in the OPEN This document defines one new optional TLV for use in the OPEN
Object. Object.
7.1.1. Stateful PCE Capability TLV 7.1.1. Stateful PCE Capability TLV
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
OPEN Object for stateful PCE capability advertisement. Its format is OPEN Object for stateful PCE capability advertisement. Its format is
shown in the following figure: shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U| | Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV format Figure 9: STATEFUL-PCE-CAPABILITY TLV format
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is 16. The length field is 16 bit-long
field is 16 bit-long and has a fixed value of 4. and has a fixed value of 4.
The value comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag
indicates that the PCC allows modification of LSP parameters; if indicates that the PCC allows modification of LSP parameters; if
set to 1 by a PCE, the U Flag indicates that the PCE is capable of set to 1 by a PCE, the U Flag indicates that the PCE is capable of
updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be
advertised by both a PCC and a PCE for PCUpd messages to be advertised by both a PCC and a PCE for PCUpd messages to be
allowed on a PCEP session. allowed on a PCEP session.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
A PCEP speaker operating in passive stateful PCE mode advertises the
stateful PCE capability with the U flag set to 0. A PCEP speaker
operating in active stateful PCE mode advertises the stateful PCE
capability with the U Flag set to 1.
Advertisement of the stateful PCE capability implies support of LSPs Advertisement of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs and that are signaled via RSVP, as well as the objects, TLVs and
procedures defined in this document. procedures defined in this document.
7.2. SRP Object 7.2. SRP Object
The SRP (Stateful PCE Request Parameters) object MUST be carried The SRP (Stateful PCE Request Parameters) object MUST be carried
within PCUpd messages and MAY be carried within PCRpt and PCErr within PCUpd messages and MAY be carried within PCRpt and PCErr
messages. The SRP object is used to correlate between update messages. The SRP object is used to correlate between update
requests sent by the PCE and the error reports and state reports sent requests sent by the PCE and the error reports and state reports sent
by the PCC. by the PCC.
SRP Object-Class is to be assigned by IANA. SRP Object-Class is 33.
SRP Object-Type is 1. SRP Object-Type is 1.
The format of the SRP object body is shown in Figure 10: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 32 skipping to change at page 32, line 32
Flags (32 bits): None defined yet. Flags (32 bits): None defined yet.
SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
current PCEP session uniquely identify the operation that the PCE has current PCEP session uniquely identify the operation that the PCE has
requested the PCC to perform on a given LSP. The SRP-ID-number is requested the PCC to perform on a given LSP. The SRP-ID-number is
incremented each time a new request is sent to the PCC, and may wrap incremented each time a new request is sent to the PCC, and may wrap
around. around.
The values 0x00000000 and 0xFFFFFFFF are reserved. The values 0x00000000 and 0xFFFFFFFF are reserved.
Optional TLVs MAY be included within the SRP object body. The
specification of such TLVs is outside the scope of this document.
Every request to update an LSP receives a new SRP-ID-number. This Every request to update an LSP receives a new SRP-ID-number. This
number is unique per PCEP session and is incremented each time an number is unique per PCEP session and is incremented each time an
operation is requested from the PCE. Thus, for a given LSP there may operation is requested from the PCE. Thus, for a given LSP there may
be more than one SRP-ID-number unacknowledged at a given time. The be more than one SRP-ID-number unacknowledged at a given time. The
value of the SRP-ID-number is echoed back by the PCC in PCErr and value of the SRP-ID-number is echoed back by the PCC in PCErr and
PCRpt messages to allow for correlation between requests made by the PCRpt messages to allow for correlation between requests made by the
PCE and errors or state reports generated by the PCC. If the error PCE and errors or state reports generated by the PCC. If the error
or report were not as a result of a PCE operation (for example in the or report were not as a result of a PCE operation (for example in the
case of a link down event), the reserved value of 0x00000000 is used case of a link down event), the reserved value of 0x00000000 is used
for the SRP-ID-number. The absence of the SRP object is equivalent for the SRP-ID-number. The absence of the SRP object is equivalent
skipping to change at page 33, line 17 skipping to change at page 33, line 20
The LSP object MUST be present within PCRpt and PCUpd messages. The The LSP object MUST be present within PCRpt and PCUpd messages. The
LSP object MAY be carried within PCReq and PCRep messages if the LSP object MAY be carried within PCReq and PCRep messages if the
stateful PCE capability has been negotiated on the session. The LSP stateful PCE capability has been negotiated on the session. The LSP
object contains a set of fields used to specify the target LSP, the object contains a set of fields used to specify the target LSP, the
operation to be performed on the LSP, and LSP Delegation. It also operation to be performed on the LSP, and LSP Delegation. It also
contains a flag indicating to a PCE that the LSP state contains a flag indicating to a PCE that the LSP state
synchronization is in progress. This document focuses on LSPs that synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object are signaled with RSVP, many of the TLVs used with the LSP object
mirror RSVP state. mirror RSVP state.
LSP Object-Class is to be assigned by IANA. LSP Object-Class is 32.
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 11: The format of the LSP object body is shown in Figure 11:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag | O|A|R|S|D| | PLSP-ID | Flag | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 12 skipping to change at page 34, line 15
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP Delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation - the first PCRpt with the D flag
set to 0 revokes the delegation. To keep the delegation, the PCE set to 0 revokes the delegation. To keep the delegation, the PCE
must set the D flag to 1 on each PCUpd message for the duration of must set the D flag to 1 on each PCUpd message for the duration of
the delegation - the first PCUpd with the D flag set to 0 returns the delegation - the first PCUpd with the D flag set to 0 returns
the delegation. the delegation.
S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent
from a PCC during State Synchronization. The S Flag MUST be set from a PCC during State Synchronization. The S Flag MUST be set
to 0 in other messages sent from the PCC. to 0 in other messages sent from the PCC. When sending a PCUpd
message, the PCE MUST set the S Flag to 0.
R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the
LSP has been removed from the PCC and the PCE SHOULD remove all LSP has been removed from the PCC and the PCE SHOULD remove all
state from its database. Upon receiving an LSP State Report with state from its database. Upon receiving an LSP State Report with
the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
remove all state for the path identified by the LSP-IDENTIFIERS remove all state for the path identified by the LSP-IDENTIFIERS
TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is
used, the PCE SHOULD remove all state for the PLSP-ID from its used, the PCE SHOULD remove all state for the PLSP-ID from its
database. database. When sending a PCUpd message, the PCE MUST set the R
Flag to 0.
A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates
the PCC's target operational status for this LSP. On PCUpd the PCC's target operational status for this LSP. On PCUpd
messages, the A Flag indicates the LSP status that the PCE desires messages, the A Flag indicates the LSP status that the PCE desires
for this LSP. In both cases, a value of '1' means that the for this LSP. In both cases, a value of '1' means that the
desired operational state is active, and a value of '0' means that desired operational state is active, and a value of '0' means that
the desired operational state is inactive. A PCC ignores the A the desired operational state is inactive. A PCC ignores the A
flag on a PCUpd message unless the operator's policy allows the flag on a PCUpd message unless the operator's policy allows the
PCE to control the corresponding LSP's administrative state. PCE to control the corresponding LSP's administrative state.
skipping to change at page 34, line 51 skipping to change at page 35, line 8
2 - ACTIVE: up and carrying traffic. 2 - ACTIVE: up and carrying traffic.
3 - GOING-DOWN: LSP is being torn down, resources are being 3 - GOING-DOWN: LSP is being torn down, resources are being
released. released.
4 - GOING-UP: LSP is being signalled. 4 - GOING-UP: LSP is being signalled.
5-7 - Reserved: these values 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. When sending a PCUpd
message, the PCE MUST set the O Field to 0.
TLVs that may be included in the LSP Object are described in the TLVs that may be included in the LSP Object are described in the
following sections. following sections. Other optional TLVs, that are not defined in
this document, MAY also be included within the LSP Object body.
7.3.1. LSP-IDENTIFIERS TLVs 7.3.1. LSP-IDENTIFIERS TLVs
The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt
messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will
generate an error with error-type 6 (mandatory object missing) and generate an error with error-type 6 (mandatory object missing) and
error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd
messages for RSVP-signaled LSPs. The special value of all zeros for messages for RSVP-signaled LSPs. The special value of all zeros for
this TLV is used to refer to all paths pertaining to a particular this TLV is used to refer to all paths pertaining to a particular
skipping to change at page 35, line 32 skipping to change at page 35, line 39
a make-before-break scenario, the PCC MUST send a separate PCRpt for a make-before-break scenario, the PCC MUST send a separate PCRpt for
the old and for the reoptimized paths, and explicitly report removal the old and for the reoptimized paths, and explicitly report removal
of any of these paths using the R bit in the LSP object. of any of these paths using the R bit in the LSP object.
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=16 | | Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address | | IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPV4-LSP-IDENTIFIERS TLV format Figure 12: IPV4-LSP-IDENTIFIERS TLV format
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is 18. The length field is 16 bit-long
field is 16 bit-long and has a fixed value of 16. The value contains and has a fixed value of 16. The value contains the following
the following fields: fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object. A value of 0 MUST be used if the LSP is not yet signaled. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
skipping to change at page 37, line 8 skipping to change at page 37, line 8
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4
address, as defined in [RFC3209], Section 4.6.1.1 for the address, as defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Sender Template Object. LSP_TUNNEL_IPv4 Sender Template Object.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=52 | | Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
skipping to change at page 37, line 39 skipping to change at page 37, line 39
+ + + +
| IPv6 tunnel endpoint address | | IPv6 tunnel endpoint address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPV6-LSP-IDENTIFIERS TLV format Figure 13: IPV6-LSP-IDENTIFIERS TLV format
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is 19. The length field is 16 bit-long
field is 16 bit-long and has a fixed value of 52. The value contains and has a fixed value of 52. The value contains the following
the following fields: fields:
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, IPv6 Tunnel Sender Address: contains the sender node's IPv6 address,
as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
Object. A value of 0 MUST be used if the LSP is not yet signaled. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
skipping to change at page 38, line 17 skipping to change at page 38, line 17
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6
address, as defined in [RFC3209], Section 4.6.1.2 for the address, as defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
The Tunnel ID remains constant over the life time of a tunnel. The Tunnel ID remains constant over the life time of a tunnel.
7.3.2. Symbolic Path Name TLV 7.3.2. Symbolic Path Name TLV
Each LSP (path) MUST have a symbolic name that is unique in the PCC. Each LSP MUST have a symbolic path name that is unique in the PCC.
This symbolic path name MUST remain constant throughout an LSP's The symbolic path name is a human-readable string that identifies an
lifetime, which may span across multiple consecutive PCEP sessions LSP in the network. The symbolic path name MUST remain constant
and/or PCC restarts. The symbolic path name MAY be specified by an throughout an LSP's lifetime, which may span across multiple
operator in a PCC's configuration. If the operator does not specify consecutive PCEP sessions and/or PCC restarts. The symbolic path
a unique symbolic name for a path, the PCC MUST auto-generate one. name MAY be specified by an operator in a PCC's configuration. If
the operator does not specify a unique symbolic name for an LSP, then
the PCC MUST auto-generate one.
The PCE uses the symbolic path name as a stable identifier for the
LSP. If the PCEP session restarts, or the PCC restarts, or the PCC
re-delegates the LSP to a different PCE, the symbolic path name for
the LSP remains constant and can be used to correlate across the PCEP
session instances.
The other protocol identifiers for the LSP cannot reliably be used to
identify the LSP across multiple PCEP sessions, for the following
reasons.
o The PLSP-ID is unique only within the scope of a single PCEP
session.
o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs
that are signalled with RSVP-TE, and may change during the
lifetime of the LSP.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
LSP State Report (PCRpt) message when during a given PCEP session an LSP State Report (PCRpt) message when during a given PCEP session an
LSP is first reported to a PCE. A PCC sends to a PCE the first LSP LSP is first reported to a PCE. A PCC sends to a PCE the first LSP
State Report either during State Synchronization, or when a new LSP State Report either during State Synchronization, or when a new LSP
is configured at the PCC. The symbolic path name MAY be included in is configured at the PCC.
the LSP object in subsequent LSP State Reports for the LSP.
The initial PCRpt creates a binding between the symbolic path name
and the PLSP-ID for the LSP which lasts for the duration of the PCEP
session. The PCC MAY omit the symbolic path name from subsequent LSP
State Reports for that LSP on that PCEP session, and just use the
PLSP-ID.
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV format Figure 14: SYMBOLIC-PATH-NAME TLV format
Type (16 bits): to be assigned by IANA. Type (16 bits): The type is 17.
Length (16 bits): indicates the total length of the TLV in octets and Length (16 bits): indicates the total length of the TLV in octets and
MUST be greater than 0. The TLV MUST be zero-padded so that the TLV MUST be greater than 0. The TLV MUST be zero-padded so that the TLV
is 4-octet aligned. is 4-octet aligned.
Symbolic Path Name (variable): symbolic name for the LSP, unique in Symbolic Path Name (variable): symbolic name for the LSP, unique in
the PCC. the PCC. It SHOULD be a string of printable ASCII characters and
SHOULD be NULL-terminated. The Symbolic Path Name (including its
NULL terminator) MUST be padded to 4-bytes alignment; the padding
itself MUST NOT be included in the Length field.
7.3.3. LSP Error Code TLV 7.3.3. LSP Error Code TLV
The LSP Error code TLV is an optional TLV for use in the LSP object The LSP Error code TLV is an optional TLV for use in the LSP object
to convey error information. When an LSP Update Request fails, an to convey error information. When an LSP Update Request fails, an
LSP State Report MUST be sent to report the current state of the LSP, LSP State Report MUST be sent to report the current state of the LSP,
and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for
the failure. Similarly, when a PCRpt is sent as a result of an LSP the failure. Similarly, when a PCRpt is sent as a result of an LSP
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD
be included to indicate the reason for the transition. be included to indicate the reason for the transition.
The format of the LSP-ERROR-CODE TLV is shown in the following The format of the LSP-ERROR-CODE TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV format Figure 15: LSP-ERROR-CODE TLV format
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is 20. The length field is 16 bit-long
field is 16 bit-long and has a fixed value of 4. The value contains and has a fixed value of 4. The value contains an error code that
an error code that indicates the cause of the failure. indicates the cause of the failure.
The following LSP Error Codes are currently defined: The following LSP Error Codes are currently defined:
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
skipping to change at page 40, line 15 skipping to change at page 41, line 8
SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object.
The format of the RSVP-ERROR-SPEC TLV is shown in the following The format of the RSVP-ERROR-SPEC TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object + + RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV format Figure 16: RSVP-ERROR-SPEC TLV format
Type (16 bits):to be assigned by IANA. Type (16 bits): The type is 21.
Length (16 bits): indicates the total length of the TLV in octets. Length (16 bits): indicates the total length of the TLV in octets.
The TLV MUST be zero-padded so that the TLV is 4-octet aligned. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
Object: as specified in [RFC2205] and [RFC5284], including the object Object: as specified in [RFC2205] and [RFC5284], including the object
header. header.
8. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. Values shown here are protocol elements defined in this document.
suggested for use by IANA.
8.1. PCE Capabilities in IGP Advertisements 8.1. PCE Capabilities in IGP Advertisements
IANA is requested to allocate new bits in the OSPF Parameters "PCE IANA is requested to confirm the early allocation of the following
Capability Flags" registry, as follows: bits in the OSPF Parameters "PCE Capability Flags" registry, and to
update the reference in the registry to point to this document, when
it is an RFC:
Bit Meaning Reference Bit Meaning Reference
11 Active Stateful PCE This document 11 Active Stateful PCE This document
capability capability
12 Passive Stateful PCE This document 12 Passive Stateful PCE This document
capability capability
8.2. PCEP Messages 8.2. PCEP Messages
IANA is requested to allocate new message types within the "PCEP IANA is requested to confirm the early allocation of the following
Messages" sub-registry of the PCEP Numbers registry, as follows: message types within the "PCEP Messages" sub-registry of the PCEP
Numbers registry, and to update the reference in the registry to
point to this document, when it is an RFC:
Value Meaning Reference Value Meaning Reference
10 Report This document 10 Report This document
11 Update This document 11 Update This document
8.3. PCEP Objects 8.3. PCEP Objects
IANA is requested to allocate new object-class values and object IANA is requested to confirm the early allocation of the following
types within the "PCEP Objects" sub-registry of the PCEP Numbers object-class values and object types within the "PCEP Objects" sub-
registry, as follows. registry of the PCEP Numbers registry, and to update the reference in
the registry to point to this document, when it is an RFC:.
Object-Class Value Name Reference Object-Class Value Name Reference
32 LSP This document 32 LSP This document
Object-Type Object-Type
1 1
33 SRP This document 33 SRP This document
Object-Type Object-Type
1 1
8.4. LSP Object 8.4. LSP Object
This document requests that a new sub-registry, named "LSP Object This document requests that a new sub-registry, named "LSP Object
Flag Field", is created within the "Path Computation Element Protocol Flag Field", is created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Flag field of the LSP (PCEP) Numbers" registry to manage the Flag field of the LSP object.
object.New values are to be assigned by Standards Action [RFC5226]. New values are to be assigned by Standards Action [RFC5226]. Each
Each bit should be tracked with the following qualities: bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
0-4 Reserved This document 0-4 Reserved This document
5-7 Operational (3 bits) This document 5-7 Operational (3 bits) This document
8 Administrative This document 8 Administrative This document
9 Remove This document 9 Remove This document
10 SYNC This document 10 SYNC This document
11 Delegate This document 11 Delegate This document
8.5. PCEP-Error Object 8.5. PCEP-Error Object
IANA is requested to allocate new Error Types and Error Values within IANA is requested to confirm the early allocation of the following
the " PCEP-ERROR Object Error Types and Values" sub-registry of the Error Types and Error Values within the "PCEP-ERROR Object Error
PCEP Numbers registry, as follows: Types and Values" sub-registry of the PCEP Numbers registry, and to
update the reference in the registry to point to this document, when
it is an RFC:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=9: ERO Object missing
Error-value=10: SRP Object missing Error-value=10: SRP Object missing
Error-value=11: LSP-IDENTIFIERS TLV missing Error-value=11: LSP-IDENTIFIERS TLV missing
19 Invalid Operation 19 Invalid Operation
Error-value=1: Attempted LSP Update Request for a non- Error-value=1: Attempted LSP Update Request for a non-
delegated LSP. The PCEP-ERROR Object delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that is followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: Attempted LSP Update Request if the Error-value=2: Attempted LSP Update Request if the
stateful PCE capability was not stateful PCE capability was not
advertised. advertised.
Error-value=3: Attempted LSP Update Request for an LSP Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID. identified by an unknown PLSP-ID.
Error-value=5: Attempted LSP State Report if active Error-value=5: Attempted LSP State Report if stateful
stateful PCE capability was not PCE capability was not advertised.
advertised.
20 LSP State synchronization error. 20 LSP State synchronization error.
Error-value=1: A PCE indicates to a PCC that it can Error-value=1: A PCE indicates to a PCC that it can
not process (an otherwise valid) LSP not process (an otherwise valid) LSP
State Report. The PCEP-ERROR Object is State Report. The PCEP-ERROR Object is
followed by the LSP Object that followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=5: A PCC indicates to a PCE that it can Error-value=5: A PCC indicates to a PCE that it can
not complete the state synchronization, not complete the state synchronization,
8.6. Notification Object 8.6. Notification Object
IANA is requested to allocate new Notification Types and Notification IANA is requested to confirm the early allocation of the following
Values within the "Notification Object" sub-registry of the PCEP Notification Types and Notification Values within the "Notification
Numbers registry, as follows: Object" sub-registry of the PCEP Numbers registry, and to update the
reference in the registry to point to this document, when it is an
RFC:
Notification-Type Meaning Notification-Type Meaning
4 Stateful PCE resource limit exceeded 4 Stateful PCE resource limit exceeded
Notification-value=1: Entering resource limit Notification-value=1: Entering resource limit
exceeded state exceeded state
Notification-value=2: Exiting resource limit exceeded
state Note to IANA: the early allocation included an additional
Notification value 2 for "Exiting resource limit exceeded state".
This Notification value is no longer required.
8.7. PCEP TLV Type Indicators 8.7. PCEP TLV Type Indicators
IANA is requested to allocate new TLV Type Indicator values within IANA is requested to confirm the early allocation of the following
the " PCEP TLV Type Indicators" sub-registry of the PCEP Numbers TLV Type Indicator values within the "PCEP TLV Type Indicators" sub-
registry, as follows: registry of the PCEP Numbers registry, and to update the reference in
the registry to point to this document, when it is an RFC:
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document 18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document 20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
8.8. STATEFUL-PCE-CAPABILITY TLV 8.8. STATEFUL-PCE-CAPABILITY TLV
skipping to change at page 45, line 35 skipping to change at page 46, line 43
priority for PCEs. This effectively defines the primary PCE and one priority for PCEs. This effectively defines the primary PCE and one
or more backup PCEs to which primary PCE's LSPs can be delegated when or more backup PCEs to which primary PCE's LSPs can be delegated when
the primary PCE fails. the primary PCE fails.
Policies defined for stateful PCEs and PCCs should eventually fit in Policies defined for stateful PCEs and PCCs should eventually fit in
the Policy-Enabled Path Computation Framework defined in [RFC5394], the Policy-Enabled Path Computation Framework defined in [RFC5394],
and the framework should be extended to support Stateful PCEs. and the framework should be extended to support Stateful PCEs.
9.2. Information and Data Models 9.2. Information and Data Models
PCEP session configuration and information in the PCEP MIB module The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include
SHOULD be extended to include advertised stateful capabilities,
synchronization status, and delegation status (at the PCC list PCEs o advertised stateful capabilities and synchronization status per
with delegated LSPs). PCEP session
o the delegation status of each configured LSP.
The PCEP MIB [RFC7420] could also be updated to include this
information.
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
PCEP extensions defined in this document do not require any new PCEP extensions defined in this document do not require any new
mechanisms beyond those already defined in [RFC5440], Section 8.3. mechanisms beyond those already defined in [RFC5440], Section 8.3.
9.4. Verifying Correct Operation 9.4. Verifying Correct Operation
Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP
extensions defined in this document. In addition to monitoring extensions defined in this document. In addition to monitoring
skipping to change at page 47, line 9 skipping to change at page 48, line 23
protected. protected.
The security provisions described in [RFC5440] remain applicable to The security provisions described in [RFC5440] remain applicable to
these extensions. However, because the protocol modifications these extensions. However, because the protocol modifications
outlined in this document allow the PCE to control path computation outlined in this document allow the PCE to control path computation
timing and sequence, the PCE defense mechanisms described in timing and sequence, the PCE defense mechanisms described in
[RFC5440] section 7.2 are also now applicable to PCC security. [RFC5440] section 7.2 are also now applicable to PCC security.
As a general precaution, it is RECOMMENDED that these PCEP extensions As a general precaution, it is RECOMMENDED that these PCEP extensions
only be activated on authenticated and encrypted sessions across PCEs only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority. and PCCs belonging to the same administrative authority, using
Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the
recommendations and best current practices in [RFC7525].
The following sections identify specific security concerns that may The following sections identify specific security concerns that may
result from the PCEP extensions outlined in this document along with result from the PCEP extensions outlined in this document along with
recommended mechanisms to protect PCEP infrastructure against related recommended mechanisms to protect PCEP infrastructure against related
attacks. attacks.
10.2. LSP State Snooping 10.2. LSP State Snooping
The stateful nature of this extension explicitly requires LSP status The stateful nature of this extension explicitly requires LSP status
updates to be sent from PCC to PCE. While this gives the PCE the updates to be sent from PCC to PCE. While this gives the PCE the
skipping to change at page 48, line 13 skipping to change at page 49, line 28
appropriate PCRpt message. As soon as that message is enqueued in appropriate PCRpt message. As soon as that message is enqueued in
the session, the PCC is free to drop any incoming PCUpd messages the session, the PCC is free to drop any incoming PCUpd messages
without additional processing. without additional processing.
10.4. Malicious PCC 10.4. Malicious PCC
A stateful session also results in an increased attack surface by A stateful session also results in an increased attack surface by
placing a requirement for the PCE to keep an LSP state replica for placing a requirement for the PCE to keep an LSP state replica for
each PCC. It is RECOMMENDED that PCE implementations provide a limit each PCC. It is RECOMMENDED that PCE implementations provide a limit
on resources a single PCC can occupy. A PCE implementing such a on resources a single PCC can occupy. A PCE implementing such a
limit MUST send a PCNtf message with notification-type to be assigned limit MUST send a PCNtf message with notification-type 4 (Stateful
by IANA (Stateful PCE resource limit exceeded) and notification-value PCE resource limit exceeded) and notification-value 1 (Entering
to be assigned by IANA (Entering resource limit exceeded state) upon resource limit exceeded state) upon receiving an LSP state report
receiving an LSP state report causing it to exceed this threshold. causing it to exceed this threshold.
Delegation of LSPs can create further strain on PCE resources and a Delegation of LSPs can create further strain on PCE resources and a
PCE implementation MAY preemptively give back delegations if it finds PCE implementation MAY preemptively give back delegations if it finds
itself lacking the resources needed to effectively manage the itself lacking the resources needed to effectively manage the
delegation. Since the delegation state is ultimately controlled by delegation. Since the delegation state is ultimately controlled by
the PCC, PCE implementations SHOULD provide throttling mechanisms to the PCC, PCE implementations SHOULD provide throttling mechanisms to
prevent strain created by flaps of either a PCEP session or an LSP prevent strain created by flaps of either a PCEP session or an LSP
delegation. delegation.
11. Contributing Authors 11. Contributing Authors
skipping to change at page 50, line 15 skipping to change at page 51, line 24
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <http://www.rfc-editor.org/info/rfc5511>. 2009, <http://www.rfc-editor.org/info/rfc5511>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<http://www.rfc-editor.org/info/rfc8051>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-pce-stateful-pce-app] [I-D.ietf-pce-pce-initiated-lsp]
Zhang, X. and I. Minei, "Applicability of a Stateful Path Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Computation Element (PCE)", draft-ietf-pce-stateful-pce- Extensions for PCE-initiated LSP Setup in a Stateful PCE
app-08 (work in progress), October 2016. Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
progress), March 2017.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)",
draft-ietf-pce-pcep-yang-02 (work in progress), March
2017.
[I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-12 (work in
progress), April 2017.
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-06 (work in ietf-pce-stateful-sync-optimizations-10 (work in
progress), October 2016. progress), March 2017.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", and throughput objectives in traffic engineering",
INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
skipping to change at page 51, line 40 skipping to change at page 53, line 19
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008, DOI 10.17487/RFC5394, December 2008,
<http://www.rfc-editor.org/info/rfc5394>. <http://www.rfc-editor.org/info/rfc5394>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Oracle Oracle
1501 4th Ave, suite 1800 1501 4th Ave, suite 1800
Seattle, WA 98101 Seattle, WA 98101
US US
Email: edward.crabbe@oracle.com Email: edward.crabbe@oracle.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: inaminei@google.com Email: inaminei@google.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
 End of changes. 99 change blocks. 
227 lines changed or deleted 332 lines changed or added

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