A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture :: RFC5886
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5886 Cisco Systems, Inc.
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 France Telecom
Y. Ikejiri
NTT Communications Corporation
June 2010
A Set of Monitoring Tools for
Path Computation Element (PCE)-Based Architecture
Abstract
A Path Computation Element (PCE)-based architecture has been
specified for the computation of Traffic Engineering (TE) Label
Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks in the context of single or
multiple domains (where a domain refers to a collection of network
elements within a common sphere of address management or path
computational responsibility such as Interior Gateway Protocol (IGP)
areas and Autonomous Systems). Path Computation Clients (PCCs) send
computation requests to PCEs, and these may forward the requests to
and cooperate with other PCEs forming a "path computation chain".
In PCE-based environments, it is thus critical to monitor the state
of the path computation chain for troubleshooting and performance
monitoring purposes: liveness of each element (PCE) involved in the
PCE chain and detection of potential resource contention states and
statistics in terms of path computation times are examples of such
metrics of interest. This document specifies procedures and
extensions to the Path Computation Element Protocol (PCEP) in order
to gather such information.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5886.
Vasseur, et al. Standards Track [Page 1]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Vasseur, et al. Standards Track [Page 2]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
Table of Contents
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Path Computation Monitoring Messages ............................6
3.1. Path Computation Monitoring Request (PCMonReq) Message .....6
3.2. Path Monitoring Reply (PCMonRep) Message ...................9
4. Path Computation Monitoring Objects ............................11
4.1. MONITORING Object .........................................11
4.2. PCC-ID-REQ Object .........................................13
4.3. PCE-ID Object .............................................14
4.4. PROC-TIME Object ..........................................15
4.5. OVERLOAD Object ...........................................17
5. Policy .........................................................18
6. Elements of Procedure ..........................................18
7. Manageability Considerations ...................................20
7.1. Control of Function and Policy ............................20
7.2. Information and Data Models ...............................20
7.3. Liveness Detection and Monitoring .........................20
7.4. Verify Correct Operations .................................20
7.5. Requirements on Other Protocols ...........................21
7.6. Impact on Network Operations ..............................21
8. Guidelines to Avoid Overload Thrashing .........................21
9. IANA Considerations ............................................22
9.1. New PCEP Message ..........................................22
9.2. New PCEP Objects ..........................................22
9.3. New Error-Values ..........................................23
9.4. MONITORING Object Flag Field ..............................23
9.5. PROC-TIME Object Flag Field ...............................24
9.6. OVERLOAD Object Flag Field ................................24
10. Security Considerations .......................................24
11. Acknowledgments ...............................................25
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................25
Vasseur, et al. Standards Track [Page 3]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
1. Introduction
The Path Computation Element (PCE)-based architecture has been
specified in [RFC4655] for the computation of Traffic Engineering
(TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks in the context of single
or multiple domains where a domain refers to a collection of network
elements within a common sphere of address management or path
computational responsibility such Interior Gateway Protocol (IGP)
areas and Autonomous Systems.
Path Computation Clients (PCCs) send computation requests to PCEs
using PCReq messages, and these may forward the requests to and
cooperate with other PCEs forming a "path computation chain". In the
case of successful path computation, the computed paths are then
provided to the requesting PCC using PCRep messages. The PCReq and
PCRep messages are defined in [RFC5440].
In PCE-based environments, it is critical to monitor the state of the
path computation chain for troubleshooting and performance monitoring
purposes: liveness of each element (PCE) involved in the PCE chain
and detection of potential resource contention states and statistics
in terms of path computation times are examples of such metrics of
interest.
As defined in [RFC4655], there are circumstances in which more than
one PCE is 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-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 tail-end domain. We call the set of PCEs involved in
the computation of a TE LSP a "path computation chain". As further
discussed in Section 3.1, the path computation chain may either be
static (pre-configured) or dynamically determined during the path
computation process.
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 multiple PCE path computation). In the former case,
the PCC may be able to use IGP extensions to check the liveness of
the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive
messages. In contrast, when multiple PCEs are involved in the path
computation chain, an example of which is the Backward Recursive PCE-
based Computation (BRPC) procedure defined in [RFC5441], the PCC's
visibility may be limited to the first PCE involved in the path
computation chain. Thus, it is critical to define mechanisms in
order to monitor the state of the path computation chain.
Vasseur, et al. Standards Track [Page 4]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
This document specifies PCEP extensions in order to gather various
state metrics along the path computation chain. In this document, we
call a "state metric" a metric that characterizes a PCE state. For
example, such a metric can have a form of a boolean (PCE is alive or
not, PCE is congested or not) or a performance metric (path
computation time at each PCE).
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
requests to gather metrics in the context of a path computation
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
addition to the computed path. Conversely, if the request is "out of
band", PCE state metric collection is performed as a standalone
request (e.g., check the liveness of a specific path computation
chain, collect the average processing time computed over the last
5-minute period on one or more PCEs).
In this document, we define two monitoring request types: general and
specific. A general monitoring request relates to the collection of
a PCE state metrics that is not coupled to a particular path
computation request (e.g., average CPU load on a PCE). Conversely, a
specific monitoring request relates to a particular path computation
request (processing time to complete the path computation for a TE
LSP).
This document specifies procedures and extensions to the Path
Computation Element Protocol (PCEP) ([RFC5440]), including new
objects and new PCEP messages, in order to monitor the path
computation chain and gather various performance metrics.
The message formats in this document are specified using Backus Naur
Format (BNF) encoding as specified in [RFC5511].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology
PCC (Path Computation Client): any client application requesting a
path computation to be performed by a Path Computation Element.
PCE (Path Computation Element): an entity (component, application, or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
Vasseur, et al. Standards Track [Page 5]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
TE LSP: Traffic Engineering Label Switched Path.
3. Path Computation Monitoring Messages
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
be either mandatory or optional. As a reminder, an object is said to
be mandatory in a PCEP message when the object must be included for
the message to be considered valid. The P flag (defined in
[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
related information during the path computation. Because the P flag
exclusively relates to a path computation request, it MUST be cleared
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 set of objects that the message can carry. An implementation
MUST form the PCEP messages using the object ordering specified in
this document.
In this document, we define two PCEP messages referred to as the Path
Computation Monitoring Request (PCMonReq) and Path Computation
Monitoring Reply (PCMonRep) messages so as to handle out-of-band
monitoring requests. The aim of the PCMonReq message sent by a PCC
to a PCE is to gather one or more PCE state metrics on a set of PCEs
involved in a path computation chain. The PCMonRep message sent by a
PCE to a PCC is used to provide such data.
3.1. Path Computation Monitoring Request (PCMonReq) Message
The Message-Type field of the PCEP common header for the PCMonReq
message is set to 8.
There is one mandatory object that MUST be included within a PCMonReq
message: the MONITORING object (see Section 4.1). If the MONITORING
object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING
object missing). Other objects are optional.
Format of a PCMonReq message (out-of-band request):
::=
[]
[]
[]
Vasseur, et al. Standards Track [Page 6]
RFC 5886 Monitoring Tools for PCE-Based Architecture June 2010
where:
::=[]
::=
[]
[]
::=[]
::=
RFC, FYI, BCP
