Internet DRAFT - draft-ietf-pce-pcep
draft-ietf-pce-pcep
Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track JL. Le Roux, Ed.
Expires: May 21, 2009 France Telecom
November 17, 2008
Path Computation Element (PCE) Communication Protocol (PCEP)
draft-ietf-pce-pcep-19.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.
This Internet-Draft will expire on May 21, 2009.
Abstract
This document specifies the Path Computation Element Communication
Protocol (PCEP) for communications between a 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 Multiprotocol Label
Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP
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.
Vasseur & Le Roux Expires May 21, 2009 [Page 1]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Architectural Protocol Overview (Model) . . . . . . . . . . . 7
4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Architectural Protocol Overview . . . . . . . . . . . . . 7
4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 8
4.2.2. Session Keepalive . . . . . . . . . . . . . . . . . . 9
4.2.3. Path Computation Request Sent By a PCC to a PCE . . . 10
4.2.4. Path Computation Reply Sent By The PCE to a PCC . . . 11
4.2.5. Notification . . . . . . . . . . . . . . . . . . . . . 13
4.2.6. Error . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.7. Termination of the PCEP Session . . . . . . . . . . . 15
4.2.8. Intermitent versus Permanent PCEP Session . . . . . . 16
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 16
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 19
6.4. Path Computation Request (PCReq) Message . . . . . . . . . 20
6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 21
6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 22
6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 23
6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 24
6.9. Reception of Unknown Messages . . . . . . . . . . . . . . 24
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 25
7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 28
7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 31
7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 32
7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 35
7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 36
7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 37
7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 40
7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 41
7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 41
Vasseur & Le Roux Expires May 21, 2009 [Page 2]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
7.12. Include Route Object Object . . . . . . . . . . . . . . . 43
7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 43
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests . . . . . . . . . . . . . . . . . 43
7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 45
7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 46
7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 47
7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 50
7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 54
7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 55
8. Manageability Considerations . . . . . . . . . . . . . . . . . 56
8.1. Control of Function and Policy . . . . . . . . . . . . . . 57
8.2. Information and Data Models . . . . . . . . . . . . . . . 58
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 58
8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 58
8.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 59
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 59
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 60
9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 60
9.4. PCEP Message Common Header . . . . . . . . . . . . . . . . 61
9.5. Open Object Flag Field . . . . . . . . . . . . . . . . . . 62
9.6. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 62
9.7. NO-PATH Object Flag Field . . . . . . . . . . . . . . . . 63
9.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 63
9.9. LSPA Object Flag Field . . . . . . . . . . . . . . . . . . 64
9.10. SVEC Object Flag Field . . . . . . . . . . . . . . . . . . 65
9.11. Notification Object . . . . . . . . . . . . . . . . . . . 65
9.12. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 66
9.13. LOAD-BALANCING Object Flag Field . . . . . . . . . . . . . 68
9.14. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 68
9.15. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 69
9.16. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 69
10. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 69
10.2. TCP Security Techniques . . . . . . . . . . . . . . . . . 70
10.3. PCEP Authentication and Integrity . . . . . . . . . . . . 71
10.4. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 71
10.5. Key Configuration and Exchange . . . . . . . . . . . . . . 72
10.6. Access Policy . . . . . . . . . . . . . . . . . . . . . . 73
10.7. Protection Against Denial of Service Attacks . . . . . . . 74
10.7.1. Protection Against TCP DoS Attacks . . . . . . . . . . 74
10.7.2. Request Input Shaping/Policing . . . . . . . . . . . . 75
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Vasseur & Le Roux Expires May 21, 2009 [Page 3]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
13.1. Normative References . . . . . . . . . . . . . . . . . . . 77
13.2. Informative References . . . . . . . . . . . . . . . . . . 77
13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 80
Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 80
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
Intellectual Property and Copyright Statements . . . . . . . . . . 89
Vasseur & Le Roux Expires May 21, 2009 [Page 4]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
1. Introduction
[RFC4655] describes the motivations and architecture for a Path
Compuation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic
Engineering Label Swtich Paths (TE LSPs). The model allows for the
separation of PCE from Path Computation Client (PCC), and allows for
the cooperation between PCEs. This necessitates a communication
protocol between PCC and PCE, and between PCEs. [RFC4657] states the
generic requirements for such a protocol including the requirement
for using the same protocol between PCC and PCE, and between PCEs.
Additional application-specific requirements (for scenarios such as
inter-area, inter-AS, etc.) are not included in [RFC4657], 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. Examples of such application-
specific requirements are [RFC4927],
[I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req].
This document specifies the Path Computation Element Communication
Protocol (PCEP) for communications between a PCC and a PCE, or
between two PCEs, in compliance with [RFC4657]. 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.
PCEP 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.
2. Terminology
Terminology used in this document
AS: Autonomous System.
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.
IGP area: OSPF area or IS-IS level.
Inter-domain TE LSP: A TE LSP whose path transits at least two
different domains where a domain can be an IGP area, an Autonomous
System or a sub-AS (BGP confederations).
PCC: Path Computation Client: any client application requesting a
Vasseur & Le Roux Expires May 21, 2009 [Page 5]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
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.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a
PCE).
TED: Traffic Engineering Database that 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.
Strict/loose path: mix of strict and loose hops comprising at least
one loose hop representing the destination where a hop may be an
abstract node such as an AS.
Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function.
The message formats in this document are specified using Backus Naur
Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf].
3. Assumptions
[RFC4655] describes various types of PCE. PCEP does not make any
assumption and thus does not impose any constraint on the nature of
the PCE.
Moreover, it is assumed that the PCE has the required information
(usually including network topology and resource information) so as
to perform the computation of a path for a TE LSP. Such information
can be gathered by routing protocols or by some other means. The way
in which the information is gathered is out of the scope of this
document.
Similarly, no assumption is made about the discovery method used by a
PCC to discover a set of PCEs (e.g., via static configuration or
dynamic discovery) and on the algorithm used to select a PCE. For
reference, [RFC4674] defines a list of requirements for dynamic PCE
discovery and IGP-based solutions for such PCE discovery are
specified in [RFC5088] and [RFC5089].
Vasseur & Le Roux Expires May 21, 2009 [Page 6]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
4. Architectural Protocol Overview (Model)
The aim of this section is to describe the PCEP model in the spirit
of [RFC4101]. An architecture protocol overview (the big picture of
the protocol) is provided in this section. Protocol details can be
found in further sections.
4.1. Problem
The PCE-based architecture used for the computation of path for MPLS
and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the
PCE are not collocated, a communication protocol between the PCC and
the PCE is needed. PCEP is such a protocol designed specifically for
communications between a PCC and a PCE or between two PCEs in
compliance with [RFC4657]: a PCC may use PCEP to send a path
computation request for one or more TE LSPs to a PCE and the PCE may
reply with a set of computed paths if one or more paths can be found
that satisfies the set of constraints.
4.2. Architectural Protocol Overview
PCEP operates over TCP, which fulfils the requirements for reliable
messaging and flow control without further protocol work.
Several PCEP messages are defined:
- Open and Keepalive messages are used to initiate and maintain a
PCEP session respectively.
- PCReq: a PCEP message sent by a PCC to a PCE to request a path
computation.
- PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
computation request. A PCRep message can either contain a set of
computed paths if the request can be satisfied, or a negative reply
if not. The negative reply may indicate the reason why no path could
be found.
- PCNtf: a PCEP notification message either sent by a PCC to a PCE or
a PCE to a PCC to notify of a specific event.
- PCErr: a PCEP message sent upon the occurrence of a protocol error
condition.
- Close message: a message used to close a PCEP session.
The set of available PCEs may be either statically configured on a
PCC or dynamically discovered. The mechanisms used to discover one
Vasseur & Le Roux Expires May 21, 2009 [Page 7]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
or more PCEs and to select a PCE are out of the scope of this
document.
A PCC may have PCEP sessions with more than one PCE and similarly a
PCE may have PCEP sessions with multiple PCCs.
Each PCEP message is regarded as a single transmission unit and parts
of messages MUST NOT be interleaved. So, for example, a PCC sending
a PCReq and wishing to close the session, must complete sending the
request message before starting to send a Close message.
4.2.1. Initialization Phase
The initialization phase consists of two successive steps (described
in a schematic form in Figure 1):
1) Establishment of a TCP connection (3-way handshake) between the
PCC and the PCE.
2) Establishment of a PCEP session over the TCP connection.
Once the TCP connection is established, the PCC and the PCE (also
referred to as "PCEP peers") initiate PCEP session establishment
during which various session parameters are negotiated. These
parameters are carried within Open messages and include the Keepalive
timer, the Deadtimer and potentially other detailed capabilities and
policy rules that specify the conditions under which path computation
requests may be sent to the PCE. If the PCEP session establishment
phase fails because the PCEP peers disagree on the session parameters
or one of the PCEP peers does not answer after the expiration of the
establishment timer, the TCP connection is immediately closed.
Successive retries are permitted but an implementation should make
use of an exponential back-off session establishment retry procedure.
Keepalive messages are used to acknowledge Open messages, and once
the PCEP session has been successfully established.
Only one PCEP session can exist between a pair of PCEP peers at any
one time. Only one TCP connection on the PCEP port can exist between
a pair of PCEP peers at any one time.
Details about the Open message and the Keepalive message can be found
in Section 6.2 and Section 6.3 respectively.
Vasseur & Le Roux Expires May 21, 2009 [Page 8]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |
Figure 1: PCEP Initialization phase (initiated by a PCC)
(Note that once the PCEP session is established, the exchange of
Keepalive messages is optional)
4.2.2. Session Keepalive
Once a session has been established, a PCE or PCC may want to know
that its PCEP peer is still available for use.
It can rely on TCP for this information, but it is possible that the
remote PCEP function has failed without disturbing the TCP
connection. It is also possible to rely on the mechanisms built into
the TCP implementations, but these might not provide sufficiently
timely notifications of failures. Lastly, a PCC could wait until it
has a path computation request to send and use its failed
transmission or the failure to receive a response as evidence that
the session has failed, but this is clearly inefficient.
In order to handle this situation, PCEP includes a keepalive
mechanism based on a Keepalive timer, a Dead timer, and a Keepalive
message.
Each end of a PCEP session runs a Keepalive timer. It restarts the
timer every time it sends a message on the session. When the timer
Vasseur & Le Roux Expires May 21, 2009 [Page 9]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
expires, it sends a Keepalive message. Other traffic may serve as
Keepalive (see Section 6.3).
The ends of the PCEP session also run Dead timers, and they restart
them whenever a message is received on the session. If one end of
the session receives no message before the Dead timer expires, it
declares the session dead.
Note that this means that the Keepalive message is unresponded and
does not form part of a two-way keepalive handshake as used in some
protocols. Also note that the mechanism is designed to reduce to a
minimum the amount of keepalive traffic on the session.
The keepalive traffic on the session may be unbalanced according to
the requirements of the session ends. Each end of the session can
specify (on an Open message) the Keepalive timer that it will use
(i.e., how often it will transmit a Keepalive message if there is no
other traffic) and a Dead timer that it recommends its peer to use
(i.e., how long the peer should wait before declaring the session
dead if it receives no traffic). The session ends may use different
Keepalive timer values.
The minimum value of the Keepalive timer is 1 second, and it is
specified in units of 1 second. The recommended default value is 30
seconds. The timer may be disabled by setting it to zero.
The recommended default for the Dead timer is 4 times the value of
the Keepalive timer used by the remote peer. This means that there
is never any risk of congesting TCP with excessive Keepalive
messages.
4.2.3. Path Computation Request Sent By a PCC to a PCE
Vasseur & Le Roux Expires May 21, 2009 [Page 10]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
event | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request sent to | |
the selected PCE | |
Figure 2: Path Computation request
Once a PCC has successfully established a PCEP session with one or
more PCEs, if an event is triggered that requires the computation of
a set of paths, the PCC first selects one or more PCE. Note that the
PCE selection decision process may have taken place prior to the PCEP
session establishment.
Once the PCC has selected a PCE, it sends the PCE 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=B
Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may
desire to specify the urgency of such request by assigning a request
priority. Each request is uniquely identified by a request-id number
and the PCC-PCE address pair. The process is shown in a schematic
form in Figure 2.
Note that multiple path computation requests may be outstanding from
one PCC to a PCE at any time.
Details about the PCReq message can be found in Section 6.4
4.2.4. Path Computation Reply Sent By The PCE to a PCC
Vasseur & Le Roux Expires May 21, 2009 [Page 11]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| |request received
| |
| |2)Path successfully
| |computed
| |
| |3) Computed paths
| |sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
Figure 3a: Path Computation Request With Successful
Path Computation
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |
|---- PCReq message--->|
| |1) Path computation
| |request received
| |
| |2) No Path found that
| |satisfies the request
| |
| |3) Negative reply sent to
| |the PCC (optionally with
| |various additional
| |information)
|<--- PCRep message ---|
| (Negative reply) |
Figure 3b: Path Computation Request With Unsuccessful
Path Computation
Upon receiving a path computation request from a PCC, the PCE
triggers a path computation, the result of which can either be:
Vasseur & Le Roux Expires May 21, 2009 [Page 12]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
o Positive (Figure 3-a): the PCE manages to compute a path that
satisfies the set of required constraints, in which case the PCE
returns the set of computed paths to the requesting PCC. Note
that PCEP supports the capability to send a single request that
requires the computation of more than one path (e.g., computation
of a set of link-diverse paths).
o Negative (Figure 3-b): no path could be found that satisfies the
set of constraints. In this case, a PCE may provide the set of
constraints that led to the path computation failure. Upon
receiving a negative reply, a PCC may decide to resend a modified
request or take any other appropriate action.
Details about the PCRep message can be found in Section 6.5.
4.2.5. Notification
There are several circumstances in which a PCE may want to notify a
PCC of a specific event. For example, suppose that the PCE suddenly
gets overloaded, potentially leading to unacceptable response times.
The PCE may want to notify one or more PCCs that some of their
requests (listed in the notification) will not be satisfied or may
experience unacceptable delays. Upon receiving such notification,
the PCC may decide to redirect its path computation requests to
another PCE should an alternate PCE be available. Similarly, a PCC
may desire to notify a PCE of a particular event such as the
cancellation of pending requests.
Vasseur & Le Roux Expires May 21, 2009 [Page 13]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
event | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | |request queued
| |
| |
5) Path computation| |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| |request X cancelled
Figure 4: Example of PCC Notification (Cancellation
Notification)
Sent To a PCE
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
event | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | |request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| |request X cancelled
| |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation
Notification) Sent To a PCC
Details about the PCNtf message can be found in Section 6.6.
Vasseur & Le Roux Expires May 21, 2009 [Page 14]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
4.2.6. Error
The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g.,
capability not supported, reception of a message with a mandatory
missing object, policy violation, unexpected message, unknown request
reference, ...).
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1)Path computation | |
event | |
2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | |malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
Figure 6: Example of Error message Sent By a PCE To a PCC
In Reply To The Reception Of a Malformed Object
Details about the PCErr message can be found in Section 6.7.
4.2.7. Termination of the PCEP Session
When one of the PCEP peers desires to terminate a PCEP session it
first sends a PCEP Close message and then closes the TCP connection.
If the PCEP session is terminated by the PCE, the PCC clears all the
states related to pending requests previously sent to the PCE.
Similarly, if the PCC terminates a PCEP session the PCE clears all
pending path computation requests sent by the PCC in question as well
as the related states. A Close message can only be sent to terminate
a PCEP session if the PCEP session has previously been established.
In case of TCP connection failure, the PCEP session is immediately
terminated.
Details about the Close message can be found in Section 6.8.
Vasseur & Le Roux Expires May 21, 2009 [Page 15]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
4.2.8. Intermitent versus Permanent PCEP Session
An implementation may decide to keep the PCEP session alive (and thus
the corresponding TCP connection) for an unlimited time (this may for
instance be appropriate when path computation requests are sent on a
frequent basis so as to avoid to open a TCP connection each time a
path computation request is needed, which would incur additional
processing delays). Conversely, in some other circumstances, it may
be desirable to systematically open and close a PCEP session for each
PCEP request (for instance when sending a path computation request is
a rare event).
5. Transport Protocol
PCEP operates over TCP using a registered TCP port (to be assigned by
IANA). This allows the requirements of reliable messaging and flow
control to be met without further protocol work. All PCEP message
MUST be sent using the registered TCP port for the source and
destination TCP port.
6. PCEP Messages
A PCEP message consists of a common header followed by a variable
length body made of a set of objects that can either be mandatory or
optional. In the context of this document, an object is said to be
mandatory in a PCEP message when the object MUST be included for the
message to be considered as valid. A PCEP message with a missing
mandatory object MUST trigger an Error message (see Section 7.15).
Conversely, if an object is optional, the object may or may not be
present.
A flag referred to as the P flag is defined in the common header of
each PCEP object (see Section 7.2). When this flag is set in an
object in a PCReq, the PCE MUST take the information carried in the
object into account during the path computation. For example, the
METRIC object defined in Section 7.8 allows a PCC to specify a
bounded acceptable path cost. The METRIC object is optional, but a
PCC may set a flag to ensure that the constraint is taken into
account. In this case, if the constraint cannot be taken into
account by the PCE, the PCE MUST trigger an Error message.
For each PCEP message type, rules are defined that specify the set of
objects that the message can carry. We use the Backus-Naur Form
(BNF) (see [I-D.farrel-rtg-common-bnf]) to specify such rules.
Square brackets refer to optional sub-sequences. An implementation
MUST form the PCEP messages using the object ordering specified in
Vasseur & Le Roux Expires May 21, 2009 [Page 16]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
this document.
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-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common Header
Ver (Version - 3 bits): PCEP version number. Current version is
version 1.
Flags (5 bits): no flags are currently defined. Unassigned bits are
considered as reserved. They MUST be set to zero on transmission and
MUST be ignored on receipt.
Message-Type (8 bits):
The following message types are currently defined (to be confirmed by
IANA).
Value Meaning
1 Open
2 Keepalive
3 Path Computation Request
4 Path Computation Reply
5 Notification
6 Error
7 Close
Message-Length (16 bits): total length of the PCEP message expressed
in bytes including the common header.
6.2. Open Message
The Open message is a PCEP message sent by a PCC to a PCE and a PCE
to a PCC in order to establish a PCEP session. The Message-Type
field of the PCEP common header for the Open message is set to 1 (To
be confirmed by IANA).
Once the TCP connection has been successfully established, the first
message sent by the PCC to the PCE or by the PCE to the PCC MUST be
an Open message as specified in Appendix A.
Any message received prior to an Open message MUST trigger a protocol
error condition causing a PCErr message to be sent with Error-Type
Vasseur & Le Roux Expires May 21, 2009 [Page 17]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
'PCEP session establishment failure' and Error-Value 'reception of an
invalid Open message or a non Open message' and the PCEP session
establishment attempt MUST be terminated by closing the TCP
connection.
The Open message is used to establish a PCEP session between the PCEP
peers. During the establishment phase the PCEP peers exchange
several session characteristics. If both parties agree on such
characteristics the PCEP session is successfully established.
Open message
<Open Message>::= <Common Header>
<OPEN>
The Open message MUST contain exactly one OPEN object (see
Section 7.3).
Various session characteristics are specified within the OPEN object.
Once the TCP connection has been successfully established the sender
MUST start an initialization timer called OpenWait after the
expiration of which if no Open message has been received it sends a
PCErr message and releases the TCP connection (see Appendix A for
details).
Once an Open message has been sent to a PCEP peer, the sender MUST
start an initialization timer called KeepWait after the expiration of
which if neither a Keepalive message has been received nor a PCErr
message in case of disagreement of the session characteristics, a
PCErr message MUST be sent and the TCP connection MUST be released
(see Appendix A for details).
The KeepWait timer has a fixed value of 1 minute.
Upon the receipt of an Open message, the receiving PCEP peer MUST
determine whether the suggested PCEP session characteristics are
acceptable. If at least one of the characteristics is not acceptable
by the receiving peer, it MUST send an Error message. The Error
message SHOULD also contain the related Open object: for each
unacceptable session parameter, an acceptable parameter value SHOULD
be proposed in the appropriate field of the Open object in place of
the originally proposed value. The PCEP peer MAY decide to resend an
Open message with different session characteristics. If a second
Open message is received with the same set of parameters or with
parameters that are still unacceptable, the receiving peer MUST send
an Error message and it MUST immediately close the TCP connection.
Details about error message can be found in Section 7.15. Successive
retries are permitted but an implementation SHOULD make use of an
exponential back-off session establishment retry procedure.
Vasseur & Le Roux Expires May 21, 2009 [Page 18]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
If the PCEP session characteristics are acceptable, the receiving
PCEP peer MUST send a Keepalive message (defined in Section 6.3) that
serves as an acknowledgment.
The PCEP session is considered as established once both PCEP peers
have received a Keepalive message from their peer.
A PCEP implementation is free to process received requests in any
order. For example, the requests may be processed in the order they
are received, re-ordered and assigned priority according to local
policy, re-ordered according to the priority encoded in the RP Object
(Section 7.4.1), or processed in parallel.
6.3. Keepalive Message
A Keepalive message is a PCEP message sent by a PCC or a PCE in order
to keep the session in active state. The Keepalive message is also
used in response to an Open message to acknowledge that an Open
message has been received and that the PCEP session characteristics
are acceptable. The Message-Type field of the PCEP common header for
the Keepalive message is set to 2 (To be confirmed by IANA). The
Keepalive message does not contain any object.
PCEP has its own keepalive mechanism used to ensure of the liveness
of the PCEP session. This requires the determination of the
frequency at which each PCEP peer sends Keepalive messages.
Asymmetric values may be chosen; thus there is no constraint
mandating the use of identical keepalive frequencies by both PCEP
peers. The DeadTimer is defined as the period of time after the
expiration of which a PCEP peer declares the session down if no PCEP
message has been received (Keepalive or any other PCEP message: thus,
any PCEP message acts as a Keepalive message). Similarly, there is
no constraints mandating the use of identical DeadTimers by both PCEP
peers. The minimum Keepalive timer value is 1 second. Deployments
SHOULD consider carefully the impact of using low values for the
Keepalive timer as these might not give rise to the expected results
in periods of temporary network instability.
Keepalive messages are sent at the frequency specified in the OPEN
object carried within an Open message according to the rules
specified in Section 7.3. Because any PCEP message may serve as
Keepalive, an implementation may either decide to send Keepalive
messages at fixed intervals regardless on whether other PCEP messages
might have been sent since the last sent Keepalive message, or may
decide to differ the sending of the next Keepalive message based on
the time at which the last PCEP message (other than Keepalive) was
sent.
Vasseur & Le Roux Expires May 21, 2009 [Page 19]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
Note that sending Keepalive messages to keep the session alive is
optional and PCEP peers may decide to not send Keepalive messages
once the PCEP session is established in which case the peer that does
not receive Keepalive messages does not expect to receive them and
MUST NOT declare the session as inactive.
Keepalive message
<Keepalive Message>::= <Common Header>
6.4. Path Computation Request (PCReq) Message
A Path Computation Request message (also referred to as a PCReq
message) is a PCEP message sent by a PCC to a PCE to request a path
computation. A PCReq message may carry more than one path
computation request. The Message-Type field of the PCEP common
header for the PCReq message is set to 3 (To be confirmed by IANA).
There are two mandatory objects that MUST be included within a PCReq
message: the RP and the END-POINTS objects (see section Section 7).
If one or both of these objects is missing, the receiving PCE MUST
send an error message to the requesting PCC. Other objects are
optional.
The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD-
BALANCING objects are defined in Section 7. The special case of two
BANDWIDTH objects is discussed in detail in Section 7.7.
Vasseur & Le Roux Expires May 21, 2009 [Page 20]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
6.5. Path Computation Reply (PCRep) Message
The PCEP Path Computation Reply message (also referred to as a PCRep
message) is a PCEP message 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 4 (To be confirmed by
IANA).
The bundling of multiple replies to a set of path computation
requests within a single PCRep message is supported by PCEP. If a
PCE receives non-synchronized 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 an
approach is the introduction of additional delays for some path
computation requests of the set. Conversely, a PCE that receives
multiple requests within the same PCReq message MAY decide to provide
each computed path in separate PCRep messages or within the same
PCRep message. A PCRep message may contain positive and negative
replies.
A PCRep message may contain a set of computed paths corresponding to
either a single path computation request with load-balancing (see
Section 7.16) or multiple path computation requests originated by a
requesting PCC. The PCRep message may also contain multiple
acceptable paths corresponding to the same request.
The PCRep message MUST contain at least one RP object. For each
reply that is bundled into a single PCReq message, an RP object MUST
be included that contains a Request-ID-number identical to the one
specified in the RP object carried in the corresponding PCReq message
(see Section 7.4 for the definition of the RP object).
If the path computation request can be satisfied (the PCE finds a set
of paths that satisfy the set of constraints), the set of computed
paths specified by means of ERO objects is inserted in the PCRep
message. The ERO is defined in Section 7.9. The situation where
multiple computed paths are provided in a PCRep message is discussed
in detail in Section 7.13. Furthermore, when a PCC requests the
computation of a set of paths for a total amount of bandwidth by
means of a LOAD-BALANCING object carried within a PCReq message, the
ERO of each computed path may be followed by a BANDWIDTH object as
discussed in section Section 7.16.
If the path computation request cannot be satisfied, the PCRep
message MUST include a NO-PATH object. The NO-PATH object (described
in Section 7.5) may also contain other information (e.g, reasons for
the path computation failure).
Vasseur & Le Roux Expires May 21, 2009 [Page 21]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of a PCRep message is as follows:
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
6.6. Notification (PCNtf) Message
The PCEP Notification message (also referred to as the PCNtf message)
can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify
of a specific event. The Message-Type field of the PCEP common
header is set to 5 (To be confirmed by IANA).
The PCNtf message MUST carry at least one NOTIFICATION object and MAY
contain several NOTIFICATION objects should the PCE or the PCC intend
to notify of multiple events. The NOTIFICATION object is defined in
Section 7.14. The PCNtf message MAY also contain RP objects (see
Section 7.4 when the notification refers to particular path
computation requests.
The PCNtf message may be sent by a PCC or a PCE in response to a
request or in an unsolicited manner.
Vasseur & Le Roux Expires May 21, 2009 [Page 22]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of a PCNtf message is as follows:
<PCNtf Message>::=<Common Header>
<notify-list>
<notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>]
<notification-list>
<request-id-list>::=<RP>[<request-id-list>]
<notification-list>::=<NOTIFICATION>[<notification-list>]
6.7. Error (PCErr) Message
The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g.,
reception of a malformed message, reception of a message with a
mandatory missing object, policy violation, unexpected message,
unknown request reference, ...). The Message-Type field of the PCEP
common header is set to 6 (To be confirmed by IANA).
The PCErr message is sent by a PCC or a PCE in response to a request
or in an unsolicited manner. If the PCErr message is sent in
response to a request, the PCErr message MUST include the set of RP
objects related to the pending path computation requests that
triggered the error condition. In the later case (unsolicited), no
RP object is inserted in the PCErr message. For example, no RP
object is inserted in a PCErr when the error condition occurred
during the initialization phase. A PCErr message MUST contain a
PCEP-ERROR object specifying the PCEP error condition. The PCEP-
ERROR object is defined in section Section 7.15.
The format of a PCErr message is as follows:
<PCErr Message> ::= <Common Header>
( <error-object-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<error-list>::=<error>[<error-list>]
The procedure upon the receipt of a PCErr message is defined in
Section 7.15.
Vasseur & Le Roux Expires May 21, 2009 [Page 23]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
6.8. Close Message
The Close message is a PCEP message that is either sent by a PCC to a
PCE or by a PCE to a PCC in order to close an established PCEP
session. The Message-Type field of the PCEP common header for the
Close message is set to 7 (To be confirmed by IANA).
Close message
<Close Message>::= <Common Header>
<CLOSE>
The Close message MUST contain exactly one CLOSE object (see
Section 6.8). If more than one CLOSE object is present, the first
MUST be processed and subsequent objects ignored.
Upon the receipt of a valid Close message, the receiving PCEP peer
MUST cancel all pending requests, it MUST close the TCP connection
and MUST NOT send any further PCEP messages on the PCEP session.
6.9. Reception of Unknown Messages
A PCEP implementation that receives an unrecognized PCEP message MUST
send a PCErr message with Error-value=2 (capability not supported).
If a PCC/PCE receives unrecognized messages at a rate equal of
greater than MAX-UNKNOWN-MESSAGES unknown message requests per
minute, the PCC/PCE MUST send a PCEP CLOSE message with close
value="Reception of an unacceptable number of unknown PCEP message".
A RECOMMENDED value for MAX-UNKOWN-MESSAGES is 5. The PCC/PCE MUST
close the TCP session and MUST NOT send any further PCEP messages on
the PCEP session.
7. Object Formats
PCEP objects have a common format. They begin with a common object
header (see Section 7.2). This is followed by object-specific fields
defined for each different object. The object may also include one
or more type-length-value (TLV) encoded data sets. Each TLV has the
same structure as described in Section 7.1.
7.1. PCE TLV Format
A PCEP object may include a set of one or more optional TLVs.
All PCEP TLVs have the following format:
Vasseur & Le Roux Expires May 21, 2009 [Page 24]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
Type: 2 bytes
Length: 2 bytes
Value: variable
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes
specifying the TLV length, and a value field.
The Length field defines the length of the value portion in bytes.
The TLV is padded to 4-bytes alignment; padding is not included in
the Length field (so a three byte value would have a length of three,
but the total size of the TLV would be eight bytes).
Unrecognized TLVs MUST be ignored.
IANA management of the PCEP Object TLV type identifier codespace is
described in Section 9.
7.2. 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 | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: PCEP common object header
Object-Class (8 bits): identifies the PCEP object class.
OT (Object-Type - 4 bits): identifies the PCEP object type.
The Object-Class and Object-Type fields are managed by IANA.
The Object-Class and Object-Type fields uniquely identify each PCEP
object.
Res flags (2 bits). Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt.
o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
specify in a PCReq message sent to a PCE whether the object must
be taken into account by the PCE during path computation or is
just optional. When the P flag is set, the object MUST be taken
Vasseur & Le Roux Expires May 21, 2009 [Page 25]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
into account by the PCE. Conversely, when the P flag is cleared,
the object is optional and the PCE is free to ignore it.
o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep
message to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its
reply and set the I flag to indicate that the optional object was
ignored during path computation. When the I flag is cleared, the
PCE indicates that the optional object was processed during the
path computation. The setting of the I flag for optional objects
is purely indicative and optional. The I flag has no meaning in a
PCRep message when the P flag has been set in the corresponding
PCReq message.
If the PCE does not understand an object with the P flag set or
understands the object but decides to ignore the object, the entire
PCEP message MUST be rejected and the PCE MUST send a PCErr message
with Error-Type="Unknown Object" or "Not supported Object" along with
the corresponding RP object. Note that if a PCReq includes multiple
requests, only requests for which an object with the P flag set is
unknown/unrecognized MUST be rejected.
Object Length (16 bits). Specifies the total object length including
the header, in bytes. The Object Length field MUST always be a
multiple of 4, and at least 4. The maximum object content length is
65528 bytes.
7.3. OPEN Object
The OPEN object MUST be present in each Open message and MAY be
present in a PCErr message. There MUST be only one OPEN object per
Open or PCErr message.
The OPEN object contains a set of fields used to specify the PCEP
version, Keepalive frequency, DeadTimer, PCEP session ID along with
various flags. The OPEN object may also contain a set of TLVs used
to convey various session characteristics such as the detailed PCE
capabilities, policy rules and so on. No TLVs are currently defined.
OPEN Object-Class is to be assigned by IANA (recommended value=1)
OPEN Object-Type is to be assigned by IANA (recommended value=1)
Vasseur & Le Roux Expires May 21, 2009 [Page 26]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of the OPEN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object format
Ver (3 bits): PCEP version. Current version is 1.
Flags (5 bits): No Flags are currently defined. Unassigned bits are
considered as reserved. They MUST be set to zero on transmission and
MUST be ignored on receipt.
Keepalive (8 bits): maximum period of time (in seconds) between two
consecutive PCEP messages sent by the sender of this message. The
minimum value for the Keepalive is 1 second. When set to 0, once the
session is established, no further Keepalive messages are sent to the
remote peer. A RECOMMENDED value for the keepalive frequency is 30
seconds.
DeadTimer (8 bits): specifies the amount of time after the expiration
of which the PCEP peer can declare the session with the sender of the
Open message down if no PCEP message has been received. The
DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is
set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value
of the Keepalive.
Example:
A sends an Open message to B with Keepalive=10 seconds and
Deadtimer=40 seconds. This means that A sends Keepalive messages (or
any other PCEP message) to B every 10 seconds and B can declare the
PCEP session with A down if no PCEP message has been received from A
within any 40 second period.
SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
identifies the current session. The SID MUST be incremented each
time a new PCEP session is established and is used for logging and
troubleshooting purposes. Each increment SHOULD have a value of 1
and may cause a wrap back to zero.
Vasseur & Le Roux Expires May 21, 2009 [Page 27]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The SID is used to disambiguate instances of sessions to the same
peer. A PCEP implementation could use a single source of SIDs across
all peers, or one source for each peer. The former might constrain
the implementation to only 256 concurrent sessions. The latter
potentially requires more states. There is one SID number in each
direction.
Optional TLVs may be included within the OPEN object body to specify
PCC or PCE characteristics. The specification of such TLVs is
outside the scope of this document.
When present in an Open message, the OPEN object specifies the
proposed PCEP session characteristics. Upon receiving unacceptable
PCEP session characteristics during the PCEP session initialization
phase, the receiving PCEP peer (PCE) MAY include an OPEN object
within the PCErr message so as to propose alternative acceptable
session characteristic values.
7.4. RP Object
The RP (Request Parameters) object MUST be carried within each PCReq
and PCRep messages and MAY be carried within PCNtf and PCErr
messages. The RP object is used to specify various characteristics
of the path computation request.
The P flag of the RP object MUST be set in PCReq and PCReq messages
and MUST be cleared in PCNtf and PCErr messages. If the RP objet is
received with the P flag set incorrectely according to the rules
states above, the receiving peer MUST send a PCErr message with
Error-type=10 and Error-value=1. The corresponding path computation
request MUST be cancelled by the PCE without further notification.
7.4.1. Object Definition
RP Object-Class is to be assigned by IANA (recommended value=2)
RP Object-Type is to be assigned by IANA (recommended value=1)
Vasseur & Le Roux Expires May 21, 2009 [Page 28]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of the RP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP object body format
The RP object body has a variable length and may contain additional
TLVs. No TLVs are currently defined.
Flags (32 bits)
The following flags are currently defined:
o Pri (Priority - 3 bits): the Priority field may be used by the
requesting PCC to specify to the PCE the request's priority from 1
to 7. 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. Furthermore, the use of the path computation request
priority by the PCE's 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 this case, it is RECOMMENDED
that the PCC set the priority field to 0 in the RP object. If the
PCE does not take into account the request priority, it is
RECOMMENDED to set the priority field to 0 in the RP object
carried within the corresponding PCRep message, regardless of the
priority value contained in the RP 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 PCCs.
The ability of a PCE to support request prioritization MAY be
dynamically discovered by the PCCs 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 to
support request prioritization by observing the Priority field of
the RP 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 handling of request priorities: in other words, the path
Vasseur & Le Roux Expires May 21, 2009 [Page 29]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
computation request has been honoured but without taking the
request priority into account.
o R (Reoptimization - 1 bit): when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an
existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when
the R bit is set, an RRO (see Section 7.10) MUST be included in
the PCReq message to show the path of the existing TE LSP. Also,
for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,
the existing bandwidth of the TE LSP to be reoptimized MUST be
supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH
object is in addition to the instance of that object used to
describe the desired bandwidth of the reoptimized LSP. For
0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the
characteristics of the existing TE LSP are optional.
o B (Bi-directional - 1 bit): when set, the PCC specifies that the
path computation request relates to a bidirectional TE LSP that
has the same traffic engineering requirements including fate
sharing, protection and restoration, LSRs, TE Links, and resource
requirements (e.g., latency and jitter) in each direction. When
cleared, the TE LSP is unidirectional.
o O (strict/loose - 1 bit): when set, in a PCReq message, this
indicates that a loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that a path exclusively made of
strict hops is required. In a PCRep message, when the O bit is
set this indicates that the returned path is a loose path,
otherwise (the O bit is cleared), the returned path is made of
strict hops.
Unassigned bits are considered as reserved. They MUST be set to zero
on transmission and MUST be ignored on receipt.
Request-ID-number (32 bits). The Request-ID-number value combined
with the source IP address of the PCC and the PCE address uniquely
identify the path computation request context. The Request-ID-number
is used for disambiguation between pending requests and thus it MUST
be changed (such as by incrementing it) each time a new request is
sent to the PCE, and may wrap.
The value 0x00000000 is considered as invalid.
If no path computation reply is received from the PCE (e.g. request
dropped by the PCE because of memory overflow), and the PCC wishes to
resend its request, the same Request-ID-number MUST be used. Upon
receiving a path computation request from a PCC with the same
Request-ID-number the PCE SHOULD treat the request as a new request
Vasseur & Le Roux Expires May 21, 2009 [Page 30]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
but an implementation MAY choose to cach path computation replies in
order to quickly handle restranmission without having to handle twice
a path computation request should have the first request been dropped
or lost. Upon receiving a path computation reply from a PCE with the
same Request-ID-number the PCC SHOULD silently discard the path
computation reply.
Conversely, different Request-ID-number MUST be used for different
requests sent to a PCE.
The same Request-ID-number MAY be used for path computation requests
sent to different PCEs. The path computation reply is unambiguously
identified by the IP source address of the replying PCE.
7.4.2. Handling of the RP Object
If a PCReq message is received that does not contain an RP object,
the PCE MUST send a PCErr message to the requesting PCC with Error-
type="Required Object missing" and Error-value="RP Object missing".
If the O bit of the RP message carried within a PCReq message is
cleared and local policy has been configured on the PCE to not
provide explicit paths (for instance, for confidentiality reasons), a
PCErr message MUST be sent by the PCE to the requesting PCC and the
pending path computation request MUST be discarded. The Error-type
is "Policy Violation" and Error-value is "O bit cleared".
R bit: when the R bit of the RP object is set in a PCReq message,
this indicates that the path computation request relates to the
reoptimization of an existing TE LSP. In this case, the PCC MUST
also provide the strict/loose path by including an RRO object in the
PCReq message so as to avoid/limit double bandwidth counting if and
only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not
requested a strict path (O bit set), a reoptimization can still be
requested by the PCC but this requires that the PCE either be
stateful (keep track of the previously computed path with the
associated list of strict hops), or have the ability to retrieve the
complete required path segment. Alternatively the PCC MUST inform
the PCE of the working path with the associated list of strict hops
in PCReq. The absence of an RRO in the PCReq message for a non-0-
bandwidth TE LSP when the R bit of the RP object is set MUST trigger
the sending of a PCErr message with Error-type="Required Object
Missing" and Error-value="RRO Object missing for reoptimization".
If a PCC/PCE receives a PCRep/PCReq message that contains a RP object
referring to an unknown Request-ID-Number, the PCC/PCE MUST send a
PCErr message with Error-Type="Unknown request reference". This is
used for debugging purposes. If a PCC/PCE receives PCRep/PCReq at a
Vasseur & Le Roux Expires May 21, 2009 [Page 31]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
rate equal of greater than MAX-UNKOWN-REQUESTS unknown requests per
minute, the PCC/PCE MUST send a PCEP CLOSE message with close
value="Reception of an unacceptable number of unknown requests/
replies". A RECOMMENDED value for MAX-UNKOWN-REQUESTS is 5. The
PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP
messages on the PCEP session.
The reception of a PCEP message that contains a RP object referring
to a Request-ID-number=0x00000000 MUST be treated similarly to an
unkown request.
7.5. NO-PATH Object
The NO-PATH object is used in PCRep messages in response to an
unsuccessful path computation request (the PCE could not find a path
satisfying the set of constraints). When a PCE cannot find a path
satisfying a set of constraints, it MUST include a NO-PATH object in
the PCRep message.
There are several categories of issue that can lead to a negative
reply. For example, the PCE chain might be broken (should there be
more than one PCE involved in the path computation) or no path
obeying the set constraints could be found. The "NI (Nature of
Issue)" field in the NO-PATH object is used to report the error
category.
Optionally, if the PCE supports such capability, the NO-PATH object
MAY contain an optional NO-PATH-VECTOR TLV defined below and used to
provide more information on the reasons that led to a negative reply.
The PCRep message MAY also contain a list of objects that specify the
set of constraints that could not be satisfied. The PCE MAY just
replicate the set of objects that was received that was the cause of
the unsuccessful computation or MAY optionally report a suggested
value for which a path could have been found (in which case the value
differs from the value in the original request).
NO-PATH Object-Class is to be assigned by IANA (recommended value=3)
NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
Vasseur & Le Roux Expires May 21, 2009 [Page 32]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature Of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH Object Format
NI - Nature Of Issue (8 bits): the NI field is used to report the
nature of the issue that led to a negative reply. Two values are
currently defined:
0x00: No path satisfying the set of constraints could be found
0x01: PCE chain broken
The Nature Of Issue field value can be used by the PCC for various
purposes:
o Constraint adjustement before re-issuing a new path computation
request,
o Explicit selection of a new PCE chain,
o Logging of the error type for futher action by the network
admistrator
IANA management of the NI field codespace is described in Section 9.
Flags (16 bits).
The following flag is currently defined:
C flag (1 bit): when set, the PCE indicates the set of unsatisfied
constraints (reasons why a path could not be found) in the PCRep
message by including the relevant PCEP objects. When cleared, no
failing constraints are specified. The C flag has no meaning and is
ignored unless the NI field is set to 0x00.
Unassigned bits are considered as reserved. They MUST be set to zero
on transmission and MUST be ignored on receipt.
Vasseur & Le Roux Expires May 21, 2009 [Page 33]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt.
The NO-PATH object body has a variable length and may contain
additional TLVs. The only TLV currently defined is the NO-PATH-
VECTOR TLV defined below.
Example: consider the case of a PCC that sends a path computation
request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot
find a path for X MBits/s. In this case, the PCE must include in the
PCRep message a NO-PATH object. Optionally the PCE may also include
the original BANDWIDTH object so as to indicate that the reason for
the unsuccessful computation is the bandwidth constraint (in this
case, the NI field value is 0x00 and C flag is set). If the PCE
supports such capability it may alternatively include the BANDWIDTH
Object and report a value of Y in the bandwidth field of the
BANDWIDTH object (in this case, the C flag is set) where Y refers to
the bandwidth for which a TE LSP with the same other characteristics
could have been computed.
When the NO-PATH object is absent from a PCRep message, the path
computation request has been fully satisfied and the corresponding
paths are provided in the PCRep message.
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH
object in order to provide more information on the reasons that led
to a negative reply.
The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in
section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying
the TLV length (length of the value portion in bytes) followed by a fixed
length value field of 32-bit flags field.
TYPE: To be assigned by IANA (suggested value=1)
LENGTH: 4
VALUE: 32-bit flags field
IANA is requested to manage the space of flags carried in the NO-
PATH-VECTOR TLV (see Section 9).
The following flags are currently defined:
o Bit number: 31 - PCE currently unavailable
o Bit number: 30 - Unknown destination
o Bit number: 29 - Unknown source
Vasseur & Le Roux Expires May 21, 2009 [Page 34]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
7.6. END-POINT Object
The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for
which a path computation is requested. The P flag of the END-POINT
object MUST be set. If the END-POINT objet is received with the P
flag cleared, the receiving peer MUST send a PCErr message with
Error-type=10 and Error-value=1. The corresponding path computation
request MUST be cancelled by the PCE without further notification.
Note that the source and destination addresses specified in the END-
POINTS object may or may not correspond to the source and destination
IP address of the TE LSP but rather to a path segment. Two END-
POINTS objects (for IPv4 and IPv6) are defined.
END-POINTS Object-Class is to be assigned by IANA (recommended
value=4)
END-POINTS Object-Type is to be assigned by IANA (recommended value=1
for IPv4 and 2 for IPv6)
Vasseur & Le Roux Expires May 21, 2009 [Page 35]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
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 12: 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 13: END-POINTS Object Body Format for IPv6
The END-POINTS object body has a fixed length of 8 bytes for IPv4 and
32 bytes for IPv6.
If more than one END-POINTS object is present, the first MUST be
processed and subsequent objects ignored.
7.7. BANDWIDTH Object
The BANDWIDTH object is used to specify the requested bandwidth for a
TE LSP. The notion of bandwidth is similar to the one used for RSVP
signaling in [RFC2205], [RFC3209] and [RFC3473].
If the requested bandwidth is equal to 0, the BANDWIDTH object is
optional. Conversely, if the requested bandwidth is non equal to 0,
the PCReq message MUST contain a BANDWIDTH object.
In the case of the reoptimization of a TE LSP, the bandwidth of the
Vasseur & Le Roux Expires May 21, 2009 [Page 36]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
existing TE LSP MUST also be included in addition to the requested
bandwidth if and only if the two values differ. Consequently, two
Object-Type values are defined that refer to the requested bandwidth
and the bandwidth of the TE LSP for which a reoptimization is being
performed.
The BANDWIDTH object may be carried within PCReq and PCRep messages.
BANDWIDTH Object-Class is to be assigned by IANA (recommended
value=5)
Two Object-Type values are defined for the BANDWIDTH object:
o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by
IANA (recommended value=1)
o Bandwidth of an existing TE LSP for which a reoptimization is
requested. BANDWIDTH Object-Type is to be assigned by IANA
(recommended value=2)
The format of the BANDWIDTH object body is as follows:
0 1 2 3
0 1 2 3 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 14: BANDWIDTH Object Body Format
Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in
IEEE floating point format (see [IEEE.754.1985]), expressed in bytes
per second. Refer to Section 3.1.2 of [RFC3471] for a table of
commonly used values.
The BANDWIDTH object body has a fixed length of 4 bytes.
7.8. METRIC Object
The METRIC object is optional and can be used for several purposes.
In a PCReq message, a PCC MAY insert one of more METRIC objects:
o To indicate the metric that MUST be optimized by the path
computation algorithm (IGP metric, TE metric, Hop counts).
Currently, three metrics are defined: the IGP cost, the TE metric
(see [RFC3785]) and the number of hops traversed by a TE LSP.
Vasseur & Le Roux Expires May 21, 2009 [Page 37]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
o To indicate a bound on the path cost that MUST NOT be exceeded for
the path to be considered as acceptable by the PCC.
In a PCRep message, the METRIC object MAY be inserted so as to
provide the cost for the computed path. It MAY also be inserted
within a PCRep with the NO-PATH object to indicate that the metric
constraint could not be satisfied.
The path computation algorithmic aspects used by the PCE to optimize
a path with respect to a specific metric are outside the scope of
this document.
It must be understood that such path metrics are only meaningful if
used consistently: for instance, if the delay of a computed path
segment is exchanged between two PCEs residing in different domains,
consistent ways of defining the delay must be used.
The absence of the METRIC object MUST be interpreted by the PCE as a
path computation request for which no constraints need be applied to
any of the metrics.
METRIC Object-Class is to be assigned by IANA (recommended value=6)
METRIC Object-Type is to be assigned by IANA (recommended value=1)
The format of the METRIC object body is as follows:
0 1 2 3
0 1 2 3 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 |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: METRIC Object Body Format
The METRIC object body has a fixed length of 8 bytes.
Reserved (16 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
T (Type - 8 bits): Specifies the metric type.
Three values are currently defined:
Vasseur & Le Roux Expires May 21, 2009 [Page 38]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
o T=1: IGP metric
o T=2: TE metric
o T=3: Hop Counts
Flags (8 bits): Two flags are currently defined:
o B (Bound - 1 bit): When set in a PCReq message, the metric-value
indicates a bound (a maximum) for the path metric that must not be
exceeded for the PCC to consider the computed path as acceptable.
The path metric must be less than or equal to the value specified
in the Metric-value field. When the B flag is cleared, the
metric-value field is not used to reflect a bound constraint.
o C (Computed Metric - 1 bit): When set in a PCReq message, this
indicates that the PCE MUST provide the computed path metric value
(should a path satisfying the constraints be found) in the PCRep
message for the corresponding metric.
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
Metric-value (32 bits): metric value encoded in 32 bits in IEEE
floating point format (See [IEEE.754.1985]).
Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq
message. There MUST be at most one instance of the METRIC object for
each metric type with the same B flag value. If two or more
instances of a METRIC object with the same B flag value are present
for a metric type, only the first instance MUST be considered and
other instances MUST be ignored.
The presence of two METRIC objects of the same type with a different
value of the B-Flag in a PCEReq message is allowed. Furthermore, it
is also allowed to insert in a PCReq message two METRIC objects with
different types that have both their B-Flag cleared: in this case, an
objective function must be used by the PCE to solve a multi-parameter
constraint problem.
A METRIC object used to indicate the metric to optimize during the
path computation MUST have the B-Flag cleared and the C-Flag set to
the appropriate value. When the path computation relates to the
reoptimization of an exiting TE LSP (in which case R-Flag of the RP
object is set) an implementation MAY decide to set the metric-value
field to the computed value of the metric of the TE LSP to be
reoptimized with regards to a specific metric type.
Vasseur & Le Roux Expires May 21, 2009 [Page 39]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
A METRIC object used to reflect a bound MUST have the B-Flag set, the
C-Flag and metric-value field set to the appropriate values.
In a PCRep message, unless not allowed by PCE policy, at least one
METRIC object MUST be present that reports the computed path metric
if the C bit of the METRIC object was set in the corresponding path
computation request (the B-flag MUST be cleared). The C-flag has no
meaning in a PCRep message. Optionally the PCRep message MAY contain
additional METRIC objects that correspond to bound constraints, in
which case the metric-value MUST be equal to the corresponding
computed path metric (the B-flag MUST be set). If no path satisfying
the constraints could be found by the PCE, the METRIC objects MAY
also be present in the PCRep message with the NO-PATH object to
indicate the constraint metric that could be satisfied.
Example: if a PCC sends a path computation request to a PCE where the
metric to optimize is the IGP metric and the TE metric must not
exceed the value of M, two METRIC object are inserted in the PCReq
message:
o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000
o Second METRIC Object with B=1, T=2, metric-value=M
If a path satisfying the set of constraints can be found by the PCE
and there is no policy that prevents the return of the computed
metric, the PCE inserts one METRIC object with B=0, T=1, metric-
value= computed IGP path cost. Additionally, the PCE may insert a
second METRIC object with B=1, T=2, metric-value= computed TE path
cost.
7.9. Explicit Route Object
The ERO is used to encode the path of a TE LSP through the network.
The ERO is carried within a PCRep message to provide the computed TE
LSP should the path computation have been successful.
The contents of this object are identical in encoding to the contents
of the Resource Reservation Protocol Traffic Engineering Extensions
(RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473]
and [RFC3477]. That is, the object is constructed from a series of
sub-objects. Any RSVP-TE ERO sub-object already defined or that
could be defined in the future for use in the RSVP-TE ERO is
acceptable in this object.
PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
Since the explicit path is available for immediate signaling by the
Vasseur & Le Roux Expires May 21, 2009 [Page 40]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO.
ERO Object-Class is to be assigned by IANA (recommended value=7)
ERO Object-Type is to be assigned by IANA (recommended value=1)
7.10. Reported Route Object
The RRO is exclusively carried within a PCReq message so as to report
the route followed by a TE LSP for which a reoptimization is desired.
The contents of this object are identical in encoding to the contents
of the Route Record Object defined in [RFC3209], [RFC3473] and
[RFC3477]. That is, the object is constructed from a series of sub-
objects. Any RSVP-TE RRO sub-object already defined or that could be
defined in the future for use in the RSVP-TE RRO is acceptable in
this object.
The meanings of all of the sub-objects and fields in this object are
identical to those defined for the RSVP-TE RRO.
PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
RRO Object-Class is to be assigned by IANA (recommended value=8)
RRO Object-Type is to be assigned by IANA (recommended value=1)
7.11. LSPA Object
The LSPA object is optional and specifies various TE LSP attributes
to be taken into account by the PCE during path computation. The
LSPA (LSP Attributes) object can be carried within a PCReq message,
or a PCRep message in case of unsuccessful path computation (in this
case, the PCRep message also contains a NO-PATH object and the LSPA
object is used to indicate the set of constraints that could not be
satisfied). Most of the fields of the LSPA object are identical to
the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in
[RFC3209] and [RFC4090]. When absent from the PCReq message, this
means that the Setup and Holding priorities are equal to 0, and there
are no affinity constraints. See section 4.7.4 of [RFC3209] for a
detailed description of the use of resource affinities.
LSPA Object-Class is to be assigned by IANA (recommended value=9)
LSPA Object-Types is to be assigned by IANA (recommended value=1)
Vasseur & Le Roux Expires May 21, 2009 [Page 41]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of the LSPA object body is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LSPA Object Body Format
Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP
with respect to taking resources, in the range of 0 to 7. The value
0 is the highest priority. The Setup Priority is used in deciding
whether this session can preempt another session.
Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP
with respect to holding resources, in the range of 0 to 7. The value
0 is the highest priority. Holding Priority is used in deciding
whether this session can be preempted by another session.
Flags (8 bits)
The flag L corresponds to the "Local protection desired" bit
([RFC3209]) of the SESSION-ATTRIBUTE Object.
L Flag (Local protection desired). When set, this means that the
computed path must include links protected with Fast Reroute as
defined in [RFC4090].
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt.
Note that Optional TLVs may be defined in the future to carry
additional TE LSP attributes such as those defined in [RFC4420].
Vasseur & Le Roux Expires May 21, 2009 [Page 42]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
7.12. Include Route Object Object
The IRO (Include Route Object) is optional and can be used to specify
that the computed path MUST traverse a set of specified network
elements. The IRO MAY be carried within PCReq and PCRep messages.
When carried within a PCRep message with the NO-PATH object, the IRO
indicates the set of elements that cause de PCE to fail to find a
path.
IRO Object-Class is to be assigned by IANA (recommended value=10)
IRO Object-Type is to be assigned by IANA (recommended value=1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IRO Body Format
Subobjects: The IRO is made of subobjects identical to the ones
defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject
type is identical to the subobject type defined in the related
documents.
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.
7.13. SVEC Object
7.13.1. Notion of Dependent and Synchronized Path Computation Requests
Independent versus dependent path computation requests: path
computation requests are said to be independent if they are not
related to each other. Conversely a set of dependent path
computation requests is such that their computations cannot be
performed independently of each other (a typical example of dependent
requests is the computation of a set of diverse paths).
Vasseur & Le Roux Expires May 21, 2009 [Page 43]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
Synchronized versus non-synchronized path computation requests: a set
of path computation requests is said to be non-synchronized if their
respective treatment (path computations) can be performed by a PCE in
a serialized and independent fashion.
There are various circumstances where the synchronization of a set of
path computations may be beneficial or required.
Consider the case of a set of N TE LSPs for which a PCC needs to send
path computation requests to a PCE. The first solution consists of
sending N separate PCReq messages to the selected PCE. In this case,
the path computation requests are non-synchronized. Note that the
PCC may chose to distribute the set of N requests across K PCEs for
load balancing purposes. 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
bundled within a single PCReq message (since PCEP allows for the
bundling of multiple path computation requests within a single PCReq
message). That said, even in the case of independent requests, it
can be desirable to request from the PCE the computation of their
paths in a synchronized fashion that is likely to lead to more
optimal path computations and/or reduced blocking probability if the
PCE is a stateless PCE. In other words, the PCE should not compute
the corresponding paths in a serialized and independent manner but it
should rather "simultaneously" compute their paths. For example,
trying to "simultaneously" compute the paths of M TE LSPs may allow
the PCE to improve the likelihood to meet multiple constraints.
Consider the case of two TE LSPs requesting N1 MBits/s and N2 MBits/s
respectively and a maximum tolerable end-to-end delay for each TE LSP
of X ms. There may be circumstances where the computation of the
first TE LSP irrespectively of the second TE LSP may lead to the
impossibility to meet the delay constraint for the second TE LSP.
A second example is related to the bandwidth constraint. It is quite
straightforward to provide examples where a serialized independent
path computation approach would lead to the impossibility to satisfy
both requests (due to bandwidth fragmentation) while a synchronized
path computation would successfully satisfy both requests.
A last example relates to the ability to avoid the allocation of the
same resource to multiple requests thus helping to reduce the call
set up failure probability compared to the serialized computation of
independent requests.
Dependent path computation are usually synchronized. For example, in
the case of the computation of M diverse paths, if such paths are
computed in a non-synchronized fashion this seriously increases the
Vasseur & Le Roux Expires May 21, 2009 [Page 44]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
probability of not being able to satisfy all requests (sometimes also
referred to as the well-know "trapping problem").
Furthermore, this would not allow a PCE to implement objective
functions such as trying to minimize the sum of the TE LSP costs. In
such a case, the path computation requests must be synchronized: they
cannot be computed independently of each other.
Conversely a set of independent path computation requests may or may
not be synchronized.
The synchronization of a set of path computation requests is achieved
by using the SVEC object that specifies the list of synchronized
requests that can either be dependent or independent.
PCEP supports the following three modes:
o Bundle of a set of independent and non-synchronized path
computation requests,
o Bundle of a set of independent and synchronized path computation
requests (SVEC object defined below required),
o Bundle of a set of dependent and synchronized path computation
requests (SVEC object defined below required).
7.13.2. SVEC Object
Section 7.13.1 details the circumstances under which it may be
desirable and/or required to synchronize a set of path computation
requests. The SVEC (Synchronization VECtor) object allows a PCC to
request the synchronization of a set of dependent or independent path
computation requests. The SVEC object is optional and may be carried
within a PCReq message.
The aim of the SVEC object carried within a PCReq message is to
request the synchronization of M path computation requests. The SVEC
object is a variable length object that lists the set of M path
computation requests that must be synchronized. Each path
computation request is uniquely identified by the Request-ID-number
carried within the respective RP object. The SVEC object also
contains a set of flags that specify the synchronization type.
SVEC Object-Class is to be assigned by IANA (recommended value=11)
SVEC Object-Type is to be assigned by IANA (recommended value=1)
Vasseur & Le Roux Expires May 21, 2009 [Page 45]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
The format of the SVEC 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-number #1 | |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SVEC Body Object Format
Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt.
Flags (24 bits): Defines the potential dependency between the set of
path computation requests.
o L (Link diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP
objects MUST NOT have any link in common.
o N (Node diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP
objects MUST NOT have any node in common.
o S (SRLG diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP
objects MUST NOT share any SRLG (Shared Risk Link Group).
In case of a set of M synchronized independent path computation
requests, the bits L, N and S are cleared.
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
The flags defined above are not exclusive.
7.13.3. Handling of the SVEC Object
The SVEC object allows a PCC to specify a list of M path computation
requests that MUST be synchronized along with a potential dependency.
The set of M path computation requests may be sent within a single
PCReq message or multiple PCReq messages. In the later case, it is
RECOMMENDED for the PCE to implement a local timer activated upon the
receipt of the first PCReq message that contains the SVEC object
Vasseur & Le Roux Expires May 21, 2009 [Page 46]
Internet-Draft draft-ietf-pce-pcep-19.txt November 2008
after the expiration of which, if all the M path computation requests
have not been received, a protocol error is triggered (this timer is
called the SyncTimer). When a PCE receives a path computation
request that cannot be satisfied (for example, because the PCReq
message contains an object with the P bit set that is not supported),
the PCE sends a PCErr message for this request (see Section 7.2, the
PCE MUST cancel the whole set of related path computation requests
and MUST send a PCErr message with Error-Type="Synchronized path
computation request missing".
Note that such PCReq message may also contain non-synchronized path
computation requests. For example, the PCReq message may comprise N
synchronized path computation requests related to RP 1, ... , RP N
listed in the SVEC object along with any other path computation
requests that are processed as normal.
7.14. 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=12)
NOTIFICATION Object-Type is to be assigned by IANA (recommended
value=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NOTIFICA
