draft-ietf-pce-monitoring-08.txt   draft-ietf-pce-monitoring-09.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track JL. Le Roux Intended status: Standards Track JL. Le Roux
Expires: July 24, 2010 France Telecom Expires: September 22, 2010 France Telecom
Y. Ikejiri Y. Ikejiri
NTT Communications Corporation NTT Communications Corporation
January 20, 2010 March 21, 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-08.txt draft-ietf-pce-monitoring-09.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 July 24, 2010. This Internet-Draft will expire on September 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18 4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
7. Manageability Considerations . . . . . . . . . . . . . . . . . 21 7. Manageability Considerations . . . . . . . . . . . . . . . . . 21
7.1. Control of Function and Policy . . . . . . . . . . . . . . 21 7.1. Control of Function and Policy . . . . . . . . . . . . . . 21
7.2. Information and Data Models . . . . . . . . . . . . . . . 21 7.2. Information and Data Models . . . . . . . . . . . . . . . 21
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Guidelines to Avoid Overload Thrashing . . . . . . . . . . . . 22
8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 22 9.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 23
8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 23 9.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 23
8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 23 9.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 24
8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 24 9.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 24
8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 24 9.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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 22, line 21 skipping to change at page 22, line 21
The frequency of PCMonReq messages may impact the operations of PCEs. The frequency of PCMonReq messages may impact the operations of PCEs.
An implementation SHOULD allow a limit to be placed on the rate of An implementation SHOULD allow a limit to be placed on the rate of
PCMonReq messages sent by a PCEP speaker and processed from a peer. PCMonReq messages sent by a PCEP speaker and processed from a peer.
It SHOULD also allow sending a notification when a rate threshold is It SHOULD also allow sending a notification when a rate threshold is
reached. An implementation SHOULD allow handling PCReq messages with reached. An implementation SHOULD allow handling PCReq messages with
a higher priority than PCMonReq messages. An implementation SHOULD a higher priority than PCMonReq messages. An implementation SHOULD
allow the configuration of a second limit for the PCReq message allow the configuration of a second limit for the PCReq message
requesting monitoring data. requesting monitoring data.
8. IANA Considerations 8. Guidelines to Avoid Overload Thrashing
8.1. New PCEP Message An important concern while processing overload information is to
prevent the overload condition on one PCE simply being moved to
another PCE. Indeed, there is a risk that the reaction to an
indication of overload will act to increase the amount of overload
within the network. Furthermore, this may lead to oscillations
between PCEs if the overload information is not handled properly.
This section presents some brief guidance on how a PCC (which term
includes a PCE making requests of another PCE) should react when it
receives an indication that a PCE is overloaded.
When an overload indication is received (on a PCRep message or on a
PCMonRep message), it identifies that new PCReq messages sent to the
PCE might be subject to a delay equal to the value in the Overload
Duration field (when present).
It also indicates that PCReq messages already queued at the PCE might
be subject to a delay. The PCC must decide how to handle new PCReq
messages, and what to do about PCReq messages already queued at the
PCE.
It is RECOMMENDED that a PCC does not cancel a queued PCReq and re-
issue it to another PCE because of the PCE being overloaded.
Such behavior is likely to result in overload thrashing as multiple
PCCs move the PCE queue to another PCE. This would simply introduce
additional delay in the processing of all requests. A PCC MAY choose
to cancel a queued PCE request if it is willing to sacrifice the
request, maybe re-issuing it later (after the overload condition has
been determined to have cleared by use of a PCMonReq/Rep exchange).
It is then RECOMMENDED to send the cancellation request with a higher
priority in order for the PCE overloaded PCE to detect the request
cancellation before processing the related request.
A PCC that is aware of PCE overload at one PCE MAY select a different
PCE to service its next PCReq message. In doing so it is RECOMMENDED
that the PCC consider whether the other PCE is overloaded or might be
likely to become overloaded by other PCCs similarly directing new
PCReq messages.
Furthermore, should the second PCE be also overloaded, it is
RECOMMENDED not to make any attempt to switch back to the other PCE
without knowing that the first PCE is no longer overloaded.
9. IANA Considerations
9.1. New PCEP Message
Each PCEP message has a message type value. Each PCEP message has a message type value.
Two new PCEP (specified in [RFC5440]) messages are defined in this Two new PCEP (specified in [RFC5440]) messages are defined in this
document: document:
Value Description Reference Value Description Reference
8 Path Computation Monitoring Request (PCMonReq) This document 8 Path Computation Monitoring Request (PCMonReq) This document
9 Path Computation Monitoring Reply (PCMonRep) This document 9 Path Computation Monitoring Reply (PCMonRep) This document
8.2. New PCEP Objects 9.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 PCC-REQ-ID 1: IPv4 addresses This document 20 PCC-REQ-ID 1: IPv4 addresses This document
2: IPv6 addresses 2: IPv6 addresses
21 PCE-ID 1: IPv4 addresses This document 21 PCE-ID 1: IPv4 addresses This document
2: IPv6 addresses This document 2: IPv6 addresses This document
22 PROC-TIME 1 This document 22 PROC-TIME 1 This document
23 OVERLOAD 1 This document 23 OVERLOAD 1 This document
8.3. New Error-Values 9.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).
Error-Type Meaning Error-value Reference Error-Type Meaning Error-value Reference
5 Policy violation 3 This document 5 Policy violation 3 This document
skipping to change at page 23, line 42 skipping to change at page 24, line 42
policy violation policy violation
A new Error-value for the PCErr message Error-types=6 (Mandatory A new Error-value for the PCErr message Error-types=6 (Mandatory
Object missing) (see [RFC5440]) is defined in this document (Error- Object missing) (see [RFC5440]) is defined in this document (Error-
Type and Error-value to be assigned by IANA). Type and Error-value to be assigned by IANA).
Error-type Meaning Error-value Reference Error-type Meaning Error-value Reference
6 Mandatory Object missing 4 This document 6 Mandatory Object missing 4 This document
MONITORING Object missing MONITORING Object missing
8.4. MONITORING Object Flag Field 9.4. MONITORING Object Flag Field
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
the MONITORING object. the MONITORING object.
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
skipping to change at page 24, line 20 skipping to change at page 25, line 20
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 Overload 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 9.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
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
skipping to change at page 24, line 42 skipping to change at page 25, line 42
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. OVERLOAD Object Flag field 9.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 OVERLOAD 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 OVERLOAD 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 (OVERLOAD Object) Codespace of the Flag field (OVERLOAD Object)
Bit Description Reference Bit Description Reference
0-7 Unassigned 0-7 Unassigned
9. Security Considerations 10. 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
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) as received from a specific peer are processed (input shaping) as
discussed in section 10.7.2 of [RFC5440], or from another domain (see discussed in section 10.7.2 of [RFC5440], or from another domain (see
also section 7.6). also section 7.6).
10. Acknowledgments 11. 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 12. References
11.1. Normative References 12.1. Normative References
[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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009. Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009. Communication Protocol (PCEP)", RFC 5541, June 2009.
11.2. Informative References 12.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
 End of changes. 17 change blocks. 
29 lines changed or deleted 77 lines changed or added

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