draft-ietf-pce-pcep-00.txt   draft-ietf-pce-pcep-01.txt 
Network Working Group JP Vasseur (Editor)
Cisco System Inc. Networking Working Group JP. Vasseur, Ed.
IETF Internet Draft JL Le Roux Internet-Draft Cisco Systems, Inc
Expires: August 28, 2006 JL. Le Roux
France Telecom France Telecom
Arthi Ayyangar A. Ayyangar
Juniper Networks Juniper Networks
Eiji Oki E. Oki
Yuichi Ikejiri
NTT NTT
Alia Atlas A. Atlas
Google, Inc Google
Andrew Dolganow A. Dolganow
Alcatel Alcatel
Proposed Status: Standard Y. Ikejiri
Expires: May 2006 November 2005 NTT Communications Corporation
K. Kumaki
KDDI Corporation
February 24, 2006
Path Computation Element (PCE) communication Protocol (PCEP) Path Computation Element (PCE) communication Protocol (PCEP) - Version 1
- Version 1 -
draft-ietf-pce-pcep-00.txt draft-ietf-pce-pcep-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 46 skipping to change at page 1, line 48
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice This Internet-Draft will expire on August 28, 2006.
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs. Such (PCC) and a Path Computation Element (PCE), or between two PCEs.
interactions include path computation requests and path computation Such interactions include path computation requests and path
replies as well as notifications of specific states related to the computation replies as well as notifications of specific states
use of a PCE in the context of MPLS and GMPLS Traffic Engineering. related to the use of a PCE in the context of MPLS and GMPLS Traffic
The PCEP protocol is designed to be flexible and extensible so as to Engineering. The PCEP protocol is designed to be flexible and
easily allow for the addition of further messages and objects, should extensible so as to easily allow for the addition of further messages
further requirements be expressed in the future. and objects, should further requirements be expressed in the future.
Conventions used in this document 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 RFC-2119. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology................................................3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction...............................................4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions................................................4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Transport protocol.........................................5 4. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 6
5. Architectural Protocol Overview (Model)....................5 5. Architectural Protocol Overview (Model) . . . . . . . . . . . 7
5.1. Problem..................................................5 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Architectural Protocol Overview..........................6 5.2. Architectural Protocol Overview . . . . . . . . . . . . . 7
5.2.1. Initialization phase...................................6 5.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 8
5.2.2. Path computation request sent by a PCC to a PCE........7 5.2.2. Path computation request sent by a PCC to a PCE . . . 9
5.2.3. Path computation reply sent by the PCE to a PCC........8 5.2.3. Path computation reply sent by the PCE to a PCC . . . 10
5.2.4. Notifications..........................................9 5.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 12
5.2.5. Termination of the PCEP Session........................10 5.2.5. Termination of the PCEP Session . . . . . . . . . . . 13
6. PCEP messages..............................................10 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Common header............................................10 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Open message.............................................11 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Keepalive message........................................13 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16
6.4. Path Computation Request (PCReq) message.................13 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17
6.5. Path Computation Reply (PCRep) message...................14 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18
6.6. Notification (PCNtf) message.............................15 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 19
6.7. Error (PCErr) message....................................15 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20
7. Object Formats.............................................16 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Common object header.....................................16 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. OPEN Object..............................................18 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21
7.3. RP Object................................................19 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. NO-PATH Object...........................................20 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5. END-POINTS Object........................................21 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24
7.6. BANDWIDTH object.........................................22 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26
7.7. DELAY Object.............................................23 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 27
7.8. ERO Object...............................................24 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28
7.9. RRO Object...............................................24 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29
7.10. LSPA Object.............................................24 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30
7.11. IRO Object..............................................26 7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 32
7.12. SVEC Object.............................................27 7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33
7.13. NOTIFICATION object.....................................28 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 33
7.14. PCEP-ERROR object.......................................31 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Independent versus synchronized path computation requests..34 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 35
9. Elements of procedure......................................35 7.12.1. Independent versus synchronized path computation
9.1. Non recognized or non support object received in a requests . . . . . . . . . . . . . . . . . . . . . . . 35
PCReq message 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 37
9.2. RP object................................................35 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 38
9.3. SVEC object..............................................36 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 39
10. Manageability Considerations..............................36 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 42
11. IANA Considerations.......................................36 7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. TCP port................................................36 8. Manageability Considerations . . . . . . . . . . . . . . . . . 45
11.2. PCEP Objects............................................36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
11.3. Notification............................................39 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 45
11.4. PCEP Error..............................................39 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 45
12. Security Considerations...................................40 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 46
12.1. PCEP Authentication and Integrity.......................40 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 47
12.2. PCEP Privacy............................................40 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48
12.3. Protection against Denial of Service attacks............41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
13. Intellectual Property Statement...........................41 10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 50
14. Acknowledgment............................................42 10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 50
15. References................................................42 10.3. Protection against Denial of Service attacks . . . . . . . 50
15.1. Normative references....................................42 10.4. Request input shaping/policing . . . . . . . . . . . . . . 51
15.2. Informative References..................................43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
16. Authors' Address..........................................44 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
Appendix A: Compliance of PCEP to the set of requirements 12.2. Informative References . . . . . . . . . . . . . . . . . . 52
specified in draft-ietf-pce-comm-protocol-gen-reqs........... 45 Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 53
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 57
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
IGP Area: OSPF Area or IS-IS level Explicit path: full explicit path from start to destination made of a
list of strict hops where a hop may be an abstract node such as an
AS.
Inter-domain TE LSP: A TE LSP whose path transits across at least IGP Area: OSPF Area or IS-IS level.
two different domains where a domain can either be an IGP area, an
Inter-domain TE LSP: A TE LSP whose path transits across at least two
different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations). Autonomous System or a sub-AS (BGP confederations).
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the
PCE). PCE).
PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a
Detour LSP.
TED: Traffic Engineering Database which contains the topology and TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means. extensions or potentially by other means.
Explicit path: full explicit path from start to destination made of a TE LSP: Traffic Engineering Label Switched Path.
list of strict hops where a hop may be an abstract node such as an
AS.
Strict/loose path: mix of strict and loose hops comprising of at Strict/loose path: mix of strict and loose hops comprising of at
least one loose hop representing the destination where a hop may be least one loose hop representing the destination where a hop may be
an abstract node such as an AS. an abstract node such as an AS.
Within this document, when PCE-PCE communications are being Within this document, when PCE-PCE communications are being
described, the requesting PCE fills the role of a PCC. This provides described, the requesting PCE fills the role of a PCC. This provides
a saving in documentation without loss of function. a saving in documentation without loss of function.
2. Introduction 2. Introduction
[PCE-ARCH] describes the motivations and architecture for a PCE-based [I-D.ietf-pce-architecture]describes the motivations and architecture
model to perform path computation for MPLS and GMPLS TE LSPs. The for a PCE-based model for the computation of MPLS and GMPLS TE LSPs.
model allows the separation of PCE from PCC, and allows cooperation The model allows the separation of PCE from PCC, and allows
between PCEs. This necessitates a communication protocol between PCC cooperation between PCEs. This necessitates a communication protocol
and PCE, and between PCEs. between PCC and PCE, and between PCEs.
[PCE-COM-GEN-REQ] states the generic requirements for such a protocol [I-D.ietf-pce-comm-protocol-gen-reqs] states the generic requirements
including a requirement that the same protocol must be used between for such a protocol including the requirement for using the same
PCC and PCE, and between PCEs. Additional application-specific protocol between PCC and PCE, and between PCEs. Additional
requirements (for scenarios such as inter-area, inter-AS, etc.) are application-specific requirements (for scenarios such as inter-area,
not included in [PCE-COM-GEN-REQ], but there is a requirement that inter-AS, etc.) are not included in [I-D.ietf-pce-comm-protocol-gen-
any solution protocol must be easily extensible to handle other reqs], but there is a requirement that any solution protocol must be
requirements as they are introduced in application-specific easily extensible to handle other requirements as they are introduced
requirements documents. in application-specific requirements documents. Examples of such
application-specific requirements are [I-D.ietf-pce-pcecp-interarea-
reqs]and [I-D.ietf-pce-inter-layer-req].
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between Path Computation Client Protocol (PCEP) for communications between Path Computation Client
(PCC) and a Path Computation Element (PCE),or between two PCEs. Such (PCC) and a Path Computation Element (PCE),or between two PCEs. Such
interactions include path computation requests and path computation interactions include path computation requests and path computation
replies as well as notifications of specific states related to the replies as well as notifications of specific states related to the
use of a PCE in the context of MPLS and GMPLS Traffic Engineering. use of a PCE in the context of MPLS and GMPLS Traffic Engineering.
The PCEP protocol is designed to be flexible and extensible so as to The PCEP protocol is designed to be flexible and extensible so as to
easily allow for the addition of further messages and objects, should easily allow for the addition of further messages and objects, should
further requirements be expressed in the future. further requirements be expressed in the future.
The compliance of PCEP to the set of requirements stated in [PCE-COM-
GEN-REQ] is covered in Appendix A.
3. Assumptions 3. Assumptions
[PCE-ARCH] describes various types of PCE: it is important to note
that no assumption is made on the nature of the PCE in this document. [I-D.ietf-pce-architecture] describes various types of PCE. PCEP
does not make any assumption and thus does not impose any constraint
on the nature of the PCE.
Moreover, it is assumed that the PCE gets the required information so Moreover, it is assumed that the PCE gets the required information so
as to perform TE LSP path computation which usually requires network as to perform TE LSP path computation which usually requires network
topology and resource information that can be gathered by routing topology and resource information that can be gathered by routing
protocols or by some other means. The retrieval of such information protocols or by some other means. The retrieval of such information
is out of the scope of this document. is out of the scope of this document.
Similarly, no assumption is made on the discovery method used by a Similarly, no assumption is made on the discovery method used by a
PCC to discover a set of PCEs (e.g. via static configuration or PCC to discover a set of PCEs (e.g. via static configuration or
dynamic discovery) and select a PCE to send its path computation dynamic discovery) and on the PCE decision selection process. For
request(s) to. For the sake of reference [PCE-DISC-REQ] defines a the sake of reference [I-D.ietf-pce-discovery-reqs] defines a list of
list of requirements for dynamic PCE discovery. requirements for dynamic PCE discovery and IGP-based solution for
such PCE discovery are specified in [I-D.ietf-pce-disco-proto-igp].
4. Transport protocol 4. Transport protocol
PCEP operates over TCP using the well-known TCP port (TBD by IANA). PCEP operates over TCP using a well-known TCP port (to be assigned by
This allows the requirements of reliable messaging and flow control IANA). This allows the requirements of reliable messaging and flow
to be met without further protocol work. control to be met without further protocol work.
An implementation may decide to keep the TCP session alive for an An implementation may decide to keep the TCP session alive for an
unlimited time (this may for instance be the case should an unlimited time (this may for instance be appropriate when path
implementation have to send new requests frequently in which case the computation requests are sent on a frequent basis so as to avoid to
TCP session will already be in place). Another motivation for leaving open a TCP session each time a path computation request is needed).
the TCP connection open would be to avoid TCP connection Conversely, in some other circumstances, it may be desirable to
establishment time. This mode is also referred to as the "Permanent systematically open and close the TCP connection for each PCEP
mode". Conversely, in some other circumstances, it may be desirable request (for instance when sending of path computation request is a
to systematically open and close the TCP connection for each PCEP rare event).
request (this may for instance be the case if sending of PCEP path
computation request is a rare event). This mode is referred to as the
"Per-request mode".
Since there are circumstances where the TCP connection state is used
to detect the PCC/PCE liveness (e.g case of a stateful PCE detecting
a PCC failure thanks to the TCP state), the desired mode MUST be
known by both the PCC and the PCE and is determined during the
initialization phase.
5. Architectural Protocol Overview (Model) 5. Architectural Protocol Overview (Model)
The aim of this section is to describe the PCEP protocol model in the The aim of this section is to describe the PCEP protocol model in the
spirit of [WP]. An architecture protocol overview (the big picture of spirit of [RFC4101]. An architecture protocol overview (the big
the protocol) is provided in this section where details of the picture of the protocol) is provided in this section. Protocol
protocol can be found in further sections. details can be found in further sections.
5.1. Problem 5.1. Problem
The PCE-based architecture used for the computation of MPLS and GMPLS The PCE-based architecture used for the computation of MPLS and GMPLS
TE LSP paths is described in [PCE-ARCH]. When the PCC and the PCE are TE LSP paths is described in [I-D.ietf-pce-architecture]. When the
not collocated, a communication protocol between the PCC and the PCE PCC and the PCE are not collocated, a communication protocol between
is required. PCEP is such a protocol designed specifically for the PCC and the PCE is required. PCEP is such a protocol designed
communications between a PCC and a PCE or between two PCEs: a PCC may specifically for communications between a PCC and a PCE or between
use PCEP to send a path computation request for one or more TE LSP(s) two PCEs: a PCC may use PCEP to send a path computation request for
to a PCE and such a PCE may reply with a set of computed path(s) if one or more TE LSP(s) to a PCE and such a PCE may reply with a set of
one or more path(s) obeying the set of constraints can be found. computed path(s) if one or more path(s) obeying the set of
constraints can be found.
5.2. Architectural Protocol Overview 5.2. Architectural Protocol Overview
PCEP operates over TCP, which allows the requirements of reliable PCEP operates over TCP, which allows the requirements of reliable
messaging and flow control to be met without further protocol work. messaging and flow control to be met without further protocol work.
Several PCEP messages are defined: Several PCEP messages are defined:
- Open and Keepalive messages are used to initiate and maintain a - Open and Keepalive messages are used to initiate and maintain a
PCEP session respectively. PCEP session respectively.
- PCReq: a message sent by a PCC to a PCE to request a path
- PCReq: a PCEP message sent by a PCC to a PCE to request a path
computation. computation.
- PCRep: a message sent by a PCE to a PCC in reply to a path
- PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
computation request. A PCRep message can either contain a set of computation request. A PCRep message can either contain a set of
computed path(s) if the request could be satisfied or a negative computed path(s) if the request could be satisfied or a negative
reply otherwise. reply otherwise.
- PCNtf: a notification message either sent by a PCC to a PCE or a
PCE to a PCC to notify of specific event. - PCNtf: a PCEP notification message either sent by a PCC to a PCE or
- PCErr: a message related to a protocol error condition. a PCE to a PCC to notify of specific event.
- PCErr: a PCEP message sent upon the occurrence of a protocol error
condition.
- Close message: a message used to close a PCEP session.
The set of available PCE(s) may be either statically configured on a The set of available PCE(s) may be either statically configured on a
PCC or dynamically discovered (the mechanism for that discovery is PCC or dynamically discovered (the mechanism for that discovery is
out of the scope of this document). A PCC may have PCEP sessions with out of the scope of this document). Note that the PCE selection
more than one PCE and similarly a PCE may have PCEP sessions with algorithm is out of the scope of this document.
multiple PCCs. A PCEP session establishment can either be triggered
by the PCC or the PCE.
5.2.1 Initialization phase A PCC may have PCEP sessions with more than one PCE and similarly a
PCE may have PCEP sessions with multiple PCCs.
The initialization phase consists of two successive steps: A PCEP session establishment is always triggered by the PCC.
5.2.1. Initialization Phase
The initialization phase consists of two successive steps (described
in a schematic form in Figure 1):
1) Establishment of a TCP connection (3-way handshake) between the 1) Establishment of a TCP connection (3-way handshake) between the
PCC and the PCE. PCC and the PCE.
2) Establishment of a PCEP session over the TCP connection 2) Establishment of a PCEP session over the TCP connection.
Once the TCP connection is established, the PCC and the PCE (also Once the TCP connection is established, the PCC and the PCE (also
referred to as "PCEP peers") initiate a PCEP session establishment referred to as "PCEP peers") initiate a PCEP session establishment
during which various session parameters are advertised. Those during which various session parameters are negotiated. These
parameters are carried within Open messages and include the keepalive parameters are carried within Open messages and include the keepalive
timer, the PCEP session mode (per-request or permanent), potential timer and, potentially, other detailed capabilities and policy rules
detailed capabilities and policy rules that specify the conditions that specify the conditions under which path computation requests may
under which path computation requests may be sent to the PCE. If the be sent to the PCE. If the PCEP session establishment phase fails
PCEP session establishment phase fails because the PCEP peers because the PCEP peers disagree on the exchanged parameters or one of
disagree on the exchanged parameters or one of the peers does not the PCEP peers does not answer after the expiration of the
answer, the transport connection is immediately closed. Successive establishment timer, the TCP connection is immediately closed.
retries are permitted but an implementation SHOULD make use of Successive retries are permitted but an implementation SHOULD make
exponential back-off. Keepalive messages are used to acknowledge Open use of exponential back-off.
messages and once the PCEP session is established Keepalive messages
Keepalive messages are used to acknowledge Open messages and once the
PCEP session has been successfully established, Keepalive messages
are exchanged between PCEP peers to ensure the liveness of the PCEP are exchanged between PCEP peers to ensure the liveness of the PCEP
session. session.
Details about the Open message and the Keepalive messages can be
found in . (Section 6.2) and Section 6.3respectively.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---- Open message --->| |---- Open message --->|
| | | |
|<--- Open message ----| |<--- Open message ----|
| | | |
| | | |
| | | |
|<--- Keepalive -------| |<--- Keepalive -------|
| | | |
|---- Keepalive ------>| |---- Keepalive ------>|
Figure 1: PCEP Initialization phase (triggered by a PCC) Figure 1: PCEP Initialization phase (triggered by a PCC)
5.2.2. Path computation request sent by a PCC to a PCE 5.2.2. Path computation request sent by a PCC to a PCE
Consider the diagram depicted in figure 2.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
2)PCE Selection | | 2)PCE Selection | |
3)Path computation |---- PCReq message--->| 3)Path computation |---- PCReq message--->|
request sent to | | request sent to | |
the selected PCE | | the selected PCE | |
Figure 2: Path computation request Figure 2: Path computation request
Once a PCC (or a PCE) has successfully established a PCEP session Once a PCC (or a PCE) has successfully established a PCEP session
with one or more PCEs, if an event is triggered that requires the with one or more PCEs, if an event is triggered that requires the
computation of a path, the PCC first selects the PCE it desires to computation of a set of path(s), the PCC first selects one of more
send a path computation request to (note that the PCE selection may PCE(s) to send the request to. Note that the PCE selection decision
be performed prior to the PCEP session establishment). Once a PCC has process may have taken place prior to the PCEP session establishment.
selected a PCE, it sends a path computation request to the PCE (PCReq
message) that contains a variety of objects that specify the set of
constraints and attributes for the path to be computed. For example
"Compute a TE LSP path with source IP address=x.y.z.t, destination IP
address=x.y.z.t, bandwidth=X Mbit/s, Priority=Y, ...".
Additionally, the PCC may desire to specify the urgency of such
request by assigning a request priority. It is worth pointing out
that each request is uniquely identified by a request-id number and
the PCC-PCE addresses pair. The process is shown in a schematic form
in figure 2.
5.2.3. Path computation reply sent by the PCE to a PCC Once the PCC has selected a PCE, it sends a path computation request
to the PCE (PCReq message) that contains a variety of objects that
specify the set of constraints and attributes for the path to be
computed. For example "Compute a TE LSP path with source IP
address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=X
Mbit/s, Priority=Y, ...". Additionally, the PCC may desire to
specify the urgency of such request by assigning a request priority.
Each request is uniquely identified by a request-id number and the
PCC-PCE addresses pair. The process is shown in a schematic form in
figure 2.
Details about the PCReq message can be found in Section 6.4
5.2.3. Path computation reply sent by the PCE to a PCC
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---- PCReq message--->| |---- PCReq message--->|
| |1) Path computation | |1) Path computation
| |request received | |request received
| | | |
| |2)Path successfully | |2)Path successfully
| |computed | |computed
| | | |
| |3) Computed path(s) sent | |3) Computed path(s) sent
| |to the PCC | |to the PCC
skipping to change at page 8, line 24 skipping to change at page 11, line 20
| |request received | |request received
| | | |
| |2)Path successfully | |2)Path successfully
| |computed | |computed
| | | |
| |3) Computed path(s) sent | |3) Computed path(s) sent
| |to the PCC | |to the PCC
|<--- PCRep message ---| |<--- PCRep message ---|
| (Positive reply) | | (Positive reply) |
Figure 3a: Path computation request with successful computation Figure 3a: Path computation request with successful path computation
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
| | | |
|---- PCReq message--->| |---- PCReq message--->|
| |1) Path computation | |1) Path computation
| |request received | |request received
| | | |
| |2) No Path found that | |2) No Path found that
| |satisfies the request | |satisfies the request
| | | |
| |3) Negative reply sent to | |3) Negative reply sent to
| |the PCC (optionally with | |the PCC (optionally with
| |various additional | |various additional
| |information) | |information)
|<--- PCRep message ---| |<--- PCRep message ---|
| (Negative reply) | | (Negative reply) |
Figure 3b: Path computation request with unsuccessfull computation Figure 3b: Path computation request with unsuccessful path computation
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation, the result of which can either be: triggers a path computation, the result of which can either be:
- Positive: the PCE manages to compute a path satisfying the set of
required constraints and returns the set of computed path(s) (note
that the PCEP protocol supports the capability to send a single
request which refers to the computation of multiple paths: for
example, compute two link diverse paths). This is illustrated in
figure 3a.
- Negative: no path could be computed that satisfies the request. In - Positive (Figure 3-a): the PCE manages to compute a path satisfying
this case, a PCE may provide the set of constraints that led to path the set of required constraints. The PCE returns the set of computed
computation failure. Upon receiving a negative reply, a PCC may path(s) to the requesting PCC. Note that PCEP supports the
decide to resend a modified request or take any other appropriate capability to send a single request which refers to the computation
action. This is illustrated in figure 3b. of multiple paths: for example, compute two link-diverse paths.
5.2.4 Notifications - Negative (Figure 3-b): no path could be found that satisfies the
set of constraints. In this case, a PCE may provide the set of
constraints that led to the path computation failure. Upon receiving
a negative reply, a PCC may decide to resend a modified request or
take any other appropriate action.
Details about the PCRep message can be found in Section 6.5.
5.2.4. Notification
There are several circumstances whereby a PCE may want to notify a There are several circumstances whereby a PCE may want to notify a
PCC of a specific event. For example, suppose that the PCE suddenly PCC of a specific event. For example, suppose that the PCE suddenly
experiences some congestion that would lead to unacceptable response experiences some congestion that would lead to unacceptable response
times. The PCE may want to notify one or more PCCs that some of their times. The PCE may want to notify one or more PCCs that some of
requests (listed in the notification) will not be satisfied, their requests (listed in the notification) will not be satisfied or
potentially resulting in path computation redirections on the PCC may experience unacceptable delays. Such notification may
potentially result in path computation redirections on the PCC
towards another PCE, if an alternate PCE is available. Similarly, a towards another PCE, if an alternate PCE is available. Similarly, a
PCC may desire to notify a PCE of particular event such as the PCC may desire to notify a PCE of particular event such as the
cancellation of pending request(s). cancellation of pending request(s).
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
2)PCE Selection | | 2)PCE Selection | |
skipping to change at page 9, line 40 skipping to change at page 13, line 22
request X sent to | |4) Path computation request X sent to | |4) Path computation
the selected PCE | |triggered the selected PCE | |triggered
| | | |
| | | |
5) Path computation| | 5) Path computation| |
request X cancelled| | request X cancelled| |
|---- PCNtf message -->| |---- PCNtf message -->|
| |6) Path computation | |6) Path computation
| |request X cancelled | |request X cancelled
Figure 4: Example of PCC notification (request cancellation) sent to Figure 4: Example of PCC notification (request cancellation) sent to a PCE
a PCE
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
2)PCE Selection | | 2)PCE Selection | |
3)Path computation |---- PCReq message--->| 3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation request X sent to | |4) Path computation
the selected PCE | |triggered the selected PCE | |triggered
| | | |
| | | |
| |5) PCE experiencing | |5) PCE experiencing
| |congestion | |congestion
| | | |
| |6) Path computation | |6) Path computation
| |request X cancelled | |request X cancelled
| | | |
|<--- PCNtf message----| |<--- PCNtf message----|
Figure 5: Example of PCEP notification (request(s) cancellation) send Figure 5: Example of PCE notification (request(s) cancellation) sent to a PCC
to a PCC
Details about the PCNtf message can be found in Section 6.6.
5.2.5. Termination of the PCEP Session 5.2.5. Termination of the PCEP Session
When one of the PCEP peers desires to terminate a PCEP session it When one of the PCEP peers desires to terminate a PCEP session it
MUST close the TCP connection. If the PCEP session is terminated by first sends a PCEP Close message and then close the TCP connection.
the PCE, the PCC MUST clear all the states related to pending
requests sent to the PCE. Similarly, if the PCC terminates a PCEP If the PCEP session is terminated by the PCE, the PCC clears all the
session the PCE MUST clear all pending path computation requests sent states related to pending requests sent to the PCE. Similarly, if
by the PCC in question as well as the related states. the PCC terminates a PCEP session the PCE clears all pending path
computation requests sent by the PCC in question as well as the
related states. A Close message can only be sent to terminate a PCEP
session if the PCEP session has previously been established.
In case of TCP connection failure, the PCEP session SHOULD be In case of TCP connection failure, the PCEP session SHOULD be
maintained for a period of time equal to the Deadtimer. maintained for a period of time equal to the Deadtimer.
6. PCEP messages Details about the Close message can be found in Section 6.8.
6. PCEP Messages
A PCEP message consists of a common header followed by a variable A PCEP message consists of a common header followed by a variable
length body made of a set of objects that can either be mandatory or length body made of a set of objects that can either be mandatory or
optional. In the context of this document, an object is said to be optional. In the context of this document, an object is said to be
mandatory in a PCEP message when the object must be included in such mandatory in a PCEP message when the object must be included in such
message for the message to be valid. Conversely, an object is said to message for the message to be considered as valid. Thus a missing
be optional the object may or may not be present. As specified in mandatory object in a PCEP message MUST be considered as a malformed
section 7.1, a specific flag is also defined in each object that can message and such condition MUST trigger an Error message.
be set by a PCEP peer to enforce a PCE to take into account the Conversely, if an object is optional, the object may or may not be
related information during the path computation. For example, the present.
DELAY object allows a PCC to specify in a path computation request a
bounded acceptable delay for the computed path. The DELAY object is A flag referred to as the P flag is defined in the common header of
optional (does not have to be present in each path computation each PCEP object (see Section 7.1) that can be set by a PCEP peer to
request message) but a PCC may set a flag to ensure that the delay enforce a PCE to take into account the related information during the
constraint is being taken into account when present in a message. path computation. For example, the COST object allows a PCC to
specify a bounded acceptable path cost. The COST object is optional
but a PCC may set a flag to ensure that such constraint is taken into
account. Similarly to the previous case, if such constraint cannot
be taken into account by the PCE, this should trigger an Error
message.
For each PCEP message type a set of rules is defined which specifies For each PCEP message type a set of rules is defined which specifies
the set of possible objects that the message can carry. We use the the set of possible objects that the message can carry. We use the
Backus-Naur Form (BNF) to specify such rules. Square brackets refer Backus-Naur Form (BNF) to specify such rules. Square brackets refer
to optional sub-sequences. An implementation MUST form the PCEP to optional sub-sequences. An implementation MUST form the PCEP
messages using the order specified in this document. messages using the order specified in this document.
If a mandatory object is missing in a received PCEP message the
recipient of the PCEP message MUST trigger a protocol error
condition.
6.1. Common header 6.1. Common header
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Message-Length | | Ver | Flags | Message-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Type | Reserved | | Message-Lenght |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - PCEP message common header Figure 6: PCEP message common header
Ver (Version - 4 bits): PCEP protocol version number. Current
Ver (Version): 3 bits version is version 1.
PCEP protocol version number. The current version is version 1
Flags: 8 bits
No Flags are currently defined
Message Length: 24 bits
Total length of the PCEP message expressed in bytes including
the common header.
Message-Type: 8 bits Flags (8 bits): no flags are currently defined.
The following message types are currently defined. Message-Type (8 bits):
The following message types are currently defined (to be confirmed by
IANA).
Value Meaning Value Meaning
1 Open 1 Open
2 Keepalive 2 Keepalive
3 Path Computation Request 3 Path Computation Request
4 Path Computation Reply 4 Path Computation Reply
5 Notification 5 Notification
6 Error 6 Error
7 Close
Message Length (32 bits): total length of the PCEP message expressed
in bytes including the common header.
6.2. Open message 6.2. Open message
The Open message is a PCEP message sent by a PCC to a PCE in order to
establish a PCEP session. The Message-Type field of the PCEP common
header for the Open message is set to 1 (To be confirmed by IANA).
Once the TCP connection has been successfully established, the first Once the TCP connection has been successfully established, the first
message sent by the PCC to the PCE or by the PCE to the PCC MUST be message sent by the PCC to the PCE or by the PCE to the PCC MUST be
an Open message. The aim of the Open message is to establish a PCEP an Open message. Any message received prior to an OPEN message MUST
session between the PCEP peers. During that phase the PCEP peers trigger a protocol error condition and the PCEP session MUST be
exchange several session characteristics. If both parties agree on terminated. The Open message is used to establish a PCEP session
such characteristics the PCEP session is successfully established. between the PCEP peers. During that phase the PCEP peers exchange
several session characteristics. If both parties agree on such
The Message-Type field of the PCEP common header for the Open message characteristics the PCEP session is successfully established.
is set to 1.
Open message
<Open Message>::= <Common Header> <Open Message>::= <Common Header>
<OPEN> <OPEN>
The Open message MUST contain exactly one OPEN object (see
Section 7.2). Various session characteristics are specified within
the OPEN object.
The Open message MUST only contain a single OPEN object defined in Once an Open message has been sent to a PCEP peer, the sender MUST
section 7. The various session characteristics specified within the start an initialization timer called InitOpen after the expiration of
OPEN object are the keepalive frequency, session mode (permanent or which a similar Open message MUST be resent if no reply has been
per-request) and potentially some optional parameters such as the received from the PCEP peer. The InitOpen timer has a fixed value of
detailed PCE capabilities and policy rules that specify the 1 minute. The maximum number of Open messages named MaxRetryOpen
conditions under which path computation requests may be sent to the that can be sent without any response from the PCEP peer is equal to
PCE. Details related to PCE capabilities discovery by means of PCEP 3.
are out of the scope of this document.
Keepalive: PCEP has its own keepalive mechanism used to ensure of the
liveness of the PCEP session. This requires the determination of the
frequency at which each PCEP peer sends the keepalive messages.
Asymmetric values may be chosen; thus there is no constraints
mandating the use of identical keepalive frequencies by both PCEP
peers. The Deadtimer is defined as the period of time after the
expiration of which a PCEP peer declares the session down if no PCEP
message has been received (keepalive or any other PCEP message: thus,
any PCEP message acts as a keepalive message). The minimum Keepalive
value is 1 second and the Deadtimer value is equal to 4 times the
Keepalive value.
Session mode: PCEP supports two session modes referred to as the
"permanent" and "per-request" modes. In the permanent mode, the PCEP
peers maintained a permanent PCEP session (and thus the TCP session
is also maintained) regardless of the rate at which PCEP messages are
exchanged. Such mode would typically be used to speed-up response
times. In the permanent mode, a loss of TCP session MUST be
interpreted as a communication failure. Conversely, in the
"per-request" mode, a PCEP session is established on-demand, when one or
more path computation requests are required and then closed by the
PCC once those path computation requests are satisfied. Both PCEP
peers MUST agree on the session mode; in case of disagreement, the
PCEP session establishment fails.
Elements of procedure: Upon the receipt of an Open message, the receiving PCEP peer MUST
- Once an Open message has been sent to a PCEP peer, the sender MUST
start an initialization timer called INIT-OPEN after the expiration
of which a similar Open message MUST be resent if no reply has been
received from the PCEP peer. The INIT-OPEN timer has a fixed value of
one minute. The maximum number of Open messages that can be sent
without any response from the PCEP peer is equal to 3.
- Upon the receipt of an Open message, the receiving PCEP peer MUST
determine whether the suggested PCEP session characteristics are determine whether the suggested PCEP session characteristics are
acceptable. If one or more characteristic(s) is not acceptable by the acceptable. If at least one of the characteristic(s) is not
receiving peer, it MUST send a PCErr message with Error-type=8, acceptable by the receiving peer, it MUST send an Error message. The
Error-value=1. The PCErr message MUST also comprise an Open object: Error message SHOULD also contain the related Open object: for each
for each unacceptable session parameter, an acceptable parameter unacceptable session parameter, an acceptable parameter value SHOULD
value MUST be proposed in the appropriate field of the Open object in be proposed in the appropriate field of the Open object in place of
place of the originally proposed value. The PCEP peer may decide to the originally proposed value. The PCEP peer MAY decide to resend an
resend an Open message with different session characteristics. Open message with different session characteristics. If a second
Consecutive retries SHOULD make use of exponential back-off so as to Open message is received with the same set of parameters or with
avoid undesirable burden of session initialization. If a second Open parameters that are still unacceptable, the receiving peer MUST send
message is received with the same set of parameters or with an Error message and it MUST immediately close the TCP connection.
parameters differing from the proposed values, the receiving peer Details about error message can be found in Section 7.14.
MUST send a PCErr message with Error-Type=8, Error-value=2 and it
MUST immediately close the TCP connection.
If the PCEP session characteristics are acceptable, the receiving If the PCEP session characteristics are acceptable, the receiving
PCEP peer MUST immediately send a Keepalive message as an PCEP peer MUST consequently send a Keepalive message (defined in
acknowledgment. Section 6.3) that would serve as acknowledgment.
The PCEP session is considered as operational once both PCEP peers The PCEP session is considered as established once both PCEP peers
have received a Keepalive message from their peer. have received a Keepalive message from their peer.
6.3. Keepalive message 6.3. Keepalive message
A Keepalive message is a PCEP message sent by a PCC or a PCE in order
to keep the session in active state. The Message-Type field of the
PCEP common header for the Keepalive message is set to 2 (To be
confirmed by IANA). The Keepalive message does not contain any
object.
Keepalive: PCEP has its own keepalive mechanism used to ensure of the
liveness of the PCEP session. This requires the determination of the
frequency at which each PCEP peer sends keepalive messages.
Asymmetric values may be chosen; thus there is no constraints
mandating the use of identical keepalive frequencies by both PCEP
peers. The DeadTimer is defined as the period of time after the
expiration of which a PCEP peer declares the session down if no PCEP
message has been received (keepalive or any other PCEP message: thus,
any PCEP message acts as a keepalive message). Similarly, there is
no constraints mandating the use of identical DeadTimers by both PCEP
peers. The minimum KeepAliveTimer value is 1 second.
Keepalive messages are used either to acknowledge an Open message if Keepalive messages are used either to acknowledge an Open message if
the receiving PCEP peer agrees on the session characteristics and to the receiving PCEP peer agrees on the session characteristics and to
ensure the liveness of the PCEP session. Keepalive messages are sent ensure the liveness of the PCEP session. Keepalive messages are sent
at the frequency specified in the OPEN object carried within an Open at the frequency specified in the OPEN object carried within an Open
message. message. Because any PCEP message may serve as Keepalive an
implementation may either decide to send Keepalive messages at the
The Message-Type field of the PCEP common header for the Open message same frequency regardless on whether other PCEP messages might have
is set to 2. been sent since the last sent Keepalive message or may decide to
differ the sending of the next Keepalive message based on the time at
which the last PCEP message (other than Keepalive) was sent.
Keepalive message
<Keepalive Message>::= <Common Header> <Keepalive Message>::= <Common Header>
6.4. Path Computation Request (PCReq) message 6.4. Path Computation Request (PCReq) message
A Path Computation Request message (also referred to as a PCReq A Path Computation Request message (also referred to as a PCReq
message) is sent by a PCC to a PCE so as to request a path message) is a PCEP message sent by a PCC to a PCE so as to request a
computation. The Message-Type field of the PCEP common header is set path computation. The Message-Type field of the PCEP common header
to 3. for the PCReq message is set to 3 (To be confirmed by IANA).
There are two mandatory objects that MUST be included within a PCReq There are two mandatory objects that MUST be included within a PCReq
message: the RP and the END-POINTS objects (see section 7). If one of message: the RP and the END-POINTS objects (see section 7). If one
these objects is missing, the receiving PCE MUST send an error of these objects is missing, the receiving PCE MUST send an error
message to the requester (PCErr message). Other objects are optional. message to the requester. Other objects are optional.
The format of a PCReq message is as follows: The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<SVEC-list>] [<SVEC-list>]
<request-list> <request-list>
where: where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> [<END-POINTS>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<DELAY>] [<METRIC>]
[<RRO>] [<RRO>]
[<XRO>] [<BANDWIDTH>]
[<IRO>] [<IRO>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, DELAY, ERO, XRO and IRO objects are defined in Section 7. The special case of two BANDWIDTH
objects are defined in section 7. objects in details inSection 7.6.
6.5. Path Computation Reply (PCRep) message 6.5. Path Computation Reply (PCRep) message
The PCEP Path Computation reply message (also referred to as a PCRep The PCEP Path Computation Reply message (also referred to as a PCRep
message) is sent by a PCE to a requesting PCC in response to a message) is a PCEP message sent by a PCE to a requesting PCC in
previously received PCReq message. The Message-Type field of the PCEP response to a previously received PCReq message. The Message-Type
common header is set to 4. field of the PCEP common header is set to 4 (To be confirmed by
IANA).
The PCRep message MUST comprise a RP object with a Request-ID-number The PCRep message MUST contain at least one RP object. For each
identical to the one specified in the RP object carried in the reply that is bundled into a single PCReq message, an RP object MUST
corresponding PCReq message (see section 7 for the definition of the be included that contains a Request-ID-number identical to the one
RP object). specified in the RP object carried in the corresponding PCReq message
(see Section 7.3for the definition of the RP object).
A PCRep may comprise multiple computed path(s) corresponding to A PCRep may comprise multiple computed path(s) corresponding to
multiple path computation requests originated by a common requesting multiple path computation requests originated by a common requesting
PCC. The bundling of multiple responses within a single PCRep message PCC and/or to multiple acceptable paths corresponding to the same
is supported by the PCEP protocol. If a PCE receives non-synchronized request. The bundling of multiple responses within a single PCRep
path computation requests by means of one or more PCReq messages from message is supported by the PCEP protocol. If a PCE receives non-
a requesting PCC it may decide to bundle the computed paths within a synchronized path computation requests by means of one or more PCReq
single PCRep message so as to reduce the control plane load. Note messages from a requesting PCC it may decide to bundle the computed
that the counter side of such an approach is the introduction of paths within a single PCRep message so as to reduce the control plane
additional delays for some path computation requests of the set. load. Note that the counter side of such an approach is the
introduction of additional delays for some path computation requests
of the set. Conversely, a PCE that receives multiple requests within
the same PCReq message, may decide to reply each path in separate
PCRep messages.
If the path computation request can be successfully satisfied (the If the path computation request can be successfully satisfied (the
PCE manages to compute a set of path(s) that obey the requested PCE manages to compute a set of path(s) that obey the requested
constraint(s)), the set of computed path(s) specified by means of ERO constraint(s)), the set of computed path(s) specified by means of ERO
object(s) is inserted in the PCRep message. Such a situation where object(s) is inserted in the PCRep message. The ERO object is
multiple computed paths are provided in a PCRep message is discussed defined in Section 7.8. Such a situation where multiple computed
in detail in section 8. paths are provided in a PCRep message is discussed in detail in
Section 7.12.
If the path computation request cannot be satisfied, the PCRep If the path computation request cannot be satisfied, the PCRep
message MUST include a NO-PATH object. The NO-PATH object (further message MUST include a NO-PATH object. The NO-PATH object (further
described in section 7) may also comprise other information (e.g described in Section 7.4) may also comprise other information (e.g
reasons for the path computation failure). reasons for the path computation failure).
The format of a PCRep message is as follows: The format of a PCRep message is as follows:
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<path-list> <response-list>
where: where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<path-list>::=<path>[<path-list>] <response-list>::=<response>[<response-list>]
<path>::=<RP> <response>::=<RP>
[<NO-PATH>] [<NO-PATH>]
[<ero-list>] [<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<DELAY>] [<METRIC>]
[<XRO>]
[<IRO>] [<IRO>]
where:
<ero-list>:==<ERO>[<ero-list]>
6.6. Notification (PCNtf) message 6.6. Notification (PCNtf) message
The PCEP Notification message (also referred to as the PCNtf message) The PCEP Notification message (also referred to as the PCNtf message)
can either be sent by a PCE to a PCC or by a PCC to a PCE so as to can either be sent by a PCE to a PCC or by a PCC to a PCE so as to
notify of a specific event. The Message-Type field of the PCEP common notify of a specific event. The Message-Type field of the PCEP
header is set to 5. common header is set to 5 (To be Confirmed by IANA).
The PCNtf message MUST carry at least one NOTIFICATION object and may The PCNtf message MUST carry at least one NOTIFICATION object and may
comprise several NOTIFICATION objects should the PCE or the PCC contain several NOTIFICATION objects should the PCE or the PCC intend
intend to notify of multiple events. The NOTIFICATION object is to notify of multiple events. The NOTIFICATION object is defined in
defined in section 7. The PCNtf message may also comprise an RP Section 7.13. The PCNtf message may also contain an RP object (see
object when the notification refers to a particular path computation Section 7.3when the notification refers to a particular path
request. computation request.
The PCNtf message may be sent by a PCC or a PCE in response to a The PCNtf message may be sent by a PCC or a PCE in response to a
request or in an unsolicited manner. request or in an unsolicited manner.
The format of a PCNtf message is as follows: The format of a PCNtf message is as follows:
<PCNtf Message>::=<Common Header> <PCNtf Message>::=<Common Header>
<notify-list> <notify-list>
<notify-list>::=<notify> [<notify-list>] <notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>] <notify>::= [<request-id-list>]
<notification-list> <notification-list>
<request-id-list>:==<RP><request-id-list> <request-id-list>:==<RP><request-id-list>
<notification-list>:=<NOTIFICATION><notification-list>
The procedure upon the reception of a PCNtf message is defined in <notification-list>:=<NOTIFICATION><notification-list>
section 9.
6.7. Error (PCErr) message 6.7. Error (PCErr) Message
The PCEP Error message (also referred to as a PCErr message) is sent The PCEP Error message (also referred to as a PCErr message) is sent
when a protocol error condition is met. The Message-Type field of the when a protocol error condition is met. The Message-Type field of
PCEP common header is set to 6. the PCEP common header is set to 6.
The PCErr message may be sent by a PCC or a PCE in response to a The PCErr message may be sent by a PCC or a PCE in response to a
request or in an unsolicited manner. In the former case, the PCErr request or in an unsolicited manner. In the former case, the PCErr
message MUST include the set of RP objects related to the pending message MUST include the set of RP objects related to the pending
path computation request(s) which triggered the protocol error path computation request(s) which triggered the protocol error
condition. In the later case (unsolicited), no RP object is inserted condition. In the later case (unsolicited), no RP object is inserted
within the PCErr message. No RP object is inserted in a PCErr when within the PCErr message. No RP object is inserted in a PCErr when
the error condition occurred during the initialization phase. A PCErr the error condition occurred during the initialization phase. A
message MUST comprise a PCEP-ERROR object specifying the PCEP error PCErr message MUST comprise a PCEP-ERROR object specifying the PCEP
condition. The PCEP-ERROR object is defined in section 7. error condition. The PCEP-ERROR object is defined in section
Section 7.14.
The format of a PCErr message is as follows: The format of a PCErr message is as follows:
<PCErr Message> ::= <Common Header> <PCErr Message> ::= <Common Header>
<error-list> <error-list>
[<Open>] [<Open>]
<error-list>:==<error>[<error-list>] <error-list>:==<error>[<error-list>]
<error>::=[<request-id-list>] <error>::=[<request-id-list>]
<error-obj-list> <error-obj-list>
<request-id-list>:==<RP>[<request-id-list>] <request-id-list>:==<RP>[<request-id-list>]
<error-obj-list>:==<PCEP-ERROR>[<error-obj-list>]
<error-obj-list>:==<PCEP-ERROR>[<error-obj-list>]
The procedure upon the reception of a PCErr message is defined in The procedure upon the reception of a PCErr message is defined in
section 9. Section 7.14.
6.8. Close message
The Close message is a PCEP message sent by either a PCC to a PCE or
by a PCE to a PCC in order to close a PCEP session. The Message-Type
field of the PCEP common header for the Open message is set to 7 (To
be confirmed by IANA).
Open message
<Close Message>::= <Common Header>
<CLOSE>
The Close message MUST contain exactly one CLOSE object (see
Section 6.8).
Upon the receipt of a Close message, the receiving PCEP peer MUST
cancel all pending requests and MUST close the TCP connection.
7. Object Formats 7. Object Formats
7.1. Common object header 7.1. Common object header
A PCEP object carried within a PCEP message consists of one or more A PCEP object carried within a PCEP message consists of one or more
32-bit words with a common header which has the following format: 32-bit words with a common header which has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|I|P| Object Length (bytes) | | Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Object body) // // (Object body) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 - PCEP common object header Figure 8: PCEP common object header
Object-Class (to be managed by IANA)
8-bit field that identifies the PCEP object class
OT (Object-Type) (to be managed by IANA)
4-bit field that identifies the PCEP object type
P flag (Processing-Rule)
1-bit flag which specifies whether the object must be taken into
account by the receiving PCEP peer or is just optional. When the P
flag is cleared, the object MUST be taken into account by the
receiving entity. If the PCC or the PCE does not understand the
object or understands the object but decides to ignore the object,
this MUST trigger a protocol error condition as defined in section
7. Conversely, when the P flag is set the object is optional and
can be silently ignored.
I flag
1-bit flag: the PCE set the I flag when the object is carried Object-Class (8 bits): identifies the PCEP object class.
within a PCRep message so as to indicate when the constraint was
optional and was ignored during path computation.
Res flags: 2-bit flag reserved (MUST be set to 0) OT (Object-Type - 4 bits): identifies the PCEP object type.
Object Length The Object-Class and Object-Type are managed by IANA.
16-bit field containing the total object length in bytes. The The Object-Class and Object-Type fields uniquely identify each PCEP
Object Length field MUST always be a multiple of 4, and at least object.
4.
The maximum object content length is 65528 bytes. The Object-Class Res (3 bits): Reserved.
and Object-Type fields uniquely identify each PCEP object.
The P bit is used to determine what action a node should take if it P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify
does not recognize the Object-Class or Object-Type of a PCEP object in a PCReq message sent to a PCE whether the object must be taken
or decides not to take into account the object: there are two into account by the PCE during path computation or is just optional.
possible ways a PCEP implementation can react. This choice is When the P flag is set, the object MUST be taken into account by the
determined by the P bit, as follows. PCE. Conversely, when the P flag is cleared, the object is optional
and the PCE is free to ignore it if not supported.
If P flag=0 I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep
message to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its
reply and set the I flag to indicate that the optional object was
ignored during path computation. When the I flag is cleared, the PCE
indicates that the optional object was processed during the path
computation. The setting of the I flag for optional objects is
purely indicative and optional. The I flag MUST be cleared if the P
flag is set.
The entire PCEP message MUST be rejected and the receiving PCEP peer If the PCE does not understand an object with the P Flag set or
MUST send a PCErr message with a PCEP-ERROR Object ("Unkown Object" understands the object but decides to ignore the object, the entire
or "Not supported Object"). PCEP message MUST be rejected and the PCE MUST send a PCErr message
with Error-Type="Unknown Object" or "Not supported Object".
If P flag=1 Res flags (2 bits). Reserved field (MUST be set to 0).
The node MAY ignore the object and process the PCEP message if Object Length (16 bits). Specifies the total object length including
possible. In that case (the message can be processed by ignoring the the header, in bytes. The Object Length field MUST always be a
object in question), the PCE SHOULD include the object in the multiple of 4, and at least 4. The maximum object content length is
corresponding PCERep message. The I flag of the common header for 65528 bytes.
this object MUST be set. If the path computation cannot be performed,
a PCErr message MUST be sent to the requesting entity with a PCEP-
ERROR object (Error-type=2, "Unknown Object").
7.2. OPEN Object 7.2. OPEN object
The OPEN object MUST be present in each Open message. There MUST be The OPEN object MUST be present in each Open message and may be
only one OPEN object per Open message. present in PCErr message. There MUST be only one OPEN object per
Open or PCErr message.
The OPEN object contains a set of fields used to specify the PCEP The OPEN object contains a set of fields used to specify the PCEP
protocol version, Keepalive frequency, PCEP session ID along with protocol version, Keepalive frequency, PCEP session ID along with
various flags. The OPEN object may also contain a set of TLVs used to various flags. The OPEN object may also contain a set of TLVs used
convey various session characteristics such as the detailed PCE to convey various session characteristics such as the detailed PCE
capability, policy rules and so on. No TLV is currently defined. capabilities, policy rules and so on. No such TLV is currently
defined.
OPEN Object-Class is to be assigned by IANA (recommended value=1) OPEN Object-Class is to be assigned by IANA (recommended value=1)
OPEN Object-Type is to be assigned by IANA (recommended value=1) OPEN Object-Type is to be assigned by IANA (recommended value=1)
The format of the OPEN object body is as follows: The format of the OPEN object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Keepalive | SID | | Ver | Keepalive | Deadtimer | SID | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - OPEN Object format Figure 9: OPEN Object format
Ver (Ver - 3 bits): PCEP version. Current version is 1.
Version (Ver): 3 bits - Current version is 1.
Keepalive frequency (Keepalive): 16 bits.
Specifies the frequency in seconds at which the sender of the Keepalive (8 bits): minimum period of time (in seconds) between the
Open message will send Keepalive messages. The minimum value for sending of PCEP messages that the sender of the Open message will
the Keepalive is 1 second. When set to 0, no keepalive is sent send Keepalive messages. The minimum value for the Keepalive is 1
to the remote peer. A RECOMMENDED value for the keepalive second. When set to 0, once the session is established, no further
frequency is 30 seconds. keepalives need to be sent to the remote peer. A RECOMMENDED value
for the keepalive frequency is 30 seconds.
PCEP session-ID (SID): 13 bits. DeadTimer (8 bits): specifies the amount of time after the expiration
Specifies a 2 octet unsigned PCEP session number that identifies of which a PCEP peer declares the session with the sender of the Open
the current session. The SID MUST be incremented each time a new message down if no PCEP message has been received. The DeadTimer
PCEP session is established. MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value
for the DeadTimer is 4 times the value of the Keepalive.
Flags SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP
session number that identifies the current session. The SID MUST be
incremented each time a new PCEP session is established and is mainly
used for logging and troubleshooting purposes.
One flag is currently defined. Flags (5 bits): No Flags are currently defined.
R flag: when cleared, this indicates that the sending PCEP peer Optional TLVs may be included within the OPEN object body to specify
requires the establishment of a PCEP session in permanent mode. PCC or PCE characteristics. The specification of such TLVs is
When set, a per-request mode is requested. outside the scope of this document.
Optional TLVs may be included within the Open message body to specify When present in an Open message, the OPEN object specifies the
PCC or PCE characteristics. proposed PCEP session characteristics. Upon receiving unacceptable
PCEP session characteristics during the PCEP session initialization
phase, the receiving PCEP peer (PCE), may include a PCEP object
within the PCErr message so as to propose alternative session
characteristic values.
7.3. RP Object 7.3. RP Object
The RP (Request Parameters) object MUST be carried within every PCReq The RP (Request Parameters) object MUST be carried within each PCReq
and PCRep messages and MAY be carried within PCNtf and PCErr and PCRep messages and MAY be carried within PCNtf and PCErr
messages. messages. The P flag of the RP object MUST be set. The RP object is
used to specify various characteristics of the path computation
request.
7.3.1. Object definition
RP Object-Class is to be assigned by IANA (recommended value=2) RP Object-Class is to be assigned by IANA (recommended value=2)
RP Object-Type is to be assigned by IANA (recommended value=1)
RP Object-Type is to be assigned by IANA (recommended value=1)
The format of the RP object body is as follows: The format of the RP object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |O|C|B|R| Pri | | Reserved | Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // | |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 - RP object body format Figure 10: RP object body format
The RP object has a variable length and may contain additional TLVs. The RP object body has a variable length and may contain additional
No TLV is currently defined. TLVs. No TLV is currently defined.
Flags: 18 bits - The following flags are currently defined: Flags: 18 bits - The following flags are currently defined:
Pri (Priority) field (3 bits) Pri (Priority - 3 bits): the Priority field may be used by the
requesting PCC to specify to the PCE the request's priority from 1 to
This field may be used by the requesting PCC to specify to the 7. The decision of which priority should be used for a specific
PCE the request's priority. The decision of which priority request is of a local matter and MUST be set to 0 when unused.
should be used for a specific request is of a local matter and Furthermore, the use of the path computation request priority by the
MUST be set to 0 when unused. Furthermore, the use of the path PCE's requests scheduler is implementation specific and out of the
computation request priority by the PCE's requests scheduler is scope of this document. Note that it is not required for a PCE to
implementation specific and out of the scope of this document. support the priority field: in that case, the priority field
Note that it is not required for a PCE to support the priority RECOMMENDED be set to 0 by the PCC in the RP object. If the PCE does
field: in that case, the priority field SHOULD be set to 0 by not take into account the request priority, it is RECOMMENDED to set
the PCC in the RP object. If the PCE does not take into account the priority field to 0 in the RP object carried within the
the request priority, it is RECOMMENDED to set the priority corresponding PCRep message, regardless of the priority value
field to 0 in the RP object carried within the corresponding contained in the RP object carried within the corresponding PCReq
PCRep message, regardless of the priority value contained in the message. A higher numerical value of the priority field reflects a
RP object carried within the corresponding PCReq message. A higher priority. Note that it is the responsibility of the network
higher numerical value of the priority field reflects a higher
priority. Note that it is the responsibility of the network
administrator to make use of the priority values in a consistent administrator to make use of the priority values in a consistent
manner across the various PCC(s). The ability of a PCE to manner across the various PCC(s). The ability of a PCE to support
support requests prioritization may be dynamically discovered by requests prioritization may be dynamically discovered by the PCC(s)
the PCC(s) by means of PCE capability discovery. If not by means of PCE capability discovery. If not advertised by the PCE,
advertised by the PCE, a PCC may decide to set the request a PCC may decide to set the request priority and will learn the
priority and will learn the ability of the PCE the support ability of the PCE the support request prioritization by observing
request prioritization by observing the Priority field of the RP the Priority field of the RP object received in the PCRep message.
object received in the PCRep message. If the value of the Pri If the value of the Pri field is set to 0, this means that the PCE
field is set to 0, this means that the PCE does not support the does not support the handling of request priorities: in other words,
Pri field: in other words, the path computation request has been the path computation request has been honoured but without taking the
honoured but without taking the request priority into account. request priority into account.
R (Reoptimization) bit: when set, the requesting PCC specifies R (Reoptimization - 1 bit): when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an that the PCReq message relates to the reoptimization of an existing
existing TE LSP in which case the path of the existing TE LSP to TE LSP in which case the path of the existing TE LSP to be
be reoptimized MUST be provided in the PCReq message by means of reoptimized MUST be provided in the PCReq (except of 0-bandwidth TE
an RRO object defined in section 7. LSP) message by means of an RRO object defined in Section 7.9.
B (Bi-directional) bit: when set, the PCC specifies that the B (Bi-directional - 1 bit): when set, the PCC specifies that the path
path computation request relates to a bidirectional TE LSP (LSPs computation request relates to a bidirectional TE LSP that has the
that have the same traffic engineering requirements including same traffic engineering requirements including fate sharing,
fate sharing, protection and restoration, LSRs, and resource protection and restoration, LSRs, and resource requirements (e.g.
requirements (e.g., latency and jitter) in each direction). When latency and jitter) in each direction. When cleared, the TE LSP is
cleared, the TE LSP is unidirectional. unidirectional.
C (Cost) bit: when set, the PCE MUST provide the cost of the O (strict/lOose - 1 bit): when set, in a PCReq message, this
computed path in the PCRep message. indicates that a strict/loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that an explicit path is required.
In a PCRep message, when the O bit is set this indicates that the
returned path is strict/loose, otherwise (the O bit is cleared), the
returned path is explicit.
O (strict/lOose): In a PCReq message, when set, this means that Request-ID-number (32 bits). The Request-ID-number value combined
a strict/loose path is acceptable. Otherwise, when cleared, this with the source IP address of the PCC and the PCE address uniquely
indicates to the PCE that an explicit path is required. In a identify the path computation request context. The Request-ID-number
PCRep message, when the O bit is set this indicates that the MUST be incremented each time a new request is sent to the PCE. If
returned path is strict/loose, otherwise (the O bit is cleared), no path computation reply is received from the PCE, and the PCC
the returned path is explicit. wishes to resend its request, the same Request-ID-number MUST be
used. Conversely, different Request-ID-number MUST be used for
different requests sent to a PCE. The same Request-ID-number may be
used for path computation requests sent to different PCEs. The path
computation reply is unambiguously identified by the IP source
address of the replying PCE.
Request-ID-number: 32 bits 7.3.2. Handling of the RP object
This value (combined with the source IP address of the PCC) If a PCReq message is received without containing an RP object, the
uniquely identifies the path computation request context and PCE MUST send a PCErr message to the requesting PCC with Error-
MUST be incremented each time a new request is sent to the PCE. type="Required Object missing" and Error-value="RP Object missing".
If no path computation reply is received from the PCE, and the
PCC wishes to resend its request, the same Request-ID-number If the C bit of the RP message carried within a PCReq message is set
MUST be used. Conversely, different Request-ID-number MUST be and local policy has been configured on the PCE to not provide the
used for different requests sent to a PCE. The same Request-ID- computed path cost, a PCErr message MUST be sent by the PCE to the
number may be used for path computation requests sent to requesting PCC and the pending path computation request MUST be
different PCEs. The path computation reply is unambiguously discarded. The Error-type is "Policy Violation" and Error-value is
identified by the IP source address of the replying PCE. "C bit set".
If the O bit of the RP message carried within a PCReq message is set
and local policy has been configured on the PCE to not provide
explicit path(s) (for instance, for confidentiality reasons), a PCErr
message MUST be sent by the PCE to the requesting PCC and the pending
path computation request MUST be discarded. The Error-type is
"Policy Violation" and Error-value is "O bit set".
R bit: when the R bit of the RP object is set in a PCReq message,
this indicates that the path computation request relates to the
reoptimization of an existing TE LSP. In this case, the PCC MUST
provide the explicit or strict/loose path by including an RRO object
in the PCReq message so as to avoid double bandwidth counting if and
only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has
previously requested a non-explicit path (O bit set), a
reoptimization can still be requested by the PCC but this implies for
the PCE to be either stateful (keep track of the previously computed
path with the associated list of strict hops) or to have the ability
to retrieve the complete required path segment. Alternatively the
PCC MUST be able to inform PCE of the working path with associated
list of strict hops in PCReq. The absence of an RRO in the PCReq
message for a non 0-bandwidth TE LSP when the R bit of the RP object
is set MUST trigger the sending of a PCErr message with Error-
type="Required Object Missing" and Error-value="RRO Object missing
for reoptimization".
If the PCC receives a PCRep message that contains a RP object
referring to an unknown Request-ID-Number, the PCC MUST send a PCErr
message with Error-Type="Unknown request reference".
7.4. NO-PATH Object 7.4. NO-PATH Object
When a PCE cannot find a path satisfying a set of constraints, it The No-PATH object is used in PCRep messages in response to a path
MUST include a NO-PATH object in the corresponding PCRep message. In computation request that was unsuccessful (the PCE could not find a
its simplest form, the NO-PATH object is limited to a set of flags path satisfying the set of constraints). When a PCE cannot find a
and just reports the impossibility to find a path that satisfies the path satisfying a set of constraints, it MUST include a NO-PATH
set of constraints. Optionally, if the PCE supports such capability, object in the PCRep message. In its simplest form, the NO-PATH
the PCRep message MAY also comprise a list of objects that specify object is limited to a set of flags and just reports the
the set of constraints that could not be satisfied. When an object impossibility to find a path that satisfies the set of constraints.
specifies a variety of constraints, the set of unsatisfied Optionally, if the PCE supports such capability, the PCRep message
constraints can be unambiguously determined by the PCC after a simple MAY also contain a list of objects that specify the set of
comparison with the original requested constraints. constraints that could not be satisfied. The PCE MAY just replicate
the object that was received that was the cause of the unsuccessful
computation or MAY optionally report a suggested value for which a
path could have been found.
NO-PATH Object-Class is to be assigned by IANA (recommended value=3) NO-PATH Object-Class is to be assigned by IANA (recommended value=3)
NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
The format of the NO-PATH object body is as follows: The format of the NO-PATH object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S| Flags | Reserved | |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 - NO-PATH object format Figure 11: NO-PATH object format
The NO-PATH object body has a fixed length of 4 octets.
The NO-PATH object has a fixed length of 4 octets.
Flags: 16 bits - The following flags are currently defined: Flags (16 bits). The following flags are currently defined:
C bit: when set, this indicates that the set of unsatisfied C flag (1 bit): when set, the PCE indicates the set of unsatisfied
constraints (reasons why a path could not be found) is specified in constraints (reasons why a path could not be found) in the PCRep
the PCRep message by means of the relevant PCEP objects. When message by including the relevant PCEP objects. When cleared, no
cleared, no reason is specified. reason is specified.
For example, consider the case of a PCC that sends a path computation Example: consider the case of a PCC that sends a path computation
request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot
find a path for X MBits/s. In this case, the PCE includes in its path find a path for X MBits/s. In this case, the PCE must include in the
computation reply a NO-PATH object with the C flag set. In addition, PCRep message a NO-PATH object. Optionally the PCE may also include
the PCRep message carries the BANDWIDTH object and the bandwidth the original BANDWIDTH object so as to indicate that the reasons for
field value is equal to X. the unsuccessful computation is the bandwidth constraint (in this
case, the C flag is set). If the PCE supports such capability it may
alternatively include the BANDWIDTH Object and report a value of Y in
the bandwidth field of the BANDWIDTH object (in this case, the C flag
is set).
When the NO-PATH object is absent from a PCRep message, the path When the NO-PATH object is absent from a PCRep message, the path
computation request has been fully satisfied and the corresponding computation request has been fully satisfied and the corresponding
path(s) is/are provided in the PCRep message. path(s) is/are provided in the PCRep message.
7.5. END-POINTS Object 7.5. END-POINT Object
The END-POINTS object is used in a PCReq message to specify the The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the TE LSP for source IP address and the destination IP address of the path for
which a path computation is requested. Two END-POINTS objects (for which a path computation is requested. Note that the source and
IPv4 and IPv6) are defined. destination addresses specified in the END-POINTS object may or may
not correspond to the source and destination IP address of the TE LSP
but rather to a path segment. Two END-POINTS objects (for IPv4 and
IPv6) are defined.
END-POINTS Object-Class is to be assigned by IANA (recommended END-POINTS Object-Class is to be assigned by IANA (recommended
value=4) value=4)
END-POINTS Object-Type is to be assigned by IANA (recommended
value=1 for IPv4 and 2 for IPv6) END-POINTS Object-Type is to be assigned by IANA (recommended value=1
for IPv4 and 2 for IPv6)
The format of the END-POINTS object body for IPv4 (Object-Type=1) is The format of the END-POINTS object body for IPv4 (Object-Type=1) is
as follows: as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 - END-POINTS object body format for IPv4 Figure 12: END-POINTS object body format for IPv4
The format of the END-POINTS object for IPv6 (Object-Type=2) is as The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows:
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Source IPv6 address (16 bytes) | | Source IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 - END-POINTS object body format for IPv6 Figure 13: END-POINTS object body format for IPv6
7.6. BANDWIDTH object The END-POINTS object body has a fixed length of 8 octets for IPv4
and 32 octets for IPv6.
7.6. BANDWIDTH Object
The BANDWIDTH object is optional and can be used to specify the The BANDWIDTH object is optional and can be used to specify the
requested bandwidth and may be carried within PCReq and PCRep requested bandwidth for a TE LSP. In the case of a non existing TE
messages. The absence of the BANDWIDTH object MUST be interpreted by LSP, the BANDWIDTH object MUST be included in the PCReq message so as
the PCE as a path computation request related to a 0 bandwidth TE to specify the required bandwidth for the new TE LSP. In the case of
LSP. the reoptimization of an existing TE LSP, the bandwidth of the
existing TE LSP MUST also be included in addition to the requested
bandwidth if and only if the two values differ. Consequently, two
Object-Type are defined that refer to the requested bandwidth and the
bandwidth of a existing TE LSP for which a reoptimization is being
performed.
When carried within a PCReq message, the BANDWIDTH object specifies a The BANDWIDTH object may be carried within PCReq and PCRep messages.
bandwidth constraint that must be satisfied by the computed path(s)
if P flag is cleared and MAY be ignored if the P flag is set. In a The absence of the BANDWIDTH object MUST be interpreted by the PCE as
PCRep message, the BANDWIDTH object indicates that the bandwidth a path computation request related to a 0 bandwidth TE LSP.
belong to the set of one or more constraint(s) that could be not
satisfied. When absent from the PCRep message that means that the
computed path satisfies the requested bandwidth constraint.
BANDWIDTH Object-Class is to be assigned by IANA (recommended BANDWIDTH Object-Class is to be assigned by IANA (recommended
value=5) value=5)
BANDWIDTH Object-Type is to be assigned by IANA (recommended
value=1)
The format of the BANDWIDTH object body is as follows:
Two Object-Type are defined for the BANDWIDTH object:
o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by
IANA (recommended value=1)
o Bandwidth of an existing TE LSP for which a reoptimization is
performed. BANDWIDTH Object-Type is to be assigned by IANA
(recommended value=2)
The format of the BANDWIDTH object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH | | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 - BANDWIDTH object body format Figure 14: BANDWIDTH object body format
Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in
IEEE floating point format, expressed in bytes per second. IEEE floating point format, expressed in bytes per second.
7.7. DELAY Object The BANDWIDTH object body has a fixed length of 4 octets.
The DELAY object can be used to specify a strict delay constraint for 7.7. METRIC Object
the TE LSP. The delay constraint MUST be taken into account during
path computation if P flag is cleared and MAY be ignored if the P
flag is set. Note that the mechanism used by the PCE to retrieve the
delays of each link is outside of the scope of this document (for the
sake of illustration the link delay could be the IGP metric or a
Service Provider may choose to use the TE metric to represent link
delays). It must be understood that such path metric is only
meaningful if used consistently: for instance, if the delay of a path
computation segment is exchanged between two PCE residing in
different domains, consistent ways of defining the delay must be
used. The delay metric may be carried within PCReq and PCRep
messages. The absence of the DELAY object MUST be interpreted by the
PCE as a path computation request without delay constraint. When
carried within a PCReq message, the DELAY object specifies a delay
constraint that must be satisfied by the computed path(s). In a PCRep
message and when the path computation was successful, the DELAY
object indicates the delay(s) of the computed path(s). When the path
computation was unsuccessful and the delay constraint was one of the
mandatory constraints that could be satisfied the DELAY object MUST
be present in the PCRep message.
DELAY Object-Class is to be assigned by IANA (recommended value=6) The METRIC object is optional and can be used for several purposes.
DELAY Object-Type is to be assigned by IANA (recommended value=1)
The format of the DELAY object body is as follows: In a PCReq message, a PCC MAY insert a METRIC object:
o To indicate the metric that must be optimized by the path
computation algorithm. Currently, two metrics are defined: the
IGP cost and the TE metric (see [RFC3785]).
o To indicate a bound on the path cost than must not be exceeded for
the path to be considered as acceptable by the PCC.
In a PCRep message, the METRIC object MAY be inserted so as to
provide the cost for the computed path. It MAY also be inserted
within a PCRep with the NO-PATH object, to indicate that the metric
constraint could not be satisfied.
The path computation algorithmic aspects used by the PCE to optimize
a path with respect to a specific metric are outside the scope of
this document.
It must be understood that such path metric is only meaningful if
used consistently: for instance, if the delay of a path computation
segment is exchanged between two PCE residing in different domains,
consistent ways of defining the delay must be used.
The absence of the METRIC object MUST be interpreted by the PCE as a
path computation request for which the PCE may choose the metric to
be used.
METRIC Object-Class is to be assigned by IANA (recommended value=6)
METRIC Object-Type is to be assigned by IANA (recommended value=1)
The format of the METRIC object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay | | Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 - DELAY object body format Figure 15: METRIC object body format
Delay: 32 bits. The requested delay constraint is encoded in 32 bits
in IEEE floating point format, expressed in milliseconds. T (Type - 3 bits): Specifies the metric type. Two values are
currently defined:
o T=1: The IGP metric
o T=2: The TE cost
B (Bound - 1 bit): When set in a PCReq message, the metric-value
indicates a bound (a maximum) for the path cost that must not be
exceeded for the PCC to consider the computed path as acceptable.
When the B flag is cleared, the metric-value field MUST be set to
0x0000. In a PCReq message, if the B-flag is cleared, then the
metric-value field MUST be set to 0. The B flag MUST always be
cleared in a PCRep message.
C (Cost - 1 bit): When set in a PECReq message, this indicates that
the PCE MUST provide the computed path cost (should a path satisfying
the constraints be found) in the PCRep message with regards to the
corresponding metric.
Metric-value (32 bits): metric value encoded in 32 bits in IEEE
floating point format.
The METRIC object body has a fixed length of 8 octets.
Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq
message.
In a PCReq message the presence of multiple METRIC object can be used
to specify a multi-parameters (e.g. a metric may be a constraint or a
parameter to minimize/maximize) objective function or multiple bounds
for different constraints.
In a PCRep message, unless not allowed by PCE policy, at least one
METRIC object MUST be present that reports the computed path cost if
the C bit of the RP object was set in the corresponding path
computation request (the B-flag MUST be cleared); optionally the
PCRep message may contain additional METRIC objects that correspond
to bound constraints, in which case the metric-value MUST be equal to
the corresponding path metric cost (the B-flag MUST be set). If no
path satisfying the constraints could be found by the PCE, the METRIC
objects MAY also be present in the PCRep message with the NO-PATH
object, to indicate a constraint metric (B-Flag was set in the path
computation request) that cannot be satisfied.
Example: if a PCC sends a path computation request to a PCE where the
metric to optimize is the IGP metric and the TE metric must not
exceed the value of M, two METRIC object are inserted in the PCReq
message:
o First METRIC Object with B=0, T=1, metric-value=0x0000
o Second METRIC Object with B=1, T=2, metric-value=M
If a path satisfying the set of constraints can be found by the PCE
and no policy preventing to provide the path cost in place, the PCE
inserts one METRIC object with B=0, T=1, metric-value= computed IGP
path cost. Additionally, the PCE may insert a second METRIC object
with B=1, T=2, metric-value= computed TE path cost.
7.8. ERO Object 7.8. ERO Object
The ERO object is used to encode a TE LSP path. If can either be The ERO object is used to encode a TE LSP. The ERO Object is carried
carried within a PCReq message to specify the existing path of a TE within a PCRep message to provide the computed TE LSP should have the
LSP to be reoptimize or within a PCRep message to provide a computed path computation been successful.
TE LSP.
The contents of this object are identical in encoding to the contents The contents of this object are identical in encoding to the contents
of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and [RSVP- of the Explicit Route Object defined in [RFC3209], [RFC3473] and
UNNUM]. That is, the object is constructed from a series of sub- [RFC3477]. That is, the object is constructed from a series of sub-
objects. Any RSVP ERO sub-object already defined or that could be objects. Any RSVP ERO sub-object already defined or that could be
defined in the future for use in the ERO is acceptable in this defined in the future for use in the ERO is acceptable in this
object. object.
PCEP ERO sub-object types correspond to RSVP ERO sub-object types. PCEP ERO sub-object types correspond to RSVP ERO sub-object types.
Since the explicit path is available for immediate signaling by the Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO. and fields in this object are identical to those defined for the ERO.
skipping to change at page 24, line 38 skipping to change at page 33, line 24
ERO Object-Type is to be assigned by IANA (recommended value=1) ERO Object-Type is to be assigned by IANA (recommended value=1)
7.9. RRO Object 7.9. RRO Object
The RRO object is used to record the route followed by a TE LSP. The The RRO object is used to record the route followed by a TE LSP. The
PCEP RRO object is exclusively carried within a PCReq message so as PCEP RRO object is exclusively carried within a PCReq message so as
to specify the route followed by a TE LSP for which a reoptimization to specify the route followed by a TE LSP for which a reoptimization
is desired. is desired.
The contents of this object are identical in encoding to the contents The contents of this object are identical in encoding to the contents
of the Route Record Object defined in [RSPV-TE], [G-RSVP] and [RSVP- of the Route Record Object defined in [RFC3209], [RFC3473] and
UNNUM]. That is, the object is constructed from a series of sub- [RFC3477]. That is, the object is constructed from a series of sub-
objects. Any RSVP RRO sub-object already defined or that could be objects. Any RSVP RRO sub-object already defined or that could be
defined in the future for use in the RRO is acceptable in this defined in the future for use in the RRO is acceptable in this
object. object.
The meanings of all of the sub-objects and fields in this object are The meanings of all of the sub-objects and fields in this object are
identical to those defined for the RRO. identical to those defined for the RRO.
PCEP RRO sub-object types correspond to RSVP RRO sub-object types. PCEP RRO sub-object types correspond to RSVP RRO sub-object types.
RRO Object-Class is to be assigned by IANA (recommended value=8) RRO Object-Class is to be assigned by IANA (recommended value=8)
skipping to change at page 24, line 50 skipping to change at page 33, line 36
objects. Any RSVP RRO sub-object already defined or that could be objects. Any RSVP RRO sub-object already defined or that could be
defined in the future for use in the RRO is acceptable in this defined in the future for use in the RRO is acceptable in this
object. object.
The meanings of all of the sub-objects and fields in this object are The meanings of all of the sub-objects and fields in this object are
identical to those defined for the RRO. identical to those defined for the RRO.
PCEP RRO sub-object types correspond to RSVP RRO sub-object types. PCEP RRO sub-object types correspond to RSVP RRO sub-object types.
RRO Object-Class is to be assigned by IANA (recommended value=8) RRO Object-Class is to be assigned by IANA (recommended value=8)
RRO Object-Type is to be assigned by IANA (recommended value=1) RRO Object-Type is to be assigned by IANA (recommended value=1)
7.10. LSPA Object 7.10. LSPA Object
The LSPA object specifies various TE LSP attributes to be taken into The LSPA object is optional and specifies various TE LSP attributes
account by the PCE during path computation. The LSPA (LSP Attributes) to be taken into account by the PCE during path computation. The
object can either be carried within a PCReq message or a PCRep LSPA (LSP Attributes) object can either be carried within a PCReq
message in case of unsuccessful path computation (in this case, the message or a PCRep message in case of unsuccessful path computation
PCReq message also comprises a NO-PATH object and the LSPA object is (in this case, the PCRep message also comprises a NO-PATH object and
used to indicate the set of constraint(s) that could not be the LSPA object is used to indicate the set of constraint(s) that
satisfied). Most of the fields of the LSPA object are identical to could not be satisfied). Most of the fields of the LSPA object are
the fields of the SESSION-ATTRIBUTE object defined in [RSVP-TE] and identical to the fields of the SESSION-ATTRIBUTE object defined in
[FRR]. [RFC3209] and [RFC4090]. When absent from the PCReq message, this
means that the Setup and Holding priorities are equal to 0, and there
are no affinity constraints.
LSPA Object-Class is to be assigned by IANA (recommended value=9) LSPA Object-Class is to be assigned by IANA (recommended value=9)
Two Objects-Types are defined for the LSPA object: LSPA without Two Objects-Types are defined for the LSPA object: LSPA without
resource affinity (Object-Type to be assigned by IANA with resource affinity (Object-Type to be assigned by IANA with
recommended value=1) and LSPA with resource affinity (Object-type=2). recommended value=1) and LSPA with resource affinity (Object-type=2).
The format of the LSPA object body with and without resource affinity The format of the LSPA object body with and without resource affinity
are as follows: are as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |N|B|L| Reserved | | Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 - LSPA object body format (without resource affinity) Figure 16: LSPA object body format (without resource affinity)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all | | Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |N|B|L| Reserved | | Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 - LSPA object body format (with resource affinity) Figure 17: LSPA object body format (with resource affinity)
Setup Priority (8 bits)
The priority of the session with respect to taking resources,
in the range of 0 to 7. The value 0 is the highest priority.
The Setup Priority is used in deciding whether this session can
preempt another session.
Holding Priority
The priority of the session with respect to holding resources, Setup Prio (Setup Priority - 8 bits). The priority of the session
in the range of 0 to 7. The value 0 is the highest priority. with respect to taking resources, in the range of 0 to 7. The value
Holding Priority is used in deciding whether this session can 0 is the highest priority. The Setup Priority is used in deciding
be preempted by another session. whether this session can preempt another session.
Holding Prio (Holding Priority - 8 bits). The priority of the
session with respect to holding resources, in the range of 0 to 7.
The value 0 is the highest priority. Holding Priority is used in
deciding whether this session can be preempted by another session.
Flags Flags
The flag L corresponds to the "Local protection desired" bit
([RFC3209]) of the SESSION-ATTRIBUTE Object.
The flags L, B and N correspond to the "Local protection desired" L Flag (Local protection desired). When set, this means that the
bit ([RSVP-TE]), "Bandwidth protection desired" bit ([FRR]) and computed path must include links protected with Fast Reroute as
the "Node protection desired" bit ([FRR]) of the SESSION-ATTRIBUTE Object defined in [RFC4090].
respectively.
L Flag (Local protection desired)
When set, this means that the computed path MUST included links
protected with Fast Reroute as defined in [FRR].
B Flag (Bandwidth protection desired)
When set, this means that the computed path MUST included links
protected with Fast Reroute as defined in [FRR] and that benefit
from bandwidth protection. The B flag MUST only be set if the L
flag is set.
N Flag (Node protection desired)
When set, this means that the computed path MUST included links
protected with Fast Reroute as defined in [FRR] and that such
links MUST be protected with NNOP (Next-next hop backup tunnel).
The N flag MUST only be set of the L flag is set.
Note that the B flag and N flag are not exclusive.
7.11. IRO Object 7.11. IRO Object
The IRO (Include Route Object) object is optional and can be used to The IRO (Include Route Object) object is optional and can be used to
specify that the computed path must traverse a set of specified specify that the computed path must traverse a set of specified
network elements. The IRO object may be carried within PCReq and network elements. The IRO object may be carried within PCReq and
PCRep messages. PCRep messages. When carried within a PCRep message with the NO-PATH
object, the IRO indicates the set of elements that could not be
included.
IRO Object-Class is to be assigned by IANA (recommended value=10) IRO Object-Class is to be assigned by IANA (recommended value=10)
IRO Object-Type is to be assigned by IANA (recommended value=1) IRO Object-Type is to be assigned by IANA (recommended value=1)
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (subobjects) | // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 - IRO objet body format
Subobjects
The IRO object is made of sub-object(s) identical to the ones defined Figure 18: IRO object body format
in [RSVP-TE], [G-MPLS] and [RSVP-UNNUM] for use in EROs. Subobjects The IRO object is made of sub-object(s) identical to the
ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs.
The following subobject types are supported: The following subobject types are supported.
Type Subobject Type Subobject
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
4 Unnumbered interface ID 4 Unnumbered Interface ID
32 Autonomous system number 32 Autonomous system number
The L bit of such sub-object has no meaning within an IRO object. The L bit of such sub-object has no meaning within an IRO object.
The ERO object carried within a PCReq message is exclusively used in
the context of a reoptimization path computation request, thus the
need to define a new object (IRO) to specify the inclusion of
specified network element(s) in a path.
7.12. SVEC Object 7.12. SVEC Object
Section 8 details the circumstances under which it may be desirable 7.12.1. Independent versus synchronized path computation requests
and/or required to correlate several path computation requests. This
leads to the specification of the SVEC object (Synchronization The PCEP protocol allows for the bundling of multiple independent
VECtor). The SVEC object is optional in a PCEP message. path computation requests within a single PCRep message. A set of
path computation requests is said to be non synchronized if their
respective treatment (path computations) can be performed by a PCE in
a serialized and independent fashion.
There are various circumstances where the synchronization of a set of
path computations may be beneficial or required.
Consider the case of a set of N TE LSPs for which a PCC needs to send
path computation requests to a PCE. The first solution consists of
sending N separate PCReq messages to the selected PCE. In this case,
the path computation requests are independent. Note that the PCC may
chose to distribute the set of N requests across K PCEs for load
balancing reasons. Considering that M (with M<N) requests are sent
to a particular PCEi, as described above, such M requests can be sent
in the form of successive PCReq messages destined to PCEi or grouped
within a single PCReq message. This is of course a viable solution
if and only if such requests are independent. That said, it can be
desirable to request from the PCE the computation of their paths in a
synchronized fashion that is likely to lead to more optimal path
computations and/or reduced blocking probability if the PCE is a
stateless PCE. In other words, the PCE should not compute the
corresponding paths in a serialized and independent manner but it
should rather simultaneously compute their paths.
For example, trying to simultaneously compute the paths of M TE LSPs
may allow the PCE to improve the likelihood to meet multiple
constraints. Consider the case of two TE LSPs requesting N1 MBits/s
and N2 MBits/s respectively and a maximum tolerable end-to-end delay
for each TE LSP of X ms. There may be circumstances where the
computation of the first TE LSP irrespectively of the second TE LSP
may lead to the impossibility to meet the delay criteria for the
second TE LSP. A second example is related to the bandwidth
constraint. It is quite straightforward to provide examples where a
serialized independent path computation approach would lead to the
impossibility to satisfy both requests (due to bandwidth
fragmentation) while a synchronized path computation would
successfully satisfy both requests. A last example relates to the
ability to avoid the allocation of the same resource to multiple
requests thus helping to reduce the call set up failure probability
compared to the serialized computation of independent requests.
Furthermore, if the PCC has to send a large number of path
computation requests, it may also be desirable to pack multiple
requests within a single PCReq object so as to minimize the control
plane overhead. Note that the algorithm used by the PCC to "pack" a
set of requests introduces some unavoidable trade-off between control
plane load and delays and such algorithm is outside of the scope of
this document.
There are other cases where the computation of M requests must be
synchronized an obvious example of which being the computation of M
diverse paths. If such paths are computed in a non-synchronized
fashion this seriously increases the probability of not being able to
satisfy all requests (sometimes also referred to as the well-know
"trapping problem"). Furthermore, this would not allow a PCE to
implement objective functions such as trying to minimize the sum of
the TE LSP costs. In such a case, the path computation requests must
be synchronized: they cannot be computed independently of each other.
The synchronization of a set of path computation requests is achieved
by using the SVEC object that specifies the list of synchronized
requests along with the nature of the synchronization.
7.12.2. SVEC Object
Section 7.12.1 details the circumstances under which it may be
desirable and/or required to synchronize a set of path computation
requests. The SVEC (Synchronization VECtor) object allows a PCC to
request such synchronization. The SVEC object is optional and may be
carried within a PCReq message.
The aim of the SVEC object carried within a PCReq message is to The aim of the SVEC object carried within a PCReq message is to
specify the correlation of M path computation requests. The SVEC specify the correlation of M path computation requests. The SVEC
object is a variable length object that lists the set of M requests object is a variable length object that lists the set of M path
the computation of which MUST be synchronized. Each path computation computation requests that must be synchronized. Each path
request is uniquely identified by the Request-ID-number carried computation request is uniquely identified by the Request-ID-number
within the respective RP object. The SVEC object also contains a set carried within the respective RP object. The SVEC object also
of flags that specify the synchronization type. contains a set of flags that specify the synchronization type.
The SVEC object is carried within PCReq messages.
SVEC Object-Class is to be assigned by IANA (recommended value=11) SVEC Object-Class is to be assigned by IANA (recommended value=11)
SVEC Object-Type is to be assigned by IANA (recommended value=1) SVEC Object-Type is to be assigned by IANA (recommended value=1)
One Object-Type is defined for this object to be assigned by IANA One Object-Type is defined for this object to be assigned by IANA
with a recommended value of 1. with a recommended value of 1.
The format of the SVEC object body is as follows: The format of the SVEC object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L| | Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Object #1 | | Request-ID-number #1 | |
| |
// // // //
| RP Object #M | | Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19 - SVEC body object format Figure 19: SVEC body object format
Flags: Defines the synchronization type between multiple path
Flags computation requests.
Defines the synchronization type between multiple path computation
requests.
L (Link diverse) bit: when set, this indicates that the computed L (Link diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST not have any link in common. objects MUST not have any link in common.
N (Node diverse) bit: when set, this indicates that the computed N (Node diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST not have any node in common. objects MUST not have any node in common.
S (SRLG diverse) bit: when set, this indicates that the computed S (SRLG diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST not share any SRLG (Shared Risk Link Group). objects MUST not share any SRLG (Shared Risk Link Group).
The flags defined above are not exclusive. The flags defined above are not exclusive.
7.13. NOTIFICATION object 7.12.3. Handling of the SVEC Object
The SVEC object allows a PCC to specify a list of M path computation
requests that must be synchronized along with the nature of the
synchronization. The set of M path computation requests may be sent
within a single PCReq message or multiple PCReq message. In the
later case, it is RECOMMENDED for the PCE to implement a local timer
upon the receipt of the first PCReq message that comprises the SVEC
object after the expiration of which, if all the M path computation
requests have not been received, a protocol error is triggered (this
timer is called the SyncTimer). In this case the PCE MUST cancel the
whole set of path computation requests and MUST send a PCErr message
with Error-Type="Synchronized path computation request missing".
Note that such PCReq message may also comprise non-synchronized path
computation requests. For example, the PCReq message may comprise N
synchronized path computation requests related to RP 1, ... , RP N
listed in the SVEC object along with any other path computation
requests.
7.13. NOTIFICATION Object
The NOTIFICATION object is exclusively carried within a PCNtf message The NOTIFICATION object is exclusively carried within a PCNtf message
and can either be used in a message sent by a PCC to a PCE or by a and can either be used in a message sent by a PCC to a PCE or by a
PCE to a PCC so as to notify of an event. PCE to a PCC so as to notify of an event.
NOTIFICATION Object-Class is to be assigned by IANA (recommended NOTIFICATION Object-Class is to be assigned by IANA (recommended
value=12) value=12)
NOTIFICATION Object-Type is to be assigned by IANA (recommended NOTIFICATION Object-Type is to be assigned by IANA (recommended
value=1) value=1)
One Object-Type is defined for this object to be assigned by IANA One Object-Type is defined for this object to be assigned by IANA
with a recommended value of 1. with a recommended value of 1.
The format of the NOTIFICATION body object is as follows: The format of the NOTIFICATION body object is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Flags | Notification- | Notification- | | Reserved | Flags | NT | NV |
| | | type | value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 - NOTIFICATION body object format Figure 20: NOTIFICATION body object format
NT (Notification Type - 8 bits): the Notification-type specifies the
Length class of notification
The Length contains the total length of the object in bytes and
includes the Type and Length fields. This length must be a
multiple of 4 and must be at least 12.
Flags NV (Notification Value - 8 bits): the Notification-value provides
addition information related to the nature of the notification.
No flags are currently defined Flags: no flags are currently defined.
A NOTIFICATION object is characterized by a Notification-type that Both the Notification-type and Notification-value should be managed
specifies the class of notification and the Notification-value that by IANA.
provides additional information related to the nature of the
notification. Both the Notification-type and Notification-value
should be managed by IANA (see IANA section).
The following Notification-type and Notification-value values are The following Notification-type and Notification-value values are
currently defined: currently defined:
Notification-type=1: Pending Request cancelled o Notification-type=1: Pending Request cancelled
Notification-value=1: PCC cancels a set of pending request(s)
* Notification-value=1: PCC cancels a set of pending request(s).
A Notification-type=1, Notification-value=1 indicates that the A Notification-type=1, Notification-value=1 indicates that the
PCC wants to inform a PCE of the cancellation of a set of PCC wants to inform a PCE of the cancellation of a set of
pending request(s). Such event could be triggered because of pending request(s). Such event could be triggered because of
external conditions such as the receipt of a positive reply from external conditions such as the receipt of a positive reply
another PCE (should the PCC have sent multiple requests to a set from another PCE (should the PCC have sent multiple requests to
of PCEs for the same path computation request), a network event a set of PCEs for the same path computation request), a network
such as a network failure rendering the request obsolete or any event such as a network failure rendering the request obsolete
other event(s) local to the PCC. A NOTIFICATION object with or any other event(s) local to the PCC. A NOTIFICATION object
Notification-type=1, Notification-value=1 is exclusively carried with Notification-type=1, Notification-value=1 is exclusively
within a PCNtf message sent by the PCC to the PCE. The RP object carried within a PCNtf message sent by the PCC to the PCE. The
MUST also be present in the PCNtf message. Multiple RP objects RP object MUST also be present in the PCNtf message. Multiple
may be carried within the PCNtf message in which case the RP objects may be carried within the PCNtf message in which
notification applies to all of them. If such notification is case the notification applies to all of them. If such
received by a PCC from a PCE, the PCC MUST silently ignore the notification is received by a PCC from a PCE, the PCC MUST
notification and no errors should be generated. silently ignore the notification and no errors should be
generated.
Notification-value=2: PCE cancels a set of pending request(s)
* Notification-value=2: PCE cancels a set of pending request(s).
A Notification-type=1, Notification-value=2 indicates that the A Notification-type=1, Notification-value=2 indicates that the
PCE wants to inform a PCC of the cancellation of a set of PCE wants to inform a PCC of the cancellation of a set of
pending request(s). Such event could be triggered because of pending request(s). Such event could be triggered because of
some PCE congested state or because of some path computation some PCE congested state or because of some path computation
requests that are part the set of synchronized path computation requests that are part the set of synchronized path computation
requests are missing. A NOTIFICATION object with Notification- requests are missing. A NOTIFICATION object with Notification-
type=1, Notification-value=2 is exclusively carried within a type=1, Notification-value=2 is exclusively carried within a
PCNtf message sent by a PCE to a PCC. The RP object MUST also be PCNtf message sent by a PCE to a PCC. The RP object MUST also
present in the PCNtf message. Multiple RP objects may be be present in the PCNtf message. Multiple RP objects may be
comprised within the PCNtf message in which case the comprised within the PCNtf message in which case the
notification applies to all of them. If such notification is notification applies to all of them. If such notification is
received by a PCE from a PCC, the PCE MUST silently ignore the received by a PCE from a PCC, the PCE MUST silently ignore the
notification and no errors should be generated. notification and no errors should be generated.
Notification-type=2: PCE congestion o Notification-type=2: PCE congestion
Notification-value=1
A Notification-type=2, Notification-value=1 indicates to the * Notification-value=1. A Notification-type=2, Notification-
PCC(s) that the PCE is currently in a congested state. If no RP value=1 indicates to the PCC(s) that the PCE is currently in a
objects are comprised in the PCNtf message, this indicates that congested state. If no RP objects are comprised in the PCNtf
no other requests SHOULD be sent to that PCE until the congested message, this indicates that no other requests SHOULD be sent
state is cleared: the pending requests are not affected and will to that PCE until the congested state is cleared: the pending
be served. If some pending requests cannot be served due to the requests are not affected and will be served. If some pending
congested state, the PCE MUST also include a set of RP object(s) requests cannot be served due to the congested state, the PCE
that identifies the set of pending requests which will not be MUST also include a set of RP object(s) that identifies the set
honored and which will be cancelled by the PCE. In this case, of pending requests that are now cancelled by the PCE and will
the PCE does not have to send an additional PCNtf message with not be honored. In this case, the PCE does not have to send an
Notification-type=1 and Notification-value=2 since the list of additional PCNtf message with Notification-type=1 and
cancelled requests is specified by including the corresponding Notification-value=2 since the list of cancelled requests is
set of RP object(s). If such notification is received by a PCE specified by including the corresponding set of RP object(s).
from a PCC, the PCE MUST silently ignore the notification and no If such notification is received by a PCE from a PCC, the PCE
errors should be generated. MUST silently ignore the notification and no errors should be
generated.
Optionally, a TLV named CONGESTION-DURATION may be included in Optionally, a TLV named CONGESTION-DURATION may be included in the
the NOTIFICATION object that specifies the duration during which NOTIFICATION object that specifies the duration during which no further
no further request should be sent to the PCE. Once this period request should be sent to the PCE. Once this period has expired the PCE
has expired the PCE should no longer be considered in congested should no longer be considered in congested state.
state.
The CONGESTION-DURATION TLV is composed of 1 octet for the type, The CONGESTION-DURATION TLV is composed of 1 octet for the type,
1 octet specifying the number of bytes in the value field 1 octet specifying the number of bytes in the value field, 2 octets
followed by a fix length value field of 4 octets specifying the for an "Unused" field (the value of which MUST be set to 0), followed by
estimated PCE congestion duration in seconds. The CONGESTION- a fix length value field of 4 octets specifying the estimated PCE
DURATION TLV is padded to eight-octet alignment congestion duration in seconds. The CONGESTION-DURATION TLV is padded
to eight-octet alignment.
TYPE: To be assigned by IANA TYPE: To be assigned by IANA
LENGTH: 4 LENGTH: 4
VALUE: estimated congestion duration in seconds VALUE: estimated congestion duration in seconds
Notification-value=2 * If a new PCEP session is established while the PCE is in
congested state, the PCE MUST immediately send a PCErr with
Notification-type=2, Notification-value=1 along with optionally
the CONGESTION-DURATION TLV.
A Notification-type=2, Notification-value=2 indicates that the * Notification-value=2. A Notification-type=2, Notification-
PCE is no longer in congested state and is available to process value=2 indicates that the PCE is no longer in congested state
new path computation requests. An implementation MUST make sure and is available to process new path computation requests. An
that a PCE sends such notification to every PCC to which a implementation MUST make sure that a PCE sends such
Notification message (with Notification-type=2, Notification- notification to every PCC to which a Notification message (with
value=1) has been sent unless a CONGESTION-DURATION TLV has been Notification-type=2, Notification-value=1) has been sent unless
included in the corresponding message and the PCE wishes to wait a CONGESTION-DURATION TLV has been included in the
for the expiration of that period of time before receiving new corresponding message and the PCE wishes to wait for the
expiration of that period of time before receiving new
requests. An implementation may decide to cancel such requests. An implementation may decide to cancel such
notification if the PCC is in down state for a specific period. notification if the PCC is in down state for a specific period.
A RECOMMENDED value for such delay is 1 hour. If such A RECOMMENDED value for such delay is 1 hour. If such
notification is received by a PCE from a PCC, the PCE MUST notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be silently ignore the notification and no errors should be
generated. generated. It is RECOMMENDED to support some dampening
notification procedure on the PCE so as to avoid too frequent
It is RECOMMENDED to support some dampening notification procedure on congestion notifications and releases. For example, an
the PCE so as to avoid too frequent congestion notifications and implementation could make use of an hysteresis approach using a
releases. For example, an implementation could make use of an dual-thresholds mechanism triggering the sending of congestion
hysteresis approach using a dual-thresholds mechanism triggering the notifications and releases. Furthermore, in case of high
sending of congestion notifications and releases. Furthermore, in instabilities of the PCE resources, an additional dampening
case of high instabilities of the PCE resources, an additional mechanism SHOULD be used (linear or exponential) to pace the
dampening mechanism SHOULD be used (linear or exponential) to pace notification frequency and avoid path computation requests
the notification frequency and avoid path computation requests
oscillation. oscillation.
7.14. PCEP-ERROR object 7.14. PCEP-ERROR Object
The PCEP-ERROR object is exclusively carried within a PCErr message The PCEP-ERROR object is exclusively carried within a PCErr message
and can either be used in a message sent by a PCC to a PCE or by a to notify of a PCEP protocol error.
PCE to a PCC to notify of a PCEP protocol error.
PCEP-ERROR Object-Class is to be assigned by IANA (recommended PCEP-ERROR Object-Class is to be assigned by IANA (recommended
value=13) value=13)
PCEP-ERROR Object-Type is to be assigned by IANA (recommended PCEP-ERROR Object-Type is to be assigned by IANA (recommended
value=1) value=1)
One Object-Type is defined for this object to be assigned by IANA One Object-Type is defined for this object to be assigned by IANA
with a recommended value of 1. with a recommended value of 1.
The format of the PCEP-ERROR object body is as follows: The format of the PCEP-ERROR object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Flags | Error-Type | Error-Value | | Reserved | Flags | Error-Type | Error-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21 - PCEP-ERROR object body format Figure 21: PCEP-ERROR object body format
A PCEP-ERROR object is used to report a PCEP protocol error and is A PCEP-ERROR object is used to report a PCEP protocol error and is
characterized by an Error-Type that specifies the type of error and characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value should be managed by type. Both the Error-Type and the Error-Value should be managed by
IANA (see the IANA section). IANA (see the IANA section).
Length (8 bits) Flags (8 bits): no flag is currently defined.
The Length contains the total length of the object in bytes
including the Type and Length fields. This length must be a
multiple of 4 and must be at least 8.
Flags (8 bits)
No flag is currently defined.
Error-type (8 bits)
The Error-type defines the class of error.
Error-value (8 bits) Error-type (8 bits): defines the class of error.
Provides additional details about the error. Error-value (8 bits): provides additional details about the error.
Optionally the PCErr message may contain additional TLV so as to Optionally the PCEP-ERROR object may contain additional TLV so as to
provide further information about the encountered error. No TLV is provide further information about the encountered error. No TLV is
currently defined. currently defined.
A single PCErr message may contain multiple PCEP-ERROR objects. A single PCErr message may contain multiple PCEP-ERROR objects.
For each PCEP protocol error, an Error type and value is defined. For each PCEP protocol error, an Error-type and an Error-value are
defined.
Error-Type Meaning Error-Type Meaning
1 Capability not supported 1 Capability not supported
2 Unknown Object 2 Unknown Object
Error-value=1: Unrecognized object class Error-value=1: Unrecognized object class
Error-value=2: Unrecognized object Type Error-value=2: Unrecognized object Type
3 Not supported object 3 Not supported object
Error-value=1: Not supported object class Error-value=1: Not supported object class
Error-value=2: Not supported object Type Error-value=2: Not supported object Type
4 Policy violation 4 Policy violation
Error-value=1: C bit set (request rejected) Error-value=1: C bit of the METRIC object set (request rejected)
Error-value=2: O bit set (request rejected) Error-value=2: O bit of the RP object set (request rejected)
5 Required Object missing 5 Mandatory Object missing
Error-value=1: RP object missing Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set) request (R bit of the RP object set)
Error-value=3: END-POINTS object missing Error-value=3: END-POINTS object missing
6 Synchronized path computation request missing 6 Synchronized path computation request missing
7 Unknown request reference 7 Unknown request reference
8 Unacceptable PCEP session characteristics 8 Unacceptable PCEP session characteristics
Error-value=1: parameter negotiation Error-value=1: parameter negotiation
Error-value=2: parameters negotiation failed Error-value=2: parameters negotiation failed
9 Deadtimer expired 9 Deadtimer expired
In case of the Error-Type 1, the PCE indicates that the path
computation request cannot be completed because it does not support
one or more required capability. The corresponding path computation
request MUST then be cancelled.
If a PCEP message is received that carries a mandatory PCEP object (P
flag cleared) not recognized by the PCEP peer or recognized but not
supported, then the PCEP peer MUST send a PCErr message with a PCEP-
ERROR object (Error-Type=2 and 3 respectively). The corresponding
path computation request MUST be cancelled by the PCE without further
notification.
If a path computation request is received which is not compliant with
an agreed policy between the PCC and the PCE, the PCE MUST send a
PCErr message with a PCEP-ERROR object (Error-Type=4). The
corresponding path computation MUST be cancelled.
If a path computation request is received that does not contain a
required object, the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=5). If there are multiple mandatory objects
missing, the PCErr message MUST contain one PCEP-ERROR object per
missing object. The corresponding path computation MUST be cancelled.
If a PCC sends a synchronized path computation request to a PCE and
the PCE does not receive all the synchronized path computation
requests listed within the corresponding SVEC object during a
configurable period of time, the PCE MUST send a PCErr message with a
PCEP-ERROR object (Error-Type=6). The corresponding synchronized path
computation MUST be cancelled.
If a PCC receives a PCRep message related to an unknown path
computation request, the PCC MUST send a PCErr message with a PCEP-
ERROR object (Error-Type=6). In addition, the PCC MUST include in the
PCErr message the unknown RP object.
If one or more characteristic(s) is not acceptable by the receiving
peer, it MUST send a PCErr message with Error-type=8, Error-value=1.
The PCErr message MUST also comprise an Open object: for each
unacceptable session parameter, an acceptable parameter value MUST be
proposed in the appropriate field of the Open object in place of the
originally proposed value. If a second Open message is received with
the same set of parameters or with parameters differing from the
proposed values, the receiving peer MUST send a PCErr message with
Error-Type=8, Error-value=2 and it MUST immediately close the TCP
connection.
If a PCEP peer does not receive any PCEP message (Keepalive, PCReq,
PCRep, PCNtf) during the Deadtimer period (equal to four times the
Keepalive value advertised in the OPEN object) the PCEP peer MUST
send a PCErr message with a PCEP-ERROR object (Error-type=9, Error-
value=1). Additionally, the PCEP session MUST be terminated and the
TCP connection MUST be closed.
8. Independent versus synchronized path computation requests
The PCEP protocol permits the bundling of multiple independent path Error-Type=1: the PCE indicates that the path computation request
computation requests within a single PCRep message. A set of path cannot be completed because it does not support one or more required
computation requests is said to be non synchronized if their capability. The corresponding path computation request MUST be
respective treatment (path computations) can be performed by a PCE in cancelled.
a serialized and independent fashion.
There are various circumstances where the synchronization of a set of
path computations may be beneficial or required.
Consider the case of a set of N TE LSPs for which a PCC needs to send
path computation requests to a PCE so as to obtain their respective
paths. The first solution consists of sending N separate PCReq
messages to the selected PCE. In this case, the path computation
requests are independent. Note that the PCC may chose to distribute
the set of N requests across K PCEs for load balancing reasons.
Considering that M (with M<N) requests are sent to a particular PCEi,
as described above, such M requests can be sent in the form of
successive PCReq messages destined to PCEi or grouped within a single
PCReq message. This is of course a viable solution if and only if
such requests are independent. That said, it can be desirable to
request from the PCE the computation of their paths in a synchronized
fashion that is likely to lead to more optimal path computations
and/or reduced blocking probability if the PCE is a stateless PCE. In
other words, the PCE should not compute the corresponding paths in a
serialized and independent manner but it should rather simultaneously
compute their paths.
For example, trying to simultaneously compute the paths of M TE LSPs Error-Type=2 or Error-Type=3: if a PCEP message is received that
may allow the PCE to improve the likelihood to meet multiple carries a PCEP object (with the P flag set) not recognized by the PCE
constraints. Consider the case of two TE LSPs requesting N1 MBits/s or recognized but not supported, then the PCE MUST send a PCErr
and N2 MBits/s respectively and a maximum tolerable end to end delay message with a PCEP-ERROR object (Error-Type=2 and 3 respectively).
for each TE LSP of X ms. There may be circumstances where the The corresponding path computation request MUST be cancelled by the
computation of the first TE LSP irrespectively of the second TE LSP PCE without further notification.
may lead to the impossibility to meet the delay criteria for the
second TE LSP. A second example is related to the bandwidth
constraint. It is quite straightforward to provide examples where a
serialized independent path computation approach would lead to the
impossibility to satisfy both requests (due to bandwidth
fragmentation) while a synchronized path computation would
successfully satisfy both requests. A last example relates to the
ability to avoid the allocation of the same resource to multiple
requests thus helping to reduce the call set up failure probability
compared to the serialized computation of independent requests.
Furthermore, if the PCC has to send a large number of path Error-Type=4: if a path computation request is received which is not
computation requests, it may also be desirable to pack multiple compliant with an agreed policy between the PCC and the PCE, the PCE
requests within a single PCReq object so as to minimize the control MUST send a PCErr message with a PCEP-ERROR object (Error-Type=4).
plane overhead. Note that the algorithm used by the PCC to "pack" The corresponding path computation MUST be cancelled. Policy-
a set of requests introduces some unavoidable trade-off between control specific TLV(s) carried within the PCEP-ERROR object may be defined
plane load and delays and such algorithm is outside of the scope of in other documents to specify the nature of the policy violation.
this document.
There are other cases where the computation of M requests must be Error-Type=5: if a path computation request is received that does not
synchronized an obvious example of which being the computation of M contain a mandatory object, the PCE MUST send a PCErr message with a
diverse paths. If such paths are computed in a non-synchronized PCEP-ERROR object (Error-Type=5). If there are multiple mandatory
fashion this seriously increases the probability of not being able to objects missing, the PCErr message MUST contain one PCEP-ERROR object
satisfy all requests (sometimes also referred to as the well-know per missing object. The corresponding path computation MUST be
"trapping problem"). Furthermore, this would not allow a PCE to cancelled.
implement objective functions such as trying to minimize the sum of
the TE LSP costs. In such a case, the path computation requests are
synchronized: they cannot be computed independently of each other.
The synchronization of a set of path computation requests is Error-Type=6: if a PCC sends a synchronized path computation request
achieved by using the SVEC object that specifies the list of to a PCE and the PCE does not receive all the synchronized path
synchronized requests along with the nature of the synchronization. computation requests listed within the corresponding SVEC object
after the expiration of the timer SyncTimer defined in
Section 7.12.3, the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=6). The corresponding synchronized path
computation MUST be cancelled. It is RECOMMENDED for the PCE to
include the REQ-MISSING TLV(s) (defined below) that identifies the
missing request(s).
9. Elements of procedure The REQ-MISSING TLV is composed of 1 octet for the type,
1 octet specifying the number of bytes in the value field, 2 octets
for an "Unused" field (the value of which MUST be set to 0), followed by
a fix length value field of 4 octets specifying the request-id-number
that correspond to the missing request. The REQ-MISSING TLV is padded
to eight-octet alignment.
9.1. Non recognized or non support object received in a PCReq message TYPE: To be assigned by IANA
LENGTH: 4
VALUE: request-id-number that corresponds to the missing request
If a PCEP message is received that carries a mandatory PCEP object (P Error-Type=7: if a PCC receives a PCRep message related to an unknown
flag cleared) not recognized by the PCE or recognized but not path computation request, the PCC MUST send a PCErr message with a
supported, then the PCE MUST send a PCErr message with a PCEP-ERROR PCEP-ERROR object (Error-Type=7). In addition, the PCC MUST include
object (Error-Type=2 and 3 respectively). In addition, the PCRep in the PCErr message the unknown RP object.
message MUST comprise the set of non recognized or non supported
object(s). The corresponding path computation request MUST be
cancelled by the PCE without further notification.
9.2. RP object Error-Type=8: if one or more PCEP session characteristic(s) are not
acceptable by the receiving peer and are not negotiable, it MUST send
a PCErr message with Error-type=8, Error-value=1. Conditions under
which such error message is sent are detailed in Section 6.2
The absence of a RP object in the PCReq message MUST trigger the Error-Type=9: If a PCEP peer does not receive any PCEP message
sending of a PCErr message with Error-type=5 and Error-value=1. (Keepalive, PCReq, PCRep, PCNtf) during the Deadtimer period, the
PCEP peer MUST send a PCErr message with a PCEP-ERROR object (Error-
type=9, Error-value=1). The PCEP session MUST be terminated
according to the procedure defined in Section 6.8.
If the C bit of the RP message carried within a PCReq message is set 7.15. CLOSE Object
and some local policy has been configured on the PCE not to provide
such cost, a PCErr message MUST be sent by the PCE to the requesting
PCC and the pending path computation request MUST be discarded. The
Error-type and Error-value of the PCEP-ERROR object MUST be set to 4
and 1 respectively.
If the O bit of the RP message carried within a PCReq message is set The CLOSE object MUST be present in each Close message. There MUST
and some local policy has been configured on the PCE to not provide be only one CLOSE object per Close message.
explicit path(s) (for instance, for confidentiality reasons), then a
PCErr message MUST be sent by the PCE to the requesting PCC and the
pending path computation request MUST be discarded. The Error-type
and Error-value of the PCEP-ERROR object MUST be set to 4 and 2
respectively.
R bit: when the R bit of the RP object is set in a PCReq message, CLOSE Object-Class is to be assigned by IANA (recommended value=14)
this indicates that the path computation request relates to the
reoptimization of an existing TE LSP. In this case, the PCC MUST
provide the explicit or strict/loose path by including an RRO object
in the PCReq message so as to avoid double bandwidth counting (unless
the TE LSP is a 0-bandwidth TE LSP). If the PCC has previously
requested a non-explicit path (O bit set), a reoptimization can still
be requested by the PCC but this implies for the PCE to be either
stateful (keep track of the previously computed path with the
associated list of strict hops) or to have the ability to retrieve
the complete required path segment, or for PCC to inform PCE of the
working path with associated list of strict hops in PCReq. The
absence of an RRO in the PCReq message when the R bit of the RP
object is set MUST trigger the sending of a PCErr message with Error-
type=5 and Error-value=2.
If the PCC receives a PCRep message which contains a RP object CLOSE Object-Type is to be assigned by IANA (recommended value=1)
referring to an unknown Request-ID-Number, it MUST trigger the The format of the CLOSE object body is as follows:
sending of a PCErr message with Error-Type=7 and Error-value=1. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.3. SVEC object Figure 14: CLOSE Object format
Reason (4 bits): specifies the reason for closing the PCEP session.
The setting of this field is optional. Two values are currently
defined.
When a requesting PCC desires to send multiple synchronized path Reasons
computation requests, it MUST send all the path computation requests Value Meaning
within a single PCReq message that contains all the synchronized path 1 No explanation provided
computation requests: in that case, the PCReq message MUST also 2 DeadTimer expired
comprise a SVEC object listing all the synchronized path computation 3 PCEP session characteristics negotiation failure
requests. Note that such PCReq message may also comprise non- Flags (4 bits): No Flags are currently defined.
synchronized path computation requests. For example, the PCReq
message may comprise N synchronized path computation requests related
to RP 1, ... , RP N listed in the SVEC object along with any other path
computation requests.
If some RPs objects carried with the SVEC object are missing in the Optional TLVs may be included within the CLOSE object body. The
PCReq message, the PCE MUST send a PCErr message with Error-Type = 6 specification of such TLVs is outside the scope of this document.
to the PCC.
10. Manageability Considerations 8. Manageability Considerations
It is expected and required to specify a MIB for the PCEP It is expected and required to specify a MIB for the PCEP
communication protocol (in a separate document). communication protocol (in a separate document). Furthermore,
additional tools related to performance, fault and diagnostic
Furthermore, additional tools related to performance, fault and detection are required which will also be specified in separate
diagnostic detection are required which will also be specified in documents.
separate documents.
11. IANA Considerations 9. IANA Considerations
11.1. TCP port 9.1. TCP Port
The PCEP protocol will use a well-known TCP port to be assigned by The PCEP protocol will use a well-known TCP port to be assigned by
IANA. IANA.
11.2. PCEP Objects 9.2. PCEP Messages
Several new PCEP objects are defined in this document that have an
Object-Class and an Object-Type. The new Object-Class and Object-Type
should be assigned by IANA.
- Open Object
The Object-Class of the Open object is to be assigned by IANA
(recommended value=1).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- RP Object
The Object-Class of the RP object is to be assigned by IANA
(recommended value=2).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- NO-PATH Object
The Object-Class of the NO-PATH object is to be assigned by IANA
(recommended value=3).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- END-POINTS Object
The Object-Class of the END-POINTS object is to be assigned by IANA
(recommended value=4).
Two Object-Type are defined for this object and should be assigned by
IANA with a recommended value of 1 and 2 for IPv4 and IPv6
respectively.
- BANDWIDTH Object
The Object-Class of the BANDWIDTH object is to be assigned by IANA
(recommended value=5).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- DELAY Object
The Object-Class of the DELAY object is to be assigned by IANA
(recommended value=6).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- ERO Object
The Object-Class of the ERO object is to be assigned by IANA Each PCEP message has a Message-Type.
(recommended value=7).
One Object-Type is defined for this object and should be assigned by Value Meaning
IANA with a recommended value of 1. 1 Open
2 Keepalive
3 Path Computation Request
4 Path Computation Reply
5 Notification
6 Error
7 Close
- RRO Object 9.3. PCEP Object
The Object-Class of the RRO object is to be assigned by IANA IANA assigns value to PCEP parameters. Each PCEP object has an
(recommended value=8). Object-Class and an Object-Type.
One Object-Type is defined for this object and should be assigned by Object-Class Name
IANA with a recommended value of 1.
- LSPA Object 1 OPEN
Object-Type
1
The Object-Class of the LSPA object is to be assigned by IANA 2 RP
(recommended value=9). Object-Type
1
Two Object-Types are defined for this object and should be assigned 3 NO-PATH
by IANA with a recommended value of 1 (without resource affinity) and Object-Type
2 (with resource affinity). 1
- IRO Object 4 END-POINTS
Object-Type
1 : IPv4 addresses
2: IPv6 addresses
The Object-Class of the IRO object is to be assigned by IANA 5 BANDWIDTH
(recommended value=10). Object-Type
1: Requested bandwidth
2: Bandwidth of an existing TE LSP
for which a reoptimization is performed.
One Object-Type is defined for this object and should be assigned by 6 METRIC
IANA with a recommended value of 1. Object-Type
1
- SVEC Object 7 ERO
Object-Type
1
The Object-Class of the SVEC object is to be assigned by IANA 8 RRO
(recommended value=11). Object-Type
1
One Object-Type is defined for this object and should be assigned by 9 LSPA
IANA with a recommended value of 1. Object-Type
1: without resource affinity
2: with resource affinity
- NOTIFICATION Object 10 IRO
Object-Type
1
The Object-Class of the NOTIFICATION object is to be assigned by IANA 11 SVEC
(recommended value=12). Object-Type
1
One Object-Type is defined for this object and should be assigned by 12 NOTIFICATION
IANA with a recommended value of 1. Object-Type
1
- PCEP-ERROR Object 13 PCEP-ERROR
The Object-Class of the PCEP-ERROR object is to be assigned by IANA Object-Type
(recommended value=13). 1
One Object-Type is defined for this object and should be assigned by 14 CLOSE
IANA with a recommended value of 1. Object-Type
1
11.3. Notification 9.4. Notification
A NOTIFICATION object is characterized by a Notification-type that A NOTIFICATION object is characterized by a Notification-type that
specifies the class of notification and a Notification-value that specifies the class of notification and a Notification-value that
provides additional information related to the nature of the provides additional information related to the nature of the
notification. Both the Notification-type and Notification-value notification. Both the Notification-type and Notification-value are
should be managed by IANA (see IANA section). managed by IANA (see IANA section).
The following Notification-type and Notification-value values are
currently defined:
Notification-type=1: Pending Request cancelled
Notification-value=1: PCC cancels a set of pending request(s)
Notification-value=2: PCE cancels a set of pending request(s)
Notification-type=2: PCE congestion
Notification-value=1: PCE in congested state
Notification-value=2: PCE no longer in congested state Notification-type Name
1 Pending Request cancelled
Notification-value
1: PCC cancels a set of pending request(s)
2: PCE cancels a set of pending request(s)
2 PCE Congestion
Notification-value
1: PCE in congested state
2: PCE no longer in congested state
11.4. PCEP Error 9.5. PCEP Error
A PCEP-ERROR object is used to report a PCEP protocol error and is PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type which specifies the type of error and characterized by an Error-Type which specifies the type of error and
an Error-value that provides additional information about the error an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value should be managed by type. Both the Error-Type and the Error-Value are managed by IANA.
IANA.
Error-Type Meaning
Error-type Meaning
1 Capability not supported 1 Capability not supported
Error-value
1
2 Unknown Object 2 Unknown Object
Error-value=1: Unrecognized object class Error-value
Error-value=2: Unrecognized object Type 1: Unrecognized object class
2: Unrecognized object Type
3 Not supported object 3 Not supported object
Error-value=1: Not supported object class Error-value
Error-value=2: Not supported object Type 1: Not supported object class
2: Not supported object Type
4 Policy violation 4 Policy violation
Error-value=1: C bit set (request rejected) Error-value
Error-value=2: O bit set (request rejected) 1: C bit of the METRIC object set (request rejected)
5 Required Object missing 2: O bit of the RP object set (request rejected)
Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization 5 Mandatory object missing
request (R bit of the RP object set). Error-value
Error-value=3: END-POINTS object missing 1: RP object missing
2: RRO object missing for a reoptimization request
(R bit of the RP object set)
3: END-POINTS object missing
6 Synchronized path computation request missing 6 Synchronized path computation request missing
Error-value
1
7 Unknown request reference 7 Unknown request reference
Error-value
1
8 Unacceptable PCEP session characteristics 8 Unacceptable PCEP session characteristics
Error-value=1: parameter negotiation Error-value
Error-value=2: parameters negotiation failed 1
9 Deadtimer expired
12. Security Considerations 9 Deadtimer expiration
Error-value
1
PCEP communication could be the target of the following attacks: 10. Security Considerations
-Spoofing (PCC or PCE impersonation)
-Snooping (message interception)
-Falsification
-Denial of Service
A PCEP attack may have significant impact, particularly in an inter- The PCEP protocol could be the target of the following attacks:
AS context as PCEP facilitates inter-AS path establishment.
o Spoofing (PCC or PCE impersonation)
o Snooping (message interception)
o Falsification
o Denial of Service
A PCEP attack may have significant impact, particularly in an
inter-AS context as PCEP facilitates inter-AS path establishment.
Several mechanisms are proposed below, so as to ensure Several mechanisms are proposed below, so as to ensure
authentication, integrity and privacy of PCEP Communications, and authentication, integrity and privacy of PCEP Communications, and
also to protect against DoS attacks. also to protect against DoS attacks.
12.1. PCEP Authentication and Integrity 10.1. PCEP Authentication and Integrity
It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
provide for the authenticity and integrity of PCEP messages. provide for the authenticity and integrity of PCEP messages. This
This will allow protecting against PCE or PCC impersonation and also will allow protecting against PCE or PCC impersonation and also
against message content falsification. against message content falsification.
This requires the maintenance, exchange and configuration of MD-5 This requires the maintenance, exchange and configuration of MD-5
keys on PCCs and PCEs. Note that such maintenance may be especially keys on PCCs and PCEs. Note that such maintenance may be especially
onerous to the operators as pointed out in [BGP-SEC-REQ]. Hence it onerous to the operators as pointed out in [I-D.ietf-rpsec-
is important to limit the number of keys while ensuring the required bgpsecrec]. Hence it is important to limit the number of keys while
level of security. ensuring the required level of security.
MD-5 signature faces some limitations, as per explained in [RFC2385]. MD-5 signature faces some limitations, as per explained in [RFC2385].
Note that when one digest technique stronger than MD5 is specified Note that when one digest technique stronger than MD5 is specified
and implemented, PCEP could be easily upgraded to use it. and implemented, PCEP could be easily upgraded to use it.
12.2. PCEP Privacy 10.2. PCEP Privacy
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication end-points do not
reside in the same AS, as an attacker that intercept a PCE message reside in the same AS, as an attacker that intercept a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. Privacy can be ensured thanks to encryption. To ensure resources. Privacy can be ensured thanks to encryption. To ensure
privacy of PCEP communication, IPSec [IPSEC] tunnels MAY be used privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used
between PCC and PCEs or between PCEs. Note that this could also be between PCC and PCEs or between PCEs. Note that this could also be
used to ensure Authentication and Integrity, in which case, TCP MD-5 used to ensure Authentication and Integrity, in which case, TCP MD-5
option would not be required. option would not be required.
12.3. Protection against Denial of Service attacks 10.3. Protection against Denial of Service attacks
PCEP can be the target of TCP DoS attacks, such as for instance SYN PCEP can be the target of TCP DoS attacks, such as for instance SYN
attacks, as all protocols running on top of TCP. PCEP can use the attacks, as all protocols running on top of TCP. PCEP can use the
same mechanisms as defined in [LDP] to mitigate the threat of such same mechanisms as defined in [RFC3036] to mitigate the threat of
attacks: such attacks:
- A PCE should avoid promiscuous TCP listens for PCEP TCP session o A PCE should avoid promiscuous TCP listens for PCEP TCP session
establishment. It should use only listens that are specific to establishment. It should use only listens that are specific to
authorized PCCs. authorized PCCs.
- The use of the MD5 option helps somewhat since it prevents a SYN
from being accepted unless the MD5 segment checksum is valid.
However, the receiver must compute the checksum before it can decide
to discard an otherwise acceptable SYN segment.
- The use of access-list on the PCE so as to restrict access to
authorized PCCs.
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any o The use of the MD5 option helps somewhat since it prevents a SYN
Intellectual Property Rights or other rights that might be claimed to from being accepted unless the MD5 segment checksum is valid.
pertain to the implementation or use of the technology described in However, the receiver must compute the checksum before it can
this document or the extent to which any license under such rights decide to discard an otherwise acceptable SYN segment.
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering o The use of access-list on the PCE so as to restrict access to
Task Force (IETF), its areas, and its working groups. Note that other authorized PCCs.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six 10.4. Request input shaping/policing
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress.
14. Acknowledgment A PCEP implementation may be subject to Denial Of Service attacks
consisting of sending a very large number of PCEP messages (e.g.
PCReq messages). Thus, especially in multi-Service Providers
environments, a PCE implementation should implement request input
shaping/policing so as to throttle the amount of received PCEP
messages without compromising the implementation behavior.
We would like to thank Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin 11. Acknowledgements
for their very valuable input. Special thank to Adrian Farrel for his
very valuable suggestions.
15. References The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
Igor Bryskin for their very valuable input. Special thank to Adrian
Farrel for his very valuable suggestions.
15.1. Normative references 12. References
[RFC] Bradner, S., "Key words for use in RFCs to indicate 12.1. Normative References
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 3667, February 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Technology", BCP 79, RFC 3979, March 2005. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP] R. Braden et al., "Resource ReSerVation Protocol (RSVP) - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Version 1 Functional Specification", RFC 2205, November 1997. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
tunnels", RFC 3209, December 2001. (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[G-RSVP] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
RFC 3473, January 2003. in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RSVP-UNNUM] Kompella, K., Rekhter Y., "Signalling Unnumbered Links [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
RFC 3477, January 2003. May 2005.
[COPS] Durham, D., "The COPS (Common Open Policy Service) Protocol", 12.2. Informative References
RFC 2748, January 2000.
[SCTP] Stewart et al., "Stream Control Transmission Protocol", [I-D.ietf-ccamp-inter-domain-rsvp-te]
RFC2960, October 2000. Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in
progress), October 2005.
[TCP] J. Postel, "Transmission Control Protocol", RFC 793, November [I-D.ietf-pce-architecture]
1981. Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-04 (work in
progress), January 2006.
[DS-TE-PROTO] Le Faucheur et al,"Protocol extensions for support of [I-D.ietf-pce-comm-protocol-gen-reqs]
Differentiated-Service-aware MPLS Traffic Engineering", RFC 4124, Roux, J. and J. Ash, "PCE Communication Protocol Generic
June 2005. Requirements", draft-ietf-pce-comm-protocol-gen-reqs-04
(work in progress), February 2006.
[G-RECV-E2E-SIG] J. P. Lang et al, "RSVP-TE Extensions in support of [I-D.ietf-pce-disco-proto-igp]
End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Roux, J., "IGP protocol extensions for Path Computation
Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Element (PCE) Discovery",
(working in progress). draft-ietf-pce-disco-proto-igp-00 (work in progress),
November 2005.
[FRR] P. Pan, G. Swallow, A. Atlas, JP. Vasseur, M. Jork, D.H Gan and [I-D.ietf-pce-discovery-reqs]
D. Cooper, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Roux, J., "Requirements for Path Computation Element (PCE)
RFC4090, May 2005. Discovery", draft-ietf-pce-discovery-reqs-03 (work in
progress), February 2006.
15.2 Informative References [I-D.ietf-pce-inter-layer-req]
Oki, E., "PCC-PCE Communication Requirements for Inter-
Layer Traffic Engineering",
draft-ietf-pce-inter-layer-req-01 (work in progress),
March 2006.
[WP] E. Rescorla, "Writting Protocol Models", RFC 4101, June 2005. [I-D.ietf-pce-pcecp-interarea-reqs]
Roux, J., "PCE Communication Protocol (PCECP) Specific
Requirements for Inter-Area (G)MPLS Traffic Engineering",
draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress),
February 2006.
[PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, "Path Computation [I-D.ietf-rpsec-bgpsecrec]
Element (PCE) Architecture", draft-ietf-pce-arch, work in Christian, B. and T. Tauber, "BGP Security Requirements",
progress. draft-ietf-rpsec-bgpsecrec-03 (work in progress),
October 2005.
[PCE-GEN-COM-REQ] J. Ash, J.L Le Roux et al., "PCE Communication [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen- April 1992.
reqs, work Progress.
[GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- Signature Option", RFC 2385, August 1998.
gmpls-routing, work in progress.
[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al, [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
"Requirements for inter-area MPLS Traffic Engineering", RFC4105, June Payload (ESP)", RFC 2406, November 1998.
2005.
[INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work B. Thomas, "LDP Specification", RFC 3036, January 2001.
in progress.
[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and
Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf- T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric
ccamp-inter-domain-framework, work in progress. as a second MPLS Traffic Engineering (TE) Metric", BCP 87,
RFC 3785, May 2004.
[MGT] A. Farrel et al., "Requirements for Manageability Sections in [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
Routing Area Drafts", draft-farrel-rtg-manageability-requirements, June 2005.
work in progress.
[XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", drfat-ietf- Appendix A. Proposed Status and Discussion [To Be Removed Upon
ccamp-rsvp-te-exclude-route, work in progress. Publication]
[PCE-DISC-REQ] JL Le Roux et al., "Requirements for Path Computation This Internet-Draft is being submitted for eventual publication as an
Element (PCE) Discovery", draft-ietf-pce-discovery-reqs, work in RFC with a proposed status of Standard. Discussion of this proposal
progress. should take place on the following mailing list: pce@ietf.org.
[BGP-SEC-REQ] B. Christian Ed., "BGP Security Requirements", Appendix B. PCEP Variables
draft-ietf-rpsec-bgpsecrec, work in progress
[LDP] L. Andersson, et al., "LDP Specification", RFC3036, January PCEP defines variable that can be configured. The following PCEP
2001 variables are defined.
[DOBB] H. Dobbertin, "The Status of MD5 After a Recent Attack", KeepAlive timer: minimum period of time between the sending of PCEP
RSALabs' CryptoBytes, Vol. 2 No. 2, Summer 1996. messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A
suggested value for the Keepalive timer is 30 seconds.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",RFC 1321, DeadTimer: period of timer after the expiration of which a PCEP peer
April 1992. declared the session down if no PCEP message has been received.
[IPSEC] S. Kent, A. Atkinson, " IP Encapsulating Security Payload SyncTimer: the SYNC timer is used in the case of synchronized path
(ESP)", RFC2406, November 1998 computation request using the SVEC object defined in Section 7.12.3.
Consider the case where a PCReq message is received by a PCE that
comprises the SVEC object referring to M synchronized path
computation requests. If after the expiration of the SYNC timer all
the M path computation requests have not been received, a protocol
error is triggered and the PCE MUST cancel the whole set of path
computation requests. A RECOMMENDED value for the SYNC timer is 60
seconds.
16. Authors' Address Authors' Addresses
Jean-Philippe Vasseur (Editor) JP Vasseur (editor)
Cisco Systems, Inc. Cisco Systems, Inc
300 Beaver Brook Road 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Jean-Louis Le Roux JL Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, Avenue Pierre-Marzin
22307 Lannion Cedex Lannion, 22307
FRANCE FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
E-mail: arthi@juniper.net
Email: arthi@juniper.net
Eiji Oki Eiji Oki
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585 Musashino, Tokyo, 180-8585
JAPAN JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Alia K. Atlas Alia Atlas
Google Inc. Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Montain View, CA 94043
EMail: akatlas@alum.mit.edu USA
Email: akatlas@alum.mit.edu
Andrew Dolganow Andrew Dolganow
Alcatel Alcatel
600 March Rd., K2K 2E6 Ottawa, ON, Canada 600 March Road
Phone: +1 (613)784 6285 Ottawa, ON K2K 2E6
CANADA
Email: andrew.dolganow@alcatel.com Email: andrew.dolganow@alcatel.com
Yuichi Ikejiri Yuichi Ikejiri
NTT Communications Corporation NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku 1-1-6 Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019 Tokyo, 100-819
JAPAN JAPAN
Email: y.ikejiri@ntt.com Email: y.ikejiri@ntt.com
Appendix A - Compliance of PCEP to the set of requirements specified
in draft-ietf-pce-comm-protocol-gen-reqs
[PCE-GEN-COM-REQ] lists a set of requirement for the PCE Kenji Kumaki
communication protocol. The aim of the appendix A is to list the KDDI Corporation
compliance of PCEP to such requirements. Note that requirements that Garden Air Tower Iidabashi, Chiyoda-ku,
are not satisfied in the context of the present version may be Tokyo, 102-8460
satisfied in further revisions. JAPAN
The following legend is used in the table below: Email: ke-kumaki@kddi.com
YES: PCEP fully fulfills the requirement Intellectual Property Statement
ME (Minor Extension): PCEP could satisfy the requirement with minor
extension(s).
SE (Substantial Extension): PCEP could satisfy the requirement with
substantial extension(s).
NO: PCEP cannot meet the requirement without substantial redesign of
the protocol.
Requirement Necessity Compliance The IETF takes no position regarding the validity or scope of any
------------------------------------------------------------------ Intellectual Property Rights or other rights that might be claimed to
Commonality of PCC-PCE and PCE-PCE Communication MUST YES pertain to the implementation or use of the technology described in
Client-Server Communication MUST YES this document or the extent to which any license under such rights
Support PCC/PCE request message to request path might or might not be available; nor does it represent that it has
computation MUST YES made any independent effort to identify any such rights. Information
Support PCE response message with computed path MUST YES on the procedures with respect to rights in RFC documents can be
Support unsolicited communication PCE-PCC MUST YES found in BCP 78 and BCP 79.
Maintain PCC-PCE session NON-RQMT
Use of Existing Transport Protocol MAY YES
Transport protocol satisfy reliability & security
requirements MAY YES
Transport Protocol Limits Size of Message MUST NOT YES
Support Path Computation Requests MUST YES
Include source & destination
Support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST YES
Support path reoptimization & inclusion of a
previously computed path MUST YES
Allow to select/prefer from advertised list of
standard objective functions/options MUST ME
Allow to customize objective function/options MUST ME
Request a less-constrained path MAY ME
Support request for less-constrained path,
including constraint-relaxation policy's SHOULD ME
Support Path Computation Responses MUST YES
Negative response support reasons for failure,
constraints to relax to achieve positive result,
less-constrained path reflecting
constraint-relaxation policy's SHOULD ME
Cancellation of Pending Requests MUST YES
Multiple Requests and Responses MUST YES
Limit by configuration number of requests within
a message MUST YES
Support multiple computed paths in response MUST YES
Support "continuation correlation" where related
requests or computed paths cannot fit within one
message MUST YES
Maximum message size & maximum number of requests
per message exchanged through PCE messages to PCC,
or indicated in request message MAY ME
Reliable Message Exchange (achieved by PCEP
itself or transport protocol MUST YES
Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCEP MUST ME
Handle overload situations without significant
decrease in performance, e.g., through throttling
of requests MUST YES
Provide acknowledged message delivery with
retransmission, in order message delivery or
facility to restore order, message corruption
detection, flow control & back-pressure to
throttle requests, rapid partner failure
detection, informed rapidly of failure of PCE-PCC
connection MUST YES
Functionality added to PCEP if transport protocol
provides it SHOULD NOT N/A
Secure Message Exchange (provided by PCEP or
transport protocol MUST YES
Support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption),
DOS attacks MUST YES
Request Prioritization MUST YES
Unsolicited Notifications SHOULD YES
Allow Asynchronous Communication MUST YES
PCC Has to Wait for Response Before Making
Another Request MUST NOT YES
Allow order of responses differ from order of
Requests MUST YES
Communication Overhead Minimization SHOULD YES
Give particular attention to message size SHOULD
Extensibility without requiring modifications to
the protocol MUST YES
Easily extensible to support intra-area,
inter-area, inter-AS intra provider, inter-AS
inter-provider, multi-layer path & virtual network
topology path computation MUST YES
Easily extensible to support future applications
not in scope (e.g., P2MP path computations) SHOULD YES
Scalability at least linearly with increase in
number of PCCs, PCEs, PCCs communicating with a
single PCE, PCEs communicated to by a single PCC,
PCEs communicated to by another PCE, domains, path
requests, handling bursts of requests MUST YES
Support Path Computation Constraints MUST ME
Support Different Service Provider Environments
(e.g., MPLS-TE and GMPLS networks, centralized &
distributed PCE path computation, single &
multiple PCE path computation) MUST YES
Policy Support for policies to accept/reject
requests, PCC to determine reason for rejection,
notification of policy violation MUST ME
Aliveness Detection of PCCs/PCEs, partner failure
Detection MUST YES
PCC/PCE Failure Response procedures defined for
PCE/PCC failures, PCC able to clear pending
Request MUST YES
PCC select another PCE upon detection of PCE
failure MUST YES
PCE able to clear pending requests from a PCC
(e.g. when it detects PCC failure or request
buffer full) MUST YES
Protocol Recovery support resynchronization of
information & requests between sender & receiver MUST ME
Minimize repeat data transfer, allow PCE to
respond to computation requests issued before
failure without requests being re-issued SHOULD ME
Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD SE
Full Copyright Statement Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Copyright (C) The Internet Society (2005). The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
This document is subject to the rights, licenses and restrictions Disclaimer of Validity
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 373 change blocks. 
1409 lines changed or deleted 1386 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/