One document matched: draft-vasseur-pce-pcep-01.txt
Differences from draft-vasseur-pce-pcep-00.txt
Network Working Group JP Vasseur (Editor)
Cisco System Inc.
IETF Internet Draft JL Le Roux
France Telecom
Arthi Ayyangar
Juniper Networks
Eiji Oki
NTT
Alia Atlas
Google, Inc
Proposed Status: Standard
Expires: January 2006 July 2005
Path Computation Element (PCE) communication Protocol (PCEP) - Version 1
draft-vasseur-pce-pcep-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Vasseur et al. [Page 1]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Abstract
This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs. Such
interactions include path computation requests and path computation
replies as well as notifications of specific states related to the
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
easily allow for the addition of further messages and objects, should
further requirements be expressed in the future.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Terminology.....................................................3
2. Introduction....................................................4
3. Assumptions.....................................................4
4. Transport protocol..............................................5
5. Architectural Protocol Overview (Model).........................5
5.1. Problem.......................................................5
5.2. Architectural Protocol Overview...............................5
5.2.1. Initiation phase............................................7
5.2.2. Parameter negotiation.......................................7
5.2.3. Path computation request sent by a PCC to a PCE.............7
5.2.4. Path computation reply sent by the PCE to a PCC.............7
5.2.5. Notifications...............................................8
6. PCEP messages...................................................9
6.1. Common header.................................................9
6.2. Path Computation Request (PCReq) message.....................10
6.3. Path Computation Reply (PCRep) message.......................11
6.4. Notification (PCNtf) message.................................12
6.5. Error (PCErr) message........................................13
7. Object Formats.................................................13
7.1. Common object header.........................................13
7.2. REQUEST-ID Object............................................15
7.3. NO-PATH Object...............................................17
7.4. END-POINTS Object............................................18
7.5. BANDWIDTH object.............................................19
7.6. DELAY Object.................................................20
7.7. IRO Object...................................................21
7.8. CVEC Object..................................................22
7.9. NOTIFICATION object..........................................23
7.10. PCEP-ERROR object...........................................26
7.11. Carrying other protocol objects in PCEP message using the..
ENCAP object..................................................... 28
8. Independent versus correlated path computation requests........30
Vasseur et al. [Page 2]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
9. Elements of procedure..........................................32
9.1. REQUEST-ID object............................................32
9.2. BANDWDITH object.............................................32
9.3. DELAY object.................................................33
9.4. XRO object...................................................33
9.5. IRO object...................................................33
9.6. CVEC object..................................................33
10. Open issues...................................................34
11. Manageability Considerations..................................35
12. IANA Considerations...........................................35
12.1. TCP port....................................................35
12.2. PCEP Objects................................................35
12.3. Notification................................................37
12.4. PCEP Error..................................................37
13. Security Considerations.......................................38
13.1. PCEP Authentication and Integrity...........................38
13.2. PCEP Privacy................................................38
13.3. Protection against Denial of Service attacks................39
14. Intellectual Property Statement...............................39
15. Acknowledgment................................................40
16. References....................................................40
16.1. Normative references........................................40
16.2. Informative References......................................41
17. Authors' Addresses............................................42
1. Terminology
Terminology used in this document
IGP Area: OSPF Area or IS-IS level
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).
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.
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.
Vasseur et al. [Page 3]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Strict/loose path: mix of strict and loose hops comprising of at
least one loose hop representing the destination where a hop may be
an abstract node such as an AS.
Within this document, when PCE-PCE communications are being
described, the requesting PCE fills the role of PCC. This provides a
saving in documentation without loss of function.
2. Introduction
[PCE-ARCH] describes the motivations and architecture for a PCE-based
model to perform path computation for MPLS and GMPLS TE LSPs. The
model allows the separation of PCE from PCC, and allows cooperation
between PCEs. This necessitates a communications protocol between PCC
and PCE, and between PCEs.
[PCE-COM-GEN-REQ] states the generic requirements for such a protocol
including a requirement that the same protocol must be used between
PCC and PCE, and between PCEs. Additional application-specific
requirements (for scenarios such as inter-area, inter-AS, etc.) are
not included in [PCE-COM-GEN-REQ], but there is a requirement that
any solution protocol must be easily extensible to handle other
requirements as they are introduced in application-specific
requirements documents.
This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between Path Computation Client
(PCC) and a Path Computation Element (PCE),or between two PCEs. Such
interactions include path computation requests and path computation
replies as well as notifications of specific states related to the
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
easily allow for the addition of further messages and objects, should
further requirements be expressed in the future.
The PCEP protocol meets the requirements stated in [PCE-COM-GEN-REQ].
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.
Moreover, it is assumed that the PCE gets the required information so
as to perform TE LSP path computation which usually requires network
topology and resource information that can be gathered by routing
protocols or by some other means. The retrieval of such information
is out of the scope of this document.
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
dynamic discovery) and select a PCE to send it(s) request(s) to. For
Vasseur et al. [Page 4]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
the sake of reference [PCE-DISC-REQ] defines a list of requirements
for dynamic PCE discovery.
4. Transport protocol
PCEP operates over TCP using the well-known TCP port (TBD by IANA).
This allows the requirements of reliable messaging and flow control
to be met without further protocol work.
An implementation may either decide to keep the TCP session alive for
an unlimited time, should it have to send a new requests later on (in
which case the TCP session will already be in place). This mode is
also referred to as the 'Permanent mode'. Conversely, in some other
circumstances, it may be desirable to systematically open and close
the TCP session for each PCEP request (this is for instance the case
if the sending of PCEP message 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.
PCE Working Group feedbacks are requested to determine whether PCEP
should support the two modes or just the 'permanent mode': see the
'open issues' section.
5. Architectural Protocol Overview (Model)
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
the protocol) is provided in this section where details of the
protocol can be found in further sections.
5.1. Problem
The PCE-based architecture used for the computation of MPLS and GMPLS
TE LSP paths has been described in [PCE-ARCH]. When the PCC and the
PCE are not collocated, this requires a communication protocol
between the PCC and the PCE. PCEP is such a protocol specified for
communications between a PCC and a PCE or between two PCEs: a PCC may
use PCEP to send a path computation request for one or more TE LSP(s)
to a PCE and such PCE may reply with a set of computed path(s) if one
or more path(s) obeying the set of constraints or less-constrained
path(s) can be found.
5.2. Architectural Protocol Overview
PCEP operates over TCP, which allows the requirements of reliable
messaging and flow control to be met without further protocol work.
Several PCEP messages are defined:
Vasseur et al. [Page 5]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
- PCReq: message sent by a PCC to a PCE to request a path
computation.
- PCRep: message sent by a PCE to a PCC in reply to a path
computation request. A PCRep message can either contain a set of
computed path(s) if the request could be successfully satisfied or a
negative reply otherwise, potentially with a set of less-constrained
path(s).
- PCNtf: notification message either sent by a PCC to a PCE or a PCE
to a PCC to notify of specific event.
- PCErr: message related to a protocol error condition.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
requested | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request sent to | |4) Path computation
the selected PCE | |triggered
| |
| |Path successfully computed
| |
| |5) Computed path(s) sent
| |to the PCC
|<--- PCRep message ---|
| (Positive reply) |
Figure 1: Path computation request with successful computation
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
requested | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request sent to | |4) Path computation
the selected PCE | |triggered
| |
| |No Path found that
| |satisfies the request
| |
| |5) Negative reply sent to
| |the PCC (optionally with
| |various additional
| |information including
|<--- PCRep message ---|less-constrained path)
| (Negative reply) |
Figure 2: Path computation request with unsuccessfully computation
Vasseur et al. [Page 6]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
5.2.1 Initiation phase
The Initiation phase consists of establishing the TCP session (3-way
handshake) between the PCC and the PCE, initialized by the PCC or the
PCE. As already pointed out, the set of available PCE(s) may be
either statically configured on a PCC or dynamically discovered. Note
that a PCC may have PCEP sessions with more than one PCE and
similarly a PCE may have PCEP sessions with multiple PCCs. A PCEP
session establishment can either be triggered by the PCC or the PCE.
5.2.2 Parameter negotiation
The Working Group has been polled to get some input on the need for a
parameters negotiation phase. See the 'Open Issues' section.
5.2.3 Path computation request sent by a PCC to a PCE
Consider the diagram depicted in figure 1. Once a PCC (or a PCE) has
established a TCP session using the well-known TCP port 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 send a path
computation request to. Once a PCC has selected a PCE, the PCC 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, whether the PCC is interested
in a less-constrained path (should no path satisfying all the
constraint be found by the PCE) and so on. It is worth pointing out
that each request is uniquely identified by a request-id number and
the PCC-PCE address pair. The process is shown in a schematic form in
figure 1.
5.2.4 Path computation reply sent by the PCE to a PCC
Upon receiving a path computation request from a PCC, the PCE
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).
- Negative: no path could be computed that satisfies the request. In
this case, the protocol allows a PCC to specify its desire to receive
a less-constrained path. If supported by the PCE, such less-
constrained computed path may be included in the negative reply along
with the corresponding path attributes. Upon receiving a negative
reply, a PCC may decide to resend a modified request or take any
other appropriate action.
Vasseur et al. [Page 7]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
5.2.5. Notifications
There are several circumstances whereby a PCE may want to notify a
PCC of a specific event. For example, suppose that the PCE suddenly
experiences some congestion that would lead to unacceptable response
times. The PCE may want to notify one or more PCC that some of their
requests (listed in the notification) will not be satisfied,
potentially resulting in path computation redirections on the PCC
towards another PCE, if an alternate PCE is present. Similarly, a PCC
may desire to notify a PCE of particular event such as the
cancellation of pending request(s).
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
requested | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | |triggered
| |
| |
5) Path computation| |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| |request X cancelled
Figure 3: Example of PCC notification (request cancellation) sent to
a PCE
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
requested | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | |triggered
| |
| |
| |5) PCE experiencing
| |congestion
| |
| |6) Path computation
| |request X cancelled
| |
|<--- PCNtf message----|
Vasseur et al. [Page 8]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Figure 4: Example of PCEP notification (request(s) cancellation) send
to a PCC
6. PCEP messages
A PCEP message consists of a common header followed by a variable
length body made of a set of objects which can either be mandatory or
optional. For each PCEP message type a set of rules is defined which
specifies the set of possible objects that it can carry. We use the
Backus-Naur Form (BNF) to specify such rules. Square brackets refer
to optional sub-sequences. An implementation MUST form the PCEP
messages using the order specified in this document.
If a mandatory object is missing in a PCEP message as defined in this
document a protocol error condition MUST be triggered by the
recipient of the PCEP message.
6.1. Common header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PCEP message common header
Ver (Version): 4 bits
PCEP protocol version number. The current version is version 1
Flags: 4 bits
No Flag is currently defined
Message Length: 24 bits
Total length of the PCEP message expressed in bytes including
the common header.
Message-Type: 8 bits
The following message types are currently defined:
1: Path Computation Request
2: Path Computation Reply
3: Notification
4: Error
Vasseur et al. [Page 9]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
6.2. Path Computation Request (PCReq) message
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
computation. The Message-Type field of the PCEP common header is set
to 1.
There are several mandatory objects that MUST be included within a
PCReq message: the REQUEST-ID, the END-POINTS, the BANDWIDTH and the
SESSION-ATTRIBUTE objects (see section 7). If one of these objects is
missing, the receiving PCE MUST return an error message to the
requester (PCErr message). Other objects are optional.
The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header>
[<cvec-list>]
<request-list>
where:
<cvec-list>::=<CVEC>[<cvec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <REQUEST-ID>
<END-POINTS>
<SESSION-ATTRIBUTE>
<BANDWIDTH>
[<GENERALIZED LABEL REQUEST>]
[<CLASSTYPE>]
[<DELAY>]
[<ERO>]
[<XRO>]
[<IRO>]
[<PROTECTION>]
[<ENCAP>]
Definition of the objects listed above:
Objects name Reference
<REQUEST-ID>
<END-POINTS>
<BANDWIDTH>
<CVEC>
<DELAY>
<IRO> Section 7 of this document
<ENCAP>
Note that the following objects are RSVP objects encapsulated in the
PCEP ENCAP object defined in section 7.11. For the sake of clarity,
the PCEP ENCAP object that carries an RSVP object X is simply
Vasseur et al. [Page 10]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
referred to as the PCEP object X. For example, when the PROTECTION
object is carried within the ENCAP object, the PCEP object is simply
called PROTECTION object.
<SESSION-ATTRIBUTE>
<ERO> [RSVP-TE]
<GENERALIZED LABEL REQUEST> [G-RSVP]
<PROTECTION> [G-RECV-E2E-SIG].
<CLASSTYPE> [DS-TE-PROTO]
<XRO> [XRO]
6.3. Path Computation Reply (PCRep) message
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
previously received PCReq message. The Message-Type field of the PCEP
common header is set to 2.
The PCRep message MUST comprise a REQUEST-ID object with a Request-
ID-number identical to the one specified in the REQUEST-ID object
carried in the corresponding PCReq message (see section 7 for the
definition of the REQUEST-ID object).
A PCRep may comprise multiple computed path(s) corresponding to
multiple path computation requests originated by a common requesting
PCC. The bundling of multiple responses within a single PCRep message
is permitted by the PCEP protocol. If a PCE receives non correlated
path computation requests by means of one or more PCReq messages from
a requesting PCC it may decide to bundle the computed paths within a
single PCRep message so as to reduce the control plane load. Note
that the counter side of such approach is the introduction of
additional delays for some path computation requests of the set.
If the path computation request can be successfully satisfied (the
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
object(s) is inserted in the PCRep message. Such a situation where
multiple computed paths are provided in a PCRep message is discussed
in detail in section 8.
If the path computation request cannot be satisfied, the PCRep
message MUST include a NO-PATH object. The NO-PATH object (further
described in section 7.3) may also comprise other information (e.g
reasons for the path computation failure, suggested constraints
values for which a path could be found).
In some circumstances (further discussed in section 7), the
requesting PCC has the ability to specify in its path computation
Vasseur et al. [Page 11]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
requests its interest in less-constrained path, should no path fully
satisfying the set of requested constraints be found. If the path
computation request cannot be (fully) satisfied and if the requesting
PCC notified its interest to receive less-constrained paths then the
PCE MAY insert in its reply a less-constrained computed path along
with the corresponding attributes.
The format of a PCRep message is as follows:
<PCRep Message> ::= <Common Header>
[<cvec-list>]
<path-list>
where:
<cvec-list>::=<CVEC>[<cvec-list>]
<path-list>::=<path>[<path-list>]
<path>::=<REQUEST-ID>
[<NO-PATH>]
[<ero-list>]
[<SESSION-ATTRIBUTE>]
[<BANDWIDTH>]
[<DELAY>]
[<XRO>]
[<IRO>]
[<PROTECTION>]
where:
<ero-list>:==<ERO>[<ero-list]>
6.4. Notification (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
notify of a specific event. The Message-Type field of the PCEP common
header is set to 3.
The PCNtf message MUST carry at least one NOTIFICATION object and may
comprise several NOTIFICATION objects, should the PCE or the PCC
intend to notify of multiple events. The NOTIFICATION object is
defined in section 7. The PCNtf message may also comprise a REQUEST-
ID object when the notification refers to a particular path
computation request.
The PCNtf message may be sent by a PCC or a PCE in response to a
request or in an unsolicited manner.
The format of a PCNtf message is as follows:
<PCNtf Message>::=<Common Header>
<notify-list>
Vasseur et al. [Page 12]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
<notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>]
<notification-list>
<request-id-list>:==<REQUEST-ID><request-id-list>
<notification-list>:=<NOTIFICATION><notification-list>
The procedure upon the reception of a PCNtf message is defined in
section 9.
6.5. Error (PCErr) message
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
PCEP common header is set to 4.
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
message MUST include the set of REQUEST-ID objects related to the
pending path computation request(s) which triggered the protocol
error condition. In the later case (unsolicited), no REQUEST-ID is
inserted within the PCErr message. A PCErr message MUST comprise a
PCEP-ERROR object specifying the PCEP error condition. The PCEP-ERROR
object is defined in section 7.
The format of a PCErr message is as follows:
<PCErr Message> ::= <Common Header>
<error-list>
<error-list>:==<error>[<error-list>]
<error>::=[<request-id-list>]
<error-obj-list>
<request-id-list>:==<REQUEST-ID>[<request-id-list>]
<error-obj-list>:==<PCEP-ERROR>[<error-obj-list>]
The procedure upon the reception of a PCErr message is defined in
section 9.
7. Object Formats
7.1. Common object header
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:
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
Vasseur et al. [Page 13]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | Object-Type |PR | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length (bytes) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PCEP common object header
Object-Class (to be managed by IANA)
8-bit field that identifies the PCEP object class
Object-Type (to be managed by IANA)
8-bit field that identifies the PCEP object type
PR (Processing-Rule)
2-bit flag which specifies whether the object is mandatory or
optional. When set to 0, the object is mandatory. When set to 1,
the object is optional.
Object Length
16-bit field containing the total object length in bytes. The
Object Length field MUST always be a multiple of 4, and at least
8.
The maximum object content length is 65528 bytes. The Object-Class
and Object-Type fields uniquely identify each PCEP object.
The PR flag is used to determine what action a node should take if it
does not recognize the Object-Class of a PCEP object: there are two
possible ways that a PCEP implementation can react to a received PCEP
object with an unknown Object-Class. This choice is determined by the
PR flag, as follows.
If PR flag=0 (Mandatory object)
The entire PCEP message should be rejected and an "Unknown Object-
Class" error returned in a PCErr message.
If PR flag=1 (Optional object)
The node should ignore the object and process the PCEP message if
possible. In that case, the PCE should send a PCNtf message prior to
sending its PCRep message containing the computed path(s) so as to
notify the requesting PCC of the list of objects that were ignored
Vasseur et al. [Page 14]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
during path computation because they were not recognized. If the path
computation cannot be performed, a PCErr message must be sent to the
requesting entity with an 'Unknown Object-Class' error.
7.2. REQUEST-ID Object
The REQUEST-ID object MUST be carried within every PCReq and PCRep
messages and MAY be carried within PCNtf and PCErr messages.
REQUEST-ID Object-Class is to be assigned by IANA (recommended
value=1)
REQUEST-ID Object-Type is to be assigned by IANA (recommended
value=1)
The PR flag of the REQUEST-ID object MUST be set to 0. Consequently,
as described in section 7.1, a PCE receiving a PCEP message that does
not support the REQUEST-ID object MUST trigger a protocol error and
return a PCErr message to the requesting PCC.
The format of the REQUEST-ID object body is as follows:
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 |O|C|B|R|L| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: REQUEST-ID object body format
The REQUEST-ID object has a variable length and may contain
additional TLVs. No TLV is currently defined.
Flags: 18 bits - The following flags are currently defined:
Pri (Priority) field (3 bits)
This field may be used by the requesting PCC to specify to the
PCE the request's priority. The decision of which priority
should be used for a specific request is of a local matter and
MUST be set to 0 when unused. In particular, the priority may or
may not be correlated to the TE LSP priority used for setup. For
example, a path computation request related to the computation
of a TE LSP path of priority n which is in a down state may have
a higher path computation priority than the path computation
request for the reoptimization of a TE LSP of priority n-1
(although a higher numerical value of the TE LSP priority
reflect a lower priority). Furthermore, the use of the path
computation request priority by the PCE's requests scheduler is
Vasseur et al. [Page 15]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
implementation specific and out of the scope of this document.
Note that it is not required for a PCE to support the priority
field: in that case, the priority field SHOULD be set to 0 by
the PCC in the REQUEST-ID object. If the PCE does not take into
account the request priority, it is RECOMMENDED to set the
priority field to 0 in the REQUEST-ID object carried within the
corresponding PCRep message, regardless of the priority value
contained in the REQUEST-ID object carried within the
corresponding PCReq message. A 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 manner across the various
PCC(s). The ability of a PCE to support requests prioritization
may be dynamically discovered by the PCC(s) by means of PCE
capability discovery. If not advertised by the PCE, a PCC may
decide to set the request priority and will learn the ability of
the PCE the support request prioritization by observing the
Priority field of the REQUEST-ID object received in the PCRep
message. If the value of the Pri field is set to 0, this means
that the PCE does not support the Pri field: in other words, the
path computation request has been honoured but without taking
into account any priority.
L (Less-constrained path) bit: when set in the PCReq message,
the requesting PCC indicates to the PCE that a less-constrained
path is of interest, should no path satisfying the full set of
constraints be found by the PCE. If set in a PCRep message,
this indicates that the requesting PCC has expressed an interest
in less-constrained path and that the PCE was capable of
computing less-constrained path(s) provided in the PCRep
message. Note that further extensions of the PCEP protocol may
allow for the support of hierarchical constraints relaxation
policy whereby the requesting PCC may be able to indicate a
preference order in which constraints may be relaxed in its path
computation request. This is discussed in the 'Open issues'
section.
R (Reoptimization) bit: when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an
existing TE LSP in which case the path of the existing TE LSP to
be reoptimized MUST be provided in the PCReq message by means of
an RRO object as defined in [RSVP-TE].
B (Bi-directional) bit: when set, the PCC specifies that the
path computation request relates to a bidirectional TE LSP (LSPs
that have the same traffic engineering requirements including
fate sharing, protection and restoration, LSRs, and resource
requirements (e.g., latency and jitter) in each direction). When
cleared, the TE LSP is unidirectional.
C (Cost) bit: when set, the PCE MUST provide the cost of the
path in the PCRep message as computed by the PCE.
Vasseur et al. [Page 16]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
O (strict/lOose): In a PCReq message, when set, this means 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 set to
1), the returned path is explicit.
Request-ID-number: 32 bits
This value (combined with the source IP address of the PCC)
uniquely identifies the Path Computation Request context and
MUST be incremented each time a new request is sent to the PCE.
If no path computation reply is received from the PCE, and the
PCC 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 sent to different PCEs. The path computation reply
is unambiguously identified by the IP source address of the
replying PCE.
7.3. NO-PATH Object
When a PCE cannot find a path satisfying a set of constraints, it
MUST include a NO-PATH object in the corresponding PCRep message. In
its simplest form, the NO-PATH object is limited to a set of flags
and just reports the impossibility to find a path that satisfies the
constraint. If the PCC has expressed an interest in less-constraint
path and the PCE has such capability, the PCRep message MAY also
comprise a list of objects that specify the set of unsatisfied
constraints along with suggested values (if supported by the PCE) and
corresponding less constrained path(s). When an object specifies a
variety of constraints, the set of unsatisfied constraints (along
with their potentially suggested values) can be unambiguously
determined by the PCC after a simple comparison with the original
requested constraints.
NO-PATH Object-Class is to be assigned by IANA (recommended value=2)
NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the NO-PATH object MUST be set to 0. Consequently, as
described in section 7.1, a PCC receiving a PCEP message that does
not support the NO-PATH object MUST trigger a protocol error and
return a PCErr message to the sending PCE.
The format of the NO-PATH object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur et al. [Page 17]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Figure 8: NO-PATH object format
The NO-PATH object has a fixed length of 4 octets.
Flags: 16 bits - The following flags are currently defined:
C bit: when set, this indicates that the set of unsatisfied
constraints (reasons why a path could not be found) is specified in
the PCRep message by means of the relevant PCEP objects. When
cleared, no reason is specified.
S bit: when set, this indicates that the PCE supports the ability to
suggest values for the set of unsatisfied constraint(s) and provides
such information in its reply. In this case, the PCRep message
contains a set of objects that specifies the list of unsatisfied
constraints with suggested values. When cleared, the PCE just
specifies the set of unsatisfied constraints with no suggested
values. The S bit MUST be cleared if the L bit of the received
REQUEST-ID object is cleared. The S bit MUST be set if and only if
the C bit is also set.
Additionally, the less-constrained computed path is also included in
the PCRep message.
For example, consider the case of a PCC that sends a path computation
request to a PCE for a TE LSP path of X MBits/s and indicates its
interest in less-constrained path, should the request not be
satisfied. Suppose that PCE cannot find a path for X MBits/s but a
path for Y Mbits/s (with Y<X) could be found.
In this case, the PCE includes in its path computation reply a NO-
PATH object with the C and S flag set. In addition, the PCRep message
carries the BANDWIDTH object and the bandwidth field value is equal
to Y. The corresponding ERO is included in the PCRep message.
When the NO-PATH object is absent from a PCRep message, the path
computation request has been fully satisfied and the corresponding
path(s) is/are provided in the PCRep message.
7.4. END-POINTS Object
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
which a path computation is requested. Two END-POINTS objects (for
IPv4 and IPv6) are defined.
END-POINTS Object-Class is to be assigned by IANA (recommended
value=3)
END-POINTS Object-Type is to be assigned by IANA (recommended
value=1 for IPv4 and 2 for IPv6)
Vasseur et al. [Page 18]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
The PR flag of the END-POINTS object MUST be set to 0. Consequently,
as described in section 7.1, a PCE receiving a PCEP message that does
not support the END-POINTS object MUST trigger a protocol error and
return a PCErr message to the requesting PCC.
The format of the END-POINTS object body for IPv4 (Object-Type=1) is
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: END-POINTS object body format for IPv4
The format of the END-POINTS object for IPv6 (Object-Type=2) is as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: END-POINTS object body format for IPv6
7.5. BANDWIDTH object
The BANDWIDTH object is optional and can be used to specify the
requested bandwidth and may be carried within PCReq and PCRep
messages. The absence of the BANDWIDTH object MUST be interpreted by
the PCE as a path computation request related to a 0 bandwidth TE
LSP.
When carried within a PCReq message, the BANDWIDTH object specifies a
bandwidth constraint that must be satisfied by the computed path(s).
In a PCRep message, the BANDWIDTH object indicates the bandwidth of
the computed path(s) or a suggested bandwidth constraint for which a
less-constrained path has been computed (if supported by the PCE and
the PCC has expressed an interest in less-constrained path). When
Vasseur et al. [Page 19]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
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
value=4)
BANDWIDTH Object-Type is to be assigned by IANA (recommended
value=1)
The PR flag of the BANDWIDTH object MUST be set to 0.
The format of the BANDWIDTH object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: BANDWIDTH object body format
Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in
IEEE floating point format, expressed in bytes per second.
7.6. DELAY Object
The DELAY object is optional and can be used to specify a strict
delay constraint for the TE LSP. 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, the DELAY object indicates the delays of the computed
path(s) or a suggested delay constraint for which a less-constrained
path has been computed.
DELAY Object-Class is to be assigned by IANA (recommended value=5)
DELAY Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the DELAY object MUST be set to 1 when the support of
the constraint is mandatory and to 0 when optional
The format of the DELAY object body is as follows:
0 1 2 3
Vasseur et al. [Page 20]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: DELAY object body format
Delay: 32 bits. The requested delay constraint is encoded in 32 bits
in IEEE floating point format, expressed in milliseconds.
7.7. IRO Object
The IRO (Include Route Object) object is optional and can be used to
specify that the computed path must traverse a set of specified
network elements. The IRO object may be carried within PCReq and
PCRep messages.
IRO Object-Class is to be assigned by IANA (recommended value=6)
IRO Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the IRO object MUST be set to 1 when the support of
the constraint is mandatory and to 0 when optional.
0 1 2 3
0 1 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IRO object body format
Subobjects
The IRO object is made of sub-object(s) identical to the ones defined
in [RSVP-TE] and [G-RSVP] for use in EROs.
The following subobject types are supported:
Type Subobject
1 IPv4 Prefix
2 IPv6 Prefix
4 Unnumbered Interface ID
32 Autonomous System Number
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.
Vasseur et al. [Page 21]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
7.8. CVEC Object
Section 8 details the circumstances where it may be desirable and/or
required to correlate several path computation requests. This leads
to the specification of the CVEC object (Correlation VECtor). The
CVEC object is optional in a PCEP message.
The aim of the CVEC object carried within a PCReq message is to
specify the correlation of M path computation requests. The CVEC
object is a variable length object that lists the set of M requests
the computation of which MUST be correlated. Each path computation
request is uniquely identified by the Request-ID-number carried
within the respective REQUEST-ID object. The CVEC object also
contains a set of flags that specify the correlation type.
The CVEC object is carried within PCReq messages.
CVEC Object-Class is to be assigned by IANA (recommended value=7)
CVEC Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the CVEC object MUST be set to 0. One Object-Type is
defined for this object to be assigned by IANA with a recommended
value of 1.
The format of the CVEC object body is as follows:
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 |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| REQUEST-ID Object #1 |
| |
// //
| REQUEST-ID Object #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: CVEC body object format
Flags
Defines the correlation type between multiple path computation
requests.
L (Link diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following
REQUEST-ID objects MUST not have any link in common.
N (Node diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following
REQUEST-ID objects MUST not have any node in common.
Vasseur et al. [Page 22]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
S (SRLG diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following
REQUEST-ID objects MUST not share any SRLG (Shared Risk Link Group).
The flags defined above are not exclusive.
7.9. NOTIFICATION object
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
PCE to a PCC so as to notify of an event.
NOTIFICATION Object-Class is to be assigned by IANA (recommended
value=8)
NOTIFICATION Object-Type is to be assigned by IANA (recommended
value=1)
The PR flag of the NOTIFICATION object MUST be set to 1. One Object-
Type is defined for this object to be assigned by IANA with a
recommended value of 8.
The format of the NOTIFICATION body object is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Flags | Notification- | Notification- |
| | | type | value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: NOTIFICATION body object format
Length
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
No flag is currently defined
A NOTIFICATION object is characterized by a Notification-type that
specifies the class of notification and the Notification-value that
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).
Vasseur et al. [Page 23]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
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)
A Notification-type=1, Notification-value=1 indicates that the
PCC wants to inform a PCE of the cancellation of a set of
pending request(s). Such event could be triggered because of
external conditions such as the receipt of a positive reply from
another PCE (should the PCC have sent multiple requests to a set
of PCEs for the same path computation request), a network event
such as a network failure rendering the request obsolete or any
other event(s) local to the PCE. A NOTIFICATION object with
Notification-type=1, Notification-value=1 is exclusively carried
within a PCNtf message sent by the PCC to the PCE. The REQUEST-
ID object MUST also be present in the PCNtf message. Multiple
REQUEST-ID objects may be carried within the PCNtf message in
which case the notification applies to all of them. If such
notification is received by a PCC from a PCE, it SHOULD silently
ignore the notification and no errors should be generated.
Notification-value=2: PCE cancels a set of pending request(s)
A Notification-type=1, Notification-value=2 indicates that the
PCE wants to inform a PCC of the cancellation of a set of
pending request(s). Such event could be triggered because of
some PCE congested state or because of some path computation
requests that are part the set of correlated path computation
requests are missing. A NOTIFICATION object with Notification-
type=1, Notification-value=2 is exclusively carried within a
PCNtf message sent by a PCE to a PCC. The REQUEST-ID object MUST
also be present in the PCNtf message. Multiple REQUEST-ID
objects may be comprised within the PCNtf message in which case
the notification applies to all of them. If such notification is
received by a PCE from a PCC, it SHOULD silently ignore the
notification and no errors should be generated.
Notification-type=2: PCE congestion
Notification-value=1
A Notification-type=2, Notification-value=1 indicates to the
PCC(s) that the PCE is currently in a congested state. If no
REQUEST-ID objects are comprised in the PCNtf message, this
indicates that no other requests should be sent to that PCE
until the congested state is cleared: the pending requests are
not affected and will be served. If some pending requests cannot
be served due to the congested state, the PCE MUST also include
a set of REQUEST-ID object(s) that identifies the set of pending
Vasseur et al. [Page 24]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
requests which will not be honored and which will be cancelled
by the PCE. In this case, the PCE does not have to send an
additional PCNtf message with Notification-type=1 and
Notification-value=2 since the list of cancelled requests is
specified by including the corresponding set of REQUEST-ID
object(s). If such notification is received by a PCE from a PCC,
it SHOULD silently ignore the notification and no errors should
be generated.
Optionally, a TLV named CONGESTION-DURATION may be included in
the NOTIFICATION object that specifies the duration during which
no further request should be sent to the PCE. Once this period
has expired the PCE should no longer be considered in congested
state.
The CONGESTION-DURATION TLV is composed of 1 octet for the type,
1 octet specifying the number of bytes in the value field
followed by a fix length value field of 4 octets specifying the
estimated PCE congestion duration in seconds. The CONGESTION-
DURATION TLV is padded to eight-octet alignment
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: estimated congestion duration in seconds
Notification-value=2
A Notification-type=2, Notification-value=2 indicates that the
PCE is no longer in congested state and is available to process
new path computation requests. An implementation MUST make sure
that a PCE sends such notification to every PCC to which a
Notification message (with Notification-type=2, Notification-
value=1) has been sent unless a CONGESTION-DURATION TLV has been
included in the corresponding message and the PCE wishes to wait
for the expiration of that period of time before receiving new
requests. If the PCE detects that a PCC to which such
notification has been sent is in down state (TCP connection
released), the PCE should delay the sending of such PCNtf
message with Notification-type=2 and Notification-value=2 until
the connection is re-established. An implementation may decide
to cancel such notification if the PCC is in down state for a
specific period. A RECOMMENDED value for such delay is 1 hour.
If such notification is received by a PCE from a PCC, it SHOULD
silently ignore the notification and no errors should be
generated.
It is RECOMMENDED to support some dampening notification procedure on
the PCE so as to avoid too frequent congestion notifications and
releases. For example, an implementation could make use of an
hysteresis approach using a dual-thresholds mechanism triggering the
sending of congestion notifications and releases. Furthermore, in
case of high instabilities of the PCE resources, an additional
Vasseur et al. [Page 25]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
dampening mechanism SHOULD be used (linear or exponential) to pace
the notification frequency and avoid path computation requests
oscillation.
Notification-type=3: Reception by the PCE of a PCEP object with an
unrecognized 'Object-Class'.
Notification-value=1
A Notification-type=3, Notification-value=1 indicates to the PCC(s)
that the PCE has received a path computation request comprising an
optional PCEP object (PR flag set to 1) with an unrecognized Object-
Class but that the PCE managed to compute a set of path(s) by
ignoring the object. In that case, the PCE should send a PCNtf
message prior to sending its PCRep message containing the computed
path(s) so as to notify the requesting PCC of the list of objects
that were ignored during path computation because they were not
recognized. In such situation, the PCNtf message MUST comprise the
list of ignored PCEP objects.
7.10. PCEP-ERROR object
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
PCE to a PCC to notify of a PCEP protocol error.
PCEP-ERROR Object-Class is to be assigned by IANA (recommended
value=9)
PCEP-ERROR Object-Type is to be assigned by IANA (recommended
value=1)
The PR flag of the PCEP-ERROR object MUST be set to 0. One Object-
Type is defined for this object to be assigned by IANA with a
recommended value of 1.
The format of the PCEP-ERROR object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Flags | Error-Type | Error-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: PCEP-ERROR object body format
A PCEP-ERROR object is used to report a PCEP protocol error and is
characterized by an Error-Type which specifies the type of error and
an Error-value that provides additional information about the error
Vasseur et al. [Page 26]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
type. Both the Error-Type and the Error-Value should be managed by
IANA (see the IANA section).
Length (8 bits)
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 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)
Provides additional details about the error.
Optionally the PCErr message may contain additional TLV so as to
provide further information about the encountered error. No TLV is
currently defined.
A single PCErr message may contain multiple PCEP-ERROR objects.
For each PCEP protocol error, an Error type and value is defined.
Error-Type Meaning
1 Capability not supported
2 Unknown Object
-Error-value=1: Unrecognized
object class
-Error-value=2: Unrecognized
object Type
3 Not supported object
4 Policy violation
Error-value=1: C bit set (request
rejected)
Error-value=2: O bit set (request
rejected)
5 Required Object missing
Error-value=1: REQUEST-ID object
Missing
Error-value=2: RRO object missing
for a reoptimization request (R bit
of the REQUEST-ID object set).
6 Correlated path computation request
missing
7 Unknown request reference
Vasseur et al. [Page 27]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
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
not recognized by the PCE (PR flag=0) or recognized but not
supported, then the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=2 and 3 respectively). The corresponding path
computation 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). The corresponding path computation MUST be
cancelled.
If a PCC sends a correlated path computation request to a PCE and the
PCE does not receive all the correlated path computation requests
listed within the corresponding CVEC object during a configurable
period of time, the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=6). The corresponding correlated 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 REQUEST-ID object.
7.11. Carrying other protocol objects in PCEP message using the ENCAP
object
There are several circumstances where objects defined for other
protocols may advantageously carried within PCEP messages to specify
TE LSP constraints used for path computation.
The first example relates to objects defined in the context of COPS
that could be used for policy during path computation.
Also several RSVP objects have been defined in [RSVP], [RSVP-TE], [G-
RSVP] and [DS-TE-PROTO] that specify TE LSP constraints which are
used during TE LSP signaling. Although the PCEP protocol is not used
for the purpose of signaling a TE LSP, there are several constraints
that are provided by a requesting PCC to a PCE to perform path
computation. Hence, when appropriate, objects already specified in
Vasseur et al. [Page 28]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
the documents referenced above can be reused to pass constraint(s) to
the computing PCE or to provide results to the requesting PCC.
A non-exhaustive list of such objects follows:
1) Explicit Route Object (ERO): The ERO object is defined in [RSVP-
TE] and is used to specify an explicit route. An explicit route is
described as a list of groups of nodes along the explicit route. This
may encode either an explicit path or a strict/loose path. See [RSVP-
TE] for the detailed object format description.
2) SESSION-ATTRIBUTE object: The SESSION-ATTRIBUTE object is defined
in [RSVP-TE]. The Session Attribute Class is 207. Two C-Types are
defined, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The
SESSION-ATTRIBUTE object with C-Type = 1 includes several TE LSP
constraints: the set up and holding priorities, a set of flags used
for various purposes which characterise TE LSP properties related for
instance to protection (and in particular various attributes used by
MPLS Traffic Engineering Fast Reroute (see [FRR])), the SE style,
session name and so on. The SESSION-ATTRIBUTE object with C-Type =1
includes the same set of fields and additionally carries resource
affinity information.
3) GENERALIZED LABEL REQUEST
The GENERALIZED LABEL REQUEST object is defined in [G-RSVP] and is
used to specify GMPLS TE LSP constraints: LSP Encoding type and
switching type. See [G-RSVP] for the detailed object format.
4) PROTECTION
The PROTECTION object is defined in [G-RECV-E2E-SIG]. LSP (Protection
Type) Flags indicates the desired end-to-end LSP recovery type. Link
Flags indicates the desired link protection type. The Notification
(N) bit and Operational (O) bit has no meaning within a PROTECTION
Object. See [G-RECV-E2E-SIG] for the detailed object format. When an
LSP recovery type indicates '1+1 Bi-directional Protection', '1:N
Protection with Extra-Traffic', '1:N Protection with Extra-Traffic',
or 'Re-routing without Extra-Traffic', the CVEC Object is used to
correlate more than one request in PCReq. When a LSP indicates
'(Full) Re-routing' or 'Unprotected', a correlated request is not
necessary.
The ENCAP object is a PCEP object used to carry objects defined by
other protocols such as COPS ([COPS]), RSVP ([RSVP]), RSVP-TE ([RSVP-
TE]) or G-RSVP ([RSVP-TE]) in PCEP messages. The body of the ENCAP
object may comprise one or more objects provided that they belong to
the same protocol. A PCEP message may contain multiple ENCAP objects.
The ENCAP Object-Class is to be assigned by IANA (recommended
value=10)
The ENCAP Object-Type is to be assigned by IANA (recommended value=1)
Vasseur et al. [Page 29]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
The PR flag of the ENCAP object MUST be set to 1 when the support of
the constraint is mandatory and to 0 when optional.
The format of the ENCAP object is as follows
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Object(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 -
- Format of the ENCAP object
Length (8 bits)
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 8.
Protocol Type (8 bits)
Specify the nature of the object carried in the object body.
1= COPS ([COPS])
2= RSVP ([RSVP])
3= RSVP-TE ([RSVP-TE])
4= G-RSVP ([G-RSVP])
For the sake of clarity, the PCEP ENCAP object that carries an RSVP
object X is simply referred to as the PCEP object X. For example,
when the PROTECTION object defined in [G-RSVP] is carried within the
PCEP ENCAP object, the PCEP object is simply called PROTECTION
object.
8. Independent versus correlated path computation requests
As already described, the PCEP protocol permits the bundling of
multiple independent path computation requests within a single PCRep
message. A set of path computation requests is said to be independent
if their respective treatment (path computations) can be performed by
a PCE in a serialized and independent fashion.
There are various circumstances where the correlation of a set of
path computations may be beneficial or required.
First 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
Vasseur et al. [Page 30]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
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
correlated fashion which 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 path 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 correlated 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
correlated an obvious example of which being the computation of M
diverse paths. If such paths are computed in a non-correlated fashion
this seriously increases the probability of not being able to satisfy
all requests (sometimes also referred to as the well-know 'trapping
problem') and 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 are correlated: they cannot be
computed independently of each others.
Vasseur et al. [Page 31]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
The correlation of a set of path computation requests is achieved by
using the CVEC object that specifies the list of correlated requests
along with the nature of the correlation.
9. Elements of procedure
9.1. REQUEST-ID object
The absence of a REQUEST-ID object in the PCReq message MUST trigger
the sending of a PCErr message with Error-type=5 and Error-value=1.
If the C bit of the REQUEST-ID message carried within a PCReq message
is set and some local policy has been configured on the PCE not to
provide such cost, 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 1 respectively.
If the O bit of the REQUEST-ID message carried within a PCReq message
is set and some local policy has been configured on the PCE to not
provide 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 REQUEST-ID 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 (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 REQUEST-
ID 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 REQUEST-ID
object referring to an unknown Request-ID-Number, it MUST trigger the
sending of a PCErr message with Error-Type=7 and Error-value=1.
9.2. BANDWDITH object
If the following conditions are met:
- The PCE cannot find a path that fully satisfies the BANDWIDTH
constraint,
- The L bit of the REQUEST-ID is set,
Vasseur et al. [Page 32]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
- The PCE can find a less-constrained path,
Then the PCE MUST return include in its PCRep message:
- A NO-PATH object,
- A BANDWIDTH object that specifies the bandwidth of the less-
constrained computed path,
- The less-constrained path(s) in the form of ERO object(s).
9.3. DELAY object
If the following conditions are met:
- The PCE cannot find a path that fully satisfies the DELAY
constraint,
- The L bit of the REQUEST-ID is set,
- The PCE can find a less-constrained path,
Then the PCE MUST return include in its PCRep message:
- A NO-PATH object,
- A DELAY object that specifies the delay of the less-constrained
computed path,
- The less-constrained path(s) in the form of ERO object(s).
9.4. XRO object
If the following conditions are met:
- The PCE cannot find a path that fully satisfies the XRO constraint,
- The L bit of the REQUEST-ID is set,
- The PCE can find a less-constrained path,
Then the PCE MUST return include in its PCRep message:
- A NO-PATH object,
- A XRO object that specifies the list of network elements in the
requested XRO that the returned path successfully avoids and thus
does not contain,
- The less-constrained path(s) in the form of ERO object(s).
9.5. IRO object
If the following conditions are met:
- The PCE cannot find a path that fully satisfies the IRO constraint,
- The L bit of the REQUEST-ID is set,
- The PCE can find a less-constrained path,
Then the PCE MUST return include in its PCRep message:
- A NO-PATH object,
- A IRO object that specifies the list of network elements in the
requested IRO that the returned path does contain,
- The less-constrained path(s) in the form of ERO object(s).
9.6. CVEC object
When a requesting PCC desires to send multiple correlated path
computation requests, as explained in section 8, it MUST send all the
Vasseur et al. [Page 33]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
path computation requests within a single PCReq message that contains
all the correlated path computation requests: in that case, the PCReq
message MUST also comprise a CVEC object listing all the correlated
path computation requests. Note that such PCReq message may also
comprise non-correlated path computation requests. For example, the
PCReq message may comprise N correlated path computation requests
related to REQUEST-ID 1, ... , REQUEST-ID N which will also be present
in the CVEC object along with any other path computation requests.
If some REQUEST-IDs carried with the CVEC object are missing in the
PCReq message, a PCErr message with Error-Type = 6 MUST be sent to
the PCC.
10. Open issues
The PCE Working Group feed-back is requested on the following items:
1) Is there a requirement for PCEP hello message that could be used
for faster PCC/PCE liveness detection? (If yes, the hello
frequency could be negotiated upon PCEP connection setup (via
'open' messages)).
2) Is there a need for an Initiation phase during which several PCEP
session attributes could be negotiated such as:
- The session mode. Does the PCC or PCE require to have a permanent
PCEP session in which case the TCP session will be maintained
regardless of rate at which PCEP messages are exchanged. Such mode
would typically be used to speed-up response times. A lost of TCP
session should in this mode be interpreted as a communication
failure. Conversely, in the 'per-request' mode, a PCEP session
would be established on-demand, when one or more path computation
requests is required and then closed by the PCC.
- The PCE detailed parameters: as stated in [PCE-DISC], there is a
requirement for an automatic discovery of the PCE attributes. If
required, detailed PCE attributed could be discovered by means of
the PCEP protocol during the PCEP Initiation phase.
- If there is a requirement for PCEP hello message, the frequency at
which hello messages are exchanged could be negotiated during the
Initiation phase.
- Specific policies could be exchanged during the Initiation phase.
3) In its current version, PCEP provides the ability for a PCC to
notify to the PCE its interest for less-constrained TE LSP. Is
there a need for a more sophisticated scheme whereby the PCC could
specify a hierarchical constraints relaxation policy? Such
constraint relaxation policy would allow the PCC to indicate a
preference order in which constraints may be relaxed.
4) The CVEC object allows a PCC to request correlated path
computations. Is there a need to be able to support 1:N
protection, N:M protection?
Vasseur et al. [Page 34]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Based on Working Groups feed-backs, the appropriate sections will be
added.
11. Manageability Considerations
It is expected and required to specify a MIB for the PCEP
communication protocol (in a separate document).
Furthermore, additional tools related to performance, fault and
diagnostic detection are required which will also be specified in
separate documents.
12. IANA Considerations
12.1 TCP port
The PCEP protocol will use a well-known TCP port to be assigned by
IANA.
12.2. PCEP Objects
Several new PCEP objects are defined in this document that have a
Object-Class and an Object-Type. The new Object-Class and Object-Type
should be assigned by IANA.
- REQUEST-ID Object
The Object-Class of the REQUEST-ID 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.
- NO-PATH Object
The Object-Class of the NO-PATH 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.
- END-POINTS Object
The Object-Class of the END-POINTS object is to be assigned by IANA
(recommended value=3).
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
Vasseur et al. [Page 35]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
The Object-Class of the BANDWIDTH object is to be assigned by IANA
(recommended value=4).
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=5).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- IRO Object
The Object-Class of the IRO 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.
- CVEC Object
The Object-Class of the CVEC object is to be assigned by IANA
(recommended value=7).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- NOTIFICATION Object
The Object-Class of the NOTIFICATION object is to be assigned by IANA
(recommended value=8).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- PCEP-ERROR Object
The Object-Class of the PCEP-ERROR object is to be assigned by IANA
(recommended value=9).
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- ENCAP Object
The Object-Class of the ENCAP object is to be assigned by IANA
(recommended value=10).
Vasseur et al. [Page 36]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
12.3. Notification
A NOTIFICATION object is characterized by a Notification-type that
specifies the class of notification and a Notification-value that
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
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=3: Reception by the PCE of a PCEP object with an
unrecognized 'Object-Class'.
Notification-value=1: indicates to the PCC(s) that the PCE has
received a path computation request comprising an optional PCEP
object (PR flag set to 1) with an unrecognized Object-Class but that
the PCE managed to compute a set of path(s) by ignoring the object.
12.4. PCEP Error
A PCEP-ERROR object is used to report a PCEP protocol error and is
characterized by an Error-Type which specifies the type of error and
an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value should be managed by
IANA.
Error-Type Meaning Error-Value
1 Capability not supported
2 Unknown Object-Class
3 Not supported object
4 Policy violation
Vasseur et al. [Page 37]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
1: Cost requested and not authorized
2: Complete path requested and not
authorized
5 Required Object missing
1: REQUEST-ID object missing
2: ERO missing in a path computation
reoptimization request
6 Correlated path computation request missing
1: Path computation requests listed
in the CVEC object not received
in the PCReq message.
7 Unknown request reference
13. Security Considerations
PCEP communication could be the target of the following attacks:
-Spoofing (PCC or PCE impersonation)
-Snooping (message interception)
-Falsification
-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
authentication, integrity and privacy of PCEP Communications, and
also to protect against DoS attacks.
13.1. PCEP Authentication and Integrity
It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
provide for the authenticity and integrity of PCEP messages.
This will allow protecting against PCE or PCC impersonation and also
against message content falsification.
This requires the maintenance, exchange and configuration of MD-5
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
is important to limit the number of keys while ensuring the required
level of security.
MD-5 signature faces some limitations, as per explained in [RFC2385].
Note that when one digest technique stronger than MD5 is specified
and implemented, PCEP could be easily upgraded to use it.
13.2. PCEP Privacy
Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not
Vasseur et al. [Page 38]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
reside in the same AS, as an attacker that intercept a PCE message
could obtain sensitive information related to computed paths and
resources. Privacy can be ensured thanks to encryption. To ensure
privacy of PCEP communication, IPSec [IPSEC] tunnels MAY be used
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
option would not be required.
13.3. Protection against Denial of Service attacks
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
same mechanisms as defined in [LDP] to mitigate the threat of such
attacks:
- A PCE should avoid promiscuous TCP listens for PCEP TCP session
establishment. It should use only listens that are specific to
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.
14. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
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
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Vasseur et al. [Page 39]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
Internet-Drafts are draft documents valid for a maximum of six
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.
15. Acknowledgment
We 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.
16. References
16.1. Normative references
[RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RSVP] R. Braden et al., 'Resource ReSerVation Protocol (RSVP) -
Version 1 Functional Specification', RFC 2205, September 1997.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC 3209, December 2001.
[G-RSVP] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions",
RFC 3473, January 2003.
[COPS] Durham, D., 'The COPS (Common Open Policy Service) Protocol',
RFC 2748, January 2000.
[SCTP] Stewart et al., 'Stream Control Transmission Protocol',
RFC2960, October 2000.
[TCP] J. Postel, "Transmission Control Protocol", RFC 793, September
1981.
[DS-TE-PROTO] Le Faucheur et al, 'Protocol extensions for support of
Differentiated-Service-aware MPLS Traffic Engineering', RFC 4124,
June 2005.
[G-RECV-E2E-SIG] J. P. Lang et al, 'RSVP-TE Extensions in support of
End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery', draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
(working in progress).
Vasseur et al. [Page 40]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
16.2. Informative References
[WP] E. Rescorla, 'Writing Protocol Models', RFC4101, June 2005.
[PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, 'Path Computation
Element (PCE) Architecture', draft-ietf-pce-architecture, work in
progress.
[PCE-GEN-COM-REQ] J. Ash, J.L Le Roux et al., 'PCE Communication
Protocol Generic Requirements', draft-ietf-pce-comm-protocol-gen-
reqs, work Progress.
[GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-
gmpls-routing, work in progress.
[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al,
"Requirements for inter-area MPLS Traffic Engineering", RFC4105, June
2005.
[INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work
in progress.
[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A
Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-
ccamp-inter-domain-framework, work in progress.
[MGT] A. Farrel et al. 'Requirements for Manageability Sections in
Routing Area Drafts', draft-farrel-rtg-manageability-requirements,
work in progress.
[XRO] Lee et al, 'Exclude Routes - Extension to RSVP-TE', draft-ietf-
ccamp-rsvp-te-exclude-route, work in progress.
[PCE-DISC-REQ] JL Le Roux et al., 'Requirements for Path Computation
Element (PCE) Discovery', draft-ietf-pce-discovery-reqs, work in
progress.
[BGP-SEC-REQ] B. Christian Ed., "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec, work in progress
[LDP] L. Andersson, et al., "LDP Specificaiton", RFC3036, January
2001
[DOBB] H. Dobbertin, "The Status of MD5 After a Recent Attack",
RSALabs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",RFC 1321,
April 1992.
Vasseur et al. [Page 41]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
[IPSEC] S. Kent, A. Atkinson, " IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998
17. Authors' Addresses
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.com
Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
E-mail: arthi@juniper.net
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
JAPAN
Email: oki.eiji@lab.ntt.co.jp
Alia K. Atlas
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
EMail: akatlas@alum.mit.edu
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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."
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
Vasseur et al. [Page 42]
Internet Draft draft-vasseur-pce-pcep-01 July 2005
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Vasseur et al. [Page 43]
| PAFTECH AB 2003-2026 | 2026-04-22 23:18:01 |