Skip to main content

PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements
draft-gandhi-pce-pm-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Rakesh Gandhi , Bin Wen , Colby Barth , Dhruv Dhody
Last updated 2016-11-16
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gandhi-pce-pm-04
PCE Working Group                                              R. Gandhi
Internet-Draft                                    Individual Contributor
Intended Status: Standards Track                                  B. Wen
Expires: May 21, 2017                                            Comcast
                                                                C. Barth
                                                        Juniper Networks
                                                                D. Dhody
                                                     Huawei Technologies
                                                       November 17, 2016

    PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements
                          draft-gandhi-pce-pm-04

Abstract

   In certain networks, network performance data such as packet loss,
   delay and delay variation (jitter) as well as bandwidth usage is a
   critical measure for Traffic Engineering (TE).  This data provides
   operators the characteristics of their networks for performance
   evaluation that is required to ensure the Service Level Agreements
   (SLAs).  Performance Measurement (PM) mechanisms can be employed to
   monitor these metrics for TE Label Switched Paths (LSPs) in real-
   time.  This document describes Path Computation Element Protocol
   (PCEP) extensions for reporting such performance measurements to an
   Active Stateful PCE.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
 

Gandhi, et al.            Expires May 21, 2017                  [Page 1]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2016 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Dependencies and Considerations  . . . . . . . . . . . . .  4
     1.2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  PCEP Extensions for Reporting Delay Measurement  . . . . . . .  6
     3.1.  DELAY-MEASUREMENT Capability Advertisement . . . . . . . .  6
       3.1.1.  DELAY-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . .  6
     3.2.  DELAY-MEASUREMENT-ATTRIBUTE TLV  . . . . . . . . . . . . .  8
       3.2.1.  Measurement-Enable sub-TLV . . . . . . . . . . . . . .  9
       3.2.2.  Measurement-Interval sub-TLV . . . . . . . . . . . . .  9
       3.2.3.  Measurement-Mode sub-TLV . . . . . . . . . . . . . . . 10
       3.2.4.  Report-Threshold sub-TLV . . . . . . . . . . . . . . . 10
       3.2.5.  Report-Interval sub-TLV  . . . . . . . . . . . . . . . 11
     3.3.  DELAY-MEASUREMENT Object . . . . . . . . . . . . . . . . . 11
   4.  PCEP Extensions for Reporting Loss Measurement . . . . . . . . 13
     4.1.  LOSS-MEASUREMENT Capability Advertisement  . . . . . . . . 13
       4.1.1.  LOSS-MEASUREMENT-CAPABILITY TLV  . . . . . . . . . . . 13
     4.2.  LOSS-MEASUREMENT-ATTRIBUTE TLV . . . . . . . . . . . . . . 15
       4.2.1.  Measurement-Enable sub-TLV . . . . . . . . . . . . . . 16
       4.2.2.  Measurement-Interval sub-TLV . . . . . . . . . . . . . 16
 

Gandhi, et al.            Expires May 21, 2017                  [Page 2]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

       4.2.3.  Measurement-Mode sub-TLV . . . . . . . . . . . . . . . 17
       4.2.4.  Report-Threshold-Packets sub-TLV . . . . . . . . . . . 17
       4.2.5.  Report-Threshold-Bytes sub-TLV . . . . . . . . . . . . 18
       4.2.6.  Report-Interval sub-TLV  . . . . . . . . . . . . . . . 18
     4.3.  LOSS-MEASUREMENT Object  . . . . . . . . . . . . . . . . . 19
   5.  PCEP Extensions for Reporting Bandwidth Usage  . . . . . . . . 20
     5.1.  BANDWIDTH-USAGE Capability Advertisement . . . . . . . . . 20
       5.1.1.  BANDWIDTH-USAGE-CAPABILITY TLV . . . . . . . . . . . . 20
     5.2.  BANDWIDTH-USAGE-ATTRIBUTE TLV  . . . . . . . . . . . . . . 21
       5.2.1.  Report-Enable sub-TLV  . . . . . . . . . . . . . . . . 22
       5.2.2.  Report-Threshold sub-TLV . . . . . . . . . . . . . . . 23
       5.2.3.  Report-Threshold-Percentage sub-TLV  . . . . . . . . . 23
       5.2.4.  Report-Interval sub-TLV  . . . . . . . . . . . . . . . 24
       5.2.5.  Report-Flow-Threshold sub-TLV  . . . . . . . . . . . . 24
       5.2.6.  Report-Flow-Threshold-Percentage sub-TLV . . . . . . . 25
     5.3.  BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 26
   6.  The PCNtf Message  . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
     8.1.  MEASUREMENT-CAPABILITY TLV Flag Field  . . . . . . . . . . 28
     8.2.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 28
       8.2.1.  DELAY-MEASUREMENT-ATTRIBUTE Sub-TLVs . . . . . . . . . 28
       8.2.2.  LOSS-MEASUREMENT-ATTRIBUTE Sub-TLVs  . . . . . . . . . 29
       8.2.3.  BANDWIDTH-USAGE-ATTRIBUTE Sub-TLV  . . . . . . . . . . 29
     8.3.  DELAY-MEASUREMENT Object . . . . . . . . . . . . . . . . . 30
       8.3.1.  DELAY-MEASUREMENT Object-Types . . . . . . . . . . . . 30
     8.4.  LOSS-MEASUREMENT Object  . . . . . . . . . . . . . . . . . 30
       8.4.1.  LOSS-MEASUREMENT Object-Types  . . . . . . . . . . . . 30
     8.5.  BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 31
     8.6.  PCE Error Codes  . . . . . . . . . . . . . . . . . . . . . 31
     8.7.  Notification Object  . . . . . . . . . . . . . . . . . . . 31
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 33
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35

 

Gandhi, et al.            Expires May 21, 2017                  [Page 3]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
   communication mechanism between a Path Computation Client (PCC) and a
   Path Control Element (PCE), or between PCE and PCE, that enables
   computation of Multi-Protocol Label Switching (MPLS) Traffic
   Engineering Label Switched Paths (TE LSPs).  [DRAFT-PCE-STATEFUL]
   specifies extensions for PCEP to enable stateful control of MPLS TE
   LSPs.  It describes two mode of operations - Passive Stateful PCE and
   Active Stateful PCE.  In this document, Active Stateful PCE is
   considered.

   In certain networks, such as financial information networks, network
   performance data (e.g. packet loss, delay and delay variation
   (jitter), bandwidth usage) is a critical measure for traffic
   engineering [RFC7471], [RFC7810], [RFC7823] and [DRAFT-IDR-TE-PM-
   BGP].  This data provides operators the characteristics of their
   networks for performance evaluation that is required to ensure the
   Service Level Agreements (SLAs).  

   [DRAFT-PCE-SERVICE-AWARE] defines the PCEP extensions for TE LSP path
   computation using packet loss, delay and delay variation as path
   selection metrics.  However, there is a need to verify that the
   traffic sent over the established TE LSP does not exceed requested
   metric bounds.  [RFC6374], [RFC6375] and [RFC7876] define protocol
   extensions needed for measuring packet loss, delay and delay
   variation (jitter) for bidirectional and unidirectional TE LSPs in
   real-time.

1.1.  Dependencies and Considerations

   This document provides mechanisms to report the performance
   measurements (PM) such as packet loss, delay, delay variation
   (jitter) and bandwidth usage for a TE LSP to an Active Stateful PCE. 
   [RFC6374] describes several reasons why PMs are valuable to
   operators.  Note that the specification of the use of the reported
   packet loss, delay, delay variation and bandwidth usage measurements
   by a Stateful PCE is outside the scope of this document.

   Furthermore, [RFC6374] describes many types of MPLS channels that may
   leverage PMs and some may have bidirectional dependencies.  Defining
   a mechanism for the verification and/or provisioning of bidirectional
   or associated bidirectional LSPs within the Stateful PCE architecture
   is outside the scope of this document.

   In all cases, delay and loss PM messages are carried over the MPLS
   Generic Associated Channel (G-ACh) as described in [RFC5586].  MPLS
   LSPs that carry the G-ACh can be referred to as MPLS Transport
 

Gandhi, et al.            Expires May 21, 2017                  [Page 4]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Profile (MPLS-TP) LSPs.  MPLS-TP LSPs require Ultimate Hop Popping
   (UHP).  It is beyond the scope of this document to define the
   mechanism by which a Stateful PCE verifies and/or provisions an LSP
   for UHP.  Note that for both unidirectional and bidirectional LSPs,
   packet loss measurement requires UHP. 

1.2.  Overview

   High-level overview of the PCEP extensions defined in this document
   for reporting performance measurements is shown in Figure 1.  

                           --------- 
                          |         |
                          |   PCE   |
                          |         |
                           --------- 
                             |    ^              
     MEASUREMENT CAPABILITY  |    |  MEASUREMENT CAPABILITY
                             |    |
     MEASUREMENT ATTRIBUTES  |    |  MEASUREMENT VALUES
                             |    |
                             v    |          
                           ---------  
                          |         |
                          |   PCC   |
                          |         |
                           ---------

   Figure 1: Overview of PCEP Extensions for Performance Measurement

2.  Conventions Used in This Document

2.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 [RFC2119].

2.2.  Terminology

   The following terminology is used in this document.

   Active Stateful PCE: PCE that uses tunnel state information learned
      from PCCs to optimize path computations.  Additionally, it
      actively updates tunnel parameters in those PCCs that delegated
      control over their tunnels to the PCE.
 

Gandhi, et al.            Expires May 21, 2017                  [Page 5]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   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.  PCEP Extensions for Reporting Delay Measurement

3.1.  DELAY-MEASUREMENT Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of DELAY-MEASUREMENT.  A PCEP Speaker (PCE or
   PCC) includes the DELAY-MEASUREMENT-CAPABILITY TLV, in the OPEN
   Object to advertise its support for PCEP Delay-Measurement
   extensions.  The presence of the DELAY-MEASUREMENT-CAPABILITY TLV in
   the OPEN Object indicates that the Delay Measurement capability is
   supported as described in this document.  

   The PCEP protocol extensions for Delay Measurement MUST NOT be used
   if one or both PCEP Speakers have not included the DELAY-MEASUREMENT-
   CAPABILITY TLV in their respective OPEN message.  If the PCEP speaker
   that supports the extensions of this draft but did not advertise this
   capability, then upon receipt of DELAY-MEASUREMENT-ATTRIBUTE TLV in
   LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid
   Operation), error-value TBD7 (Delay-Measurement capability was not
   advertised) and it will terminate the PCEP session.  Similarly, the
   PCEP speaker SHOULD generate error-value TBD9 (Bidirectional
   Measurement capability was not advertised) and TBD10 (Unidirectional
   Measurement capability was not advertised) upon receipt of DELAY-
   MEASUREMENT-ATTRIBUTE TLV in LSPA object with two-way measurement
   request and one-way measurement request, respectively, when it did
   not advertise this capability.  Further, the PCEP speaker SHOULD
   generate error-value TBD11 (Inferred Mode Measurement capability was
   not advertised) and TBD12 (Direct Mode Measurement capability was not
   advertised) upon receipt of DELAY-MEASUREMENT-ATTRIBUTE TLV in LSPA
   object with Inferred Mode delay measurement request and Direct Mode
   delay measurement request, respectively, when it did not advertise
   this capability.

3.1.1.  DELAY-MEASUREMENT-CAPABILITY TLV

   The DELAY-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in
 

Gandhi, et al.            Expires May 21, 2017                  [Page 6]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   the OPEN Object for Delay Measurement via PCEP capability
   advertisement.  Its format is shown in the following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Type=TBD1        |           Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                   |N|I|B|U|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  DELAY-MEASUREMENT-CAPABILITY TLV format

   The type of the TLV is TBD1 and it has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits):

   o  D (Delay Measurement - 1 bit): if set to 1 by a PCC, the D Flag
      indicates that the PCC allows reporting of delay measurement
      information; if set to 1 by a PCE, the D Flag indicates that the
      PCE is capable of receiving delay measurement information from the
      PCC.  The DELAY-MEASUREMENTE-ATTRIBUTE TLV MUST be encoded when
      both PCEP speakers have the D Flag set.

   o  U (Unidirectional Measurement - 1 bit): if set to 1 by a PCC, the
      U Flag indicates that the PCC allows reporting of unidirectional
      delay measurement information; if set to 1 by a PCE, the U Flag
      indicates that the PCE is capable of receiving unidirectional
      delay measurement information from the PCC. 

   o  B (Bidirectional Measurement - 1 bit): if set to 1 by a PCC, the B
      Flag indicates that the PCC allows reporting of bidirectional
      delay measurement information; if set to 1 by a PCE, the B Flag
      indicates that the PCE is capable of receiving bidirectional delay
      measurement information from the PCC. 

   o  I (Inferred Mode - 1 bit): if set to 1 by a PCC, the I Flag
      indicates that the PCC allows reporting of inferred mode delay
      measurement information; if set to 1 by a PCE, the I Flag
      indicates that the PCE is capable of receiving inferred mode delay
      measurement information from the PCC. 

   o  N (Direct Mode - 1 bit): if set to 1 by a PCC, the N Flag
      indicates that the PCC allows reporting of direct mode delay
      measurement information; if set to 1 by a PCE, the N Flag
      indicates that the PCE is capable of receiving direct mode delay
      measurement information from the PCC. 

 

Gandhi, et al.            Expires May 21, 2017                  [Page 7]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.

   Advertisement of the Delay-Measurement capability TLV implies support
   of delay measurement, as well as the objects, TLVs and procedures
   defined in this document.

3.2.  DELAY-MEASUREMENT-ATTRIBUTE TLV

   The DELAY-MEASUREMENT-ATTRIBUTE TLV provides the configurable
   parameters of the delay measurement feature.  This is an optional TLV
   defined for the LSPA Object.

   For PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with delay
   measurement feature enabled, this TLV is included in the LSPA Object
   with PCInitiate message.  The DELAY-MEASUREMENT-ATTRIBUTE TLV can
   also be carried in PCUpd message in LSPA Object in order to make
   updates to delay measurement attributes such as Measurement-Interval.

   The format of the DELAY-MEASUREMENT-ATTRIBUTE TLV is shown in the
   following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=TBD3           |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            sub-TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  DELAY-MEASUREMENT-ATTRIBUTE TLV format

   Type: TBD3

   Length: Variable

   Value: Comprises one or more sub-TLVs.

   Following sub-TLVs are defined in this document:

   Type Len  Name
   -----------------------------------------------------------------
    0   4    Reserved
    1   4    Measurement-Enable sub-TLV
    2   4    Measurement-Interval sub-TLV
 

Gandhi, et al.            Expires May 21, 2017                  [Page 8]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

    3   4    Measurement-Mode sub-TLV
    4   4    Report-Threshold sub-TLV
    5   4    Report-Interval sub-TLV

   The Measurement-Enable sub-TLV MUST be added in LSPA Object when the
   delay measurement feature is enabled for the LSP.  All other sub-TLVs
   are optional and any unrecognized sub-TLV MUST be silently ignored. 
   If a sub-TLV of same type appears more than once, only the first
   occurrence is processed and all others MUST be ignored.  If sub-TLVs
   are not present, the default values based on the local policy are
   assumed.

   The following sub-sections describe the sub-TLVs which are currently
   defined to be carried within this TLV.

3.2.1.  Measurement-Enable sub-TLV

   The Measurement-Enable sub-TLV specifies the delay measurement mode
   enabled.

   The Type is 1, Length is 4, and the value comprises of 4-octet. Value
   is defined as following:

   Value     Name
   ------------------------------------------------------------------
    0        Delay Measurement Disabled
    1        One-way Delay Measurement Enabled
    2        Two-way Delay Measurement Enabled
    3        One-Way and Two-Way Delay Measurements Enabled

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=1              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Enable                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Enable sub-TLV format

3.2.2.  Measurement-Interval sub-TLV

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the measurement.

   The Type is 2, Length is 4, and the value comprises of 4-octet time
 

Gandhi, et al.            Expires May 21, 2017                  [Page 9]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   interval, the valid range is from 1 to 604800, in seconds.  The
   default value is 300 seconds.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=2              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Interval                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Interval sub-TLV format

3.2.3.  Measurement-Mode sub-TLV

   The Measurement-Mode sub-TLV specifies the delay measurement mode
   which can be direct or inferred.

   The Type is 3, Length is 4, and the value comprises of 4-octet delay
   measurement mode.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=3              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Mode                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Mode sub-TLV format

   Value     Name
   ------------------------------------------------------------------
    0        Inferred Mode (using test traffic)
    1        Direct Mode (using data traffic)

3.2.4.  Report-Threshold sub-TLV

   The Report-Threshold sub-TLV specifies the delay threshold value.

   The Type is 4, Length is 4, and the value comprises of 4-octet delay
   threshold value.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

Gandhi, et al.            Expires May 21, 2017                 [Page 10]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   |           Type=4              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Report-Threshold                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Threshold sub-TLV format

   The measured delay value MUST only be reported once the value exceeds
   the specified threshold value.  This reporting can be used to trigger
   an immediate action at the PCE peer.

3.2.5.  Report-Interval sub-TLV

   The Report-Interval sub-TLV specifies the time interval in seconds
   when measured delay values are to be reported.  Maximum value of the
   measured metric (e.g. average delay, delay variation) collected
   during the report interval is reported.

   The Type is 5, Length is 4, and the value comprises of 4-octet time
   interval, the valid range is from 1 to 604800, in seconds.  The
   default value equals to the Measurement-Interval.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=5              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Report-Interval                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Interval sub-TLV format

   The measured delay value MUST be reported if the specified threshold
   is crossed OR the report-interval expires.  The periodic reporting
   can be used at the PCEP peer to monitor the LSP metrics.

3.3.  DELAY-MEASUREMENT Object

   The DELAY-MEASUREMENT Object with Object-Class (Value TBD5) is
   defined in this document to report the delay measurement of a TE LSP.

   When the LSP is enabled with the delay measurement feature, locally
   or by PCE, the PCC SHOULD include the DELAY-MEASUREMENT Object to
   report the measured delay values to the PCE in the PCRpt message. 

   Object-Types are defined as follows:
 

Gandhi, et al.            Expires May 21, 2017                 [Page 11]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Object-Type  Len   Name       
   --------------------------------------------------------------
    0           4     Reserved         
    1           4     One-Way Delay Measurement Value 
    2           8     One-Way Delay Measurement Min/Max Values 
    3           4     One-Way Delay Variation Measurement Value 
    4           4     Two-Way Delay Measurement Value 
    5           8     Two-Way Delay Measurement Min/Max Values 
    6           4     Two-Way Delay Variation Measurement Value 

   The payload format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delay Value Average                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delay Value Minimum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delay Value Maximum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delay Variation Value                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          DELAY-MEASUREMENT Object formats (One-Way and Two-Way)

   o  One-way Delay Measurement Value: Delay of the LSP in one (forward)
      direction, encoded as 24-bit integer, as defined in RFC 7471
      [RFC7471].  When set to the maximum value 16,777,215 (16.777215
      sec), the delay is at least that value and may be larger.  

   o  One-way Delay Measurement Variation Value: Delay Variation of the
      LSP in one (forward) direction, encoded as 24-bit integer, as
      defined in RFC 7471 [RFC7471].  When set to the maximum value
      16,777,215 (16.777215 sec), the delay variation is at least that
      value and may be larger. 
 

Gandhi, et al.            Expires May 21, 2017                 [Page 12]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   o  Two-way Delay Measurement Value: Delay of the bidirectional LSP in
      both (forward and reverse) directions, encoded as 24-bit integer,
      as defined in RFC 7471 [RFC7471].  When set to the maximum value
      16,777,215 (16.777215 sec), the delay is at least that value and
      may be larger. 

   o  Two-way Delay Measurement Variation Value: Delay Variation of the
      bidirectional LSP in both (forward and reverse) directions,
      encoded as 24-bit integer, as defined in RFC 7471 [RFC7471].  When
      set to the maximum value 16,777,215 (16.777215 sec), the delay
      variation is at least that value and may be larger. 

4.  PCEP Extensions for Reporting Loss Measurement

4.1.  LOSS-MEASUREMENT Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of LOSS-MEASUREMENT.  A PCEP Speaker includes
   the LOSS-MEASUREMENT-CAPABILITY TLV, in the OPEN Object to advertise
   its support for PCEP Loss-Measurement extensions.  The presence of
   the LOSS-MEASUREMENT-CAPABILITY TLV in the OPEN Object indicates that
   the Loss Measurement capability is supported as described in this
   document.  

   The PCEP protocol extensions for Loss Measurement MUST NOT be used if
   one or both PCEP Speakers have not included the LOSS-MEASUREMENT-
   CAPABILITY TLV in their respective OPEN message.  If the PCEP speaker
   that supports the extensions of this draft but did not advertise this
   capability, then upon receipt of LOSS-MEASUREMENT-ATTRIBUTE TLV in
   LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid
   Operation), error-value TBD8 (Loss-Measurement capability was not
   advertised) and it will terminate the PCEP session.  Similarly, the
   PCEP speaker SHOULD generate error-value TBD9 (Bidirectional
   Measurement capability was not advertised) and TBD10 (Unidirectional
   Measurement capability was not advertised) upon receipt of LOSS-
   MEASUREMENT-ATTRIBUTE TLV in LSPA object with two-way measurement
   request and one-way measurement request, respectively, when it did
   not advertise this capability.  Further, the PCEP speaker SHOULD
   generate error-value TBD11 (Inferred Mode Measurement capability was
   not advertised) and TBD12 (Direct Mode Measurement capability was not
   advertised) upon receipt of LOSS-MEASUREMENT-ATTRIBUTE TLV in LSPA
   object with Inferred Mode loss measurement request and Direct Mode
   loss measurement request, respectively, when it did not advertise
   this capability.

4.1.1.  LOSS-MEASUREMENT-CAPABILITY TLV
 

Gandhi, et al.            Expires May 21, 2017                 [Page 13]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   The LOSS-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in the
   OPEN Object for Loss Measurement via PCEP capability advertisement. 
   Its format is shown in the following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Type=TBD2        |           Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                   |N|I|B|U|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  LOSS-MEASUREMENT-CAPABILITY TLV format

   The type of the TLV is TBD2 and it has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits):

   o  L (Loss Measurement - 1 bit): if set to 1 by a PCC, the L Flag
      indicates that the PCC allows reporting of loss measurement
      information; if set to 1 by a PCE, the L Flag indicates that the
      PCE is capable of receiving loss measurement information from the
      PCC.  The LOSS-MEASUREMENTE-ATTRIBUTE TLV MUST be encoded when
      both PCEP speakers have the L Flag set.

   o  U (Unidirectional Measurement - 1 bit): if set to 1 by a PCC, the
      U Flag indicates that the PCC allows reporting of unidirectional
      loss measurement information; if set to 1 by a PCE, the U Flag
      indicates that the PCE is capable of receiving unidirectional loss
      measurement information from the PCC. 

   o  B (Bidirectional Measurement - 1 bit): if set to 1 by a PCC, the B
      Flag indicates that the PCC allows reporting of bidirectional loss
      measurement information; if set to 1 by a PCE, the B Flag
      indicates that the PCE is capable of receiving bidirectional loss
      measurement information from the PCC. 

   o  I (Inferred Mode - 1 bit): if set to 1 by a PCC, the I Flag
      indicates that the PCC allows reporting of inferred mode loss
      measurement information; if set to 1 by a PCE, the I Flag
      indicates that the PCE is capable of receiving inferred mode loss
      measurement information from the PCC. 

   o  N (Direct Mode - 1 bit): if set to 1 by a PCC, the N Flag
      indicates that the PCC allows reporting of direct mode loss
      measurement information; if set to 1 by a PCE, the N Flag
      indicates that the PCE is capable of receiving direct mode loss
      measurement information from the PCC.
 

Gandhi, et al.            Expires May 21, 2017                 [Page 14]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.

   Advertisement of the Loss-Measurement capability TLV implies support
   of loss measurement, as well as the objects, TLVs and procedures
   defined in this document.

4.2.  LOSS-MEASUREMENT-ATTRIBUTE TLV

   The LOSS-MEASUREMENT-ATTRIBUTE TLV provides the configurable
   parameters of the loss measurement feature.  This is an optional TLV
   defined for the LSPA Object.

   For PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with loss measurement
   feature enabled, this TLV is included in the LSPA Object with
   PCInitiate message.  The LOSS-MEASUREMENT-ATTRIBUTE TLV can also be
   carried in PCUpd message in LSPA Object in order to make updates to
   loss measurement attributes such as Measurement-Interval.

   The format of the LOSS-MEASUREMENT-ATTRIBUTE TLV is shown in the
   following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=TBD4           |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                            sub-TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  LOSS-MEASUREMENT-ATTRIBUTE TLV format

   Type: TBD4

   Length: Variable

   Value: Comprises one or more sub-TLVs.

   Following sub-TLVs are defined in this document:

   Type Len  Name
   ------------------------------------------------------------------
    0   4    Reserved
    1   4    Measurement-Enable sub-TLV
    2   4    Measurement-Interval sub-TLV
 

Gandhi, et al.            Expires May 21, 2017                 [Page 15]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

    3   4    Measurement-Mode sub-TLV
    4   4    Report-Threshold-Packets sub-TLV
    5   4    Report-Threshold-Bytes sub-TLV
    6   4    Report-Interval sub-TLV

   The Measurement-Enable sub-TLV MUST be added in the LSPA Object when
   the loss measurement feature is enabled for the LSP.  All other
   sub-TLVs are optional and any unrecognized sub-TLV MUST be silently
   ignored.  If a sub-TLV of same type appears more than once, only the
   first occurrence is processed and all others MUST be ignored.  If
   sub-TLVs are not present, the default values based on the local
   policy are assumed.

   The following sub-sections describe the sub-TLVs which are currently
   defined to be carried within this TLV.

4.2.1.  Measurement-Enable sub-TLV

   The Measurement-Enable sub-TLV specifies the loss measurement mode
   enabled.

   The Type is 1, Length is 4, and the value comprises of 4-octet. 
   Value is defined as following:

   Value    Name
   ------------------------------------------------------------------
    0       Loss Measurement Disabled
    1       Unidirectional Loss Measurement Enabled
    2       Bidirectional Loss Measurement Enabled

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=1              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Enable                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Enable sub-TLV format

4.2.2.  Measurement-Interval sub-TLV

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the measurement.

 

Gandhi, et al.            Expires May 21, 2017                 [Page 16]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   The Type is 2, Length is 4, and the value comprises of 4-octet time
   interval, the valid range is from 1 to 604800, in seconds.  The
   default value is 300 seconds.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=2              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Interval                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Interval sub-TLV format

4.2.3.  Measurement-Mode sub-TLV

   The Measurement-Mode sub-TLV specifies the loss measurement mode
   which can be direct or inferred.

   The Type is 3, Length is 4, and the value comprises of 4-octet loss
   measurement mode.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=3              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Measurement-Mode                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Measurement-Mode sub-TLV format

   Value     Name
   ------------------------------------------------------------------
    0        Inferred Mode (using test traffic)
    1        Direct Mode (using data traffic)

4.2.4.  Report-Threshold-Packets sub-TLV

   The Report-Threshold-Packets sub-TLV specifies the loss threshold
   value.

   The Type is 4, Length is 4, and the value comprises of 4-octet loss
   threshold values.

 

Gandhi, et al.            Expires May 21, 2017                 [Page 17]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=4              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Report-Threshold-Packets                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Threshold-Packets sub-TLV format

   The measured loss value MUST only be reported once the value exceeds
   the specified threshold value.  This reporting can be used to trigger
   an immediate action at the PCE peer.

4.2.5.  Report-Threshold-Bytes sub-TLV

   The Report-Threshold-Bytes sub-TLV specifies the loss threshold
   value.

   The Type is 5, Length is 4, and the value comprises of 4-octet loss
   threshold values.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=5              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Report-Threshold-Bytes                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Threshold-Bytes sub-TLV format

   The measured loss value MUST only be reported once the value exceeds
   the specified threshold value.  This reporting can be used to trigger
   an immediate action at the PCE peer.

4.2.6.  Report-Interval sub-TLV

   The Report-Interval sub-TLV specifies the time interval in seconds
   when measured loss values are to be reported.  Maximum value of the
   measured metric (e.g. packets-lost, bytes-lost) collected during the
   report interval is reported.

   The Type is 6, Length is 4, and the value comprises of 4-octet time
   interval, the valid range is from 1 to 604800, in seconds.  The
   default value equals to the Measurement-Interval.

 

Gandhi, et al.            Expires May 21, 2017                 [Page 18]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=6              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Report-Interval                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Interval sub-TLV format

   The measured loss value MUST be reported if the specified threshold
   is crossed OR the report-interval expires.  The periodic reporting
   can be used at the PCEP peer to monitor the LSP metrics.

4.3.  LOSS-MEASUREMENT Object

   The LOSS-MEASUREMENT Object with Object-Class (Value TBD6) is defined
   in this document to report the packet loss measurement of a TE LSP.

   When the LSP is enabled with the loss measurement feature, locally or
   by PCE, the PCC SHOULD include the LOSS-MEASUREMENT Object to report
   the measured packet loss to the PCE in the PCRpt message.

   Object-Types are defined as follows:

   Object-Type  Len   Name       
   --------------------------------------------------------------
    0           4     Reserved    
    1           4     Tx Packets-Lost
    2           4     Tx Bytes-Lost
    3           4     Rx Packets-Lost
    4           4     Rx Bytes-Lost

   The payload format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Packets-Lost                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Bytes-Lost                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

Gandhi, et al.            Expires May 21, 2017                 [Page 19]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

          LOSS-MEASUREMENT Object formats (Tx and Rx directions)

   o  Packets-Lost: Number of packets sent over the LSP were lost.

   o  Bytes-Lost: Number of Bytes sent over the LSP were lost.

   Packets and Bytes lost in the Rx direction is reported only when
   bidirectional loss measurement is enabled.

5.  PCEP Extensions for Reporting Bandwidth Usage

5.1.  BANDWIDTH-USAGE Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of bandwidth usage reporting.  A PCEP Speaker
   includes the "BANDWIDTH-USAGE-CAPABILITY" TLV, in the OPEN Object to
   advertise its support for PCEP extension.  The presence of the
   "BANDWIDTH-USAGE-CAPABILITY" TLV in the OPEN Object indicates that
   the Bandwidth Usage reporting is supported as described in this
   document.  

   The PCEP protocol extensions for Bandwidth Usage MUST NOT be used if
   one or both PCEP Speakers have not included the "BANDWIDTH-USAGE-
   CAPABILITY" TLV in their respective OPEN message.  If the PCEP
   speaker that supports the extensions of this draft but did not
   advertise this capability, then upon receipt of BANDWIDTH-USAGE-
   ATTRIBUTE TLV in LSPA object, it SHOULD generate a PCErr with error-
   type 19 (Invalid Operation), error-value TBD13 (Bandwidth usage
   capability was not advertised) and it will terminate the PCEP
   session.

5.1.1.  BANDWIDTH-USAGE-CAPABILITY TLV

   The BANDWIDTH-USAGE-CAPABILITY TLV is an optional TLV for use in the
   OPEN Object for Bandwidth Usage reporting via PCEP capability
   advertisement.  Its format is shown in the following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Type=[TBD14]    |            Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                           |B|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Gandhi, et al.            Expires May 21, 2017                 [Page 20]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

                  BANDWIDTH-USAGE-CAPABILITY TLV format

   The type of the TLV is (TBD14) and it has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits):

   o  B (bandwidth usage - 1 bit): if set to 1 by a PCC, the B Flag
      indicates that the PCC allows reporting of bandwidth usage
      information; if set to 1 by a PCE, the B Flag indicates that the
      PCE is capable of receiving bandwidth usage information from the
      PCC.  The BANDWIDTH-USAGE-ATTRIBUTE TLV MUST be encoded when both
      PCEP speakers have the B Flag set.

   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.

5.2.  BANDWIDTH-USAGE-ATTRIBUTE TLV

   The BANDWIDTH-USAGE-ATTRIBUTE TLV provides the 'configurable knobs'
   of the feature and it can be included as an optional TLV in the LSPA
   Object (as described in [RFC5440]).  

   For PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with bandwidth usage
   reporting enabled, this TLV is included in the LSPA Object with
   PCInitiate message.     

   The TLV is encoded in all PCEP messages for the LSP till the
   bandwidth usage reporting feature is enabled, the absence of the TLV
   indicate the PCEP speaker wish to disable this feature.   

   The format of the BANDWIDTH-USAGE-ATTRIBUTE TLV is shown in the
   following figure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=[TBD15]        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                           sub-TLVs                           //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    BANDWIDTH-USAGE-ATTRIBUTE TLV format

   Type: TBD15

 

Gandhi, et al.            Expires May 21, 2017                 [Page 21]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Length: Variable

   Value: This comprises one or more sub-TLVs.

   Following sub-TLVs are defined in this document:

   Type Len Name
   -------------------------------------------------------------------
   0    4   Reserved
   1    4   Report-Enable sub-TLV
   2    4   Report-Threshold sub-TLV
   3    4   Report-Interval sub-TLV
   4    4   Report-Threshold-Percentage sub-TLV
   5    4   Report-Flow-Threshold sub-TLV
   6    4   Report-Flow-Threshold-Percentage sub-TLV

   Future specification can define additional sub-TLVs.

   All sub-TLVs are optional and any unrecognized sub-TLV MUST be
   silently ignored.  If a sub-TLV of same type appears more than once,
   only the first occurrence is processed and all others MUST be
   ignored.

   The BANDWIDTH-USAGE-ATTRIBUTE TLV can also be carried in PCUpd
   message in LSPA Object in order to make updates to the attributes
   such as Report-Interval.

   If sub-TLVs are not present, the default values based on the local
   policy are assumed.

   The following sub-sections describe the sub-TLVs which are currently
   defined to be carried within the BANDWIDTH-USAGE-ATTRIBUTE TLV.

5.2.1.  Report-Enable sub-TLV

   The Report-Enable sub-TLV specifies that the Bandwidth-Usage
   reporting is enabled.

   The Type is 1, Length is 4, and the value comprises of 4-octet. Value
   is defined as following:

   Value     Name
   ------------------------------------------------------------------
    0        Bandwidth-Usage Reporting Disabled
    1        Bandwidth-Usage Reporting Enabled

    0                   1                   2                   3
 

Gandhi, et al.            Expires May 21, 2017                 [Page 22]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=1              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Report-Enable                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Report-Enable sub-TLV format

5.2.2.  Report-Threshold sub-TLV

   The Report-Threshold sub-TLV is used to decide when the bandwidth
   samples collected so far should be reported immediately, bypassing
   the report-interval.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=2              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Report-Threshold                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Threshold sub-TLV format

   The Type is 2, Length is 4, and the value comprises of -

   o  Threshold: The absolute threshold bandwidth value, encoded in IEEE
      floating point format (see [IEEE.754.1985]), expressed in bytes
      per second.  Refer to Section 3.1.2 of [RFC3471] for a table of
      commonly used values.  If the increase or the decrease of at least
      one of the bandwidth samples (BwSamples) collected so far compared
      to the current bandwidth reservation is greater than or equal to
      the threshold value, the bandwidth samples collected so far are
      reported.

5.2.3.  Report-Threshold-Percentage sub-TLV

   The Report-Threshold-Percentage sub-TLV is used to decide when the
   bandwidth samples collected so far should be reported immediately,
   bypassing the report-interval.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=3              |           Length=4            |
 

Gandhi, et al.            Expires May 21, 2017                 [Page 23]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reserved                       |  Percentage |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Report-Threshold-Percentage sub-TLV format

   The Type is 3, Length is 4, and the value comprises of -

   o  Reserved: SHOULD be set to zero on transmission and MUST be
      ignored on receipt.

   o  Percentage: The threshold value, encoded in percentage (an integer
      from 0 to 100).  If the percentage increase or the decrease of at
      least one of the bandwidth sample (BwSample) compared to the
      current bandwidth reservation is greater than or equal to the
      threshold percentage, the bandwidth samples collected so far are
      reported.

5.2.4.  Report-Interval sub-TLV

   The Report-Interval sub-TLV specifies a time interval in seconds in
   which collected bandwidth samples should be reported to PCE.

   The Type is 4, Length is 4, and the value comprises of 4-octet time
   interval, the valid range is from 1 to 604800, in seconds.  Default
   value is 3600 seconds.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=4              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Report-Interval                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Interval sub-TLV format

5.2.5.  Report-Flow-Threshold sub-TLV

   The Report-Flow-Threshold sub-TLV is used to decide when the
   bandwidth samples collected should be reported immediately, bypassing
   the report-interval.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

Gandhi, et al.            Expires May 21, 2017                 [Page 24]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   |           Type=5              |           Length=8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reserved                     |      Count    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Report-Flow-Threshold                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Report-Flow-Threshold sub-TLV format

   The Type is 5, Length is 8, and the value comprises of -

   o  Reserved: SHOULD be set to zero on transmission and MUST be
      ignored on receipt.

   o  Count: The Report-Flow-Count value, encoded in integer.  The value
      0 is considered to be invalid.  The number of consecutive samples
      for which the bandwidth usage report condition MUST be met for the
      the bandwidth samples collected so far are reported immediately,
      bypassing the report-interval.

   o  Threshold: The absolute flow threshold bandwidth value, encoded in
      IEEE floating point format (see [IEEE.754.1985]), expressed in
      bytes per second.  Refer to Section 3.1.2 of [RFC3471] for a table
      of commonly used values.  If the increase or the decrease of the
      current bandwidth sample (BwSample) compared to the current
      bandwidth reservation is greater than or equal to the flow
      threshold value, bandwidth usage report condition is said to be
      met.

5.2.6.  Report-Flow-Threshold-Percentage sub-TLV

   The Report-Flow-Threshold-Percentage sub-TLV is used to decide when
   the bandwidth samples collected should be reported immediately,
   bypassing the report-interval.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type=6              |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Percentage |    Reserved                     |      Count    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Report-Flow-Threshold-Percentage sub-TLV format

   The Type is 6, Length is 4, and the value comprises of -

   o  Reserved: SHOULD be set to zero on transmission and MUST be
 

Gandhi, et al.            Expires May 21, 2017                 [Page 25]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

      ignored on receipt.

   o  Percentage: The flow threshold value, encoded in percentage (an
      integer from 0 to 100).  If the percentage increase or the
      decrease of the current bandwidth sample (BwSample) compared to
      the current bandwidth reservation is greater than or equal to the
      threshold percentage, bandwidth usage report condition is said to
      be met.

   o  Count: The Report-Flow-Count value, encoded in integer.  The value
      0 is considered to be invalid.  The number of consecutive samples
      for which the bandwidth usage report condition MUST be met for the
      the bandwidth samples collected so far are reported immediately,
      bypassing the report-interval. 

5.3.  BANDWIDTH Object

   A new object-type for BANDWIDTH object is defined to report the real-
   time bandwidth usage of a TE LSP.

   The object-type is (TBD16), the object length is variable with
   multiples of 4 bytes.  The payload format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        BwSample1                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ...                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        BwSampleN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Bandwidth-Usage format

   o  BwSample: The actual bandwidth usage, (the BwSample collected at
      the end of each sample-interval) encoded in IEEE floating point
      format (see [IEEE.754.1985]), expressed in bytes per second.

   The Bandwidth-Usage object-type is used by the PCC to report the
   real-time bandwidth usage of a TE LSP to the PCE in the PCRpt
   message.

6.  The PCNtf Message

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
 

Gandhi, et al.            Expires May 21, 2017                 [Page 26]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   by a PCEP speaker to notify its peer of a specific event.  A PCEP
   speaker SHOULD notify its PCEP peer that it is overwhelmed, and on
   receipt of such notification the peer SHOULD NOT send any PCEP
   messages related to PM reporting.  If a PCEP message related to PM
   reporting is received, it MUST be silently ignored.

   When a PCEP speaker is overwhelmed, it SHOULD notify its peer by
   sending a PCNtf message with Notification Type = TBD17 (PM Overwhelm
   State) and Notification Value = 1 (Entering overwhelm state). 
   Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY be included that
   specifies the time period during which no further PCEP messages
   related to PM reporting should be sent.  When the PCEP speaker is no
   longer in the overwhelm state and is available to process the PM
   reporting, it SHOULD notify its peer by sending a PCNtf message with
   Notification Type = TBD17 (PM Overwhelm State) and Notification Value
   = 2 (Clearing PM overwhelm state). 

7.  Security Considerations

   This document defines new MEASUREMENT objects and ATTRIBUTE TLVs for
   reporting loss, delay measurements and bandwidth-usage which do not
   add additional security concerns beyond those discussed in [RFC5440]
   and [DRAFT-PCE-STATEFUL].

   Some deployments may find the reporting of the network performance
   measurement information as extra sensitive and thus should employ
   suitable PCEP security mechanisms like TCP-AO or [DRAFT-PCE-PCEPS].

 

Gandhi, et al.            Expires May 21, 2017                 [Page 27]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

8.  IANA Considerations

8.1.  MEASUREMENT-CAPABILITY TLV Flag Field

   IANA is requested to create a registry to manage the Flag field of
   the DELAY-MEASUREMENT-CAPABILITY TLV and LOSS-MEASUREMENT-CAPABILITY
   TLV.

   New bit numbers to be allocated only by an IETF Consensus action. 
   Each bit should be tracked with the following qualities:

      o  Bit number (counting from bit 0 as the most significant bit)

      o  Capability description

      o  Defining RFC

   Following types for DELAY-MEASUREMENT-CAPABILITY, LOSS-MEASUREMENT-
   CAPABILITY, BANDWIDTH-USAGE TLVs are defined in this document:

   Type      Name                                 Reference
   ----------------------------------------------------------
    TBD1     DELAY-MEASUREMENT-CAPABILITY         [This I.D.]
    TBD2     LOSS-MEASUREMENT-CAPABILITY          [This I.D.]
    TBD14    BANDWIDTH-USAGE-CAPABILITY           [This I.D.]

8.2.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs; IANA is requested
   to make the following allocations from this registry.  (see
   <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
   indicators> )

   Value     Name                                 Reference
   ----------------------------------------------------------
    TBD3     DELAY-MEASUREMENT-ATTRIBUTE          [This I.D.]
    TBD4     LOSS-MEASUREMENT-ATTRIBUTE           [This I.D.]
    TBD15    BANDWIDTH-USAGE-ATTRIBUTE            [This I.D.]

8.2.1.  DELAY-MEASUREMENT-ATTRIBUTE Sub-TLVs

   This document specifies the DELAY-MEASUREMENT-ATTRIBUTE Sub-TLVs. 
   IANA is requested to create an "DELAY-MEASUREMENT-ATTRIBUTE Sub-TLV
   Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-
   TLVs carried in the DELAY-MEASUREMENT-ATTRIBUTE TLV.  This document
   defines the following types:

 

Gandhi, et al.            Expires May 21, 2017                 [Page 28]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   Type      Name                                 Reference
   ----------------------------------------------------------
    0        Reserved                             [This I.D.]
    1        Measurement-Enable sub-TLV           [This I.D.]
    2        Measurement-Interval sub-TLV         [This I.D.]
    3        Measurement-Mode sub-TLV             [This I.D.]
    4        Report-Threshold sub-TLV             [This I.D.]
    5        Report-Interval sub-TLV              [This I.D.]
    6-       Unassigned                           [This I.D.]
   65535

8.2.2.  LOSS-MEASUREMENT-ATTRIBUTE Sub-TLVs

   This document specifies the LOSS-MEASUREMENT-ATTRIBUTE Sub-TLVs. 
   IANA is requested to create an "LOSS-MEASUREMENT-ATTRIBUTE Sub-TLV
   Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-
   TLVs carried in the LOSS-MEASUREMENT-ATTRIBUTE TLV.  This document
   defines the following types:

   Type      Name                                 Reference
   ----------------------------------------------------------
    0        Reserved                             [This I.D.]
    1        Measurement-Enable sub-TLV           [This I.D.]
    2        Measurement-Interval sub-TLV         [This I.D.]
    3        Measurement-Mode sub-TLV             [This I.D.]
    4        Report-Threshold-Packet sub-TLV      [This I.D.]
    5        Report-Threshold-Bytes sub-TLV       [This I.D.]
    6        Report-Interval sub-TLV              [This I.D.]
    7-       Unassigned                           [This I.D.]
   65535

8.2.3.  BANDWIDTH-USAGE-ATTRIBUTE Sub-TLV

   This document specifies the BANDWIDTH-USAGE-ATTRIBUTE Sub-TLVs.  IANA
   is requested to create an "BANDWIDTH-USAGE-ATTRIBUTE Sub-TLV Types"
   sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs
   carried in the BANDWIDTH-USAGE-ATTRIBUTE TLV.  This document defines
   the following types:

   Type      Name                                 Reference
   --------------------------------------------------------------
    0        Reserved                             [This I.D.]
    1        Report-Enable sub-TLV                [This I.D.]
    2        Report-Threshold sub-TLV             [This I.D.]
    3        Report-Threshold-Percentage sub-TLV  [This I.D.]
    4        Report-Interval sub-TLV              [This I.D.]
    5        Report-Flow-Threshold sub-TLV        [This I.D.]
    6        Report-Flow-Threshold percentage     [This I.D.]
 

Gandhi, et al.            Expires May 21, 2017                 [Page 29]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

             sub-TLV
    7-       Unassigned                           [This I.D.]
   65535

8.3.  DELAY-MEASUREMENT Object

   This document defines Object-Class for the DELAY-MEASUREMENT Object;
   IANA is requested to make the following allocations from this
   registry.  (see
   <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects>).

   Object-Class  Name                             Reference
   ----------------------------------------------------------
    TBD5         DELAY-MEASUREMENT Object         [This I.D.]

8.3.1.  DELAY-MEASUREMENT Object-Types

   This document specifies the DELAY-MEASUREMENT Object-Types.  IANA is
   requested to create an "DELAY-MEASUREMENT Object-Types" sub-registry
   for DELAY-MEASUREMENT Object.  This document defines the following
   types:

   Type      Name                                       Reference
   ---------------------------------------------------------------
    0        Reserved                                   [This I.D.]
    1        One-Way Delay Measurement Value            [This I.D.]
    2        One-Way Delay Measurement Min/Max Values   [This I.D.]
    3        One-Way Delay Variation Measurement Value  [This I.D.]
    4        Two-Way Delay Measurement Value            [This I.D.]
    5        Two-Way Delay Measurement Min/Max Values   [This I.D.]
    6        Two-Way Delay Variation Measurement Value  [This I.D.]

8.4.  LOSS-MEASUREMENT Object

   This document defines Object-Class for the LOSS-MEASUREMENT Object;
   IANA is requested to make the following allocations from this
   registry.  (see
   <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects>).

   Object-Class   Name                            Reference
   ----------------------------------------------------------
    TBD6          LOSS-MEASUREMENT Object         [This I.D.]

8.4.1.  LOSS-MEASUREMENT Object-Types

   This document specifies the LOSS-MEASUREMENT Object-Types.  IANA is
 

Gandhi, et al.            Expires May 21, 2017                 [Page 30]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   requested to create an "LOSS-MEASUREMENT Object-Types" sub-registry
   for LOSS-MEASUREMENT Object.  This document defines the following
   types:

   Type      Name                                 Reference
   ----------------------------------------------------------
    0        Reserved                             [This I.D.]
    1        Tx Packets-Lost                      [This I.D.]
    2        Tx Bytes-Lost                        [This I.D.]
    3        Rx Packets-Lost                      [This I.D.]
    4        Rx Bytes-Lost                        [This I.D.]

8.5.  BANDWIDTH Object

   This document defines new Object-Type for the BANDWIDTH object
   (Object-Class 5, [RFC5440]); IANA is requested to make the following
   allocation from this registry.
   <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects>.

   Object-Type   Name                             Reference
   -----------------------------------------------------------
    TBD16        Bandwidth-Usage Report           [This I.D.]

8.6.  PCE Error Codes

   This document defines two new error-values for PCErr with error-code
   19 (Invalid Operation).  IANA is requested to make the following
   allocations.

   Error-Value    Name                                      Reference
   --------------------------------------------------------------------
    TBD7  Delay-Measurement capability was not advertised   [This I.D.]
    TBD8  Loss-Measurement capability was not advertised    [This I.D.]
    TBD9  Bidirectional Measurement capability 
                                         was not advertised [This I.D.]
    TBD10 Unidirectional Measurement capability
                                         was not advertised [This I.D.]
    TBD11 Inferred Mode Measurement capability 
                                         was not advertised [This I.D.]
    TBD12 Direct Mode Measurement capability 
                                         was not advertised [This I.D.]
    TBD13 Bandwidth usage capability was not advertised     [This I.D.]

8.7.  Notification Object

 

Gandhi, et al.            Expires May 21, 2017                 [Page 31]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

   IANA is requested to allocate new Notification Types and Notification
   Values within the "Notification Object" sub-registry of the PCEP
   Numbers registry, as follows:

   Type        Meaning                                 Reference
   ---------------------------------------------------------------
    TBD17      PM Overwhelm State                      [This I.D.]

               Notification-value=1:  Entering PM overwhelm state
               Notification-value=2:  Clearing PM overwhelm state

 

Gandhi, et al.            Expires May 21, 2017                 [Page 32]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

9.  References

9.1.  Normative References

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

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March
              2009.

   [DRAFT-PCE-STATEFUL]  Crabbe, E., Minei, I., Medved, J., and R.
              Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-
              stateful-pce, (work in progress).

   [DRAFT-PCE-INITIATED-LSP]  Crabbe, E., Minei, I., Sivabalan, S., and
              R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in
              a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp,
              (work in progress).

9.2.  Informative References

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586, June 2009.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", DOI 10.17487/RFC6374, RFC
              6374, September 2011.

   [RFC6375]  Frost, D. and S. Bryant, "A Packet Loss and Delay
              Measurement Profile for MPLS-Based Transport Networks",
              RFC 6375, September 2011.

   [RFC7471]  S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi,
              "OSPF Traffic Engineering (TE) Metric Extensions", RFC
              7471, March 2015. 

   [RFC7810]  S. Previdi, S. Giacalone, D. Ward, J. Drake, Q. Wu, "IS-IS
              Traffic Engineering (TE) Metric Extensions", RFC 7810, May
              2016.

   [RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
              "Performance-Based Path Selection for Explicitly Routed
 

Gandhi, et al.            Expires May 21, 2017                 [Page 33]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

              Label Switched Paths (LSPs) Using TE Metric Extensions",
              RFC 7823, May 2016.

   [RFC7876]  Bryant, S., Sivabalan, S., Soni, S., "UDP Return Path for
              Packet Loss and Delay Measurement for MPLS Networks", RFC
              7876, July 2016.

   [DRAFT-PCE-PCEPS]  Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
              Transport for PCEP", draft-ietf-pce-pceps, (work in
              progress).

   [DRAFT-PCE-SERVICE-AWARE]  Dhody, D., V. Manral, V., Ali, Z., Kumaki,
              K., "Extensions to the Path Computation Element
              Communication Protocol (PCEP) to compute service aware
              Label Switched Path (LSP)", draft-ietf-pce-pcep-service-
              aware, (work in progress).

   [DRAFT-IDR-TE-PM-BGP]  Wu, Q., Danhua, W., Previdi, S., Gredler, H.,
              and S. Ray, "BGP attribute for North-Bound Distribution of
              Traffic Engineering (TE) performance Metrics", draft-ietf-
              idr-te-pm-bgp (work in progress).

   [IEEE.754.1985]  Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic", IEEE
              Standard 754, August 1985.

 

Gandhi, et al.            Expires May 21, 2017                 [Page 34]
Internet-Draft      PCEP for Performance Measurement   November 17, 2016

Acknowledgments

   TBA.

Authors' Addresses

   Rakesh Gandhi
   Individual Contributor

   EMail: rgandhi.ietf@gmail.com

   Bin Wen
   Comcast

   EMail: Bin_Wen@cable.comcast.com

   Colby Barth
   Juniper Networks

   EMail: cbarth@juniper.net

   Dhruv Dhody
   Huawei Technologies

   EMail: dhruv.ietf@gmail.com

Gandhi, et al.            Expires May 21, 2017                 [Page 35]