draft-ietf-pce-stateful-pce-08.txt   draft-ietf-pce-stateful-pce-09.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Google, Inc. Internet-Draft I. Minei
Intended status: Standards Track J. Medved Intended status: Standards Track Google, Inc.
Expires: August 16, 2014 Cisco Systems, Inc. Expires: December 24, 2014 J. Medved
I. Minei Cisco Systems, Inc.
Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
February 12, 2014 June 22, 2014
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-08 draft-ietf-pce-stateful-pce-09
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
PCEP sessions. This document describes a set of extensions to PCEP PCEP sessions. This document describes a set of extensions to PCEP
to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. to enable stateful control of 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 16, 2014. This Internet-Draft will expire on December 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 8 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8
5. Architectural Overview of Protocol Extensions . . . . . . . . 9 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 10 5.3. Capability Advertisement . . . . . . . . . . . . . . . . 10
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 14 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 14
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 17 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . 17
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17
5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 18 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 18
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 19 Request/Response . . . . . . . . . . . . . . . . . . 18
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 20 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . 20
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 22 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . 22
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26
6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 26
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 26 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 27
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 27 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 27 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 29
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 31 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 30
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . 32
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 35
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 35 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 37
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 37 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 38
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 38 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 39
8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39
9. Manageability Considerations . . . . . . . . . . . . . . . . . 39 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 40
9.1. Control Function and Policy . . . . . . . . . . . . . . . 39 9. Manageability Considerations . . . . . . . . . . . . . . . . 40
9.2. Information and Data Models . . . . . . . . . . . . . . . 40 9.1. Control Function and Policy . . . . . . . . . . . . . . . 40
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 40 9.2. Information and Data Models . . . . . . . . . . . . . . . 41
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41
9.5. Requirements on Other Protocols and Functional 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 42
Components . . . . . . . . . . . . . . . . . . . . . . . . 41 9.5. Requirements on Other Protocols and Functional Components 42
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 42
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 41 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 42
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 43
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 42 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 43
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 44
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP). [RFC5440] describes the Path Computation Element Protocol (PCEP).
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between PCEs, enabling (PCC) and a Path Computation Element (PCE), or between PCEs, enabling
computation of Multiprotocol Label Switching (MPLS) for Traffic computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP) characteristics. Extensions Engineering Label Switched Path (TE LSP) characteristics. Extensions
for support of Generalized MPLS (GMPLS) in PCEP are defined in for support of Generalized MPLS (GMPLS) in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
skipping to change at page 9, line 26 skipping to change at page 9, line 15
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 at any time. the delegation or the PCE may give up the delegation at any time.
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to
support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or
IS-IS ([RFC5089]) for PCE discovery. IS-IS ([RFC5089]) for PCE discovery.
5. Architectural Overview of Protocol Extensions 5. 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.
An active stateful PCE may have control of a PCC's LSPs that were An active stateful PCE may have control of a PCC's LSPs that were
skipping to change at page 10, line 40 skipping to change at page 10, line 26
messages as shown in the following table. messages as shown in the following table.
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| Function | Message | | Function | Message |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| Capability Advertisement (E-C,C-E) | Open | | Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt | | State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt | | LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd | | LSP Update Request (E-C) | PCUpd |
| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS sub- |
| | sub-TLV | | | TLV |
| OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, |
| | PCE-CAP-FLAGS sub-TLV | | | PCE-CAP-FLAGS sub-TLV |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
Table 1: New Function to Message Mapping Table 1: New Function to Message Mapping
5.3. Capability Advertisement 5.3. Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of stateful PCEP extensions. A PCEP Speaker advertise their support of stateful PCEP extensions. A PCEP Speaker
skipping to change at page 12, line 14 skipping to change at page 11, line 50
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 advertised stateful PCEP capabilities and PCC's local
configuration (see more details in Section 9.1). configuration (see more details in Section 9.1).
The end of synchronization marker is a PCRpt message with the SYNC The end of synchronization marker is a PCRpt message with the SYNC
Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV
in this case. If the PCC has no state to synchronize, it will only in this case, and it will include an empty ERO in its path. If the
send the end of synchronization marker. PCC has no state to synchronize, it will only send the end of
synchronization marker.
A PCE SHOULD NOT send PCUpd messages to a PCC before State A PCE SHOULD NOT send PCUpd messages to a PCC before State
Synchronization is complete. A PCC SHOULD NOT send PCReq messages to Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
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
skipping to change at page 19, line 4 skipping to change at page 18, line 41
PCE state indefinetely. Note also that flushing the state should be PCE state indefinetely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss. implemented using make-before-break to avoid traffic loss.
If there is a 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 larger than the standby PCE. Assuming the State Timeout Interval is larger than the
Redelegation Timeout, the LSP state will be kept intact. Redelegation Timeout, the LSP state will be kept intact.
5.6. LSP Operations 5.6. LSP Operations
5.6.1. Passive Stateful PCE Path Computation Request/Response
5.6.1. Passive Stateful PCE Path Computation Request/Response
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
1) Path computation |----- PCReq message --->| 1) Path computation |----- PCReq message --->|
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
skipping to change at page 19, line 35 skipping to change at page 19, line 33
6) Repeat for each |----- PCRpt message --->| 6) Repeat for each |----- PCRpt message --->|
LSP status change| | LSP status 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], Section sends a path computation request to the PCE ([RFC5440],
4.2.3). Section 4.2.3). The PCReq message MAY contain the LSP Object to
identify the LSP for which the path computation is requested.
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation and returns either a positive or a triggers a path computation and returns either a positive or a
negative reply to the PCC ([RFC5440], Section 4.2.4). negative reply to the PCC ([RFC5440], Section 4.2.4).
Upon receiving a positive path computation reply, the PCC receives a Upon receiving a positive path computation reply, the PCC receives a
set of computed paths and starts to setup the LSPs. For each LSP, it set of computed paths and starts to setup the LSPs. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Pending'. indicating that the LSP's status is "Going-up".
Once an LSP is up, the PCC sends an LSP State Report carried on a Once an LSP is up, the PCC sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Up'. PCRpt message 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 If the LSP could not be set up, the PCC sends an LSP State Report
indicating that the LSP is "Down' and stating the cause of the indicating that the LSP is "Down' and stating the cause of the
failure. Note that due to timing constraints, the LSP status may failure. Note that due to timing constraints, the LSP status may
change from 'Pending' to 'Up' (or 'Down') before the PCC has had a change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a
chance to send an LSP State Report indicating that the status is chance to send an LSP State Report indicating that the status is
'Pending'. In such cases, the PCC may choose to only send the PCRpt 'Going-up'. In such cases, the PCC may choose to only send the PCRpt
indicating the latest status ('Up' or 'Down'). indicating the latest status ('Up' or 'Down').
Upon receiving a negative reply from a PCE, a PCC may decide to Upon receiving a negative reply from a PCE, a PCC may decide to
resend a modified request or take any other appropriate action. For resend a modified request or take any other appropriate action. For
each requested LSP, it also sends an LSP State Report carried on a each requested LSP, it also sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Down'. PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
There is no direct correlation between PCRep and PCRpt messages. For There is no direct correlation between PCRep and PCRpt messages. For
a given LSP, multiple LSP State Reports will follow a single 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.
skipping to change at page 20, line 43 skipping to change at page 20, line 42
1) LSP State |-- PCRpt, Delegate=1 -->| 1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . | Synchronization | . |
or add new LSP | . |2) PCE decides to or add new LSP | . |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 Status Report|---- PCRpt message ---->|
sent(->Pending) | . | sent(->Going-up) | . |
| . | | . |
| . | | . |
5) LSP Status Report|---- PCRpt message ---->| 5) LSP Status 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.
skipping to change at page 21, line 23 skipping to change at page 21, line 23
specify the set of constraints and attributes for the LSP's path. specify the set of constraints and attributes for the LSP's path.
Each LSP Update Request has a unique identifier, the SRP-ID-number, Each LSP Update Request has a unique identifier, the SRP-ID-number,
carried in the SRP (Stateful PCE Request Parameters) Object described carried in the SRP (Stateful PCE Request Parameters) Object described
in Section 7.2. The SRP-ID-number is used to correlate errors and in Section 7.2. The SRP-ID-number is used to correlate errors and
state reports to LSP Update Requests. A single PCUpd message MAY state reports to LSP Update Requests. A single PCUpd message MAY
contain multiple LSP Update Requests. contain multiple LSP Update Requests.
Upon receiving a PCUpd message the PCC starts to setup LSPs specified Upon receiving a PCUpd message the PCC starts to setup LSPs specified
in LSP Update Requests carried in the message. For each LSP, it in LSP Update Requests carried in the message. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is 'Pending'. If the PCC decides indicating that the LSP's status is 'Going-up'. If the PCC decides
that the LSP parameters proposed in the PCUpd message are that the LSP parameters proposed in the PCUpd message are
unacceptable, it MUST report this error by including the LSP-ERROR- unacceptable, it MUST report this error by including the LSP-ERROR-
CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
parameters" in the LSP object in the PCRpt message to the PCE. Based parameters" in the LSP object in the PCRpt message to the PCE. Based
on local policy, it MAY react further to this error by revoking the on local policy, it MAY react further to this error by revoking the
delegation. If the PCC receives a PCUpd message for an LSP object delegation. If the PCC receives a PCUpd message for an LSP object
identified with a PLSP-ID that does not exist on the PCC, it MUST identified with a PLSP-ID that does not exist on the PCC, it MUST
generate a PCErr with error-type 19 (Invalid Operation), error-value generate a PCErr with error-type 19 (Invalid Operation), error-value
3, (Attempted LSP Update Request for an LSP identified by an unknown 3, (Attempted LSP Update Request for an LSP identified by an unknown
PSP-ID) (see Section 8.4). PSP-ID) (see Section 8.4).
skipping to change at page 23, line 28 skipping to change at page 23, line 28
<attribute-list> is defined in [RFC5440] and extended by PCEP extensions. <attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is 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 treats this as When the PCC does not include the SRP object, the PCE treats this as
an SRP object with an SRP-ID-number equal to the reserved value 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
object SHOULD be included and the value of the SRP-ID-number in the object MUST be included and the value of the SRP-ID-number in the SRP
SRP Object MUST be the same as that sent in the PCUpd message that Object MUST be the same as that sent in the PCUpd message that
triggered the state that is reported. If the PCC compressed several triggered the state that is reported. If the PCC compressed several
PCUpd messages for the same LSP by only processing the latest one, PCUpd messages for the same LSP by only processing the latest one,
then it should use the SRP-ID-number of that request. No state then it should use the SRP-ID-number of that request. No state
compression is allowed for state reporting, e.g. PCRpt messages MUST compression is allowed for state reporting, e.g. PCRpt messages MUST
NOT be pruned from the PCC's egress queue even if subsequent NOT be pruned from the PCC's egress queue even if subsequent
operations on the same LSP have been completed before the PCRpt operations on the same LSP have been completed before the PCRpt
message has been sent to the TCP stack. The PCC MUST explicitly message has been sent to the TCP stack. The PCC MUST explicitly
report state changes (including removal) for paths it manages. report state changes (including removal) for paths it manages.
The LSP object (see Section 7.3) is mandatory, and it MUST be The LSP object (see Section 7.3) is mandatory, and it MUST be
skipping to change at page 24, line 23 skipping to change at page 24, line 23
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCUpd message is set to [TBD]. the PCUpd message is set to [TBD].
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<udpate-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>::= <ERO><attribute-list> <path>::= <ERO><attribute-list>
skipping to change at page 25, line 22 skipping to change at page 25, line 22
messages for each, identified by the LSP-IDENTIFIERS TLV. When the messages for each, identified by the LSP-IDENTIFIERS TLV. When the
old path is torn down after the head end switches over the traffic, old path is torn down after the head end switches over the traffic,
this event MUST be reported by sending a PCRpt message with the LSP- this event MUST be reported by sending a PCRpt message with the LSP-
IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number
that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a
make-before-break operation will typically result in at least two make-before-break operation will typically result in at least two
PCRpt messages, one for the new path and one for the removal of the PCRpt messages, one for the new path and one for the removal of the
old path (more messages may be possible if intermediate states are old path (more messages may be possible if intermediate states are
reported). reported).
If the path setup fails due to an RSVP signaling error, the error is
reported to the PCE. The PCC will not attempt to resignal the path
until it is prompted again by the PCE with a subsequent PCUpd
message.
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request it processed to indicate the resulting state of the LSP in Request it processed to indicate the resulting state of the LSP in
the network (even if this processing did not result in changing the the network (even if this processing did not result in changing the
state of the LSP). The SRP-ID-number included in the PCRpt MUST state of the LSP). The SRP-ID-number included in the PCRpt MUST
match that in the PCUpd. A PCC MAY respond with multiple LSP State match that in the PCUpd. A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case, Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included for the first message, for the SRP-ID-number MUST be included for the first message, for
subsequent messages the reserved value 0x00000000 SHOULD be used. subsequent messages the reserved value 0x00000000 SHOULD be used.
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
skipping to change at page 26, line 41 skipping to change at page 26, line 46
<error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new <error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new
<error-obj-list> <error-obj-list>
<request-id-list>::=<RP>[<request-id-list>] <request-id-list>::=<RP>[<request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new <stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new
<error-list>::=<error>[<error-list>] <error-list>::=<error>[<error-list>]
6.4. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see
Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and a PCE.
The definition of the PCReq message from [RFC5440] is extended to
optionally include the LSP object after the END-POINTS object. The
encoding from [RFC5440] will become:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>] <--- New Object
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
6.5. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see
(Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was
included in the corresponding PCReq message from the PCC.
The definition of the PCRep message from [RFC5440] is extended to
optionally include the LSP object after the RP object. The encoding
from [RFC5440] will become:
<PCRep Message> ::= <Common Header>
<response-list>
Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>] <--- New Object
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
7. Object Formats 7. Object Formats
The PCEP objects defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document MUST always be set to 0 on PCEP objects defined in this document MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST be ignored on receipt since these flags are
exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
skipping to change at page 28, line 9 skipping to change at page 29, line 19
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 [TBD]. SRP Object-Class is [TBD].
SRP Object-Type is 1. SRP Object-Type is 1.
The format of the SRP object body is shown in Figure 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The SRP Object format Figure 10: The SRP Object format
The SRP object body has a variable length and may contain additional The SRP object body has a variable length and may contain additional
TLVs. TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the
optional TLVs.
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.
skipping to change at page 28, line 49 skipping to change at page 30, line 12
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
to an SRP object with the reserved value of 0x00000000. An SRP-ID- to an SRP object with the reserved value of 0x00000000. An SRP-ID-
number is considered unacknowledged and cannot be reused until a number is considered unacknowledged and cannot be reused until a
PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the
same LSP. A PCRpt with state "Pending" is not considered as an same LSP. In case of SRP-ID wrapping the last SRP-ID before the
acknowledgement. wrapping MUST be explicitly acknowledged, to avoid a situation where
SRP-IDs remain unacknowledged after the wrap. This means that the
PCC may need to issue two PCUpd messages on detecting a wrap.
7.3. LSP Object 7.3. LSP Object
The LSP object MUST be present within PCRpt and PCUpd messages. The The LSP object MUST be present within PCRpt and PCUpd messages. The
LSP object contains a set of fields used to specify the target LSP, LSP object MAY be carried within PCReq and PCRep messages if the
the operation to be performed on the LSP, and LSP Delegation. It stateful PCE capability has been negotiated on the session. The LSP
also contains a flag indicating to a PCE that the LSP state 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
contains a flag indicating to a PCE that the LSP state
synchronization is in progress. This document focuses on LSPs that synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object are signaled with RSVP, many of the TLVs used with the LSP object
mirror RSVP state. mirror RSVP state.
LSP Object-Class is [TBD]. LSP Object-Class is [TBD].
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 11: The format of the LSP object body is shown in Figure 11:
skipping to change at page 31, line 30 skipping to change at page 33, line 8
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=12 | | Type=[TBD] | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 8 skipping to change at page 34, 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 l following The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=36 | | Type=[TBD] | Length=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 34, line 37 skipping to change at page 35, line 34
operator in a PCC's configuration. If the operator does not specify operator in a PCC's configuration. If the operator does not specify
a unique symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
when during a given PCEP session an LSP is first reported to a PCE. when during a given PCEP session an LSP is first reported to a PCE.
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 the LSP Object The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
and the SRP Object.
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=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 35, line 37 skipping to change at page 36, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV format Figure 15: LSP-ERROR-CODE TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets. The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value contains an error code that indicates the cause of the The value contains an error code that indicates the cause of the
failure. failure.
The following LSP Error Codes are defined: The following LSP Error Codes are defined:
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
7.3.4. RSVP Error Spec TLV 7.3.4. RSVP Error Spec TLV
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
to carry RSVP error information. It includes the RSVP ERROR_SPEC or to carry RSVP error information. It includes the RSVP ERROR_SPEC or
USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned
to the PCC from a downstream node. If the set up of an LSP fails at to the PCC from a downstream node. If the set up of an LSP fails at
a downstream node which returned an ERROR_SPEC to the PCC, the PCC a downstream node which returned an ERROR_SPEC to the PCC, the PCC
SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 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
skipping to change at page 36, line 38 skipping to change at page 37, line 38
8. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. Values shown here are protocol elements defined in this document. Values shown here are
suggested for use by IANA. suggested for use by IANA.
8.1. PCEP Messages 8.1. PCEP Messages
This document defines the following new PCEP messages: This document defines the following new PCEP messages:
Value Meaning Reference Value Meaning Reference
10 Report This document 10 Report This document
11 Update This document 11 Update This document
8.2. PCEP Objects 8.2. PCEP Objects
This document defines the following new PCEP Object-classes and This document defines the following new PCEP Object-classes and
Object-values: Object-values:
Object-Class Value Name Reference Object-Class Value Name Reference
32 LSP This document 32 LSP This document
Object-Type Object-Type
1 1
33 SRP This document 33 SRP This document
Object-Type Object-Type
1 1
8.3. LSP Object 8.3. LSP Object
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field of the LSP object. New values are to be assigned by Standards field of the LSP object. New values are to be assigned by Standards
Action [RFC5226]. Each bit should be tracked with the following Action [RFC5226]. Each bit should be tracked with the following
qualities: qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
25-27 Operational (3 bits) This document 0-4 Reserved This document
28 Administrative This document 5-7 Operational (3 bits) This document
29 Remove This document 8 Administrative This document
30 SYNC This document 9 Remove This document
31 Delegate This document 10 SYNC This document
11 Delegate This document
8.4. PCEP-Error Object 8.4. PCEP-Error Object
This document defines new Error-Type and Error-Value for the This document defines new Error-Type and Error-Value for the
following new error conditions: following new error conditions:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=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 active Error-value=2: Attempted LSP Update Request if active
skipping to change at page 38, line 34 skipping to change at page 39, line 35
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.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document 18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document 20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document 21 RSVP-ERROR-SPEC This document
8.6. STATEFUL-PCE-CAPABILITY TLV 8.6. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
values are to be assigned by Standards Action [RFC5226]. Each bit values are to be assigned by Standards Action [RFC5226]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.7. LSP-ERROR-CODE TLV 8.7. LSP-ERROR-CODE TLV
This document requests that a registry is created to manage the value This document requests that a registry is created to manage the value
of the LSP error code field in this TLV. This field specifies the of the LSP error code field in this TLV. This field specifies the
reason for failure to update the LSP. reason for failure to update the LSP.
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
9. Manageability Considerations 9. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440] All manageability requirements and considerations listed in [RFC5440]
apply to PCEP protocol extensions defined in this document. In apply to PCEP protocol extensions defined in this document. In
addition, requirements and considerations listed in this section addition, requirements and considerations listed in this section
apply. apply.
9.1. Control Function and Policy 9.1. Control Function and Policy
skipping to change at page 40, line 48 skipping to change at page 41, line 48
9.2. Information and Data Models 9.2. Information and Data Models
PCEP session configuration and information in the PCEP MIB module PCEP session configuration and information in the PCEP MIB module
SHOULD be extended to include advertised stateful capabilities, SHOULD be extended to include advertised stateful capabilities,
synchronization status, and delegation status (at the PCC list PCEs synchronization status, and delegation status (at the PCC list PCEs
with delegated LSPs). with delegated LSPs).
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
PCEP protocol extensions defined in this document do not require any PCEP protocol extensions defined in this document do not require any
new mechanisms beyond those already defined in [RFC5440], Section new mechanisms beyond those already defined in [RFC5440],
8.3. 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
protocol extensions defined in this document. In addition to protocol extensions defined in this document. In addition to
monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP
implementation SHOULD provide the following parameters: implementation SHOULD provide the following parameters:
o Total number of LSP updates o Total number of LSP updates
skipping to change at page 44, line 38 skipping to change at page 45, line 36
(PCE) Discovery", RFC 5089, January 2008. (PCE) Discovery", RFC 5089, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
RFC 5284, August 2008. RFC 5284, August 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440, March
March 2009. 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-stateful-pce-app] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path Zhang, X. and I. Minei, "Applicability of a Stateful Path
Computation Element (PCE)", Computation Element (PCE)", draft-ietf-pce-stateful-pce-
draft-ietf-pce-stateful-pce-app-01 (work in progress), app-02 (work in progress), June 2014.
September 2013.
[I-D.minei-pce-stateful-sync-optimizations] [I-D.minei-pce-stateful-sync-optimizations]
Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X., Crabbe, E., Medved, J., Minei, I., 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", Synchronization Procedures for a Stateful PCE", draft-
draft-minei-pce-stateful-sync-optimizations-01 (work in minei-pce-stateful-sync-optimizations-02 (work in
progress), December 2013. progress), March 2014.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", for Stateful PCE Discovery", draft-sivabalan-pce-disco-
draft-sivabalan-pce-disco-stateful-03 (work in progress), stateful-03 (work in progress), January 2014.
January 2014.
[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
Information Infrastructure Symposium, July 2007. 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.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET- Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004. Networking, June 2004.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
Christian, B., and W. Lai, "Applicability Statement for Christian, B., and W. Lai, "Applicability Statement for
Traffic Engineering with MPLS", RFC 3346, August 2002. Traffic Engineering with MPLS", RFC 3346, August 2002.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630, September
September 2003. 2003.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[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, October 2008. Engineering", RFC 5305, October 2008.
skipping to change at page 46, line 27 skipping to change at page 47, line 27
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: edc@google.com Email: edc@google.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
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
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: inaminei@google.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
Mlynske Nivy 56 Mlynske Nivy 56
Bratislava 821 05 Bratislava 821 05
Slovakia Slovakia
Email: robert.varga@pantheon.sk Email: robert.varga@pantheon.sk
 End of changes. 52 change blocks. 
166 lines changed or deleted 232 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/