draft-ietf-pce-stateful-pce-02.txt   draft-ietf-pce-stateful-pce-03.txt 
Network Working Group E. Crabbe Network Working Group E. Crabbe
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: April 18, 2013 Cisco Systems, Inc. Expires: September 23, 2013 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
October 15, 2012 March 22, 2013
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-02 draft-ietf-pce-stateful-pce-03
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path synchronization or PCE control of timing and sequence of path
computations within and across PCEP sessions. This document computations within and across PCEP sessions. This document
describes a set of extensions to PCEP to enable stateful control of describes a set of extensions to PCEP to enable stateful control of
MPLS-TE and GMPLS tunnels via PCEP. MPLS-TE and GMPLS LSPs via PCEP.
Requirements Language 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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013. This Internet-Draft will expire on September 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation and Objectives for Stateful PCE in an MPLS TE 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 7
deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16
5. Architectural Overview of Protocol Extensions . . . . . . . . 16 5. Architectural Overview of Protocol Extensions . . . . . . . . 16
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 17 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 17
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 24 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 25 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 25 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 26
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 26 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 27
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 27 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 28
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 27 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 28
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 28 Request/Response . . . . . . . . . . . . . . . . . . . 29
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 29 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 30
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 30 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 31
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 31 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 32
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 32 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 33
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 33 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 33 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 34
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 34 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 35
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 35 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 35
7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 35 7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 36
7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 38 7.2.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 38
7.2.2. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 38 7.2.2. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 39
7.2.3. LSP State Database Version TLV . . . . . . . . . . . . 39 7.2.3. LSP State Database Version TLV . . . . . . . . . . . . 40
7.2.4. Delegation Parameters TLVs . . . . . . . . . . . . . . 40 7.2.4. Delegation Parameters TLVs . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 40 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 42 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 42
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43
9. Manageability Considerations . . . . . . . . . . . . . . . . . 42 9. Manageability Considerations . . . . . . . . . . . . . . . . . 43
9.1. Control Function and Policy . . . . . . . . . . . . . . . 42 9.1. Control Function and Policy . . . . . . . . . . . . . . . 43
9.2. Information and Data Models . . . . . . . . . . . . . . . 43 9.2. Information and Data Models . . . . . . . . . . . . . . . 44
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 44 Components . . . . . . . . . . . . . . . . . . . . . . . . 45
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 44 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 45
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 45 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 45
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 45 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 46
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 46 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 46
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 46 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 47
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 47 12.2. Informative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP. [RFC5440] describes the Path Computation Element Protocol (PCEP.
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE, (PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for enabling computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP) characteristics. Traffic Engineering Label Switched Path (TE LSP) characteristics.
Extensions for support of GMPLS in PCEP are defined in Extensions for support of GMPLS in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
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 tunnels between and across PCEP sessions in stateful control of LSPs between and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect tunnel compliance with [RFC4657]. It includes mechanisms to effect LSP
state synchronization between PCCs and PCEs, delegation of control state synchronization between PCCs and PCEs, delegation of control
over tunnels to PCEs, and PCE control of timing and sequence of path over LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer. PCE, PCEP Peer.
This document uses the following terms defined in [RFC4090]: MPLS TE This document uses the following terms defined in [RFC4090]: MPLS TE
Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.
The following terms are defined in this document: The following terms are defined in this document:
Passive Stateful PCE: uses LSP state information learned from PCCs Passive Stateful PCE: uses LSP state information learned from PCCs
to optimize path computations. It does not actively update tunnel to optimize path computations. It does not actively update LSP
state. A PCC maintains synchronization with the PCE. state. A PCC maintains synchronization with the PCE.
Active Stateful PCE: uses tunnel state information learned from PCCs Active Stateful PCE: is an extension of Passive Stateful PCE, which
to optimize path computations. Additionally, it actively updates utilizes the Delegation mechanism to update LSP parameters in
tunnel parameters in those PCCs that delegated control over their those PCCs that delegated control over their LSPs to the PCE.
tunnels to the PCE.
Delegation: An operation to grant a PCE temporary rights to modify a Delegation: An operation to grant a PCE temporary rights to modify a
subset of tunnel parameters on one or more PCC's tunnels. Tunnels subset of LSP parameters on one or more PCC's LSPs. LSPs are
are delegated from a PCC to a PCE. delegated from a PCC to a PCE, and are referred to as delegated
LSPs. The PCC who owns the PCE state for the LSP has the right to
delegate it. An LSP is owned by a single PCC at any given point
in time.
Revocation An operation performed by a PCC on a previously delegated
LSP. Revocation revokes the rights granted to the PCE in the
delegation operation.
Delegation Timeout Interval: when a PCEP session is terminated, a Delegation Timeout Interval: when a PCEP session is terminated, a
PCC waits for this time period before revoking tunnel delegation PCC waits for this time period before revoking LSP delegation to a
to a PCE. PCE. The delegation timeout interval is a PCC-local value that
can be either operator-configured or dynamically computed by the
PCC based on local policy.
LSP State Report: an operation to send LSP state (Operational / LSP State Report: an operation to send LSP state (Operational /
Admin Status, LSP attributes configured and set by a PCE, etc.) Admin Status, LSP attributes configured and set by a PCE, etc.)
from a PCC to a PCE. from a PCC to a PCE.
LSP Update Request: an operation where a PCE requests a PCC to LSP Update Request: an operation where an Active Stateful PCE
update one or more attributes of an LSP and to re-signal the LSP requests a PCC to update one or more attributes of an LSP and to
with updated attributes. re-signal the LSP with updated attributes.
LSP Priority: a specific pair of MPLS setup and hold priority LSP Priority: a specific pair of MPLS setup and hold priority values
values. as defined in [RFC3209].
LSP State Database: information about and attributes of all LSPs LSP State Database: information about and attributes of all LSPs
that are being reported to one or more PCEs via LSP State Reports. that are being reported to one or more PCEs via LSP State Reports.
Minimum Cut Set: the minimum set of links for a specific source Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, result in a destination pair which, when removed from the network, result in a
specific source being completely isolated from specific specific source being completely isolated from specific
destination. The summed capacity of these links is equivalent to destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the the maximum capacity from the source to the destination by the
max-flow min-cut theorem. max-flow min-cut theorem.
skipping to change at page 6, line 37 skipping to change at page 6, line 43
by some downstream mode, the head-end LSP is notified by means of by some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend Label RSVP. Upon receiving the notification, the headend Label
Switching Router (LSR) recomputes the path and signals the LSP Switching Router (LSR) recomputes the path and signals the LSP
along an alternate path. [NET-REC] along an alternate path. [NET-REC]
MPLS TE Global Path Protection: once an LSP failure is detected by MPLS TE Global Path Protection: once an LSP failure is detected by
some downstream mode, the head-end LSP is notified by means of some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend LSR reroutes RSVP. Upon receiving the notification, the headend LSR reroutes
traffic using a pre-signaled backup (secondary) LSP. [NET-REC]. traffic using a pre-signaled backup (secondary) LSP. [NET-REC].
Revocation: an operation performed by a PCC on a previously Within this document, PCE-PCE communications are described by having
delegated LSP. Revocation clears the LSP's PCE specific state on the requesting PCE fill the role of a PCC. This provides a saving in
the PCC and, if a PCEP session with the PCE the LSP was delegated
to exists in the UP state, also generates a revocation message to
the PCE.
Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE in an MPLS TE deployment 3. Motivation and Objectives for Stateful PCE
3.1. Motivation 3.1. Motivation
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful showcasing scenarios that benefit from the deployment of a stateful
PCE. The scenarios are specific to MPLS TE deployments, but the PCE. The scenarios apply equally to MPLS-TE and GMPLS deployments.
extensions described in this document apply to GMPLS tunnels as well.
3.1.1. Background 3.1.1. Background
Traffic engineering has been a goal of the MPLS architecture since Traffic engineering has been a goal of the MPLS architecture since
its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209] engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis; total reserved capacity by traffic class on a per interface basis;
individual LSP state is available only locally on each LER for it's individual LSP state is available only locally on each LER for it's
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 8, line 11 skipping to change at page 8, line 11
o Any reliable synchronization mechanism would result in significant o Any reliable synchronization mechanism would result in significant
control plane overhead control plane overhead
o Out-of-band ted synchronization would be complex and prone to race o Out-of-band ted synchronization would be complex and prone to race
conditions conditions
o Path calculations incorporating total network state would be o Path calculations incorporating total network state would be
highly complex highly complex
In general, stress on the MPLS TE control plane will be directly In general, stress on the control plane will be directly proportional
proportional to the size of the system being controlled and the to the size of the system being controlled and the tightness of the
tightness of the control loop, and indirectly proportional to the control loop, and indirectly proportional to the amount of over-
amount of over-provisioning in terms of both network capacity and provisioning in terms of both network capacity and reservation
reservation overhead. overhead.
Despite these concerns in terms of implementation complexity and Despite these concerns in terms of implementation complexity and
scalability, several TE algorithms exist today that have been scalability, several TE algorithms exist today that have been
demonstrated to be extremely effective in large TE systems, providing demonstrated to be extremely effective in large TE systems, providing
both rapid convergence and significant benefits in terms of both rapid convergence and significant benefits in terms of
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
skipping to change at page 11, line 28 skipping to change at page 11, line 28
detailed in [RFC3209]. This behavior is directly implied to be detailed in [RFC3209]. This behavior is directly implied to be
correct in [RFC3209] and is often desirable from an operator's correct in [RFC3209] and is often desirable from an operator's
perspective, because either a) the destination prefixes are not perspective, because either a) the destination prefixes are not
reachable via any means other than MPLS or b) this would result in reachable via any means other than MPLS or b) this would result in
significant packet loss as demand is shifted to other LSPs in the significant packet loss as demand is shifted to other LSPs in the
overlay mesh. overlay mesh.
In addition, there are currently few implementations offering ingress In addition, there are currently few implementations offering ingress
admission control at the LSP level. Again, having ingress admission admission control at the LSP level. Again, having ingress admission
control on a per LSP basis is not necessarily desirable from an control on a per LSP basis is not necessarily desirable from an
operational perspective, as a) one must over-provision tunnels operational perspective, as a) one must over-provision LSPs
significantly in order to avoid deleterious effects resulting from significantly in order to avoid deleterious effects resulting from
stacked transport and flow control systems and b) there is currently stacked transport and flow control systems and b) there is currently
no efficient commonly available northbound interface for dynamic no efficient commonly available northbound interface for dynamic
configuration of per LSP ingress admission control (such an interface configuration of per LSP ingress admission control (such an interface
could easily be defined using the extensions present in this spec, could easily be defined using the extensions present in this spec,
but it beyond the scope of the current document). but it beyond the scope of the current document).
Lack of ingress admission control coupled with the behavior in Lack of ingress admission control coupled with the behavior in
[RFC3209] effectively results in mis-signaled LSPs during periods of [RFC3209] effectively results in mis-signaled LSPs during periods of
contention for network capacity between LSPs in a given LSP priority. contention for network capacity between LSPs in a given LSP priority.
skipping to change at page 16, line 40 skipping to change at page 16, line 40
LSP Update Request (E-C): A PCE requests modification of attributes LSP Update Request (E-C): A PCE requests modification of attributes
on a PCC's LSP. on a PCC's LSP.
LSP State Report (C-E): a PCC sends an LSP state report to a PCE LSP State Report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of an LSP changes. whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the authoritative source of the LSP's attributes as long as the
delegation is in effect (See Section 5.5); the PCC may withdraw delegation is in effect (See Section 5.5); the PCC may withdraw
the delegation or the PCE may give up the delegation the delegation or the PCE may give up the delegation at any time.
In addition to new PCEP functions, stateful capabilities discovery [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to
will be required in OSPF ([RFC5088]) and IS-IS ([RFC5089]). Stateful support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or
capabilities discovery is not in scope of this document. IS-IS ([RFC5089]) for PCE discovery.
5. Architectural Overview of Protocol Extensions 5. Architectural Overview of Protocol Extensions
5.1. LSP State Ownership 5.1. LSP State Ownership
In the PCEP protocol (defined in [RFC5440]), LSP state and operation In the PCEP protocol (defined in [RFC5440]), LSP state and operation
are under the control of a PCC (a PCC may be an LSR or a management are under the control of a PCC (a PCC may be an LSR or a management
station). Attributes received from a PCE are subject to PCC's local station). Attributes received from a PCE are subject to PCC's local
policy. The PCEP protocol extensions described in this document do policy. The PCEP protocol extensions described in this document do
not change this behavior. not change this behavior.
skipping to change at page 18, line 41 skipping to change at page 18, line 41
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the Stateful PCE Capability TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP protocol extensions for stateful PCEs MUST NOT be used if The PCEP protocol extensions for stateful PCEs MUST NOT be used if
one or both PCEP Speakers have not included the Stateful PCE one or both PCEP Speakers have not included the Stateful PCE
Capability TLV in their respective OPEN message, otherwise a PCErr Capability TLV in their respective OPEN message. If the PCEP
with code "Stateful PCE capability not negotiated" (see Section 8.4) Speakers support the extensions of this draft, then a PCErr with code
will be generated and the PCEP session will be terminated. "Stateful PCE capability not negotiated" (see Section 8.4) will be
generated and the PCEP session will be terminated.
LSP delegation and LSP update operations defined in this document MAY LSP delegation and LSP update operations defined in this document MAY
only be used if both PCEP Speakers set the LSP-UPDATE Flag in the only be used if both PCEP Speakers set the LSP-UPDATE Flag in the
"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)',
otherwise a PCErr with code "Delegation not negotiated" (see otherwise a PCErr with code "Delegation not negotiated" (see
Section 8.4) will be generated. Note that even if the update Section 8.4) will be generated. Note that even if the update
capability has not been negotiated, a PCE can still receive LSP capability has not been negotiated, a PCE can still receive LSP
Status Reports from a PCC and build and maintain an up to date view Status Reports from a PCC and build and maintain an up to date view
of the state of the PCC's LSPs. of the state of the PCC's LSPs.
skipping to change at page 19, line 20 skipping to change at page 19, line 21
phase ([RFC5440]). phase ([RFC5440]).
During State Synchronization, a PCC first takes a snapshot of the During State Synchronization, a PCC first takes a snapshot of the
state of its LSPs state, then sends the snapshot to a PCE in a state of its LSPs state, then sends the snapshot to a PCE in a
sequence of LSP State Reports. Each LSP State Report sent during sequence of LSP State Reports. Each LSP State Report sent during
State Synchronization has the SYNC Flag in the LSP Object set to 1. State Synchronization has the SYNC Flag in the LSP Object set to 1.
The set of LSPs for which state is synchronized with a PCE is The set of LSPs for which state is synchronized with a PCE is
determined by negotiated stateful PCEP capabilities and PCC's local determined by negotiated stateful PCEP capabilities and PCC's local
configuration (see more details in Section 9.1). configuration (see more details in Section 9.1).
The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
value 0. The LSP Object does not include the Symbolic Path name TLV
in this case.
A PCE SHOULD NOT send PCUpd messages to a PCC before State A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
If the PCC encounters a problem which prevents it from completing the If the PCC encounters a problem which prevents it from completing the
state transfer, it MUST send a PCErr message to the PCE and terminate state transfer, it MUST send a PCErr message to the PCE and terminate
the session using the PCEP session termination procedure. the session using the PCEP session termination procedure.
In the event of a PCC resetting the session during resynchronization,
the PCE MUST clean up state it received from this PCC. Session
reestablishment MUST be re-attempted per the procedures defined in
[RFC5440].
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgements for properly received
synchronization messages. It MUST respond with a PCErr message synchronization messages. It MUST respond with a PCErr message
indicating "PCRpt error" (see Section 8.4) if it encounters a problem indicating "PCRpt error" (see Section 8.4) if it encounters a problem
with the LSP State Report it received from the PCC. Either the PCE with the LSP State Report it received from the PCC. Either the PCE
or the PCC MAY terminate the session if the PCE encounters a problem or the PCC MAY terminate the session if the PCE encounters a problem
during the synchronization. during the synchronization.
The successful State Synchronization sequence is shown in Figure 3. The successful State Synchronization sequence is shown in Figure 3.
+-+-+ +-+-+ +-+-+ +-+-+
skipping to change at page 20, line 20 skipping to change at page 20, line 20
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-----PCRpt, SYNC=1----->| (Sync done) |-----PCRpt, SYNC=1----->| (Sync done)
| . | | . |
| . | | . |
| . | | . |
| | | |
|-----PCRpt, SYNC=0----->| (Regular |-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report) | | LSP State Report
| | for PLSP-ID=0)
Figure 3: Successful state synchronization Figure 3: Successful state synchronization
The sequence where the PCE fails during the State Synchronization The sequence where the PCE fails during the State Synchronization
phase is shown in Figure 4. phase is shown in Figure 4.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 21, line 41 skipping to change at page 21, line 42
version, which is incremented each time a change is made to the PCC's version, which is incremented each time a change is made to the PCC's
local LSP State Database. The LSP State Database version is an local LSP State Database. The LSP State Database version is an
unsigned 64-bit value that MUST be incremented by 1 for each unsigned 64-bit value that MUST be incremented by 1 for each
successive change in the LSP state database. The LSP State Database successive change in the LSP state database. The LSP State Database
version MUST start at 1 and may wrap around. Values 0 and version MUST start at 1 and may wrap around. Values 0 and
0xFFFFFFFFFFFFFFFF are reserved. 0xFFFFFFFFFFFFFFFF are reserved.
State Synchronization Avoidance is negotiated on a PCEP session State Synchronization Avoidance is negotiated on a PCEP session
during session startup. To make sure that a PCEP peer can recognize during session startup. To make sure that a PCEP peer can recognize
a previously connected peer even if its IP address changed, each PCEP a previously connected peer even if its IP address changed, each PCEP
peer includes the NODE_IDENTIFIER TLV in the OPEN message. peer includes the PREDUNDANCY-GROUP-ID TLV in the OPEN message.
If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN
object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the
LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the
PCC's latest LSP State Database version. PCC's latest LSP State Database version.
If a PCE's LSP State Database survived the restart of a PCEP session, If a PCE's LSP State Database survived the restart of a PCEP session,
the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and
the TLV will contain the last LSP State Database version received on the TLV will contain the last LSP State Database version received on
an LSP State Report from the PCC in a previous PCEP session. If a an LSP State Report from the PCC in a previous PCEP session. If a
PCC's LSP State Database survived the restart, the PCC will include PCC's LSP State Database survived the restart, the PCC will include
the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
the last LSP State Database version sent on an LSP State Update from the last LSP State Database version sent on an LSP State Update from
the PCC in the previous PCEP session. If a PCEP Speaker's LSP State the PCC in the previous PCEP session. If a PCEP Speaker's LSP State
Database did not survive the restart of a PCEP session, the PCEP Database did not survive the restart of a PCEP session, the PCEP
Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object.
If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN
Object and the TLV values match, the PCC MAY skip State Object and the TLV values match, the PCC MAY skip State
Synchronization. Otherwise, the PCE MUST purge any remaining LSP Synchronization. Otherwise, the PCC MUST perform State
state and expect the PCC to perform State Synchronization; if the PCC Synchronization. If the PCC attempts to skip State Synchronization
attempts to skip State Synchronization (i.e. the SYNC Flag = 0 on the (i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC),
first LSP State Report from the PCC), the PCE MUST send back a the PCE MUST send back a PCError with Error-type 20 Error-value 2
PCError with Error-type 20 Error-value 2 'LSP Database version 'LSP Database version mismatch', and close the PCEP session.
mismatch', and close the PCEP session.
If state synchronization is required, then after the Initialization
phase has completed, the PCE MUST mark any LSPs in the LSP database
that were previously reported by the PCC as stale. When the PCC
reports an LSP during state synchronization, if the LSP already
exists in the LSP database, the PCE MUST update the LSP database and
clear the stale marker from the LSP. When it has finished state
synchronization, the PCC MUST immediately send a PCRpt message
containing a state-report with an LSP object containing an PLSP-ID of
0 and with the SYNC flag set to 0 (see Section 5.4). This state-
report indicates to the PCE that state synchronization has completed.
On receiving this state-report, the PCE MUST purge any LSPs from the
LSP database that are still marked as stale.
Note that a PCE MAY force State Synchronization by not including the Note that a PCE MAY force State Synchronization by not including the
LSP-DB-VERSION TLV in its OPEN object. LSP-DB-VERSION TLV in its OPEN object.
Figure 6 shows an example sequence where State Synchronization is Figure 6 shows an example sequence where State Synchronization is
skipped. skipped.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
skipping to change at page 23, line 4 skipping to change at page 23, line 32
|--PCRpt,DBv=44,SYNC=0-->| (Regular |--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report) | | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->| |--PCRpt,DBv=45,SYNC=0-->|
| | | |
Figure 6: State Synchronization skipped Figure 6: State Synchronization skipped
Figure 7 shows an example sequence where State Synchronization is Figure 7 shows an example sequence where State Synchronization is
performed due to LSP State Database version mismatch during the PCEP performed due to LSP State Database version mismatch during the PCEP
session setup. Note that the same State Synchronization sequence session setup. Note that the same State Synchronization sequence
would happen if either the PCE or the PCE would not include the LSP- would happen if either the PCC or the PCE would not include the LSP-
DB-VERSION TLV in their respective Open messages. DB-VERSION TLV in their respective Open messages.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|--Open--, | |--Open--, |
| DBv=46 \ ,---Open--| | DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
skipping to change at page 24, line 35 skipping to change at page 25, line 35
Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent
from PCC from PCC
5.5. LSP Delegation 5.5. LSP Delegation
If during Capability negotiation both the PCE and the PCC have If during Capability negotiation both the PCE and the PCC have
indicated that they support LSP Update, then the PCC may choose to indicated that they support LSP Update, then the PCC may choose to
grant the PCE a temporary right to update (a subset of) LSP grant the PCE a temporary right to update (a subset of) LSP
attributes on one or more LSPs. This is called "LSP Delegation", and attributes on one or more LSPs. This is called "LSP Delegation", and
it MAY be performed at any time after the Initialization phase. it MAY be performed at any time after the Initialization phase,
including during the Synchronization phase.
LSP Delegation is controlled by operator-defined policies on a PCC. LSP Delegation is controlled by operator-defined policies on a PCC.
LSPs are delegated individually - different LSPs may be delegated to LSPs are delegated individually - different LSPs may be delegated to
different PCEs, and an LSP may be delegated to one or more PCEs. The different PCEs. An LSP is delegated to at most one PCE at any given
delegation policy, when all PCC's LSPs are delegated to a single PCE point in time. The delegation policy, when all PCC's LSPs are
at any given time, SHOULD be supported by all delegation-capable delegated to a single PCE at any given time, SHOULD be supported by
PCCs. Conversely, the policy revoking the delegation for all PCC's all delegation-capable PCCs. Conversely, the policy revoking the
LSPs SHOULD also be supported delegation for all PCC's LSPs SHOULD also be supported
A PCE may return LSP delegation at any time if it no longer wishes to A PCE may return LSP delegation at any time if it no longer wishes to
update the LSP's state. A PCC may revoke LSP delegation at any time. update the LSP's state. A PCC may revoke LSP delegation at any time.
Delegation, Revocation, and Return are done individually for each Delegation, Revocation, and Return are done individually for each
LSP. LSP.
In the event of an delegation being rejected or returned by a PCE,
the PCC should react based on local policy. It could either retry
delegating to the same PCE using an exponentially increasing timer or
delegate to an alternate PCE.
5.5.1. Delegating an LSP 5.5.1. Delegating an LSP
A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP
State Report to 1. A PCE confirms the delegation when it sends the State Report to 1. A PCE confirms the delegation when it sends the
first LSP Update Request for the delegated LSP to the PCC by setting first LSP Update Request for the delegated LSP to the PCC by setting
the Delegate flag to 1. Note that a PCE does not immediately confirm the Delegate flag to 1. Note that a PCE does not immediately confirm
to the PCC the acceptance of LSP Delegation; Delegation acceptance is to the PCC the acceptance of LSP Delegation; Delegation acceptance is
confirmed when the PCC wishes to update the LSP via the LSP Update confirmed when the PCE wishes to update the LSP via the LSP Update
Request. If a PCE does not accept the LSP Delegation, it MUST Request. If a PCE does not accept the LSP Delegation, it MUST
immediately respond with an empty LSP Update Request which has the immediately respond with an empty LSP Update Request which has the
Delegate flag set to 0. Delegate flag set to 0.
The delegation sequence is shown in Figure 9. The delegation sequence is shown in Figure 9.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 25, line 44 skipping to change at page 26, line 46
Figure 9: Delegating an LSP Figure 9: Delegating an LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE. the Delegate flag to 1 on each LSP Status Report sent to the PCE.
5.5.2. Revoking a Delegation 5.5.2. Revoking a Delegation
When a PCC decides that a PCE is no longer permitted to modify an When a PCC decides that a PCE is no longer permitted to modify an
LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke
an LSP delegation at any time during the LSP's life time. A PCC an LSP delegation at any time during the LSP's life time. A PCC
revoking a LSP MAY immediately clear the LSP state provided by the revoking an LSP delegation MAY immediately clear the LSP state
PCE, and MUST ignore any further PCUpd messages received regarding provided by the PCE. If the PCC has received but not yet acted on
the revoked LSP from the previous PCE delegate. PCUpd messages from the PCE for the LSP whose delegation is being
revoked, then it SHOULD ignore these PCUpd messages when processing
the message queue. Any further PCUpd messages are handled according
to the PCUpd procedures described in this document.
If a PCEP session with the PCE to which the LSP is delegated exists If a PCEP session with the PCE to which the LSP is delegated exists
in the UP state during the revocation, the PCC MUST notify that PCE in the UP state during the revocation, the PCC MUST notify that PCE
by sending an LSP State Report with the Delegate flag set to 0, as by sending an LSP State Report with the Delegate flag set to 0, as
shown in Figure 10. shown in Figure 10.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 26, line 25 skipping to change at page 27, line 30
|---PCRpt, Delegate=0--->| PCC revokes delegation |---PCRpt, Delegate=0--->| PCC revokes delegation
| | | |
Figure 10: Revoking a Delegation Figure 10: Revoking a Delegation
After an LSP delegation has been revoked, a PCE can no longer update After an LSP delegation has been revoked, a PCE can no longer update
LSP's parameters; an attempt to update parameters of a non-delegated LSP's parameters; an attempt to update parameters of a non-delegated
LSP will result in the PCC sending a PCErr message indicating "LSP is LSP will result in the PCC sending a PCErr message indicating "LSP is
not delegated" (see Section 8.4). not delegated" (see Section 8.4).
When a PCC's PCEP session with a PCE terminates, the PCC SHALL wait a When a PCC's PCEP session with a PCE terminates, the PCC MUST wait a
time interval specified in 'Delegation Timeout Interval' before time interval specified in 'Delegation Timeout Interval' before
revoking LSP delegations to the PCE. If a new PCEP session with the revoking LSP delegations to the PCE. If a new PCEP session with the
PCE can be established before the 'Delegation Timeout' timer expires, PCE can be established before the 'Delegation Timeout' timer expires,
LSP delegations to the PCE remain intact. If, after expiry of the LSP delegations to the PCE remain intact. If, after expiry of the
'Delegation Timeout' timer, a PCC can not delegate an LSP to another 'Delegation Timeout' timer, a PCC can not delegate an LSP to another
PCE (for example, if a PCC is not connected to any active stateful PCE (for example, if a PCC is not connected to any active stateful
PCE or if no connected active stateful PCE accepts the delegation), PCE or if no connected active stateful PCE accepts the delegation),
the PCC SHALL flush any LSP state set by the PCE. the PCC SHALL flush any LSP state set by the PCE.
If State Synchronization Avoidance is enabled, a PCC MUST increment If State Synchronization Avoidance is enabled, a PCC MUST increment
skipping to change at page 27, line 30 skipping to change at page 28, line 30
If a PCC can not delegate an LSP to a PCE (for example, if a PCC is If a PCC can not delegate an LSP to a PCE (for example, if a PCC is
not connected to any active stateful PCE or if no connected active not connected to any active stateful PCE or if no connected active
stateful PCE accepts the delegation), the LSP delegation on the PCC stateful PCE accepts the delegation), the LSP delegation on the PCC
will time out within a configurable Delegation Timeout Interval and will time out within a configurable Delegation Timeout Interval and
the PCC MUST flush any LSP state set by a PCE. the PCC MUST flush any LSP state set by a PCE.
5.5.4. Redundant Stateful PCEs 5.5.4. Redundant Stateful PCEs
Note that a PCE may not have any delegated LSPs: in a redundant Note that a PCE may not have any delegated LSPs: in a redundant
configuration where one PCE is backing up another PCE, the backup PCE configuration where one PCE is backing up another PCE, the backup PCE
will not have any delegated LSPs. The backup PCE does not update any may have only a subset of LSPs delegated to it. The backup PCE does
LSPs, but it receives all LSP State Reports from a PCC. When the not update any LSPs that are not delegated to it, but receives all
primary PCE fails, a PCC will delegate to the secondary PCE all LSPs LSP State Reports from a PCC. When the primary PCE for a given LSP
that had been previously delegated to the failed PCE. set fails, after expiry of the delegation timeout, that PCC will
delegate to the redundant PCE all LSPs that had been previously
delegated to the failed PCE.
5.6. LSP Operations 5.6. LSP Operations
5.6.1. Passive Stateful PCE Path Computation Request/Response 5.6.1. Passive Stateful PCE Path Computation Request/Response
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) Path computation |----- PCReq message --->| 1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation request sent to | |2) Path computation
skipping to change at page 30, line 21 skipping to change at page 31, line 21
A PCE sends an LSP Update Request carried on a PCUpd message to the A PCE sends an LSP Update Request carried on a PCUpd message to the
PCC. The LSP Update Request contains a variety of objects that PCC. The LSP Update Request contains a variety of objects that
specify the set of constraints and attributes for the LSP's path. specify the set of constraints and attributes for the LSP's path.
Additionally, the PCC may specify the urgency of such request by Additionally, the PCC may specify the urgency of such request by
assigning a request priority. A single PCUpd message MAY contain assigning a request priority. A single PCUpd message MAY contain
multiple LSP Update Requests. multiple LSP Update Requests.
Upon receiving a PCUpd message the PCC starts to setup LSPs specified Upon receiving a PCUpd message the PCC starts to setup LSPs specified
in LSP Update Requests carried in the message. For each LSP, it in LSP Update Requests carried in the message. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Pending'. indicating that the LSP's status is 'Pending'.If the PCC decides that
the LSP parameters proposed in the PCUpd message are unacceptable, it
MAY revoke the delegation. Error reporting for this condition will
be defined in a future version of this draft.
Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
to the PCE, indicating that the LSP's status is 'Up'. If the LSP to the PCE, indicating that the LSP's status is 'Up'. If the LSP
could not be set up, the PCC sends an LSP State Report indicating could not be set up, the PCC sends an LSP State Report indicating
that the LSP is 'Down' and stating the cause of the failure. A PCC that the LSP is 'Down' and stating the cause of the failure. A PCC
may choose to compress LSP State Updates to only reflect the most up may choose to compress LSP State Updates to only reflect the most up
to date state, as discussed in the previous section. to date state, as discussed in the previous section.
A PCC sends each LSP State Report to each stateful PCE that is A PCC sends each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
A PCC MUST NOT send to any PCE a Path Computation Request for a A PCC MUST NOT send to any PCE a Path Computation Request for a
delegated LSP. delegated LSP. Should the PCC decide it wants to issue a Path
Computation Request on a delegated LSP, it MUST perform Delegation
Revocation procedure first.
5.7. LSP Protection 5.7. LSP Protection
With a stateless PCE or a passive stateful PCE, LSP protection and LSP protection and interaction with stateful PCE, as well as the
restoration settings may be operator-configured locally at a PCC. A extensions necessary to implement this functionality will be
PCE may be merely asked to compute the protected (primary) and backup discussed in a separate draft.
(secondary) paths for the LSP.
An active stateful PCE controls the LSPs that are delegated to it,
and must therefore be able to set via PCEP the desired protection /
restoration mechanism for each delegated LSP. PCEP extensions for
stateful PCEs SHOULD support, at a minimum, the following protection
mechanisms for MPLS-TE LSPs:
o MPLS TE Global Default Restoration
o MPLS TE Global Path Protection
o FRR One-to-One Backup
o FRR Facility Backup - link protection, node protection, or both
The necessary extensions for support of protection are described in
technology-specific documents.
5.8. Transport 5.8. Transport
A Permanent PCEP session MUST be established between a stateful PCE A Permanent PCEP session MUST be established between a stateful PCE
and the PCC. and the PCC. In the case of session failure, session reestablishment
MUST be re-attempted per the procedures defined in [RFC5440].
State cleanup after session termination, as well as session setup State cleanup after session termination, as well as session setup
failures will be described in a later version of this document. failures will be described in a later version of this document.
6. PCEP Messages 6. PCEP Messages
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to in a PCEP message when the object must be included for the message to
skipping to change at page 32, line 5 skipping to change at page 32, line 31
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE, or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is set to [TBD]. for the PCRpt message is set to [TBD].
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= <LSP> <state-report> ::= <LSP>
[<path-list>] [<path-list>]
Where: Where:
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
Where: Where:
<path> is defined in technology-specific documents per LSP type. <path-list> is defined in [RFC5440] and extended by PCEP extensions.
The LSP object (see Section 7.2) is mandatory, and it MUST be The LSP object (see Section 7.2) is mandatory, and it MUST be
included in each LSP State Report on the PCRpt message. If the LSP included in each LSP State Report on the PCRpt message. If the LSP
object is missing, the receiving PCE MUST send a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP
object missing). object missing).
The path descriptor is described in separate technology-specific The path descriptor is described in separate technology-specific
documents according to the LSP type. documents according to the LSP type.
skipping to change at page 33, line 4 skipping to change at page 33, line 31
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <LSP> <update-request> ::= <LSP>
[<path-list>] [<path-list>]
Where: Where:
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
Where: Where:
<path> is defined in technology-specific documents per LSP type <path> is defined in technology-specific documents per LSP type
There is one mandatory object that MUST be included within each LSP There is one mandatory object that MUST be included within each LSP
Update Request in the PCUpd message: the LSP object (see Update Request in the PCUpd message: the LSP object (see
Section 7.2). If the LSP object is missing, the receiving PCE MUST Section 7.2). If the LSP object is missing, the receiving PCE MUST
send a PCErr message with Error-type=6 (Mandatory Object missing) and send a PCErr message with Error-type=6 (Mandatory Object missing) and
Error-value=[TBD] (LSP object missing). Error-value=[TBD] (LSP object missing).
Each LSP Update Request results in a separate LSP setup operation at A PCC only acts on an LSP Update Request if permitted by the local
a PCC. An LSP Update Request MUST contain all LSP parameters that a policy configured by the network manager. Each LSP Update Request
PCC wishes to set for the LSP. A PCC MAY set missing parameters from that the PCC acts on results in an LSP setup operation. An LSP
locally configured defaults. If the LSP specified the Update Request Update Request MUST contain all LSP parameters that a PCC wishes to
is already up, it will be re-signaled. The PCC will use make-before- set for the LSP. A PCC MAY set missing parameters from locally
break whenever possible in the re-signaling operation. configured defaults. If the LSP specified in the Update Request is
already up, it will be re-signaled.
The PCC SHOULD use the make-before-break procedures described in
[RFC3209] in the re-signaling operation. When traffic switchover to
the updated path and teardown of the old path are under the control
of PCC, no extensions are necessary. The PCC MUST send a PCrpt
message with the new path attributes to the PCE only after traffic
has been switched over. In some situations, it may be desirable for
the PCE to control the timing of traffic switchover. This mode of
operation and the extensions necessary to support it are left for
further study. In either case, resignaling of the path, label
allocation, and RSVP id allocations are under the control of the PCC.
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request to indicate the resulting state of the LSP in the network. A Request to indicate the resulting state of the LSP in the network. A
PCC MAY respond with multiple LSP State Reports to report LSP setup PCC MAY respond with multiple LSP State Reports to report LSP setup
progress of a single LSP. progress of a single LSP.
If the rate of PCUpd messages sent to a PCC for the same target LSP If the rate of PCUpd messages sent to a PCC for the same target LSP
exceeds the rate at which the PCC can signal LSPs into the network, exceeds the rate at which the PCC can signal LSPs into the network,
the PCC MAY perform state compression and only re-signal the last the PCC MAY perform state compression and only re-signal the last
modification in its queue. modification in its queue.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
Note also that it's up to the PCE to handle inter-LSP dependencies; Note also that it's up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP set-ups is required, the PCE has to for example, if ordering of LSP set-ups is required, the PCE has to
wait for an LSP State Report for a previous LSP before triggering the wait for an LSP State Report for a previous LSP before starting the
LSP setup of a next LSP. update of the next LSP. If the PCUpd cannot be satisfied (for
example due to unsupported object or TLV), the PCC MUST respond with
an PCErr message
6.3. The PCReq Message 6.3. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see A PCC MAY include the LSP object in the PCReq message (see
Section 7.2) if stateful PCE capability has been negotiated on a PCEP Section 7.2) if stateful PCE capability has been negotiated on a PCEP
session between the PCC and a PCE. The extensions to the PCReq session between the PCC and a PCE. The extensions to the PCReq
message are described in technology-specific documents for MPLS and message are described in technology-specific documents for MPLS and
GMPLS. GMPLS.
6.4. The PCRep Message 6.4. The PCRep Message
skipping to change at page 35, line 34 skipping to change at page 36, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP State DB Version | | LSP State DB Version |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-DB-VERSION TLV format Figure 15: LSP-DB-VERSION TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer. The value contains a 64-bit unsigned integer.
7.1.3. Node Identifier TLV 7.1.3. PCE Redundancy Group Identifier TLV
NODE-IDENTIFIER is an optional TLV that MAY be included in the OPEN PREDUNDANCY-GROUP-ID is an optional TLV that MAY be included in the
Object when a PCEP Speaker wishes to determine if State OPEN Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. It Synchronization can be skipped when a PCEP session is restarted. It
contains a unique identifier for the node that does not change during contains a unique identifier for the node that does not change during
the life time of the PCEP Speaker. It identifies the PCEP Speaker to the life time of the PCEP Speaker. It identifies the PCEP Speaker to
its peers if the Speaker's IP address changed. its peers if the Speaker's IP address changed.
The format of the NODE-IDENTIFIER TLV is shown in the following The format of the PREDUNDANCY-GROUP-ID TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// PCEP Speaker Node Identifier // // PCE redundancy group Identifier //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: NODE-IDENTIFIER TLV format Figure 16: PREDUNDANCY-GROUP-ID TLV format
The type of the TLV is [TBD] and it has a a variable length, which The type of the TLV is [TBD] and it has a a variable length, which
MUST be greater than 0. The value contains a node identifier that MUST be greater than 0. The value contains a node identifier that
MUST be unique in the network. The node identifier MAY be configured MUST be unique in the network. The node identifier MAY be configured
by an operator. If the node identifier is not configured by the by an operator. If the node identifier is not configured by the
operator, it can be derived from a PCC's MAC address or serial operator, it can be derived from a PCC's MAC address or serial
number. number.
7.2. LSP Object 7.2. LSP Object
skipping to change at page 36, line 43 skipping to change at page 37, line 28
LSP Object-Class is [TBD]. LSP Object-Class is [TBD].
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 17: The format of the LSP object body is shown in Figure 17:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-ID | Flags |R|O|S|D| | PLSP-ID | Flags |R|O|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The LSP Object format Figure 17: The LSP Object format
The LSP object body has a variable length and may contain additional The LSP object body has a variable length and may contain additional
TLVs. TLVs.
LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique PLSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique
LSP-ID for each LSP that is constant for the life time of a PCEP PLSP-ID for each LSP that is constant for the life time of a PCEP
session. The mapping of the Symbolic Path Name to LSP-ID is session. The mapping of the Symbolic Path Name to PLSP-ID is
communicated to the PCE by sending a PCRpt message containing the communicated to the PCE by sending a PCRpt message containing the
'Symbolic Path Name' TLV. All subsequent PCEP messages then address 'Symbolic Path Name' TLV. All subsequent PCEP messages then address
the LSP by the LSP-ID. the LSP by the PLSP-ID. The values of 0 and 0xFFFF are reserved.
Flags (12 bits): Flags (12 bits):
D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1
indicates that the PCC is delegating the LSP to the PCE. On a indicates that the PCC is delegating the LSP to the PCE. On a
PCUpd message, the D flag set to 1 indicates that the PCE is PCUpd message, the D flag set to 1 indicates that the PCE is
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP Delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation - the first PCRpt with the D flag
set to 0 revokes the delegation. To keep the delegation, the PCE set to 0 revokes the delegation. To keep the delegation, the PCE
skipping to change at page 38, line 11 skipping to change at page 38, line 49
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 and in separate technology-specific documents. following sections and in separate technology-specific documents.
7.2.1. Symbolic Path Name TLV 7.2.1. Symbolic Path Name TLV
Each LSP (path) MUST have a symbolic name that is unique in the PCC. Each LSP (path) MUST have a symbolic name that is unique in the PCC.
This symbolic path name MUST remain constant throughout a path's This symbolic path name MUST remain constant throughout a path's
lifetime, which may span across multiple consecutive PCEP sessions lifetime, which may span across multiple consecutive PCEP sessions
and/or PCC restarts. The symbolic path name MAY be specified by an and/or PCC restarts. The symbolic path name MAY be specified by an
operator in a PCC's CLI configuration. If the operator does not operator in a PCC's configuration. If the operator does not specify
specify a symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
when during a given PCEP session an LSP is first reported to a PCE. when during a given PCEP session an LSP is first reported to a PCE.
A PCC sends to a PCE the first LSP State Report either during State A PCC sends to a PCE the first LSP State Report either during State
Synchronization, or when a new LSP is configured at the PCC. The Synchronization, or when a new LSP is configured at the PCC. The
symbolic path name MAY be included in subsequent LSP State Reports symbolic path name MAY be included in subsequent LSP State Reports
for the LSP. for the LSP.
The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
and the LSPA Object. and the LSPA Object.
skipping to change at page 42, line 20 skipping to change at page 43, line 11
8.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
21 IPV4-RSVP-ERROR-SPEC This document 21 IPV4-RSVP-ERROR-SPEC This document
22 IPV6-RSVP-ERROR-SPEC This document 22 IPV6-RSVP-ERROR-SPEC This document
23 LSP-DB-VERSION This document 23 LSP-DB-VERSION This document
24 PREDUNDANCY-GROUP-ID This document
8.6. STATEFUL-PCE-CAPABILITY TLV 8.6. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
values are to be assigned by Standards Action [RFC5226]. Each bit values are to be assigned by Standards Action [RFC5226]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
skipping to change at page 43, line 13 skipping to change at page 44, line 6
specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
allow configuring the stateful PCEP capability and the LSP Update allow configuring the stateful PCEP capability and the LSP Update
capability. A PCC implementation SHOULD allow the operator to capability. A PCC implementation SHOULD allow the operator to
specify multiple candidate PCEs for and a delegation preference for specify multiple candidate PCEs for and a delegation preference for
each candidate PCE. A PCC SHOULD allow the operator to specify an each candidate PCE. A PCC SHOULD allow the operator to specify an
LSP delegation policy where LSPs are delegated to the most-preferred LSP delegation policy where LSPs are delegated to the most-preferred
online PCE. A PCC MAY allow the operator to specify different LSP online PCE. A PCC MAY allow the operator to specify different LSP
delegation policies. delegation policies.
A PCE or PCC implementation SHOULD allow the operator to configure a A PCE or PCC implementation SHOULD allow the operator to configure a
Node Identifier (Section 7.1.3). PREDUNDANCY-GROUP-ID (Section 7.1.3).
A PCC implementation which allows concurrent connections to multiple A PCC implementation which allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and it MUST NOT advertise LSP existence and state to a PCE if domains and it MUST NOT advertise LSP existence and state to a PCE if
the LSP is delegated to a PCE in a different group. the LSP is delegated to a PCE in a different group.
A PCC implementation SHOULD allow the operator to specify whether the A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically controlled by any PCE (for example, LSPs that are statically
configured at the PCC). configured at the PCC).
A PCC implementation SHOULD allow the operator to specify the A PCC implementation SHOULD allow the operator to specify the
Delegation Timeout Interval. The default value of the Delegation Delegation Timeout Interval. The default value of the Delegation
Timeout Interval SHOULD be set to 30 seconds. Timeout Interval SHOULD be set to 30 seconds. An operator MAY also
configure a policy that will dynamically adjust the Delegation
Timeout, for example setting it to zero when the PCC has an
established session to a backup PCE.
When an LSP can no longer be delegated to a PCE, after the expiration When an LSP can no longer be delegated to a PCE, after the expiration
of the Delegation Timeout Interval, the LSP MAY either: 1) retain its of the Delegation Timeout Interval, the LSP MAY either: 1) retain its
current parameters or 2) revert to operator-defined default LSP current parameters or 2) revert to operator-defined default LSP
parameters. This behavior SHOULD be configurable and in the case parameters. This behavior SHOULD be configurable and in the case
when (2) is supported, a PCC implementation MUST allow the operator when (2) is supported, a PCC implementation MUST allow the operator
to specify the default LSP parameters. to specify the default LSP parameters.
A PCC implementation SHOULD allow the operator to specify delegation A PCC implementation SHOULD allow the operator to specify delegation
priority for PCEs. This effectively defines the primary PCE and one priority for PCEs. This effectively defines the primary PCE and one
skipping to change at page 44, line 26 skipping to change at page 45, line 20
implementation SHOULD provide the following parameters: implementation SHOULD provide the following parameters:
o Total number of LSP updates o Total number of LSP updates
o Number of successful LSP updates o Number of successful LSP updates
o Number of dropped LSP updates o Number of dropped LSP updates
o Number of LSP updates where LSP setup failed o Number of LSP updates where LSP setup failed
A PCC implementation SHOULD provide a command to show to which PCEs A PCC implementation SHOULD provide a command to show for each LSP
LSPs are delegated. whether it is delegated, and if so, to which PCE.
A PCC implementation SHOULD allow the operator to manually revoke LSP A PCC implementation SHOULD allow the operator to manually revoke LSP
delegation. delegation.
9.5. Requirements on Other Protocols and Functional Components 9.5. Requirements on Other Protocols and Functional Components
PCEP protocol extensions defined in this document do not put new PCEP protocol extensions defined in this document do not put new
requirements on other protocols. requirements on other protocols.
9.6. Impact on Network Operation 9.6. Impact on Network Operation
skipping to change at page 46, line 42 skipping to change at page 47, line 32
delegation. Since the delegation state is ultimately controlled by delegation. Since the delegation state is ultimately controlled by
the PCC, PCE implementations SHOULD provide throttling mechanisms to the PCC, PCE implementations SHOULD provide throttling mechanisms to
prevent strain created by flaps of either a PCEP session or an LSP prevent strain created by flaps of either a PCEP session or an LSP
delegation. delegation.
11. Acknowledgements 11. Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria and Ramon We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar
Stefan Kobza and Kexin Tang for helpful discussions. Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej
Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath and
Calvin Ying for helpful comments and discussions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
skipping to change at page 47, line 49 skipping to change at page 48, line 41
March 2009. March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions] [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-06 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in
progress), July 2012. progress), October 2012.
[I-D.sivabalan-pce-disco-stateful]
Sivabalan, S. and J. Medved, "IGP Extensions for Stateful
PCE Discovery", draft-sivabalan-pce-disco-stateful-00
(work in progress), January 2013.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre- and throughput objectives in traffic engineering", pre-
print, 2011. print, 2011.
 End of changes. 79 change blocks. 
174 lines changed or deleted 223 lines changed or added

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