draft-ietf-pce-monitoring-06.txt   draft-ietf-pce-monitoring-07.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 17, 2010 France Telecom Expires: June 19, 2010 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
December 14, 2009 December 16, 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-06.txt draft-ietf-pce-monitoring-07.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 17, 2010. This Internet-Draft will expire on June 19, 2010.
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
(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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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) . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 15 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15
4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17 4.4. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 17
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18
7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20
7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20
7.2. Information and Data Models . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . 21 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21
8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21
8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21
8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 23 8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Path Computation Element (PCE) based architecture has been The Path Computation Element (PCE) based architecture has been
skipping to change at page 10, line 25 skipping to change at page 10, line 25
<MONITORING> <MONITORING>
[<RP>] [<RP>]
[<metric-pce-list>] [<metric-pce-list>]
where: where:
<metric-pce-list>::=<metric-pce>[<metric-pce-list>] <metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID> <metric-pce>::=<PCE-ID>
[<PROC-TIME>] [<PROC-TIME>]
[<CONGESTION>] [<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>
skipping to change at page 11, line 36 skipping to change at page 11, line 36
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<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>] [<OVERLOAD>]
The RP and the NO-PATH objects are defined in [RFC5440]. 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 [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.
skipping to change at page 13, line 38 skipping to change at page 13, line 38
performance metric is specific, the G bit MUST be cleared. The G bit performance metric is specific, the G bit MUST be cleared. The G bit
MUST always be ignored in a PCMonRep or PCRep message. MUST always be ignored in a PCMonRep or PCRep message.
P (Processing Time) - 1 bit: the P bit of the MONITORING object P (Processing Time) - 1 bit: the P bit of the MONITORING object
carried in a PCMonReq or a PCReq message is set to indicate that the carried in a PCMonReq or a PCReq message is set to indicate that the
processing times is a metric of interest. If allowed by policy, a processing times is a metric of interest. If allowed by policy, a
PROC-TIME object MUST be inserted in the corresponding PCMonRep or PROC-TIME object MUST be inserted in the corresponding PCMonRep or
PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or
PCRep message. PCRep message.
C (Congestion) - 1 bit: The C bit of the MONITORING object carried in C (Overload) - 1 bit: The C bit of the MONITORING object carried in a
a PCMonReq or a PCReq message is set to indicate that the congestion PCMonReq or a PCReq message is set to indicate that the overload
status is a metric of interest, in which case a CONGESTION object status is a metric of interest, in which case a OVERLOAD object MUST
MUST be inserted in the corresponding PCMonRep or PCRep message. The be inserted in the corresponding PCMonRep or PCRep message. The C
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 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
skipping to change at page 17, line 24 skipping to change at page 17, 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. CONGESTION Object 4.4. OVERLOAD Object
The CONGESTION object is used to report a PCE processing congestion The OVERLOAD object is used to report a PCE processing congestion
state. Note that "congestion" 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 congested 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 congestion 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 CONGESTION 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 CONGESTION Object-Class is to be experiencing a congested state. The OVERLOAD Object-Class is to be
assigned by IANA (recommended value=22). The CONGESTION Object-Type assigned by IANA (recommended value=22). The OVERLOAD Object-Type is
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 | Overload 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 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 congested 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 PCE chain involved in the
monitoring request may decide to learn from the congestion monitoring request may decide to learn from the overload information
information received by one of downstream PCE in the chain. 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 23 skipping to change at page 20, line 23
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
state metrics (aliveness, congestion, processing time, etc). This state metrics (aliveness, overload, processing time, etc). This may
may apply to any session the PCEP speaker participates in, to a apply to any session the PCEP speaker participates in, to a specific
specific session with a given PCEP peer or to a specific group of session with a given PCEP peer or to a specific group of sessions
sessions with a specific group of PCEP peers, for instance the PCEP with a specific group of PCEP peers, for instance the PCEP peers of a
peers of a neighbor AS. 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
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
skipping to change at page 21, line 43 skipping to change at page 21, line 43
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 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 22, line 41 skipping to change at page 22, line 41
o Defining RFC o Defining RFC
Several bits are defined for the MONITORING Object flag field in this Several bits are defined for the MONITORING Object flag field in this
document: document:
Codespace of the Flag field (MONITORING Object) Codespace of the Flag field (MONITORING Object)
Bit Description Reference Bit Description Reference
0-18 Unassigned 0-18 Unassigned
19 Incomplete This document 19 Incomplete This document
20 Congestion This document 20 Overload This document
21 Processing Time This document 21 Processing Time This document
22 General This document 22 General This document
23 Liveness This document 23 Liveness This document
8.5. PROC-TIME Object Flag Field 8.5. PROC-TIME 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 PROC-TIME object. the PROC-TIME object.
New bit numbers may be allocated only by an IETF review. Each bit New bit numbers may be allocated only by an IETF review. Each bit
skipping to change at page 23, line 20 skipping to change at page 23, line 20
o Defining RFC o Defining RFC
One bit is defined for the PROC-TIME Object flag field in this One bit is defined for the PROC-TIME Object flag field in this
document: document:
Codespace of the Flag field (PROC-TIME Object) Codespace of the Flag field (PROC-TIME Object)
Bit Description Reference Bit Description Reference
0-14 Unassigned 0-14 Unassigned
15 Estimated This document 15 Estimated This document
8.6. CONGESTION Object Flag field 8.6. OVERLOAD 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 CONGESTION object. the OVERLOAD object.
New bit numbers may be allocated only by an IETF review. Each bit New bit numbers may be allocated only by an IETF review. Each bit
should be tracked with the following qualities: 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
No Flag are currently defined for the CONGESTION Object flag field in No Flag are currently defined for the OVERLOAD Object flag field in
this document. this document.
Codespace of the Flag field (CONGESTION Object) Codespace of the Flag field (OVERLOAD Object)
Bit Description Reference Bit Description Reference
0-7 Unassigned 0-7 Unassigned
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
denial 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 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), or from
another domain (see also section 7.6). another domain (see also section 7.6).
10. Acknowledgments 10. Acknowledgments
 End of changes. 27 change blocks. 
39 lines changed or deleted 39 lines changed or added

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