draft-ietf-pce-stateful-pce-03.txt   draft-ietf-pce-stateful-pce-04.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: September 23, 2013 Cisco Systems, Inc. Expires: November 9, 2013 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
March 22, 2013 May 8, 2013
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-03 draft-ietf-pce-stateful-pce-04
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path synchronization or PCE control of timing and sequence of path
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 23, 2013. This Internet-Draft will expire on November 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . 7 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 6
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 18
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 25
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 26
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 26 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 26
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 27 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 27
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 28 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 28
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 28 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 28
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 29 Request/Response . . . . . . . . . . . . . . . . . . . 29
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 30 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 30
skipping to change at page 3, line 44 skipping to change at page 3, line 44
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 32 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 32
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 33 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 33
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 34 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 34
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 35 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. PCE Redundancy Group Identifier TLV . . . . . . . . . 36 7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 36
7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 38 7.2.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 38
7.2.2. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 39 7.2.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 41
7.2.3. LSP State Database Version TLV . . . . . . . . . . . . 40 7.2.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 41
7.2.4. Delegation Parameters TLVs . . . . . . . . . . . . . . 41 7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 43
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 43
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 41 7.3. Optional TLVs for the LSPA Object . . . . . . . . . . . . 44
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3.1. Tunnel ID TLV . . . . . . . . . . . . . . . . . . . . 44
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 44
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 42
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9. Manageability Considerations . . . . . . . . . . . . . . . . . 43 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Control Function and Policy . . . . . . . . . . . . . . . 43 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Information and Data Models . . . . . . . . . . . . . . . 44 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 45
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 45
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 46
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46
9. Manageability Considerations . . . . . . . . . . . . . . . . . 47
9.1. Control Function and Policy . . . . . . . . . . . . . . . 47
9.2. Information and Data Models . . . . . . . . . . . . . . . 48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 45 Components . . . . . . . . . . . . . . . . . . . . . . . . 49
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 45 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 45 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 46 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 46 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 47 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 48 12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP. [RFC5440] describes the Path Computation Element Protocol (PCEP.
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE, (PCC) and a Path 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]
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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.
MPLS TE Global Default Restoration: once an LSP failure is detected
by some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend Label
Switching Router (LSR) recomputes the path and signals the LSP
along an alternate path. [NET-REC]
MPLS TE Global Path Protection: once an LSP failure is detected by
some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend LSR reroutes
traffic using a pre-signaled backup (secondary) LSP. [NET-REC].
Within this document, PCE-PCE communications are described by having Within this document, PCE-PCE communications are described by having
the requesting PCE fill the role of a PCC. This provides a saving in the requesting PCE fill the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE 3. Motivation and Objectives for Stateful PCE
3.1. Motivation 3.1. Motivation
skipping to change at page 7, line 28 skipping to change at page 7, line 14
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
retention of total LSP state for all LERs within in the network would retention of total LSP state for all LERs within in the network would
be prohibitively costly. be prohibitively costly.
Unfortunately, this visibility in terms of global LSP state may Unfortunately, this visibility in terms of global LSP state may
result in a number of issues for some demand patterns, particularly result in a number of issues for some demand patterns, particularly
within a common setup and hold priority. This issue affects online within a common setup and hold priority. This issue affects online
traffic engineering systems, and in particular, the widely traffic engineering systems.
implemented but seldom deployed auto-bandwidth system.
A sufficiently over-provisioned system will by definition have no A sufficiently over-provisioned system will by definition have no
issues routing its demand on the shortest path. However, lowering issues routing its demand on the shortest path. However, lowering
the degree to which network over-provisioning is required in order to the degree to which network over-provisioning is required in order to
run a healthy, functioning network is a clear and explicit promise of run a healthy, functioning network is a clear and explicit promise of
MPLS architecture. In particular, it has been a goal of MPLS to MPLS architecture. In particular, it has been a goal of MPLS to
provide mechanisms to alleviate congestion scenarios in which provide mechanisms to alleviate congestion scenarios in which
"traffic streams are inefficiently mapped onto available resources; "traffic streams are inefficiently mapped onto available resources;
causing subsets of network resources to become over-utilized while causing subsets of network resources to become over-utilized while
others remain underutilized" ([RFC2702]). others remain underutilized" ([RFC2702]).
skipping to change at page 16, line 8 skipping to change at page 15, line 47
PCE such that a single LSP is under the control a single PCE at PCE such that a single LSP is under the control a single PCE at
any given time. A PCC may revoke this delegation at any time any given time. A PCC may revoke this delegation at any time
during the lifetime of the LSP. If LSP delegation is revoked during the lifetime of the LSP. If LSP delegation is revoked
while the PCEP session is up, the PCC MUST notify the PCE about while the PCEP session is up, the PCC MUST notify the PCE about
the revocation. A PCE may return an LSP delegation at any point the revocation. A PCE may return an LSP delegation at any point
during the lifetime of the PCEP session. during the lifetime of the PCEP session.
o Allow a PCE to control computation timing and update timing across o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it. all LSPs that have been delegated to it.
o Allow a PCE to specify protection / restoration settings for all
LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event PCE o Enable uninterrupted operation of PCC's LSPs in the event PCE
failure or while control of LSPs is being transferred between failure or while control of LSPs is being transferred between
PCEs. PCEs.
4. New Functions to Support Stateful PCEs 4. New Functions to Support Stateful PCEs
Several new functions will be required in PCEP to support stateful Several new functions will be required in PCEP to support stateful
PCEs. A function can be initiated either from a PCC towards a PCE PCEs. A function can be initiated either from a PCC towards a PCE
(C-E) or from a PCE towards a PCC (E-C). The new functions are: (C-E) or from a PCE towards a PCC (E-C). The new functions are:
skipping to change at page 21, line 28 skipping to change at page 21, line 28
Figure 5: Failed state synchronization (PCC failure) Figure 5: Failed state synchronization (PCC failure)
5.4.1. State Synchronization Avoidance 5.4.1. State Synchronization Avoidance
State Synchronization MAY be skipped following a PCEP session restart State Synchronization MAY be skipped following a PCEP session restart
if the state of both PCEP peers did not change during the period if the state of both PCEP peers did not change during the period
prior to session re-initialization. To be able to make this prior to session re-initialization. To be able to make this
determination, state must be exchanged and maintained by both PCE and determination, state must be exchanged and maintained by both PCE and
PCC during normal operation. This is accomplished by keeping track PCC during normal operation. This is accomplished by keeping track
of the changes to the LSP State Database. When State Synchronization of the changes to the LSP State Database, using a database version
called the LSP State Database Version.
The LSP State Database version is an unsigned 64-bit value that MUST
be incremented by 1 for each successive change in the LSP state
database. The LSP State Database version MUST start at 1 and may
wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. The PCC
is the owner of the LSP State Database version, which is incremented
each time a change is made to the PCC's local LSP State Database.
Operations that trigger a change to the local LSP State database
include a change in the LSP operational state, delegation of an LSP,
removal or addition of an LSP or change in any of the LSP attributes
that would trigger a report to the PCE. When State Synchronization
avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- avoidance is enabled on a PCEP session, a PCC includes the LSP-DB-
VERSION TLV as an optional TLV in the LSP Object on each LSP State VERSION TLV as an optional TLV in the LSP Object on each LSP State
Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database
version, which is incremented each time a change is made to the PCC's version.
local LSP State Database. The LSP State Database version is an
unsigned 64-bit value that MUST be incremented by 1 for each
successive change in the LSP state database. The LSP State Database
version MUST start at 1 and may wrap around. Values 0 and
0xFFFFFFFFFFFFFFFF are reserved.
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 PREDUNDANCY-GROUP-ID TLV in the OPEN message. peer includes the PREDUNDANCY-GROUP-ID TLV in the OPEN message.
If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN
object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the
LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the
PCC's latest LSP State Database version. PCC's latest LSP State Database version.
If a PCE's LSP State Database survived the restart of a PCEP session, If a PCE's LSP State Database survived the restart of a PCEP session,
the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and
the TLV will contain the last LSP State Database version received on the TLV will contain the last LSP State Database version received on
an LSP State Report from the PCC in a previous PCEP session. If a an LSP State Report from the PCC in a previous PCEP session. If a
PCC's LSP State Database survived the restart, the PCC will include PCC's LSP State Database survived the restart, 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 Report 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 PCC MUST perform State Synchronization. Otherwise, the PCC MUST perform State
Synchronization. If the PCC attempts to skip State Synchronization Synchronization. If the PCC attempts to skip State Synchronization
(i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC), (i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC),
the PCE MUST send back a PCError with Error-type 20 Error-value 2 the PCE MUST send back a PCError with Error-type 20 Error-value 2
'LSP Database version mismatch', and close the PCEP session. 'LSP Database version mismatch', and close the PCEP session.
If state synchronization is required, then after the Initialization If state synchronization is required, then after the Initialization
phase has completed, the PCE MUST mark any LSPs in the LSP database 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 that were previously reported by the PCC as stale. When the PCC
reports an LSP during state synchronization, if the LSP already reports an LSP during state synchronization, if the LSP already
exists in the LSP database, the PCE MUST update the LSP database and exists in the LSP database, the PCE MUST update the LSP database and
clear the stale marker from the LSP. When it has finished state clear the stale marker from the LSP. When it has finished state
synchronization, the PCC MUST immediately send a PCRpt message synchronization, the PCC MUST immediately send a PCRpt message
containing a state-report with an LSP object containing an PLSP-ID of containing a state report with an LSP object containing an PLSP-ID of
0 and with the SYNC flag set to 0 (see Section 5.4). This state- 0 and with the SYNC flag set to 0 (see Section 5.4). This state
report indicates to the PCE that state synchronization has completed. report indicates to the PCE that state synchronization has completed.
On receiving this state-report, the PCE MUST purge any LSPs from the On receiving this state report, the PCE MUST purge any LSPs from the
LSP database that are still marked as stale. LSP database that are still marked as stale.
Note that a PCE MAY force State Synchronization by not including the Note that a PCE 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 25, line 22 skipping to change at page 25, line 22
| \/ IDB=0 | | \/ IDB=0 |
| /\ | | /\ |
| / `-------->| (OK to skip sync) | / `-------->| (OK to skip sync)
(Skip sync) |<--------` | (Skip sync) |<--------` |
| . | | . |
| . | | . |
| . | | . |
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Report) | | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Update) | | LSP State Report)
|------PCRpt,SYNC=0----->| |------PCRpt,SYNC=0----->|
| | | |
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
skipping to change at page 31, line 30 skipping to change at page 31, line 30
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 that indicating that the LSP's status is 'Pending'.If the PCC decides that
the LSP parameters proposed in the PCUpd message are unacceptable, it the LSP parameters proposed in the PCUpd message are unacceptable, it
MAY revoke the delegation. Error reporting for this condition will MAY revoke the delegation. Error reporting for this condition will
be defined in a future version of this draft. 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 Reports to only reflect the most up
to date state, as discussed in the previous section. to date state, as discussed in the previous section.
A PCC sends each LSP State Report to each stateful PCE that is A PCC sends each LSP State Report to each stateful PCE that is
connected to the PCC. connected to the PCC.
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. Should the PCC decide it wants to issue a Path delegated LSP. Should the PCC decide it wants to issue a Path
Computation Request on a delegated LSP, it MUST perform Delegation Computation Request on a delegated LSP, it MUST perform Delegation
Revocation procedure first. Revocation procedure first.
skipping to change at page 33, line 42 skipping to change at page 33, line 42
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).
A PCC only acts on an LSP Update Request if permitted by the local A PCC only acts on an LSP Update Request if permitted by the local
policy configured by the network manager. Each LSP Update Request policy configured by the network manager. Each LSP Update Request
that the PCC acts on results in an LSP setup operation. An LSP that the PCC acts on results in an LSP setup operation. An LSP
Update Request MUST contain all LSP parameters that a PCC wishes to Update Request MUST contain all LSP parameters that a PCE wishes to
set for the LSP. A PCC MAY set missing parameters from locally set for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Update Request is configured defaults. If the LSP specified in the Update Request is
already up, it will be re-signaled. already up, it will be re-signaled.
The PCC SHOULD use the make-before-break procedures described in The PCC SHOULD use the make-before-break procedures described in
[RFC3209] in the re-signaling operation. When traffic switchover to [RFC3209] in the re-signaling operation. When traffic switchover to
the updated path and teardown of the old path are under the control 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 of PCC, no extensions are necessary. The PCC MUST send a PCrpt
message with the new path attributes to the PCE only after traffic message with the new path attributes to the PCE only after traffic
has been switched over. In some situations, it may be desirable for has been switched over. In some situations, it may be desirable for
skipping to change at page 35, line 11 skipping to change at page 35, line 11
7. Object Formats 7. Object Formats
The PCEP objects defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document MUST always be set to 0 on PCEP objects defined in this document MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST be ignored on receipt since these flags are
exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines a new optional TLV for the OPEN Object to This document defines two new optional TLVs for use in the OPEN
support stateful PCE capability negotiation. Object.
7.1.1. Stateful PCE Capability TLV 7.1.1. Stateful PCE Capability TLV
The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
following figure: OPEN Object for stateful PCE capability negotiation. Its format is
shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|U| | Flags |S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: STATEFUL-PCE-CAPABILITY TLV format Figure 14: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets. The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag
indicates that the PCC allows modification of LSP parameters; if indicates that the PCC allows modification of LSP parameters; if
set to 1 by a PCE, the U Flag indicates that the PCE wishes to set to 1 by a PCE, the U Flag indicates that the PCE is capable of
update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be
advertised by both a PCC and a PCE for PCUpd messages to be advertised by both a PCC and a PCE for PCUpd messages to be
allowed on a PCEP session. allowed on a PCEP session.
S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers,
the PCC will include the LSP-DB-VERSION TLV in each LSP Object. the PCC will include the LSP-DB-VERSION TLV in each LSP Object.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
7.1.2. LSP State Database Version TLV 7.1.2. LSP State Database Version TLV
skipping to change at page 38, line 43 skipping to change at page 38, line 43
LSP has been removed from the PCC. Upon receiving an LSP State LSP has been removed from the PCC. Upon receiving an LSP State
Report with the R Flag set to 1, the PCE SHOULD remove all state Report with the R Flag set to 1, the PCE SHOULD remove all state
related to the LSP from its database. related to the LSP from its database.
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
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. LSP Identifiers TLVs
Whenever the value of an LSP identifier changes, a PCC MUST send out
an LSP State Report, where the LSP Object carries the LSP Identifiers
TLV that contains the new value. The LSP Identifiers TLV MUST also
be included in the LSP object during state synchronization. There
are two LSP Identifiers TLVs, one for IPv4 and one for IPv6.
The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: IPV4-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 12 octets.
The value contains the following fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa).
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Session Object.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following
figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: IPV6-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 36 octets.
The value contains the following fields:
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address,
as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6
Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
Object.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa).
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object.
7.2.2. Symbolic Path Name TLV
Each LSP (path) MUST have a symbolic name that is unique in the PCC. Each LSP (path) MUST have a symbolic name that is unique in the PCC.
This symbolic path name MUST remain constant throughout a path's This symbolic path name MUST remain constant throughout a path's
lifetime, which may span across multiple consecutive PCEP sessions lifetime, which may span across multiple consecutive PCEP sessions
and/or PCC restarts. The symbolic path name MAY be specified by an and/or PCC restarts. The symbolic path name MAY be specified by an
operator in a PCC's configuration. If the operator does not specify operator in a PCC's configuration. If the operator does not specify
a unique symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
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.
skipping to change at page 39, line 26 skipping to change at page 41, line 41
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SYMBOLIC-PATH-NAME TLV format Figure 20: SYMBOLIC-PATH-NAME TLV format
The type of the TLV is [TBD] and it has a variable length, which MUST The type of the TLV is [TBD] and it has a variable length, which MUST
be greater than 0. be greater than 0.
7.2.2. RSVP ERROR_SPEC TLVs 7.2.3. LSP Error Code TLV
If an LSP Update Request failed, an LSP State Report MUST be sent to
all connected stateful PCEs. LSP State Report MUST contain the LSP
Error Code TLV, indicating the cause of the failure.
The format of the LSP-ERROR-CODE TLV is shown in the following
figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LSP-ERROR-CODE TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value contains the error code that indicates the cause of the
failure. Error codes will be defined in a later revision of this
document.
7.2.4. RSVP ERROR_SPEC TLVs
If the set up of an LSP failed at a downstream node which returned an If the set up of an LSP failed at a downstream node which returned an
ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP
State Report. Depending on whether RSVP signaling was performed over State Report. Depending on whether RSVP signaling was performed over
IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or
an IPV6-ERROR_SPEC TLV. an IPV6-ERROR_SPEC TLV.
The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=8 | | Type=[TBD] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ IPv4 ERROR_SPEC object (rfc2205) + + IPv4 ERROR_SPEC object (rfc2205) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: IPV4-RSVP-ERROR-SPEC TLV format
Figure 22: IPV4-RSVP-ERROR-SPEC 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 the RSVP IPv4 ERROR_SPEC object defined in The value contains the RSVP IPv4 ERROR_SPEC object defined in
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined
in [RFC2205], [RFC3209] and [RFC3473].. in [RFC2205], [RFC3209] and [RFC3473]..
The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following
figure: figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=20 | | Type=[TBD] | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IPv6 ERROR_SPEC object (rfc2205) // // IPv6 ERROR_SPEC object (rfc2205) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: IPV6-RSVP-ERROR-SPEC TLV format Figure 23: IPV6-RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a fixed length of 20 octets. The type of the TLV is [TBD] and it has a fixed length of 20 octets.
The value contains the RSVP IPv6 ERROR_SPEC object defined in The value contains the RSVP IPv6 ERROR_SPEC object defined in
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined
in [RFC2205], [RFC3209] and [RFC3473]. in [RFC2205], [RFC3209] and [RFC3473].
7.2.3. LSP State Database Version TLV 7.2.5. LSP State Database Version TLV
The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP
object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which
covers state synchronization avoidance. The format of the TLV is covers state synchronization avoidance. The format of the TLV is
described in Section 7.1.2, where the details of its use in the OPEN described in Section 7.1.2, where the details of its use in the OPEN
message are listed. message are listed.
If State Synchronization Avoidance has been enabled on a PCEP session If State Synchronization Avoidance has been enabled on a PCEP session
(as described in Section 5.4.1) , a PCC MUST include the LSP-DB- (as described in Section 5.4.1) , a PCC MUST include the LSP-DB-
VERSION TLV in each LSP Object sent out on the session. If the TLV VERSION TLV in each LSP Object sent out on the session. If the TLV
skipping to change at page 41, line 5 skipping to change at page 43, line 44
(mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV
missing) and close the session. If State Synchronization Avoidance missing) and close the session. If State Synchronization Avoidance
has not been enabled on a PCEP session, the PCC SHOULD NOT include has not been enabled on a PCEP session, the PCC SHOULD NOT include
the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it
were it to receive one. were it to receive one.
Since a PCE does not send LSP updates to a PCC, a PCC should never Since a PCE does not send LSP updates to a PCC, a PCC should never
encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were
it to receive one from a PCE. it to receive one from a PCE.
7.2.4. Delegation Parameters TLVs 7.2.6. Delegation Parameters TLVs
Multiple delegation parameters, such as sub-delegation permissions, Multiple delegation parameters, such as sub-delegation permissions,
authentication parameters, etc. need to be communicated from a PCC to authentication parameters, etc. need to be communicated from a PCC to
a PCE during the delegation operation. Delegation parameters will be a PCE during the delegation operation. Delegation parameters will be
carried in multiple delegation parameter TLVs, which will be defined carried in multiple delegation parameter TLVs, which will be defined
in future revisions of this document. in future revisions of this document.
7.3. Optional TLVs for the LSPA Object
TLVs that may be included in the LSPA Object are described in the
following sections and in separate technology-specific documents.
7.3.1. Tunnel ID TLV
The Tunnel ID TLV MAY be included in the LSPA object.
The format of the TUNNEL TLV is shown in the following figure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Tunnel-ID TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value contains a single field:
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel
IDs.
7.3.2. Symbolic Path Name TLV
See section Section 7.2.2.
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:
skipping to change at page 43, line 8 skipping to change at page 46, line 32
State Synchronization Avoidance State Synchronization Avoidance
enabled. enabled.
8.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs: This document defines the following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
16 STATEFUL-PCE-CAPABILITY This document 16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE 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 24 PREDUNDANCY-GROUP-ID This document
25 TUNNEL-ID This document
8.6. STATEFUL-PCE-CAPABILITY TLV 8.6. STATEFUL-PCE-CAPABILITY TLV
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
values are to be assigned by Standards Action [RFC5226]. Each bit values are to be assigned by Standards Action [RFC5226]. Each bit
should be tracked with the following qualities: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
skipping to change at page 47, line 36 skipping to change at page 51, line 18
11. Acknowledgements 11. Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria and Ramon We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar
Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej
Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath and Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath,
Calvin Ying for helpful comments and discussions. Calvin Ying and Xian Zhang for helpful comments and discussions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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
skipping to change at page 48, line 45 skipping to change at page 52, line 26
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-07 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in
progress), October 2012. progress), October 2012.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S. and J. Medved, "IGP Extensions for Stateful Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
PCE Discovery", draft-sivabalan-pce-disco-stateful-00 for Stateful PCE Discovery",
(work in progress), January 2013. draft-sivabalan-pce-disco-stateful-01 (work in progress),
April 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. 36 change blocks. 
86 lines changed or deleted 250 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/