draft-ietf-pce-stateful-pce-01.txt   draft-ietf-pce-stateful-pce-02.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: January 16, 2013 Cisco Systems, Inc. Expires: April 18, 2013 Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
July 15, 2012 R. Varga
Pantheon Technologies SRO
October 15, 2012
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-01 draft-ietf-pce-stateful-pce-02
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path synchronization or PCE control of timing and sequence of path
computations within and across PCEP sessions. This document computations within and across PCEP sessions. This document
describes a set of extensions to PCEP to enable this functionality, describes a set of extensions to PCEP to enable stateful control of
providing stateful control of Multiprotocol Label Switching (MPLS) MPLS-TE and GMPLS tunnels via PCEP.
Traffic Engineering Label Switched Paths (TE LSP) via PCEP.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on April 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . 6 3. Motivation and Objectives for Stateful PCE in an MPLS TE
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16
5. Architectural Overview of Protocol Extensions . . . . . . . . 16 5. Architectural Overview of Protocol Extensions . . . . . . . . 16
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 17
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 20 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 24 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 24
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 25 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 25
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 25 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 25
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 26 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 26
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 27 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 27
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 27 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 27
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 28 Request/Response . . . . . . . . . . . . . . . . . . . 28
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 29 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 29
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 30 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 30
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 31 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 31
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 32 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 32
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 33
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 35 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 33
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 36 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 34
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 36 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 35
7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 37 7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 35
7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 38 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 36
7.2.1. The LSP Symbolic Name TLV . . . . . . . . . . . . . . 39 7.2.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 38
7.2.2. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 40 7.2.2. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 38
7.2.3. LSP Update Error Code TLV . . . . . . . . . . . . . . 42 7.2.3. LSP State Database Version TLV . . . . . . . . . . . . 39
7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 42 7.2.4. Delegation Parameters TLVs . . . . . . . . . . . . . . 40
7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 44 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 44 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 45 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 42
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 45 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 46 9. Manageability Considerations . . . . . . . . . . . . . . . . . 42
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46 9.1. Control Function and Policy . . . . . . . . . . . . . . . 42
8.7. LSP-UPDATE-ERROR-CODE TLV . . . . . . . . . . . . . . . . 47 9.2. Information and Data Models . . . . . . . . . . . . . . . 43
9. Manageability Considerations . . . . . . . . . . . . . . . . . 47 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44
9.1. Control Function and Policy . . . . . . . . . . . . . . . 47 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44
9.2. Information and Data Models . . . . . . . . . . . . . . . 48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 49 Components . . . . . . . . . . . . . . . . . . . . . . . . 44
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 45
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 45
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 46
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 51 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 46
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 12.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP. [RFC5440] describes the Path Computation Element Protocol (PCEP.
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between PCE and PCE, (PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for enabling computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP) characteristics Traffic Engineering Label Switched Path (TE LSP) characteristics.
Extensions for support of GMPLS in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions]
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
stateful control of TE LSPs between and across PCEP sessions in stateful control of tunnels between and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect LSP compliance with [RFC4657]. It includes mechanisms to effect tunnel
state synchronization between PCCs and PCEs, delegation of control of state synchronization between PCCs and PCEs, delegation of control
LSPs to PCEs, and PCE control of timing and sequence of path over tunnels to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer. PCE, PCEP Peer.
This document uses the following terms defined in [RFC4090]: MPLS TE This document uses the following terms defined in [RFC4090]: MPLS TE
Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.
The following terms are defined in this document: The following terms are defined in this document:
Passive Stateful PCE: uses LSP state information learned from PCCs Passive Stateful PCE: uses LSP state information learned from PCCs
to optimize path computations. It does not actively update LSP to optimize path computations. It does not actively update tunnel
state. A PCC maintains synchronization with the PCE. state. A PCC maintains synchronization with the PCE.
Active Stateful PCE: uses LSP state information learned from PCCs to Active Stateful PCE: uses tunnel state information learned from PCCs
optimize path computations. Additionally, it actively updates LSP to optimize path computations. Additionally, it actively updates
parameters in those PCCs that delegated control over their LSPs to tunnel parameters in those PCCs that delegated control over their
the PCE. tunnels to the PCE.
Delegation: An operation to grant a PCE temporary rights to modify a Delegation: An operation to grant a PCE temporary rights to modify a
subset of LSPs parameters on one or more PCC's LSPs. LSPs are subset of tunnel parameters on one or more PCC's tunnels. Tunnels
delegated from a PCC to a PCE. are delegated from a PCC to a PCE.
Delegation Timeout Interval: when a PCEP session is terminated, a Delegation Timeout Interval: when a PCEP session is terminated, a
PCC waits for this time period before revoking LSP delegation to a PCC waits for this time period before revoking tunnel delegation
PCE. to a PCE.
LSP State Report: an operation to send LSP state (Operational / LSP State Report: an operation to send LSP state (Operational /
Admin Status, LSP attributes configured and set by a PCE, etc.) Admin Status, LSP attributes configured and set by a PCE, etc.)
from a PCC to a PCE. from a PCC to a PCE.
LSP Update Request: an operation where a PCE requests a PCC to LSP Update Request: an operation where a PCE requests a PCC to
update one or more attributes of an LSP and to re-signal the LSP update one or more attributes of an LSP and to re-signal the LSP
with updated attributes. with updated attributes.
LSP Priority: a specific pair of MPLS setup and hold priority LSP Priority: a specific pair of MPLS setup and hold priority
skipping to change at page 6, line 46 skipping to change at page 7, line 5
to exists in the UP state, also generates a revocation message to to exists in the UP state, also generates a revocation message to
the PCE. the PCE.
Within this document, when describing PCE-PCE communications, the Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives 3. Motivation and Objectives for Stateful PCE in an MPLS TE deployment
3.1. Motivation 3.1. Motivation
In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful
PCE. The scenarios are specific to MPLS TE deployments, but the
extensions described in this document apply to GMPLS tunnels as well.
3.1.1. Background 3.1.1. Background
Traffic engineering has been a goal of the MPLS architecture since Traffic engineering has been a goal of the MPLS architecture since
its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic
engineering system provided by [RFC3630], [RFC5305], and [RFC3209] engineering system provided by [RFC3630], [RFC5305], and [RFC3209]
information about network resources utilization is only available as information about network resources utilization is only available as
total reserved capacity by traffic class on a per interface basis; total reserved capacity by traffic class on a per interface basis;
individual LSP state is available only locally on each LER for it's individual LSP state is available only locally on each LER for it's
own LSPs. In most cases, this makes good sense, as distribution and own LSPs. In most cases, this makes good sense, as distribution and
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
skipping to change at page 18, line 24 skipping to change at page 18, line 39
parameter updates. parameter updates.
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the Stateful PCE Capability TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP protocol extensions for stateful PCEs MUST not be used if The PCEP protocol extensions for stateful PCEs MUST NOT be used if
one or both PCEP Speakers have not included the Stateful PCE one or both PCEP Speakers have not included the Stateful PCE
Capability TLV in their respective OPEN message, otherwise a PCErr Capability TLV in their respective OPEN message, otherwise a PCErr
with code "Stateful PCE capability not negotiated" (see Section 8.4) with code "Stateful PCE capability not negotiated" (see Section 8.4)
will be generated and the PCEP session will be terminated. will be generated and the PCEP session will be terminated.
LSP delegation and LSP update operations defined in this document MAY LSP delegation and LSP update operations defined in this document MAY
only be used if both PCEP Speakers set the LSP-UPDATE Flag in the only be used if both PCEP Speakers set the LSP-UPDATE Flag in the
"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)',
otherwise a PCErr with code "Delegation not negotiated" (see otherwise a PCErr with code "Delegation not negotiated" (see
Section 8.4) will be generated. Note that even if the update Section 8.4) will be generated. Note that even if the update
skipping to change at page 21, line 12 skipping to change at page 21, line 36
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. 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, which is incremented each time a change is made to the PCC's
local LSP State Database. The LSP State Database version is an local LSP State Database. The LSP State Database version is an
unsigned 64-bit value that MUST be incremented by 1 for each unsigned 64-bit value that MUST be incremented by 1 for each
successive change in the LSP state database. The LSP State Database successive change in the LSP state database. The LSP State Database
version MUST start at 1 and may wrap around. Values 0 and version MUST start at 1 and may wrap around. Values 0 and
0xFFFFFFFFFFFFFFF are reserved. 0xFFFFFFFFFFFFFFFF are reserved.
State Synchronization Avoidance is negotiated on a PCEP session State Synchronization Avoidance is negotiated on a PCEP session
during session startup. To make sure that a PCEP peer can recognize during session startup. To make sure that a PCEP peer can recognize
a previously connected peer even if its IP address changed, each PCEP a previously connected peer even if its IP address changed, each PCEP
peer includes the NODE_IDENTIFIER TLV in the OPEN message. peer includes the NODE_IDENTIFIER 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 Update from the PCC in a previous PCEP session. If a an LSP State Report from the PCC in a previous PCEP session. If a
PCC's LSP State Database survived the restart, the PCC will include PCC's LSP State Database survived the restart, the PCC will include
the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
the last LSP State Database version sent on an LSP State Update from the last LSP State Database version sent on an LSP State Update from
the PCC in the previous PCEP session. If a PCEP Speaker's LSP State the PCC in the previous PCEP session. If a PCEP Speaker's LSP State
Database did not survive the restart of a PCEP session, the PCEP Database did not survive the restart of a PCEP session, the PCEP
Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object.
If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN
Object and the TLV values match, the PCC MAY skip State Object and the TLV values match, the PCC MAY skip State
Synchronization. Otherwise, the PCE MUST purge any remaining LSP Synchronization. Otherwise, the PCE MUST purge any remaining LSP
skipping to change at page 22, line 21 skipping to change at page 22, line 41
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
| /\ | | /\ |
| / `-------->| (OK to skip sync) | / `-------->| (OK to skip sync)
(Skip sync) |<--------` | (Skip sync) |<--------` |
| . | | . |
| . | | . |
| . | | . |
| | | |
|--PCRpt,DBv=43,SYNC=0-->| (Regular |--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Update) | | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular |--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Update) | | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->| |--PCRpt,DBv=45,SYNC=0-->|
| | | |
Figure 6: State Synchronization skipped Figure 6: State Synchronization skipped
Figure 7 shows an example sequence where State Synchronization is Figure 7 shows an example sequence where State Synchronization is
performed due to LSP State Database version mismatch during the PCEP performed due to LSP State Database version mismatch during the PCEP
session setup. Note that the same State Synchronization sequence session setup. Note that the same State Synchronization sequence
would happen if either the PCE or the PCE would not include the LSP- would happen if either the PCE or the PCE would not include the LSP-
DB-VERSION TLV in their respective Open messages. DB-VERSION TLV in their respective Open messages.
skipping to change at page 23, line 26 skipping to change at page 23, line 28
| | | |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start) |--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . | | . |
| . | | . |
| . | | . |
|--PCRpt,DBv=46,SYNC=1-->| (Sync done) |--PCRpt,DBv=46,SYNC=1-->| (Sync done)
| . | | . |
| . | | . |
| . | | . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular |--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Update) | | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular |--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Update) | | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->| |--PCRpt,DBv=49,SYNC=0-->|
| | | |
Figure 7: State Synchronization performed Figure 7: State Synchronization performed
Figure 8 shows an example sequence where State Synchronization is Figure 8 shows an example sequence where State Synchronization is
skipped, but because one or both PCEP Speakers set the INCLUDE-DB- skipped, but because one or both PCEP Speakers set the INCLUDE-DB-
VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the
PCE. If the current PCEP session restarts, the PCEP Speakers will PCE. If the current PCEP session restarts, the PCEP Speakers will
have to perform State Synchronization, since the PCE will not know have to perform State Synchronization, since the PCE will not know
skipping to change at page 24, line 20 skipping to change at page 24, line 20
| DBv=42 \ ,---Open--| | DBv=42 \ ,---Open--|
| IDB=0 \ / DBv=42 | | IDB=0 \ / DBv=42 |
| \/ 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 Update) | | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Update) | | LSP State Update)
|------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
skipping to change at page 30, line 47 skipping to change at page 30, line 47
With a stateless PCE or a passive stateful PCE, LSP protection and With a stateless PCE or a passive stateful PCE, LSP protection and
restoration settings may be operator-configured locally at a PCC. A restoration settings may be operator-configured locally at a PCC. A
PCE may be merely asked to compute the protected (primary) and backup PCE may be merely asked to compute the protected (primary) and backup
(secondary) paths for the LSP. (secondary) paths for the LSP.
An active stateful PCE controls the LSPs that are delegated to it, An active stateful PCE controls the LSPs that are delegated to it,
and must therefore be able to set via PCEP the desired protection / and must therefore be able to set via PCEP the desired protection /
restoration mechanism for each delegated LSP. PCEP extensions for restoration mechanism for each delegated LSP. PCEP extensions for
stateful PCEs SHOULD support, at a minimum, the following protection stateful PCEs SHOULD support, at a minimum, the following protection
mechanisms: mechanisms for MPLS-TE LSPs:
o MPLS TE Global Default Restoration o MPLS TE Global Default Restoration
o MPLS TE Global Path Protection o MPLS TE Global Path Protection
o FRR One-to-One Backup o FRR One-to-One Backup
o FRR Facility Backup - link protection, node protection, or both o FRR Facility Backup - link protection, node protection, or both
The necessary extensions for support of protection are described in
technology-specific documents.
5.8. Transport 5.8. Transport
A Permanent PCEP session MUST be established between a stateful PCEs A Permanent PCEP session MUST be established between a stateful PCE
and the PCC. and the PCC.
State cleanup after session termination, as well as session setup State cleanup after session termination, as well as session setup
failures will be described in a later version of this document. failures will be described in a later version of this document.
6. PCEP Messages 6. PCEP Messages
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory be either mandatory or optional. An object is said to be mandatory
skipping to change at page 32, line 18 skipping to change at page 32, line 18
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= <LSP> <state-report> ::= <LSP>
[<path-list>] [<path-list>]
Where: Where:
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
<path>::=<ERO><attribute-list>
Where: Where:
<path> is defined in technology-specific documents per LSP type.
<attribute-list> ::= [<LSPA>]
[<BANDWIDTH>]
[<RRO>]
[<metric-list>]
<metric-list> ::= <METRIC>[<metric-list>]
The LSP object (see Section 7.2) is mandatory, and it MUST be The LSP object (see Section 7.2) is mandatory, and it MUST be
included in each LSP State Report on the PCRpt message. If the LSP included in each LSP State Report on the PCRpt message. If the LSP
object is missing, the receiving PCE MUST send a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP
object missing). object missing).
The LSP State Report MAY contain a path descriptor for the primary The path descriptor is described in separate technology-specific
path and one or more path descriptors for backup paths. A path documents according to the LSP type.
descriptor MUST contain an ERO object as it was specified by a PCE or
an operator. A path descriptor MUST contain the RRO object if a
primary or secondary LSP is set up along the path in the network. A
path descriptor MAY contain the LSPA, BANDWIDTH, and METRIC objects.
The ERO,LSPA, BANDWIDTH, METRIC, and RRO objects are defined
in[RFC5440].
6.2. The PCUpd Message 6.2. The PCUpd Message
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCRpt message is set to [TBD]. the PCRpt message is set to [TBD].
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
skipping to change at page 33, line 17 skipping to change at page 32, line 52
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <LSP> <update-request> ::= <LSP>
[<path-list>] [<path-list>]
Where: Where:
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
Where:
<path>::=<ERO><attribute-list> <path> is defined in technology-specific documents per LSP type
Where:
<attribute-list> ::= [<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
<metric-list> ::= <METRIC>[<metric-list>]
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).
The LSP Update Request MUST contain a path descriptor for the primary
path, and MAY contain one or more path descriptors for backup paths.
A path descriptor MUST contain an ERO object. A path descriptor MAY
further contain the BANDWIDTH, IRO, and METRIC objects. The ERO,
LSPA, BANDWIDTH, METRIC, and IRO objects are defined in [RFC5440].
Each LSP Update Request results in a separate LSP setup operation at Each LSP Update Request results in a separate LSP setup operation at
a PCC. An LSP Update Request MUST contain all LSP parameters that a a PCC. An LSP Update Request MUST contain all LSP parameters that a
PCC wishes to set for the LSP. A PCC MAY set missing parameters from PCC wishes to set for the LSP. A PCC MAY set missing parameters from
locally configured defaults. If the LSP specified the Update Request locally configured defaults. If the LSP specified the Update Request
is already up, it will be re-signaled. The PCC will use make-before- is already up, it will be re-signaled. The PCC will use make-before-
break whenever possible in the re-signaling operation. break whenever possible in the re-signaling operation.
A PCC MUST respond with an LSP State Report to each LSP Update A PCC MUST respond with an LSP State Report to each LSP Update
Request to indicate the resulting state of the LSP in the network. A Request to indicate the resulting state of the LSP in the network. A
PCC MAY respond with multiple LSP State Reports to report LSP setup PCC MAY respond with multiple LSP State Reports to report LSP setup
skipping to change at page 34, line 22 skipping to change at page 33, line 44
Note also that it's up to the PCE to handle inter-LSP dependencies; Note also that it's up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP set-ups is required, the PCE has to for example, if ordering of LSP set-ups is required, the PCE has to
wait for an LSP State Report for a previous LSP before triggering the wait for an LSP State Report for a previous LSP before triggering the
LSP setup of a next LSP. LSP setup of a next LSP.
6.3. The PCReq Message 6.3. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see A PCC MAY include the LSP object in the PCReq message (see
Section 7.2) if stateful PCE capability has been negotiated on a PCEP Section 7.2) if stateful PCE capability has been negotiated on a PCEP
session between the PCC and a PCE. The definition of the PCReq session between the PCC and a PCE. The extensions to the PCReq
message (see [RFC5440], Section 6.4) is then extended as follows: message are described in technology-specific documents for MPLS and
GMPLS.
<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>]
Where:
<metric-list>::=<METRIC>[<metric-list>]
6.4. The PCRep Message 6.4. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see A PCE MAY include the LSP object in the PCRep message (see
(Section 7.2) if stateful PCE capability has been negotiated on a (Section 7.2) if stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was PCEP session between the PCC and the PCE and the LSP object was
included in the corresponding PCReq message from the PCC. The included in the corresponding PCReq message from the PCC. The
definition of the PCRep message (see [RFC5440], Section 6.5) is then extensions to the PCRep message are described in technology-specific
extended as follows documents for MPLS and GMPLS.
<PCRep Message> ::= <Common Header>
<response-list>
Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>] <--- New Object
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
Where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-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 36, line 22 skipping to change at page 34, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (16 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 wishes to
update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be update 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.
skipping to change at page 38, line 38 skipping to change at page 37, line 8
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: The LSP Object format Figure 17: The LSP Object format
The LSP object body has a variable length and may contain additional The LSP object body has a variable length and may contain additional
TLVs. TLVs.
LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique
LSP-ID for each LSP that is constant for the life time of a PCEP LSP-ID for each LSP that is constant for the life time of a PCEP
session. The mapping of the LSP Symbolic Name to LSP-ID is session. The mapping of the Symbolic Path Name to LSP-ID is
communicated to the PCE by sending a PCRpt message containing the communicated to the PCE by sending a PCRpt message containing the
'LSP Symbolic Name' TLV. All subsequent PCEP messages then address 'Symbolic Path Name' TLV. All subsequent PCEP messages then address
the LSP by the LSP-ID. the LSP by the LSP-ID.
Flags (12 bits): Flags (12 bits):
D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1
indicates that the PCC is delegating the LSP to the PCE. On a indicates that the PCC is delegating the LSP to the PCE. On a
PCUpd message, the D flag set to 1 indicates that the PCE is PCUpd message, the D flag set to 1 indicates that the PCE is
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP Delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation - the first PCRpt with the D flag
skipping to change at page 39, line 25 skipping to change at page 37, line 44
is not attempting to set it up. On PCUpd messages the flag is not attempting to set it up. On PCUpd messages the flag
indicates the desired status for the LSP. Value of '1' means that indicates the desired status for the LSP. Value of '1' means that
the desired LSP state is operational, value of '0' means that the the desired LSP state is operational, value of '0' means that the
target LSP should be non-operational. Setting the LSP status from target LSP should be non-operational. Setting the LSP status from
the PCE SHALL NOT override the operator: if a pce-controlled LSP the PCE SHALL NOT override the operator: if a pce-controlled LSP
has been configured to be non-operational, setting the LSP's has been configured to be non-operational, setting the LSP's
status to '1' from an PCE will not make it operational. status to '1' from an PCE will not make it operational.
R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the
LSP has been removed from the PCC. Upon receiving an LSP State LSP has been removed from the PCC. Upon receiving an LSP State
Update 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 are currently defined for the LSP Object are described in TLVs that may be included in the LSP Object are described in the
the following sections. following sections and in separate technology-specific documents.
7.2.1. The LSP Symbolic Name TLV 7.2.1. Symbolic Path Name TLV
Each LSP MUST have a symbolic name that is unique in the PCC. The Each LSP (path) MUST have a symbolic name that is unique in the PCC.
LSP Symbolic Name MUST remain constant throughout an LSP's lifetime, This symbolic path name MUST remain constant throughout a path's
which may span across multiple consecutive PCEP sessions and/or PCC lifetime, which may span across multiple consecutive PCEP sessions
restarts. The LSP Symbolic Name MAY be specified by an operator in a and/or PCC restarts. The symbolic path name MAY be specified by an
PCC's CLI configuration. If the operator does not specify a Symbolic operator in a PCC's CLI configuration. If the operator does not
Name for an LSP, the PCC MUST auto-generate one. specify a symbolic name for a path, the PCC MUST auto-generate one.
The LSP-SYMBOLIC-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. LSP Synchronization, or when a new LSP is configured at the PCC. The
State Report MAY be included in subsequent LSP State Reports for the symbolic path name MAY be included in subsequent LSP State Reports
LSP. for the LSP.
The format of the LSP-SYMBOLIC-NAME TLV is shown in the following The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
and the LSPA Object.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic LSP Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: LSP-SYMBOLIC-NAME TLV format Figure 18: 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. LSP Identifiers TLVs 7.2.2. RSVP ERROR_SPEC 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 19: 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 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=36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: 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.3. LSP Update 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
Update Error Code TLV, indicating the cause of the failure.
The format of the LSP-UPDATE-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-UPDATE-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 LSP
setup 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 22: IPV4-RSVP-ERROR-SPEC TLV format Figure 19: 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] and [RFC3209]. 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 23: IPV6-RSVP-ERROR-SPEC TLV format Figure 20: 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] and [RFC3209]. in [RFC2205], [RFC3209] and [RFC3473].
7.2.5. LSP State Database Version TLV 7.2.3. 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 44, line 22 skipping to change at page 40, line 15
(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.6. Delegation Parameters TLVs 7.2.4. 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.
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
skipping to change at page 45, line 41 skipping to change at page 41, line 35
31 Delegate This document 31 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 for a path in an LSP
Update Request where TE-LSP setup is
requested
Error-value=10: BANDWIDTH Object missing for a path in
an LSP Update Request where TE-LSP
setup is requested
Error-value=11: LSPA Object missing for a path in an
LSP Update Request where TE-LSP setup
is requested
Error-value=12: LSP-DB-VERSION TLV missing Error-value=12: LSP-DB-VERSION TLV missing
19 Invalid Operation 19 Invalid Operation
Error-value=1: Attempted LSP Update Request for a non- Error-value=1: Attempted LSP Update Request for a non-
delegated LSP. The PCEP-ERROR Object delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that is followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: Attempted LSP Update Request if active Error-value=2: Attempted LSP Update Request if active
stateful PCE capability was not stateful PCE capability was not
negotiated active PCE. negotiated active PCE.
20 LSP State synchronization error. 20 LSP State synchronization error.
skipping to change at page 46, line 31 skipping to change at page 42, line 16
Error-value=3: The LSP-DB-VERSION TLV Missing when Error-value=3: The LSP-DB-VERSION TLV Missing when
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 LSP-SYMBOLIC-NAME This document 17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-UPDATE-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
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:
skipping to change at page 47, line 10 skipping to change at page 42, line 41
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
30 INCLUDE-DB-VERSION This document 30 INCLUDE-DB-VERSION This document
31 LSP-UPDATE-CAPABILITY This document 31 LSP-UPDATE-CAPABILITY This document
8.7. LSP-UPDATE-ERROR-CODE TLV
This document requests that a registry is created to manage the Error
Codes in the LSP-UPDATE-ERROR-CODE TLV. New values are to be
assigned by Standards Action [RFC5226].
The following Error Codes are defined in this document:
Value Meaning Reference
1 LSP Setup failed outside of the node. Must This document
be followed by the RSVP-ERROR-SPEC TLV,
which indicates the failure cause.
2 LSP not operational This document
9. Manageability Considerations 9. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440] All manageability requirements and considerations listed in [RFC5440]
apply to PCEP protocol extensions defined in this document. In apply to PCEP protocol extensions defined in this document. In
addition, requirements and considerations listed in this section addition, requirements and considerations listed in this section
apply. apply.
9.1. Control Function and Policy 9.1. Control Function and Policy
In addition to configuring specific PCEP session parameters, as In addition to configuring specific PCEP session parameters, as
skipping to change at page 51, line 45 skipping to change at page 47, line 17
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
skipping to change at page 52, line 24 skipping to change at page 47, line 47
[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 2009. March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-06 (work in
progress), July 2012.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre- and throughput objectives in traffic engineering", pre-
print, 2011. print, 2011.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
skipping to change at page 53, line 42 skipping to change at page 49, line 23
Email: edc@google.com Email: edc@google.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Ina Minei Ina Minei
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: ina@juniper.net Email: ina@juniper.net
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
 End of changes. 64 change blocks. 
352 lines changed or deleted 137 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/