draft-ietf-pce-pcep-06.txt   draft-ietf-pce-pcep-07.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems
Intended status: Standards Track JL. Le Roux, Ed. Intended status: Standards Track JL. Le Roux, Ed.
Expires: August 17, 2007 France Telecom Expires: September 3, 2007 France Telecom
February 13, 2007 March 2, 2007
Path Computation Element (PCE) communication Protocol (PCEP) Path Computation Element (PCE) communication Protocol (PCEP)
draft-ietf-pce-pcep-06.txt draft-ietf-pce-pcep-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2007. This Internet-Draft will expire on September 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs. (PCC) and a Path Computation Element (PCE), or between two PCEs.
skipping to change at page 2, line 49 skipping to change at page 2, line 49
7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21
7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24
7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26
7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26
7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 29 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 29
7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 30 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 30
7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 31 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 31
7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 34 7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 34
7.9. Route Record Object . . . . . . . . . . . . . . . . . . . 34 7.9. Record Route Object . . . . . . . . . . . . . . . . . . . 34
7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 35 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 35
7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36
7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 37 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 37
7.12.1. Notion of Dependent and Synchronized path 7.12.1. Notion of Dependent and Synchronized path
computation requests . . . . . . . . . . . . . . . . . 37 computation requests . . . . . . . . . . . . . . . . . 37
7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38
7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 40 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 40
7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40
7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43
7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 47 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 47
7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 48 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 48
8. Manageability Considerations . . . . . . . . . . . . . . . . . 49 8. Manageability Considerations . . . . . . . . . . . . . . . . . 49
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8.1. Control of Function and Policy . . . . . . . . . . . . . . 49
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.2. Information and Data Models . . . . . . . . . . . . . . . 50
9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 50 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 51
9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 50 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 51
9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 51 8.5. Requirements on Other Protocols and Functional
9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 52 Componentssection . . . . . . . . . . . . . . . . . . . . 51
9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 53 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 52
10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 60 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 52
11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 60 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 52
11.3. Protection against Denial of Service attacks . . . . . . . 60 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 54
11.4. Request input shaping/policing . . . . . . . . . . . . . . 61 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 54
12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 61 9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 55
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61
14.1. Normative References . . . . . . . . . . . . . . . . . . . 63 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62
14.2. Informative References . . . . . . . . . . . . . . . . . . 63 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 62
Appendix A. Compliance with the PCECP Requirement Document . . . 65 11.3. Protection against Denial of Service attacks . . . . . . . 62
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 65 11.4. Request input shaping/policing . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 67 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Compliance with the PCECP Requirement Document . . . 67
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . . . . . 69
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
Explicit path: full explicit path from start to destination made of a 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 list of strict hops where a hop may be an abstract node such as an
AS. AS.
IGP area: OSPF area or IS-IS level. IGP area: OSPF area or IS-IS level.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
different domains where a domain can either be an IGP area, an different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations). Autonomous System or a sub-AS (BGP confederations).
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a
PCE). PCE).
TED: Traffic Engineering Database that contains the topology and TED: Traffic Engineering Database that contains the topology and
resource information of the domain. The TED may be fed by IGP resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means. extensions or potentially by other means.
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
Strict/loose path: mix of strict and loose hops comprising of at Strict/loose path: mix of strict and loose hops comprising of at
least one loose hop representing the destination where a hop may be least one loose hop representing the destination where a hop may be
skipping to change at page 5, line 40 skipping to change at page 5, line 40
Moreover, it is assumed that the PCE gets the required information so Moreover, it is assumed that the PCE gets the required information so
as to perform the computation of TE LSP that usually requires network as to perform the computation of TE LSP that usually requires network
topology and resource information. Such information can be gathered topology and resource information. Such information can be gathered
by routing protocols or by some other means, the gathering of which by routing protocols or by some other means, the gathering of which
is out of the scope of this document. is out of the scope of this document.
Similarly, no assumption is made on the discovery method used by a Similarly, no assumption is made on the discovery method used by a
PCC to discover a set of PCEs (e.g. via static configuration or PCC to discover a set of PCEs (e.g. via static configuration or
dynamic discovery) and on the algorithm used to select a PCE. For dynamic discovery) and on the algorithm used to select a PCE. For
the sake of reference [RFC4674] defines a list of requirements for the sake of reference [RFC4674] defines a list of requirements for
dynamic PCE discovery and IGP-based solution for such PCE discovery dynamic PCE discovery and IGP-based solutions for such PCE discovery
are specified in [I-D.ietf-pce-disco-proto-ospf] and are specified in [I-D.ietf-pce-disco-proto-ospf] and
[I-D.ietf-pce-disco-proto-isis]. [I-D.ietf-pce-disco-proto-isis].
4. Architectural Protocol Overview (Model) 4. Architectural Protocol Overview (Model)
The aim of this section is to describe the PCEP model in the spirit The aim of this section is to describe the PCEP model in the spirit
of [RFC4101]. An architecture protocol overview (the big picture of of [RFC4101]. An architecture protocol overview (the big picture of
the protocol) is provided in this section. Protocol details can be the protocol) is provided in this section. Protocol details can be
found in further sections. found in further sections.
skipping to change at page 6, line 51 skipping to change at page 7, line 5
- Close message: a message used to close a PCEP session. - Close message: a message used to close a PCEP session.
The set of available PCE(s) may be either statically configured on a The set of available PCE(s) may be either statically configured on a
PCC or dynamically discovered. The mechanisms used to discover one PCC or dynamically discovered. The mechanisms used to discover one
or more PCE(s) and to select a PCE are out of the scope of this or more PCE(s) and to select a PCE are out of the scope of this
document. document.
A PCC may have PCEP sessions with more than one PCE and similarly a A PCC may have PCEP sessions with more than one PCE and similarly a
PCE may have PCEP sessions with multiple PCCs. PCE may have PCEP sessions with multiple PCCs.
The establishment of a PCEP session is always initiated by the PCC.
4.2.1. Initialization Phase 4.2.1. Initialization Phase
The initialization phase consists of two successive steps (described The initialization phase consists of two successive steps (described
in a schematic form in Figure 1): in a schematic form in Figure 1):
1) Establishment of a TCP connection (3-way handshake) between the 1) Establishment of a TCP connection (3-way handshake) between the
PCC and the PCE. PCC and the PCE.
2) Establishment of a PCEP session over the TCP connection. 2) Establishment of a PCEP session over the TCP connection.
skipping to change at page 7, line 36 skipping to change at page 7, line 36
use of an exponential back-off session establishment retry procedure. use of an exponential back-off session establishment retry procedure.
Keepalive messages are used to acknowledge Open messages and once the Keepalive messages are used to acknowledge Open messages and once the
PCEP session has been successfully established, Keepalive messages PCEP session has been successfully established, Keepalive messages
are exchanged between PCEP peers to ensure the liveness of the PCEP are exchanged between PCEP peers to ensure the liveness of the PCEP
session. session.
A single PCEP session can exist between a pair a PCEP peers. A single PCEP session can exist between a pair a PCEP peers.
Details about the Open message and the Keepalive messages can be Details about the Open message and the Keepalive messages can be
found in . (Section 6.2) and Section 6.3 respectively. found inSection 6.2 and Section 6.3 respectively.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---- Open message --->| |---- Open message --->|
| | | |
|<--- Open message ----| |<--- Open message ----|
| | | |
| | | |
| | | |
|<--- Keepalive -------| |<--- Keepalive -------|
| | | |
|---- Keepalive ------>| |---- Keepalive ------>|
Figure 1: PCEP Initialization phase without parameter Figure 1: PCEP Initialization phase (initiated by a PCC)
negotiation(initiated by a PCC)
4.2.2. Path computation request sent by a PCC to a PCE 4.2.2. Path computation request sent by a PCC to a PCE
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
2)PCE Selection | | 2)PCE Selection | |
3)Path computation |---- PCReq message--->| 3)Path computation |---- PCReq message--->|
skipping to change at page 13, line 27 skipping to change at page 13, line 27
|<-- PCErr message ---| |<-- PCErr message ---|
| | | |
Figure 6: Example of Error message (policy violation) sent by a PCE Figure 6: Example of Error message (policy violation) sent by a PCE
Details about the PCErr message can be found in Section 6.7. Details about the PCErr message can be found in Section 6.7.
4.2.6. Termination of the PCEP Session 4.2.6. Termination of the PCEP Session
When one of the PCEP peers desires to terminate a PCEP session it When one of the PCEP peers desires to terminate a PCEP session it
first sends a PCEP Close message and then close the TCP connection. 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 If the PCEP session is terminated by the PCE, the PCC clears all the
states related to pending requests previously sent to the PCE. states related to pending requests previously sent to the PCE.
Similarly, if the PCC terminates a PCEP session the PCE clears all Similarly, if the PCC terminates a PCEP session the PCE clears all
pending path computation requests sent by the PCC in question as well 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 as the related states. A Close message can only be sent to terminate
a PCEP session if the PCEP session has previously been established. a PCEP session if the PCEP session has previously been established.
In case of TCP connection failure, the PCEP session is immediatly In case of TCP connection failure, the PCEP session is immediately
terminated. terminated.
Details about the Close message can be found in Section 6.8. Details about the Close message can be found in Section 6.8.
5. Transport protocol 5. Transport protocol
PCEP operates over TCP using a well-known TCP port (to be assigned by PCEP operates over TCP using a well-known TCP port (to be assigned by
IANA). This allows the requirements of reliable messaging and flow IANA). This allows the requirements of reliable messaging and flow
control to be met without further protocol work. control to be met without further protocol work.
An implementation may decide to keep the TCP session alive for an An implementation may decide to keep the TCP connection alive for an
unlimited time (this may for instance be appropriate when path unlimited time (this may for instance be appropriate when path
computation requests are sent on a frequent basis so as to avoid to computation requests are sent on a frequent basis so as to avoid to
open a TCP session each time a path computation request is needed, open a TCP connection each time a path computation request is needed,
which would incur additional processing delays). Conversely, in some which would incur additional processing delays). Conversely, in some
other circumstances, it may be desirable to systematically open and other circumstances, it may be desirable to systematically open and
close the TCP connection for each PCEP request (for instance when close the TCP connection for each PCEP request (for instance when
sending a path computation request is a rare event). sending a path computation request is a rare event).
6. PCEP Messages 6. PCEP Messages
A PCEP message consists of a common header followed by a variable A PCEP message consists of a common header followed by a variable
length body made of a set of objects that can either be mandatory or length body made of a set of objects that can either be mandatory or
optional. In the context of this document, an object is said to be optional. In the context of this document, an object is said to be
skipping to change at page 15, line 15 skipping to change at page 15, line 15
The following message types are currently defined (to be confirmed by The following message types are currently defined (to be confirmed by
IANA). IANA).
Value Meaning Value Meaning
1 Open 1 Open
2 Keepalive 2 Keepalive
3 Path Computation Request 3 Path Computation Request
4 Path Computation Reply 4 Path Computation Reply
5 Notification 5 Notification
6 Error 6 Error
7 Close 7 Close
Reserved: This field MUST be set to zero on transmission and MUST be
ignored on receipt.
Message Length (32 bits): total length of the PCEP message expressed Message-Length (16 bits): total length of the PCEP message expressed
in bytes including the common header. in bytes including the common header.
6.2. Open message 6.2. Open message
The Open message is a PCEP message sent by a PCC to a PCE and a PCE 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 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 field of the PCEP common header for the Open message is set to 1 (To
be confirmed by IANA). be confirmed by IANA).
Once the TCP connection has been successfully established, the first Once the TCP connection has been successfully established, the first
message sent by the PCC to the PCE or by the PCE to the PCC MUST be message sent by the PCC to the PCE or by the PCE to the PCC MUST be
an Open message. Any message received prior to an Open message an Open message. Any message received prior to an Open message MUST
(other than a Keepalive message) MUST trigger a protocol error trigger a protocol error condition and the PCEP session MUST be
condition and the PCEP session MUST be terminated. The Open message terminated. The Open message is used to establish a PCEP session
is used to establish a PCEP session between the PCEP peers. During between the PCEP peers. During the establishment phase the PCEP
the establishment phase the PCEP peers exchange several session peers exchange several session characteristics. If both parties
characteristics. If both parties agree on such characteristics the agree on such characteristics the PCEP session is successfully
PCEP session is successfully established. established.
Open message Open message
<Open Message>::= <Common Header> <Open Message>::= <Common Header>
<OPEN> <OPEN>
The Open message MUST contain exactly one OPEN object (see The Open message MUST contain exactly one OPEN object (see
Section 7.2). Various session characteristics are specified within Section 7.2). Various session characteristics are specified within
the OPEN object. 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 Section 10 for details).
Once an Open message has been sent to a PCEP peer, the sender MUST Once an Open message has been sent to a PCEP peer, the sender MUST
start an initialization timer called KeepWait after the expiration of start an initialization timer called KeepWait after the expiration of
which if neither an Open message has been received nor a PCErr which if neither a KeepAlive message has been received nor a PCErr
message in case of disagreement of the session characteristics, the message in case of disagreement of the session characteristics, a
TCP connection MUST be released (see Section 10 for details). PCErr message MUST be sent and the TCP connection MUST be released
(see Section 10 for details).
The KeepWait timer has a fixed value of 1 minute. The KeepWait timer has a fixed value of 1 minute.
Upon the receipt of an Open message, the receiving PCEP peer MUST Upon the receipt of an Open message, the receiving PCEP peer MUST
determine whether the suggested PCEP session characteristics are determine whether the suggested PCEP session characteristics are
acceptable. If at least one of the characteristic(s) is not acceptable. If at least one of the characteristic(s) is not
acceptable by the receiving peer, it MUST send an Error message. The acceptable by the receiving peer, it MUST send an Error message. The
Error message SHOULD also contain the related Open object: for each Error message SHOULD also contain the related Open object: for each
unacceptable session parameter, an acceptable parameter value SHOULD unacceptable session parameter, an acceptable parameter value SHOULD
be proposed in the appropriate field of the Open object in place of be proposed in the appropriate field of the Open object in place of
skipping to change at page 16, line 37 skipping to change at page 16, line 39
A Keepalive message is a PCEP message sent by a PCC or a PCE in order A Keepalive message is a PCEP message sent by a PCC or a PCE in order
to keep the session in active state. The Message-Type field of the to keep the session in active state. The Message-Type field of the
PCEP common header for the Keepalive message is set to 2 (To be PCEP common header for the Keepalive message is set to 2 (To be
confirmed by IANA). The Keepalive message does not contain any confirmed by IANA). The Keepalive message does not contain any
object. object.
PCEP has its own keepalive mechanism used to ensure of the liveness PCEP has its own keepalive mechanism used to ensure of the liveness
of the PCEP session. This requires the determination of the of the PCEP session. This requires the determination of the
frequency at which each PCEP peer sends keepalive messages. frequency at which each PCEP peer sends keepalive messages.
Asymmetric values may be chosen; thus there is no constraints Asymmetric values may be chosen; thus there is no constraint
mandating the use of identical keepalive frequencies by both PCEP mandating the use of identical keepalive frequencies by both PCEP
peers. The DeadTimer is defined as the period of time after the 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 expiration of which a PCEP peer declares the session down if no PCEP
message has been received (keepalive or any other PCEP message: thus, message has been received (keepalive or any other PCEP message: thus,
any PCEP message acts as a keepalive message). Similarly, there is any PCEP message acts as a keepalive message). Similarly, there is
no constraints mandating the use of identical DeadTimers by both PCEP no constraints mandating the use of identical DeadTimers by both PCEP
peers. The minimum KeepAliveTimer value is 1 second. peers. The minimum KeepAlive timer value is 1 second.
Keepalive messages are used either to acknowledge an Open message if Keepalive messages are used to acknowledge an Open message if the
the receiving PCEP peer agrees on the session characteristics and to receiving PCEP peer agrees on the session characteristics and to
ensure the liveness of the PCEP session. Keepalive messages are sent ensure the liveness of the PCEP session. Keepalive messages are sent
at the frequency specified in the OPEN object carried within an Open at the frequency specified in the OPEN object carried within an Open
message. Because any PCEP message may serve as Keepalive an message. Because any PCEP message may serve as Keepalive an
implementation may either decide to send Keepalive messages at fixed implementation may either decide to send Keepalive messages at fixed
intervals regardless on whether other PCEP messages might have been intervals regardless on whether other PCEP messages might have been
sent since the last sent Keepalive message or may decide to differ 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 sending of the next Keepalive message based on the time at which
the last PCEP message (other than Keepalive) has been sent. the last PCEP message (other than Keepalive) has been sent.
Keepalive message Keepalive message
<Keepalive Message>::= <Common Header> <Keepalive Message>::= <Common Header>
6.4. Path Computation Request (PCReq) message 6.4. Path Computation Request (PCReq) message
A Path Computation Request message (also referred to as a PCReq A Path Computation Request message (also referred to as a PCReq
message) is a PCEP message sent by a PCC to a PCE so as to request a message) is a PCEP message sent by a PCC to a PCE so as to request a
path computation. The Message-Type field of the PCEP common header path computation. The Message-Type field of the PCEP common header
for the PCReq message is set to 3 (To be confirmed by IANA). for the PCReq message is set to 3 (To be confirmed by IANA).
There is are two mandatory objects that MUST be included within a There are two mandatory objects that MUST be included within a PCReq
PCReq message: the RP and the END-POINTS objects (see section message: the RP and the END-POINTS objects (see section Section 7).
Section 7). If one of these objects is missing, the receiving PCE If one of these objects is missing, the receiving PCE MUST send an
MUST send an error message to the requesting PCC. Other objects are error message to the requesting PCC. Other objects are optional.
optional.
The format of a PCReq message is as follows: The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<SVEC-list>] [<SVEC-list>]
<request-list> <request-list>
where: where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
skipping to change at page 17, line 45 skipping to change at page 17, line 46
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>] [<RRO>]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: where:
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD-
BALANCING objects are defined in Section 7. The special case of two BALANCING objects are defined in Section 7. The special case of two
BANDWIDTH objects is discussed in details in Section 7.6. BANDWIDTH objects is discussed in details in Section 7.6.
6.5. Path Computation Reply (PCRep) message 6.5. Path Computation Reply (PCRep) message
The PCEP Path Computation Reply message (also referred to as a PCRep The PCEP Path Computation Reply message (also referred to as a PCRep
message) is a PCEP message sent by a PCE to a requesting PCC in message) is a PCEP message sent by a PCE to a requesting PCC in
response to a previously received PCReq message. The Message-Type response to a previously received PCReq message. The Message-Type
field of the PCEP common header is set to 4 (To be confirmed by field of the PCEP common header is set to 4 (To be confirmed by
IANA). IANA).
skipping to change at page 20, line 52 skipping to change at page 20, line 52
<request-id-list>:==<RP>[<request-id-list>] <request-id-list>:==<RP>[<request-id-list>]
<error-obj-list>:==<PCEP-ERROR>[<error-obj-list>] <error-obj-list>:==<PCEP-ERROR>[<error-obj-list>]
The procedure upon the reception of a PCErr message is defined in The procedure upon the reception of a PCErr message is defined in
Section 7.14. Section 7.14.
6.8. Close message 6.8. Close message
The Close message is a PCEP message that is either sent by a PCC to a 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 a PCEP session. The PCE or by a PCE to a PCC in order to close an established PCEP
Message-Type field of the PCEP common header for the Open message is session. The Message-Type field of the PCEP common header for the
set to 7 (To be confirmed by IANA). Open message is set to 7 (To be confirmed by IANA).
Close message Close message
<Close Message>::= <Common Header> <Close Message>::= <Common Header>
<CLOSE> <CLOSE>
The Close message MUST contain exactly one CLOSE object (see The Close message MUST contain exactly one CLOSE object (see
Section 6.8). Section 6.8).
Upon the receipt of a Close message, the receiving PCEP peer MUST Upon the receipt of a Close message, the receiving PCEP peer MUST
cancel all pending requests and MUST close the TCP connection. cancel all pending requests and MUST close the TCP connection.
skipping to change at page 23, line 16 skipping to change at page 23, line 16
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | Deadtimer | SID | | Ver | Flags | Keepalive | Deadtimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object format Figure 9: OPEN Object format
Ver (Ver - 4 bits): PCEP version. Current version is 1. Ver (3 bits): PCEP version. Current version is 1.
Flags (4 bits): No Flags are currently defined. Unassigned bits are Flags (5 bits): No Flags are currently defined. Unassigned bits are
considered as reserved and MUST be set to zero on transmission. considered as reserved and MUST be set to zero on transmission.
Keepalive (8 bits): minimum period of time (in seconds) between the Keepalive (8 bits): maximum period of time (in seconds) between the
sending of PCEP messages. The minimum value for the Keepalive is 1 sending of PCEP messages. The minimum value for the Keepalive is 1
second. When set to 0, once the session is established, no further second. When set to 0, once the session is established, no further
Keepalive messages need to be sent to the remote peer. A RECOMMENDED Keepalive messages need to be sent to the remote peer. A RECOMMENDED
value for the keepalive frequency is 30 seconds. value for the keepalive frequency is 30 seconds.
DeadTimer (8 bits): specifies the amount of time after the expiration DeadTimer (8 bits): specifies the amount of time after the expiration
of which a PCEP peer declares the session with the sender of the Open of which a PCEP peer declares the session with the sender of the Open
message down if no PCEP message has been received. The DeadTimer message down if no PCEP message has been received. The DeadTimer
MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value
for the DeadTimer is 4 times the value of the Keepalive. for the DeadTimer is 4 times the value of the Keepalive.
skipping to change at page 25, line 14 skipping to change at page 25, line 14
priority field to 0 in the RP object carried within the corresponding priority field to 0 in the RP object carried within the corresponding
PCRep message, regardless of the priority value contained in the RP PCRep message, regardless of the priority value contained in the RP
object carried within the corresponding PCReq message. A higher object carried within the corresponding PCReq message. A higher
numerical value of the priority field reflects a higher priority. numerical value of the priority field reflects a higher priority.
Note that it is the responsibility of the network administrator to Note that it is the responsibility of the network administrator to
make use of the priority values in a consistent manner across the make use of the priority values in a consistent manner across the
various PCC(s). The ability of a PCE to support requests various PCC(s). The ability of a PCE to support requests
prioritization may be dynamically discovered by the PCC(s) by means prioritization may be dynamically discovered by the PCC(s) by means
of PCE capability discovery. If not advertised by the PCE, a PCC may 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 decide to set the request priority and will learn the ability of the
PCE the support request prioritization by observing the Priority PCE to support request prioritization by observing the Priority field
field of the RP object received in the PCRep message. If the value of the RP object received in the PCRep message. If the value of the
of the Pri field is set to 0, this means that the PCE does not Pri field is set to 0, this means that the PCE does not support the
support the handling of request priorities: in other words, the path handling of request priorities: in other words, the path computation
computation request has been honoured but without taking the request request has been honoured but without taking the request priority
priority into account. into account.
R (Reoptimization - 1 bit): when set, the requesting PCC specifies R (Reoptimization - 1 bit): when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an existing that the PCReq message relates to the reoptimization of an existing
TE LSP in which case, in addition to the TE LSP attributes, the TE LSP in which case, in addition to the TE LSP attributes, the
current path of the existing TE LSP to be reoptimized MUST be current path of the existing TE LSP to be reoptimized MUST be
provided in the PCReq (except for 0-bandwidth TE LSP) message by provided in the PCReq (except for 0-bandwidth TE LSP) message by
means of an RRO object defined in Section 7.9. means of an RRO object defined in Section 7.9.
B (Bi-directional - 1 bit): when set, the PCC specifies that the path B (Bi-directional - 1 bit): when set, the PCC specifies that the path
computation request relates to a bidirectional TE LSP that has the computation request relates to a bidirectional TE LSP that has the
skipping to change at page 26, line 16 skipping to change at page 26, line 16
computation requests sent to different PCEs. The path computation computation requests sent to different PCEs. The path computation
reply is unambiguously identified by the IP source address of the reply is unambiguously identified by the IP source address of the
replying PCE. replying PCE.
7.3.2. Handling of the RP object 7.3.2. Handling of the RP object
If a PCReq message is received without containing an RP object, the If a PCReq message is received without containing an RP object, the
PCE MUST send a PCErr message to the requesting PCC with Error- PCE MUST send a PCErr message to the requesting PCC with Error-
type="Required Object missing" and Error-value="RP Object missing". type="Required Object missing" and Error-value="RP Object missing".
If the O bit of the RP message carried within a PCReq message is set If the O bit of the RP message carried within a PCReq message is
and local policy has been configured on the PCE to not provide cleared and local policy has been configured on the PCE to not
explicit path(s) (for instance, for confidentiality reasons), a PCErr provide explicit path(s) (for instance, for confidentiality reasons),
message MUST be sent by the PCE to the requesting PCC and the pending a PCErr message MUST be sent by the PCE to the requesting PCC and the
path computation request MUST be discarded. The Error-type is pending path computation request MUST be discarded. The Error-type
"Policy Violation" and Error-value is "O bit set". is "Policy Violation" and Error-value is "O bit set".
R bit: when the R bit of the RP object is set in a PCReq message, 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 this indicates that the path computation request relates to the
reoptimization of an existing TE LSP. In this case, the PCC MUST 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 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 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 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 a strict path (O bit set), a reoptimization can still be
requested by the PCC but this implies for the PCE to be either requested by the PCC but this implies for the PCE to be either
stateful (keep track of the previously computed path with the stateful (keep track of the previously computed path with the
skipping to change at page 26, line 47 skipping to change at page 26, line 47
trigger the sending of a PCErr message with Error-type="Required trigger the sending of a PCErr message with Error-type="Required
Object Missing" and Error-value="RRO Object missing for Object Missing" and Error-value="RRO Object missing for
reoptimization". reoptimization".
If the PCC receives a PCRep message that contains a RP object If the PCC receives a PCRep message that contains a RP object
referring to an unknown Request-ID-Number, the PCC MUST send a PCErr referring to an unknown Request-ID-Number, the PCC MUST send a PCErr
message with Error-Type="Unknown request reference". message with Error-Type="Unknown request reference".
7.4. NO-PATH Object 7.4. NO-PATH Object
The No-PATH object is used in PCRep messages in response to an The NO-PATH object is used in PCRep messages in response to an
unsuccessful path computation request (the PCE could not find a path unsuccessful path computation request (the PCE could not find a path
satisfying the set of constraints). When a PCE cannot 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 satisfying a set of constraints, it MUST include a NO-PATH object in
the PCRep message. The NO-PATH object is used to report the the PCRep message. The NO-PATH object is used to report the
impossibility to find a path that satisfies the set of constraints. impossibility to find a path that satisfies the set of constraints.
Optionally, if the PCE supports such capability, the NO-PATH object Optionally, if the PCE supports such capability, the NO-PATH object
MAY contain an optional NO-PATH-VECTOR TLV defined below and the MAY contain an optional NO-PATH-VECTOR TLV defined below and the
PCRep message MAY also contain a list of objects that specify the set PCRep message MAY also contain a list of objects that specify the set
of constraints that could not be satisfied. The PCE MAY just of constraints that could not be satisfied. The PCE MAY just
replicate the set of object(s) that was received that was the cause replicate the set of object(s) that was received that was the cause
skipping to change at page 28, line 36 skipping to change at page 28, line 36
TYPE: To be assigned by IANA TYPE: To be assigned by IANA
LENGTH: 4 LENGTH: 4
VALUE: 32-bits flags field VALUE: 32-bits flags field
IANA is requested to manage the space of flags carried in the NO-PATH-VECTOR TLV (see IANA section). IANA is requested to manage the space of flags carried in the NO-PATH-VECTOR TLV (see IANA section).
The following flags are currently defined: The following flags are currently defined:
0x01: PCE currently unavailable 0x01: PCE currently unavailable
0x02: Unknown destination 0x02: Unknown destination
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.
Flags (16 bits). The following flags are currently defined: Flags (16 bits).
Reserved: This field MUST be set to zero on transmission and MUST be The following flag is currently defined:
ignored on receipt.
C flag (1 bit): when set, the PCE indicates the set of unsatisfied C flag (1 bit): when set, the PCE indicates the set of unsatisfied
constraints (reasons why a path could not be found) in the PCRep constraints (reasons why a path could not be found) in the PCRep
message by including the relevant PCEP objects. When cleared, no message by including the relevant PCEP objects. When cleared, no
reason is specified. reason is specified.
Reserved: 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 Example: consider the case of a PCC that sends a path computation
request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot
find a path for X MBits/s. In this case, the PCE must include in the 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 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 original BANDWIDTH object so as to indicate that the reason for
the unsuccessful computation is the bandwidth constraint (in this the unsuccessful computation is the bandwidth constraint (in this
case, the C flag is set). If the PCE supports such capability it may case, the C flag is set). If the PCE supports such capability it may
alternatively include the BANDWIDTH Object and report a value of Y in 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 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 is set) where Y refers to the bandwidth for which a TE LSP with the
skipping to change at page 33, line 5 skipping to change at page 33, line 5
o T=2: TE metric o T=2: TE metric
o T=3: Hop Counts o T=3: Hop Counts
B (Bound - 1 bit): When set in a PCReq message, the metric-value B (Bound - 1 bit): When set in a PCReq message, the metric-value
indicates a bound (a maximum) for the path cost that must not be indicates a bound (a maximum) for the path cost that must not be
exceeded for the PCC to consider the computed path as acceptable. exceeded for the PCC to consider the computed path as acceptable.
When the B flag is cleared, the metric-value field is not used to When the B flag is cleared, the metric-value field is not used to
reflect a bound constraint. reflect a bound constraint.
C (Cost - 1 bit): When set in a PECReq message, this indicates that C (Cost - 1 bit): When set in a PCReq message, this indicates that
the PCE MUST provide the computed path cost (should a path satisfying the PCE MUST provide the computed path cost (should a path satisfying
the constraints be found) in the PCRep message for the corresponding the constraints be found) in the PCRep message for the corresponding
metric. metric.
Metric-value (32 bits): metric value encoded in 32 bits in IEEE Metric-value (32 bits): metric value encoded in 32 bits in IEEE
floating point format. floating point format.
Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 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 message. There MUST be at most one instance of the METRIC object for
each metric type. In two or more instances of a METRIC object are each metric type. If two or more instances of a METRIC object are
present for a metric type, only the first instance MUST be considered present for a metric type, only the first instance MUST be considered
and other instances MUST be ignored. and other instances MUST be ignored.
In a PCReq message the presence of multiple METRIC object can be used In a PCReq message the presence of multiple METRIC object can be used
to specify a multi-parameters (e.g. a metric may be a constraint or a to specify a multi-parameters (e.g. a metric may be a constraint or a
parameter to minimize/maximize) objective function or multiple bounds parameter to minimize/maximize) objective function or multiple bounds
for different constraints where at most one METRIC object must be for different constraints where at most one METRIC object must be
used to indicate the metric to optimize (B-flag is cleared): the used to indicate the metric to optimize (B-flag is cleared): the
other METRIC object MUST be used to reflect bound constraints (B-Flag other METRIC object MUST be used to reflect bound constraints (B-Flag
is set). is set).
skipping to change at page 34, line 38 skipping to change at page 34, line 38
PCEP ERO sub-object types correspond to RSVP ERO sub-object types. PCEP ERO sub-object types correspond to RSVP ERO sub-object types.
Since the explicit path is available for immediate signaling by the Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO. and fields in this object are identical to those defined for the ERO.
ERO Object-Class is to be assigned by IANA (recommended value=7) ERO Object-Class is to be assigned by IANA (recommended value=7)
ERO Object-Type is to be assigned by IANA (recommended value=1) ERO Object-Type is to be assigned by IANA (recommended value=1)
7.9. Route Record Object 7.9. Record Route Object
The RRO is used to record the route followed by a TE LSP. The PCEP The RRO is used to record the route followed by a TE LSP. The PCEP
RRO is exclusively carried within a PCReq message so as to specify RRO is exclusively carried within a PCReq message so as to specify
the route followed by a TE LSP for which a reoptimization is desired. 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 The contents of this object are identical in encoding to the contents
of the Route Record Object defined in [RFC3209], [RFC3473] and of the Route Record Object defined in [RFC3209], [RFC3473] and
[RFC3477]. That is, the object is constructed from a series of sub- [RFC3477]. That is, the object is constructed from a series of sub-
objects. Any RSVP RRO sub-object already defined or that could be objects. Any RSVP RRO sub-object already defined or that could be
defined in the future for use in the RRO is acceptable in this defined in the future for use in the RRO is acceptable in this
skipping to change at page 37, line 21 skipping to change at page 37, line 21
7.12. SVEC Object 7.12. SVEC Object
7.12.1. Notion of Dependent and Synchronized path computation requests 7.12.1. Notion of Dependent and Synchronized path computation requests
Independent versus dependent path computation requests: path Independent versus dependent path computation requests: path
computation requests are said to be independent if they are not computation requests are said to be independent if they are not
related to each other. Conversely a set of dependent path related to each other. Conversely a set of dependent path
computation requests is such that their computations cannot be computation requests is such that their computations cannot be
performed independently of each other (a typical example of dependent performed independently of each other (a typical example of dependent
requests is the computation of a set of diverse paths. requests is the computation of a set of diverse paths).
Synchronized versus non-synchronized path computation requests: a set Synchronized versus non-synchronized path computation requests: a set
of path computation requests is said to be non-synchronized if their of path computation requests is said to be non-synchronized if their
respective treatment (path computations) can be performed by a PCE in respective treatment (path computations) can be performed by a PCE in
a serialized and independent fashion. a serialized and independent fashion.
There are various circumstances where the synchronization of a set of There are various circumstances where the synchronization of a set of
path computations may be beneficial or required. path computations may be beneficial or required.
Consider the case of a set of N TE LSPs for which a PCC needs to send Consider the case of a set of N TE LSPs for which a PCC needs to send
skipping to change at page 42, line 23 skipping to change at page 42, line 23
Notification-value=2 is carried within a PCNtf message sent by Notification-value=2 is carried within a PCNtf message sent by
a PCE to a PCC. The RP object corresponding to the cancelled a PCE to a PCC. The RP object corresponding to the cancelled
request MUST also be present in the PCNtf message. Multiple RP request MUST also be present in the PCNtf message. Multiple RP
objects may be carried within the PCNtf message in which case objects may be carried within the PCNtf message in which case
the notification applies to all of them. If such notification the notification applies to all of them. If such notification
is received by a PCE from a PCC, the PCE MUST silently ignore is received by a PCE from a PCC, the PCE MUST silently ignore
the notification and no errors should be generated. the notification and no errors should be generated.
o Notification-type=2: PCE congestion o Notification-type=2: PCE congestion
* Notification-value=1. A Notification-type=2, Notification- * Notification-value=1: A Notification-type=2, Notification-
value=1 indicates to the PCC(s) that the PCE is currently in a value=1 indicates to the PCC(s) that the PCE is currently in a
congested state. If no RP objects are comprised in the PCNtf congested state. If no RP objects are comprised in the PCNtf
message, this indicates that no other requests SHOULD be sent message, this indicates that no other requests SHOULD be sent
to that PCE until the congested state is cleared: the pending to that PCE until the congested state is cleared: the pending
requests are not affected and will be served. If some pending requests are not affected and will be served. If some pending
requests cannot be served due to the congested state, the PCE requests cannot be served due to the congested state, the PCE
MUST also include a set of RP object(s) that identifies the set MUST also include a set of RP object(s) that identifies the set
of pending requests that are cancelled by the PCE and will not of pending requests that are cancelled by the PCE and will not
be honored. In this case, the PCE does not have to send an be honored. In this case, the PCE does not have to send an
additional PCNtf message with Notification-type=1 and additional PCNtf message with Notification-type=1 and
skipping to change at page 43, line 21 skipping to change at page 43, line 21
1 octet specifying the number of bytes in the value field, 2 octets 1 octet specifying the number of bytes in the value field, 2 octets
for an "Unused" field (the value of which MUST be set to 0), followed by for an "Unused" field (the value of which MUST be set to 0), followed by
a fix length value field of 4 octets specifying the estimated PCE a fix length value field of 4 octets specifying the estimated PCE
congestion duration in seconds. The CONGESTION-DURATION TLV is padded congestion duration in seconds. The CONGESTION-DURATION TLV is padded
to eight-octet alignment. to eight-octet alignment.
TYPE: To be assigned by IANA TYPE: To be assigned by IANA
LENGTH: 4 LENGTH: 4
VALUE: estimated congestion duration in seconds VALUE: estimated congestion duration in seconds
* If a new PCEP session is established while the PCE is in * Notification-value=2: A Notification-type=2, Notification-
congested state, the PCE MUST immediately send a PCNtf with
Notification-type=2, Notification-value=1 along with the
optional CONGESTION-DURATION TLV.
* Notification-value=2. A Notification-type=2, Notification-
value=2 indicates that the PCE is no longer in congested state value=2 indicates that the PCE is no longer in congested state
and is available to process new path computation requests. An and is available to process new path computation requests. An
implementation MUST make sure that a PCE sends such implementation MUST make sure that a PCE sends such
notification to every PCC to which a Notification message (with notification to every PCC to which a Notification message (with
Notification-type=2, Notification-value=1) has been sent unless Notification-type=2, Notification-value=1) has been sent unless
a CONGESTION-DURATION TLV has been included in the a CONGESTION-DURATION TLV has been included in the
corresponding message and the PCE wishes to wait for the corresponding message and the PCE wishes to wait for the
expiration of that period of time before receiving new expiration of that period of time before receiving new
requests. If such notification is received by a PCE from a requests. If such notification is received by a PCE from a
PCC, the PCE MUST silently ignore the notification and no PCC, the PCE MUST silently ignore the notification and no
skipping to change at page 44, line 42 skipping to change at page 44, line 36
Reserved (8 bits): This field MUST be set to zero on transmission and Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
Flags (8 bits): no flag is currently defined. Flags (8 bits): no flag is currently defined.
Error-type (8 bits): defines the class of error. Error-type (8 bits): defines the class of error.
Error-value (8 bits): provides additional details about the error. Error-value (8 bits): provides additional details about the error.
Optionally the PCEP-ERROR object may contain additional TLV so as to Optionally the PCEP-ERROR object may contain additional TLV so as to
provide further information about the encountered error. No TLV is provide further information about the encountered error.
currently defined.
A single PCErr message may contain multiple PCEP-ERROR objects. A single PCErr message may contain multiple PCEP-ERROR objects.
For each PCEP error, an Error-type and an Error-value are defined. For each PCEP error, an Error-type and an Error-value are defined.
Error-Type Meaning Error-Type Meaning
1 PCEP session establishment failure 1 PCEP session establishment failure
Error-value=1: reception of a malformed Open message Error-value=1: reception of a malformed message
Error-value=2: no Open message received before the expiration Error-value=2: no Open message received before the expiration
of the OpenWait timer of the OpenWait timer
Error-value=3: unacceptable and non negotiable session Error-value=3: unacceptable and non negotiable session
characteristics characteristics
Error-value=4: unacceptable but negotiable session Error-value=4: unacceptable but negotiable session
characteristics characteristics
Error-value=5: reception of a second Open message Error-value=5: reception of a second Open message
with still unacceptable session characteristics with still unacceptable session characteristics
Error-value=6: reception of a PCErr message proposing Error-value=6: reception of a PCErr message proposing
unacceptable session characteristics unacceptable session characteristics
skipping to change at page 45, line 34 skipping to change at page 45, line 34
Error-value=2: Unrecognized object Type Error-value=2: Unrecognized object Type
4 Not supported object 4 Not supported object
Error-value=1: Not supported object class Error-value=1: Not supported object class
Error-value=2: Not supported object Type Error-value=2: Not supported object Type
5 Policy violation 5 Policy violation
Error-value=1: C bit of the METRIC object set (request rejected) Error-value=1: C bit of the METRIC object set (request rejected)
Error-value=2: O bit of the RP object set (request rejected) Error-value=2: O bit of the RP object set (request rejected)
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=1: RP object missing Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set) request (R bit of the RP object set) when bandwidth
is not equal to 0.
Error-value=3: END-POINTS object missing Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing 7 Synchronized path computation request missing
8 Unknown request reference 8 Unknown request reference
9 DeadTimer expired 9 Attempt to establish a second PCEP session
10 Attempt to establish a second PCEP session
Error-Type=1: PCEP session establishment failure. Error-Type=1: PCEP session establishment failure.
If a malformed Open message is received, the receiving PCEP peer MUST If a malformed message is received, the receiving PCEP peer MUST send
send a PCErr message with Error-type=1, Error-value=1. a PCErr message with Error-type=1, Error-value=1.
If no Open message is received before the expiration of the OpenWait If no Open message is received before the expiration of the OpenWait
timer, the receiving PCEP peer MUST send a PCErr message with Error- timer, the receiving PCEP peer MUST send a PCErr message with Error-
type=1, Error-value=2 (see Section 10 for details). type=1, Error-value=2 (see Section 10 for details).
If one or more PCEP session characteristic(s) are unacceptable by the If one or more PCEP session characteristic(s) are unacceptable by the
receiving peer and are not negotiable, it MUST send a PCErr message receiving peer and are not negotiable, it MUST send a PCErr message
with Error-type=1, Error-value=3. with Error-type=1, Error-value=3.
If an Open message is received with unacceptable session If an Open message is received with unacceptable session
skipping to change at page 46, line 33 skipping to change at page 46, line 33
message with Error-type=1, Error-value=7. message with Error-type=1, Error-value=7.
Error-Type=2: the PCE indicates that the path computation request Error-Type=2: the PCE indicates that the path computation request
cannot be honored because it does not support one or more required cannot be honored because it does not support one or more required
capability. The corresponding path computation request MUST be capability. The corresponding path computation request MUST be
cancelled. cancelled.
Error-Type=3 or Error-Type=4: if a PCEP message is received that Error-Type=3 or Error-Type=4: if a PCEP message is received that
carries a PCEP object (with the P flag set) not recognized by the PCE carries a PCEP object (with the P flag set) not recognized by the PCE
or recognized but not supported, then the PCE MUST send a PCErr or recognized but not supported, then the PCE MUST send a PCErr
message with a PCEP-ERROR object (Error-Type=2 and 3 respectively). message with a PCEP-ERROR object (Error-Type=3 and 4 respectively).
The corresponding path computation request MUST be cancelled by the In addition, the PCC MAY include in the PCErr message the unknown
PCE without further notification. object. The corresponding path computation request MUST be cancelled
by the PCE without further notification.
Error-Type=5: if a path computation request is received that is not Error-Type=5: if a path computation request is received that is not
compliant with an agreed policy between the PCC and the PCE, the PCE 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=5). MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5).
The corresponding path computation MUST be cancelled. Policy- The corresponding path computation MUST be cancelled. Policy-
specific TLV(s) carried within the PCEP-ERROR object may be defined specific TLV(s) carried within the PCEP-ERROR object may be defined
in other documents to specify the nature of the policy violation. in other documents to specify the nature of the policy violation.
Error-Type=6: if a path computation request is received that does not Error-Type=6: if a path computation request is received that does not
contain a mandatory object, the PCE MUST send a PCErr message with a contain a mandatory object, the PCE MUST send a PCErr message with a
skipping to change at page 47, line 25 skipping to change at page 47, line 26
a fix length value field of 4 octets specifying the request-id-number a fix length value field of 4 octets specifying the request-id-number
that correspond to the missing request. The REQ-MISSING TLV is padded that correspond to the missing request. The REQ-MISSING TLV is padded
to eight-octet alignment. to eight-octet alignment.
TYPE: To be assigned by IANA TYPE: To be assigned by IANA
LENGTH: 4 LENGTH: 4
VALUE: request-id-number that corresponds to the missing request VALUE: request-id-number that corresponds to the missing request
Error-Type=8: if a PCC receives a PCRep message related to an unknown Error-Type=8: if a PCC receives a PCRep message related to an unknown
path computation request, the PCC MUST send a PCErr message with a path computation request, the PCC MUST send a PCErr message with a
PCEP-ERROR object (Error-Type=7). In addition, the PCC MUST include PCEP-ERROR object (Error-Type=8). In addition, the PCC MUST include
in the PCErr message the unknown RP object. in the PCErr message the unknown RP object.
Error-Type=9: If a PCEP peer does not receive any PCEP message Error-Type=9: if a PCEP peer detects an attempt from another PCEP
(Keepalive, PCReq, PCRep, PCNtf) during the DeadTimer period, the
PCEP peer MUST send a PCErr message with a PCEP-ERROR object (Error-
type=9, Error-value=1). The PCEP session MUST be terminated
according to the procedure defined in Section 6.8.
Error-Type=10: If a PCEP peer detects an attempt from another PCEP
peer to establish a second PCEP session, it MUST send a PCErr message peer to establish a second PCEP session, it MUST send a PCErr message
with Error-type=9, Error-value=1. The existing PCEP session MUST be with Error-type=9, Error-value=1. The existing PCEP session MUST be
preserved and all subsequent messages related to the tentative preserved and all subsequent messages related to the tentative
establishment of the second PCEP session MUST be silently ignored. establishment of the second PCEP session MUST be silently ignored.
7.15. LOAD-BALANCING Object 7.15. LOAD-BALANCING Object
There are situations where no TE LSP with a bandwidth of X could be There are situations where no TE LSP with a bandwidth of X could be
found by a PCE while such bandwidth requirement could be satisfied by found by a PCE while such bandwidth requirement could be satisfied by
a set of TE LSPs such that the sum of their bandwidths is equal to X. a set of TE LSPs such that the sum of their bandwidths is equal to X.
skipping to change at page 48, line 25 skipping to change at page 48, line 20
| Reserved | flags | Max-LSP | | Reserved | flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth | | Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: LOAD-BALANCING object body format Figure 21: LOAD-BALANCING object body format
Reserved : This field MUST be set to zero on transmission and MUST be Reserved : This field MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
Flags () Flags: No Flag is currently defined.
Max-LSP - 8 bits: maximum number of TE LSPs in the set Max-LSP - 8 bits: maximum number of TE LSPs in the set
Min-Bandwidth - 32 bits. Specifies the minimum bandwidth of each Min-Bandwidth - 32 bits. Specifies the minimum bandwidth of each
element of the set of TE LSPs. The bandwidth is encoded in 32 bits element of the set of TE LSPs. The bandwidth is encoded in 32 bits
in IEEE floating point format, expressed in bytes per second. in IEEE floating point format, expressed in bytes per second.
The LOAD-BALANCING object body has a fixed length of 8 octets. The LOAD-BALANCING object body has a fixed length of 8 octets.
If a PCC requests the computation of a set of TE LSP(s) so that the If a PCC requests the computation of a set of TE LSP(s) so that the
skipping to change at page 49, line 17 skipping to change at page 49, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason | | Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: CLOSE Object format Figure 22: CLOSE Object format
Reason (4 bits): specifies the reason for closing the PCEP session. Reason (4 bits): specifies the reason for closing the PCEP session.
The setting of this field is optional. Three values are currently The setting of this field is optional. The following values are
defined. currently defined.
Reasons Reasons
Value Meaning Value Meaning
1 No explanation provided 1 No explanation provided
2 DeadTimer expired 2 DeadTimer expired
3 PCEP session characteristics negotiation failure 3 PCEP session characteristics negotiation failure
4 Reception of a malformed PCEP message 4 Reception of a malformed PCEP message
Reserved: This field MUST be set to zero on transmission and MUST be Reserved: This field MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
Flags (4 bits): No Flags are currently defined. Flags (4 bits): No Flags are currently defined.
Optional TLVs may be included within the CLOSE object body. The Optional TLVs may be included within the CLOSE object body. The
specification of such TLVs is outside the scope of this document. specification of such TLVs is outside the scope of this document.
8. Manageability Considerations 8. Manageability Considerations
It is expected and required to specify a MIB for the PCEP This section is compliant with
communication protocol (in a separate document). Furthermore, [I-D.ietf-pce-manageability-requirements].
additional tools related to performance, fault and diagnostic
detection are required which will also be specified in separate 8.1. Control of Function and Policy
documents.
A PCEP implementation SHOULD allow configuring the following PCEP
session parameters on a PCEP peer:
o The local keepalive and Deadtimer (i.e. parameters send by the
PCEP speaker in an Open message),
o The maximum acceptable remote keepalive and dead timers
(i.e.parameters sent by a peer in an Open message),
o Negotiation enabled or disabled,
o If negotiation is allowed, the minimum acceptable Keepalive and
Deadtimer timers sent by a PCEP peer,
o The SyncTimer,
o The maximum number of sessions that can be setup
o Request timer: amount of time a PCC waits for a reply before
resending its path computation requests (potentially to an
alternate PCE).
These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific
session with a given PCEP peer or a specific group of sessions with a
specific group of PCEP peers. A PCEP implementation SHOULD allow
configuring the initiation of a PCEP session with a selected subset
of discovered PCEs. Note that PCE selection is a local
implementation issue. A PCEP implementation SHOULD allow configuring
a specific PCEP session with a given PCEP peer. This includes the
configuration of the following parameters:
o The IP address of the PCEP peer,
o The PCEP speaker role: PCC, PCE or both,
o Whether the PCEP speaker should initiate the PCEP session or wait
for initiation by the peer,
o The PCEP session parameters, as listed above, if they differ from
the default parameters,
o A set of PCEP policies including the type of operations allowed
for the PCEP peer (e.g. diverse path computation, synchronization,
etc.)
A PCEP implementation MUST allow restricting the set of PCEP peers
that can initiate a PCEP session with the PCEP speaker (e.g. list of
authorized PCEP peers, all PCEP peers in the area, all PCEP peers in
the AS).
8.2. Information and Data Models
A PCEP MIB module is defined in [I-D.kkoushik-pce-pcep-mib] that
describes managed objects for modeling of PCEP communication
including:
o PCEP client configuration and status,
o PCEP peer configuration and information,
o PCEP session configuration and information,
o Notifications to indicate PCEP session changes.
8.3. Liveness Detection and Monitoring
PCEP includes a keepalive mechanism, allowing checking the liveliness
of a PCEP peer and a notification procedure allowing a PCE to
advertise its congestion state to a PCC. Also, procedures in order
to monitor the liveliness and performances of a given PCE chain (in
case of Multiple-PCE path computation) are defined in
[I-D.vasseur-pce-monitoring].
8.4. Verifying Correct Operation
Verifying the correct operation of a PCEP communication can be
performed by monitoring various parameters. A PCEP implementation
SHOULD provide the following parameters:
o Response time (minimum, average and maximum), on a per PCE Peer
basis,
o PCEP Session failures,
o Amount of time the session has been in active state,
o Number of corrupted messages,
o Number of failed computations,
o Number of requests for which no reply has been received after the
expiration of a configurable timer and by verifying that a
returned path fit in with the requested TE parameters.
A PCEP implementation SHOULD log error events (e.g. corrupted
messages, unrecognized objects, etc.).
8.5. Requirements on Other Protocols and Functional Componentssection
PCEP does not put any new requirements on other protocols. As PCEP
relies on the TCP transport protocol, PCEP management can make use of
TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).
The PCE Discovery mechanisms ([I-D.ietf-pce-disco-proto-isis],
[I-D.ietf-pce-disco-proto-ospf]) may have an impact on PCEP. To
avoid that a high frequency of PCE Discovery/Disappearance trigger
high frequency of PCEP session setup/deletion, it is RECOMMENDED to
introduce some dampening for establishment of PCEP sessions.
8.6. Impact on Network Operation
In order to avoid any unacceptable impact on network operations, an
implementation SHOULD allow limiting the number of session that can
be setup on a PCEP speaker, and MAY allow limiting the rate of
messages sent by a PCEP speaker and received from a peer. It MAY
also allow sending a notification when a rate threshold is reached.
9. IANA Considerations 9. IANA Considerations
9.1. TCP Port 9.1. TCP Port
PCEP will use a well-known TCP port to be assigned by IANA. PCEP will use a well-known TCP port to be assigned by IANA.
9.2. PCEP Messages 9.2. PCEP Messages
Each PCEP message has a Message-Type. Each PCEP message has a Message-Type.
skipping to change at page 53, line 8 skipping to change at page 55, line 8
9.5. PCEP Error 9.5. PCEP Error
PCEP-ERROR objects are used to report a PCEP error and are PCEP-ERROR objects are used to report a PCEP error and are
characterized by an Error-Type which specifies the type of error and characterized by an Error-Type which specifies the type of error and
an Error-value that provides additional information about the error an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value are managed by IANA. type. Both the Error-Type and the Error-Value are managed by IANA.
For each PCEP error, an Error-type and an Error-value are defined. For each PCEP error, an Error-type and an Error-value are defined.
Error-Type Meaning Error-Type Meaning
1 PCEP session establishment failure 1 PCEP session establishment failure
Error-value=1: reception of a malformed Open message Error-value=1: reception of a malformed message
Error-value=2: no Open message received before the expiration Error-value=2: no Open message received before the expiration
of the OpenWait timer of the OpenWait timer
Error-value=3: unacceptable and non negotiable session Error-value=3: unacceptable and non negotiable session
characteristics characteristics
Error-value=4: unacceptable but negotiable session Error-value=4: unacceptable but negotiable session
characteristics characteristics
Error-value=5: reception of a second Open message Error-value=5: reception of a second Open message
with still unacceptable session characteristics with still unacceptable session characteristics
Error-value=6: reception of a PCErr message proposing Error-value=6: reception of a PCErr message proposing
unacceptable session characteristics unacceptable session characteristics
skipping to change at page 53, line 38 skipping to change at page 55, line 38
5 Policy violation 5 Policy violation
Error-value=1: C bit of the METRIC object set (request rejected) Error-value=1: C bit of the METRIC object set (request rejected)
Error-value=2: O bit of the RP object set (request rejected) Error-value=2: O bit of the RP object set (request rejected)
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=1: RP object missing Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set) request (R bit of the RP object set)
Error-value=3: END-POINTS object missing Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing 7 Synchronized path computation request missing
8 Unknown request reference 8 Unknown request reference
9 DeadTimer expired 9 Attempt to establish a second PCEP session
10 Attempt to establish a second PCEP session
9.6. NO-PATH-VECTOR TLV 9.6. NO-PATH-VECTOR TLV
IANA is requested to manage the space of flags carried in the NO- IANA is requested to manage the space of flags carried in the NO-
PATH-VECTOR TLV defined in this document, numbering them in the usual PATH-VECTOR TLV defined in this document, numbering them in the usual
IETF notation starting at zero and continuing through 31. IETF notation starting at zero and continuing through 31.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: - Bit number Each bit should be tracked with the following qualities: - Bit number
skipping to change at page 55, line 16 skipping to change at page 57, line 16
connection using the PCEP well-known TCP port. The value of the connection using the PCEP well-known TCP port. The value of the
TCPConnect timer is 60 seconds. TCPConnect timer is 60 seconds.
TCPRetry: specifies the number of times the system has tried to TCPRetry: specifies the number of times the system has tried to
establish a TCP connection with a PCEP peer without success. establish a TCP connection with a PCEP peer without success.
TCPMaxRetry: Maximum number of times the system tries to establish a TCPMaxRetry: Maximum number of times the system tries to establish a
TCP connection using the PCEP well-known TCP port before going back TCP connection using the PCEP well-known TCP port before going back
to the Idle state. The value of the TCPMaxRetry is 5. to the Idle state. The value of the TCPMaxRetry is 5.
OpenWait: timer (in seconds) that corresponds to the amount of time a OpenWait: timer that corresponds to the amount of time a PCEP peer
PCEP peer will wait to receive an Open message from the PCEP peer will wait to receive an Open message from the PCEP peer after the
after the expiration of which the system releases the PCEP resource expiration of which the system releases the PCEP resource and go back
and go back to the Idle state. to the Idle state. The OpenWait timer has a fixed value of 1 minute.
KeepWait: timer that corresponds to the amount of time a PCEP peer KeepWait: timer that corresponds to the amount of time a PCEP peer
will wait to receive a KeepAlive or a PCErr message from the PCEP will wait to receive a KeepAlive or a PCErr message from the PCEP
peer after the expiration of which the system releases the PCEP peer after the expiration of which the system releases the PCEP
resource and go back to the Idle state. The KeepWait timer has a resource and go back to the Idle state. The KeepWait timer has a
fixed value of 1 minute. fixed value of 1 minute.
OpenRetry: specifies the number of times the system has received an OpenRetry: specifies the number of times the system has received an
Open message with unacceptable PCEP session characteristics. Open message with unacceptable PCEP session characteristics.
skipping to change at page 56, line 24 skipping to change at page 58, line 24
o Starts the TCPConnect timer, o Starts the TCPConnect timer,
o Initiates of a TCP connection with the PCEP peer, o Initiates of a TCP connection with the PCEP peer,
o Increments the TCPRetry variable, o Increments the TCPRetry variable,
o Moves to the TCPPending state. o Moves to the TCPPending state.
Upon receiving a TCP connection on the well-known PCEP TCP port, if Upon receiving a TCP connection on the well-known PCEP TCP port, if
the PCE is in congested state, the PCE MUST immediately send a PCErr
with Notification-type=2, Notification-value=1 along with the
optional CONGESTION-DURATION TLV (see Section 7.13).
Upon receiving a TCP connection on the well-known PCEP TCP port, if
the TCP connection establishment succeeds, the system: the TCP connection establishment succeeds, the system:
o Sends an Open message, o Sends an Open message,
o Starts the OpenWait timer, o Starts the OpenWait timer,
o Stars the KeepWait timer, o Stars the KeepWait timer,
o Moves to the OpenWait state. o Moves to the OpenWait state.
skipping to change at page 57, line 47 skipping to change at page 59, line 41
attributes (Keepalive frequency, DeadTimer, ...). attributes (Keepalive frequency, DeadTimer, ...).
If an error is detected (e.g. malformed Open message, presence of two If an error is detected (e.g. malformed Open message, presence of two
Open objects, ...), PCEP generates an error notification, the PCEP Open objects, ...), PCEP generates an error notification, the PCEP
peer sends a PCErr message with Error-Type=1 and Error-value=1. The peer sends a PCErr message with Error-Type=1 and Error-value=1. The
system releases the PCEP resources for the PCEP peer, closes the TCP system releases the PCEP resources for the PCEP peer, closes the TCP
connection and moves to the Idle state. connection and moves to the Idle state.
If no errors are detected, PCEP increments the OpenRetry variable. If no errors are detected, PCEP increments the OpenRetry variable.
If OpenRetry=2, the PCEP peer sends a PCErr with Error-Type=1 and If no errors are detected, OpenRetry=2 and the session
Error-value=5, the system releases the PCEP resources for that peer, characteristics are unacceptable, the PCEP peer sends a PCErr with
and moves back to the Idle state. Error-Type=1 and Error-value=5, the system releases the PCEP
resources for that peer and moves back to the Idle state.
If no errors are detected and the session characteristics are If no errors are detected and the session characteristics are
acceptable to the local system, the system: acceptable to the local system, the system:
o Sends a Keepalive message to the PCEP peer, o Sends a Keepalive message to the PCEP peer,
o Starts the Keepalive timer, o Starts the Keepalive timer,
o Sets the RemoteOK variable to 1. o Sets the RemoteOK variable to 1.
If LocalOK=1 the system moves to the UP state. If LocalOK=1 the system moves to the UP state.
If LocalOK=0 the system moves to the KeepWait state. If LocalOK=0 the system moves to the KeepWait state.
If no errors are detected but the session characteristics are If no errors are detected but the session characteristics are
unacceptable and non-negotiable, the PCEP peer sends a PCErr with unacceptable and non-negotiable, the PCEP peer sends a PCErr with
skipping to change at page 59, line 32 skipping to change at page 61, line 28
the Idle State. the Idle State.
UP State UP State
In the UP state, the PCEP peer starts exchanging PCEP messages In the UP state, the PCEP peer starts exchanging PCEP messages
according to the session characteristics. according to the session characteristics.
If the Keepalive timer expires, the system sends a Keepalive message. If the Keepalive timer expires, the system sends a Keepalive message.
If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from
the PCEP peer after the expiration of the DeadTimer, the systems the PCEP peer after the expiration of the DeadTimer, terminates PCEP
sends a PCErr message with a PCEP-ERROR object (Error-type=9, Error- session according to the procedure defined in Section 6.8, releases
value=1), terminates PCEP session according to the procedure defined the PCEP resources for that PCEP peer, closes the TCP connection and
in Section 6.8, releases the PCEP resources for that PCEP peer, moves to the Idle State.
closes the TCP connection and moves to the Idle State.
If a malformed message is received, the system terminates the PCEP If a malformed message is received, the system terminates the PCEP
session according to the procedure defined in Section 6.8, the system session according to the procedure defined in Section 6.8, releases
releases the PCEP resources for that PCEP peer, closes the TCP the PCEP resources for that PCEP peer, closes the TCP connection and
connection and moves to the Idle State. moves to the Idle State.
If the system detects that the PCEP peer tries to setup a second TCP
connection, it stops the TCP connection establishment and sends a
PCErr with Error-Type=10.
If the TCP connection fails, the system releases the PCEP resources If the TCP connection fails, the system releases the PCEP resources
for that PCEP peer, closes the TCP connection and moves to the Idle for that PCEP peer, closes the TCP connection and moves to the Idle
State. State.
11. Security Considerations 11. Security Considerations
PCEP could be the target of the following attacks: PCEP could be the target of the following attacks:
o Spoofing (PCC or PCE impersonation) o Spoofing (PCC or PCE impersonation)
skipping to change at page 61, line 6 skipping to change at page 63, line 6
used to ensure Authentication and Integrity, in which case, TCP MD-5 used to ensure Authentication and Integrity, in which case, TCP MD-5
option would not be required. option would not be required.
11.3. Protection against Denial of Service attacks 11.3. Protection against Denial of Service attacks
PCEP can be the target of TCP DoS attacks, such as for instance SYN PCEP can be the target of TCP DoS attacks, such as for instance SYN
attacks, as all protocols running on top of TCP. PCEP can use the attacks, as all protocols running on top of TCP. PCEP can use the
same mechanisms as defined in [RFC3036] to mitigate the threat of same mechanisms as defined in [RFC3036] to mitigate the threat of
such attacks: such attacks:
o A PCE should avoid promiscuous TCP listens for PCEP TCP session o A PCE should avoid promiscuous TCP listens for PCEP TCP connection
establishment. It should use only listens that are specific to establishment. It should use only listens that are specific to
authorized PCCs. authorized PCCs.
o The use of the MD5 option helps somewhat since it prevents a SYN o The use of the MD5 option helps somewhat since it prevents a SYN
from being accepted unless the MD5 segment checksum is valid. from being accepted unless the MD5 segment checksum is valid.
However, the receiver must compute the checksum before it can However, the receiver must compute the checksum before it can
decide to discard an otherwise acceptable SYN segment. decide to discard an otherwise acceptable SYN segment.
o The use of access-list on the PCE so as to restrict access to o The use of access-list on the PCE so as to restrict access to
authorized PCCs. authorized PCCs.
skipping to change at page 63, line 43 skipping to change at page 65, line 43
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[RFC4674] Le Roux, J., "Requirements for Path Computation Element [RFC4674] Le Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, October 2006. (PCE) Discovery", RFC 4674, October 2006.
14.2. Informative References 14.2. Informative References
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS Ayyangar, A., "Inter domain Multiprotocol Label Switching
Traffic Engineering - RSVP-TE extensions", (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering -
draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in RSVP-TE extensions",
progress), January 2007. draft-ietf-ccamp-inter-domain-rsvp-te-05 (work in
progress), March 2007.
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS protocol extensions for Path Computation Roux, J., "IS-IS protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-01 (work in progress), draft-ietf-pce-disco-proto-isis-02 (work in progress),
December 2006. February 2007.
[I-D.ietf-pce-disco-proto-ospf] [I-D.ietf-pce-disco-proto-ospf]
Roux, J., "OSPF protocol extensions for Path Computation Roux, J., "OSPF protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-ospf-01 (work in progress), draft-ietf-pce-disco-proto-ospf-02 (work in progress),
December 2006. February 2007.
[I-D.ietf-pce-inter-layer-req] [I-D.ietf-pce-inter-layer-req]
Oki, E., "PCC-PCE Communication Requirements for Inter- Oki, E., "PCC-PCE Communication Requirements for Inter-
Layer Traffic Engineering", Layer Traffic Engineering",
draft-ietf-pce-inter-layer-req-03 (work in progress), draft-ietf-pce-inter-layer-req-03 (work in progress),
October 2006. October 2006.
[I-D.ietf-pce-interas-pcecp-reqs] [I-D.ietf-pce-interas-pcecp-reqs]
Bitar, N., "Inter-AS Requirements for the Path Computation Bitar, N., "Inter-AS Requirements for the Path Computation
Element Communication Protocol (PCECP)", Element Communication Protocol (PCECP)",
draft-ietf-pce-interas-pcecp-reqs-01 (work in progress), draft-ietf-pce-interas-pcecp-reqs-01 (work in progress),
October 2006. October 2006.
[I-D.ietf-pce-manageability-requirements]
Farrel, A., "Inclusion of Manageability Sections in PCE
Working Group Drafts",
draft-ietf-pce-manageability-requirements-01 (work in
progress), March 2007.
[I-D.ietf-pce-pcecp-interarea-reqs] [I-D.ietf-pce-pcecp-interarea-reqs]
Roux, J., "PCE Communication Protocol (PCECP) Specific Roux, J., "PCE Communication Protocol (PCECP) Specific
Requirements for Inter-Area Multi Protocol Label Requirements for Inter-Area Multi Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work
in progress), December 2006. in progress), December 2006.
[I-D.ietf-rpsec-bgpsecrec] [I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements", Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-06 (work in progress), draft-ietf-rpsec-bgpsecrec-07 (work in progress),
June 2006. February 2007.
[I-D.kkoushik-pce-pcep-mib]
Stephan, E. and K. Koushik, "PCE communication
protocol(PCEP) Management Information Base",
draft-kkoushik-pce-pcep-mib-00 (work in progress),
February 2007.
[I-D.vasseur-pce-monitoring]
Roux, J. and J. Vasseur, "A set of monitoring tools for
Path Computation Element based Architecture",
draft-vasseur-pce-monitoring-02 (work in progress),
March 2007.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and
T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric
as a second MPLS Traffic Engineering (TE) Metric", BCP 87, as a second MPLS Traffic Engineering (TE) Metric", BCP 87,
RFC 3785, May 2004. RFC 3785, May 2004.
[RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022,
March 2005.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Label Ayyangar, "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment Switching (MPLS) Label Switched Path (LSP) Establishment
Using Resource ReserVation Protocol-Traffic Engineering Using Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006. (RSVP-TE)", RFC 4420, February 2006.
Appendix A. Compliance with the PCECP Requirement Document Appendix A. Compliance with the PCECP Requirement Document
skipping to change at page 66, line 10 skipping to change at page 68, line 34
Consider the case where a PCReq message is received by a PCE that Consider the case where a PCReq message is received by a PCE that
contains the SVEC object referring to M synchronized path computation contains the SVEC object referring to M synchronized path computation
requests. If after the expiration of the SYNC timer all the M path requests. If after the expiration of the SYNC timer all the M path
computation requests have not been received, a protocol error is computation requests have not been received, a protocol error is
triggered and the PCE MUST cancel the whole set of path computation triggered and the PCE MUST cancel the whole set of path computation
requests. A RECOMMENDED value for the SYNC timer is 60 seconds. requests. A RECOMMENDED value for the SYNC timer is 60 seconds.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
JL Le Roux (editor) JL Le Roux (editor)
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lannion, 22307 Lannion, 22307
 End of changes. 70 change blocks. 
162 lines changed or deleted 296 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/