draft-ietf-pce-pcep-07.txt   draft-ietf-pce-pcep-08.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track JL. Le Roux, Ed. Intended status: Standards Track JL. Le Roux, Ed.
Expires: September 3, 2007 France Telecom Expires: January 6, 2008 France Telecom
March 2, 2007 July 5, 2007
Path Computation Element (PCE) communication Protocol (PCEP) Path Computation Element (PCE) communication Protocol (PCEP)
draft-ietf-pce-pcep-07.txt draft-ietf-pce-pcep-08.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 35 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 September 3, 2007. This Internet-Draft will expire on January 6, 2008.
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 35 skipping to change at page 2, line 35
4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11
4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13 4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13
5. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 13 5. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 13
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16
6.4. Path Computation Request (PCReq) message . . . . . . . . . 17 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17
6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18
6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 19 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 20
6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 21
6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 20 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 21
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 7.1. Common object header . . . . . . . . . . . . . . . . . . . 22
7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 23
7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 25
7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 27
7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 28
7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 29 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 30
7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 30 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 31
7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 31 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 32
7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 34 7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 35
7.9. Record Route Object . . . . . . . . . . . . . . . . . . . 34 7.9. Route Record Object . . . . . . . . . . . . . . . . . . . 35
7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 35 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 36
7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36 7.11. Include Route Object Object . . . . . . . . . . . . . . . 38
7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 37 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 38
7.12.1. Notion of Dependent and Synchronized path 7.12.1. Notion of Dependent and Synchronized path
computation requests . . . . . . . . . . . . . . . . . 37 computation requests . . . . . . . . . . . . . . . . . 38
7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 40
7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 40 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 41
7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 42
7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 45
7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 47 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 49
7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 48 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 50
8. Manageability Considerations . . . . . . . . . . . . . . . . . 49 8. Manageability Considerations . . . . . . . . . . . . . . . . . 51
8.1. Control of Function and Policy . . . . . . . . . . . . . . 49 8.1. Control of Function and Policy . . . . . . . . . . . . . . 51
8.2. Information and Data Models . . . . . . . . . . . . . . . 50 8.2. Information and Data Models . . . . . . . . . . . . . . . 52
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 51 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 53
8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 51 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 53
8.5. Requirements on Other Protocols and Functional 8.5. Requirements on Other Protocols and Functional
Componentssection . . . . . . . . . . . . . . . . . . . . 51 Componentssection . . . . . . . . . . . . . . . . . . . . 53
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 52 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 52 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 54
9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 52 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 54
9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 54 9.4. Notification Object . . . . . . . . . . . . . . . . . . . 56
9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 54 9.5. PCEP Error Object . . . . . . . . . . . . . . . . . . . . 56
9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 55 9.6. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 57
10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 56 9.7. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 58
11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 58
11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 62 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 65
11.3. Protection against Denial of Service attacks . . . . . . . 62 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 65
11.4. Request input shaping/policing . . . . . . . . . . . . . . 63 11.3. Protection against Denial of Service attacks . . . . . . . 66
12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 63 11.4. Request input shaping/policing . . . . . . . . . . . . . . 66
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 66
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
14.1. Normative References . . . . . . . . . . . . . . . . . . . 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.2. Informative References . . . . . . . . . . . . . . . . . . 65 14.1. Normative References . . . . . . . . . . . . . . . . . . . 68
Appendix A. Compliance with the PCECP Requirement Document . . . 67 14.2. Informative References . . . . . . . . . . . . . . . . . . 68
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 68 Appendix A. PCEP Variables . . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . . 69 Intellectual Property and Copyright Statements . . . . . . . . . . 72
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
AS: Autonomous System.
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.
Inter-domain TE LSP: A TE LSP whose path transits across at least two Inter-domain TE LSP: A TE LSP whose path transits across at least two
different domains where a domain can either be an IGP area, an 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).
skipping to change at page 5, line 9 skipping to change at page 5, line 11
allows for the separation of PCE from PCC, and allows for the allows for the separation of PCE from PCC, and allows for the
cooperation between PCEs. This necessitates a communication protocol cooperation between PCEs. This necessitates a communication protocol
between PCC and PCE, and between PCEs. [RFC4657] states the generic between PCC and PCE, and between PCEs. [RFC4657] states the generic
requirements for such protocol including the requirement for using requirements for such protocol including the requirement for using
the same protocol between PCC and PCE, and between PCEs. Additional the same protocol between PCC and PCE, and between PCEs. Additional
application-specific requirements (for scenarios such as inter-area, application-specific requirements (for scenarios such as inter-area,
inter-AS, etc.) are not included in [RFC4657], but there is a inter-AS, etc.) are not included in [RFC4657], but there is a
requirement that any solution protocol must be easily extensible to requirement that any solution protocol must be easily extensible to
handle other requirements as they are introduced in application- handle other requirements as they are introduced in application-
specific requirements documents. Examples of such application- specific requirements documents. Examples of such application-
specific requirements are [I-D.ietf-pce-pcecp-interarea-reqs], specific requirements are [RFC4927],
[I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req].
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs, in (PCC) and a Path Computation Element (PCE), or between two PCEs, in
compliance with [RFC4657]. Such interactions include path compliance with [RFC4657]. Such interactions include path
computation requests and path computation replies as well as computation requests and path computation replies as well as
notifications of specific states related to the use of a PCE in the notifications of specific states related to the use of a PCE in the
context of MPLS and GMPLS Traffic Engineering. context of MPLS and GMPLS Traffic Engineering.
skipping to change at page 6, line 33 skipping to change at page 6, line 35
- Open and Keepalive messages are used to initiate and maintain a - Open and Keepalive messages are used to initiate and maintain a
PCEP session respectively. PCEP session respectively.
- PCReq: a PCEP message sent by a PCC to a PCE to request a path - PCReq: a PCEP message sent by a PCC to a PCE to request a path
computation. computation.
- PCRep: a PCEP message sent by a PCE to a PCC in reply to a path - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
computation request. A PCRep message can either contain a set of computation request. A PCRep message can either contain a set of
computed path(s) if the request can be satisfied or a negative reply computed path(s) if the request can be satisfied or a negative reply
otherwise. otherwise in which case the negative reply may also indicate the
reason why no path could be found.
- PCNtf: a PCEP notification message either sent by a PCC to a PCE or - PCNtf: a PCEP notification message either sent by a PCC to a PCE or
a PCE to a PCC to notify of a specific event. a PCE to a PCC to notify of a specific event.
- PCErr: a PCEP message sent upon the occurrence of a protocol error - PCErr: a PCEP message sent upon the occurrence of a protocol error
condition. condition.
- 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 either be 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.
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
skipping to change at page 7, line 25 skipping to change at page 7, line 26
Once the TCP connection is established, the PCC and the PCE (also Once the TCP connection is established, the PCC and the PCE (also
referred to as "PCEP peers") initiate a PCEP session establishment referred to as "PCEP peers") initiate a PCEP session establishment
during which various session parameters are negotiated. These during which various session parameters are negotiated. These
parameters are carried within Open messages and include the Keepalive parameters are carried within Open messages and include the Keepalive
timer, the Deadtimer and potentially other detailed capabilities and timer, the Deadtimer and potentially other detailed capabilities and
policy rules that specify the conditions under which path computation policy rules that specify the conditions under which path computation
requests may be sent to the PCE. If the PCEP session establishment requests may be sent to the PCE. If the PCEP session establishment
phase fails because the PCEP peers disagree on the session parameters phase fails because the PCEP peers disagree on the session parameters
or one of the PCEP peers does not answer after the expiration of the or one of the PCEP peers does not answer after the expiration of the
establishment timer, the TCP connection is immediately closed. establishment timer, the TCP connection is immediately closed.
Successive retries are permitted but an implementation SHOULD make Successive retries are permitted but an implementation should make
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 may be exchanged between PCEP peers to ensure the liveness of the
session. PCEP 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 inSection 6.2 and Section 6.3 respectively. found inSection 6.2 and Section 6.3 respectively.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
skipping to change at page 8, line 21 skipping to change at page 8, line 21
|<--- Open message ----| |<--- Open message ----|
| | | |
| | | |
| | | |
|<--- Keepalive -------| |<--- Keepalive -------|
| | | |
|---- Keepalive ------>| |---- Keepalive ------>|
Figure 1: PCEP Initialization phase (initiated by a PCC) Figure 1: PCEP Initialization phase (initiated by a PCC)
(Note that the exchange of Keepalive messages is optional)
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--->|
request sent to | | request sent to | |
the selected PCE | | the selected PCE | |
Figure 2: Path computation request Figure 2: Path computation request
Once a PCC has successfully established a PCEP session with one or Once a PCC has successfully established a PCEP session with one or
more PCEs, if an event is triggered that requires the computation of more PCEs, if an event is triggered that requires the computation of
a set of path(s), the PCC first selects one or more PCE(s) to send a set of path(s), the PCC first selects one or more PCE(s). Note
the request to. Note that the PCE selection decision process may that the PCE selection decision process may have taken place prior to
have taken place prior to the PCEP session establishment. the PCEP session establishment.
Once the PCC has selected a PCE, it sends a path computation request Once the PCC has selected a PCE, it sends a path computation request
to the PCE (PCReq message) that contains a variety of objects that to the PCE (PCReq message) that contains a variety of objects that
specify the set of constraints and attributes for the path to be specify the set of constraints and attributes for the path to be
computed. For example "Compute a TE LSP path with source IP computed. For example "Compute a TE LSP path with source IP
address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B
Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may
desire to specify the urgency of such request by assigning a request desire to specify the urgency of such request by assigning a request
priority. Each request is uniquely identified by a request-id number priority. Each request is uniquely identified by a request-id number
and the PCC-PCE address pair. The process is shown in a schematic and the PCC-PCE address pair. The process is shown in a schematic
skipping to change at page 10, line 46 skipping to change at page 10, line 46
| |various additional | |various additional
| |information) | |information)
|<--- PCRep message ---| |<--- PCRep message ---|
| (Negative reply) | | (Negative reply) |
Figure 3b: Path computation request with unsuccessful path computation Figure 3b: Path computation request with unsuccessful path computation
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation, the result of which can either be: triggers a path computation, the result of which can either be:
- Positive (Figure 3-a): the PCE manages to compute a path that o Positive (Figure 3-a): the PCE manages to compute a path that
satisfies the set of required constraints, in which case the PCE satisfies the set of required constraints, in which case the PCE
returns the set of computed path(s) to the requesting PCC. Note that returns the set of computed path(s) to the requesting PCC. Note
PCEP supports the capability to send a single request which requires that PCEP supports the capability to send a single request that
the computation of more than one path (e.g. computation of a set of requires the computation of more than one path (e.g. computation
link-diverse paths). of a set of link-diverse paths).
- Negative (Figure 3-b): no path could be found that satisfies the o Negative (Figure 3-b): no path could be found that satisfies the
set of constraints. In this case, a PCE may provide the set of set of constraints. In this case, a PCE may provide the set of
constraints that led to the path computation failure. Upon receiving constraints that led to the path computation failure. Upon
a negative reply, a PCC may decide to resend a modified request or receiving a negative reply, a PCC may decide to resend a modified
take any other appropriate action. request or take any other appropriate action.
Details about the PCRep message can be found in Section 6.5. Details about the PCRep message can be found in Section 6.5.
4.2.4. Notification 4.2.4. Notification
There are several circumstances whereby a PCE may want to notify a There are several circumstances whereby a PCE may want to notify a
PCC of a specific event. For example, suppose that the PCE suddenly PCC of a specific event. For example, suppose that the PCE suddenly
experiences some congestion that would lead to unacceptable response gets overloaded thus potentially leading to unacceptable response
times. The PCE may want to notify one or more PCCs that some of times. The PCE may want to notify one or more PCCs that some of
their requests (listed in the notification) will not be satisfied or their requests (listed in the notification) will not be satisfied or
may experience unacceptable delays. Upon receiving such may experience unacceptable delays. Upon receiving such
notification, the PCC may decide to redirect it(s) path computation notification, the PCC may decide to redirect it(s) path computation
request(s) to another PCE should an alternate PCE be available. request(s) to another PCE should an alternate PCE be available.
Similarly, a PCC may desire to notify a PCE of a particular event Similarly, a PCC may desire to notify a PCE of a particular event
such as the cancellation of pending request(s). such as the cancellation of pending request(s).
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
skipping to change at page 12, line 35 skipping to change at page 12, line 35
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
2)PCE Selection | | 2)PCE Selection | |
3)Path computation |---- PCReq message--->| 3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation request X sent to | |4) Path computation
the selected PCE | |triggered the selected PCE | |triggered
| | | |
| | | |
| |5) PCE experiencing | |5) PCE gets overloaded
| |congestion | |
| | | |
| |6) Path computation | |6) Path computation
| |request X cancelled | |request X cancelled
| | | |
|<--- PCNtf message----| |<--- PCNtf message----|
Figure 5: Example of PCE notification (cancellation notification) sent to a PCC Figure 5: Example of PCE notification (cancellation notification) sent to a PCC
Details about the PCNtf message can be found in Section 6.6. Details about the PCNtf message can be found in Section 6.6.
skipping to change at page 14, line 25 skipping to change at page 14, line 25
Conversely, if an object is optional, the object may or may not be Conversely, if an object is optional, the object may or may not be
present. present.
A flag referred to as the P flag is defined in the common header of A flag referred to as the P flag is defined in the common header of
each PCEP object (see Section 7.1) that can be set by a PCEP peer to each PCEP object (see Section 7.1) that can be set by a PCEP peer to
enforce a PCE to take into account the related information during the enforce a PCE to take into account the related information during the
path computation. For example, the METRIC object defined in path computation. For example, the METRIC object defined in
Section 7.7 allows a PCC to specify a bounded acceptable path cost. Section 7.7 allows a PCC to specify a bounded acceptable path cost.
The METRIC object is optional but a PCC may set a flag to ensure that The METRIC object is optional but a PCC may set a flag to ensure that
such constraint is taken into account. Similarly to the previous such constraint is taken into account. Similarly to the previous
case, if such constraint cannot be taken into account by the PCE, case, if such constraint cannot be taken into account by the PCE, the
this should trigger an Error message. PCE MUST trigger an Error message.
For each PCEP message type, rules are defined that specify the set of For each PCEP message type, rules are defined that specify the set of
objects that the message can carry. We use the Backus-Naur Form objects that the message can carry. We use the Backus-Naur Form
(BNF) to specify such rules. Square brackets refer to optional sub- (BNF) to specify such rules. Square brackets refer to optional sub-
sequences. An implementation MUST form the PCEP messages using the sequences. An implementation MUST form the PCEP messages using the
object ordering specified in this document. object ordering specified in this document.
6.1. Common header 6.1. Common header
0 1 2 3 0 1 2 3
skipping to change at page 15, line 28 skipping to change at page 15, line 28
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 MUST an Open message as specified in Section 10. Any message received
trigger a protocol error condition and the PCEP session MUST be prior to an Open message MUST trigger a protocol error condition and
terminated. The Open message is used to establish a PCEP session the PCEP session MUST be terminated. The Open message is used to
between the PCEP peers. During the establishment phase the PCEP establish a PCEP session between the PCEP peers. During the
peers exchange several session characteristics. If both parties establishment phase the PCEP peers exchange several session
agree on such characteristics the PCEP session is successfully characteristics. If both parties agree on such characteristics the
established. PCEP session is successfully 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. Once the TCP connection has been successfully the OPEN object. Once the TCP connection has been successfully
established the sender MUST start an initialization timer called established the sender MUST start an initialization timer called
OpenWait after the expiration of which if no Open message has been OpenWait after the expiration of which if no Open message has been
received it sends a PCErr message and releases the TCP connection received it sends a PCErr message and releases the TCP connection
skipping to change at page 17, line 10 skipping to change at page 17, line 10
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.
Note that sending Keepalive messages to maintain the session alive is
optional and PCEP peers may decide to not send Keepalive messages
once the PCEP session is established.
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).
skipping to change at page 17, line 38 skipping to change at page 18, line 18
<request-list> <request-list>
where: where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> <END-POINTS>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<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, RRO, 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
skipping to change at page 18, line 33 skipping to change at page 19, line 11
acceptable paths corresponding to the same request. acceptable paths corresponding to the same request.
The bundling of multiple replies to a set of path computation The bundling of multiple replies to a set of path computation
requests within a single PCRep message is supported by PCEP. If a requests within a single PCRep message is supported by PCEP. If a
PCE receives non-synchronized path computation requests by means of PCE receives non-synchronized path computation requests by means of
one or more PCReq messages from a requesting PCC it MAY decide to one or more PCReq messages from a requesting PCC it MAY decide to
bundle the computed paths within a single PCRep message so as to bundle the computed paths within a single PCRep message so as to
reduce the control plane load. Note that the counter side of such an reduce the control plane load. Note that the counter side of such an
approach is the introduction of additional delays for some path approach is the introduction of additional delays for some path
computation requests of the set. Conversely, a PCE that receives computation requests of the set. Conversely, a PCE that receives
multiple requests within the same PCReq message, it MAY decide to multiple requests within the same PCReq message MAY decide to provide
provide each computed path in separate PCRep messages. each computed path in separate PCRep messages or within the same
PCRep message.
If the path computation request can be satisfied (the PCE finds a set If the path computation request can be satisfied (the PCE finds a set
of path(s) that satisfy the set of constraint(s)), the set of of path(s) that satisfy the set of constraint(s)), the set of
computed path(s) specified by means of ERO object(s) is inserted in computed path(s) specified by means of ERO object(s) is inserted in
the PCRep message. The ERO object is defined in Section 7.8. Such a the PCRep message. The ERO object is defined in Section 7.8. Such a
situation where multiple computed paths are provided in a PCRep situation where multiple computed paths are provided in a PCRep
message is discussed in detail in Section 7.12. Furthermore, when a message is discussed in detail in Section 7.12. Furthermore, when a
PCC requests the computation a set of paths for a total amount of PCC requests the computation a set of paths for a total amount of
bandwidth of X by means of a LOAD-BALANCING object carried within a bandwidth of X by means of a LOAD-BALANCING object carried within a
PCReq message, the ERO of each computed path may be followed by a PCReq message, the ERO of each computed path may be followed by a
skipping to change at page 19, line 14 skipping to change at page 20, line 14
The format of a PCRep message is as follows: The format of a PCRep message is as follows:
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
where: where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>]
[<path-list>] [<path-list>]
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
<path>::= <ERO> <path>::= <ERO><attribute-list>
[<LSPA>]
where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
where:
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
6.6. Notification (PCNtf) message 6.6. Notification (PCNtf) message
The PCEP Notification message (also referred to as the PCNtf message) The PCEP Notification message (also referred to as the PCNtf message)
can either be sent by a PCE to a PCC or by a PCC to a PCE so as to can either be sent by a PCE to a PCC or by a PCC to a PCE so as to
notify of a specific event. The Message-Type field of the PCEP notify of a specific event. The Message-Type field of the PCEP
common header is set to 5 (To be confirmed by IANA). common header is set to 5 (To be confirmed by IANA).
The PCNtf message MUST carry at least one NOTIFICATION object and may The PCNtf message MUST carry at least one NOTIFICATION object and may
skipping to change at page 21, line 5 skipping to change at page 22, line 5
<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 an established PCEP PCE or by a PCE to a PCC in order to close an established PCEP
session. The Message-Type field of the PCEP common header for the session. The Message-Type field of the PCEP common header for the
Open message is set to 7 (To be confirmed by IANA). Close 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 21, line 46 skipping to change at page 22, line 46
OT (Object-Type - 4 bits): identifies the PCEP object type. OT (Object-Type - 4 bits): identifies the PCEP object type.
The Object-Class and Object-Type fields are managed by IANA. The Object-Class and Object-Type fields are managed by IANA.
The Object-Class and Object-Type fields uniquely identify each PCEP The Object-Class and Object-Type fields uniquely identify each PCEP
object. object.
Res flags (2 bits). Reserved field. This field MUST be set to zero Res flags (2 bits). Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
in a PCReq message sent to a PCE whether the object must be taken specify in a PCReq message sent to a PCE whether the object must
into account by the PCE during path computation or is just optional. be taken into account by the PCE during path computation or is
When the P flag is set, the object MUST be taken into account by the just optional. When the P flag is set, the object MUST be taken
PCE. Conversely, when the P flag is cleared, the object is optional into account by the PCE. Conversely, when the P flag is cleared,
and the PCE is free to ignore it if not supported. the object is optional and the PCE is free to ignore it if not
supported.
I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep
message to indicate to a PCC whether or not an optional object was message to indicate to a PCC whether or not an optional object was
processed. The PCE MAY include the ignored optional object in its processed. The PCE MAY include the ignored optional object in its
reply and set the I flag to indicate that the optional object was reply and set the I flag to indicate that the optional object was
ignored during path computation. When the I flag is cleared, the PCE ignored during path computation. When the I flag is cleared, the
indicates that the optional object was processed during the path PCE indicates that the optional object was processed during the
computation. The setting of the I flag for optional objects is path computation. The setting of the I flag for optional objects
purely indicative and optional. The I flag has no meaning in a PCRep is purely indicative and optional. The I flag has no meaning in a
message when the P flag had been set in the corresponding PCRep PCRep message when the P flag had been set in the corresponding
message. PCRep message.
If the PCE does not understand an object with the P flag set or If the PCE does not understand an object with the P flag set or
understands the object but decides to ignore the object, the entire understands the object but decides to ignore the object, the entire
PCEP message MUST be rejected and the PCE MUST send a PCErr message PCEP message MUST be rejected and the PCE MUST send a PCErr message
with Error-Type="Unknown Object" or "Not supported Object". with Error-Type="Unknown Object" or "Not supported Object".
Object Length (16 bits). Specifies the total object length including Object Length (16 bits). Specifies the total object length including
the header, in bytes. The Object Length field MUST always be a the header, in bytes. The Object Length field MUST always be a
multiple of 4, and at least 4. The maximum object content length is multiple of 4, and at least 4. The maximum object content length is
65528 bytes. 65528 bytes.
skipping to change at page 22, line 37 skipping to change at page 23, line 38
7.2. OPEN object 7.2. OPEN object
The OPEN object MUST be present in each Open message and MAY be The OPEN object MUST be present in each Open message and MAY be
present in a PCErr message. There MUST be only one OPEN object per present in a PCErr message. There MUST be only one OPEN object per
Open or PCErr message. Open or PCErr message.
The OPEN object contains a set of fields used to specify the PCEP The OPEN object contains a set of fields used to specify the PCEP
version, Keepalive frequency, DeadTimer, PCEP session ID along with version, Keepalive frequency, DeadTimer, PCEP session ID along with
various flags. The OPEN object may also contain a set of TLVs used various flags. The OPEN object may also contain a set of TLVs used
to convey various session characteristics such as the detailed PCE to convey various session characteristics such as the detailed PCE
capabilities, policy rules and so on. No such TLV is currently capabilities, policy rules and so on. No TLVs are currently defined.
defined.
OPEN Object-Class is to be assigned by IANA (recommended value=1) OPEN Object-Class is to be assigned by IANA (recommended value=1)
OPEN Object-Type is to be assigned by IANA (recommended value=1) OPEN Object-Type is to be assigned by IANA (recommended value=1)
The format of the OPEN object body is as follows: The format of the OPEN object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | Deadtimer | SID | | Ver | Flags | Keepalive | Deadtimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 28 skipping to change at page 24, line 28
Flags (5 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): maximum 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 the PCEP peer can declare the session with the sender of the
message down if no PCEP message has been received. The DeadTimer Open message down if no PCEP message has been received. The
MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value DeadTimer MUST be set to 0 if the Keepalive is set to 0. A
for the DeadTimer is 4 times the value of the Keepalive. RECOMMENDED value for the DeadTimer is 4 times the value of the
Keepalive.
SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP Example
session number that identifies the current session. The SID MUST be
incremented each time a new PCEP session is established and is mainly A sends an Open message to B with Keepalive=10 seconds and
used for logging and troubleshooting purposes. Deadtimer=30 seconds. This means that A sends Keepalive messages (or
ay other PCEP message) to B every 30 seconds and B can declare the
PCEP session with A down if no PCEP has been received from A.
SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
identifies the current session. The SID MUST be incremented each
time a new PCEP session is established and is mainly used for logging
and troubleshooting purposes.
Optional TLVs may be included within the OPEN object body to specify Optional TLVs may be included within the OPEN object body to specify
PCC or PCE characteristics. The specification of such TLVs is PCC or PCE characteristics. The specification of such TLVs is
outside the scope of this document. outside the scope of this document.
When present in an Open message, the OPEN object specifies the When present in an Open message, the OPEN object specifies the
proposed PCEP session characteristics. Upon receiving unacceptable proposed PCEP session characteristics. Upon receiving unacceptable
PCEP session characteristics during the PCEP session initialization PCEP session characteristics during the PCEP session initialization
phase, the receiving PCEP peer (PCE) MAY include an OPEN object phase, the receiving PCEP peer (PCE) MAY include an OPEN object
within the PCErr message so as to propose alternative session within the PCErr message so as to propose alternative acceptable
characteristic values. session characteristic values.
7.3. RP Object 7.3. RP Object
The RP (Request Parameters) object MUST be carried within each PCReq The RP (Request Parameters) object MUST be carried within each PCReq
and PCRep messages and MAY be carried within PCNtf and PCErr and PCRep messages and MAY be carried within PCNtf and PCErr
messages. The P flag of the RP object MUST be set in PCReq and PCReq messages. The P flag of the RP object MUST be set in PCReq and PCReq
messages and MUST be cleared in PCNtf and PCErr messages. The RP messages and MUST be cleared in PCNtf and PCErr messages. The RP
object is used to specify various characteristics of the path object is used to specify various characteristics of the path
computation request. computation request.
skipping to change at page 24, line 41 skipping to change at page 25, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP object body format Figure 10: RP object body format
The RP object body has a variable length and may contain additional The RP object body has a variable length and may contain additional
TLVs. No TLVs are currently defined. TLVs. No TLVs are currently defined.
Reserved (8 bits): Reserved: This field MUST be set to zero on Reserved (8 bits): Reserved: This field MUST be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
Flags: 18 bits - The following flags are currently defined: Flags (24 bits)
Pri (Priority - 3 bits): the Priority field may be used by the The following flags are currently defined:
requesting PCC to specify to the PCE the request's priority from 1 to
7. The decision of which priority should be used for a specific
request is of a local matter and MUST be set to 0 when unused.
Furthermore, the use of the path computation request priority by the
PCE's scheduler is implementation specific and out of the scope of
this document. Note that it is not required for a PCE to support the
priority field: in this case, it is RECOMMENDED to set the priority
field to 0 by the PCC in the RP object. If the PCE does not take
into account the request priority, it is RECOMMENDED to set the
priority field to 0 in the RP object carried within the corresponding
PCRep message, regardless of the priority value contained in the RP
object carried within the corresponding PCReq message. A higher
numerical value of the priority field reflects a higher priority.
Note that it is the responsibility of the network administrator to
make use of the priority values in a consistent manner across the
various PCC(s). The ability of a PCE to support requests
prioritization may be dynamically discovered by the PCC(s) by means
of PCE capability discovery. If not advertised by the PCE, a PCC may
decide to set the request priority and will learn the ability of the
PCE to support request prioritization by observing the Priority field
of the RP object received in the PCRep message. If the value of the
Pri field is set to 0, this means that the PCE does not support the
handling of request priorities: in other words, the path computation
request has been honoured but without taking the request priority
into account.
R (Reoptimization - 1 bit): when set, the requesting PCC specifies o Pri (Priority - 3 bits): the Priority field may be used by the
that the PCReq message relates to the reoptimization of an existing requesting PCC to specify to the PCE the request's priority from 1
TE LSP in which case, in addition to the TE LSP attributes, the to 7. The decision of which priority should be used for a
current path of the existing TE LSP to be reoptimized MUST be specific request is of a local matter and MUST be set to 0 when
provided in the PCReq (except for 0-bandwidth TE LSP) message by unused. Furthermore, the use of the path computation request
means of an RRO object defined in Section 7.9. priority by the PCE's scheduler is implementation specific and out
of the scope of this document. Note that it is not required for a
PCE to support the priority field: in this case, it is RECOMMENDED
to set the priority field to 0 by the PCC in the RP object. If
the PCE does not take into account the request priority, it is
RECOMMENDED to set the priority field to 0 in the RP object
carried within the corresponding PCRep message, regardless of the
priority value contained in the RP object carried within the
corresponding PCReq message. A higher numerical value of the
priority field reflects a higher priority. Note that it is the
responsibility of the network administrator to make use of the
priority values in a consistent manner across the various PCC(s).
The ability of a PCE to support requests prioritization may be
dynamically discovered by the PCC(s) by means of PCE capability
discovery. If not advertised by the PCE, a PCC may decide to set
the request priority and will learn the ability of the PCE to
support request prioritization by observing the Priority field of
the RP object received in the PCRep message. If the value of the
Pri field is set to 0, this means that the PCE does not support
the handling of request priorities: in other words, the path
computation request has been honoured but without taking the
request priority into account.
B (Bi-directional - 1 bit): when set, the PCC specifies that the path o R (Reoptimization - 1 bit): when set, the requesting PCC specifies
computation request relates to a bidirectional TE LSP that has the that the PCReq message relates to the reoptimization of an
same traffic engineering requirements including fate sharing, existing TE LSP in which case, in addition to the TE LSP
protection and restoration, LSRs, and resource requirements (e.g. attributes, the current path of the existing TE LSP to be
latency and jitter) in each direction. When cleared, the TE LSP is reoptimized MUST be provided in the PCReq (except for 0-bandwidth
unidirectional. TE LSP) message by means of an RRO object defined in Section 7.9.
O (strict/lOose - 1 bit): when set, in a PCReq message, this o B (Bi-directional - 1 bit): when set, the PCC specifies that the
indicates that a loose path is acceptable. Otherwise, when cleared, path computation request relates to a bidirectional TE LSP that
this indicates to the PCE that a path exclusively made of strict hops has the same traffic engineering requirements including fate
is required. In a PCRep message, when the O bit is set this sharing, protection and restoration, LSRs, and resource
indicates that the returned path is a loose path, otherwise (the O requirements (e.g. latency and jitter) in each direction. When
bit is cleared), the returned path is made of strict hops. cleared, the TE LSP is unidirectional.
o O (strict/lOose - 1 bit): when set, in a PCReq message, this
indicates that a loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that a path exclusively made of
strict hops is required. In a PCRep message, when the O bit is
set this indicates that the returned path is a loose path,
otherwise (the O bit is cleared), the returned path is made of
strict hops.
Unassigned bits are considered as reserved and MUST be set to zero on Unassigned bits are considered as reserved and MUST be set to zero on
transmission. transmission.
Request-ID-number (32 bits). The Request-ID-number value combined Request-ID-number (32 bits). The Request-ID-number value combined
with the source IP address of the PCC and the PCE address uniquely with the source IP address of the PCC and the PCE address uniquely
identify the path computation request context. The Request-ID-number identify the path computation request context. The Request-ID-number
MUST be incremented each time a new request is sent to the PCE. The MUST be incremented each time a new request is sent to the PCE. The
value 0x0000000 is considered as invalid. If no path computation value 0x0000000 is considered as invalid. If no path computation
reply is received from the PCE, and the PCC wishes to resend its reply is received from the PCE, and the PCC wishes to resend its
skipping to change at page 26, line 21 skipping to change at page 27, line 30
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 If the O bit of the RP message carried within a PCReq message is
cleared and local policy has been configured on the PCE to not cleared and local policy has been configured on the PCE to not
provide explicit path(s) (for instance, for confidentiality reasons), provide explicit path(s) (for instance, for confidentiality reasons),
a PCErr message MUST be sent by the PCE to the requesting PCC and the a PCErr message MUST be sent by the PCE to the requesting PCC and the
pending path computation request MUST be discarded. The Error-type pending path computation request MUST be discarded. The Error-type
is "Policy Violation" and Error-value is "O bit set". is "Policy Violation" and Error-value is "O bit cleared".
R bit: when the R bit of the RP object is set in a PCReq message, 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 27, line 5 skipping to change at page 28, line 14
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.
There are potentially several categories of issues that can lead to a
negative reply. For example, the PCE chain might be broken (should
there be more than one PCE involved in the path computation) or no
path obeying the set constraints could be found. The "NI (Nature of
Issue)" field in the NO-PATH object is used to report the error
category.
Optionally, if the PCE supports such capability, the NO-PATH object 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 used to
PCRep message MAY also contain a list of objects that specify the set provide more information on the reasons that led to a negative reply
of constraints that could not be satisfied. The PCE MAY just and the PCRep message MAY also contain a list of objects that specify
the set of constraints that could not be satisfied. The PCE MAY just
replicate the set of object(s) that was received that was the cause replicate the set of object(s) that was received that was the cause
of the unsuccessful computation or MAY optionally report a suggested of the unsuccessful computation or MAY optionally report a suggested
value for which a path could have been found. value for which a path could have been found.
NO-PATH Object-Class is to be assigned by IANA (recommended value=3) NO-PATH Object-Class is to be assigned by IANA (recommended value=3)
NO-PATH Object-Type is to be assigned by IANA (recommended value=1) NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
The format of the NO-PATH object body is as follows: The format of the NO-PATH object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |Nature Of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH object format Figure 11: NO-PATH object format
Optionally, a TLV named NO-PATH-VECTOR MAY be included in the NI - Nature Of Issue (8 bits): the NI field is used to report the
NO-PATH object that specifies the reason that led to unsuccessful path computation. nature of the issue that led to a negative reply. Two values are
currently defined:
The NO-PATH-VECTOR TLV is composed of 1 octet for the type,
1 octet specifying the number of bytes in the value field, followed by
a fix length value field of 32-bits flags field used to report the reason(s)
that led to unsuccessful path computation The NO-PATH-VECTOR TLV is padded
to eight-octet alignment.
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: 32-bits flags field
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: 0x00: No path satisfying the set of constraints could be found
0x01: PCE currently unavailable 0x01: PCE chain broken
0x02: Unknown destination
Flags (16 bits). Flags (16 bits).
The following flag is currently defined: The following flag is currently defined:
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. When the C bit is set, the NI field value MUST
be 0x00.
Reserved: This field MUST be set to zero on transmission and MUST be Reserved (8 bits): This field MUST be set to zero on transmission and
ignored on receipt. MUST be ignored on receipt.
The NO-PATH object body has a variable length and may contain The NO-PATH object body has a variable length and may contain
additional TLVs. The only TLV currently defined is the NO-PATH- additional TLVs. The only TLV currently defined is the NO-PATH-
VECTOR TLV defined below. 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 NI field value is 0x00 and C flag is set). If the PCE
alternatively include the BANDWIDTH Object and report a value of Y in supports such capability it may alternatively include the BANDWIDTH
the bandwidth field of the BANDWIDTH object (in this case, the C flag Object and report a value of Y in the bandwidth field of the
is set) where Y refers to the bandwidth for which a TE LSP with the BANDWIDTH object (in this case, the C flag is set) where Y refers to
same other characteristics could have been computed. the bandwidth for which a TE LSP with the same other characteristics
could have been computed.
When the NO-PATH object is absent from a PCRep message, the path When the NO-PATH object is absent from a PCRep message, the path
computation request has been fully satisfied and the corresponding computation request has been fully satisfied and the corresponding
path(s) is/are provided in the PCRep message. path(s) is/are provided in the PCRep message.
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH
object in order to provide more information on the reasons that led
to a negative reply.
The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte
specifying the number of bytes in the value field, followed by a fix
length value field of 32-bits flags field used to report the
reason(s) that led to unsuccessful path computation.
The NO-PATH-VECTOR TLV is padded to eight-byte alignment.
TYPE: To be assigned by IANA
LENGTH: 4
VALUE: 32-bits flags field
IANA is requested to manage the space of flags carried in the NO-
PATH-VECTOR TLV (see Section 9).
The following flags are currently defined:
o 0x01: PCE currently unavailable
o 0x02: Unknown destination
o 0x03: Unknown source
7.5. END-POINT Object 7.5. END-POINT Object
The END-POINTS object is used in a PCReq message to specify the The END-POINTS object is used in a PCReq message to specify the
source IP address and the destination IP address of the path for source IP address and the destination IP address of the path for
which a path computation is requested. Note that the source and which a path computation is requested. Note that the source and
destination addresses specified in the END-POINTS object may or may destination addresses specified in the END-POINTS object may or may
not correspond to the source and destination IP address of the TE LSP not correspond to the source and destination IP address of the TE LSP
but rather to a path segment. Two END-POINTS objects (for IPv4 and but rather to a path segment. Two END-POINTS objects (for IPv4 and
IPv6) are defined. IPv6) are defined.
skipping to change at page 30, line 35 skipping to change at page 31, line 35
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Destination IPv6 address (16 bytes) | | Destination IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: END-POINTS object body format for IPv6 Figure 13: END-POINTS object body format for IPv6
The END-POINTS object body has a fixed length of 8 octets for IPv4 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and
and 32 octets for IPv6. 32 bytes for IPv6.
7.6. BANDWIDTH Object 7.6. BANDWIDTH Object
The BANDWIDTH object is used to specify the requested bandwidth for a The BANDWIDTH object is used to specify the requested bandwidth for a
TE LSP. TE LSP.
If the requested bandwidth is equal to 0, the BANDWIDTH object is If the requested bandwidth is equal to 0, the BANDWIDTH object is
optional. Conversely, if the requested bandwidth is non equal to 0, optional. Conversely, if the requested bandwidth is non equal to 0,
the PCReq message MUST contain a BANDWIDTH object. the PCReq message MUST contain a BANDWIDTH object.
skipping to change at page 31, line 31 skipping to change at page 32, line 31
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth | | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: BANDWIDTH object body format Figure 14: BANDWIDTH object body format
Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in
IEEE floating point format, expressed in bytes per second. IEEE floating point format, expressed in bytes per second.
The BANDWIDTH object body has a fixed length of 4 octets. The BANDWIDTH object body has a fixed length of 4 bytes.
7.7. METRIC Object 7.7. METRIC Object
The METRIC object is optional and can be used for several purposes. The METRIC object is optional and can be used for several purposes.
In a PCReq message, a PCC MAY insert a METRIC object: In a PCReq message, a PCC MAY insert a METRIC object:
o To indicate the metric that MUST be optimized by the path o To indicate the metric that MUST be optimized by the path
computation algorithm (IGP metric, TE metric, Hop counts). computation algorithm (IGP metric, TE metric, Hop counts).
Currently, three metrics are defined: the IGP cost and the TE Currently, three metrics are defined: the IGP cost, the TE metric
metric (see [RFC3785]) and the number of hops traversed by a TE (see [RFC3785]) and the number of hops traversed by a TE LSP.
LSP.
o To indicate a bound on the path cost than MUST NOT be exceeded for o To indicate a bound on the path cost that MUST NOT be exceeded for
the path to be considered as acceptable by the PCC. the path to be considered as acceptable by the PCC.
In a PCRep message, the METRIC object MAY be inserted so as to In a PCRep message, the METRIC object MAY be inserted so as to
provide the cost for the computed path. It MAY also be inserted provide the cost for the computed path. It MAY also be inserted
within a PCRep with the NO-PATH object to indicate that the metric within a PCRep with the NO-PATH object to indicate that the metric
constraint could not be satisfied. constraint could not be satisfied.
The path computation algorithmic aspects used by the PCE to optimize The path computation algorithmic aspects used by the PCE to optimize
a path with respect to a specific metric are outside the scope of a path with respect to a specific metric are outside the scope of
this document. this document.
skipping to change at page 32, line 33 skipping to change at page 33, line 33
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|B| T | | Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value | | metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: METRIC object body format Figure 15: METRIC object body format
The METRIC object body has a fixed length of 8 octets. The METRIC object body has a fixed length of 8 bytes.
Reserved (16 bits): This field MUST be set to zero on transmission Reserved (16 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt. and MUST be ignored on receipt.
T (Type - 8 bits): Specifies the metric type. T (Type - 8 bits): Specifies the metric type.
Three values are currently defined: Three values are currently defined:
o T=1: IGP metric o T=1: IGP metric
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 Flags (8 bits): Two flags are currently defined:
o B (Bound - 1 bit): When set in a PCReq message, the metric-value
indicates a bound (a maximum) for the path 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 PCReq message, this indicates that o 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
the constraints be found) in the PCRep message for the corresponding satisfying the constraints be found) in the PCRep message for the
metric. corresponding metric.
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
Metric-value (32 bits): metric value encoded in 32 bits in IEEE 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. If two or more instances of a METRIC object are each metric type with the same B flag value. If two or more
present for a metric type, only the first instance MUST be considered instances of a METRIC object with the same B flag value are present
and other instances MUST be ignored. for a metric type, only the first instance MUST be considered 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 objects can be
to specify a multi-parameters (e.g. a metric may be a constraint or a used to specify a multi-parameters (e.g. a metric may be a constraint
parameter to minimize/maximize) objective function or multiple bounds or a parameter to minimize/maximize) objective function or multiple
for different constraints where at most one METRIC object must be bounds for different constraints where at most one METRIC object must
used to indicate the metric to optimize (B-flag is cleared): the be 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).
A METRIC object used to indicate the metric to optimize during the A METRIC object used to indicate the metric to optimize during the
path computation MUST have the B-Flag cleared and the T-Flag set to path computation MUST have the B-Flag cleared and the T-Flag set to
the appropriate value. When the path computation relates to the the appropriate value. When the path computation relates to the
reoptimization of an exiting TE LSP (in which case R-Flag of the RP reoptimization of an exiting TE LSP (in which case R-Flag of the RP
object is set) an implementation MAY decide to set the metric-value object is set) an implementation MAY decide to set the metric-value
field to the cost of the TE LSP to be reoptimized with regards to a field to the cost of the TE LSP to be reoptimized with regards to a
specific metric type. specific metric type.
A METRIC object used to reflect a bound MUST have the B-Flag set, the A METRIC object used to reflect a bound MUST have the B-Flag set, the
T-Flag and metric-value field set to the appropriate values. T-Flag and metric-value field set to the appropriate values.
In a PCRep message, unless not allowed by PCE policy, at least one In a PCRep message, unless not allowed by PCE policy, at least one
METRIC object MUST be present that reports the computed path cost if METRIC object MUST be present that reports the computed path cost in
the C bit of the METRIC object was set in the corresponding path particular if the C bit of the METRIC object was set in the
computation request (the B-flag MUST be cleared); optionally the corresponding path computation request (the B-flag MUST be cleared);
PCRep message MAY contain additional METRIC objects that correspond optionally the PCRep message MAY contain additional METRIC objects
to bound constraints, in which case the metric-value MUST be equal to that correspond to bound constraints, in which case the metric-value
the corresponding path metric cost (the B-flag MUST be set). If no MUST be equal to the corresponding path metric cost (the B-flag MUST
path satisfying the constraints could be found by the PCE, the METRIC be set). If no path satisfying the constraints could be found by the
objects MAY also be present in the PCRep message with the NO-PATH PCE, the METRIC objects MAY also be present in the PCRep message with
object to indicate the constraint metric that could be satisfied. the NO-PATH object to indicate the constraint metric that could be
satisfied.
Example: if a PCC sends a path computation request to a PCE where the Example: if a PCC sends a path computation request to a PCE where the
metric to optimize is the IGP metric and the TE metric must not metric to optimize is the IGP metric and the TE metric must not
exceed the value of M, two METRIC object are inserted in the PCReq exceed the value of M, two METRIC object are inserted in the PCReq
message: message:
o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000
o Second METRIC Object with B=1, T=2, metric-value=M o Second METRIC Object with B=1, T=2, metric-value=M
skipping to change at page 34, line 38 skipping to change at page 35, line 46
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. Record Route Object 7.9. Route Record 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 36, line 9 skipping to change at page 37, line 32
Figure 16: LSPA object body format Figure 16: LSPA object body format
Setup Prio (Setup Priority - 8 bits). The priority of the session Setup Prio (Setup Priority - 8 bits). The priority of the session
with respect to taking resources, in the range of 0 to 7. The value with respect to taking resources, in the range of 0 to 7. The value
0 is the highest priority. The Setup Priority is used in deciding 0 is the highest priority. The Setup Priority is used in deciding
whether this session can preempt another session. whether this session can preempt another session.
Holding Prio (Holding Priority - 8 bits). The priority of the Holding Prio (Holding Priority - 8 bits). The priority of the
session with respect to holding resources, in the range of 0 to 7. session with respect to holding resources, in the range of 0 to 7.
The value 0 is the highest priority. Holding Priority is used in The value 0 is the highest priority. Holding Priority is used in
deciding whether this session can be preempted by another session. deciding whether this session can be preempted by another session.
Flags
Flags (8 bits)
The flag L corresponds to the "Local protection desired" bit The flag L corresponds to the "Local protection desired" bit
([RFC3209]) of the SESSION-ATTRIBUTE Object. ([RFC3209]) of the SESSION-ATTRIBUTE Object.
L Flag (Local protection desired). When set, this means that the L Flag (Local protection desired). When set, this means that the
computed path must include links protected with Fast Reroute as computed path must include links protected with Fast Reroute as
defined in [RFC4090]. defined in [RFC4090].
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
Reserved (8 bits): This field MUST be set to zero on transmission and Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
Note that the Optional TLV field may contain additional TE LSP Note that the Optional TLV field may contain additional TE LSP
attributes as defined in [RFC4420]. attributes as defined in [RFC4420].
7.11. IRO Object 7.11. Include Route Object Object
The IRO (Include Route Object) object is optional and can be used to The IRO (Include Route Object) is optional and can be used to specify
specify that the computed path MUST traverse a set of specified that the computed path MUST traverse a set of specified network
network elements. The IRO object MAY be carried within PCReq and elements. The IRO MAY be carried within PCReq and PCRep messages.
PCRep messages. When carried within a PCRep message with the NO-PATH When carried within a PCRep message with the NO-PATH object, the IRO
object, the IRO indicates the set of elements that fail the PCE to indicates the set of elements that fail the PCE to find a path.
find a path.
IRO Object-Class is to be assigned by IANA (recommended value=10) IRO Object-Class is to be assigned by IANA (recommended value=10)
IRO Object-Type is to be assigned by IANA (recommended value=1) IRO Object-Type is to be assigned by IANA (recommended value=1)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IRO object body format Figure 17: IRO body format
Subobjects The IRO object is made of sub-object(s) identical to the Subobjects The IRO is made of sub-object(s) identical to the ones
ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs.
The following subobject types are supported. The following subobject types are supported.
Type Subobject Type Subobject
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
4 Unnumbered Interface ID 4 Unnumbered Interface ID
32 Autonomous system number 32 Autonomous system number
The L bit of such sub-object has no meaning within an IRO object. The L bit of such sub-object has no meaning within an IRO.
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
skipping to change at page 37, line 40 skipping to change at page 39, line 17
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
path computation requests to a PCE. The first solution consists of path computation requests to a PCE. The first solution consists of
sending N separate PCReq messages to the selected PCE. In this case, sending N separate PCReq messages to the selected PCE. In this case,
the path computation requests are non synchronized. Note that the the path computation requests are non synchronized. Note that the
PCC may chose to distribute the set of N requests across K PCEs for PCC may chose to distribute the set of N requests across K PCEs for
load balancing purpose. Considering that M (with M<N) requests are load balancing purpose. Considering that M (with M<N) requests are
sent to a particular PCEi, as described above, such M requests can be sent to a particular PCEi, as described above, such M requests can be
sent in the form of successive PCReq messages destined to PCEi or sent in the form of successive PCReq messages destined to PCEi or
bundled within a single PCReq message (since PCEP allows for the bundled within a single PCReq message (since PCEP allows for the
bundling of multiple path computation requests within a single PCRep bundling of multiple path computation requests within a single PCReq
message). That said, even in the case of independent requests, it message). That said, even in the case of independent requests, it
can be desirable to request from the PCE the computation of their can be desirable to request from the PCE the computation of their
paths in a synchronized fashion that is likely to lead to more paths in a synchronized fashion that is likely to lead to more
optimal path computations and/or reduced blocking probability if the optimal path computations and/or reduced blocking probability if the
PCE is a stateless PCE. In other words, the PCE should not compute PCE is a stateless PCE. In other words, the PCE should not compute
the corresponding paths in a serialized and independent manner but it the corresponding paths in a serialized and independent manner but it
should rather simultaneously compute their paths. For example, should rather "simultaneously" compute their paths. For example,
trying to simultaneously compute the paths of M TE LSPs may allow the trying to "simultaneously" compute the paths of M TE LSPs may allow
PCE to improve the likelihood to meet multiple constraints. Consider the PCE to improve the likelihood to meet multiple constraints.
the case of two TE LSPs requesting N1 MBits/s and N2 MBits/s Consider the case of two TE LSPs requesting N1 MBits/s and N2 MBits/s
respectively and a maximum tolerable end-to-end delay for each TE LSP respectively and a maximum tolerable end-to-end delay for each TE LSP
of X ms. There may be circumstances where the computation of the of X ms. There may be circumstances where the computation of the
first TE LSP irrespectively of the second TE LSP may lead to the first TE LSP irrespectively of the second TE LSP may lead to the
impossibility to meet the delay constraint for the second TE LSP. A impossibility to meet the delay constraint for the second TE LSP. A
second example is related to the bandwidth constraint. It is quite second example is related to the bandwidth constraint. It is quite
straightforward to provide examples where a serialized independent straightforward to provide examples where a serialized independent
path computation approach would lead to the impossibility to satisfy path computation approach would lead to the impossibility to satisfy
both requests (due to bandwidth fragmentation) while a synchronized both requests (due to bandwidth fragmentation) while a synchronized
path computation would successfully satisfy both requests. A last path computation would successfully satisfy both requests. A last
example relates to the ability to avoid the allocation of the same example relates to the ability to avoid the allocation of the same
skipping to change at page 39, line 34 skipping to change at page 41, line 21
| Request-ID-number #1 | | | Request-ID-number #1 | |
// // // //
| Request-ID-number #M | | Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SVEC body object format Figure 18: SVEC body object format
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: Defines the potential dependency between the set of path Flags (24 bits): Defines the potential dependency between the set of
computation requests. path computation requests.
L (Link diverse) bit: when set, this indicates that the computed o L (Link diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST NOT have any link in common. objects MUST NOT have any link in common.
N (Node diverse) bit: when set, this indicates that the computed o N (Node diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST NOT have any node in common. objects MUST NOT have any node in common.
S (SRLG diverse) bit: when set, this indicates that the computed o S (SRLG diverse) bit: when set, this indicates that the computed
paths corresponding to the requests specified by the following RP paths corresponding to the requests specified by the following RP
objects MUST NOT share any SRLG (Shared Risk Link Group). objects MUST NOT share any SRLG (Shared Risk Link Group).
In case of a set of M synchronized independent path computation In case of a set of M synchronized independent path computation
requests, the bits L, N and S are cleared. requests, the bits L, N and S are cleared.
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
The flags defined above are not exclusive. The flags defined above are not exclusive.
7.12.3. Handling of the SVEC Object 7.12.3. Handling of the SVEC Object
The SVEC object allows a PCC to specify a list of M path computation The SVEC object allows a PCC to specify a list of M path computation
requests that MUST be synchronized along with a potential dependency. requests that MUST be synchronized along with a potential dependency.
The set of M path computation requests may be sent within a single The set of M path computation requests may be sent within a single
PCReq message or multiple PCReq message. In the later case, it is PCReq message or multiple PCReq message. In the later case, it is
RECOMMENDED for the PCE to implement a local timer upon the receipt RECOMMENDED for the PCE to implement a local timer activated upon the
of the first PCReq message that contains the SVEC object after the receipt of the first PCReq message that contains the SVEC object
expiration of which, if all the M path computation requests have not after the expiration of which, if all the M path computation requests
been received, a protocol error is triggered (this timer is called have not been received, a protocol error is triggered (this timer is
the SyncTimer). In this case the PCE MUST cancel the whole set of called the SyncTimer). In this case the PCE MUST cancel the whole
path computation requests and MUST send a PCErr message with Error- set of path computation requests and MUST send a PCErr message with
Type="Synchronized path computation request missing". Error-Type="Synchronized path computation request missing".
Note that such PCReq message may also contain non-synchronized path Note that such PCReq message may also contain non-synchronized path
computation requests. For example, the PCReq message may comprise N computation requests. For example, the PCReq message may comprise N
synchronized path computation requests related to RP 1, ... , RP N synchronized path computation requests related to RP 1, ... , RP N
listed in the SVEC object along with any other path computation listed in the SVEC object along with any other path computation
requests. requests.
7.13. NOTIFICATION Object 7.13. NOTIFICATION Object
The NOTIFICATION object is exclusively carried within a PCNtf message The NOTIFICATION object is exclusively carried within a PCNtf message
skipping to change at page 41, line 21 skipping to change at page 42, line 46
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NOTIFICATION body object format Figure 19: NOTIFICATION body object format
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 flags are currently defined. Unassigned flags
MUST be set to zero on transmission and MUST be ignored on receipt.
NT (Notification Type - 8 bits): the Notification-type specifies the NT (Notification Type - 8 bits): the Notification-type specifies the
class of notification class of notification
NV (Notification Value - 8 bits): the Notification-value provides NV (Notification Value - 8 bits): the Notification-value provides
addition information related to the nature of the notification. addition information related to the nature of the notification.
Flags: no flags are currently defined.
Both the Notification-type and Notification-value should be managed Both the Notification-type and Notification-value should be managed
by IANA. by IANA.
The following Notification-type and Notification-value values are The following Notification-type and Notification-value values are
currently defined: currently defined:
o Notification-type=1: Pending Request cancelled o Notification-type=1: Pending Request cancelled
* Notification-value=1: PCC cancels a set of pending request(s). * Notification-value=1: PCC cancels a set of pending request(s).
A Notification-type=1, Notification-value=1 indicates that the A Notification-type=1, Notification-value=1 indicates that the
skipping to change at page 42, line 10 skipping to change at page 43, line 37
present in the PCNtf message. Multiple RP objects may be present in the PCNtf message. Multiple RP objects may be
carried within the PCNtf message in which case the notification carried within the PCNtf message in which case the notification
applies to all of them. If such notification is received by a applies to all of them. If such notification is received by a
PCC from a PCE, the PCC MUST silently ignore the notification PCC from a PCE, the PCC MUST silently ignore the notification
and no errors should be generated. and no errors should be generated.
* Notification-value=2: PCE cancels a set of pending request(s). * Notification-value=2: PCE cancels a set of pending request(s).
A Notification-type=1, Notification-value=2 indicates that the A Notification-type=1, Notification-value=2 indicates that the
PCE wants to inform a PCC of the cancellation of a set of PCE wants to inform a PCC of the cancellation of a set of
pending request(s). Such event could be triggered because of pending request(s). Such event could be triggered because of
PCE congested state or because of missing path computation PCE overloaded state or because of missing path computation
requests that are part the set of synchronized path computation requests that are part the set of synchronized path computation
requests. A NOTIFICATION object with Notification-type=1, requests. A NOTIFICATION object with Notification-type=1,
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: Overloaded PCE
* 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 an
congested state. If no RP objects are comprised in the PCNtf overloaded 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 overloaded 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 overloaded 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
Notification-value=2 since the list of cancelled requests is Notification-value=2 since the list of cancelled requests is
specified by including the corresponding set of RP object(s). specified by including the corresponding set of RP object(s).
If such notification is received by a PCE from a PCC, the PCE If such notification is received by a PCE from a PCC, the PCE
MUST silently ignore the notification and no errors should be MUST silently ignore the notification and no errors should be
generated. generated.
Optionally, a TLV named CONGESTION-DURATION may be included in the Optionally, a TLV named OVERLOADED-DURATION may be included in the
NOTIFICATION object that specifies the period of time during which no further NOTIFICATION object that specifies the period of time during which no further
request should be sent to the PCE. Once this period of time has elapsed, the PCE request should be sent to the PCE. Once this period of time has elapsed, the PCE
should no longer be considered in congested state. should no longer be considered in congested state.
The CONGESTION-DURATION TLV is composed of 1 octet for the type, The OVERLOADED-DURATION TLV is composed of 1 byte for the type,
1 octet specifying the number of bytes in the value field, 2 octets 1 byte specifying the number of bytes in the value field, 2 bytes
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 bytes specifying the estimated PCE
congestion duration in seconds. The CONGESTION-DURATION TLV is padded congestion duration in seconds. The OVERLOADED-DURATION TLV is padded
to eight-octet alignment. to eight-byte alignment.
TYPE: To be assigned by IANA TYPE: To be assigned by IANA
LENGTH: 4 LENGTH: 4
VALUE: estimated congestion duration in seconds VALUE: period of time (in seconds) during which the PCE should be considered
as overloaded.
* Notification-value=2: A Notification-type=2, Notification- * 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 an OVERLOADED-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
errors should be generated. It is RECOMMENDED to support some errors should be generated. It is RECOMMENDED to support some
dampening notification procedure on the PCE so as to avoid too dampening notification procedure on the PCE so as to avoid too
frequent congestion state and congestion state release frequent congestion state and congestion state release
notifications. For example, an implementation could make use notifications. For example, an implementation could make use
of an hysteresis approach using a dual-thresholds mechanism of an hysteresis approach using a dual-thresholds mechanism
triggering the sending of congestion state notifications. triggering the sending of congestion state notifications.
Furthermore, in case of high instabilities of the PCE Furthermore, in case of high instabilities of the PCE
resources, an additional dampening mechanism SHOULD be used resources, an additional dampening mechanism SHOULD be used
(linear or exponential) to pace the notification frequency and (linear or exponential) to pace the notification frequency and
avoid path computation requests oscillation. avoid path computation requests oscillation.
* Alternatively, PCE may decide to signal its (non) overloaded
state using a IGP-based notification mechanism as defined in
[I-D.ietf-pce-disco-proto-isis]and
[I-D.ietf-pce-disco-proto-ospf]. A PCE may also decide to
signal its overloaded state using PCEP and its no longer
overloaded state using an IGP-based notification and vice-
versa.
7.14. PCEP-ERROR Object 7.14. PCEP-ERROR Object
The PCEP-ERROR object is exclusively carried within a PCErr message The PCEP-ERROR object is exclusively carried within a PCErr message
to notify of a PCEP error. to notify of a PCEP error.
PCEP-ERROR Object-Class is to be assigned by IANA (recommended PCEP-ERROR Object-Class is to be assigned by IANA (recommended
value=13) value=13)
PCEP-ERROR Object-Type is to be assigned by IANA (recommended PCEP-ERROR Object-Type is to be assigned by IANA (recommended
value=1) value=1)
skipping to change at page 44, line 29 skipping to change at page 46, line 8
A PCEP-ERROR object is used to report a PCEP error and is A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error and characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value should be managed by type. Both the Error-Type and the Error-Value should be managed by
IANA (see the IANA section). IANA (see the IANA section).
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. This flag MUST be set
to zero on transmission and MUST be ignored on receipt.
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. provide further information about the encountered error.
A single PCErr message may contain multiple PCEP-ERROR objects. A single PCErr message may contain multiple PCEP-ERROR objects.
skipping to change at page 46, line 34 skipping to change at page 48, line 34
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=3 and 4 respectively). message with a PCEP-ERROR object (Error-Type=3 and 4 respectively).
In addition, the PCC MAY include in the PCErr message the unknown In addition, the PCC MAY include in the PCErr message the unknown or
object. The corresponding path computation request MUST be cancelled not supported object. The corresponding path computation request
by the PCE without further notification. 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 13 skipping to change at page 49, line 13
Error-Type=7: if a PCC sends a synchronized path computation request Error-Type=7: if a PCC sends a synchronized path computation request
to a PCE and the PCE does not receive all the synchronized path to a PCE and the PCE does not receive all the synchronized path
computation requests listed within the corresponding SVEC object computation requests listed within the corresponding SVEC object
after the expiration of the timer SyncTimer defined in after the expiration of the timer SyncTimer defined in
Section 7.12.3, the PCE MUST send a PCErr message with a PCEP-ERROR Section 7.12.3, the PCE MUST send a PCErr message with a PCEP-ERROR
object (Error-Type=7). The corresponding synchronized path object (Error-Type=7). The corresponding synchronized path
computation MUST be cancelled. It is RECOMMENDED for the PCE to computation MUST be cancelled. It is RECOMMENDED for the PCE to
include the REQ-MISSING TLV(s) (defined below) that identifies the include the REQ-MISSING TLV(s) (defined below) that identifies the
missing request(s). missing request(s).
The REQ-MISSING TLV is composed of 1 octet for the type, The REQ-MISSING TLV is composed of 1 byte for the type,
1 octet specifying the number of bytes in the value field, 2 octets 1 byte specifying the number of bytes in the value field, 2 bytes
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 request-id-number a fix length value field of 4 bytes 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-byte 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=8). 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 detects an attempt from another PCEP Error-Type=9: 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 although such bandwidth requirement could be satisfied
a set of TE LSPs such that the sum of their bandwidths is equal to X. by a set of TE LSPs such that the sum of their bandwidths is equal to
Thus it might be useful for a PCC to request a set of TE LSPs so that X. Thus it might be useful for a PCC to request a set of TE LSPs so
the sum of their bandwidth is equal to X MBits/s, with potentially that the sum of their bandwidth is equal to X MBits/s, with
some constraints on the number of TE LSPs and the minimum bandwidth potentially some constraints on the number of TE LSPs and the minimum
of each of these TE LSPs. Such request is made by inserting a LOAD- bandwidth of each of these TE LSPs. Such request is made by
BALANCING object in a PCReq message sent to a PCE. inserting a LOAD-BALANCING object in a PCReq message sent to a PCE.
The LOAD-BALANCING object is optional. The LOAD-BALANCING object is optional.
LOAD-BALANCING Object-Class is to be assigned by IANA (recommended LOAD-BALANCING Object-Class is to be assigned by IANA (recommended
value=14) value=14)
LOAD-BALANCING Object-Type is to be assigned by IANA (recommended LOAD-BALANCING Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the LOAD-BALANCING object body is as follows: The format of the LOAD-BALANCING object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | flags | 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 (16 bits): This field MUST be set to zero on transmission
ignored on receipt. and MUST be ignored on receipt.
Flags: No Flag is currently defined. Flags (8 bits): No Flag is currently defined. The Flag field MUST be
set to zero on transmission and MUST be ignored on receipt).
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 bytes.
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
sum of their bandwidth is X, the maximum number of TE LSP is N and sum of their bandwidth is X, the maximum number of TE LSP is N and
each TE LSP must at least have a bandwidth of B, it inserts a each TE LSP must at least have a bandwidth of B, it inserts a
BANDWIDTH object specifying X as the required bandwidth and a LOAD- BANDWIDTH object specifying X as the required bandwidth and a LOAD-
BALANCING object with the Max-LSP and Min-Bandwidth fields set to N BALANCING object with the Max-LSP and Min-Bandwidth fields set to N
and B respectively. and B respectively.
7.16. CLOSE Object 7.16. CLOSE Object
skipping to change at page 49, line 24 skipping to change at page 51, line 24
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. The following values are The setting of this field is optional. The following values are
currently 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 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 (16 bits): This field MUST be set to zero on transmission
ignored on receipt. and MUST be ignored on receipt.
Flags (4 bits): No Flags are currently defined. Flags (4 bits): No Flags are currently defined. The Flag field MUST
be set to zero on transmission and MUST be ignored on receipt.
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
This section is compliant with This section follows the guidance of
[I-D.ietf-pce-manageability-requirements]. [I-D.ietf-pce-manageability-requirements].
8.1. Control of Function and Policy 8.1. Control of Function and Policy
A PCEP implementation SHOULD allow configuring the following PCEP A PCEP implementation SHOULD allow configuring the following PCEP
session parameters on a PCEP peer: session parameters on a PCEP peer:
o The local keepalive and Deadtimer (i.e. parameters send by the o The local keepalive and Deadtimer (i.e. parameters send by the
PCEP speaker in an Open message), PCEP speaker in an Open message),
o The maximum acceptable remote keepalive and dead timers o The maximum acceptable remote keepalive and dead timers
(i.e.parameters sent by a peer in an Open message), (i.e.parameters sent by a peer in an Open message),
o Negotiation enabled or disabled, o Negotiation enabled or disabled,
o If negotiation is allowed, the minimum acceptable Keepalive and o If negotiation is allowed, the minimum acceptable Keepalive and
Deadtimer timers sent by a PCEP peer, Deadtimer timers sent by a PCEP peer,
o The SyncTimer, o The SyncTimer,
o The maximum number of sessions that can be setup o The maximum number of sessions that can be setup,
o Request timer: amount of time a PCC waits for a reply before o Request timer: amount of time a PCC waits for a reply before
resending its path computation requests (potentially to an resending its path computation requests (potentially to an
alternate PCE). alternate PCE).
These parameters may be configured as default parameters for any PCEP These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific 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 session with a given PCEP peer or a specific group of sessions with a
specific group of PCEP peers. A PCEP implementation SHOULD allow specific group of PCEP peers. A PCEP implementation SHOULD allow
configuring the initiation of a PCEP session with a selected subset configuring the initiation of a PCEP session with a selected subset
skipping to change at page 54, line 10 skipping to change at page 56, line 10
1 1
14 LOAD-BALANCING 14 LOAD-BALANCING
Object-Type Object-Type
1 1
15 CLOSE 15 CLOSE
Object-Type Object-Type
1 1
9.4. Notification 9.4. Notification Object
A NOTIFICATION object is characterized by a Notification-type that A NOTIFICATION object is characterized by a Notification-type that
specifies the class of notification and a Notification-value that specifies the class of notification and a Notification-value that
provides additional information related to the nature of the provides additional information related to the nature of the
notification. Both the Notification-type and Notification-value are notification. Both the Notification-type and Notification-value are
managed by IANA (see IANA section). managed by IANA (see IANA section).
Notification-type Name Notification-type Name
1 Pending Request cancelled 1 Pending Request cancelled
Notification-value Notification-value
1: PCC cancels a set of pending request(s) 1: PCC cancels a set of pending request(s)
2: PCE cancels a set of pending request(s) 2: PCE cancels a set of pending request(s)
2 PCE Congestion 2 PCE Congestion
Notification-value Notification-value
1: PCE in congested state 1: PCE in congested state
2: PCE no longer in congested state 2: PCE no longer in congested state
9.5. PCEP Error 9.5. PCEP Error Object
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 message Error-value=1: reception of a malformed message
skipping to change at page 55, line 21 skipping to change at page 57, line 21
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
Error-value=7: No Keepalive or PCErr message received Error-value=7: No Keepalive or PCErr message received
before the expiration of the KeepWait timer before the expiration of the KeepWait timer
Error-value=8: PCEP version not supported
2 Capability not supported 2 Capability not supported
3 Unknown Object 3 Unknown Object
Error-value=1: Unrecognized object class Error-value=1: Unrecognized object class
Error-value=2: Unrecognized object Type Error-value=2: Unrecognized object Type
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 cleared (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 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 Attempt to establish a second PCEP session 9 Attempt to establish a second PCEP session
9.6. NO-PATH-VECTOR TLV 9.6. CLOSE Object
The CLOSE object MUST be present in each Close message in order to
close a PCEP session. The reason field of the CLOSE object specifies
the reason for closing the PCEP session. The reason field of the
CLOSE object is managed by IANA.
Reasons
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
9.7. 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
- Defining RFC - Name of bit - Defining RFC - Name of bit
Currently two bits are defined. Currently two bits are defined.
Here are the suggested values: Here are the suggested values:
0x01: PCE currently Unavailable 0x01: PCE currently Unavailable
0x02: Unknown Destination. 0x02: Unknown Destination
0x03: Unknown Source
10. PCEP Finite State Machine (FSM) 10. PCEP Finite State Machine (FSM)
The section describes the PCEP Finite State Machine (FSM). The section describes the PCEP Finite State Machine (FSM).
PCEP Finite State Machine PCEP Finite State Machine
+-+-+-+-+-+-+<------+ +-+-+-+-+-+-+<------+
+------| SessionUP |<---+ | +------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | | | +-+-+-+-+-+-+ | |
skipping to change at page 57, line 5 skipping to change at page 59, line 41
|||| V | | |||| V | |
|||+--->+-+-+-+-+ | | |||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ | ||+---->| Idle |-------+ |
|+----->| |----------+ |+----->| |----------+
+------>+-+-+-+-+ +------>+-+-+-+-+
Figure 23: PCEP Finite State Machine for the PCC Figure 23: PCEP Finite State Machine for the PCC
PCEP defines the following set of variables: PCEP defines the following set of variables:
TCPConnect: timer (in seconds) started after having initialized a TCP Connect: timer (in seconds) started after having initialized a TCP
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 ConnectRetry: 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 ConnectMaxRetry: Maximum number of times the system tries to
TCP connection using the PCEP well-known TCP port before going back establish a TCP connection using the PCEP well-known TCP port before
to the Idle state. The value of the TCPMaxRetry is 5. going back to the Idle state. The value of the ConnectMaxRetry is 5.
OpenWait: timer that corresponds to the amount of time a PCEP peer OpenWait: timer that corresponds to the amount of time a PCEP peer
will wait to receive an Open message from the PCEP peer after the will wait to receive an Open message from the PCEP peer after the
expiration of which the system releases the PCEP resource and go back expiration of which the system releases the PCEP resource and go back
to the Idle state. The OpenWait timer has a fixed value of 1 minute. to the Idle state. The OpenWait timer has a fixed value of 60
seconds.
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 60 seconds.
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.
The following two states variable are defined: The following two states variable are defined:
RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system
has received an acceptable Open message. has received an acceptable Open message.
LocalOK: the LocalOK variable is a Boolean set to 1 if the system has LocalOK: the LocalOK variable is a Boolean set to 1 if the system has
skipping to change at page 58, line 4 skipping to change at page 60, line 42
as "the system") waits for an initialization event that can either be as "the system") waits for an initialization event that can either be
manually triggered by the user (configuration) or automatically manually triggered by the user (configuration) or automatically
triggered by various events. In Idle state, PCEP resources are triggered by various events. In Idle state, PCEP resources are
allocated (memory, potential process, ...) but no PCEP messages are allocated (memory, potential process, ...) but no PCEP messages are
accepted from any PCEP peer. The system listens the well-known PCEP accepted from any PCEP peer. The system listens the well-known PCEP
TCP port. TCP port.
The following set of variable are initialized: The following set of variable are initialized:
TCPRetry=0, TCPRetry=0,
LocalOK=0, LocalOK=0,
RemoteOK=0, RemoteOK=0,
OpenRetry=0. OpenRetry=0.
Upon detection of a local initialization event (e.g. user Upon detection of a local initialization event (e.g. user
configuration to establish a PCEP session with a particular PCEP configuration to establish a PCEP session with a particular PCEP
peer, local event triggering the establishment of a PCEP session with peer, local event triggering the establishment of a PCEP session with
a PCEP peer, ...), the system: a PCEP peer such as the automatic detection of a PCEP peer, ...), the
system:
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 Starts the Connect timer,
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 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 Moves to the OpenWait state. o Moves to the OpenWait state.
If the connection establishment fails, the system remains in the Idle
state. Any other event received in the Idle state is ignored.
It is expected that an implementation will use an exponentially It is expected that an implementation will use an exponentially
increase timer between automatically generated Initialization events increase timer between automatically generated Initialization events
and between retrials of TCP connection establishments. and between retrials of TCP connection establishments.
TCPPending State TCPPending State
If the TCP connection establishment succeeds, the system: If 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 Starts the KeepWait timer,
o Moves to the OpenWait state. o Moves to the OpenWait state.
If the TCP connection establishment fails (an error is detected If the TCP connection establishment fails (an error is detected
during the TCP connection establishment) or the TCPConnectTimer during the TCP connection establishment) or the Connect timer
expires: expires:
If TCPRetry =TCPMaxRetry the system moves to the Idle State If ConnectRetry =ConnectMaxRetry the system moves to the Idle State
If TCPRetry < TCPMaxRetry the system:
o Starts the TCPConnect timer, If ConnectRetry < ConnectMaxRetry the system:
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 ConnectRetry variable,
o Restarts the Connect timer,
o Stays in the TPCPending state. o Stays in the TPCPending state.
If the system detects that the PCEP peer tries to simultaneously If the system detects that the PCEP peer tries to simultaneously
establish a TCP connection, it stops the TCP connection establishment establish a TCP connection, it stops the TCP connection establishment
if and only if the PCEP peer has a higher IP address and moves to the if and only if the PCEP peer has a higher IP address and moves to the
Idle state. This guarantees that in case of "collision" a single TCP Idle state. This guarantees that in case of "collision" a single TCP
connection is established. connection is established.
In response to any other event the system releases the PCEP resources
for that peer and moves back to the Idle state.
OpenWait State: OpenWait State:
In the OpenWait state, the system waits for an Open message from its In the OpenWait state, the system waits for an Open message from its
PCEP peer. PCEP peer.
If the system receives an Open message from the PCEP peer before the If the system receives an Open message from the PCEP peer before the
expiration of the OpenWait timer, PCEP checks the PCEP session expiration of the OpenWait timer, PCEP checks the PCEP session
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 no errors are detected, OpenRetry=2 and the session If no errors are detected, OpenRetry=1 and the session
characteristics are unacceptable, the PCEP peer sends a PCErr with characteristics are unacceptable, the PCEP peer sends a PCErr with
Error-Type=1 and Error-value=5, the system releases the PCEP Error-Type=1 and Error-value=5, the system releases the PCEP
resources for that peer and moves back to the Idle state. 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 clears the OpenWait timer and moves to the UP
state.
If LocalOK=0 the system moves to the KeepWait state. If LocalOK=0 the system clears the OpenWait timer, starts the
KeepWait timer and 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
Error-Type=1 and Error-value=3, the system releases the PCEP Error-Type=1 and Error-value=3, the system releases the PCEP
resources for that peer, and moves back to the Idle state. resources for that peer, and moves back to the Idle state.
If no errors are detected, OpenRetry=1, the session characteristics If no errors are detected, OpenRetry=0, the session characteristics
are unacceptable but negotiable (such as the Keepalive frequency or are unacceptable but negotiable (such as the Keepalive period or the
the DeadTimer), the system: DeadTimer), the system:
o sends a PCErr message with Error-Type=1 and Error-value=4 that o Increments the OpenRetry variable,
o Sends a PCErr message with Error-Type=1 and Error-value=4 that
contains proposed acceptable session characteristics, contains proposed acceptable session characteristics,
o If LocalOK=1, the system stays in the OpenWait state o If LocalOK=1, the system restarts the OpenWait timer and stays in
the OpenWait state
o If LocalOK=0, the system moves to the KeepWait state o If LocalOK=0, the system clears the OpenWait timer, starts the
KeepWait timer and moves to the KeepWait state
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 PCEP peer sends a PCErr message with Error-Type=1 and timer, the PCEP peer sends a PCErr message with Error-Type=1 and
Error-value=2, the system releases the PCEP resources for the PCEP Error-value=2, the system releases the PCEP resources for the PCEP
peer, closes the TCP connection and moves to the Idle state. peer, closes the TCP connection and moves to the Idle state.
In response to any other event the system releases the PCEP resources
for that peer and moves back to the Idle state.
KeepWait State KeepWait State
In the Keepwait state, the system waits for the receipt of a In the Keepwait state, the system waits for the receipt of a
Keepalive from its PCEP peer acknowledging its Open message or a Keepalive from its PCEP peer acknowledging its Open message or a
PCErr message in response to unacceptable PCEP session PCErr message in response to unacceptable PCEP session
characteristics proposed in the Open message. characteristics proposed in the Open message.
If an error is detected (e.g. malformed Keepalive message), PCEP
generates an error notification, the PCEP 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 connection and moves to
the Idle state.
If a Keepalive message is received before the expiration of the If a Keepalive message is received before the expiration of the
KeepWait timer, LocalOK=1 KeepWait timer, then the system sets LocalOK=1 and:
If RemoteOK=1, the system moves to the UP state. o If RemoteOK=1, the system clears the KeepWait timer and moves to
the UP state.
If RemoteOK=0, the system moves to the OpenWait State. o If RemoteOK=0, the system clears the KeepWait timer, starts the
OpenWait timer and moves to the OpenWait State.
If a PCErr message is received before the expiration of the KeepWait If a PCErr message is received before the expiration of the KeepWait
timer: timer:
1. If the proposed values are unacceptable, the PCEP peer sends a 1. If the proposed values are unacceptable, the PCEP peer sends a
PCErr message with Error-Type=1 and Error-value=6 and the system PCErr message with Error-Type=1 and Error-value=6 and the system
releases the PCEP resources for that PCEP peer, closes the TCP releases the PCEP resources for that PCEP peer, closes the TCP
connection and moves to the Idle state. connection and moves to the Idle state.
2. If the proposed values are acceptable, the system adjusts its 2. If the proposed values are acceptable, the system adjusts its
PCEP session characteristics according to the proposed values PCEP session characteristics according to the proposed values
received in the PCErr message restarts the KeepWait timer and received in the PCErr message restarts the KeepWait timer and
sends a new Open message. If RemoteOK=1, the system stays in the sends a new Open message. If RemoteOK=1, the system restarts the
KeepWait state. If RemoteOK=0, the system moves to the OpenWait KeepWait timer and stays in the KeepWait state. If RemoteOK=0,
state. the system clears the KeepWait timer, start the OpenWait timer
and moves to the OpenWait state.
If neither a Keepalive nor a PCErr is received after the expiration If neither a Keepalive nor a PCErr is received after the expiration
of the KeepWait timer, the PCEP peer sends a PCErr message with of the KeepWait timer, the PCEP peer sends a PCErr message with
Error-Type=1 and Error-value=7 and, system releases the PCEP Error-Type=1 and Error-value=7 and, system releases the PCEP
resources for that PCEP peer, closes the TCP connection and moves to resources for that PCEP peer, closes the TCP connection and moves to
the Idle State. the Idle State.
In response to any other event the system releases the PCEP resources
for that peer and moves back to 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 restarts the Keepalive
timer and 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, terminates PCEP the PCEP peer after the expiration of the DeadTimer, the system
session according to the procedure defined in Section 6.8, releases terminates PCEP session according to the procedure defined in
the PCEP resources for that PCEP peer, closes the TCP connection and Section 6.8, releases the PCEP resources for that PCEP peer, closes
moves to the Idle State. 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, releases session according to the procedure defined in Section 6.8, releases
the PCEP resources for that PCEP peer, closes the TCP connection and the PCEP resources for that PCEP peer, closes the TCP 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 If the system detects that the PCEP peer tries to setup a second TCP
connection, it stops the TCP connection establishment and sends a connection, it stops the TCP connection establishment and sends a
PCErr with Error-Type=10. PCErr with Error-Type=9.
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 62, line 43 skipping to change at page 66, line 6
Note that when one digest technique stronger than MD5 is specified Note that when one digest technique stronger than MD5 is specified
and implemented, PCEP could be easily upgraded to use it. and implemented, PCEP could be easily upgraded to use it.
11.2. PCEP Privacy 11.2. PCEP Privacy
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication end-points do not
reside in the same AS, as an attacker that intercept a PCE message reside in the same AS, as an attacker that intercept a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. Privacy can be ensured thanks to encryption. To ensure resources. Privacy can be ensured thanks to encryption. To ensure
privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used privacy of PCEP communication, IPSec [RFC4303] tunnels MAY be used
between PCC and PCEs or between PCEs. Note that this could also be between PCC and PCEs or between PCEs. Note that this could also be
used to ensure Authentication and Integrity, in which case, TCP MD-5 used to ensure Authentication and Integrity, in which case, TCP MD-5
option would not be required. option would not be required.
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:
skipping to change at page 64, line 39 skipping to change at page 68, line 9
Garden Air Tower Iidabashi, Chiyoda-ku, Garden Air Tower Iidabashi, Chiyoda-ku,
Tokyo, 102-8460 Tokyo, 102-8460
JAPAN JAPAN
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard
Douville and Jon Parker for their very valuable input. Special thank Douville, Jon Parker and Martin German for their very valuable input.
to Adrian Farrel for his very valuable suggestions. Special thank to Adrian Farrel for his very valuable suggestions.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
skipping to change at page 65, line 30 skipping to change at page 68, line 39
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC4674] Le Roux, J., "Requirements for Path Computation Element
(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., "Inter domain Multiprotocol Label Switching Ayyangar, A., "Inter domain Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering -
RSVP-TE extensions", RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-05 (work in draft-ietf-ccamp-inter-domain-rsvp-te-06 (work in
progress), March 2007. progress), April 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-02 (work in progress), draft-ietf-pce-disco-proto-isis-06 (work in progress),
February 2007. June 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-02 (work in progress), draft-ietf-pce-disco-proto-ospf-06 (work in progress),
February 2007. June 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-04 (work in progress),
October 2006. March 2007.
[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] [I-D.ietf-pce-manageability-requirements]
Farrel, A., "Inclusion of Manageability Sections in PCE Farrel, A., "Inclusion of Manageability Sections in PCE
Working Group Drafts", Working Group Drafts",
draft-ietf-pce-manageability-requirements-01 (work in draft-ietf-pce-manageability-requirements-01 (work in
progress), March 2007. progress), March 2007.
[I-D.ietf-pce-pcecp-interarea-reqs]
Roux, J., "PCE Communication Protocol (PCECP) Specific
Requirements for Inter-Area Multi Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work
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-07 (work in progress), draft-ietf-rpsec-bgpsecrec-07 (work in progress),
February 2007. February 2007.
[I-D.kkoushik-pce-pcep-mib] [I-D.kkoushik-pce-pcep-mib]
Stephan, E. and K. Koushik, "PCE communication Stephan, E. and K. Koushik, "PCE communication
protocol(PCEP) Management Information Base", protocol(PCEP) Management Information Base",
draft-kkoushik-pce-pcep-mib-00 (work in progress), draft-kkoushik-pce-pcep-mib-00 (work in progress),
February 2007. February 2007.
[I-D.vasseur-pce-monitoring] [I-D.vasseur-pce-monitoring]
Roux, J. and J. Vasseur, "A set of monitoring tools for Vasseur, J., "A set of monitoring tools for Path
Path Computation Element based Architecture", Computation Element based Architecture",
draft-vasseur-pce-monitoring-02 (work in progress), draft-vasseur-pce-monitoring-03 (work in progress),
March 2007. May 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
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 [RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022, Transmission Control Protocol (TCP)", RFC 4022,
March 2005. 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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 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 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
The aim of this section is to list the set of requirements set forth
in [RFC4657] that are not satisfied by the current revision of this
document. This only concerns the requirements listed as MUST
according to [RFC2119].
Here is the list of currently unsatisfied requirements:
o Allow to select/prefer from advertised list of standard objective [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
functions/options Communication Protocol Generic Requirements", RFC 4657,
September 2006.
o Allow to customize objective function/options [RFC4674] Le Roux, J., "Requirements for Path Computation Element
o Support "unsynchronized" & "synchronized" objective functions (PCE) Discovery", RFC 4674, October 2006.
PCEP is a flexible protocol allowing for the addition of new message [RFC4927] Le Roux, J., "Path Computation Element Communication
and objects type. With regards to the requirement liste above, the Protocol (PCECP) Specific Requirements for Inter-Area MPLS
Working Group has decided to cover those requirements in a separate and GMPLS Traffic Engineering", RFC 4927, June 2007.
document.
Appendix B. PCEP Variables Appendix A. PCEP Variables
PCEP defines the following configurable variables: PCEP defines the following configurable variables:
KeepAlive timer: minimum period of time between the sending of PCEP KeepAlive timer: minimum period of time between the sending of PCEP
messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A
suggested value for the Keepalive timer is 30 seconds. suggested value for the Keepalive timer is 30 seconds.
DeadTimer: period of timer after the expiration of which a PCEP peer DeadTimer: period of timer after the expiration of which a PCEP peer
declared the session down if no PCEP message has been received. declared the session down if no PCEP message has been received.
 End of changes. 168 change blocks. 
399 lines changed or deleted 495 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/