PCE Working Group JP Vasseur
Cisco System Inc.
IETF Internet Draft JL Le Roux
France Telecom
Arthi Ayyangar
Juniper Networks
Eiji Oki
NTT
Alia Atlas
Avici Systems, Inc
Proposed Status: Standard
Expires: November 2005 May 2005
Path Computation Element (PCE) Communication Protocol (PCEP)
- Version 1 -
draft-vasseur-pce-pcep-00.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.
Abstract
Vasseur et al. [Page 1]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
This document specifies a communication protocol named PCEP (Path
Computation Element (PCE) Communication Protocol) for supporting the
interactions between a Path Computation Client (PCC) and a 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 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. PCEP overview.........................................5
6. PCEP Finite State Machine (FSM).......................6
7. PCEP messages.........................................6
7.1. Common header.......................................6
7.2. Path Computation Request (PCReq) message............7
7.3. Path Computation Reply (PCRep) message..............8
7.4. Notification (PCNtf) message........................10
7.5. Error (PCErr) message...............................10
8. Object Formats........................................11
8.1. Common object header................................11
8.2. REQUEST-ID Object...................................12
8.3. END-POINTS object...................................14
8.4. BANDWIDTH object....................................15
8.5. DELAY Object........................................16
8.6. IRO Object..........................................16
8.7. CVEC Object.........................................17
8.8. NOTIFICATION object.................................18
8.9. PCEP-ERROR object...................................21
8.10. Reuse of existing RSVP objects.....................23
9. Path computation requests bundling....................24
9.1. Motivations.........................................25
9.1.1. Independent requests..............................25
9.1.2. Correlated request................................25
9.2. CVEC object.........................................26
9.3. Bundling of response within a PCRep message.........26
10. Elements of procedure................................26
10.1. REQUEST-ID message.................................26
10.2. BANDWITH Object....................................27
10.3. DELAY Object.......................................27
10.4. XRO Object.........................................27
Vasseur et al. [Page 2]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
10.5. IRO Object........................................27
10.6. CVEC object.......................................28
10.7. SESSION-ATTRIBUTE object..........................28
11. Manageability.......................................28
12. IANA considerations.................................28
12.1. TCP port..........................................28
12.2. PCEP Objects......................................28
12.3. Notification......................................30
12.4. PCEP Error........................................30
13. Security Considerations.............................31
14. Intellectual Property Statement.....................31
15. Acknowledgment......................................32
16. References..........................................32
16.1. Normative references..............................32
16.2. Informative References............................32
17. AuthorsÆ Address....................................33
1. Terminology
Terminology used in this document
CSPF: Constraint-based Shortest Path First.
IGP Area: OSPF Area or IS-IS level
Intra-domain TE LSP: TE LSP whose path does not transit across
domains where a domain can either be an IGP area, an Autonomous
System or a sub-AS (BGP confederations).
Inter-domain TE LSP: A TE LSP whose path transits across at least
two different IGP domains where a domain can either be an IGP area,
an Autonomous System or a sub-AS (BGP confederations).
Link State Advertisement: An OSPF LSA or IS-IS LSP
LSDB: Link State Database.
LSP: Label Switched Path.
LSR: Label Switch Router.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by the 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 (see
further description in section 3).
Vasseur et al. [Page 3]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
PCEP: PCE Communication Protocol.
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.
TE LSP: Traffic Engineering Label Switched Path.
TE LSP head-end: Head/source of the TE LSP.
TE LSP tail-end: Tail/destination of the TE LSP.
2. Introduction
There are several motivations for the adoption of a PCE based
architecture to perform TE LSP path computation:
(1) Limitation of the PCC:
- Partial visibility (e.g. in the case of inter-domain TE LSPs),
- Absence of the TED or use of Non-TE-Enabled IGP,
- Network element lacks control plane or routing capability,
(2) Requirement for sophisticated path computation not available on
the PCC:
- CPU-intensive path computation,
- Backup path computation for bandwidth protection where more
sophisticated backup tunnel path computations are required to
minimize the required amount of backup capacity,
- Multi-Layer traffic engineering.
A more detailed description of the motivations listed above can be
found in [PCE-ARCH] and this list does not mean to be exhaustive.
Further, [PCE-ARCH] defines the building blocks for the PCE
architecture (not repeated in this document), an element of which is
the PCC-PCE/PCE-PCE communication protocol. The aim of this document
is to specify such communication protocol with the objective to be
compliant with the set of generic requirements specified in [PCE-COM-
GEN-REQ] produced by the PCE Working Group.
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.
Vasseur et al. [Page 4]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 the sake
of reference [PCE-DISC-REQ] defines a list of requirements for
dynamic PCE discovery.
4. Transport protocol
Reliable messaging and flow control are two key requirements
specified in [PCE-COM-GEN-REQ] for PCEP. Consequently, TCP has been
chosen as the transport protocol of choice and meet such
requirements. The PCEP protocol will use a well-known TCP port to be
assigned by IANA.
An implementation may either decide to keep the TCP session alive for
a unlimited time, should it have to send a new request later on (in
which case the TCP session will already be in place); 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). 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 notified
by the PCE when advertising its capability or manually configured on
the PCE/PCC. Furthermore, another option would consist of negotiating
the desired mode upon PCEP connection set up. Such aspect will be
detailed in further revision of this document based on Working Group
comments.
5. PCEP overview
The PCE Working Group has produced a set of requirements for the PCE
communication protocols ([PCE-COM-GEN-REQ]) which served as input to
the design of the PCEP protocol and will not be repeated here in
their entirety.
A set of chief objectives of the PCEP protocol are:
- To rely on a transport protocol that provides reliable data
delivery, flow control and security,
- To design a flexible protocol that could easily be extended to
meet further requirements,
- To ensure that the same protocol could be used between a PCC and a
PCE as well as between two PCEs,
- When appropriate, try to re-use objects already defined to encode
TE LSP constraints (e.g. some RSVP ([RSVP]), RSVP-TE ([RSVP-TE]
and [G-RSVP]) objects),
- To design a scalable protocol capable of coping with situations
which may require extensive protocol exchanges.
Vasseur et al. [Page 5]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
Note on terminology: in the rest of this document we use the PCC
terminology to refer to an entity that sends a request to a PCE,
should it be a regular PCC or a PCE itself acting as a PCC.
6. PCEP Finite State Machine (FSM)
PCE Working Group feed-backs will be requested on the following
items:
- Is there a need for "open" and "close" messages?
- 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)
- Is there a requirement for detailed capability discovery upon PCEP
connection set up?
Based on Working Groups feed-backs, the appropriate sections and the
detailed FSM will be added.
7. 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. Note that although BNF implies a specific
object order, a specific order is recommended but not imposed by
PCEP. In other words, an implementation SHOULD form the PCEP messages
using the recommended order but SHOULD accept a message with an
arbitrary order. Conversely, if a mandatory object is missing in a
PCEP message as defined in this document, this MUST trigger a
protocol error condition.
7.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver (Version): 4 bits
PCEP protocol version number. The current version is version 1
Flags: 12 bits
No Flag is currently defined
Vasseur et al. [Page 6]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
Message Length: 16 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
7.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 TE LSP 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 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 sender
as specified in section 9. Other objects are optional.
The IP source address of the PCReq message is any IP address of the
sending PCC and MUST not be changed for a specific path computation
request, should multiple PCReq messages be sent that all relate to
same request. Furthermore, the requesting PCC MUST ensure that such
IP address is reachable and present in the Routing Information Based
(RIB). It is RECOMMENDED for the sending PCC to make use of the same
IP address for all of its requests (unless such IP address becomes
unreachable) in order to ease statistic computations on the PCE: for
instance, if the PCC sends multiple path computation requests during
a specific period of time, it is RECOMMENDED to systematically use
the same source IP address. This way, some statistics can be
maintained by the PCE to track the number of received path
computation requests per PCC. If the PCCÆs address becomes
unreachable, the PCE MUST not conclude of a PCC failure. The state of
the TCP Connection dictates the PCC liveness.
The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header>
<REQUEST-ID>
<END-POINTS>
<SESSION-ATTRIBUTE>
[<GENERALIZED LABEL REQUEST>]
[<BANDWIDTH>]
[<CLASSTYPE>]
Vasseur et al. [Page 7]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
[<DELAY>]
[<ERO>]
[<XRO>]
[<IRO>]
[<PROTECTION>]
When used with the CVEC object (see section 7) the PCReq message has
the following form:
<PCReq Message>::= <Common Header>
<CVEC>
<request-list>
<request-list>::= <REQUEST-ID>
<END-POINTS>
<SESSION-ATTRIBUTE>
[<GENERALIZED LABEL REQUEST>]
[<BANDWIDTH>]
[<CLASSTYPE>]
[<DELAY>]
[<ERO>]
[<XRO>]
[<IRO>]
[<PROTECTION>]
Definition of the objects listed above:
Objects name Reference
<REQUEST-ID>
<END-POINTS>
<BANDWIDTH>
<CVEC>
<DELAY>
<IRO> Section 7 of this document
<SESSION-ATTRIBUTE>
<ERO> [RSVP-TE]
<GENERALIZED LABEL REQUEST> [G-RSVP]
<PROTECTION> [G-RECV-E2E-SIG].
<CLASSTYPE> [DS-TE-PROTO]
<XRO> [XRO]
7.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
Vasseur et al. [Page 8]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 received in the REQUEST-ID object
carried in the corresponding PCReq message (see section 7 for the
definition of the REQUEST-ID object). The IP destination address of
the PCRep message MUST be equal to the IP source address present in
the corresponding PCReq message.
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 PCReq message. Such a situation where
multiple computed paths are provided in a PCRep message is discussed
in detail in section 8.
In some circumstances (further discussed in section 7), the
requesting PCC has the ability to specify in its path computation
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>
<REQUEST-ID>
<ERO> [<ERO> à <ERO>]
[<SESSION-ATTRIBUTE>]
[<GENERALIZED LABEL REQUEST>]
[<BANDWIDTH>]
[<DELAY>]
[<XRO>]
[<IRO>]
[<PROTECTION>]
When used with the CVEC object, the PCRep message has the following
form:
<PCRep Message> ::= <Common Header>
<CVEC>
<path-list>
path-list:== <REQUEST-ID>
<ERO> [<ERO> à <ERO>]
[<SESSION-ATTRIBUTE>]
[<GENERALIZED LABEL REQUEST>]
[<BANDWIDTH>]
[<DELAY>]
Vasseur et al. [Page 9]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
[<XRO>]
[<IRO>]
[<PROTECTION>]
7.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
intent 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>
[<REQUEST-ID> à <REQUEST-ID>]
<NOTIFICATION> [<NOTIFICATION> à <NOTIFICATION>]
The expected procedure upon the reception of a PCNtf message is
defined in section 9.
7.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>
[<REQUEST-ID> à <REQUEST-ID>]
<PCEP-ERROR>
Vasseur et al. [Page 10]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
The expected procedure upon the reception of a PCErr message is
defined in section 9.
8. Object Formats
8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | Object-Type | Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OS|PR| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Common PCEP 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
Object Length
16-bit field containing the total object length in bytes. Must
always be a multiple of 4, and at least 8.
OS (Object-Semantic)
2-bit flag that specifies the nature of the object carried within
the object body. When set to 0, the object body carries a native
PCEP object. When set to 1, the object body carries an RSVP
object.
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.
The maximum object content length is 65528 bytes. The Object-Class
and Object-Type fields uniquely identify each PCEP object.
Vasseur et al. [Page 11]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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
during path computation because not recognized (see section XX). If
not possible, a PCErr message must be sent to the requesting entity
with a "Unknown Object-Class" error.
8.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
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 |P|C|B|R|N|L| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - REQUEST-ID object body format
The REQUEST-ID object has a variable length and may contain
additional TLVs. No TLV is currently defined.
Vasseur et al. [Page 12]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 priority than the path computation request for the
reoptimization of a TE LSP of priority n-1. Furthermore, the use
of the path computation request priority by the PCE by its
requests scheduler is 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
way 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. Conversely, 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.
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.
N (No path) bit: The N bit is exclusively used in PCRep message
to indicate the status of the path computation response for a
specific path computation request identified by the REQUEST-ID
object. When cleared, the path computation request has been
Vasseur et al. [Page 13]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
(fully or partially) satisfied and the corresponding path(s)
is/are provided in the PCRep message. When set, that means that
no path could be found by the PCE (thus no path is provided in
the PCRep message).
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.
B (Bi-directional) bit: when set, the PCC specifies that the
path computation request relates to a bidirectional TE LSP. When
cleared, the TE LSP is unidirectional.
C (Cost) bit: when set, the PCE MUST provide the cost of the
computed path in the PCRep message.
P (Partial): When cleared in a PCReq message this indicates to
the PCE that a path exclusively made of strict hops (set of
directly connected LSRs) is required, and otherwise (the P bit
is set to 1), a path with strict or loose route, or a mix of the
two, is acceptable. In a PCRep message, when the P bit is
cleared this indicates that the returned path is a strict route,
otherwise (the P bit is set to 1), the returned path is partial
(comprises loose hops).
Request-ID-number: 32 bits
This value (combined with the source IP address of the PCC)
uniquely identifies the Path Computation Request context and is
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.
8.3. 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
END-POINTS Object-Type is to be assigned by IANA (recommended
value=1)
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
Vasseur et al. [Page 14]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 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 3 - END-POINTS object body format for IPv4
The format of the END-POINTS object for IPv6 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 4 - END-POINTS object body format for IPv6
8.4. 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.
BANDWIDTH Object-Class is to be assigned by IANA
BANDWIDTH Object-Type is to be assigned by IANA (recommended
value=1)
The PR flag of the BANDWIDTH object MUST be set to 1.
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
Vasseur et al. [Page 15]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 -
- 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.
8.5. 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). The requested delay 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).
DELAY Object-Class is to be assigned by IANA
DELAY Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the DELAY object MUST be set to 1.
The format of the DELAY 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 -
- DELAY object body format
Delay: 32 bits. The requested delay constraint is encoded in 32 bits
in IEEE floating point format, expressed in milliseconds.
8.6. 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 element (abstract node). The IRO object may be carried within
PCReq and PCRep messages.
IRO Object-Class is to be assigned by IANA
Vasseur et al. [Page 16]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
IRO Object-Type is to be assigned by IANA (recommended value=1)
The PR flag of the IRO object MUST be set to 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Ï IRO object body format Subobjects The IRO object is made of sub-object 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
Note that the L bit of such sub-object has no meaning within an IRO
object.
Note also that 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 TE LSP path.
8.7. 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 a new PCEP object named the CVEC object
(Correlation VECtor). The CVEC object is optional.
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
Vasseur et al. [Page 17]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
CVEC Object-Type is to be assigned by IANA
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 8 -
- 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.
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.
8.8. 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
NOTIFICATION Object-Type is to be assigned by IANA (recommended
value=1)
Vasseur et al. [Page 18]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 1.
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 9 -
- 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).
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 its desire to cancel 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 from the PCC to the PCE. In that
Vasseur et al. [Page 19]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
case, the REQUEST-ID object MUST also be present in the PCNtf
message. Note that multiple REQUEST-ID objects may be carried
within the PCNtf message in which case the notification applies
to all of them.
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 its desire to cancel 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. In that case, the REQUEST-ID object
MUST also be present in the PCNtf message. Note that multiple
REQUEST-ID objects may be comprised within the PCNtf message in
which case the notification applies to all of them.
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
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).
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 can be considered as no longer 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.
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: estimated congestion duration in seconds
Vasseur et al. [Page 20]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 had been
included in the corresponding message and the PCE wishes to wait
for the expiration of that 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.
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 a dual-
thresholds mechanism triggering the sending of congestion
notifications and releases. Further, in case of high instabilities of
the PCE resources, an additional 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.
8.9. 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.
Vasseur et al. [Page 21]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
PCEP-ERROR Object-Class is to be assigned by IANA
PCEP-ERROR Object-Type is to be assigned by IANA
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 10 - 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
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.
Note that optionally the PCErr message may contain additional TLV so
as to provide further information about the encountered error. No TLV
is currently defined.
Furthermore, a single PCErr message may contain multiple PCEP-ERROR
objects.
Vasseur et al. [Page 22]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
For each PCEP protocol error, an Error type and value is defined.
Error-Type Meaning
1 Capability not supported
2 Unknown Object-Class
3 Not supported object
4 Policy violation
5 Required Object missing
6 Correlated path computation request
missing
7 Unknown request reference
In case of the Error-Type 2, 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 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.
If a PCEP message is received that relates to a request 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 PCEP path computation request is received that does not comprise
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, 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).
8.10. Reuse of existing RSVP objects
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
which are provided by a requesting PCC to a PCE to perform path
computation. Hence, when appropriate, objects already in the
Vasseur et al. [Page 23]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
documents referenced above can be reused to pass constraint(s) or
results to the computing PCE or 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. In
addition to the ability to identify specific nodes along the path, an
explicit route can identify a group of nodes that must be traversed
along the 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 TEP LSP constraints: LSP Encoding type,
switching type, and G-PID parameter. 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 an PROTECTION
Object. See [G-RECV-E2E-SIG] for the detailed object format. When LSP
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.
An RSVP object may be carried within a PCEP object. In this case, the
OS flag of the PCP common header MUST be set to 1.
9. Path computation requests bundling
Vasseur et al. [Page 24]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
There are various circumstances where bundling multiple path
computation requests is desirable or required.
9.1. Motivations
9.1.1. Independent requests
When an LSR has to signal a set of N TE LSPs for which it needs to
send path computation requests to a PCE so as to obtain their
respective paths, the first solution consists of sending N
independent PCReq messages to the selected PCE. 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. This is of
course a viable solution if and only if such requests are
independent. That said, even if such M request are independent, 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.
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 relies 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
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 is outside of the scope of this document.
The considerations listed above highlight one of the benefits of
requesting the PCE to correlate the computation of M independent
requests.
9.1.2. Correlated request
Vasseur et al. [Page 25]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 (in contrast with the previous
cases discussed in section 8.1.1 where a set of requests are
independent but would benefit from being computed in a correlated
fashion).
9.2. CVEC object
For the reasons explained in sections 8.1, path computation requests
may be correlated. This is achieved by using the CVEC object that
specifies the list of correlated requests along with the nature of
the correlation.
9.3. Bundling of response within a PCRep message
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.
10. Elements of procedure
10.1. REQUEST-ID message
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 P 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 path made of strict hops (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.
Vasseur et al. [Page 26]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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 complete or partial path by including an ERO object in
the PCReq message so as to avoid double bandwidth counting. The ERO
must be formed of strict hops only. If the PCC has previously
requested a Partial ERO (P bit cleared), a reoptimization can still
be requested by the PCC but this implies for the PCE to be either
statefull (keep a trace 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 ERO 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 PCReq 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.
10.2. BANDWIDTH Object
If the PCE cannot find a path that fully satisfies the bandwidth
constraint and if the L bit of the REQUEST-ID is set and the PCE can
find a less-constrained path, the PCE MUST return the less-
constrained path in the form of an ERO along with a BANDWIDHT object
that indicates the bandwidth for the computed TE LSP path.
10.3. DELAY Object
If the PCE cannot find a path that fully satisfies the delay
constraint and if the L bit of the REQUEST-ID is set and the PCE can
find a less-constrained path, the PCE MUST return the less-
constrained path in the form of an ERO along with a DELAY object that
indicates the delay for the computed TE LSP path.
10.4. XRO Object
If the PCE cannot find a path that fully satisfies the XRO constraint
and if the L bit of the REQUEST-ID is set and the PCE can find a
less-constrained path, the PCE MUST return the less-constrained path
in the form of an ERO object along with a XRO object that specifies
the list of network elements that the returned path does not
comprise. Note that the inclusion of such XRO object in the PCReq
message is required, should a partial path (path containing a set of
loose hops/abstract nodes(s)) be returned to the PCC.
10.5. IRO Object
If the PCE cannot find a path that fully satisfies the IRO constraint
and if the L bit of the REQUEST-ID is set and the PCE can find a
less-constrained path, the PCE MUST return the less-constrained path
Vasseur et al. [Page 27]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
in the form of an ERO object along with a IRO object that specifies
the list of network elements that the returned path comprises. Note
that the inclusion of such IRO object in the PCReq message is
required, should a partial path (path containing a set of loose
hops/abstract nodes(s)) be returned to the PCC.
10.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
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.
10.7. SESSION-ATTRIBUTE object
If the PCE cannot find a path that fully satisfies some of the
constraints specified in the SESSION-ATTRIBUTE object carried within
the PCReq message and if the L bit of the REQUEST-ID is set and the
PCE can find a less-constrained path, then the PCE MUST return the
less-constrained path in the form of an ERO along with a SESSION-
ATTRIBUTE object that indicates the constraints that the returned
computed TE LSP path has satisfied.
11. Manageability
To be detailed in further revision of this document.
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 which 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.
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
Vasseur et al. [Page 28]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
- END-POINTS Object
The Object-Class of the END-POINTS object is to be assigned by IANA.
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
- BANDWIDTH Object
The Object-Class of the BANDWIDTH object is to be assigned by IANA.
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.
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.
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.
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.
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.
One Object-Type is defined for this object and should be assigned by
IANA with a recommended value of 1.
Vasseur et al. [Page 29]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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
1: Cost requested and not authorized
2: Complete path requested and not
Vasseur et al. [Page 30]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
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:
resend requested
7 Unknown request reference
13. Security Considerations
To be detailed in a further revision of this document.
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.
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.
Vasseur et al. [Page 31]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
15. Acknowledgment
We would like to thank Dave Oran and Dean Cheng for their very
valuable input.
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.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[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", Formatted:
RFC 3473, January 2003.
[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", draft-ietf-
tewg-diff-te-proto, (Work in progress).
[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).
16.2. Informative References
[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).
Vasseur et al. [Page 32]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
[GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-
gmpls-routing-09.txt (work in progress)
[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al,
"Requirements for inter-area MPLS Traffic Engineering", draft-ietf-
tewg-interarea-mpls-te-req-03.txt, work in progress.
[INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-
09.txt, 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-00.txt, work in progress.
[MGT] A. Farrel et al. "Requirements for Manageability Sections in
Routing Area Drafts", draft-farrel-rtg-manageability-requirements-
00.txt, work in progress.
[XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", draft-ietf-
ccamp-rsvp-te-exclude-route-03.txt, work in progress.
[PCE-DISC-REQ] JL Le Roux et al., "Requirements for Path Computation
Element (PCE) Discovery", draft-leroux-pce-discovery-reqs-00.txt,
work in progress.
17. Authors Address
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
Vasseur et al. [Page 33]
Internet Draft draft-vasseur-pce-pcep-00 May 2005
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
JAPAN
Email: oki.eiji@lab.ntt.co.jp
Alia K. Atlas
Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2070
EMail: aatlas@avici.com
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
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 34]