[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-vasseur-pce-monitoring) 00 01 02 03 04 05 06 07 08 09 RFC 5886

Networking Working Group                                JP. Vasseur, Ed.
Internet-Draft                                        Cisco Systems, Inc
Intended status: Standards Track                             JL. Le Roux
Expires: March 6, 2009                                    France Telecom
                                                              Y. Ikejiri
                                          NTT Communications Corporation
                                                       September 2, 2008


      A set of monitoring tools for Path Computation Element based
                              Architecture
                    draft-ietf-pce-monitoring-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 6, 2009.

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 IGP areas and Autonomous
   Systems).  In PCE-based environments, it is thus critical to monitor



Vasseur, et al.           Expires March 6, 2009                 [Page 1]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   the state of the path computation chain for troubleshooting and
   performance monitoring purposes: liveness of each element (PCE)
   involved in the PCE chain, detection of potential resource contention
   states and statistics in term 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.

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].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Path Computation Monitoring messages . . . . . . . . . . . . .  4
     3.1.  Path Computation Monitoring Request message (PCMonReq) . .  5
     3.2.  Path Monitoring Reply message (PCMonRep) . . . . . . . . .  7
   4.  Path Computation Monitoring Objects  . . . . . . . . . . . . .  8
     4.1.  MONITORING Object  . . . . . . . . . . . . . . . . . . . .  8
     4.2.  PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  CONGESTION Object  . . . . . . . . . . . . . . . . . . . . 13
   5.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . . 14
   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19













Vasseur, et al.           Expires March 6, 2009                 [Page 2]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


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 as IGP areas and Autonomous
   Systems.

   As defined in [RFC4655], there are circumstances where 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 PCE chain may either be static (pre-configured) or
   dynamically determined during the path computation process.

   In PCE-based environments, it is critical to monitor the state of the
   path computation chain for troubeshooting and performance monitoring
   purposes: liveness of each element (PCE) involved in the PCE chain,
   detection of potential resource contention states and statistics in
   term of path computation times are examples of such metrics of
   interest.  This document specifies procedures and extensions to the
   Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in
   order to monitor the path computation chain and gather various
   performance metrics.

   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 BRPC procedure defined
   in [I-D.ietf-pce-brpc], 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.

   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 metric can have a form of a bolean (PCE is alive or
   not, PCE is congested or not) or a performance metric (path



Vasseur, et al.           Expires March 6, 2009                 [Page 3]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   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 PCE chain, collect the
   average processing time computed over the last 5mn 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).


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.

   TE LSP: Traffic Engineering Label Switched Path.


3.  Path Computation Monitoring messages

   As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a
   common header 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 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 [I-D.ietf-pce-pcep]) 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
   (PCEMonReq and PCMonRep message) defined in this document.




Vasseur, et al.           Expires March 6, 2009                 [Page 4]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   For each PCEP message type a set of rules is defined that specify the
   set of objects that the message can carry.  We use the Backus-Naur
   Form (BNF) to specify such rules.  Square brackets refer to optional
   sub-sequences.  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 request.  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 message (PCMonReq)

   The Message-Type field of the PCEP common header for the PCMonReq
   message is set to 8 (To be confirmed by IANA).

   There is one mandatory object that MUST be included within a PCMonReq
   message: the Monitoring object (see section 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.



























Vasseur, et al.           Expires March 6, 2009                 [Page 5]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   The format of a PCMonReq message is as follows:
   <PCMonReq Message>::= <Common Header>
                         <MONITORING>
                         [<pce-list>]
                         [<svec-list>]
                         [<request-list>]
   where:

   <svec-list>::=<SVEC>
                 [<OF>]
                 [<svec-list>]

   <request-list>::=<request>[<request-list>]

   <request>::= <RP>
                <END-POINTS>
                [<LSPA>]
                [<BANDWIDTH>]
                [<metric-list>]
                [<RRO>]
                [<IRO>]
                [<LOAD-BALANCING>]
                [<XRO>]

   <metric-list>::=<METRIC>[<metric-list>]

   <pce-list>::=<PCE-ID>[<pce-list>]

   The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD-
   BALANCING objects are defined in [I-D.ietf-pce-pcep].  The XRO object
   is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in
   [I-D.ietf-pce-of].

   The PCMonReq message is used to gather various PCE state metrics
   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
   objects defined in Section 4.2.) or may alternatively be determined
   by the path computation procedure.  For example, if the BRPC
   procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE
   LSP, the PCE chain may be determined dynamically.  In that case, the
   PCC sends a PCMonReq message that contains the PCEP objects that
   charaterize the TE LSP attributes along with the monitoring objects
   (see Section 4.1) that list the set of metric(s) of interest.

   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
   may be extended in the future.




Vasseur, et al.           Expires March 6, 2009                 [Page 6]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   For the sake of illustraion, consider the three following examples:

   Example 1: PCC1 requests to check the path computation chain that
   would be used should it request a path computation for a specific TE
   LSP named T1.  A PCMonReq message is sent that contains a MONITORING
   object specifying a path computation check, along with the
   appropriate set of objects (e.g.  RP, END-POINTS, ...) that would be
   included in a PCReq message for T1.

   Example 2: PCC1 requests a path computation for a TE LSP and also
   request to gather the processing time along the path computation
   chain selected for the computation of T1.  A PCReq message is sent
   that also contains a MONITORING object that specifies the performance
   metric of interest.  The PCRep message also carries a PROC-TIME
   object defined in section Section 4.1 that reports the computed
   metrics.

   Example 3: PCC2 requests to gather performance metrics along the
   specific path computation chain <pce1, pce2, pce3, pce7>.  A PCMonreq
   message is sent to PCE1 that contains a sequence of PCE-ID objects
   that identify PCE1, PCE2, PCE3 and PCE7 respectively.

3.2.  Path Monitoring Reply message (PCMonRep)

   The PCMonRep message is used to provide PCE state metrics back to the
   requester for "out of band" monitoring requests.  The Message-Type
   field of the PCEP common header for the PCMonRep message is set to 9
   (To be confirmed by IANA).

   There is one mandatory object that MUST be included within a PCMonRep
   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.















Vasseur, et al.           Expires March 6, 2009                 [Page 7]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   The format of a PCReq message is as follows:
   <PCMonRep Message>::= <Common Header>
                         <MONITORING>
                         [<RP>]
                         [<metric-pce-list>]

   where:

   <metric-pce-list>::=<metric-pce>[<metric-pce-list>]

   <metric-pce>::=[<PCE-ID>]
                  [<PROC-TIME>]
                  [<TIME-STAMP>]
                  [<CONGESTION>]


4.  Path Computation Monitoring Objects

   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
   I flag cleared since these flags are exclusively related to path
   computation requests.

   Several objects are defined in this section that can be carried
   within the PCEP PCReq or PCRep messages defined in
   [I-D.ietf-pce-pcep] in case of "in band" monitoring requests.  In
   case of "out of band" monitoring requests, the objects defined in
   this section are carried within PCMonReq and PCMonRep messages.
   Conversely, if the PCC requests the computation of the TE LSP in
   addition to gathering PCE state metrics (i.e.  "In band" requests),
   these objects are carried within PCReq and PCRep messages.

4.1.  MONITORING Object

   The MONITORING object MUST be present within PCMonReq and PCMonRep
   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).
   There SHOULD NOT be more than one instance of the MONITORING object:
   if more than one instance of the MONITORING object is present, the
   recipient MUST process the first instance and MUST ignore other
   instances.

   The MONITORING object is used to specify the set of requested PCE
   state metrics.




Vasseur, et al.           Expires March 6, 2009                 [Page 8]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   The MONITORING Object-Class is to be assigned by IANA (recommended
   value=19)

   The MONITORING Object-Type is to be assigned by IANA (recommended
   value=1)

   The format of the MONITORING object body is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |                  Flags              |I|C|P|G|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Monitoring-id-number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLV(s)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Flags: 24 bits

   The following flags are currently defined:

   L (Liveness) - 1 bit: when set, this indicates that the state metric
   of interest is the PCE's liveness and thus the PCE MUST include a
   PCE-ID object in the corresponding reply.  The L bit MUST always be
   ignored in a PCMonRep or PCRep message.

   G (General) - 1 bit: when set, this indicates that the monitoring
   request is a general monitoring request.  When the requested
   performance metric is specific, the G bit MUST be cleared.  The G bit
   MUST always be ignored in a PCMonRep or PCRep message.

   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
   processing times is a metric of interest, in which case a 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.

   C (Congestion) - 1 bit: The C bit of the MONITORING object carried in
   a PCMonReq or a PCReq message is set to indicate that the congestion
   status is a metric of interest, in which case a CONGESTION object
   MUST be inserted in the corresponding PCMonRep or PCRep message.  The
   C bit MUST always be ignored in a PCMonRep or PCRep message.

   I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message



Vasseur, et al.           Expires March 6, 2009                 [Page 9]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   and that message does not trigger any policy violation, but the PCE
   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
   meaning in a request and SHOULD be ignored on receipt.

   Monitoring-id-number (32 bits): The monitoring-id-number value
   combined with the PCEP-ID of the PCC identifies the monitoring
   request context.  The monitoring-id-number MUST start at a non-zero
   value and MUST be incremented each time a new monitoring request is
   sent to a PCE.  Each increment SHOULD have a value of 1 and may cause
   a wrap back to one.  If no reply to a monitoring request is received
   from the PCE, and the PCC wishes to resend its path computation
   monitoring request, the same monitoring-id-number MUST be used.
   Conversely, a different monitoring-id-number MUST be used for
   different requests sent to a PCE.  The path computation monitoring
   reply is unambiguously identified by the monitoring-id-number and the
   PCEP-ID of the replying PCE.  A PCEP implementation SHOULD checkpoint
   the Monitoring-id-number of pending monitoring requests in case of
   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
   transmission and ignored on reception.

   No optional TLVs are currently defined.

4.2.  PCEP-ID Object

   The PCEP-ID Object is used to specify a PCE's IP address.

   A set of PCEP-ID objects may be inserted within a PCReq or a PCMonReq
   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
   PCE reporting PCE state metrics or that was involved in the path
   computation chain.

   Two PCEP-ID objects (for IPv4 and IPv6) are defined.  PCEP-ID Object-
   Class is to be assigned by IANA (recommended value=20) PCEP-ID
   Object-Type is to be assigned by IANA (recommended value=1 for IPv4
   and 2 for IPv6)

   The format of the PCEP-ID Object is as follows:









Vasseur, et al.           Expires March 6, 2009                [Page 10]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   The format of the PCEP-ID 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 PCEP-ID object body has a fixed length of 4 octets for IPv4 and
   16 octets for IPv6.

   When a dynamic discovery mechanism is used for PCE discovery, a PCE
   advertises its PCE address in the PCE-ADDRESS sub-TLV defined in
   [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
   PCMonRep messages.

4.3.  PROC-TIME Object

   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
   carried within the corresponding PCMonReq or PCReq message is set.
   The PROC-TIME object is used to report various processing time
   related metrics.

   1) Case of general monitoring requests

   A PCC may request processing time metrics for general monitoring
   requests (e.g. the PCC may want to know the minimum, maximum and
   average processing times on a particular PCE).  In this case, general
   requests can only be made by using PCMonReq/PCMonRep messages.  The
   processing-time field (as explained below) is exclusively used for
   specific monitoring requests and MUST be cleared for general
   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
   scope of this document (A PCE may decide to compute the minimum
   processing time over a period of times, for the last N path
   computation requests, ...).




Vasseur, et al.           Expires March 6, 2009                [Page 11]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   2) Case of specific monitoring requests

   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
   document but a flag is specified that is used to indicate to the
   requester whether the processing time value was estimated or
   computed.  The PCE may either (1) estimate the processing time
   without performing an actual path computation or (2) effectively
   perform the computation to report the processing time.  In the former
   case, the E bit of the PROC-TIME object MUST be set.  The G bit MUST
   be cleared and the Min-processing-time, Max-processing-time, Average-
   processing-time and Variance-processing-time MUST be set to
   0x00000000.

   When the processing time is requested in addition to a path
   computation (case where the MONITORING object is carried within a
   PCReq message), the PROC-TIME object always reports the actual
   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
   value=21)

   The PROC-TIME Object-Type is to be assigned by IANA (recommended
   value=1)

   The format of the PROC-TIME object body is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved                |           Flags             |E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Current-processing-time                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Min-processing-time                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Max-processing-time                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Average-processing time                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Variance-processing-time                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Flags: 18 bits - No Flags are currently defined:

   E (Estimated) - 1 bit: when set, this indicates that the reported
   metric value is based on estimated processing time as opposed to
   actual computation(s).



Vasseur, et al.           Expires March 6, 2009                [Page 12]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   Current-processing-time: This field indicates in milliseconds the
   processing time for the path computation of interest characterized in
   the corresponding PCMonReq message.

   Min-processing-time: This field indicates in milliseconds the minimum
   processing time.

   Max-processing-time: This field indicates in milliseconds the maximum
   processing time.

   Average-processing-time: This field indicates in milliseconds the
   average processing time.

   Variance-processing-time: This field indicates in milliseconds the
   variance of the processing times.

   Unassigned bits are considered as reserved and MUST be set to zero on
   transmission.

   More granularity may be introduced in further revision of this
   document to get a monitoring metric for a general request of a
   particular class (e.g. all PCReq of priority X).

4.4.  CONGESTION Object

   The CONGESTION object MUST be present within a PCMonRep or a PCRep
   message if the C bit of the MONITORING object carried within the
   corresponding PCMonReq or PCReq message is set.  The CONGESTION
   object is used to report a PCE processing congestion state.  The
   CONGESTION Object-Class is to be assigned by IANA (recommended
   value=22) The CONGESTION Object-Type is to be assigned by IANA
   (recommended value=1)

   The format of the CONGESTION object body is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|        Reserved             |    Congestion Duration        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   C (Congestion) - 1 bit: when set, this indicates that PCE is
   congested, in which case the congestion duration may be non nul.
   When cleared this indicates that the PCE is not congested and the
   "Congestion Duration" field MUST be set to 0x0000.

   Congestion duration - 16 bits: This field indicates in seconds the
   estimated congestion duration.



Vasseur, et al.           Expires March 6, 2009                [Page 13]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


5.  Policy

   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-
   Type=5 and Error-value=3 (To be Confirmed by IANA).


6.  Elements of Procedure

   I bit processing: as indicated in section Section 4.1, if a PCE
   supports a received PCMonReq message and that message does not
   trigger any policy violation, but the PCE cannot provide any of the
   set of requested performance metrics for unspecified reasons, the PCE
   MUST set the I bit.  Once set, the I bit MUST NOT be changed by a
   receiving PCE.

   Reception of a PCMonReq message: upon receiving a PCMonReq message:

   1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support
   the PCMonReq message, the PCE peer must send a PCErr message with
   Error-value=2 (capability not supported).

   2) If the PCE supports the PCMonReq message but the request is
   prohibited by policy, the PCE MUST send a PCErr message with Error-
   Type=5 and Error-value=3.

   3) If the PCE supports the PCMonReq and the monitoring request is not
   prohibited by policy, the receiving PCE MUST first determine whether
   it is the last PCE of the path computation chain.  If the PCE is not
   the last element of the path computation chain, the PCMonReq message
   is relayed to the next hop PCE: such next-hop may either be specified
   by means of a PCEP-ID object present in the PCMonReq message or
   dynamically determined by means of a procedure outside of the scope
   of this document.  Conversely, if the PCE is the last PCE of the path
   computation chain, the PCE originates a PCMonRep message that
   contains the requested objects according to the set of requested PCE
   states metrics listed in the MONITORING object carried in the
   corresponding PCMonReq message.

   Upon receiving a PCMonRep message: upon receiving a PCMonRep message,
   the PCE processes the request, adds the relevant objects to the
   PCMonRep message and forwards the PCMonRep message to the upstream
   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



Vasseur, et al.           Expires March 6, 2009                [Page 14]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   chain.


7.  Manageability Considerations

   To be addressed in a further revision of this document.


8.  IANA Considerations

   Each PCEP message has a message type value.

   Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined
   in this document:

   Value    Meaning
     8      Path Computation Monitoring Request (PCMonReq)
     9      Path Computation Monitoring Reply (PCMonRep)

   Each PCEP object has an Object-Class and an Object-Type.  The
   following new PCEP objects are defined in this document.

   Object-Class      Name

          19         MONITORING
                     Object-Type
                        1

          20         PCEP-ID
                     Object-Type
                      1: IPv4 addresses
                      2: IPv6 addresses

          21         PROC-TIME
                     Object-Type
                        1

          22         CONGESTION
                     Object-Type
                        1

   A registry has been created for the Error-type and Error-value of the
   PCEP Error Object.

   A new Error-value for the PCErr message Error-types=5 (Policy
   Violation) (see [I-D.ietf-pce-pcep]) is defined in this document
   (Error-Type and Error-value to be assigned by IANA).




Vasseur, et al.           Expires March 6, 2009                [Page 15]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


     Error-type        Meaning
        5              Policy violation
                         Error-value=3              [This document]
                             Monitoring message supported but rejected
                             due to policy violation

   A new Error-value for the PCErr message Error-types=6 (Mandatory
   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        Meaning
        6              Mandatory Object missing
                         Error-value=4                [This document]
                            MONITORING Object missing


9.  Security Considerations

   To be addressed in a further revision of this document.


10.  Acknowledgements

   The authors would like to thank Eiji Oki, Mach Chen and Dimitri
   Papadimitriou for their useful comments.  Special thank to Adrian
   Farrel for his detailed review.


11.  References

11.1.  Normative References

   [I-D.ietf-pce-pcep]
              Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
              A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
              "Path Computation Element (PCE) Communication Protocol
              (PCEP)", draft-ietf-pce-pcep-14 (work in progress),
              September 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.







Vasseur, et al.           Expires March 6, 2009                [Page 16]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


11.2.  Informative References

   [I-D.ietf-pce-brpc]
              Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A
              Backward Recursive PCE-based Computation (BRPC) Procedure
              To Compute  Shortest Constrained Inter-domain Traffic
              Engineering Label Switched Paths", draft-ietf-pce-brpc-09
              (work in progress), April 2008.

   [I-D.ietf-pce-disco-proto-isis]
              Roux, J., "IS-IS Protocol Extensions for Path Computation
              Element (PCE) Discovery",
              draft-ietf-pce-disco-proto-isis-08 (work in progress),
              September 2007.

   [I-D.ietf-pce-of]
              Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
              Functions in the Path Computation Element  Communication
              Protocol (PCEP)", draft-ietf-pce-of-04 (work in progress),
              August 2008.

   [I-D.ietf-pce-pcep-xro]
              Takeda, T., Oki, E., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in
              progress), July 2008.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.


Authors' Addresses

   JP Vasseur (editor)
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Email: jpv@cisco.com






Vasseur, et al.           Expires March 6, 2009                [Page 17]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


   JL Le Roux
   France Telecom
   2, Avenue Pierre-Marzin
   Lannion,   22307
   FRANCE

   Email: jeanlouis.leroux@orange-ftgroup.com


   Yuichi Ikejiri
   NTT Communications Corporation
   1-1-6, Uchisaiwai-cho, Chiyoda-ku
   Tokyo,   100-8019
   Japan

   Email: : y.ikejiri@ntt.com



































Vasseur, et al.           Expires March 6, 2009                [Page 18]


Internet-Draft      draft-ietf-pce-monitoring-02.txt      September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Vasseur, et al.           Expires March 6, 2009                [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/