draft-ietf-pce-monitoring-04.txt   draft-ietf-pce-monitoring-05.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: July 24, 2009 France Telecom Expires: December 14, 2009 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
January 20, 2009 June 12, 2009
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-04.txt draft-ietf-pce-monitoring-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 July 24, 2009. This Internet-Draft will expire on December 14, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 refers to a collection of network multiple domains (where a domain refers to a collection of 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). Path Computation Clients (PCCs) send computation requests Systems). Path Computation Clients (PCCs) send computation requests
to PCEs, and these may forward the requests to and cooperate with to PCEs, and these may forward the requests to and cooperate with
other PCEs forming a "path computation chain". In PCE-based other PCEs forming a "path computation chain".
environments, it is thus critical to monitor the state of the path
computation chain for troubleshooting and performance monitoring
purposes: liveness of each element (PCE) involved in the PCE chain,
detection of potential resource contention states and statistics in
term of path computation times are examples of such metrics of
interest. This document specifies procedures and extensions to the
Path Computation Element Protocol (PCEP) in order to gather such
information.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In PCE-based environments, it is thus critical to monitor the state
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this of the path computation chain for troubleshooting and performance
document are to be interpreted as described in RFC 2119 [RFC2119]. monitoring purposes: liveness of each element (PCE) involved in the
PCE chain, detection of potential resource contention states and
statistics in term of path computation times are examples of such
metrics of interest. This document specifies procedures and
extensions to the Path Computation Element Protocol (PCEP) in order
to gather such information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Path Computation Monitoring messages . . . . . . . . . . . . . 5 3. Path Computation Monitoring messages . . . . . . . . . . . . . 6
3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6
3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9
4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11
4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12
4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14
4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 14 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15
4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 16 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 17 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18
7. Manageability Considerations . . . . . . . . . . . . . . . . . 19 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20
7.1. Control of Function and Policy . . . . . . . . . . . . . . 19 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20
7.2. Information and Data Models . . . . . . . . . . . . . . . 19 7.2. Information and Data Models . . . . . . . . . . . . . . . 20
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 20 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21
8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 20 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21
8.3. New Error-Type and Error-Values . . . . . . . . . . . . . 21 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21
8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 21 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22
8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22
8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 22 8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. 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 refers to a collection of network or multiple domains where a domain refers to a collection of 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 Interior Gateway Protocol (IGP)
Systems. areas and Autonomous Systems.
Path Computation Clients (PCCs) send computation requests to PCEs, Path Computation Clients (PCCs) send computation requests to PCEs
and these may forward the requests to and cooperate with other PCEs using PCReq messages, and these may forward the requests to and
forming a "path computation chain". In PCE-based environments, it is cooperate with other PCEs forming a "path computation chain". In
critical to monitor the state of the path computation chain for case of succesful path computation the computed paths are then
troubeshooting and performance monitoring purposes: liveness of each provided to the requesting PCC using PCRep messages. The PCReq and
element (PCE) involved in the PCE chain, detection of potential PCRep messages are defined in [RFC5440].
resource contention states and statistics in term of path computation
times are examples of such metrics of interest. This document In PCE-based environments, it is critical to monitor the state of the
specifies procedures and extensions to the Path Computation Element path computation chain for troubleshooting and performance monitoring
Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to monitor the path purposes: liveness of each element (PCE) involved in the PCE chain,
computation chain and gather various performance metrics. detection of potential resource contention states and statistics in
term of path computation times are examples of such metrics of
interest.
As defined in [RFC4655], there are circumstances where more than one 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 PCE are involved in the computation of a TE LSP. A typical example
when the PCC requires the computation of a TE LSP where the head-end is when the PCC requires the computation of a TE LSP where the head-
and the tail-end of the TE LSP do not reside in adjacent domains and end and the tail-end of the TE LSP do not reside in adjacent domains
there is no single PCE with the visibility of both the head-end and and there is no single PCE with the visibility of both the head-end
tail-end domain. We call the set of PCEs involved in the computation and tail-end domain. We call the set of PCEs involved in the
of a TE LSP a "path computation chain". As further discussed in computation of a TE LSP a "path computation chain". As further
Section 3.1, the PCE chain may either be static (pre-configured) or discussed in Section 3.1, the PCE chain may either be static (pre-
dynamically determined during the path computation process. configured) or dynamically determined during the path computation
process.
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 Backward Recursive PCE-
in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the based Computation (BRPC) procedure defined in [RFC5441], the PCC's
first PCE involved in the path computation chain. Thus, it is visibility may be limited to the first PCE involved in the path
critical to define mechanisms in order to monitor the state of the computation chain. Thus, it is critical to define mechanisms in
path computation chain. order to monitor the state of the path computation chain.
This document specifies PCEP extensions in order to gather various This document specifies PCEP extensions in order to gather various
state metrics along the path computation chain. In this document we state metrics along the path computation chain. In this document we
call a "state metric" a metric that characterizes a PCE state. For call a "state metric" a metric that characterizes a PCE state. For
example, such metric can have a form of a bolean (PCE is alive or example, such metric can have a form of a boolean (PCE is alive or
not, PCE is congested or not) or a performance metric (path not, PCE is congested or not) or a performance metric (path
computation time at each PCE). computation time at each PCE).
PCE state metrics can be gathered in two different contexts: in band PCE state metrics can be gathered in two different contexts: in band
or out of band. By "In band" we refer to the situation whereby a PCC or out of band. By "in band" we refer to the situation whereby a PCC
requests to gather metrics in the context of a path computation requests to gather metrics in the context of a path computation
request. For example, a PCC may send a path computation request to a request. For example, a PCC may send a path computation request to a
PCE and may want to know the processing time of that request in PCE and may want to know the processing time of that request in
addition to the computed path. Conversely, if the request is "out of addition to the computed path. Conversely, if the request is "out of
band", PCE state metric collection is performed as a standalone band", PCE state metric collection is performed as a standalone
request (e.g. check the liveness of a specific PCE chain, collect the request (e.g., check the liveness of a specific PCE chain, collect
average processing time computed over the last 5mn period on one or the average processing time computed over the last 5mn period on one
more PCEs"). or 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 metrics 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).
This document specifies procedures and extensions to the Path
Computation Element Protocol (PCEP) ([RFC5440]), including new
objects and new PCEP messages, in order to monitor the path
computation chain and gather various performance metrics.
The message formats in this document are specified using Backus Naur The message formats in this document are specified using Backus Naur
Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. Format (BNF) encoding as specified in [RFC5511].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
PCC (Path Computation Client): any client application requesting a PCC (Path Computation Client): any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE (Path Computation Element): an entity (component, application or PCE (Path Computation Element): an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
TE LSP: Traffic Engineering Label Switched Path. 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 [RFC5440], a PCEP message consists of a common header
common header followed by a variable length body made of a set of followed by a variable length body made of a set of objects that can
objects that can either be mandatory or optional. As a reminder, an either be mandatory or optional. As a reminder, an object is said to
object is said to be mandatory in a PCEP message when the object must be mandatory in a PCEP message when the object must be included for
be included for the message to be considered as valid. The P flag the message to be considered as valid. The P flag (defined in
(defined in [I-D.ietf-pce-pcep]) is located in the common header of [RFC5440]) is located in the common header of each PCEP object and
each PCEP object and can be set by a PCEP peer to require a PCE to can be set by a PCEP peer to require a PCE to take into account the
take into account the related information during the path related information during the path computation. Because the P flag
computation. Because the P flag exclusively relates to a path exclusively relates to a path computation request, it MUST be cleared
computation request, it MUST be cleared in the two PCEP messages in the two PCEP messages (PCMonReq and PCMonRep message).
(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. An implementation MUST set of objects that the message can carry. An implementation MUST
form the PCEP messages using the object ordering specified in this form the PCEP messages using the object ordering specified in this
document. document.
In this document we define two PCEP messages referred to as the Path In this document we define two PCEP messages referred to as the Path
Computation Monitoring Request (PCMonReq) and Path Computation Computation Monitoring Request (PCMonReq) and Path Computation
Monitoring Reply (PCMonRep) messages so as to handle "out of band" Monitoring Reply (PCMonRep) messages so as to handle "out of band"
monitoring request. The aim of the PCMonReq message sent by a PCC to monitoring request. The aim of the PCMonReq message sent by a PCC to
skipping to change at page 8, line 31 skipping to change at page 8, line 32
[<RRO>[<BANDWIDTH>]] [<RRO>[<BANDWIDTH>]]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: where:
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
<pce-list>::=<PCE-ID>[<pce-list>] <pce-list>::=<PCE-ID>[<pce-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD-
BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object BALANCING objects are defined in [RFC5440]. The XRO object is
is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in defined in [RFC5521] and the OF object is defined in [RFC5541].
[I-D.ietf-pce-of].
The PCMonReq message is used to gather various PCE state metrics The PCMonReq message is used to gather various PCE state metrics
along a path computation chain. The path computation chain may be along a path computation chain. The path computation chain may be
determined by the PCC (in the form of a series of a series of PCE-ID determined by the PCC (in the form of a series of a series of PCE-ID
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 ([RFC5441]) is used to compute an inter-domain TE LSP, the
LSP, the PCE chain may be determined dynamically. In that case, the PCE chain may be determined dynamically. In that case, the PCC sends
PCC sends a PCMonReq message that contains the PCEP objects that a PCMonReq message that contains the PCEP objects that characterize
charaterize the TE LSP attributes along with the MONITORING object the TE LSP attributes along with the MONITORING object (see
(see Section 4.1) that lists the set of metrics of interest. Section 4.1) that lists the set of metrics 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
may be extended in the future. may be extended in the future.
As pointed out in [I-D.ietf-pce-pcep] several situations can arise: As pointed out in [RFC5440] several situations can arise:
o Bundle of a set of independent and non-synchronized path o Bundle of a set of independent and non-synchronized path
computation requests, computation requests,
o Bundle of a set of independent and synchronized path computation o Bundle of a set of independent and synchronized path computation
requests (SVEC object defined below required), requests (SVEC object defined below required),
o Bundle of a set of dependent and synchronized path computation o Bundle of a set of dependent and synchronized path computation
requests (SVEC object defined below required). requests (SVEC object defined below required).
skipping to change at page 9, line 27 skipping to change at page 9, line 27
the case of dependent and/or synchronized requests sent using more the case of dependent and/or synchronized requests sent using more
than one PCReq or PCMonReq message. than one PCReq or PCMonReq message.
Examples of requests. For the sake of illustration, consider the Examples of requests. For the sake of illustration, consider the
three following examples: three following examples:
Example 1 (out of band request): PCC1 requests to check the path Example 1 (out of band request): PCC1 requests to check the path
computation chain that would be used should it request a path computation chain that would be used should it request a path
computation for a specific TE LSP named T1. A PCMonReq message is computation for a specific TE LSP named T1. A PCMonReq message is
sent that contains a MONITORING object specifying a path computation sent that contains a MONITORING object specifying a path computation
check, along with the appropriate set of objects (e.g. RP, END- check, along with the appropriate set of objects (e.g., RP, END-
POINTS, ...) that would be included in a PCReq message for T1. POINTS, ...) that would be included in a PCReq message for T1.
Example 2 (in band request): PCC1 requests a path computation for a Example 2 (in band request): PCC1 requests a path computation for a
TE LSP and also request to gather the processing time along the path TE LSP and also request to gather the processing time along the path
computation chain selected for the computation of T1. A PCReq computation chain selected for the computation of T1. A PCReq
message is sent that also contains a MONITORING object that specifies message is sent that also contains a MONITORING object that specifies
the performance metrics of interest. the performance metrics of interest.
Example 3 (out of band request): PCC2 requests to gather performance Example 3 (out of band request): PCC2 requests to gather performance
metrics along the specific path computation chain <pce1, pce2, pce3, metrics along the specific path computation chain <pce1, pce2, pce3,
pce7>. A PCMonreq message is sent to PCE1 that contains a MONITORING pce7>. A PCMonReq message is sent to PCE1 that contains a MONITORING
object and a sequence of PCE-ID objects that identify PCE1, PCE2, object and a sequence of PCE-ID objects that identify PCE1, PCE2,
PCE3 and PCE7 respectively. PCE3 and PCE7 respectively.
In all of the examples above, a PCRep message (in-band request) or In all of the examples above, a PCRep message (in-band request) or
PCMonReq message (out of band request) is sent in response to the PCMonReq message (out of band request) is sent in response to the
request that reports the computed metrics. request that reports the computed metrics.
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
skipping to change at page 11, line 37 skipping to change at page 11, line 37
[<IRO>] [<IRO>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>] <metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID> <metric-pce>::=<PCE-ID>
[<PROC-TIME>] [<PROC-TIME>]
[<CONGESTION>] [<CONGESTION>]
The RP object is defined in [I-D.ietf-pce-pcep]. The RP and the NO-PATH objects are defined in [RFC5440].
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]. The P flag and the I object format defined in [RFC5440]. The P flag and the I flag of the
flag of the PCEP objects defined in this document SHOULD always be PCEP objects defined in this document SHOULD always be set to 0 on
set to 0 on transmission and MUST be ignored on receipt since these transmission and MUST be ignored on receipt since these flags are
flags are exclusively related to path computation requests. exclusively related to path 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 [RFC5440] in case
[I-D.ietf-pce-pcep] in case of "in band" monitoring requests (the PCC of "in band" monitoring requests (the PCC requests the computation of
requests the computation of the TE LSP in addition to gathering PCE the TE LSP in addition to gathering PCE state metrics). In case of
state metrics). In case of "out of band" monitoring requests, the "out of band" monitoring requests, the objects defined in this
objects defined in this section are carried within PCMonReq and section are carried within PCMonReq and PCMonRep messages.
PCMonRep messages.
All TLVs carried in objects defined in this document have the TLV
format defined in [RFC5440]
o Type: 2 bytes
o Length: 2 bytes
o Value: variable
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes
specifying the TLV length, and a value field. The Length field
defines the length of the value portion in bytes. The TLV is padded
to 4-bytes alignment; padding is not included in the Length field (so
a 3-byte value would have a length of 3, but the total size of the
TLV would be 8 bytes). Unrecognized TLVs MUST be ignored.
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). within PCRep and PCReq messages ("in band" monitoring requests).
There SHOULD NOT be more than one instance of the MONITORING object: There SHOULD NOT be more than one instance of the MONITORING object
if more than one instance of the MONITORING object is present, the in a PCMonReq or PCMonRep message: if more than one instance of the
recipient MUST process the first instance and MUST ignore other MONITORING object is present, the recipient MUST process the first
instances. instance and MUST ignore other instances.
The MONITORING object is used to specify the set of requested PCE The MONITORING object is used to specify the set of requested PCE
state metrics. 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) //
skipping to change at page 13, line 34 skipping to change at page 14, line 8
and that message does not trigger any policy violation, but the PCE and that message does not trigger any policy violation, but the PCE
cannot provide any of the set of requested performance metrics for cannot provide any of the set of requested performance metrics for
unspecified reasons, the PCE MUST set the I bit. The I bit has no unspecified reasons, the PCE MUST set the I bit. The I bit has no
meaning in a request and SHOULD be ignored on receipt. 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 PCEP-ID of the PCC identifies the monitoring combined with the PCEP-ID of the PCC identifies the monitoring
request context. The monitoring-id-number MUST start at a non-zero request context. The monitoring-id-number MUST start at a non-zero
value and MUST be incremented each time a new monitoring request is value and MUST be incremented each time a new monitoring request is
sent to a PCE. Each increment SHOULD have a value of 1 and may cause sent to a PCE. Each increment SHOULD have a value of 1 and may cause
a wrap back to one. If no reply to a monitoring request is received a wrap back to zero. If no reply to a monitoring request is received
from the PCE, and the PCC wishes to resend its path computation from the PCE, and the PCC wishes to resend its path computation
monitoring request, the same monitoring-id-number MUST be used. monitoring request, the same monitoring-id-number MUST be used.
Conversely, a different monitoring-id-number MUST be used for Conversely, a different monitoring-id-number MUST be used for
different requests sent to a PCE. The path computation monitoring different requests sent to a PCE. The path computation monitoring
reply is unambiguously identified by the monitoring-id-number and the reply is unambiguously identified by the monitoring-id-number and the
PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint
the Monitoring-id-number of pending monitoring requests in case of 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- restart thus avoiding the re-use of a Monitoring-id-number of an in-
process monitoring request. process monitoring request.
skipping to change at page 15, line 4 skipping to change at page 15, line 36
advertises its PCE address in the PCE-ADDRESS sub-TLV defined in advertises its PCE address in the PCE-ADDRESS sub-TLV defined in
[RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and [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 PCMonReq messages and a PCE MUST also use this address in PCRep and
PCMonRep messages. PCMonRep messages.
4.3. PROC-TIME Object 4.3. PROC-TIME Object
If allowed by policy, the PCE includes a PROC-TIME object within a If allowed by policy, the PCE includes a PROC-TIME object within a
PCMonRep or a PCRep message if the P bit of the MONITORING object PCMonRep or a PCRep message if the P bit of the MONITORING object
carried within the corresponding PCMonReq or PCReq message is set. carried within the corresponding PCMonReq or PCReq message is set.
The PROC-TIME object is used to report various processing time The PROC-TIME object is used to report various processing time
related metrics. 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
Current-processing-time field (as explained below) is exclusively Current-processing-time field (as explained below) is exclusively
used for specific monitoring requests and MUST be cleared for general used for specific monitoring requests and MUST be cleared for general
monitoring requests. The algorithms used by a PCE to compute the monitoring requests. The algorithms used by a PCE to compute the
Min, Average, Max and Variance of the processing times are out of the minimum, maximum, average and variance of the processing times are
scope of this document (A PCE may decide to compute the minimum out of the scope of this document (A PCE may decide to compute the
processing time over a period of times, for the last N path minimum processing time over a period of times, for the last N path
computation requests, ...). computation requests, ...).
2) Case of specific monitoring requests 2) Case of specific monitoring requests
In the case of a specific request, the algorithms used by a PCE to In the case of a specific request, the algorithms used by a PCE to
compute the Procesing-time metrics are out of the scope of this compute the Processing-time metrics are out of the scope of this
document but a flag is specified that is used to indicate to the document but a flag is specified that is used to indicate to the
requester whether the processing time value was estimated or requester whether the processing time value was estimated or
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.
skipping to change at page 17, line 16 skipping to change at page 17, line 41
assigned by IANA (recommended value=22) The CONGESTION Object-Type is assigned by IANA (recommended value=22) The CONGESTION Object-Type is
to be assigned by IANA (recommended value=1) to be assigned by IANA (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Congestion Duration | | Flags | Reserved | Congestion Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits - No flag is currently defined: Flags: 8 bits - No flag is currently defined.
Congestion duration - 16 bits: This field indicates in the amount of Congestion duration - 16 bits: This field indicates in the amount of
time in seconds that the responding PCE expects that it may continue time in seconds that the responding PCE expects that it may continue
to be congested from the time that the response message was to be congested from the time that the response message was
generated. The receiver MAY use this value to decide whether or not generated. The receiver MAY use this value to decide whether or not
so send further requests to the same PCE. so send further requests to the same PCE.
It is worth noting that a PCE along a PCE chain involved in the It is worth noting that a PCE along a PCE chain involved in the
monitoring request may decide to learn from the congestion monitoring request may decide to learn from the congestion
information received by one of downstream PCE in the chain. information received by one of downstream PCE in the chain.
skipping to change at page 17, line 45 skipping to change at page 18, line 22
I bit processing: as indicated in section Section 4.1, if a PCE I bit processing: as indicated in section Section 4.1, if a PCE
supports a received PCMonReq message and that message does not supports a received PCMonReq message and that message does not
trigger any policy violation, but the PCE cannot provide any of the trigger any policy violation, but the PCE cannot provide any of the
set of requested performance metrics for unspecified reasons, the PCE set of requested performance metrics for unspecified reasons, the PCE
MUST set the I bit. Once set, the I bit MUST NOT be changed by a MUST set the I bit. Once set, the I bit MUST NOT be changed by a
receiving PCE. receiving PCE.
Upon receiving a PCMonReq message: Upon receiving a PCMonReq message:
1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support 1) As specified in [RFC5440], if the PCE does not support the
the PCMonReq message, the PCE peer MUST send a PCErr message with PCMonReq message, the PCE peer MUST send a PCErr message with Error-
Error-value=2 (capability not supported). According to the procedure value=2 (capability not supported). According to the procedure
defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives defined in section 6.9 of [RFC5440], if a PCC/PCE receives
unrecognized messages at a rate equal of greater than specified rate, unrecognized messages at a rate equal of greater than specified rate,
the PCC/PCE must send a PCEP CLOSE message with close the PCC/PCE must send a PCEP CLOSE message with close value=5
value="Reception of an unacceptable number of unknown PCEP message. "Reception of an unacceptable number of unrecognized PCEP messages".
In this case, the PCC/PCE must also close the TCP session and must In this case, the PCC/PCE must also close the TCP session and must
not send any further PCEP messages on the PCEP session. not send any further PCEP messages on the PCEP session.
2) If the PCE supports the PCMonReq message but the monitoring 2) If the PCE supports the PCMonReq message but the monitoring
request is prohibited by policy, the PCE must follow the procedure request is prohibited by policy, the PCE must follow the procedure
specified in section 5. As pointed out in section 4.3, a PCE may specified in section 5. As pointed out in section 4.3, a PCE may
still partially satisfy a request, leaving out some of the required still partially satisfy a request, leaving out some of the required
data if not allowed by policy. data if not allowed by policy.
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 PCE-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.
Upon receiving a PCReq message that carries a MONITORING and Upon receiving a PCReq message that carries a MONITORING and
potentially other monitoring objects (e.g. PCE-ID object): potentially other monitoring objects (e.g., PCE-ID object):
1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support 1) As specified in [RFC5440], if the PCE does not support (in band)
(in band) monitoring, the PCE peer MUST send a PCErr message with monitoring, the PCE peer MUST send a PCErr message with Error-value=2
Error-value=2 (capability not supported). According to the procedure (capability not supported). According to the procedure defined in
defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages
unrecognized messages at a rate equal of greater than specified rate, at a rate equal of greater than specified rate, the PCC/PCE must send
the PCC/PCE must send a PCEP CLOSE message with close a PCEP CLOSE message with close value=5 "Reception of an unacceptable
value="Reception of an unacceptable number of unknown PCEP message. number of unrecognized PCEP messages". In this case, the PCC/PCE
In this case, the PCC/PCE must also close the TCP session and must must also close the TCP session and must not send any further PCEP
not send any further PCEP messages on the PCEP session. messages on the PCEP session.
2) If the PCE supports the monitoring request but the monitoring 2) If the PCE supports the monitoring request but the monitoring
request is prohibited by policy, the PCE must follow the procedure request is prohibited by policy, the PCE must follow the procedure
specified in section 5. As pointed out in section 4.3, a PCE may specified in section 5. As pointed out in section 4.3, a PCE may
still partially satisfy a request, leaving out some of the required still partially satisfy a request, leaving out some of the required
data if not allowed by policy. data if not allowed by policy.
3) If the PCE supports the monitoring request and that request is not 3) If the PCE supports the monitoring request and that 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 PCReq message the last element of the path computation chain, the PCReq message
(with the MONITORING object and potentially other monitoring objects (with the MONITORING object and potentially other monitoring objects
such as the PCE-ID) is relayed to the next hop PCE: such next-hop may such as the PCE-ID) is relayed to the next hop PCE: such next hop may
either be specified by means of a PCE-ID object present in the PCReq either be specified by means of a PCE-ID object present in the PCReq
message or dynamically determined by means of a procedure outside of message or dynamically determined by means of a procedure outside of
the scope of this document. Conversely, if the PCE is the last PCE the scope of this document. Conversely, if the PCE is the last PCE
of the path computation chain, the PCE originates a PCRep message of the path computation chain, the PCE originates a PCRep message
that contains the requested objects according to the set of requested that contains the requested objects according to the set of requested
PCE states metrics listed in the MONITORING and potentially other PCE states metrics listed in the MONITORING and potentially other
monitoring objects carried in the corresponding PCReq message. monitoring objects carried in the corresponding PCReq message.
Upon receiving a PCMonRep message: upon receiving a PCMonRep message, Upon receiving a PCMonRep message, the PCE processes the request,
the PCE processes the request, adds the relevant objects to the adds the relevant objects to the PCMonRep message and forwards the
PCMonRep message and forwards the PCMonRep message to the upstream PCMonRep message to the upstream requesting PCE or PCC.
requesting PCE or PCC.
Upon receiving a PCRep message that carrries monitoring data, the Upon receiving a PCRep message that carries monitoring data, the
message is processed, additional monitoring data is added according message is processed, additional monitoring data is added according
to this specification and the message is forwarded upstream to the to this specification and the message is forwarded upstream to the
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.
7. Manageability Considerations 7. Manageability Considerations
7.1. Control of Function and Policy 7.1. Control of Function and Policy
It MUST be possible to configure the activation/deactivation of PCEP It MUST be possible to configure the activation/deactivation of PCEP
monitoring on a PCEP speaker. In addition to the parameters already monitoring on a PCEP speaker. In addition to the parameters already
listed in section 8.1 of [I-D.ietf-pce-pcep], a PCEP implementation listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD
SHOULD allow configuring on a PCE whether specific, generic, in band allow configuring on a PCE whether specific, generic, in band and out
and out of band monitoring requests are allowed or not. Also a PCEP of band monitoring requests are allowed or not. Also a PCEP
implementation SHOULD allow configuring on a PCE a list of authorized implementation SHOULD allow configuring on a PCE a list of authorized
state metrics (aliveness, congestion, processing time, etc). This state metrics (aliveness, congestion, processing time, etc). This
may apply to any session the PCEP speaker participates in, to a may apply to any session the PCEP speaker participates in, to a
specific session with a given PCEP peer or to a specific group of specific session with a given PCEP peer or to a specific group of
sessions with a specific group of PCEP peers, for instance the PCEP sessions with a specific group of PCEP peers, for instance the PCEP
peers of a neighbor AS. peers of a neighbor AS.
7.2. Information and Data Models 7.2. Information and Data Models
A new MIB Module may be defined that provides local PCE state A new MIB Module may be defined that provides local PCE state
skipping to change at page 20, line 14 skipping to change at page 20, line 36
7.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
This document provides mechanisms to monitor the liveliness and This document provides mechanisms to monitor the liveliness and
performances of a given PCE chain. performances of a given PCE chain.
7.4. Verify Correct Operations 7.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[I-D.ietf-pce-pcep]. [RFC5440].
7.5. Requirements On Other Protocols 7.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any requirements on Mechanisms defined in this document do not imply any requirements on
other protocols in addition to those already listed in other protocols in addition to those already listed in [RFC5440].
[I-D.ietf-pce-pcep].
7.6. Impact On Network Operations 7.6. Impact On Network Operations
The frequency of PCMonReq messages may impact the operations of PCEs. The frequency of PCMonReq messages may impact the operations of PCEs.
An implementation SHOULD allow a limit to be placed on the rate of An implementation SHOULD allow a limit to be placed on the rate of
PCMonReq messages sent by a PCEP speaker and processed from a peer. PCMonReq messages sent by a PCEP speaker and processed from a peer.
It SHOULD also allow sending a notification when a rate threshold is It SHOULD also allow sending a notification when a rate threshold is
reached. An implementation SHOULD allow handling PCReq messages with reached. An implementation SHOULD allow handling PCReq messages with
a higher priority than PCMonReq messages. An implementation SHOULD a higher priority than PCMonReq messages. An implementation SHOULD
allow the configuration of a second limit for the PCReq message allow the configuration of a second limit for the PCReq message
requesting monitoring data. requesting monitoring data.
8. IANA Considerations 8. IANA Considerations
8.1. New PCEP Message 8.1. New PCEP Message
Each PCEP message has a message type value. 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 [RFC5440]) messages are defined in this
in this document: document:
Value Description Reference Value Description Reference
8 Path Computation Monitoring Request (PCMonReq) This document 8 Path Computation Monitoring Request (PCMonReq) This document
9 Path Computation Monitoring Reply (PCMonRep) This document 9 Path Computation Monitoring Reply (PCMonRep) This document
8.2. New PCEP Objects 8.2. New PCEP Objects
Each PCEP object has an Object-Class and an Object-Type. The Each PCEP object has an Object-Class and an Object-Type. The
following new PCEP objects are defined in this document. following new PCEP objects are defined in this document:
Object-Class Value Name Object-Type Reference Object-Class Value Name Object-Type Reference
19 MONITORING 1 This document 19 MONITORING 1 This document
20 PCE-ID 1: IPv4 addresses This document 20 PCE-ID 1: IPv4 addresses This document
2: IPv6 addresses This document 2: IPv6 addresses This document
21 PROC-TIME 1 This document 21 PROC-TIME 1 This document
22 CONGESTION 1 This document 22 CONGESTION 1 This document
8.3. New Error-Type and Error-Values 8.3. New Error-Values
A registry has been created for the Error-type and Error-value of the A registry was created for the Error-type and Error-value of the PCEP
PCEP Error Object. Error Object.
A new Error-value for the PCErr message Error-types=5 (Policy A new Error-value for the PCErr message Error-types=5 (Policy
Violation) (see [I-D.ietf-pce-pcep]) is defined in this document Violation) (see [RFC5440]) is defined in this document (Error-value
(Error-value to be assigned by IANA). to be assigned by IANA).
Error-Type Meaning Error-value Reference Error-Type Meaning Error-value Reference
5 Policy violation 3 This document 5 Policy violation 3 This document
Monitoring message supported Monitoring message supported
but rejected due to but rejected due to
policy violation policy violation
A new Error-value for the PCErr message Error-types=6 (Mandatory A new Error-value for the PCErr message Error-types=6 (Mandatory
Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document Object missing) (see [RFC5440]) is defined in this document (Error-
(Error-Type and Error-value to be assigned by IANA). Type and Error-value to be assigned by IANA).
Error-type Meaning Error-value Reference Error-type Meaning Error-value Reference
6 Mandatory Object missing 4 This document 6 Mandatory Object missing 4 This document
MONITORING Object missing MONITORING Object missing
8.4. MONITORING Object Flag Field 8.4. MONITORING Object Flag Field
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
the MONITORING object. the MONITORING object.
skipping to change at page 23, line 4 skipping to change at page 23, line 21
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
the CONGESTION object. the CONGESTION object.
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:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability Description o Capability Description
o Defining RFC o Defining RFC
One bit is defined for the CONGESTION Object flag field in this One bit is defined for the CONGESTION Object flag field in this
document: document:
Codespace of the Flag field (CONGESTION Object) Codespace of the Flag field (CONGESTION Object)
Bit Description Reference Bit Description Reference
0-6 Unassigned 0-7 Unassigned
7 Congestion This document
9. Security Considerations 9. Security Considerations
The use of monitoring data can be used for various attacks such as The use of monitoring data can be used for various attacks such as
denail of service attacks (for example by setting the C bit and denial of service attacks (for example by setting the C bit and
congestion during field of the CONGESTION object to stop PCCs from congestion during field of the CONGESTION object to stop PCCs from
using a PCE). Thus it is recommended to make use of the security using a PCE). Thus it is recommended to make use of the security
mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session mechanisms discussed in [RFC5440] to secure a PCEP session
(authenticity, integrity, privacy, DoS protection, etc) to secure the (authenticity, integrity, privacy, DoS protection, etc) to secure the
PCMonReq, PCMonRep messages and PCE state metric objects defined in PCMonReq, PCMonRep messages and PCE state metric objects defined in
this document. An implementation SHOULD allow limiting the rate at this document. An implementation SHOULD allow limiting the rate at
which PCMonReq or PCReq messages carrying monitoring requests which PCMonReq or PCReq messages carrying monitoring requests
received from a specific peer are processed (input shapping), or from received from a specific peer are processed (input shaping), or from
another domain (see also section 7.6). another domain (see also section 7.6).
10. Acknowledgements 10. Acknowledgments
The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe The authors would like to thank Eiji Oki, Mach Chen, Fabien
and Dimitri Papadimitriou for their useful comments. Special thank Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful
to Adrian Farrel for his detailed review. comments. Special thank to Adrian Farrel for his detailed review.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.farrel-rtg-common-bnf] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used Requirement Levels", BCP 14, RFC 2119, March 1997.
in Various Protocol Specifications",
draft-farrel-rtg-common-bnf-07 (work in progress),
November 2008.
[I-D.ietf-pce-of] [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective (PCE) Communication Protocol (PCEP)", RFC 5440,
Functions in the Path Computation Element Communication March 2009.
Protocol (PCEP)", draft-ietf-pce-of-06 (work in progress),
December 2008.
[I-D.ietf-pce-pcep] [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, Used to Form Encoding Rules in Various Routing Protocol
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, Specifications", RFC 5511, April 2009.
"Path Computation Element (PCE) Communication Protocol
(PCEP)", draft-ietf-pce-pcep-19 (work in progress),
November 2008.
[I-D.ietf-pce-pcep-xro] [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Takeda, T., Oki, E., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in Route Exclusions", RFC 5521, April 2009.
progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Requirement Levels", BCP 14, RFC 2119, March 1997. Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pce-brpc]
Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A
Backward Recursive PCE-based Computation (BRPC) Procedure
To Compute Shortest Constrained Inter-domain Traffic
Engineering Label Switched Paths", draft-ietf-pce-brpc-09
(work in progress), April 2008.
[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.
[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.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
 End of changes. 73 change blocks. 
197 lines changed or deleted 204 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/