draft-ietf-pce-monitoring-01.txt   draft-ietf-pce-monitoring-02.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track JL. Le Roux Intended status: Standards Track JL. Le Roux
Expires: August 9, 2008 France Telecom Expires: March 6, 2009 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
February 6, 2008 September 2, 2008
A set of monitoring tools for Path Computation Element based A set of monitoring tools for Path Computation Element based
Architecture Architecture
draft-ietf-pce-monitoring-01.txt draft-ietf-pce-monitoring-02.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 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2008. This Internet-Draft will expire on March 6, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
A Path Computation Element (PCE) based architecture has been A Path Computation Element (PCE) based architecture has been
specified for the computation of Traffic Engineering (TE) Label specified for the computation of Traffic Engineering (TE) Label
Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks in the context of single or Generalized MPLS (GMPLS) networks in the context of single or
multiple domains (where a domain is referred to as a collection of multiple domains (where a domain refers to a collection of network
network elements within a common sphere of address management or path elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous computational responsibility such as IGP areas and Autonomous
Systems). In PCE-based environments it is thus critical to monitor Systems). In PCE-based environments, it is thus critical to monitor
the state of the path computation chain for troubleshooting and the state of the path computation chain for troubleshooting and
performance monitoring purposes: liveness of each element (PCE) performance monitoring purposes: liveness of each element (PCE)
involved in the PCE chain, detection of potential resource contention involved in the PCE chain, detection of potential resource contention
states, statistics in term of path computation times are examples of states and statistics in term of path computation times are examples
such metrics of interest. This document specifies procedures and of such metrics of interest. This document specifies procedures and
extensions to the Path Computation Element Protocol (PCEP) in order extensions to the Path Computation Element Protocol (PCEP) in order
to gather such information. to gather such information.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Computation Monitoring messages . . . . . . . . . . . . . 5 3. Path Computation Monitoring messages . . . . . . . . . . . . . 4
3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 3.1. Path Computation Monitoring Request message (PCMonReq) . . 5
3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 8 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 7
4. Path Computation Monitoring Objects . . . . . . . . . . . . . 9 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 8
4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 9 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 8
4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 11 4.2. PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10
4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 12 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11
4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 14 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 13
4.5. TIMESTAMP Object . . . . . . . . . . . . . . . . . . . . . 15 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Multi-destination monitoring . . . . . . . . . . . . . . . . . 15 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14
6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Manageability Considerations . . . . . . . . . . . . . . . . . 15
7. Elements of procedure . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Manageability Considerations . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. To be considered in a further revision of this document . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Terminology
AS: Autonomous System.
LSR: Label Switching Router.
PCC (Path Computation Client): any client application requesting a
path computation to be performed by a Path Computation Element.
PCE (Path Computation Element): an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TE LSP: Traffic Engineering Label Switched Path.
TED: Traffic Engineering Database.
2. Introduction 1. Introduction
The Path Computation Element (PCE) based architecture has been The Path Computation Element (PCE) based architecture has been
specified in [RFC4655] for the computation of Traffic Engineering specified in [RFC4655] for the computation of Traffic Engineering
(TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks in the context of single (MPLS) and Generalized MPLS (GMPLS) networks in the context of single
or multiple domains where a domain is referred to as a collection of or multiple domains where a domain refers to a collection of network
network elements within a common sphere of address management or path elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous computational responsibility such as IGP areas and Autonomous
Systems. Systems.
As defined in [RFC4655], there are circumstances where more than one
PCE is involved in the computation of a TE LSP. A typical example is
when the PCC requires the computation of a TE LSP where the head-end
and the tail-end of the TE LSP do not reside in adjacent domains and
there is no single PCE with the visibility of both the head-end and
tail-end domain. We call the set of PCEs involved in the computation
of a TE LSP a "path computation chain". As further discussed in
Section 3.1, the PCE chain may either be static (pre-configured) or
dynamically determined during the path computation process.
In PCE-based environments, it is critical to monitor the state of the In PCE-based environments, it is critical to monitor the state of the
path computation chain for troubeshooting and performance monitoring path computation chain for troubeshooting and performance monitoring
purposes: liveness of each element (PCE) involved in the PCE chain, purposes: liveness of each element (PCE) involved in the PCE chain,
detection of potential resource contention states, statistics in term detection of potential resource contention states and statistics in
of path computation times are examples of such metrics of interest. term of path computation times are examples of such metrics of
This document specifies procedures and extensions to the Path interest. This document specifies procedures and extensions to the
Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in
monitor the path computation chain and gather various performance order to monitor the path computation chain and gather various
metrics. performance metrics.
As discussed in [RFC4655], a TE LSP may be computed by one PCE As discussed in [RFC4655], a TE LSP may be computed by one PCE
(referred to as single PCE path computation) or several PCEs (referred to as single PCE path computation) or several PCEs
(referred to as multiple PCE path computation). In the former case, (referred to as multiple PCE path computation). In the former case,
the PCC may be able to use IGP extensions to check the liveness of the PCC may be able to use IGP extensions to check the liveness of
the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive
messages. In contrast, when multiple PCEs are involved in the path messages. In contrast, when multiple PCEs are involved in the path
computation chain an example of which is the BRPC procedure defined computation chain an example of which is the BRPC procedure defined
in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the
first PCE involved in the path computation chain. Thus, it is first PCE involved in the path computation chain. Thus, it is
critical to define mechanisms in order to monitor the state of the critical to define mechanisms in order to monitor the state of the
path computation chain. path computation chain.
The aim of this document is to specify PCEP extensions in order to This document specifies PCEP extensions in order to gather various
gather various state metrics along the path computation chain. In state metrics along the path computation chain. In this document we
this document we call a "state metric" a metric that characterizes a call a "state metric" a metric that characterizes a PCE state. For
PCE state. For example, such metric can have a form of a bolean (PCE example, such metric can have a form of a bolean (PCE is alive or
is alive or not, PCE is congested or not) or a performance metric not, PCE is congested or not) or a performance metric (path
(path computation time at each PCE). computation time at each PCE).
PCE state metrics collection can be gathered in two different PCE state metrics can be gathered in two different contexts: in band
contexts: in band or out of band. By "In band" we refer to the or out of band. By "In band" we refer to the situation whereby a PCC
situation whereby a PCC requests to gather metrics in the context of requests to gather metrics in the context of a path computation
a path computation request. For example, a PCC may send a path request. For example, a PCC may send a path computation request to a
computation request to a PCE and may want to know the processing time PCE and may want to know the processing time of that request in
of that request in addition to the computed path. Conversely, if the addition to the computed path. Conversely, if the request is "out of
request is "out of band", PCE state metric collection is performed as band", PCE state metric collection is performed as a standalone
a standalone request (e.g. check the liveness of a specific PCE request (e.g. check the liveness of a specific PCE chain, collect the
chain, collect the average processing time computed over the last 5mn average processing time computed over the last 5mn period on one or
period on one or more PCE(s)"). more PCEs").
In this document we define two monitoring request types: general and In this document we define two monitoring request types: general and
specific. A general monitoring request relates to the collection of specific. A general monitoring request relates to the collection of
a PCE state metric(s) that is not coupled to a particular path a PCE state metrics that is not coupled to a particular path
computation request (e.g. average CPU load on a PCE). Conversely, a computation request (e.g. average CPU load on a PCE). Conversely, a
specific monitoring request relates to a particular path computation specific monitoring request relates to a particular path computation
request (processing time to complete the path computation for a TE request (processing time to complete the path computation for a TE
LSP). LSP).
2. Terminology
PCC (Path Computation Client): any client application requesting a
path computation to be performed by a Path Computation Element.
PCE (Path Computation Element): an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TE LSP: Traffic Engineering Label Switched Path.
3. Path Computation Monitoring messages 3. Path Computation Monitoring messages
As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a
common header followed by a variable length body made of a set of common header followed by a variable length body made of a set of
objects that can either be mandatory or optional. As a reminder, an objects that can either be mandatory or optional. As a reminder, an
object is said to be mandatory in a PCEP message when the object must object is said to be mandatory in a PCEP message when the object must
be included for the message to be considered as valid. The P flag be included for the message to be considered as valid. The P flag
(defined in [I-D.ietf-pce-pcep]) is located in the common header of (defined in [I-D.ietf-pce-pcep]) is located in the common header of
each PCEP object and can be set by a PCEP peer to enforce a PCE to each PCEP object and can be set by a PCEP peer to require a PCE to
take into account the related information during the path take into account the related information during the path
computation. Because the P flag exclusively relates to a path computation. Because the P flag exclusively relates to a path
computation request, it MUST be cleared in the two PCEP messages computation request, it MUST be cleared in the two PCEP messages
(PCEMonReq and PCMonRep message) defined in this document. (PCEMonReq and PCMonRep message) defined in this document.
For each PCEP message type a set of rules is defined that specify the For each PCEP message type a set of rules is defined that specify the
set of objects that the message can carry. We use the Backus-Naur set of objects that the message can carry. We use the Backus-Naur
Form (BNF) to specify such rules. Square brackets refer to optional Form (BNF) to specify such rules. Square brackets refer to optional
sub-sequences. An implementation MUST form the PCEP messages using sub-sequences. An implementation MUST form the PCEP messages using
the object ordering specified in this document. the object ordering specified in this document.
skipping to change at page 6, line 21 skipping to change at page 5, line 26
involved in a path computation chain. The PCMonRep message sent by a involved in a path computation chain. The PCMonRep message sent by a
PCE to a PCC is used to provide such data. PCE to a PCC is used to provide such data.
3.1. Path Computation Monitoring Request message (PCMonReq) 3.1. Path Computation Monitoring Request message (PCMonReq)
The Message-Type field of the PCEP common header for the PCMonReq The Message-Type field of the PCEP common header for the PCMonReq
message is set to 8 (To be confirmed by IANA). message is set to 8 (To be confirmed by IANA).
There is one mandatory object that MUST be included within a PCMonReq There is one mandatory object that MUST be included within a PCMonReq
message: the Monitoring object (see section Section 4.1). If the message: the Monitoring object (see section Section 4.1). If the
Monitoring object is missing, the receiving PCE MUST send an error Monitoring object is missing, the receiving PCE MUST send a PCErr
message to the sender. Other objects are optional. message with Error-type=6 (Mandatory Object missing) and Error-
value=4 (MONITORING Object missing). Other objects are optional.
The format of a PCMonReq message is as follows: The format of a PCMonReq message is as follows:
<PCMonReq Message>::= <Common Header> <PCMonReq Message>::= <Common Header>
<MONITORING> <MONITORING>
[<pce-list>] [<pce-list>]
[<svec-list>] [<svec-list>]
[<request-list>] [<request-list>]
where: where:
<svec-list>::=<SVEC> <svec-list>::=<SVEC>
skipping to change at page 7, line 51 skipping to change at page 6, line 51
objects defined in Section 4.2.) or may alternatively be determined objects defined in Section 4.2.) or may alternatively be determined
by the path computation procedure. For example, if the BRPC by the path computation procedure. For example, if the BRPC
procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE
LSP, the PCE chain may be determined dynamically. In that case, the LSP, the PCE chain may be determined dynamically. In that case, the
PCC sends a PCMonReq message that contains the PCEP objects that PCC sends a PCMonReq message that contains the PCEP objects that
charaterize the TE LSP attributes along with the monitoring objects charaterize the TE LSP attributes along with the monitoring objects
(see Section 4.1) that list the set of metric(s) of interest. (see Section 4.1) that list the set of metric(s) of interest.
Several PCE state metrics may be requested that are specified by a Several PCE state metrics may be requested that are specified by a
set of objects defined in Section 4. Note that this set of objects set of objects defined in Section 4. Note that this set of objects
is by all means not limitative and may be extended in further may be extended in the future.
revision of this document.
For the sake of illustraion, consider the three following examples: For the sake of illustraion, consider the three following examples:
Example 1: PCC1 requests to check the path computation chain should a Example 1: PCC1 requests to check the path computation chain that
path computation be requested for a specific TE LSP named T1. A would be used should it request a path computation for a specific TE
PCMonReq message is sent that contains a MONITORING object specifying LSP named T1. A PCMonReq message is sent that contains a MONITORING
a path computation check, along with the appropriate set of objects object specifying a path computation check, along with the
(e.g. RP, END-POINTS, ...) that would be included in a PCReq message appropriate set of objects (e.g. RP, END-POINTS, ...) that would be
for T1. included in a PCReq message for T1.
Example 2: PCC1 requests a path computation for a TE LSP and also Example 2: PCC1 requests a path computation for a TE LSP and also
request to gather the processing time along the path computation request to gather the processing time along the path computation
chain selected for the computation of T1. A PCReq message is sent chain selected for the computation of T1. A PCReq message is sent
that also contains a MONITORING object that specifies the performance that also contains a MONITORING object that specifies the performance
metric of interest. The PCRep message also comprises a PROC-TIME metric of interest. The PCRep message also carries a PROC-TIME
object defined in section Section 4.1 that reports the computed object defined in section Section 4.1 that reports the computed
metrics. metrics.
Example 3: PCC2 requests to gather performance metrics along the Example 3: PCC2 requests to gather performance metrics along the
specific path computation chain <pce1, pce2, pce3, pce7>. A PCMonreq specific path computation chain <pce1, pce2, pce3, pce7>. A PCMonreq
message is sent to PCE1 that contains a set of PCE-ID objects that message is sent to PCE1 that contains a sequence of PCE-ID objects
identify PCE1, PCE2, PCE3 and PCE7 respectively. that identify PCE1, PCE2, PCE3 and PCE7 respectively.
3.2. Path Monitoring Reply message (PCMonRep) 3.2. Path Monitoring Reply message (PCMonRep)
The PCMonRep message is used to provide PCE state metrics back to the The PCMonRep message is used to provide PCE state metrics back to the
requester for "out of band" monitoring requests. The Message-Type requester for "out of band" monitoring requests. The Message-Type
field of the PCEP common header for the PCMonRep message is set to 9 field of the PCEP common header for the PCMonRep message is set to 9
(To be confirmed by IANA). (To be confirmed by IANA).
There is one mandatory object that MUST be included within a PCMonRep There is one mandatory object that MUST be included within a PCMonRep
message: the Monitoring object (see Section 4.1). If the Monitoring message: the Monitoring object (see Section 4.1). If the Monitoring
object is missing, the receiving PCE MUST send an error message to object is missing, the receiving PCE MUST send a PCErr message with
the requesting PCC. Other objects are optional. Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING
Object missing).
Other objects are optional.
The format of a PCReq message is as follows: The format of a PCReq message is as follows:
<PCMonRep Message>::= <Common Header> <PCMonRep Message>::= <Common Header>
<MONITORING> <MONITORING>
[<RP>] [<RP>]
[<metric-pce-list>] [<metric-pce-list>]
where: where:
<metric-pce-list>::=<metric-pce>[<metric-pce-list>] <metric-pce-list>::=<metric-pce>[<metric-pce-list>]
skipping to change at page 9, line 25 skipping to change at page 8, line 25
<metric-pce>::=[<PCE-ID>] <metric-pce>::=[<PCE-ID>]
[<PROC-TIME>] [<PROC-TIME>]
[<TIME-STAMP>] [<TIME-STAMP>]
[<CONGESTION>] [<CONGESTION>]
4. Path Computation Monitoring Objects 4. Path Computation Monitoring Objects
The PCEP objects defined in the document are compliant with the PCEP The PCEP objects defined in the document are compliant with the PCEP
object format defined in [I-D.ietf-pce-pcep], with the P flag and the object format defined in [I-D.ietf-pce-pcep], with the P flag and the
I flag cleared since these flags are exclusively related to path I flag cleared since these flags are exclusively related to path
computation request. computation requests.
Several objects are defined in this section that can be carried Several objects are defined in this section that can be carried
within the PCEP PCReq or PCRep messages defined in within the PCEP PCReq or PCRep messages defined in
[I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In [I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In
case of "out of band" monitoring requests, the objects defined in case of "out of band" monitoring requests, the objects defined in
this section are carried within PCMonReq and PCMonRep messages. this section are carried within PCMonReq and PCMonRep messages.
Conversely, if the PCC requests the computation of the TE LSP in Conversely, if the PCC requests the computation of the TE LSP in
addition to gathering PCE state metrics (i.e. "In band" requests), addition to gathering PCE state metrics (i.e. "In band" requests),
these objects are carried within PCReq and PCRep messages. these objects are carried within PCReq and PCRep messages.
4.1. MONITORING Object 4.1. MONITORING Object
The MONITORING object MUST be present within PCMonReq and PCMonRep The MONITORING object MUST be present within PCMonReq and PCMonRep
messages ("out of band" monitoring requests) and MAY be carried messages ("out of band" monitoring requests) and MAY be carried
within PCRep and PCReq messages ("in band" monitoring requests). The
MONITORING object MUST be present within PCMonReq and PCMonRep
messages ("out of band" monitoring requests) and MAY be carried
within PCERep and PCReq messages ("in band" monitoring requests). within PCERep and PCReq messages ("in band" monitoring requests).
There MUST be exactly once instance of the MONITORING object: if more There SHOULD NOT be more than one instance of the MONITORING object:
than one instance of the MONITORING object is present, the recipient if more than one instance of the MONITORING object is present, the
MUST only process the first instance and ignore other instances. The recipient MUST process the first instance and MUST ignore other
MONITORING object is used to specify the set of requested PCE state instances.
metrics.
The MONITORING object is used to specify the set of requested PCE
state metrics.
The MONITORING Object-Class is to be assigned by IANA (recommended The MONITORING Object-Class is to be assigned by IANA (recommended
value=19) value=19)
The MONITORING Object-Type is to be assigned by IANA (recommended The MONITORING Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the MONITORING object body is as follows: The format of the MONITORING 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 |I|C|P|G|L| | Reserved | Flags |I|C|P|G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| monitoring-id-number | | Monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 18 bits Flags: 24 bits
The following flags are currently defined: The following flags are currently defined:
L (Liveness) - 1 bit: when set, this indicates that the state metric L (Liveness) - 1 bit: when set, this indicates that the state metric
of interest is the PCE's liveness and thus the PCE MUST include a of interest is the PCE's liveness and thus the PCE MUST include a
PCE-ID object in the corresponding reply. PCE-ID object in the corresponding reply. The L bit MUST always be
ignored in a PCMonRep or PCRep message.
G (General) - 1 bit: when set, this indicates that the monitoring G (General) - 1 bit: when set, this indicates that the monitoring
request is a general monitoring request. When the requested request is a general monitoring request. When the requested
performance metric is specific, the G bit MUST be cleared. performance metric is specific, the G bit MUST be cleared. The G bit
MUST always be ignored in a PCMonRep or PCRep message.
P (Processing Time) - 1 bit: the P bit of the MONITORING object P (Processing Time) - 1 bit: the P bit of the MONITORING object
carried in a PCMonReq or a PCReq message is set to indicate that the carried in a PCMonReq or a PCReq message is set to indicate that the
processing times is a metric of interest, in which case a PROC-TIME processing times is a metric of interest, in which case a PROC-TIME
object MUST be inserted in the corresponding PCMonRep or PCRep object MUST be inserted in the corresponding PCMonRep or PCRep
message. The P bit MUST always be set in a PCMonRep message if also message. The P bit MUST always be ignored in a PCMonRep or PCRep
set in the corresponding PCMonReq message. message.
C (Congestion) - 1 bit: The C bit of the MONITORING object carried in C (Congestion) - 1 bit: The C bit of the MONITORING object carried in
a PCMonReq or a PCReq message is set to indicate that the congestion a PCMonReq or a PCReq message is set to indicate that the congestion
status is a metric of interest, in which case a CONGESTION object status is a metric of interest, in which case a CONGESTION object
MUST be inserted in the corresponding PCMonRep or PCRep message. The MUST be inserted in the corresponding PCMonRep or PCRep message. The
C bit MUST always be set in a PCMonRep message if also set in the C bit MUST always be ignored in a PCMonRep or PCRep message.
corresponding PCMonReq message.
I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message
the PCMonReq message, which does not trigger any policy violation but and that message does not trigger any policy violation, but the PCE
that cannot provide the set of requested performance metrics for cannot provide any of the set of requested performance metrics for
unspecified reasons. unspecified reasons, the PCE MUST set the I bit. The I bit has no
meaning in a request and SHOULD be ignored on receipt.
Monitoring-id-number (32 bits). The monitoring-id-number value Monitoring-id-number (32 bits): The monitoring-id-number value
combined with the source IP address of the PCC and the PCE address combined with the PCEP-ID of the PCC identifies the monitoring
uniquely identify the monitoring request context. The monitoring-id- request context. The monitoring-id-number MUST start at a non-zero
number MUST be incremented each time a new monitoring is sent to a value and MUST be incremented each time a new monitoring request is
PCE. The value 0x0000000 is considered as invalid. If no reply to a sent to a PCE. Each increment SHOULD have a value of 1 and may cause
monitoring request is received from the PCE, and the PCC wishes to a wrap back to one. If no reply to a monitoring request is received
resend its path computation monitoring request, the same monitoring- from the PCE, and the PCC wishes to resend its path computation
id-number MUST be used. Conversely, different monitoring-id-number monitoring request, the same monitoring-id-number MUST be used.
MUST be used for different requests sent to a PCE. The same Conversely, a different monitoring-id-number MUST be used for
monitoring-id-number may be used for path computation monitoring different requests sent to a PCE. The path computation monitoring
requests sent to different PCEs. The path computation monitoring reply is unambiguously identified by the monitoring-id-number and the
reply is unambiguously identified by the IP source address of the PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint
replying PCE. the Monitoring-id-number of pending monitoring requests in case of
restart thus avoiding the re-use of a Monitoring-id-number of an in-
process monitoring request.
Unassigned bits are considered as reserved and MUST be set to zero on Unassigned bits are considered as reserved and MUST be set to zero on
transmission. transmission and ignored on reception.
No optional TLVs are currently defined. No optional TLVs are currently defined.
4.2. PCE-ID Object 4.2. PCEP-ID Object
The PCE-ID Object is used to specify a PCE's IP address. The PCEP-ID Object is used to specify a PCE's IP address.
A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq A set of PCEP-ID objects may be inserted within a PCReq or a PCMonReq
message to specify the PCE for which PCE state metrics are requested message to specify the PCE for which PCE state metrics are requested
and in a PCMonRep or a PCRep message to record the IP address of the and in a PCMonRep or a PCRep message to record the IP address of the
PCE reporting PCE state metrics or that was involved in the path PCE reporting PCE state metrics or that was involved in the path
computation chain. computation chain.
Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- Two PCEP-ID objects (for IPv4 and IPv6) are defined. PCEP-ID Object-
Class is to be assigned by IANA (recommended value=20) PCE-ID Object- Class is to be assigned by IANA (recommended value=20) PCEP-ID
Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 Object-Type is to be assigned by IANA (recommended value=1 for IPv4
for IPv6) and 2 for IPv6)
The format of the PCE-ID Object is as follows: The format of the PCEP-ID Object is as follows:
The format of the PCE-ID object body for IPv4 and IPv6 are as The format of the PCEP-ID object body for IPv4 and IPv6 are as
follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 The PCEP-ID object body has a fixed length of 4 octets for IPv4 and
octets for IPv6. 16 octets for IPv6.
A PCE MUST use the same IP address as the address used in the PCE- When a dynamic discovery mechanism is used for PCE discovery, a PCE
ADDRESS sub-TLV defined in [RFC5088] and [RFC5089] should a dynamic advertises its PCE address in the PCE-ADDRESS sub-TLV defined in
discovery mechanism be used for PCE discovery. [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and
PCMonReq messages and a PCE MUST also use this address in PCRep and
PCMonRep messages.
4.3. PROC-TIME Object 4.3. PROC-TIME Object
The PROC-TIME object MUST be present within a PCMonRep or a PCRep If allowed by policy, the PCE includes a PROC-TIME object within a
message if the P bit of the MONITORING object carried within the PCMonRep or a PCRep message if the P bit of the MONITORING object
corresponding PCMonReq or PCReq message is set. The PROC-TIME object carried within the corresponding PCMonReq or PCReq message is set.
is used to report various processing time related metrics. The PROC-TIME object is used to report various processing time
related metrics.
1) Case of general monitoring requests 1) Case of general monitoring requests
A PCC may request processing time metrics for general monitoring A PCC may request processing time metrics for general monitoring
requests (e.g. the PCC may want to know the minimum, maximum and requests (e.g. the PCC may want to know the minimum, maximum and
average processing times on a particular PCE). In this case, general average processing times on a particular PCE). In this case, general
requests can only be made by using PCMonReq/PCMonRep messages. The requests can only be made by using PCMonReq/PCMonRep messages. The
processing-time field (as explained below) is exclusively used for processing-time field (as explained below) is exclusively used for
specific monitoring requests and MUST be cleared for general specific monitoring requests and MUST be cleared for general
monitoring requests. The algorithm(s) used by a PCE to compute the monitoring requests. The algorithm(s) used by a PCE to compute the
skipping to change at page 13, line 17 skipping to change at page 12, line 21
computed. The PCE may either (1) estimate the processing time computed. The PCE may either (1) estimate the processing time
without performing an actual path computation or (2) effectively without performing an actual path computation or (2) effectively
perform the computation to report the processing time. In the former perform the computation to report the processing time. In the former
case, the E bit of the PROC-TIME object MUST be set. The G bit MUST case, the E bit of the PROC-TIME object MUST be set. The G bit MUST
be cleared and the Min-processing-time, Max-processing-time, Average- be cleared and the Min-processing-time, Max-processing-time, Average-
processing-time and Variance-processing-time MUST be set to processing-time and Variance-processing-time MUST be set to
0x00000000. 0x00000000.
When the processing time is requested in addition to a path When the processing time is requested in addition to a path
computation (case where the MONITORING object is carried within a computation (case where the MONITORING object is carried within a
PCReq message), the PROC-TIME object always report the actual PCReq message), the PROC-TIME object always reports the actual
processing time for that request and thus the E bits MUST be cleared. processing time for that request and thus the E bit MUST be cleared.
The PROC-TIME Object-Class is to be assigned by IANA (recommended The PROC-TIME Object-Class is to be assigned by IANA (recommended
value=21) value=21)
The PROC-TIME Object-Type is to be assigned by IANA (recommended The PROC-TIME Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the PROC-TIME object body is as follows: The format of the PROC-TIME 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 | | Reserved | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Processing-time |E| | Current-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time | | Min-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time | | Max-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time | | Average-processing time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time | | Variance-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 27 skipping to change at page 13, line 30
Unassigned bits are considered as reserved and MUST be set to zero on Unassigned bits are considered as reserved and MUST be set to zero on
transmission. transmission.
More granularity may be introduced in further revision of this More granularity may be introduced in further revision of this
document to get a monitoring metric for a general request of a document to get a monitoring metric for a general request of a
particular class (e.g. all PCReq of priority X). particular class (e.g. all PCReq of priority X).
4.4. CONGESTION Object 4.4. CONGESTION Object
The CONGESTIION object MUST be present within a PCMonRep or a PCRep The CONGESTION object MUST be present within a PCMonRep or a PCRep
message if the C bit of the MONITORING object carried within the message if the C bit of the MONITORING object carried within the
corresponding PCMonReq or PCReq message is set. The CONGESTION corresponding PCMonReq or PCReq message is set. The CONGESTION
object is used to report a PCE processing congestion state. The object is used to report a PCE processing congestion state. The
CONGESTION Object-Class is to be assigned by IANA (recommended CONGESTION Object-Class is to be assigned by IANA (recommended
value=22) The CONGESTION Object-Type is to be assigned by IANA value=22) The CONGESTION Object-Type is to be assigned by IANA
(recommended value=1) (recommended value=1)
The format of the CONGESTION object body is as follows: The format of the CONGESTION object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved | Congestion Duration | |C| Reserved | Congestion Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C (Congestion) - 1 bit: when set, this indicates that PCE is C (Congestion) - 1 bit: when set, this indicates that PCE is
congested, in which case the congestion duration may be non nul. congested, in which case the congestion duration may be non nul.
When cleared this indicates that the PCE is not congested. When cleared this indicates that the PCE is not congested and the
"Congestion Duration" field MUST be set to 0x0000.
Congestion duration - 16 bits: This field indicates in seconds the Congestion duration - 16 bits: This field indicates in seconds the
estimated congestion duration. estimated congestion duration.
4.5. TIMESTAMP Object 5. Policy
A TIMESTAMP object will be specified in a further revision of this
document that could be used to indicate when a PCMonReq message has
been received by a PCE and when the PCMonReq message has been relayed
to the next-hop PCE or the time at which a PCMonRep message has been
sent to the requester.
5. Multi-destination monitoring
In a further revision of this document, a new object will be
specified allowing a PCC or a user to gather PCE state metrics for a
set of destinations using a single PCMonReq message. For example,
using a single PCMonreq message originated by a PCC, PCE state
metrics for the set of path computation chains involved in the
computation of a set of TE LSPs will be gathered. Such set of
destinations could be specified in the form of a subnets.
6. Policy
The receipt of a PCMonReq message may trigger a policy violation on The receipt of a PCMonReq message may trigger a policy violation on
some PCE in which case the PCE MUST send a PCErr message with Error- some PCE in which case the PCE MUST send a PCErr message with Error-
Type=5 and Error-value=3 (To be Confirmed by IANA). Type=5 and Error-value=3 (To be Confirmed by IANA).
7. Elements of procedure 6. Elements of Procedure
I bit processing: as indicated in section Section 4.1, the I bit MUST I bit processing: as indicated in section Section 4.1, if a PCE
be set by a PCE that supports the PCMonReq message, which does not supports a received PCMonReq message and that message does not
trigger any policy violation but that cannot provide the set of trigger any policy violation, but the PCE cannot provide any of the
required performance metrics for unspecified reasons. Once set, the set of requested performance metrics for unspecified reasons, the PCE
I bit MUST NOT be changed by a receiving PCE. MUST set the I bit. Once set, the I bit MUST NOT be changed by a
receiving PCE.
Reception of a PCMonReq message: upon receiving a PCMonReq message: Reception of a PCMonReq message: upon receiving a PCMonReq message:
1) If the PCE does not support the PCMonReq message, the PCE MUST 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support
send a PCErr message with Error-type=14 and Error-value=1. the PCMonReq message, the PCE peer must send a PCErr message with
Error-value=2 (capability not supported).
2) If the PCE supports the PCMonReq message but the request is 2) If the PCE supports the PCMonReq message but the request is
prohibited by policy, the PCE MUST send a PCErr message with Error- prohibited by policy, the PCE MUST send a PCErr message with Error-
Type=5 and Error-value=3. Type=5 and Error-value=3.
3) If the PCE supports the PCMonReq and the monitoring request is not 3) If the PCE supports the PCMonReq and the monitoring request is not
prohibited by policy, the receiving PCE MUST first determine whether prohibited by policy, the receiving PCE MUST first determine whether
it is the last PCE of the path computation chain. If the PCE is not it is the last PCE of the path computation chain. If the PCE is not
the last element of the path computation chain, the PCMonReq message the last element of the path computation chain, the PCMonReq message
is relayed to the next hop PCE: such next-hop may either be specified is relayed to the next hop PCE: such next-hop may either be specified
by means of a PCE-ID object present in the PCMonReq message or by means of a PCEP-ID object present in the PCMonReq message or
dynamically determined by means of a procedure outside of the scope dynamically determined by means of a procedure outside of the scope
of this document. Conversely, if the PCE is the last PCE of the path of this document. Conversely, if the PCE is the last PCE of the path
computation chain, the PCE originates a PCMonRep message that computation chain, the PCE originates a PCMonRep message that
contains the requested objects according to the set of requested PCE contains the requested objects according to the set of requested PCE
states metrics listed in the MONITORING object carried in the states metrics listed in the MONITORING object carried in the
corresponding PCMonReq message. corresponding PCMonReq message.
Reception of a PCMonRep message: upon receiving a PCMonRep message, Upon receiving a PCMonRep message: upon receiving a PCMonRep message,
the PCE processes the request, adds the relevant objects to the the PCE processes the request, adds the relevant objects to the
PCMonRep message and forwards the PCMonRep message to the upstream PCMonRep message and forwards the PCMonRep message to the upstream
requesting PCE or PCC. requesting PCE or PCC.
Special case of Multi-destination monitoring: monitoring request Special case of Multi-destination monitoring: monitoring request
related to more than one destinations may involve a set of path related to more than one destinations may involve a set of path
computation chains. In that case, a PCE sends each copy of the computation chains. In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation PCMonReq message to each downstream PCE of each path computation
chain. chain.
8. Manageability Considerations 7. Manageability Considerations
To be addressed in a further revision of this document. To be addressed in a further revision of this document.
9. To be considered in a further revision of this document 8. IANA Considerations
It might be desirable to modify the format of the PCMonReq and
PCMonRep messages to support the bundling of multiple performance
metrics collection for a set of TE LSPs.
10. IANA Considerations Each PCEP message has a message type value.
Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined
in this document: in this document:
Value Meaning Value Meaning
8 Path Computation Monitoring Request (PCMonReq) 8 Path Computation Monitoring Request (PCMonReq)
9 Path Computation Monitoring Reply (PCMonRep) 9 Path Computation Monitoring Reply (PCMonRep)
The following new PCEP objects are defined in this document. Each PCEP object has an Object-Class and an Object-Type. The
following new PCEP objects are defined in this document.
Object-Class Name Object-Class Name
19 MONITORING 19 MONITORING
Object-Type Object-Type
1 1
20 PCE-ID 20 PCEP-ID
Object-Type Object-Type
1: IPv4 addresses 1: IPv4 addresses
2: IPv6 addresses 2: IPv6 addresses
21 PROC-TIME 21 PROC-TIME
Object-Type Object-Type
1 1
22 CONGESTION 22 CONGESTION
Object-Type Object-Type
1 1
A new Error type for the PCErr message (see [I-D.ietf-pce-pcep]) is A registry has been created for the Error-type and Error-value of the
defined in this document (Error-Type and Error-value to be assigned PCEP Error Object.
by IANA).
A new Error-value for the PCErr message Error-types=5 (Policy
Violation) (see [I-D.ietf-pce-pcep]) is defined in this document
(Error-Type and Error-value to be assigned by IANA).
Error-type Meaning Error-type Meaning
14 Performance Monitoring not supported 5 Policy violation
Error-value Error-value=3 [This document]
1: Monitoring message not supported by one Monitoring message supported but rejected
of PCEs along the domain path due to policy violation
2: MONITORING object missing in a PCMonReq
message
A new Error-value for the PCErr message Error-types=4 (see A new Error-value for the PCErr message Error-types=6 (Mandatory
[I-D.ietf-pce-pcep]) is defined in this document (Error-Type and Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document
Error-value to be assigned by IANA). (Error-Type and Error-value to be assigned by IANA).
Error-type Meaning Error-type Meaning
5 Performance Monitoring Policy violation 6 Mandatory Object missing
3: Monitoring message supported but rejected Error-value=4 [This document]
due to policy violation MONITORING Object missing
11. Security Considerations 9. Security Considerations
To be addressed in a further revision of this document. To be addressed in a further revision of this document.
12. Acknowledgements 10. Acknowledgements
The authors would like to thank Eiji Oki, Mach Chen and Dimitri The authors would like to thank Eiji Oki, Mach Chen and Dimitri
Papadimitriou for their useful comments. Papadimitriou for their useful comments. Special thank to Adrian
Farrel for his detailed review.
13. References 11. References
13.1. Normative References 11.1. Normative References
[I-D.ietf-pce-pcep] [I-D.ietf-pce-pcep]
Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
Y., Kumaki, K., Vasseur, J., and J. Roux, "Path A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
Computation Element (PCE) communication Protocol (PCEP)", "Path Computation Element (PCE) Communication Protocol
draft-ietf-pce-pcep-09 (work in progress), November 2007. (PCEP)", draft-ietf-pce-pcep-14 (work in progress),
September 2008.
[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.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
13.2. Informative References 11.2. Informative References
[I-D.ietf-pce-brpc] [I-D.ietf-pce-brpc]
Vasseur, J., "A Backward Recursive PCE-based Computation Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A
(BRPC) procedure to compute shortest inter-domain Traffic Backward Recursive PCE-based Computation (BRPC) Procedure
Engineering Label Switched Paths", draft-ietf-pce-brpc-06 To Compute Shortest Constrained Inter-domain Traffic
(work in progress), September 2007. Engineering Label Switched Paths", draft-ietf-pce-brpc-09
(work in progress), April 2008.
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS Protocol Extensions for Path Computation Roux, J., "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-08 (work in progress), draft-ietf-pce-disco-proto-isis-08 (work in progress),
September 2007. September 2007.
[I-D.ietf-pce-of] [I-D.ietf-pce-of]
Roux, J., "Encoding of Objective Functions in Path Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
Computation Element communication Protocol (PCEP)", Functions in the Path Computation Element Communication
draft-ietf-pce-of-01 (work in progress), November 2007. Protocol (PCEP)", draft-ietf-pce-of-04 (work in progress),
August 2008.
[I-D.ietf-pce-pcep-xro] [I-D.ietf-pce-pcep-xro]
Oki, E. and A. Farrel, "Extensions to the Path Computation Takeda, T., Oki, E., and A. Farrel, "Extensions to the
Element Communication Protocol (PCEP) for Route Path Computation Element Communication Protocol (PCEP) for
Exclusions", draft-ietf-pce-pcep-xro-02 (work in Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in
progress), September 2007. progress), July 2008.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008. (PCE) Discovery", RFC 5089, January 2008.
Authors' Addresses Authors' Addresses
skipping to change at page 20, line 44 skipping to change at line 806
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. 76 change blocks. 
226 lines changed or deleted 227 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/