draft-ietf-pce-pcep-12.txt   draft-ietf-pce-pcep-13.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.
Created: March 24, 2008 France Telecom Expires: February 19, 2009 France Telecom
Expires: September 24, 2008 August 18, 2008
Path Computation Element (PCE) Communication Protocol (PCEP) Path Computation Element (PCE) Communication Protocol (PCEP)
draft-ietf-pce-pcep-12.txt draft-ietf-pce-pcep-13.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 24, 2008. This Internet-Draft will expire on February 19, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Such interactions include path computation requests and path Such interactions include path computation requests and path
computation replies as well as notifications of specific states computation replies as well as notifications of specific states
related to the use of a PCE in the context of Multiprotocol Label related to the use of a PCE in the context of Multiprotocol Label
Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.2.2. Path Computation Request Sent By a PCC to a PCE . . . 8 4.2.2. Path Computation Request Sent By a PCC to a PCE . . . 8
4.2.3. Path Computation Reply Sent By The PCE to a PCC . . . 9 4.2.3. Path Computation Reply Sent By The PCE to a PCC . . . 9
4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11
4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13 4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13
4.2.7. Intermitent versus Permanent PCEP Session . . . . . . 14 4.2.7. Intermitent versus Permanent PCEP Session . . . . . . 14
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 14 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 14
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 16 6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 17
6.4. Path Computation Request (PCReq) Message . . . . . . . . . 17 6.4. Path Computation Request (PCReq) Message . . . . . . . . . 18
6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 18 6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 18
6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 20 6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 20
6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 21
6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 21 6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 22
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 22 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 22 7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 23
7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 26 7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 26
7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 28 7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 28
7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 28 7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 29
7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 31 7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 32
7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 32 7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 33
7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 33 7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 34
7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 36 7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 37
7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 36 7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 38
7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 37 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 38
7.12. Include Route Object Object . . . . . . . . . . . . . . . 38 7.12. Include Route Object Object . . . . . . . . . . . . . . . 40
7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 39 7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 40
7.13.1. Notion of Dependent and Synchronized Path 7.13.1. Notion of Dependent and Synchronized Path
Computation Requests . . . . . . . . . . . . . . . . . 39 Computation Requests . . . . . . . . . . . . . . . . . 40
7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 41 7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 42
7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 42 7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 43
7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 42 7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 44
7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 45 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 47
7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 50 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 51
7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 51 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 52
8. Manageability Considerations . . . . . . . . . . . . . . . . . 52 8. Manageability Considerations . . . . . . . . . . . . . . . . . 53
8.1. Control of Function and Policy . . . . . . . . . . . . . . 52 8.1. Control of Function and Policy . . . . . . . . . . . . . . 54
8.2. Information and Data Models . . . . . . . . . . . . . . . 53 8.2. Information and Data Models . . . . . . . . . . . . . . . 55
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 53 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 55
8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 53 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 55
8.5. Requirements on Other Protocols and Functional 8.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 54 Components . . . . . . . . . . . . . . . . . . . . . . . . 56
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 54 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 56
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.2. PCEP Top-Level Registry . . . . . . . . . . . . . . . . . . 54 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 56
9.2.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . 55 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 57
9.2.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . 55 9.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 58
9.2.3. RP Object . . . . . . . . . . . . . . . . . . . . . . 56 9.5. Notification Object . . . . . . . . . . . . . . . . . . . 59
9.2.4. Notification Object . . . . . . . . . . . . . . . . . 56 9.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 59
9.2.5. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . 57 9.7. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 60
9.2.6. CLOSE Object . . . . . . . . . . . . . . . . . . . . . 60 9.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 61
9.2.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . 60 9.9. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 61
9.2.7.1. No-Path Nature of Issue . . . . . . . . . . . . . . 60 9.10. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 62
9.2.7.2. No-Path Bit Flags . . . . . . . . . . . . . . . . . 60 9.11. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 62
9.2.8. METRIC Object . . . . . . . . . . . . . . . . . . . . 61
9.2.8.1. Metric Type . . . . . . . . . . . . . . . . . . . . 61
9.2.8.2. Metric Control Flags . . . . . . . . . . . . . . . 61
9.2.9. PCEP TLV Type Indicators . . . . . . . . . . . . . . . 61
9.2.10. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62
10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62 10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 63
10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 63 10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 63
10.3. Protection Against Denial of Service Attacks . . . . . . . 63 10.3. Protection Against Denial of Service Attacks . . . . . . . 63
10.3.1. Protection Against TCP DoS Attacks . . . . . . . . . . 63 10.3.1. Protection Against TCP DoS Attacks . . . . . . . . . . 63
10.3.2. Request Input Shaping/Policing . . . . . . . . . . . . 63 10.3.2. Request Input Shaping/Policing . . . . . . . . . . . . 64
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 64 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 64
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . . 65 13.2. Informative References . . . . . . . . . . . . . . . . . . 66
Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 68 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 68
Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 74 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
Intellectual Property and Copyright Statements . . . . . . . . . . 76 Intellectual Property and Copyright Statements . . . . . . . . . . 77
1. Introduction 1. Introduction
[RFC4655] describes the motivations and architecture for a Path [RFC4655] describes the motivations and architecture for a Path
Compuation Element (PCE) based model for the computation of Compuation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic
Engineering Label Swtich Paths (TE LSPs). The model allows for the Engineering Label Swtich Paths (TE LSPs). The model allows for the
separation of PCE from Path Computation Client (PCC), and allows for separation of PCE from Path Computation Client (PCC), and allows for
the cooperation between PCEs. This necessitates a communication the cooperation between PCEs. This necessitates a communication
protocol between PCC and PCE, and between PCEs. [RFC4657] states the protocol between PCC and PCE, and between PCEs. [RFC4657] states the
skipping to change at page 5, line 27 skipping to change at page 5, line 27
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
Strict/loose path: mix of strict and loose hops comprising at least Strict/loose path: mix of strict and loose hops comprising at least
one loose hop representing the destination where a hop may be an one loose hop representing the destination where a hop may be an
abstract node such as an AS. abstract node such as an AS.
Within this document, when describing PCE-PCE communications, the Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Backus Naur
Format (BNF) encoding. The BNF used is very simple and is modeled on
that used in the Resource Reservation Protocol (RSVP) [RFC2205], the
Traffic Engineering extensions to RSVP (RSVP-TE) [RFC3209], and the
Generalized Multiprotocol Label Switching (GMPLS) extensions to
RSVP-TE [RFC3473].
3. Assumptions 3. Assumptions
[RFC4655] describes various types of PCE. PCEP does not make any [RFC4655] describes various types of PCE. PCEP does not make any
assumption and thus does not impose any constraint on the nature of assumption and thus does not impose any constraint on the nature of
the PCE. the PCE.
Moreover, it is assumed that the PCE has the required information Moreover, it is assumed that the PCE has the required information
(usually including network topology and resource information) so as (usually including network topology and resource information) so as
to perform the computation of a path for a TE LSP. Such information to perform the computation of a path for a TE LSP. Such information
can be gathered by routing protocols or by some other means. The way can be gathered by routing protocols or by some other means. The way
skipping to change at page 6, line 21 skipping to change at page 6, line 23
4.1. Problem 4.1. Problem
The PCE-based architecture used for the computation of path for MPLS The PCE-based architecture used for the computation of path for MPLS
and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the
PCE are not collocated, a communication protocol between the PCC and PCE are not collocated, a communication protocol between the PCC and
the PCE is needed. PCEP is such a protocol designed specifically for the PCE is needed. PCEP is such a protocol designed specifically for
communications between a PCC and a PCE or between two PCEs in communications between a PCC and a PCE or between two PCEs in
compliance with [RFC4657]: a PCC may use PCEP to send a path compliance with [RFC4657]: a PCC may use PCEP to send a path
computation request for one or more TE LSPs to a PCE and the PCE may computation request for one or more TE LSPs to a PCE and the PCE may
reply with a set of computed paths if one or more paths can be found reply with a set of computed paths if one or more path(s) can be
that satisfies the set of constraints. found that satisfies the set of constraints.
4.2. Architectural Protocol Overview 4.2. Architectural Protocol Overview
PCEP operates over TCP, which fulfils the requirements for reliable PCEP operates over TCP, which fulfils the requirements for reliable
messaging and flow control without further protocol work. messaging and flow control without further protocol work.
Several PCEP messages are defined: Several PCEP messages are defined:
- 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 paths if the request can be satisfied, or a negative reply computed paths if the request can be satisfied, or a negative reply
if not. The negative reply may indicate the reason why no path if not. The negative reply may indicate the reason why no path could
could be found. 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 PCEs may be either statically configured on a The set of available PCE(s) may be either statically configured on a
PCC or dynamically discovered. The mechanisms used to discover one PCC or dynamically discovered. The mechanisms used to discover one
or more PCEs and to select a PCE are out of the scope of this or more PCEs 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 38 skipping to change at page 7, line 43
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 Keepalive messages are used to acknowledge Open messages, and once
the PCEP session has been successfully established, Keepalive the PCEP session has been successfully established, Keepalive
messages may be exchanged between PCEP peers to ensure the liveness messages may be exchanged between PCEP peers to ensure the liveness
of the PCEP session. of the PCEP session.
Only one PCEP session can exist between a pair a PCEP peers at any Only one PCEP session can exist between a pair of PCEP peers at any
one time. one time.
Details about the Open message and the Keepalive message can be found Details about the Open message and the Keepalive message can be found
inSection 6.2 and Section 6.3 respectively. inSection 6.2 and Section 6.3 respectively.
+---+ +---+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
| Open msg | | Open msg |
|-------- | |-------- |
| \ Open msg | | \ Open msg |
| \ ---------| | \ ---------|
| \/ | | \/ |
| /\ | | /\ |
| / -------->| | / -------->|
skipping to change at page 8, line 36 skipping to change at page 8, line 36
: : : :
| | | |
|---- Keepalive ----->| |---- Keepalive ----->|
| | | |
|<--- Keepalive ------| |<--- Keepalive ------|
| | | |
Figure 1: PCEP Initialization phase (initiated by a PCC) Figure 1: PCEP Initialization phase (initiated by a PCC)
(Note that once the PCEP session is established, the exchange of (Note that once the PCEP session is established, the exchange of
Keepalive messages is optional.) 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 | |
request sent to | | request sent to | |
the selected PCE | | the selected PCE | |
|---- PCReq message -->|
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 paths, the PCC first selects one or more PCE. Note that the a set of paths, the PCC first selects one or more PCE. Note that the
PCE selection decision process may have taken place prior to the PCEP PCE selection decision process may have taken place prior to the PCEP
session establishment. session establishment.
Once the PCC has selected a PCE, it sends the PCE a path computation Once the PCC has selected a PCE, it sends the PCE a path computation
skipping to change at page 10, line 6 skipping to change at page 10, line 4
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
form in Figure 2. form in Figure 2.
Details about the PCReq message can be found in Section 6.4 Details about the PCReq message can be found in Section 6.4
4.2.3. Path Computation Reply Sent By The PCE to a PCC 4.2.3. Path Computation Reply Sent By The PCE to a PCC
+-+-+ +-+-+
+---+ +---+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---- PCReq message--->| |---- PCReq message--->|
| |1) Path computation | |1) Path computation
| |request received | |request received
| | | |
| |2)Path successfully | |2)Path successfully
| |computed | |computed
| | | |
| |3) Computed paths | |3) Computed path(s)
| |sent to the PCC | |sent
| |to the PCC
|<--- PCRep message ---| |<--- PCRep message ---|
| (Positive reply) | | (Positive reply) |
Figure 3a: Path Computation Request With Successful Figure 3a: Path Computation Request With Successful
Path Computation Path Computation
+---+ +---+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
| | | |
|---- PCReq message -->| |---- PCReq message--->|
| |1) Path computation | |1) Path computation
| |request received | |request received
| | | |
| |2) No Path found that | |2) No Path found that
| |satisfies the request | |satisfies the request
| | | |
| |3) Negative reply sent to | |3) Negative reply sent to
| |the PCC (optionally with | |the PCC (optionally with
| |various additional | |various additional
| |information) | |information)
skipping to change at page 12, line 5 skipping to change at page 12, line 5
PCC of a specific event. For example, suppose that the PCE suddenly PCC of a specific event. For example, suppose that the PCE suddenly
gets overloaded, potentially leading to unacceptable response times. gets overloaded, potentially leading to unacceptable response times.
The PCE may want to notify one or more PCCs that some of their The PCE may want to notify one or more PCCs that some of their
requests (listed in the notification) will not be satisfied or may requests (listed in the notification) will not be satisfied or may
experience unacceptable delays. Upon receiving such notification, experience unacceptable delays. Upon receiving such notification,
the PCC may decide to redirect its path computation requests to the PCC may decide to redirect its path computation requests to
another PCE should an alternate PCE be available. Similarly, a PCC another PCE should an alternate PCE be available. Similarly, a PCC
may desire to notify a PCE of a particular event such as the may desire to notify a PCE of a particular event such as the
cancellation of pending requests. cancellation of pending requests.
+---+ +---+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
1)Path computation | | 1)Path computation | |
event | | event | |
| |
2)PCE Selection | | 2)PCE Selection | |
3)Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | |request queued
| | | |
3)Path computation | |
request X sent to | |
the selected PCE | |
|---- PCReq message -->|
| |4) Path computation
| |request queued
| | | |
5) Path computation| | 5) Path computation| |
request X cancelled| | request X cancelled| |
|---- PCNtf message -->| |---- PCNtf message -->|
| |6) Path computation | |6) Path computation
| |request X cancelled | |request X cancelled
Figure 4: Example of PCC Notification (Cancellation Figure 4: Example of PCC Notification (Cancellation
Notification) Sent To a PCE Notification)
Sent 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--->|
request X sent to | |4) Path computation
the selected PCE | |request queued
| | | |
3)Path computation | |
request X sent to | |
the selected PCE | |
|---- PCReq message -->|
| |4) Path computation
| |request queued
| | | |
| |5) PCE gets overloaded | |5) PCE gets overloaded
| | | |
| |
| |6) Path computation | |6) Path computation
| |request X cancelled | |request X cancelled
|<--- PCNtf message ---| | |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation Figure 5: Example of PCE Notification (Cancellation
Notification) Sent To a PCC 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.
4.2.5. Error 4.2.5. Error
The PCEP Error message (also referred to as a PCErr message) is sent The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g., the request is not compliant with the PCEP specification (e.g.,
reception of a malformed message, reception of a message with a capability not supported, reception of a message with a mandatory
mandatory missing object, policy violation, unexpected message, missing object, policy violation, unexpected message, unknown request
unknown request reference, ...). reference, ...).
+---+ +---+ +-+-+ +-+-+
|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 | | request X sent to | |4) Reception of a
request X sent to | | the selected PCE | |malformed object
the selected PCE | |
|---- PCReq message--->|
| |4) Reception of a
| |malformed object
| | | |
| |5) Request discarded | |5) Request discarded
|<-- PCErr message ----| | |
|<-- PCErr message ---|
| |
Figure 6: Example of Error message Sent By a PCE To a PCC Figure 6: Example of Error message Sent By a PCE To a PCC
In Reply To The Reception Of a Malformed Object In Reply To The Reception Of a Malformed Object
Details about the PCErr message can be found in Section 6.7. Details about the PCErr message can be found in Section 6.7.
4.2.6. Termination of the PCEP Session 4.2.6. Termination of the PCEP Session
When one of the PCEP peers desires to terminate a PCEP session it When one of the PCEP peers desires to terminate a PCEP session it
first sends a PCEP Close message and then closes the TCP connection. first sends a PCEP Close message and then closes the TCP connection.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
object in a PCReq, the PCE MUST take the information carried in the object in a PCReq, the PCE MUST take the information carried in the
object into account during the path computation. For example, the object into account during the path computation. For example, the
METRIC object defined in Section 7.8 allows a PCC to specify a METRIC object defined in Section 7.8 allows a PCC to specify a
bounded acceptable path cost. The METRIC object is optional, but a bounded acceptable path cost. The METRIC object is optional, but a
PCC may set a flag to ensure that the constraint is taken into PCC may set a flag to ensure that the constraint is taken into
account. In this case, if the constraint cannot be taken into account. In this case, if the constraint cannot be taken into
account by the PCE, the PCE MUST trigger an Error message. account by the PCE, the 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 (BNF) (see [RFC4234]) to specify such rules. Square brackets refer
sub-sequences. An implementation MUST form the PCEP messages using to optional sub-sequences. An implementation MUST form the PCEP
the object ordering specified in this document. messages using the object ordering specified in this document.
6.1. Common header 6.1. Common header
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 | Message-Type | Message-Length | | Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common Header Figure 7: PCEP Message Common Header
Ver (Version - 3 bits): PCEP version number. Current version is Ver (Version - 3 bits): PCEP version number. Current version is
version 1. version 1.
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. They MUST be set to zero on transmission and
MUST be ignored on receipt.
Message-Type (8 bits): Message-Type (8 bits):
The following message types are currently defined (to be confirmed by The following message types are currently defined (to be confirmed by
IANA). IANA).
Value Meaning Value Meaning
1 Open 1 Open
2 Keepalive 2 Keepalive
3 Path Computation Request 3 Path Computation Request
4 Path Computation Reply 4 Path Computation Reply
skipping to change at page 15, line 46 skipping to change at page 15, line 47
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 as specified in Appendix A. Any message received an Open message as specified in Appendix A.
prior to an Open message MUST trigger a protocol error condition and
the PCEP session MUST be terminated. The Open message is used to Any message received prior to an Open message MUST trigger a protocol
establish a PCEP session between the PCEP peers. During the error condition causing a PCErr message to be sent with Error-Type
establishment phase the PCEP peers exchange several session 'PCEP session establishment failure' and Error-Value 'reception of an
characteristics. If both parties agree on such characteristics the invalid Open message or a non Open message' and the PCEP session
PCEP session is successfully established. TOTO establishment attempt MUST be terminated by closing the TCP
connection.
The Open message is used to establish a PCEP session between the PCEP
peers. During the establishment phase the PCEP peers exchange
several session characteristics. If both parties agree on such
characteristics the PCEP session is successfully established.
Open message Open message
<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.3). Section 7.3).
Various session characteristics are specified within the OPEN object. Various session characteristics are specified within the OPEN object.
Once the TCP connection has been successfully established the sender Once the TCP connection has been successfully established the sender
MUST start an initialization timer called OpenWait after the MUST start an initialization timer called OpenWait after the
expiration of which if no Open message has been received it sends a expiration of which if no Open message has been received it sends a
PCErr message and releases the TCP connection (see Appendix A for PCErr message and releases the TCP connection (see Appendix A for
details). details).
skipping to change at page 16, line 29 skipping to change at page 16, line 36
start an initialization timer called KeepWait after the expiration of start an initialization timer called KeepWait after the expiration of
which if neither a KeepAlive message has been received nor a PCErr which if neither a KeepAlive message has been received nor a PCErr
message in case of disagreement of the session characteristics, a message in case of disagreement of the session characteristics, a
PCErr message MUST be sent and the TCP connection MUST be released PCErr message MUST be sent and the TCP connection MUST be released
(see Appendix A for details). (see Appendix A for details).
The KeepWait timer has a fixed value of 1 minute. The KeepWait timer has a fixed value of 1 minute.
Upon the receipt of an Open message, the receiving PCEP peer MUST Upon the receipt of an Open message, the receiving PCEP peer MUST
determine whether the suggested PCEP session characteristics are determine whether the suggested PCEP session characteristics are
acceptable. If at least one of the characteristics is not acceptable. If at least one of the characteristic(s) is not
acceptable by the receiving peer, it MUST send an Error message. The acceptable by the receiving peer, it MUST send an Error message. The
Error message SHOULD also contain the related Open object: for each Error message SHOULD also contain the related Open object: for each
unacceptable session parameter, an acceptable parameter value SHOULD unacceptable session parameter, an acceptable parameter value SHOULD
be proposed in the appropriate field of the Open object in place of be proposed in the appropriate field of the Open object in place of
the originally proposed value. The PCEP peer MAY decide to resend an the originally proposed value. The PCEP peer MAY decide to resend an
Open message with different session characteristics. If a second Open message with different session characteristics. If a second
Open message is received with the same set of parameters or with Open message is received with the same set of parameters or with
parameters that are still unacceptable, the receiving peer MUST send parameters that are still unacceptable, the receiving peer MUST send
an Error message and it MUST immediately close the TCP connection. an Error message and it MUST immediately close the TCP connection.
Details about error message can be found in Section 7.15. Details about error message can be found in Section 7.15.
If the PCEP session characteristics are acceptable, the receiving If the PCEP session characteristics are acceptable, the receiving
PCEP peer MUST send a Keepalive message (defined in Section 6.3) that PCEP peer MUST send a Keepalive message (defined in Section 6.3) that
serves as an acknowledgment. serves as an acknowledgment.
The PCEP session is considered as established once both PCEP peers The PCEP session is considered as established once both PCEP peers
have received a Keepalive message from their peer. have received a Keepalive message from their peer.
A PCEP implementation is free to process received requests in any
order. For example, the requests may be processed in the order they
are received, re-ordered and assigned priority according to local
policy, re-ordered according to the priority encoded in the RP Object
(Section 7.4.1), or processed in parallel.
6.3. Keepalive Message 6.3. Keepalive Message
A Keepalive message is a PCEP message sent by a PCC or a PCE in order A Keepalive message is a PCEP message sent by a PCC or a PCE in order
to keep the session in active state. The Keepalive message is also to keep the session in active state. The Keepalive message is also
used in response to an Open message to acknowledge that an Open used in response to an Open message to acknowledge that an Open
message has been received and that the PCEP session characteristics message has been received and that the PCEP session characteristics
are acceptable. The Message-Type field of the PCEP common header for are acceptable. The Message-Type field of the PCEP common header for
the Keepalive message is set to 2 (To be confirmed by IANA). The the Keepalive message is set to 2 (To be confirmed by IANA). The
Keepalive message does not contain any object. Keepalive message does not contain any object.
skipping to change at page 19, line 5 skipping to change at page 19, line 20
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 MAY decide to provide multiple requests within the same PCReq message MAY decide to provide
each computed path in separate PCRep messages or within the same each computed path in separate PCRep messages or within the same
PCRep message. A PCRep message may contain positive and negative PCRep message. A PCRep message may contain positive and negative
replies. replies.
A PCRep message may contain a set of computed paths corresponding to A PCRep message may contain a set of computed path(s) corresponding
either a single path computation request with load-balancing (see to either a single path computation request with load-balancing (see
Section 7.16) or multiple path computation requests originated by a Section 7.16) or multiple path computation requests originated by a
requesting PCC. The PCRep message may also contain multiple requesting PCC. The PCRep message may also contain multiple
acceptable paths corresponding to the same request. acceptable paths corresponding to the same request.
The PCRep message MUST contain at least one RP object. For each The PCRep message MUST contain at least one RP object. For each
reply that is bundled into a single PCReq message, an RP object MUST reply that is bundled into a single PCReq message, an RP object MUST
be included that contains a Request-ID-number identical to the one be included that contains a Request-ID-number identical to the one
specified in the RP object carried in the corresponding PCReq message specified in the RP object carried in the corresponding PCReq message
(see Section 7.4 for the definition of the RP object). (see Section 7.4 for the definition of the RP object).
skipping to change at page 20, line 39 skipping to change at page 21, line 14
The format of a PCNtf message is as follows: The format of a PCNtf message is as follows:
<PCNtf Message>::=<Common Header> <PCNtf Message>::=<Common Header>
<notify-list> <notify-list>
<notify-list>::=<notify> [<notify-list>] <notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>] <notify>::= [<request-id-list>]
<notification-list> <notification-list>
<request-id-list>::=<RP><request-id-list> <request-id-list>::=<RP>[<request-id-list>]
<notification-list>::=<NOTIFICATION><notification-list> <notification-list>::=<NOTIFICATION>[<notification-list>]
6.7. Error (PCErr) Message 6.7. Error (PCErr) Message
The PCEP Error message (also referred to as a PCErr message) is sent The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g., the request is not compliant with the PCEP specification (e.g.,
reception of a malformed message, reception of a message with a reception of a malformed message, reception of a message with a
mandatory missing object, policy violation, unexpected message, mandatory missing object, policy violation, unexpected message,
unknown request reference, ...). The Message-Type field of the PCEP unknown request reference, ...). The Message-Type field of the PCEP
common header is set to 6 (To be confirmed by IANA). common header is set to 6 (To be confirmed by IANA).
skipping to change at page 21, line 46 skipping to change at page 22, line 20
Close 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). If more than one CLOSE object is present, the first Section 6.8). If more than one CLOSE object is present, the first
MUST be processed and subsequent objects ignored. MUST be processed and subsequent objects ignored.
Upon the receipt of a vlaid Close message, the receiving PCEP peer Upon the receipt of a valid Close message, the receiving PCEP peer
MUST cancel all pending requests, it MUST close the TCP connection MUST cancel all pending requests, it MUST close the TCP connection
and MUST NOT send any further PCEP messages on the PCEP session. and MUST NOT send any further PCEP messages on the PCEP session.
7. Object Formats 7. Object Formats
PCEP objects have a common format. They begin with a common object PCEP objects have a common format. They begin with a common object
header (see Section 7.2). This is followed by object-specific fields header (see Section 7.2). This is followed by object-specific fields
defined for each different object. The object may also include one defined for each different object. The object may also include one
or more type-length-value (TLV) encoded data sets. Each TLV has the or more type-length-value (TLV) encoded data sets. Each TLV has the
same structure as described in Section 7.1. same structure as described in Section 7.1.
skipping to change at page 23, line 14 skipping to change at page 23, line 32
Object-Class (8 bits): identifies the PCEP object class. Object-Class (8 bits): identifies the PCEP object class.
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. Unassigned bits are on transmission and MUST be ignored on receipt.
considered as reserved. They MUST be set to zero on transmission and
MUST be ignored on receipt.
o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
specify in a PCReq message sent to a PCE whether the object must specify in a PCReq message sent to a PCE whether the object must
be taken into account by the PCE during path computation or is be taken into account by the PCE during path computation or is
just optional. When the P flag is set, the object MUST be taken just optional. When the P flag is set, the object MUST be taken
into account by the PCE. Conversely, when the P flag is cleared, into account by the PCE. Conversely, when the P flag is cleared,
the object is optional and the PCE is free to ignore it. the object is optional and the PCE is free to ignore it.
o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 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
skipping to change at page 24, line 29 skipping to change at page 24, line 42
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object format Figure 9: OPEN Object format
Ver (3 bits): PCEP version. Current version is 1. Ver (3 bits): PCEP version. Current version is 1.
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. They MUST be set to zero on transmission and
MUST be ignored on receipt.
Keepalive (8 bits): maximum period of time (in seconds) between two Keepalive (8 bits): maximum period of time (in seconds) between two
consecutive PCEP messages sent by the sender of this message. The consecutive PCEP messages sent by the sender of this message. The
minimum value for the Keepalive is 1 second. When set to 0, once the minimum value for the Keepalive is 1 second. When set to 0, once the
session is established, no further Keepalive messages are sent to the session is established, no further Keepalive messages are sent to the
remote peer. A RECOMMENDED value for the keepalive frequency is 30 remote peer. A RECOMMENDED value for the keepalive frequency is 30
seconds. 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 the PCEP peer can declare the session with the sender of the of which the PCEP peer can declare the session with the sender of the
skipping to change at page 25, line 16 skipping to change at page 25, line 30
A sends an Open message to B with Keepalive=10 seconds and A sends an Open message to B with Keepalive=10 seconds and
Deadtimer=30 seconds. This means that A sends Keepalive messages (or Deadtimer=30 seconds. This means that A sends Keepalive messages (or
ay other PCEP message) to B every 10 seconds and B can declare the ay other PCEP message) to B every 10 seconds and B can declare the
PCEP session with A down if no PCEP message has been received from A PCEP session with A down if no PCEP message has been received from A
within any 30 second period. within any 30 second period.
SID (PCEP session-ID - 8 bits): unsigned PCEP session number that SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
identifies the current session. The SID MUST be incremented each identifies the current session. The SID MUST be incremented each
time a new PCEP session is established and is used for logging and time a new PCEP session is established and is used for logging and
troubleshooting purposes. There is one SID number in each direction. troubleshooting purposes. Each increment SHOULD have a value of 1.
The SID is used to disambiguate instances of sessions to the same
peer. A PCEP implementation could use a single source of SIDs across
all peers, or one source for each peer. The former might constrain
the implementation to only 255 concurrent sessions. The latter
potentially requires more states. There is one SID number in each
direction.
Optional TLVs may be included within the OPEN object body to specify 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 acceptable within the PCErr message so as to propose alternative acceptable
skipping to change at page 26, line 21 skipping to change at page 26, line 30
The format of the RP object body is as follows: The format of the RP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri | | Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Flags (32 bits) Flags (24 bits)
The following flags are currently defined: The following flags are currently defined:
o Pri (Priority - 3 bits): the Priority field may be used by the o Pri (Priority - 3 bits): the Priority field may be used by the
requesting PCC to specify to the PCE the request's priority from 1 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 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 specific request is of a local matter and MUST be set to 0 when
unused. Furthermore, the use of the path computation request unused. Furthermore, the use of the path computation request
priority by the PCE's scheduler is implementation specific and out 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 of the scope of this document. Note that it is not required for a
skipping to change at page 27, line 15 skipping to change at page 27, line 25
the request priority and will learn the ability of the PCE to the request priority and will learn the ability of the PCE to
support request prioritization by observing the Priority field of support request prioritization by observing the Priority field of
the RP object received in the PCRep message. If the value of the 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 Pri field is set to 0, this means that the PCE does not support
the handling of request priorities: in other words, the path the handling of request priorities: in other words, the path
computation request has been honoured but without taking the computation request has been honoured but without taking the
request priority into account. request priority into account.
o R (Reoptimization - 1 bit): when set, the requesting PCC specifies o R (Reoptimization - 1 bit): when set, the requesting PCC specifies
that the PCReq message relates to the reoptimization of an that the PCReq message relates to the reoptimization of an
existing TE LSP in which case, in addition to the TE LSP existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when
attributes, the current path of the existing TE LSP to be the R bit is set, an RRO (see Section 7.10) MUST be included in
reoptimized MUST be provided in the PCReq (except for 0-bandwidth the PCReq message to show the path of the existing TE LSP. Also,
TE LSPs) message by means of an RRO object defined in Section 7.10 for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,
and (again except in the case of 0-bandwidth TE LSPs) the existing the existing bandwidth of the TE LSP to be reoptimized MUST be
bandwidth of the LSP to be reoptimized MUST be supplied in an supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH
additional BANDWIDTH object as described in Section 7.7. object is in addition to the instance of that object used to
describe the desired bandwidth of the reoptimized LSP. For
0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the
characteristics of the existing TE LSP are optional.
o B (Bi-directional - 1 bit): when set, the PCC specifies that the o B (Bi-directional - 1 bit): when set, the PCC specifies that the
path computation request relates to a bidirectional TE LSP that path computation request relates to a bidirectional TE LSP that
has the same traffic engineering requirements including fate has the same traffic engineering requirements including fate
sharing, protection and restoration, LSRs, TE Links, and resource sharing, protection and restoration, LSRs, TE Links, and resource
requirements (e.g., latency and jitter) in each direction. When requirements (e.g., latency and jitter) in each direction. When
cleared, the TE LSP is unidirectional. cleared, the TE LSP is unidirectional.
o O (strict/loose - 1 bit): when set, in a PCReq message, this o O (strict/loose - 1 bit): when set, in a PCReq message, this
indicates that a loose path is acceptable. Otherwise, when indicates that a loose path is acceptable. Otherwise, when
cleared, this indicates to the PCE that a path exclusively made of 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 strict hops is required. In a PCRep message, when the O bit is
set this indicates that the returned path is a loose path, set this indicates that the returned path is a loose path,
otherwise (the O bit is cleared), the returned path is made of otherwise (the O bit is cleared), the returned path is made of
strict hops. strict hops.
Unassigned bits are considered as reserved and MUST be set to zero on Unassigned bits are considered as reserved. They MUST be set to zero
transmission. on transmission and MUST be ignored on receipt.
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 is used for disambiguation between pending requests and thus it MUST
value 0x0000000 is considered as invalid. If no path computation be incremented each time a new request is sent to the PCE.
reply is received from the PCE, and the PCC wishes to resend its
request, the same Request-ID-number MUST be used. Conversely, The value 0x00000000 is considered as invalid.
different Request-ID-number MUST be used for different requests sent
to a PCE. The same Request-ID-number MAY be used for path If no path computation reply is received from the PCE (e.g. request
computation requests sent to different PCEs. The path computation dropped by the PCE because of memory overflow), and the PCC wishes to
reply is unambiguously identified by the IP source address of the resend its request, the same Request-ID-number MUST be used. Upon
replying PCE. receiving a path computation request from a PCC with the same
Request-ID-number the PCE SHOULD treat the request as a new request
but an implementation MAY choose to cach path computation replies in
order to quickly handle restranmission without having to handle twice
a path computation request should have the first request been dropped
or lost. Upon receiving a path computation reply from a PCE with the
same Request-ID-number the PCC SHOULD silently discard the path
computation reply.
Conversely, different Request-ID-number MUST be used for different
requests sent to a PCE.
The same Request-ID-number MAY be used for path computation requests
sent to different PCEs. The path computation reply is unambiguously
identified by the IP source address of the replying PCE.
7.4.2. Handling of the RP Object 7.4.2. Handling of the RP Object
If a PCReq message is received that does not contain an RP object, If a PCReq message is received that does not contain an RP object,
the PCE MUST send a PCErr message to the requesting PCC with Error- the 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 paths (for instance, for confidentiality reasons), a provide explicit paths (for instance, for confidentiality reasons), a
skipping to change at page 28, line 35 skipping to change at page 29, line 15
requested by the PCC but this requires that the PCE either be requested by the PCC but this requires that the PCE either be
stateful (keep track of the previously computed path with the stateful (keep track of the previously computed path with the
associated list of strict hops), or have the ability to retrieve the associated list of strict hops), or have the ability to retrieve the
complete required path segment. Alternatively the PCC MUST inform complete required path segment. Alternatively the PCC MUST inform
the PCE of the working path with the associated list of strict hops the PCE of the working path with the associated list of strict hops
in PCReq. The absence of an RRO in the PCReq message for a non-0- in PCReq. The absence of an RRO in the PCReq message for a non-0-
bandwidth TE LSP when the R bit of the RP object is set MUST trigger bandwidth TE LSP when the R bit of the RP object is set MUST trigger
the sending of a PCErr message with Error-type="Required Object the sending of a PCErr message with Error-type="Required Object
Missing" and Error-value="RRO Object missing for reoptimization". Missing" and Error-value="RRO Object missing for reoptimization".
If the PCC receives a PCRep message that contains a RP object If a PCC/PCE receives a PCRep/PCReq message that contains a RP object
referring to an unknown Request-ID-Number, the PCC MUST send a PCErr referring to an unknown Request-ID-Number, the PCC/PCE MUST send a
message with Error-Type="Unknown request reference". PCErr message with Error-Type="Unknown request reference". This is
used for debugging purposes. If a PCC/PCE receives PCRep/PCReq at a
rate equal of greater than 5 unknown requests per minute, the PCC/PCE
MUST send a PCEP CLOSE message with close value="Reception of an
unacceptable number of unknown requests/replies".
The reception of a PCEP message that contains a RP object referring
to a Request-ID-number=0x00000000 MUST be treated similarly to an
unkown request.
7.5. NO-PATH Object 7.5. 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 PCRep message.
There are several categories of issue that can lead to a negative There are several categories of issue that can lead to a negative
skipping to change at page 29, line 27 skipping to change at page 30, line 17
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature Of Issue|C| Flags | Reserved | |Nature Of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH Object Format Figure 11: NO-PATH Object Format
NI - Nature Of Issue (8 bits): the NI field is used to report the NI - Nature Of Issue (8 bits): the NI field is used to report the
nature of the issue that led to a negative reply. Two values are nature of the issue that led to a negative reply. Two values are
currently defined: currently defined:
0x00: No path satisfying the set of constraints could be found 0x00: No path satisfying the set of constraints could be found
0x01: PCE chain broken 0x01: PCE chain broken
The Nature Of Issue field value can be used by the PCC for various
purposes:
o Constraint adjustement before re-issuing a new path computation
request,
o Explicit selection of a new PCE chain,
o Logging of the error type for futher action by the network
admistrator
IANA management of the NI field codespace is described in Section 9. IANA management of the NI field codespace is described in Section 9.
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
failing constraints are specified. The C flag has no meaning and is failing constraints are specified. The C flag has no meaning and is
ignored unless the NI field is set to 0x00. ignored unless the NI field is set to 0x00.
Unassigned bits are considered as reserved. They MUST be set to zero
on transmission and MUST be ignored on receipt.
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.
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
skipping to change at page 30, line 33 skipping to change at page 31, line 36
could have been computed. 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
paths are provided in the PCRep message. paths are provided in the PCRep message.
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 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 object in order to provide more information on the reasons that led
to a negative reply. to a negative reply.
The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in
in section 7.1 and is comprised of 2 bytes for the type, 2 bytes section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying
specifying the TLV length (length of the value portion in bytes) the TLV length (length of the value portion in bytes) followed by a fixed
followed by a fixed length value field of 32-bit flags field. length value field of 32-bit flags field.
TYPE: To be assigned by IANA (suggested value=1) TYPE: To be assigned by IANA (suggested value=1)
LENGTH: 1 LENGTH: 4
VALUE: 32-bit flags field VALUE: 32-bit flags field
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 (see Section 9). PATH-VECTOR TLV (see Section 9).
The following flags are currently defined: The following flags are currently defined:
o Bit number: 1 - PCE currently unavailable o Bit number: 1 - PCE currently unavailable
o Bit number: 2 - Unknown destination o Bit number: 2 - Unknown destination
o Bit number: 3 - Unknown source o Bit number: 3 - Unknown source
7.6. END-POINT Object 7.6. 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. The P flag of the END-POINT which a path computation is requested. The P flag of the END-POINT
object MUST be set. If the END-POINT objet is received with the P object MUST be set. If the END-POINT objet is received with the P
skipping to change at page 31, line 21 skipping to change at page 32, line 24
flag cleared, the receiving peer MUST send a PCErr message with flag cleared, the receiving peer MUST send a PCErr message with
Error-type=10 and Error-value=1. The corresponding path computation Error-type=10 and Error-value=1. The corresponding path computation
request MUST be cancelled by the PCE without further notification. request MUST be cancelled by the PCE without further notification.
Note that the source and destination addresses specified in the END- Note that the source and destination addresses specified in the END-
POINTS object may or may not correspond to the source and destination POINTS object may or may not correspond to the source and destination
IP address of the TE LSP but rather to a path segment. Two END- IP address of the TE LSP but rather to a path segment. Two END-
POINTS objects (for IPv4 and IPv6) are defined. POINTS objects (for IPv4 and IPv6) are defined.
END-POINTS Object-Class is to be assigned by IANA (recommended END-POINTS Object-Class is to be assigned by IANA (recommended
value=4). value=4)
END-POINTS Object-Type is to be assigned by IANA (recommended value=1 END-POINTS Object-Type is to be assigned by IANA (recommended value=1
for IPv4 and 2 for IPv6). for IPv4 and 2 for IPv6)
The format of the END-POINTS object body for IPv4 (Object-Type=1) is The format of the END-POINTS object body for IPv4 (Object-Type=1) is
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address | | Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: END-POINTS Object Body Format for IPv4 Figure 12: END-POINTS Object Body Format for IPv4
The format of the END-POINTS object for IPv6 (Object-Type=2) is as
follows: The format of the END-POINTS object for IPv6 (Object-Type=2) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Source IPv6 address (16 bytes) | | Source IPv6 address (16 bytes) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 32, line 32 skipping to change at page 33, line 44
The END-POINTS object body has a fixed length of 8 bytes for IPv4 and The END-POINTS object body has a fixed length of 8 bytes for IPv4 and
32 bytes for IPv6. 32 bytes for IPv6.
If more than one END-POINTS object is present, the first MUST be If more than one END-POINTS object is present, the first MUST be
processed and subsequent objects ignored. processed and subsequent objects ignored.
7.7. BANDWIDTH Object 7.7. 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. The notion of bandwidth is similar to the one used for RSVP
signaling in [RFC2205], [RFC3209] and [RFC3473].
If the requested bandwidth is equal to 0, the BANDWIDTH object is 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.
In the case of the reoptimization of a TE LSP, the bandwidth of the In the case of the reoptimization of a TE LSP, the bandwidth of the
existing TE LSP MUST also be included in addition to the requested existing TE LSP MUST also be included in addition to the requested
bandwidth if and only if the two values differ. Consequently, two bandwidth if and only if the two values differ. Consequently, two
Object-Type values are defined that refer to the requested bandwidth Object-Type values are defined that refer to the requested bandwidth
and the bandwidth of the TE LSP for which a reoptimization is being and the bandwidth of the TE LSP for which a reoptimization is being
skipping to change at page 33, line 24 skipping to change at page 34, line 35
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. Refer to IEEE floating point format (see XXX), expressed in bytes per second.
Section 3.1.2 of [RFC3471] for a table of commonly used values. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used
values.
The BANDWIDTH object body has a fixed length of 4 bytes. The BANDWIDTH object body has a fixed length of 4 bytes.
7.8. METRIC Object 7.8. 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 one of more METRIC objects: In a PCReq message, a PCC MAY insert one of more METRIC objects:
o To indicate the metric that MUST be optimized by the path o To indicate the metric that MUST be optimized by the path
skipping to change at page 35, line 26 skipping to change at page 36, line 41
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 with the same B flag value. If two or more each metric type with the same B flag value. If two or more
instances of a METRIC object with the same B flag value are present instances of a METRIC object with the same B flag value are present
for a metric type, only the first instance MUST be considered and for a metric type, only the first instance MUST be considered and
other instances MUST be ignored. other instances MUST be ignored.
The presence of two METRIC objects of the same type with a different The presence of two METRIC objects of the same type with a different
value of the B-Flag in a PCEReq message is allowed. Furthermore, it value of the B-Flag in a PCEReq message is allowed. Furthermore, it
is also allowed to insert in a PCReq message two METRIC objects with is also allowed to insert in a PCReq message two METRIC objects with
the same type that have both their B-Flag cleared: in this case, an different types that have both their B-Flag cleared: in this case, an
objective function must be used by the PCE to solve a multi-parameter objective function must be used by the PCE to solve a multi-parameter
constraint problem. constraint problem.
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 C-Flag set to path computation MUST have the B-Flag cleared and the C-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 computed value of the metric of the TE LSP to be field to the computed value of the metric of the TE LSP to be
reoptimized with regards to a specific metric type. reoptimized with regards to a specific metric type.
skipping to change at page 37, line 29 skipping to change at page 38, line 44
The LSPA object is optional and specifies various TE LSP attributes The LSPA object is optional and specifies various TE LSP attributes
to be taken into account by the PCE during path computation. The to be taken into account by the PCE during path computation. The
LSPA (LSP Attributes) object can be carried within a PCReq message, LSPA (LSP Attributes) object can be carried within a PCReq message,
or a PCRep message in case of unsuccessful path computation (in this or a PCRep message in case of unsuccessful path computation (in this
case, the PCRep message also contains a NO-PATH object and the LSPA case, the PCRep message also contains a NO-PATH object and the LSPA
object is used to indicate the set of constraints that could not be object is used to indicate the set of constraints that could not be
satisfied). Most of the fields of the LSPA object are identical to satisfied). Most of the fields of the LSPA object are identical to
the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in
[RFC3209] and [RFC4090]. When absent from the PCReq message, this [RFC3209] and [RFC4090]. When absent from the PCReq message, this
means that the Setup and Holding priorities are equal to 0, and there means that the Setup and Holding priorities are equal to 0, and there
are no affinity constraints. are no affinity constraints. See section 4.7.4 of [RFC3209] for a
detailed description of the use of resource affinities.
LSPA Object-Class is to be assigned by IANA (recommended value=9) LSPA Object-Class is to be assigned by IANA (recommended value=9)
LSPA Object-Types is to be assigned by IANA (recommended value=1) LSPA Object-Types is to be assigned by IANA (recommended value=1)
The format of the LSPA object body is: The format of the LSPA object body is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all | | Include-all |
skipping to change at page 37, line 49 skipping to change at page 39, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all | | Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved | | Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LSPA Object Body Format Figure 16: LSPA Object Body Format
Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP
with respect to taking resources, in the range of 0 to 7. The value 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 TE LSP Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP
skipping to change at page 41, line 25 skipping to change at page 43, line 4
request the synchronization of M path computation requests. The SVEC request the synchronization of M path computation requests. The SVEC
object is a variable length object that lists the set of M path object is a variable length object that lists the set of M path
computation requests that must be synchronized. Each path computation requests that must be synchronized. Each path
computation request is uniquely identified by the Request-ID-number computation request is uniquely identified by the Request-ID-number
carried within the respective RP object. The SVEC object also carried within the respective RP object. The SVEC object also
contains a set of flags that specify the synchronization type. contains a set of flags that specify the synchronization type.
SVEC Object-Class is to be assigned by IANA (recommended value=11) SVEC Object-Class is to be assigned by IANA (recommended value=11)
SVEC Object-Type is to be assigned by IANA (recommended value=1) SVEC Object-Type is to be assigned by IANA (recommended value=1)
The format of the SVEC object body is as follows: The format of the SVEC 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 |S|N|L| | Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (24 bits): Defines the potential dependency between the set of Flags (24 bits): Defines the potential dependency between the set of
path computation requests. path computation requests.
skipping to change at page 43, line 4 skipping to change at page 44, line 31
The NOTIFICATION object is exclusively carried within a PCNtf message The NOTIFICATION object is exclusively carried within a PCNtf message
and can either be used in a message sent by a PCC to a PCE or by a and can either be used in a message sent by a PCC to a PCE or by a
PCE to a PCC so as to notify of an event. PCE to a PCC so as to notify of an event.
NOTIFICATION Object-Class is to be assigned by IANA (recommended NOTIFICATION Object-Class is to be assigned by IANA (recommended
value=12) value=12)
NOTIFICATION Object-Type is to be assigned by IANA (recommended NOTIFICATION Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the NOTIFICATION body object is as follows: The format of the NOTIFICATION body object 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 | NT | NV | | Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // 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 Flags (8 bits): no flags are currently defined. Unassigned flags
MUST be set to zero on transmission and MUST be ignored on receipt. MUST be set to zero on transmission and MUST be ignored on receipt.
skipping to change at page 44, line 22 skipping to change at page 46, line 4
type=1, Notification-value=2 is carried within a PCNtf message type=1, Notification-value=2 is carried within a PCNtf message
sent by a PCE to a PCC. The RP object corresponding to the sent by a PCE to a PCC. The RP object corresponding to the
cancelled request MUST also be present in the PCNtf message. cancelled request MUST also be present in the PCNtf message.
Multiple RP objects may be carried within the PCNtf message in Multiple RP objects may be carried within the PCNtf message in
which case the notification applies to all of them. If such which case the notification applies to all of them. If such
notification is received by a PCE from a PCC, the PCE MUST notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be silently ignore the notification and no errors should be
generated. generated.
o Notification-type=2: Overloaded PCE 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 PCCs that the PCE is currently in an value=1 indicates to the PCC(s) that the PCE is currently in an
overloaded state. If no RP objects are included in the PCNtf overloaded state. If no RP objects are included 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 overloaded 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 overloaded state, the PCE requests cannot be served due to the overloaded state, the PCE
MUST also include a set of RP objects that identifies the set MUST also include a set of RP objects 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 objects. If specified by including the corresponding set of RP object(s).
such notification is received by a PCE from a PCC, the PCE MUST If such notification is received by a PCE from a PCC, the PCE
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 OVERLOADED-DURATION may be included in * An PCE implementation SHOULD use a dual threshold mechanism
the NOTIFICATION object that specifies the period of time used to determine whether it is in a congestion state with
during whichno further request should be sent to the PCE. Once regards to specific resources monitoring (e.g. CPU, memory,
this period of time has elapsed, the PCE should no longer be ...). The use of such thresholds is to avoid oscillations
considered in congested state. between overloaded/non-overloaded state that may result in
oscillations of request targets by the PCCs."
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV *
format defined in section 7.1 and is comprised of 2 bytes for
the type, 2 bytes specifying the TLV length (length of the Optionally, a TLV named OVERLOADED-DURATION may be included in the
value portion in bytes) followed by a fix length value field of NOTIFICATION object that specifies the period of time during which
32-bits flags field. no further request should be sent to the PCE. Once this period of
time has elapsed, the PCE should no longer be considered in congested
state.
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format
defined in section 7.1 and is comprised of 2 bytes for the type,
2 bytes specifying the TLV length (length of the value portion in bytes)
followed by a fix length value field of 32-bits flags field.
TYPE: To be assigned by IANA (suggested value=2) TYPE: To be assigned by IANA (suggested value=2)
LENGTH: 4 LENGTH: 4
VALUE: 32-bits flags field indicates the estimated PCE VALUE: 32-bits flags field indicates the estimated PCE congestion
congestion duration in seconds. duration in seconds.
* 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 SHOULD make sure that a PCE sends such implementation SHOULD 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
an OVERLOADED-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
skipping to change at page 46, line 4 skipping to change at page 47, line 30
7.15. PCEP-ERROR Object 7.15. 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)
The format of the PCEP-ERROR object body is as follows: The format of the PCEP-ERROR 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 | Error-Type | Error-Value | | Reserved | Flags | Error-Type | Error-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: PCEP-ERROR Object Body Format Figure 20: PCEP-ERROR Object Body Format
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).
skipping to change at page 47, line 6 skipping to change at page 49, line 6
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.
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- Meaning
Type
1 PCEP session establishment failure 1 PCEP session establishment failure
Error-value=1: reception of an invalid Open message or Error-value=1: reception of an invalid Open message or
a non Open message. a non Open message.
Error-value=2: no Open message received before the Error-value=2: no Open message received before the expiration
expiration of the OpenWait timer of the OpenWait timer
Error-value=3: unacceptable and non negotiable session Error-value=3: unacceptable and non negotiable session
characteristics characteristics
Error-value=4: unacceptable but negotiable session Error-value=4: unacceptable but negotiable session
characteristics characteristics
Error-value=5: reception of a second Open message with Error-value=5: reception of a second Open message
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
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
Error-value=3: Unrecognized subobject type
Error-value=4: Unrecognized parameter
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
Error-value=3: Unsupported subobject type
Error-value=4: Unsupported parameter
5 Policy violation 5 Policy violation
Error-value=1: C bit of the METRIC object set (request Error-value=1: C bit of the METRIC object set (request rejected)
rejected) Error-value=2: O bit of the RP object set (request rejected)
Error-value=2: O bit of the RP object set (request
rejected)
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=1: RP object missing Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set) when request (R bit of the RP object set) when
bandwidth is not equal to 0. bandwidth is not equal to 0.
Error-value=3: END-POINTS object missing Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing 7 Synchronized path computation request missing
8 Unknown request reference 8 Unknown request reference
9 Attempt to establish a second PCEP session 9 Attempt to establish a second PCEP session
10 Reception of an invalid object 10 Reception of an invalid object
skipping to change at page 48, line 47 skipping to change at page 50, line 40
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).
If the object type or object class is unknown or unsupported, the PCE In addition, the PCE MAY include in the PCErr message the unknown or
MAY include in the PCErr message the unknown or not supported object. not supported object. The corresponding path computation request
Furthermore, if a subobject or parameter is unknown or unsupported, MUST be cancelled by the PCE without further notification.
the PCE MAY include the parent object up to and including (but no
further than) the unknown or unsupported subobject or parameter. In
the case where the unknown or unsupported parameter is a bit flag,
the included object should contain the whole bit flag field with all
bits after the parameter at issue set to zero. The corresponding path
computation request MUST be cancelled by the PCE without further
notification.
Error-Type=5: if a path computation request is received that is not Error-Type=5: if a path computation request is received that is not
compliant with an agreed policy between the PCC and the PCE, the PCE compliant with an agreed policy between the PCC and the PCE, the PCE
MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5). MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5).
The corresponding path computation MUST be cancelled. Policy- The corresponding path computation MUST be cancelled. Policy-
specific TLVs carried within the PCEP-ERROR object may be defined in specific TLVs carried within the PCEP-ERROR object may be defined in
other documents to specify the nature of the policy violation. 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 49, line 31 skipping to change at page 51, line 18
cancelled. cancelled.
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.13.3, the PCE MUST send a PCErr message with a PCEP-ERROR Section 7.13.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 TLVs (defined below) that identifies the include the REQ-MISSING TLVs (defined below) that identifies the
missing requests. missing request(s).
The REQ-MISSING TLV is compliant with the PCEP TLV format defined The REQ-MISSING TLV is compliant with the PCEP TLV format defined
in section 7.1 and is comprised of 2 bytes for the type, 2 bytes in section 7.1 and is comprised of 2 bytes for the type, 2 bytes
specifying the TLV length (length of the value portion in bytes) specifying the TLV length (length of the value portion in bytes)
followed by a fix length value field of 4 bytes. followed by a fix length value field of 4 bytes.
TYPE: To be assigned by IANA (suggested value=3) TYPE: To be assigned by IANA (suggested value=3)
LENGTH: 4 LENGTH: 4
VALUE: 4 bytes that indicates the request-id-number that corresponds VALUE: 4 bytes that indicates the request-id-number that corresponds
to the missing request. to the missing request.
skipping to change at page 51, line 12 skipping to change at page 52, line 51
TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH
object specifying X as the required bandwidth and a LOAD-BALANCING object specifying X as the required bandwidth and a LOAD-BALANCING
object with the Max-LSP and Min-Bandwidth fields set to N and B object with the Max-LSP and Min-Bandwidth fields set to N and B
respectively. respectively.
7.17. CLOSE Object 7.17. CLOSE Object
The CLOSE object MUST be present in each Close message. There MUST The CLOSE object MUST be present in each Close message. There MUST
be only one CLOSE object per Close message. If a Close message is be only one CLOSE object per Close message. If a Close message is
received that contains more than one CLOSE object, the first CLOSE received that contains more than one CLOSE object, the first CLOSE
object is the one that must be processed. Other CLOSE objects MUST object is the one that must be processed. Other CLOSE object(s) MUST
be silently ignored. be silently ignored.
CLOSE Object-Class is to be assigned by IANA (recommended value=15) CLOSE Object-Class is to be assigned by IANA (recommended value=15)
CLOSE Object-Type is to be assigned by IANA (recommended value=1) CLOSE Object-Type is to be assigned by IANA (recommended value=1)
The format of the CLOSE object body is as follows: The format of the CLOSE 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 | Reason | | Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: CLOSE Object Format Figure 22: CLOSE Object Format
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.
Flags (8 bits): No Flags are currently defined. The Flag field MUST Flags (8 bits): No Flags are currently defined. The Flag field MUST
be set to zero on transmission and MUST be ignored on receipt. be set to zero on transmission and MUST be ignored on receipt.
skipping to change at page 51, line 49 skipping to change at page 53, line 39
Reason (8 bits): specifies the reason for closing the PCEP session. Reason (8 bits): specifies the reason for closing the PCEP session.
The setting of this field is optional. IANA is requested to manage The setting of this field is optional. IANA is requested to manage
the codespace of the Reason field. The following values are the codespace of the Reason field. The following values are
currently defined (To be confirmed by IANA). currently defined (To be confirmed by IANA).
Reasons Reasons
Value Meaning Value Meaning
1 No explanation provided 1 No explanation provided
2 DeadTimer expired 2 DeadTimer expired
3 Reception of a malformed PCEP message 3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of
unknown requests/replies
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 follows the guidance of 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
skipping to change at page 54, line 34 skipping to change at page 56, line 31
In order to avoid any unacceptable impact on network operations, an In order to avoid any unacceptable impact on network operations, an
implementation SHOULD allow a limit to be placed on the number of implementation SHOULD allow a limit to be placed on the number of
session that can be set up on a PCEP speaker, and MAY allow a limit session that can be set up on a PCEP speaker, and MAY allow a limit
to be placed on the rate of messages sent by a PCEP speaker and to be placed on the rate of messages sent by a PCEP speaker and
received from a peer. It MAY also allow sending a notification when received from a peer. It MAY also allow sending a notification when
a rate threshold is reached. a rate threshold is reached.
9. IANA Considerations 9. IANA Considerations
9.1. TCP Port IANA assigns values to the PCEP protocol parameters (messages,
objects, TLVs).
PCEP uses a well-known TCP port. IANA is requested to assign a port
number from the "System" sub-registry of the "Port Numbers" registry.
9.2. PCEP Top-Level Registry
IANA is requested to establish a new top-level registry to contain IANA is requested to establish a new top-level registry to contain
all PCEP codepoints and sub-registries. The registry should be called all PCEP codepoints and sub-registries.
"Path Computation Element Protocol (PCEP)".
The allocation policy for each sub-registry defined in this document The allocation policy for each new registry is by IETF Consensus: new
is "IETF Consensus" (see [RFC2434]). Specifically, new assignments values are assigned through the IETF consensus process (see
are made via RFCs approved by the IESG. Typically, the IESG will [RFC2434]). Specifically, new assignments are made via RFCs approved
seek input on prospective assignments from appropriate persons (e.g., by the IESG. Typically, the IESG will seek input on prospective
a relevant Working Group if one exists). assignments from appropriate persons (e.g., a relevant Working Group
if one exists).
9.2.1. PCEP Messages 9.1. TCP Port
IANA is requested to create a sub-registry for PCEP messages type PCEP will use a well-known TCP port to be assigned by IANA.
values. Each PCEP message has a message type value. The sub-registry
should be called "PCEP Message Types".
New PCEP Message Types may be allocated only by an IETF Consensus 9.2. PCEP Messages
action.
Message Message Reference IANA is requested to create a registry for PCEP messages. Each PCEP
Type message has a message type value.
Value Meaning Reference
1 Open This document 1 Open This document
2 Keepalive This document 2 Keepalive This document
3 Path Computation Request This document 3 Path Computation Request This document
4 Path Computation Reply This document 4 Path Computation Reply This document
5 Notification This document 5 Notification This document
6 Error This document 6 Error This document
7 Close This document 7 Close This document
9.2.2. PCEP Object 9.3. PCEP Object
IANA is requested to create a sub-registry for objects carried in IANA is requested to create a registry for PCEP objects. Each PCEP
PCEP messages. Each PCEP object has an Object-Class and an object has an Object-Class and an Object-Type.
Object-Type. The sub-registry should be called "PCEP Objects".
New Object-Classes and new Object-Types of existing Object-Classes Object-Class Value Name Reference
may be allocated only by an IETF Consensus action.
Object Name Reference
Class
1 OPEN This document 1 OPEN This document
Object-Type Object-Type
1: Open This document 1
2 RP This document 2 RP This document
Object-Type Object-Type
1: Request Parameters This document 1
3 NO-PATH This document 3 NO-PATH This document
Object-Type Object-Type
1: No Path This document 1
4 END-POINTS This document 4 END-POINTS This document
Object-Type Object-Type
1: IPv4 addresses This document 1: IPv4 addresses
2: IPv6 addresses This document 2: IPv6 addresses
5 BANDWIDTH This document 5 BANDWIDTH This document
Object-Type Object-Type
1: Requested bandwidth This document 1: Requested bandwidth
2: Bandwidth of an existing TE LSP for This document 2: Bandwidth of an existing TE LSP
which a reoptimization is performed. for which a reoptimization is performed.
6 METRIC This document 6 METRIC This document
Object-Type Object-Type
1: Metric This document 1
7 ERO This document 7 ERO This document
Object-Type Object-Type
1: Explicit Route This document 1
8 RRO This document 8 RRO This document
Object-Type Object-Type
1: Record Route This document 1
9 LSPA This document 9 LSPA This document
Object-Type Object-Type
1: LSP Attributes This document 1
10 IRO This document 10 IRO This document
Object-Type Object-Type
1: Include Route This document 1
11 SVEC This document 11 SVEC This document
Object-Type Object-Type
1: Synchronization Vector This document 1
12 NOTIFICATION This document 12 NOTIFICATION This document
Object-Type Object-Type
1: Notification This document 1
13 PCEP-ERROR This document 13 PCEP-ERROR This document
Object-Type Object-Type
1: Error This document 1
14 LOAD-BALANCING This document 14 LOAD-BALANCING This document
Object-Type Object-Type
1: Load Balancing This document 1
15 CLOSE This document 15 CLOSE This document
Object-Type Object-Type
1: Close This document 1
9.2.3. RP Object
IANA is requested to create a new sub-registry for the bits in the 9.4. RP Object
Flags field of the RP Object. The sub-registry should be called
"Request Parameters Bit Flags".
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: Each bit should be tracked with the following qualities:
- Bit number o Bit number
- Bit name
- Description
- Defining RFC
The field contains 32 bits numbered from 1 as the least significant o Capability Description
bit.
Bit Name Description Reference o Defining RFC
1-3 Pri Priority This document Several bits are defined in this document. The following values have
4 R-bit Reoptimization This document been assigned:
5 B-bit Bi-directional This document
6 O-bit Strict/Loose This document
9.2.4. Notification Object Codespace of the Flag field (Metric Object)
Bit Description Reference
IANA is requested to create a sub-registry for the Notification-type 1-3 Priority This document
and Notification-value of the Notification Object and manage the code 4 Reoptimization This document
space. The sub-registry should be called "Notification Types and 5 Bi-directional This document
Values". 6 Strict/Loose This document
New Notification-Types and new Notification-Values of existing 9.5. Notification Object
Notification-Types may be allocated only by an IETF Consensus action.
Notification IANA is requested to create a registry for the Notification-type and
Type Name Reference Notification-value of the Notification Object and manage the code
space.
Notification-type Name Reference
1 Pending Request cancelled This document 1 Pending Request cancelled This document
Notification-value: Notification-value
1: PCC cancels a set of pending requests This document 1: PCC cancels a set of pending request(s)
2: PCE cancels a set of pending requests This document 2: PCE cancels a set of pending request(s)
2 PCE Congestion This document 2 PCE Congestion This document
Notification-value Notification-value
1: PCE in congested state This document 1: PCE in congested state
2: PCE no longer in congested state This document 2: PCE no longer in congested state
9.2.5. PCEP-ERROR Object
IANA is requested to create a sub-registry for the Error-type and 9.6. PCEP-ERROR Object
Error-value of the PCEP Error Object and manage the code space. The
sub-registry should be called "Error Types and Values".
New Error-Types and new Error-Values of existing Error-Types may be IANA is requested to create a registry for the Error-type and Error-
allocated only by an IETF Consensus action. value of the PCEP Error Object and manage the code space.
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 Reference
Error
Type Meaning Reference
1 PCEP session establishment failure This document 1 PCEP session establishment failure This document
Error-value=1: This document Error-value=1: reception of an invalid Open message or
Reception of an invalid Open message or a a non Open message.
non-Open message. Error-value=2: no Open message received before the expiration
Error-value=2: This document of the OpenWait timer
No Open message received before the expiration Error-value=3: unacceptable and non negotiable session
of the OpenWait timer. characteristics
Error-value=3: Error-value=4: unacceptable but negotiable session
Unacceptable and non negotiable session This document characteristics
characteristics. Error-value=5: reception of a second Open message
Error-value=4: with still unacceptable session characteristics
Unacceptable but negotiable session This document Error-value=6: reception of a PCErr message proposing
characteristics. unacceptable session characteristics
Error-value=5: This document Error-value=7: No Keepalive or PCErr message received
Reception of a second Open message with still before the expiration of the KeepWait timer
unacceptable session characteristics.
Error-value=6: This document
Reception of a PCErr message proposing
unacceptable session characteristics.
Error-value=7: This document
No Keepalive or PCErr message received before
the expiration of the KeepWait timer.
Error-value=8: PCEP version not supported Error-value=8: PCEP version not supported
2 Capability not supported This document 2 Capability not supported This document
3 Unknown Object This document 3 Unknown Object This document
Error-value=1: This document Error-value=1: Unrecognized object class
Unrecognized object class Error-value=2: Unrecognized object Type
Error-value=2: This document
Unrecognized object type
Error-value=3: This document
Unrecognized subobject type
Error-value=4: This document
Unrecognized parameter
4 Not supported object This document 4 Not supported object This document
Error-value=1: This document Error-value=1: Not supported object class
Unsupported object class. Error-value=2: Not supported object Type
Error-value=2: This document
Unsupported object type.
Error-value=3: This document
Unsupported subobject type.
Error-value=4: This document
Unsupported parameter.
5 Policy violation This document 5 Policy violation This document
Error-value=1: This document Error-value=1: C bit of the METRIC object set (request rejected)
C bit of the METRIC object set (request Error-value=2: O bit of the RP object cleared (request rejected)
rejected). 6 Mandatory Object missing This document
Error-value=2: This document Error-value=1: RP object missing
O bit of the RP object cleared (request Error-value=2: RRO missing for a reoptimization
rejected). request (R bit of the RP object set)
Error-value=3: END-POINTS object missing
6 Mandatory Object missing. This document 7 Synchronized path computation request missing This document
Error-value=1: 8 Unknown request reference This document
RP object missing. 9 Attempt to establish a second PCEP session This document
Error-value=2: This document
RRO missing for a reoptimization request
(R bit of the RP object set).
Error-value=3: This document
END-POINTS object missing.
7 Synchronized path computation request missing. This document
8 Unknown request reference. This document
9 Attempt to establish a second PCEP session. This document
10 Reception of an invalid object This document 10 Reception of an invalid object This document
Error-value=1: This document Error-value=1: reception of an object with P flag not set although
Reception of an object with P flag not set the P-flag must be set according to this specification.
although the P-flag must be set according
to this specification.
9.2.6. CLOSE Object
IANA is requested to create a sub-registry for the Reason field of 9.7. CLOSE Object
the PCEP Close Object and manage the code space. The sub-registry
should be called "Close Reasons".
New Close Reasons may be allocated only by an IETF Consensus action. 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 Reasons
Value Meaning Value Meaning
1 No explanation provided 1 No explanation provided
2 DeadTimer expired 2 DeadTimer expired
3 Reception of a malformed PCEP message 3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of
unknown requests/replies
9.2.7. NO-PATH Object 9.8. NO-PATH Object
9.2.7.1. No-Path Nature of Issue
IANA is requested to create a sub-registry to manage the Nature of
Issue (NI) field present in the NO-PATH Object. The sub-registry
should be called "No-Path Nature of Issue".
New Nature of Issue values may be allocated only by an IETF Consensus IANA is requested to create a registry to manage the codespace of NI
action. field present in the NO-PATH Object.
Value Meaning Reference Value Meaning Reference
0 No path satisfying the set of constraints This document 0 No path satisfying the set This document
could be found of constraints could be found
1 PCE chain broken This document 1 PCE chain broken This docuement
9.2.7.2. No-Path Bit Flags
IANA is requested to created a sub-registry of bits carried in the
Flags field of the PCEP NO-PATH object. The sub-registry should be
called "No-Path Flags".
New assignments from this sub-registry are by IETF Consensus action.
The field contains 16 bits numbered from 1 as the least significant
bit.
Bit Name Description Reference
16 C-bit Unsatisfied constraints included This document
9.2.8. METRIC Object
9.2.8.1. Metric Type
IANA is requested to create a sub-registry to manage the Metric Type 9.9. METRIC Object
carried in the T field of the PCEP METRIC object. The sub-registry
should be called "Metric Types".
New assignments from this sub-registry are by IETF Consensus action. IANA is requested to create a registry to manage the codespace of T
field and the Flag field of the METRIC Object.
Codespace of the T field (Metric Object)
Value Meaning Reference Value Meaning Reference
1 IGP metric This document 1 IGP metric This document
2 TE metric This document 2 TE metric This document
3 Hop Counts This document 3 Hop Counts This document
9.2.8.2. Metric Control Flags New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:
IANA is requested to create a sub-registry to manage the Flags field o Bit number
carried in the PCEP METRIC object. The sub-registry should be called
"Metric Control Flags".
New bit numbers may be allocated only by an IETF Consensus action. o Capability Description
Each bit should be tracked with the following qualities: o Defining RFC
- Bit number
- Bit name
- Description
- Defining RFC
The field contains 8 bits numbered from 1 as the least significant Several bits are defined in this document. The following values have
bit. been assigned:
Bit Name Description Reference Codespace of the Flag field (Metric Object)
Bit Description Reference
1 B-bit Bound This document 1 Bound This document
2 C-bit Computed metric This document 2 Computed metric This document
9.2.9. PCEP TLV Type Indicators 9.10. PCEP TLV Type Indicators
PCEP TLV type values are allocated from a common TLV type codepoint IANA is requested to create a registry for the PCEP TLVs.
space. IANA is requested to create a sub-registry for the PCEP TLV
types. The sub-registry should be called "PCEP TLV Types"
New assignments from this sub-registry are by IETF Consensus action. Value Meaning Reference
TLV Type Meaning Reference
1 NO-PATH-VECTOR TLV This document 1 NO-PATH-VECTOR TLV This document
2 OVERLOAD-DURATION TLV This document 2 OVERLOAD-DURATION TLV This document
3 REQ-MISSING TLV This document 3 REQ-MISSING TLV This document
9.2.10. NO-PATH-VECTOR TLV 9.11. 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. The sub-registry should be called "No-Path Reasons". PATH-VECTOR TLV defined in this document, numbering them in the usual
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: Each bit should be tracked with the following qualities: - Bit number
- Bit number - Name flag - Reference
- Name
- Reference
The field carries 32 bits numbered from zer as the most significant
bit to 31 as the least significant bit.
Bit
Number Name Reference
Bit Number Name Reference
1 PCE currently Unavailable This document 1 PCE currently Unavailable This document
2 Unknown Destination This document 2 Unknown Destination This document
3 Unknown Source This document 3 Unknown Source This document
10. Security Considerations 10. 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 64, line 15 skipping to change at page 65, line 10
11. Authors' Addresses 11. Authors' Addresses
The content of this document was contributed by the editors and the The content of this document was contributed by the editors and the
co-authors listed below: co-authors listed below:
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: arthi@juniper.net Email: arthi@juniper.net
Eiji Oki Eiji Oki
NTT NTT
Midori 3-9-12 Midori 3-9-11
Musashino, Tokyo, 180-8585 Musashino, Tokyo, 180-8585
JAPAN JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Alia Atlas Alia Atlas
British Telecom British Telecom
Email: akatlas@alum.mit.edu Email: akatlas@alum.mit.edu
Andrew Dolganow Andrew Dolganow
Alcatel Alcatel
600 March Road 600 March Road
Ottawa, ON K2K 2E6 Ottawa, ON K2K 2E6
skipping to change at page 65, line 21 skipping to change at page 66, line 21
suggestions. The authors would also like to thank Fabien Verhaeghe suggestions. The authors would also like to thank Fabien Verhaeghe
for the very fruitful discussions and useful suggestions. for the very fruitful discussions and useful suggestions.
13. References 13. References
13.1. Normative References 13.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.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
skipping to change at page 65, line 46 skipping to change at page 66, line 50
[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.
13.2. Informative References 13.2. Informative References
[I-D.ietf-pce-inter-layer-req] [I-D.ietf-pce-inter-layer-req]
Oki, E., "PCC-PCE Communication and PCE Discovery Oki, E., "PCC-PCE Communication and PCE Discovery
Requirements for Inter-Layer Traffic Engineering", Requirements for Inter-Layer Traffic Engineering",
draft-ietf-pce-inter-layer-req (work in progress). draft-ietf-pce-inter-layer-req-07 (work in progress),
April 2008.
[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., Kumaki, K., and R. Zhang, "Inter-AS
Element Communication Protocol (PCECP)", Requirements for the Path Computation Element
draft-ietf-pce-interas-pcecp-reqs (work in progress). Communication Protocol (PCEP)",
draft-ietf-pce-interas-pcecp-reqs-06 (work in progress),
May 2008.
[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 (work in draft-ietf-pce-manageability-requirements-04 (work in
progress. progress), June 2008.
[I-D.ietf-pce-monitoring]
Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based
Architecture", draft-ietf-pce-monitoring (work in
progress).
[I-D.ietf-pce-monitoring] [I-D.ietf-pce-monitoring]
Vasseur, J., Roux, J., and Y. Ikejiri, "A set of Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based monitoring tools for Path Computation Element based
Architecture", draft-ietf-pce-monitoring (work in Architecture", draft-ietf-pce-monitoring-01 (work in
progress). progress), February 2008.
[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 (work in progress). draft-ietf-rpsec-bgpsecrec-09 (work in progress),
November 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 (work in progress). draft-kkoushik-pce-pcep-mib-01 (work in progress),
July 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.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
skipping to change at page 67, line 5 skipping to change at page 68, line 8
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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. 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.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
skipping to change at page 71, line 4 skipping to change at page 71, line 48
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 Connect timer during the TCP connection establishment) or the Connect timer
expires: expires:
o If ConnectRetry =ConnectMaxRetry the system moves to the Idle o If ConnectRetry =ConnectMaxRetry the system moves to the Idle
State State
o If ConnectRetry < ConnectMaxRetry the system: o If ConnectRetry < ConnectMaxRetry the system:
1. Initiates of a TCP connection with the PCEP peer, 1. Initiates of a TCP connection with the PCEP peer,
2. Increments the ConnectRetry variable,
2. Increments the ConnectRetry variable,
3. Restarts the Connect timer, 3. Restarts the Connect timer,
4. Stays in the TPCPending state. 4. Stays in the TPCPending state.
In response to any other event the system releases the PCEP resources In response to any other event the system releases the PCEP resources
for that peer and moves back to the Idle state. 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
skipping to change at page 71, line 45 skipping to change at page 72, line 43
o Otherwise, the system checks the PCEP session attributes o Otherwise, the system checks the PCEP session attributes
(Keepalive frequency, DeadTimer, ...). (Keepalive frequency, DeadTimer, ...).
If an error is detected (e.g. malformed Open message, reception of a If an error is detected (e.g. malformed Open message, reception of a
message that is not an Open message, presence of two Open objects, message that is not an Open message, presence of two Open objects,
...), PCEP generates an error notification, the PCEP peer sends a ...), PCEP generates an error notification, the PCEP peer sends a
PCErr message with Error-Type=1 and Error-value=1. The system PCErr message with Error-Type=1 and Error-value=1. The system
releases the PCEP resources for the PCEP peer, closes the TCP 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, OpenRetry=1 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,
skipping to change at page 74, line 40 skipping to change at page 75, line 40
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.
SyncTimer: the SYNC timer is used in the case of synchronized path SyncTimer: the SYNC timer is used in the case of synchronized path
computation request using the SVEC object defined in Section 7.13.3. computation request using the SVEC object defined in Section 7.13.3.
Consider the case where a PCReq message is received by a PCE that Consider the case where a PCReq message is received by a PCE that
contains the SVEC object referring to M synchronized path computation contains the SVEC object referring to M synchronized path computation
requests. If after the expiration of the SYNC timer all the M path requests. If after the expiration of the SYNC timer all the M path
computation requests have not been received, a protocol error is computation requests have not been received, a protocol error is
triggered and the PCE MUST cancel the whole set of path computation triggered and the PCE MUST cancel the whole set of path computation
requests. A RECOMMENDED value for the SYNC timer is 60 seconds. requests. The aim of the SyncTimer is to avoid the storage of unused
synchronized request should one of them get lost for some reasons
(e.g a misbehaving PCC). Thus the value of the Synctimer must be
large enough to avoid the expiration of the timer under normal
circumstances. A RECOMMENDED value for the SYNC timer is 60 seconds.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
skipping to change at page 76, line 44 skipping to change at line 3428
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 196 change blocks. 
483 lines changed or deleted 430 lines changed or added

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