draft-ietf-pce-monitoring-07.txt   draft-ietf-pce-monitoring-08.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: June 19, 2010 France Telecom Expires: July 24, 2010 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
December 16, 2009 January 20, 2010
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-07.txt draft-ietf-pce-monitoring-08.txt
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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 June 19, 2010. This Internet-Draft will expire on July 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Path Computation Monitoring messages . . . . . . . . . . . . . 6 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) . . . . . . . . . 10
4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 12
4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12
4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 4.2. PCC-ID-REQ Object . . . . . . . . . . . . . . . . . . . . 14
4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15 4.3. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 15
4.4. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 17 4.4. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 16
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 7. Manageability Considerations . . . . . . . . . . . . . . . . . 21
7.2. Information and Data Models . . . . . . . . . . . . . . . 20 7.1. Control of Function and Policy . . . . . . . . . . . . . . 21
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 7.2. Information and Data Models . . . . . . . . . . . . . . . 21
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22
8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 22
8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 22
8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 23
8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 23
8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 23 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 Interior Gateway Protocol (IGP) computational responsibility such Interior Gateway Protocol (IGP)
skipping to change at page 4, line 37 skipping to change at page 4, line 37
term of path computation times are examples of such metrics of term of path computation times are examples of such metrics of
interest. interest.
As defined in [RFC4655], there are circumstances where more than one As defined in [RFC4655], there are circumstances where more than one
PCE are involved in the computation of a TE LSP. A typical example PCE are 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- 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 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 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 and tail-end domain. We call the set of PCEs involved in the
computation of a TE LSP a "path computation chain". As further computation of a TE LSP a "path computation chain". As further
discussed in Section 3.1, the PCE chain may either be static (pre- discussed in Section 3.1, the path computation chain may either be
configured) or dynamically determined during the path computation static (pre-configured) or dynamically determined during the path
process. 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 Backward Recursive PCE- computation chain an example of which is the Backward Recursive PCE-
based Computation (BRPC) procedure defined in [RFC5441], the PCC's based Computation (BRPC) procedure defined in [RFC5441], the PCC's
visibility may be limited to the first PCE involved in the path visibility may be limited to the first PCE involved in the path
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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 request (e.g., check the liveness of a specific path computation
the average processing time computed over the last 5mn period on one chain, collect the average processing time computed over the last 5mn
or more PCEs"). period on one 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 This document specifies procedures and extensions to the Path
skipping to change at page 6, line 19 skipping to change at page 6, line 19
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable length body made of a set of objects that can followed by a variable length body made of a set of objects that can
either be mandatory or optional. As a reminder, an object is said to either be mandatory or optional. As a reminder, an object is said to
be mandatory in a PCEP message when the object must be included for be mandatory in a PCEP message when the object must be included for
the message to be considered as valid. The P flag (defined in the message to be considered as valid. The P flag (defined in
[RFC5440]) is located in the common header of each PCEP object and [RFC5440]) is located in the common header of each PCEP object and
can be set by a PCEP peer to require a PCE to take into account the can be set by a PCEP peer to require a PCE to take into account the
related information during the path computation. Because the P flag related information during the path computation. Because the P flag
exclusively relates to a path computation request, it MUST be cleared exclusively relates to a path computation request, it MUST be cleared
in the two PCEP messages (PCMonReq and PCMonRep message). in the two PCEP messages (PCMonReq 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 7, line 8 skipping to change at page 7, line 8
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 a PCErr MONITORING object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error- message with Error-type=6 (Mandatory Object missing) and Error-
value=4 (MONITORING Object missing). Other objects are optional. value=4 (MONITORING Object missing). Other objects are optional.
Format of a PCMonReq message (out of band request): Format of a PCMonReq message (out of band request):
<PCMonReq Message>::= <Common Header> <PCMonReq Message>::= <Common Header>
<MONITORING> <MONITORING>
<PCC-ID-REQ>
[<pce-list>] [<pce-list>]
[<svec-list>] [<svec-list>]
[<request-list>] [<request-list>]
where: where:
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC> <svec-list>::=<SVEC>
[<OF>] [<OF>]
[<svec-list>] [<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> <END-POINTS>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>] [<RRO>]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
[<XRO>] [<XRO>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
<pce-list>::=<PCE-ID>[<pce-list>]
Format of a PCReq message with monitoring data requested (in band Format of a PCReq message with monitoring data requested (in band
request): request):
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<MONITORING> <MONITORING>
<PCC-ID-REQ>
[<pce-list>] [<pce-list>]
[<svec-list>] [<svec-list>]
<request-list> <request-list>
where: where:
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> <END-POINTS>
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<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>]
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 [RFC5440]. The XRO object is BALANCING objects are defined in [RFC5440]. The XRO object is
defined in [RFC5521] and the OF object is defined in [RFC5541]. defined in [RFC5521] and the OF object is defined in [RFC5541]. The
PCC-ID-REQ object is defined in Section 4.2.
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.3.) according to policy specified on the
by the path computation procedure. For example, if the BRPC PCC or may alternatively be determined by the path computation
procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the procedure. For example, if the BRPC procedure ([RFC5441]) is used to
PCE chain may be determined dynamically. In that case, the PCC sends compute an inter-domain TE LSP, the path computation chain may be
a PCMonReq message that contains the PCEP objects that characterize determined dynamically. In that case, the PCC sends a PCMonReq
the TE LSP attributes along with the MONITORING object (see message that contains the PCEP objects that characterize the TE LSP
Section 4.1) that lists the set of metrics of interest. attributes along with the MONITORING object (see Section 4.1) that
lists the set of metrics of interest. if a list of PCE is present in
the monitoring request, it takes precedence over mechanisms used to
dynamicaly determine the path computation chain. If a PCE receives a
monitoring request that specifies a next hop PCE in the PCE list that
is unreachable, the request MUST be silently discarded.
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 [RFC5440] 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,
skipping to change at page 10, line 16 skipping to change at page 10, line 25
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 a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING
Object missing). Object missing).
Other objects are optional. Other objects are optional.
Format of a PCMonRep (out of band request): Format of a PCMonRep (out of band request):
<PCMonRep Message>::= <Common Header> <PCMonRep Message>::= <Common Header>
<MONITORING> <MONITORING>
<PCC-ID-REQ>
[<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>]
<metric-pce>::=<PCE-ID> <metric-pce>::=<PCE-ID>
[<PROC-TIME>] [<PROC-TIME>]
[<OVERLOAD>] [<OVERLOAD>]
Format of a PCRep message with monitoring data (in band): Format of a PCRep message with monitoring data (in band):
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
where: where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
<MONITORING> <MONITORING>
<PCC-ID-REQ>
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
[<path-list>] [<path-list>]
[<metric-pce-list>] [<metric-pce-list>]
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list> <path>::= <ERO><attribute-list>
where: where:
skipping to change at page 11, line 38 skipping to change at page 11, line 39
[<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>]
[<OVERLOAD>] [<OVERLOAD>]
The RP and the NO-PATH objects are defined in [RFC5440]. The RP and the NO-PATH objects are defined in [RFC5440]. The PCC-ID-
REQ object is defined in Section 4.2.
If the path computation chain has been statically specified in the
corresponding monitoring request using the series of a series of
PCE-ID objects defined in Section 4.3 the monitoring request MUST use
the same path computation chain (using the pce-list but in the
reverse order).
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 [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document SHOULD always be set to 0 on PCEP objects defined in this document SHOULD always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST be ignored on receipt since these 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
skipping to change at page 14, line 4 skipping to change at page 14, line 6
be inserted in the corresponding PCMonRep or PCRep message. The C be inserted in the corresponding PCMonRep or PCRep message. The C
bit MUST always be ignored in a PCMonRep or PCRep message. bit MUST always be ignored in a PCMonRep or PCRep message.
I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message
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 PCC-REQ-ID identifying the requesting PCC uniquely
request context. The monitoring-id-number MUST start at a non-zero identifies the monitoring request context. The monitoring-id-number
value and MUST be incremented each time a new monitoring request is MUST start at a non-zero value and MUST be incremented each time a
sent to a PCE. Each increment SHOULD have a value of 1 and may cause new monitoring request is sent to a PCE. Each increment SHOULD have
a wrap back to zero. If no reply to a monitoring request is received a value of 1 and may cause a wrap back to zero. If no reply to a
from the PCE, and the PCC wishes to resend its path computation monitoring request is received from the PCE, and the PCC wishes to
monitoring request, the same monitoring-id-number MUST be used. resend its path computation monitoring request, the same monitoring-
Conversely, a different monitoring-id-number MUST be used for id-number MUST be used. Conversely, a different monitoring-id-number
different requests sent to a PCE. The path computation monitoring MUST be used for different requests sent to a PCE. A PCEP
reply is unambiguously identified by the monitoring-id-number and the implementation SHOULD checkpoint the Monitoring-id-number of pending
PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint monitoring requests in case of restart thus avoiding the re-use of a
the Monitoring-id-number of pending monitoring requests in case of Monitoring-id-number of an in-process monitoring request.
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 and ignored on reception. transmission and ignored on reception.
No optional TLVs are currently defined. No optional TLVs are currently defined.
4.2. PCE-ID Object 4.2. PCC-ID-REQ Object
The PCE-ID Object is used to specify a PCE's IP address. The PCC-ID-REQ Object is used to specify the IP address of the
requesting PCC.
The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message
to specify the IP address of the requesting PCC.
Two PCC-ID-REQ objects (for IPv4 and IPv6) are defined. PCC-ID-REQ
Object-Class is to be assigned by IANA (recommended value=20) PCC-ID-
REQ Object-Type is to be assigned by IANA (recommended value=1 for
IPv4 and 2 for IPv6)
The format of the PCE-ID-REQ Object is as follows:
The format of the PCC-ID-REQ object body for IPv4 and IPv6 are as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4
and 16 octets for IPv6.
4.3. PCE-ID Object
The PCE-ID Object is used to specify a PCE's IP address. The PCE-ID
object can either be used to specifyt the list of PCE for which
monitoring data is requested and to specify the IP address of the
requesting PCC.
A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq A set of PCE-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 PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object-
Class is to be assigned by IANA (recommended value=20) PCE-ID Object- Class is to be assigned by IANA (recommended value=21) PCE-ID Object-
Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2
for IPv6) for IPv6)
The format of the PCE-ID Object is as follows: The format of the PCE-ID Object is as follows:
The format of the PCE-ID object body for IPv4 and IPv6 are as The format of the PCE-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
skipping to change at page 15, line 31 skipping to change at page 16, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16
octets for IPv6. octets for IPv6.
When a dynamic discovery mechanism is used for PCE discovery, a PCE When a dynamic discovery mechanism is used for PCE discovery, a PCE
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.4. 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
skipping to change at page 16, line 25 skipping to change at page 17, line 25
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 reports the actual PCReq message), the PROC-TIME object always reports the actual
processing time for that request and thus the E bit 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=22)
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 |E| | Reserved | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 24 skipping to change at page 18, line 24
Max-processing-time: This field indicates in milliseconds the maximum Max-processing-time: This field indicates in milliseconds the maximum
processing time. processing time.
Average-processing-time: This field indicates in milliseconds the Average-processing-time: This field indicates in milliseconds the
average processing time. average processing time.
Variance-processing-time: This field indicates in milliseconds the Variance-processing-time: This field indicates in milliseconds the
variance of the processing times. variance of the processing times.
4.4. OVERLOAD Object Since PCC may potentially use monitoring metrics as input to their
PCE selection, it MAY be required to normalize how time metrics
(along with others metrics described in further revision of this
document) are computed to ensure consistency between the monitoring
metrics computed by a set of PCEs.
4.5. OVERLOAD Object
The OVERLOAD object is used to report a PCE processing congestion The OVERLOAD object is used to report a PCE processing congestion
state. Note that "overload" as indicated by this object refers to state. Note that "overload" as indicated by this object refers to
the processing state of the PCE and its ability to handle new PCEP the processing state of the PCE and its ability to handle new PCEP
requests. A PCE is overloaded when it has a backlog of PCEP requests requests. A PCE is overloaded when it has a backlog of PCEP requests
such that it cannot immediately start to process a new request thus such that it cannot immediately start to process a new request thus
leading to waiting times. The overload duration is quantified as leading to waiting times. The overload duration is quantified as
being the (estimated) time until the PCE expects to be able to being the (estimated) time until the PCE expects to be able to
immediately process a new PCEP request. immediately process a new PCEP request.
The OVERLOAD object MUST be present within a PCMonRep or a PCRep The OVERLOAD 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 and the PCE is corresponding PCMonReq or PCReq message is set and the PCE is
experiencing a congested state. The OVERLOAD Object-Class is to be experiencing a congested state. The OVERLOAD Object-Class is to be
assigned by IANA (recommended value=22). The OVERLOAD Object-Type is assigned by IANA (recommended value=23). The OVERLOAD 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 | Overload Duration | | Flags | Reserved | Overload Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits - No flag is currently defined. Flags: 8 bits - No flag is currently defined.
Overload duration - 16 bits: This field indicates in the amount of Overload duration - 16 bits: This field indicates in the amount of
skipping to change at page 18, line 9 skipping to change at page 19, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits - No flag is currently defined. Flags: 8 bits - No flag is currently defined.
Overload duration - 16 bits: This field indicates in the amount of Overload 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 overloaded from the time that the response message was to be overloaded 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 path computation chain involved
monitoring request may decide to learn from the overload information in the monitoring request may decide to learn from the overload
received by one of downstream PCE in the chain. information received by one of downstream PCE in the chain.
5. Policy 5. 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).
6. Elements of Procedure 6. Elements of Procedure
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
skipping to change at page 20, line 7 skipping to change at page 21, line 17
Upon receiving a PCMonRep message, the PCE processes the request, Upon receiving a PCMonRep message, the PCE processes the request,
adds the relevant objects to the PCMonRep message and forwards the adds the relevant objects to the PCMonRep message and forwards the
PCMonRep message to the upstream requesting PCE or PCC. PCMonRep message to the upstream requesting PCE or PCC.
Upon receiving a PCRep message that carries 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
related to more than one destinations may involve a set of path
computation chains. In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation
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 [RFC5440], a PCEP implementation SHOULD listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD
allow configuring on a PCE whether specific, generic, in band and out allow configuring on a PCE whether specific, generic, in band 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
skipping to change at page 20, line 38 skipping to change at page 21, line 42
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
metrics, as well as state metrics of other PCEs gathered using metrics, as well as state metrics of other PCEs gathered using
mechanisms defined in this document. mechanisms defined in this document.
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 path computation 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
[RFC5440]. [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
skipping to change at page 21, line 38 skipping to change at page 23, line 9
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 PCC-REQ-ID 1: IPv4 addresses This document
2: IPv6 addresses
21 PCE-ID 1: IPv4 addresses This document
2: IPv6 addresses This document 2: IPv6 addresses This document
21 PROC-TIME 1 This document 22 PROC-TIME 1 This document
22 OVERLOAD 1 This document 23 OVERLOAD 1 This document
8.3. New Error-Values 8.3. New Error-Values
A registry was created for the Error-type and Error-value of the PCEP A registry was created for the Error-type and Error-value of the 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 [RFC5440]) is defined in this document (Error-value Violation) (see [RFC5440]) is defined in this document (Error-value
to be assigned by IANA). to be assigned by IANA).
skipping to change at page 24, line 6 skipping to change at page 25, line 29
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
denial of service attacks (for example by setting the C bit and denial of service attacks (for example by setting the C bit and
overload duration field of the OVERLOAD object to stop PCCs from overload duration field of the OVERLOAD 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 [RFC5440] 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 shaping), or from received from a specific peer are processed (input shaping) as
another domain (see also section 7.6). discussed in section 10.7.2 of [RFC5440], or from another domain (see
also section 7.6).
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Eiji Oki, Mach Chen, Fabien The authors would like to thank Eiji Oki, Mach Chen, Fabien
Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful
comments. Special thank 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
 End of changes. 37 change blocks. 
89 lines changed or deleted 147 lines changed or added

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