draft-ietf-pce-monitoring-02.txt   draft-ietf-pce-monitoring-03.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: March 6, 2009 France Telecom Expires: May 6, 2009 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
September 2, 2008 November 2, 2008
A set of monitoring tools for Path Computation Element based A set of monitoring tools for Path Computation Element based
Architecture Architecture
draft-ietf-pce-monitoring-02.txt draft-ietf-pce-monitoring-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6, 2009. This Internet-Draft will expire on May 6, 2009.
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 33 skipping to change at page 2, line 33
3.1. Path Computation Monitoring Request message (PCMonReq) . . 5 3.1. Path Computation Monitoring Request message (PCMonReq) . . 5
3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 7 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 7
4. Path Computation Monitoring Objects . . . . . . . . . . . . . 8 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 8
4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 8 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 8
4.2. PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10 4.2. PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10
4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11
4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 13 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 13
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14
7. Manageability Considerations . . . . . . . . . . . . . . . . . 15 7. Manageability Considerations . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. Control of Function and Policy . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.2. Information and Data Models . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
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 as IGP areas and Autonomous
skipping to change at page 8, line 17 skipping to change at page 8, line 17
<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>]
[<TIME-STAMP>]
[<CONGESTION>] [<CONGESTION>]
4. Path Computation Monitoring Objects 4. Path Computation Monitoring Objects
The PCEP objects defined in the document are compliant with the PCEP The PCEP objects defined in the document are compliant with the PCEP
object format defined in [I-D.ietf-pce-pcep], with the P flag and the object format defined in [I-D.ietf-pce-pcep], with the P flag and the
I flag cleared since these flags are exclusively related to path I flag cleared since these flags are exclusively related to path
computation requests. 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 8, line 40 skipping to change at page 8, line 39
case of "out of band" monitoring requests, the objects defined in case of "out of band" monitoring requests, the objects defined in
this section are carried within PCMonReq and PCMonRep messages. this section are carried within PCMonReq and PCMonRep messages.
Conversely, if the PCC requests the computation of the TE LSP in Conversely, if the PCC requests the computation of the TE LSP in
addition to gathering PCE state metrics (i.e. "In band" requests), addition to gathering PCE state metrics (i.e. "In band" requests),
these objects are carried within PCReq and PCRep messages. these objects are carried within PCReq and PCRep messages.
4.1. MONITORING Object 4.1. MONITORING Object
The MONITORING object MUST be present within PCMonReq and PCMonRep The MONITORING object MUST be present within PCMonReq and PCMonRep
messages ("out of band" monitoring requests) and MAY be carried messages ("out of band" monitoring requests) and MAY be carried
within PCRep and PCReq messages ("in band" monitoring requests). The
MONITORING object MUST be present within PCMonReq and PCMonRep
messages ("out of band" monitoring requests) and MAY be carried
within PCERep and PCReq messages ("in band" monitoring requests). within PCERep and PCReq messages ("in band" monitoring requests).
There 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 if more than one instance of the MONITORING object is present, the
recipient MUST process the first instance and MUST ignore other recipient MUST process the first instance and MUST ignore other
instances. 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
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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
processing-time field (as explained below) is exclusively used for Current-processing-time field (as explained below) is exclusively
specific monitoring requests and MUST be cleared for general used for specific monitoring requests and MUST be cleared for general
monitoring requests. The algorithm(s) used by a PCE to compute the monitoring requests. The algorithm(s) used by a PCE to compute the
Min, Average, Max and Variance of the processing times are out of the Min, Average, Max and Variance of the processing times are out of the
scope of this document (A PCE may decide to compute the minimum scope of this document (A PCE may decide to compute the minimum
processing time over a period of times, for the last N path 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 algorithm(s) used by a PCE to In the case of a specific request, the algorithm(s) used by a PCE to
compute the Procesing-time metrics are out of the scope of this compute the Procesing-time metrics are out of the scope of this
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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
To be addressed in a further revision of this document. 7.1. Control of Function and Policy
It MUST be possible to configure the activation/deactivation of PCEP
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
SHOULD allow configuring on a PCE whether specific, generic, in-band
and out-of-band monitoring requests are allowed or not. Also a PCEP
implementation SHOULD allow configuring on a PCE a list of authorized
state metrics (aliveness, congestion, processing time, etc). This
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
sessions with a specific group of PCEP peers, for instance the PCEP
peers of a neighbor AS.
7.2. Information and Data Models
A new MIB Module MAY be defined that provides local PCE state
metrics, as well as state metrics of other PCEs gathered using
mechanisms defined in this document.
7.3. Liveness Detection and Monitoring
This document provides mechanisms to monitor the liveliness and
performances of a given PCE chain.
7.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[I-D.ietf-pce-pcep].
7.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any requirements on
other protocols in addition to those already listed in
[I-D.ietf-pce-pcep].
7.6. Impact On Network Operations
The frequency of PCMonReq messages may impact the operations of PCEs.
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.
It SHOULD also allow sending a notification when a rate threshold is
reached. An implementation SHOULD allow handling PCReq messages with
a higher priority than PCMonReq messages.
8. IANA Considerations 8. IANA Considerations
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 [I-D.ietf-pce-pcep]) messages are defined
in this document: in this document:
Value Meaning Value Meaning
8 Path Computation Monitoring Request (PCMonReq) 8 Path Computation Monitoring Request (PCMonReq)
skipping to change at page 16, line 22 skipping to change at page 17, line 22
Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document
(Error-Type and Error-value to be assigned by IANA). (Error-Type and Error-value to be assigned by IANA).
Error-type Meaning Error-type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=4 [This document] Error-value=4 [This document]
MONITORING Object missing MONITORING Object missing
9. Security Considerations 9. Security Considerations
To be addressed in a further revision of this document. Mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session
(authenticity, integrity, privacy, DoS protection, etc) can be used
to secure the PCMonReq, PCMonRep messages and PCE state metric
objects defined in this document as well. A PCE may face a denial of
service attack with PCMonReq messages. An implementation SHOULD
allow limiting the rate at which PCMonReq messages received from a
specific peer are processed (input shapping), or from another domain
(see also section 7.6).
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Eiji Oki, Mach Chen and Dimitri The authors would like to thank Eiji Oki, Mach Chen and Dimitri
Papadimitriou for their useful comments. Special thank to Adrian Papadimitriou for their useful comments. Special thank to Adrian
Farrel for his detailed review. Farrel for his detailed review.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-pce-pcep] [I-D.ietf-pce-pcep]
Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol "Path Computation Element (PCE) Communication Protocol
(PCEP)", draft-ietf-pce-pcep-14 (work in progress), (PCEP)", draft-ietf-pce-pcep-18 (work in progress),
September 2008. November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pce-brpc] [I-D.ietf-pce-brpc]
skipping to change at page 17, line 23 skipping to change at page 18, line 26
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS Protocol Extensions for Path Computation Roux, J., "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-08 (work in progress), draft-ietf-pce-disco-proto-isis-08 (work in progress),
September 2007. September 2007.
[I-D.ietf-pce-of] [I-D.ietf-pce-of]
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
Functions in the Path Computation Element Communication Functions in the Path Computation Element Communication
Protocol (PCEP)", draft-ietf-pce-of-04 (work in progress), Protocol (PCEP)", draft-ietf-pce-of-05 (work in progress),
August 2008. September 2008.
[I-D.ietf-pce-pcep-xro] [I-D.ietf-pce-pcep-xro]
Takeda, T., Oki, E., 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", draft-ietf-pce-pcep-xro-06 (work in
progress), July 2008. progress), July 2008.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
 End of changes. 12 change blocks. 
24 lines changed or deleted 77 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/