PCE Working Group R. Gandhi
Internet-Draft Individual Contributor
Intended Status: Standards Track B. Wen
Expires: September 1, 2017 Comcast
C. Barth
Juniper Networks
D. Dhody
Huawei Technologies
February 28, 2017
PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements
draft-gandhi-pce-pm-05
Abstract
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow Stateful control of Multi-Protocol
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
LSPs) using PCEP.
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 for both PCE-Initiated and PCC-Initiated LSPs.
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
Gandhi, et al. Expires September 1, 2017 [Page 1]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2017 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. Auto-bandwidth Considerations . . . . . . . . . . . . . . 5
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of the PCEP Extensions . . . . . . . . . . . . . . . 6
4. PCEP Extensions for Reporting Delay Measurement . . . . . . . 7
4.1. DELAY-MEASUREMENT Capability Advertisement . . . . . . . . 7
4.1.1. DELAY-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . . 8
4.2. DELAY-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . . 9
4.2.1. Measurement-Enable sub-TLV . . . . . . . . . . . . . . 10
4.2.2. Measurement-Interval sub-TLV . . . . . . . . . . . . . 10
4.2.3. Measurement-Mode sub-TLV . . . . . . . . . . . . . . . 11
4.2.4. Report-Threshold sub-TLV . . . . . . . . . . . . . . . 11
4.2.5. Report-Interval sub-TLV . . . . . . . . . . . . . . . 12
4.3. DELAY-MEASUREMENT Object . . . . . . . . . . . . . . . . . 12
5. PCEP Extensions for Reporting Loss Measurement . . . . . . . . 14
5.1. LOSS-MEASUREMENT Capability Advertisement . . . . . . . . 14
5.1.1. LOSS-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . . 15
Gandhi, et al. Expires September 1, 2017 [Page 2]
Internet-Draft PCEP for Performance Measurement February 28, 2017
5.2. LOSS-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . . 16
5.2.1. Measurement-Enable sub-TLV . . . . . . . . . . . . . . 17
5.2.2. Measurement-Interval sub-TLV . . . . . . . . . . . . . 18
5.2.3. Measurement-Mode sub-TLV . . . . . . . . . . . . . . . 18
5.2.4. Report-Threshold-Packets sub-TLV . . . . . . . . . . . 19
5.2.5. Report-Threshold-Bytes sub-TLV . . . . . . . . . . . . 19
5.2.6. Report-Interval sub-TLV . . . . . . . . . . . . . . . 20
5.3. LOSS-MEASUREMENT Object . . . . . . . . . . . . . . . . . 20
6. PCEP Extensions for Reporting Bandwidth Usage . . . . . . . . 22
6.1. BANDWIDTH-USAGE Capability Advertisement . . . . . . . . . 22
6.1.1. BANDWIDTH-USAGE-CAPABILITY TLV . . . . . . . . . . . . 22
6.2. BANDWIDTH-USAGE-ATTRIBUTES TLV . . . . . . . . . . . . . . 23
6.2.1. Measurement-Enable sub-TLV . . . . . . . . . . . . . . 24
6.2.2. Measurement-Interval sub-TLV . . . . . . . . . . . . . 24
6.2.3. Report-Threshold sub-TLV . . . . . . . . . . . . . . . 25
6.2.4. Report-Threshold-Percentage sub-TLV . . . . . . . . . 25
6.2.5. Report-Interval sub-TLV . . . . . . . . . . . . . . . 26
6.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 26
7. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 28
8.1. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. Manageability Considerations . . . . . . . . . . . . . . . . 29
10.1. Control of Function and Policy . . . . . . . . . . . . . 29
10.2. Information and Data Models . . . . . . . . . . . . . . . 29
10.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29
10.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29
10.5. Requirements On Other Protocols . . . . . . . . . . . . . 29
10.6. Impact On Network Operations . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.1. MEASUREMENT-CAPABILITY TLV Types . . . . . . . . . . . . 31
11.2. MEASUREMENT-ATTRIBUTES TLV Types . . . . . . . . . . . . 31
11.2.1. DELAY-MEASUREMENT-ATTRIBUTES Sub-TLVs . . . . . . . . 31
11.2.2. LOSS-MEASUREMENT-ATTRIBUTES Sub-TLVs . . . . . . . . 32
11.2.3. BANDWIDTH-USAGE-ATTRIBUTES Sub-TLV . . . . . . . . . 32
11.3. MEASUREMENT Object-Class . . . . . . . . . . . . . . . . 33
11.3.1. DELAY-MEASUREMENT Object-Types . . . . . . . . . . . 33
11.3.2. LOSS-MEASUREMENT Object-Types . . . . . . . . . . . . 33
11.3.3. BANDWIDTH Object-Type . . . . . . . . . . . . . . . . 34
11.4. PCE Error Codes . . . . . . . . . . . . . . . . . . . . . 34
11.5. Notification Object . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Gandhi, et al. Expires September 1, 2017 [Page 3]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 to PCEP to enable Stateful
control of TE LSPs. It describes two mode of operations - Passive
Stateful PCE and Active Stateful PCE. Further [DRAFT-PCE-INITIATED-
LSP] describes the setup, maintenance and teardown of PCE-Initiated
LSPs for the Stateful PCE model. In this document, the focus is on
Active Stateful PCE where the LSPs are controlled by the PCE, for
both PCE-Initiated and PCC-Initiated LSPs.
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. The protocol extensions have been defined to advertise
link performance metrics, see [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. Such path computations use link properties for
packet loss and delay and do not provide end-to-end LSP metrics.
There is a need to verify and monitor that the traffic sent over the
established TE LSP does not exceed the requested metric bounds (e.g.
total end-to-end delay). [RFC6374], [RFC6375] and [RFC7876] define
protocol extensions needed for measuring packet loss, delay and delay
variation (jitter) for bidirectional and unidirectional TE LSPs end-
to-end in real-time.
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,
for both PCE-Initiated and PCC-Initiated LSPs.
1.1. Dependencies and Considerations
[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.
Gandhi, et al. Expires September 1, 2017 [Page 4]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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
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. Auto-bandwidth Considerations
Auto-Bandwidth feature allows a head-end LSR (PCC) to automatically
adjust the LSP bandwidth reservation based on the traffic demand of a
TE LSP. Auto-bandwidth requested bandwidth computation can be
implemented on a PCC or a Stateful PCE.
[DRAFT-IETF-PCE-AUTOBW] describes the PCEP extensions for auto-
bandwidth, where the requested bandwidth for the LSP is computed by
the PCC and reported to the Stateful PCE. There is a benefit in
pushing the responsibility for deciding when auto-bandwidth
adjustments are needed to the PCC as this distributes the load of
monitoring the bandwidth usage of the LSPs down to the PCCs and frees
up the PCE for path computations. In addition, it reduces the load
on PCEP communications for reporting the bandwidth usage of the LSP.
However, exactly when to adjust an LSP bandwidth could be better left
to a Stateful PCE. That is, a PCE could be flexible in its
interpretation of thresholds enabling it to trigger auto-bandwidth
adjustment early if it believes there is a good reason (for example,
doing a set of parallel path re-computations) or late (for example,
when it knows that an adjustment would be disruptive to the network).
When the auto-bandwidth computation is delegated to the PCC, the PCC
cannot see the impact on other LSPs in the network, and the PCE
cannot tell whether the request to adjust the LSP bandwidth is
critical or not. The bandwidth usage reporting defined in this
document can be used by the PCE to do computations to determine
whether auto-bandwidth adjustments are needed and/or desirable before
performing the path computations.
2. Conventions Used in This Document
2.1. Requirements Language
Gandhi, et al. Expires September 1, 2017 [Page 5]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 reader is assumed to be familiar with the terminology defined in
[RFC5440] and [RFC6374].
3. Overview of the PCEP Extensions
The 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 ATTRIBUTES
| | (For delegated LSPs)
| |
| | MEASUREMENT REPORTS
v |
---------
| |
| PCC |
| |
---------
Figure 1: Overview of PCEP Extensions
The PCEP extensions for reporting performance measurements comprise
of the following:
o The Stateful PCE and PCC (head-end of the LSP) advertise the
capability of their support for the delay, loss and bandwidth-
usage measurements and reporting in the PCEP Open message (in the
OPEN Object).
o The Stateful PCE enables the measurement of a feature and sends
and updates the configuration parameters of the feature using the
LSPA object to PCC in PCInitiate and PCUpd messages respectively.
Gandhi, et al. Expires September 1, 2017 [Page 6]
Internet-Draft PCEP for Performance Measurement February 28, 2017
o The PCC reports the measured values of the feature to the Stateful
PCE at the end of the specified report-interval or when measured
values cross the specified report-threshold. The periodic
reporting can be used at the PCE to monitor the TE LSP metrics
whereas report-threshold can be used to trigger an immediate
action at the PCE on the TE LSP.
o The PCE and PCC notify of their entering and clearing the
overwhelmed state when operating under higher LSP scale.
4. PCEP Extensions for Reporting Delay Measurement
4.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 (in the Open message) indicates that the Delay
Measurement capability is supported as described in this document.
Additional procedure is defined as following:
o 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.
o If the PCEP speaker that supports the extensions of this document
but did not advertise this capability, then upon receipt of DELAY-
MEASUREMENT-ATTRIBUTES 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.
o 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-ATTRIBUTES TLV in LSPA object
with two-way measurement request and one-way measurement request,
respectively, when it did not advertise this capability.
o 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-ATTRIBUTES TLV in LSPA object with
Inferred Mode delay measurement request and Direct Mode delay
measurement request, respectively, when it did not advertise this
Gandhi, et al. Expires September 1, 2017 [Page 7]
Internet-Draft PCEP for Performance Measurement February 28, 2017
capability.
4.1.1. DELAY-MEASUREMENT-CAPABILITY TLV
The DELAY-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in
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-MEASUREMENT-ATTRIBUTES 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
Gandhi, et al. Expires September 1, 2017 [Page 8]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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.
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.
4.2. DELAY-MEASUREMENT-ATTRIBUTES TLV
The DELAY-MEASUREMENT-ATTRIBUTES TLV provides the configurable
parameters of the delay measurement feature.
The format of the DELAY-MEASUREMENT-ATTRIBUTES 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-ATTRIBUTES TLV Format
PCEP TLV Type: TBD3
Length: The Length field defines the length of the value portion
in bytes as per [RFC5440].
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
3 4 Measurement-Mode sub-TLV
4 4 Report-Threshold sub-TLV
Gandhi, et al. Expires September 1, 2017 [Page 9]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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.
4.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
------------------------------------------------------------------
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
4.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
interval, the valid range is from 1 to 604800, in seconds. The
default value is 300 seconds.
0 1 2 3
Gandhi, et al. Expires September 1, 2017 [Page 10]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 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 Direct Mode (using data traffic) (default mode)
1 Inferred Mode (using test traffic)
4.2.4. Report-Threshold sub-TLV
The Report-Threshold sub-TLV specifies the threshold value used to
trigger an immediate reporting of the measurements bypassing the
report-interval. It is used to detect a sudden change in the
performance measurement metric of a TE LSP. In order to detect that
a measured value has crossed the threshold, the average delay (or
average delay variance, etc.) is compared from the last reported
interval and the current interval. If the change (increase or
decrease) is above the threshold, the new measurement is reported
immediately. The measurements are still reported at the end of the
report-interval even if they were reported due to crossing of the
threshold.
The Type is 4, Length is 4, and the value comprises of 4-octet delay
threshold value. By default, report-threshold check is disabled.
Gandhi, et al. Expires September 1, 2017 [Page 11]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Threshold sub-TLV Format
o Report-Threshold: Absolute value of the delay, encoded as 24-bit
integer, as defined in RFC 7471 [RFC7471]. The report-threshold
is used for delay and delay variation measurements.
The measured delay value MUST be reported immediately once the value
exceeds the specified threshold value.
4.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.
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 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=5 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Interval sub-TLV Format
The measured delay value MUST be reported when the specified report-
interval expires.
4.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.
Gandhi, et al. Expires September 1, 2017 [Page 12]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class=TBD5 | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DELAY-MEASUREMENT Object Format
Object Length (16 bits): Specifies the total object length including
the header, in bytes [RFC5440].
Object-Types (OT) are defined as follows:
Object-Type Len Name
--------------------------------------------------------------
0 8 Reserved
1 8 One-Way Delay Measurement Value
2 12 One-Way Delay Measurement Min/Max Values
3 8 One-Way Delay Variation Measurement Value
4 8 Two-Way Delay Measurement Value
5 12 Two-Way Delay Measurement Min/Max Values
6 8 Two-Way Delay Variation Measurement Value
The object body format is as following:
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
Gandhi, et al. Expires September 1, 2017 [Page 13]
Internet-Draft PCEP for Performance Measurement February 28, 2017
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Variation Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DELAY-MEASUREMENT Object Body 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.
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.
5. PCEP Extensions for Reporting Loss Measurement
5.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 (in the Open
message) indicates that the Loss Measurement capability is supported
as described in this document. Additional procedure is defined as
following:
o 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.
Gandhi, et al. Expires September 1, 2017 [Page 14]
Internet-Draft PCEP for Performance Measurement February 28, 2017
o If the PCEP speaker that supports the extensions of this document
but did not advertise this capability, then upon receipt of LOSS-
MEASUREMENT-ATTRIBUTES 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.
o 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-ATTRIBUTES TLV in LSPA object
with two-way measurement request and one-way measurement request,
respectively, when it did not advertise this capability.
o 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-ATTRIBUTES TLV in LSPA object with
Inferred Mode loss measurement request and Direct Mode loss
measurement request, respectively, when it did not advertise this
capability.
5.1.1. LOSS-MEASUREMENT-CAPABILITY TLV
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-ATTRIBUTES TLV MUST be encoded when
Gandhi, et al. Expires September 1, 2017 [Page 15]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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.
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.
5.2. LOSS-MEASUREMENT-ATTRIBUTES TLV
The LOSS-MEASUREMENT-ATTRIBUTES TLV provides the configurable
parameters of the loss measurement feature.
The format of the LOSS-MEASUREMENT-ATTRIBUTES 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Gandhi, et al. Expires September 1, 2017 [Page 16]
Internet-Draft PCEP for Performance Measurement February 28, 2017
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT-ATTRIBUTES TLV Format
PCEP TLV Type: TBD4
Length: The Length field defines the length of the value portion
in bytes as per [RFC5440].
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
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.
5.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
------------------------------------------------------------------
1 Unidirectional Loss Measurement Enabled
2 Bidirectional Loss Measurement Enabled
Gandhi, et al. Expires September 1, 2017 [Page 17]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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
5.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
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
5.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
Gandhi, et al. Expires September 1, 2017 [Page 18]
Internet-Draft PCEP for Performance Measurement February 28, 2017
Value Name
------------------------------------------------------------------
0 Direct Mode (using data traffic) (default mode)
1 Inferred Mode (using test traffic)
5.2.4. Report-Threshold-Packets sub-TLV
The Report-Threshold-Packets sub-TLV specifies the threshold value
used to trigger an immediate reporting of the measurements bypassing
the report-interval. It is used to detect a sudden change in the
performance measurement metric of a TE LSP. In order to detect that
a measured value has crossed the threshold, the sum of packet loss is
compared from the last reported interval and the current interval.
If the change (increase or decrease) is above the threshold, the new
measurement is reported immediately. The measurements are still
reported at the end of the report-interval even if they were reported
due to crossing of the threshold.
The Type is 4, Length is 4, and the value comprises of 4-octet loss
threshold values. By default, report-threshold check is disabled.
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
o Report-Threshold-Packets: Absolute value of the total number of
packets.
The measured loss value MUST be reported immediately once the value
exceeds the specified threshold value. This reporting can be used to
trigger an immediate action at the PCE.
5.2.5. Report-Threshold-Bytes sub-TLV
The Report-Threshold-Bytes sub-TLV specifies the threshold value used
to trigger an immediate reporting of the measurements bypassing the
report-interval. It is used to detect a sudden change in the
performance measurement metric of a TE LSP. In order to detect that
a measured value has crossed the threshold, the sum of Byte loss is
compared from the last reported interval and the current interval.
If the change (increase or decrease) is above the threshold, the new
measurement is reported immediately. The measurements are still
Gandhi, et al. Expires September 1, 2017 [Page 19]
Internet-Draft PCEP for Performance Measurement February 28, 2017
reported at the end of the report-interval even if they were reported
due to crossing of the threshold.
The Type is 5, Length is 4, and the value comprises of 4-octet loss
threshold values. By default, report-threshold check is disabled.
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
o Report-Threshold-Bytes: Absolute value of the total number of
bytes.
The measured loss value MUST be reported immediately once the value
exceeds the specified threshold value.
5.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.
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 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=6 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Interval sub-TLV Format
The measured loss value MUST be reported when the specified report-
interval expires.
5.3. LOSS-MEASUREMENT Object
The LOSS-MEASUREMENT Object with Object-Class (Value TBD6) is defined
Gandhi, et al. Expires September 1, 2017 [Page 20]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class=TBD6 | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT Object Format
Object Length (16 bits): Specifies the total object length including
the header, in bytes [RFC5440].
Object-Types (OT) are defined as following:
Object-Type Len Name
--------------------------------------------------------------
0 8 Reserved
1 8 Tx Packets-Lost
2 8 Tx Bytes-Lost
3 8 Rx Packets-Lost
4 8 Rx Bytes-Lost
The object body format is as following:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT Object Body Formats (Tx and Rx)
Gandhi, et al. Expires September 1, 2017 [Page 21]
Internet-Draft PCEP for Performance Measurement February 28, 2017
o Packets-Lost: Total number of packets sent over the LSP were lost
(sum of all samples).
o Bytes-Lost: Total number of Bytes sent over the LSP were lost (sum
of all samples).
The Packets-Lost and Bytes-Lost in the Rx direction are reported when
bidirectional loss measurement is enabled.
6. PCEP Extensions for Reporting Bandwidth Usage
6.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 (in the Open
message) indicates that the Bandwidth Usage reporting is supported as
described in this document. Additional procedure is defined as
following:
o 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.
o If the PCEP speaker that supports the extensions of this document
but did not advertise this capability, then upon receipt of
BANDWIDTH-USAGE-ATTRIBUTES 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.
6.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 September 1, 2017 [Page 22]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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-ATTRIBUTES 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.
6.2. BANDWIDTH-USAGE-ATTRIBUTES TLV
The BANDWIDTH-USAGE-ATTRIBUTES TLV provides the configurable
parameters of the bandwidth usage feature.
The format of the BANDWIDTH-USAGE-ATTRIBUTES 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-ATTRIBUTES TLV Format
PCEP TLV Type: TBD15
Length: The Length field defines the length of the value portion
in bytes as per [RFC5440].
Value: Comprises one or more sub-TLVs.
Following sub-TLVs are defined in this document:
Type Len Name
-------------------------------------------------------------------
0 4 Reserved
Gandhi, et al. Expires September 1, 2017 [Page 23]
Internet-Draft PCEP for Performance Measurement February 28, 2017
1 4 Measurement-Enable sub-TLV
2 4 Measurement-Interval sub-TLV
3 4 Report-Threshold sub-TLV
4 4 Report-Threshold-Percentage sub-TLV
5 4 Report-Interval 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.
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-ATTRIBUTES TLV.
6.2.1. Measurement-Enable sub-TLV
The Measurement-Enable sub-TLV specifies that the BANDWIDTH-USAGE
measurement is enabled.
The Type is 1, Length is 4, and the value comprises of 4-octet. Value
is defined as following:
Value Name
------------------------------------------------------------------
1 Bandwidth Usage Reporting 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
6.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
interval, the valid range is from 1 to 604800, in seconds. The
Gandhi, et al. Expires September 1, 2017 [Page 24]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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
6.2.3. Report-Threshold sub-TLV
The Report-Threshold sub-TLV is used to decide if the bandwidth
samples collected so far should be immediately reported bypassing the
report-interval. It is used to detect a sudden change in the
bandwidth usage of a TE LSP. In order to detect that a bandwidth
usage has crossed the threshold, the average bandwidth usage (or the
maximum bandwidth sample) is compare from the last reported interval
and the current interval. If the change (increase or decrease) is
above the threshold, the bandwidth samples collected so far in the
report-interval are reported immediately. By default, report-
threshold check is disabled.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Threshold sub-TLV Format
The Type is 3, 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.
6.2.4. Report-Threshold-Percentage sub-TLV
The Report-Threshold-Percentage sub-TLV is used to decide if the
bandwidth samples collected so far should be immediately reported
bypassing the report-interval. By default report-threshold check is
disabled.
Gandhi, et al. Expires September 1, 2017 [Page 25]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Threshold-Percentage sub-TLV Format
The Type is 4, 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).
6.2.5. Report-Interval sub-TLV
The Report-Interval sub-TLV specifies a time interval in seconds when
collected bandwidth samples are to be reported to PCE.
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 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=5 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Interval sub-TLV Format
The collected bandwidth sample values MUST be reported when the
specified report-interval expires.
6.3. BANDWIDTH Object
A new object-type for BANDWIDTH object (Object-Class 5) is defined to
report the real-time bandwidth usage of a TE LSP.
When the TE LSP is enabled with the bandwidth usage reporting,
locally or by PCE, the PCC SHOULD include the BANDWIDTH-USAGE Object
to report the real-time bandwidth usage of the TE LSP to the PCE in
Gandhi, et al. Expires September 1, 2017 [Page 26]
Internet-Draft PCEP for Performance Measurement February 28, 2017
the PCRpt message.
The object-type is (TBD16), the object length is variable with
multiples of 4 bytes. The payload format is defined as following:
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 Object Format
o BwSample: The actual bandwidth usage, (the BwSample collected at
the end of each measurement-interval) encoded in IEEE floating
point format (see [IEEE.754.1985]), expressed in bytes per second.
7. PCEP Messages
Following procedure is defined for the extensions to different PCEP
messages for reporting performance measurements.
o MEASUREMENT-ATTRIBUTES TLV is an optional TLV defined for the LSPA
Object [RFC5440].
o For PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with a feature
enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV MUST be
included in the LSPA Object with PCInitiate message.
o For PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with a feature
enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV is carried
in PCUpd message in the LSPA Object in order to make updates to
the attributes such as Report-Interval.
o For PCC-Initiated LSP with a feature enabled, when the LSP is
delegated to the PCE, the corresponding MEASUREMENT-ATTRIBUTES TLV
MUST be included in the LSPA Object of the PCRpt message.
o The MEASUREMENT-ATTRIBUTES TLV is encoded in all PCEP messages for
the LSP with a feature enabled, the absence of the corresponding
MEASUREMENT-ATTRIBUTES TLV indicates that the PCEP speaker wishes
to disable the feature.
Gandhi, et al. Expires September 1, 2017 [Page 27]
Internet-Draft PCEP for Performance Measurement February 28, 2017
o When an LSP is enabled with a measurement reporting feature,
locally or by PCE, the PCC SHOULD include the corresponding
MEASUREMENT Object to report the measured values to the PCE in the
PCRpt message.
8. Scaling Considerations
It should be noted that when measurement reporting is deployed under
LSP scale, it can lead to frequent notification updates to the PCE.
Operators are advised to set the values of various measurement
reporting parameters appropriate for the deployed LSP scale.
If a PCE gets overwhelmed, it can notify the PCC to temporarily
suspend the reporting of the measurements as described below.
8.1. The PCNtf Message
As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
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 measurement reporting. If a PCEP message related
to measurement 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).
9. Security Considerations
This document defines new MEASUREMENT-ATTRIBUTES TLVs, CAPABILITY
TLVs and MEASUREMENT Objects 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 performance
measurement and bandwidth usage information as extra sensitive as it
could be used to influence LSP path computation and LSP setup with
adverse effect. Additionally, snooping of PCEP messages with such
Gandhi, et al. Expires September 1, 2017 [Page 28]
Internet-Draft PCEP for Performance Measurement February 28, 2017
data or using PCEP messages for network reconnaissance, may give an
attacker sensitive information about the operations of the network.
Thus, such deployment should employ suitable PCEP security mechanisms
like TCP Authentication Option (TCP-AO) [RFC5925] or
[DRAFT-PCE-PCEPS].
10. Manageability Considerations
10.1. Control of Function and Policy
The performance measurement reporting SHOULD be controlled per TE
tunnel (at PCC or PCE) and the values for feature attributes e.g.
measurement-interval, report-interval, report-threshold SHOULD be
configurable by an operator.
10.2. Information and Data Models
A Management Information Base (MIB) module for modeling PCEP is
described in [RFC7420]. However, one may prefer the mechanism for
configuration using YANG data model [DRAFT-PCE-PCEP-YANG]. These
SHOULD be enhanced to provide controls and indicators for support of
performance measurement reporting feature. Support for various
configuration knobs as well as counters of messages sent/received
containing the TLVs (defined in this document) SHOULD be added.
10.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
10.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
10.5. Requirements On Other Protocols
Mechanisms defined in this document do not add any new requirements
on other protocols.
10.6. Impact On Network Operations
In order to avoid any unacceptable impact on network operations, an
implementation SHOULD allow a limit to be placed on the number of
LSPs that can be enabled with performance measurement reporting
Gandhi, et al. Expires September 1, 2017 [Page 29]
Internet-Draft PCEP for Performance Measurement February 28, 2017
feature. An implementation MAY allow a limit to be placed on the
rate of measurement reporting messages sent by a PCEP speaker and
received by a peer. An implementation MAY also allow sending a
notification when a PCEP speaker is overwhelmed or the rate of
messages reach a threshold.
Gandhi, et al. Expires September 1, 2017 [Page 30]
Internet-Draft PCEP for Performance Measurement February 28, 2017
11. IANA Considerations
11.1. MEASUREMENT-CAPABILITY TLV Types
This document defines the following new PCEP TLVs; IANA is requested
to make the following allocations from the "PCEP TLV Type Indicators"
registry. <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-
type-indicators>
Type Name Reference
----------------------------------------------------------
TBD1 DELAY-MEASUREMENT-CAPABILITY [This I.D.]
TBD2 LOSS-MEASUREMENT-CAPABILITY [This I.D.]
TBD14 BANDWIDTH-USAGE-CAPABILITY [This I.D.]
IANA is requested to create a registry to manage the Flag field of
the DELAY-MEASUREMENT-CAPABILITY TLV, LOSS-MEASUREMENT-CAPABILITY TLV
and BANDWIDTH-USAGE-CAPABILITY TLV.
New bit numbers are allocated only by an IETF Review action
[RFC5226]. 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
11.2. MEASUREMENT-ATTRIBUTES TLV Types
This document defines the following new PCEP TLV Types; IANA is
requested to make the following TLV type allocations from the "PCEP
TLV Type Indicators" registry.
<http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
indicators>
Type Name Reference
----------------------------------------------------------
TBD3 DELAY-MEASUREMENT-ATTRIBUTES [This I.D.]
TBD4 LOSS-MEASUREMENT-ATTRIBUTES [This I.D.]
TBD15 BANDWIDTH-USAGE-ATTRIBUTES [This I.D.]
11.2.1. DELAY-MEASUREMENT-ATTRIBUTES Sub-TLVs
IANA is requested to create an "DELAY-MEASUREMENT-ATTRIBUTES Sub-TLV
Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-
Gandhi, et al. Expires September 1, 2017 [Page 31]
Internet-Draft PCEP for Performance Measurement February 28, 2017
TLVs carried in the DELAY-MEASUREMENT-ATTRIBUTES TLV. New sub-TLV
are allocated only by an IETF Review action [RFC5226].
This document defines the following sub-TLV 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 sub-TLV [This I.D.]
5 Report-Interval sub-TLV [This I.D.]
6- Unassigned [This I.D.]
65535
11.2.2. LOSS-MEASUREMENT-ATTRIBUTES Sub-TLVs
IANA is requested to create an "LOSS-MEASUREMENT-ATTRIBUTES Sub-TLV
Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-
TLVs carried in the LOSS-MEASUREMENT-ATTRIBUTES TLV. New sub-TLV are
allocated only by an IETF Review action [RFC5226].
This document defines the following sub-TLV 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
11.2.3. BANDWIDTH-USAGE-ATTRIBUTES Sub-TLV
IANA is requested to create an "BANDWIDTH-USAGE-ATTRIBUTES Sub-TLV
Types" sub-registry in the "PCEP TLV Type Indicators" for the sub-
TLVs carried in the BANDWIDTH-USAGE-ATTRIBUTES TLV. New sub-TLV are
allocated only by an IETF Review action [RFC5226].
This document defines the following sub-TLV types:
Gandhi, et al. Expires September 1, 2017 [Page 32]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 Report-Threshold sub-TLV [This I.D.]
4 Report-Threshold-Percentage sub-TLV [This I.D.]
5 Report-Interval sub-TLV [This I.D.]
6- Unassigned [This I.D.]
65535
11.3. MEASUREMENT Object-Class
This document defines Object-Class for the following Objects; IANA is
requested to make the following allocations from the "PCEP Objects"
registry. <http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-
objects>
Object-Class Name Reference
----------------------------------------------------------
TBD5 DELAY-MEASUREMENT Object [This I.D.]
TBD6 LOSS-MEASUREMENT Object [This I.D.]
11.3.1. DELAY-MEASUREMENT Object-Types
IANA is requested to create an "DELAY-MEASUREMENT Object-Types"
sub-registry for DELAY-MEASUREMENT Object (Object-class TBD5).
This document defines the following object-types:
Object-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.]
11.3.2. LOSS-MEASUREMENT Object-Types
IANA is requested to create an "LOSS-MEASUREMENT Object-Types"
sub-registry for LOSS-MEASUREMENT Object (Object-class TBD6).
This document defines the following object-types:
Gandhi, et al. Expires September 1, 2017 [Page 33]
Internet-Draft PCEP for Performance Measurement February 28, 2017
Object-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.]
11.3.3. BANDWIDTH Object-Type
This document defines new Object-Type for the BANDWIDTH object
(Object-Class 5, [RFC5440]); IANA is requested to make the following
allocation from the "PCEP Objects" registry.
<http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects>
Object-Type Name Reference
-----------------------------------------------------------
TBD16 BANDWIDTH-USAGE Object [This I.D.]
11.4. 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.]
11.5. Notification Object
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
Gandhi, et al. Expires September 1, 2017 [Page 34]
Internet-Draft PCEP for Performance Measurement February 28, 2017
---------------------------------------------------------------
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 September 1, 2017 [Page 35]
Internet-Draft PCEP for Performance Measurement February 28, 2017
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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).
12.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.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[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.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", RFC
7420, December 2014.
Gandhi, et al. Expires September 1, 2017 [Page 36]
Internet-Draft PCEP for Performance Measurement February 28, 2017
[RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, and S. Previdi,
"OSPF Traffic Engineering (TE) Metric Extensions", RFC
7471, March 2015.
[RFC7810] S. Previdi, S. Giacalone, D. Ward, J. Drake, and 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
Label Switched Paths (LSPs) Using TE Metric Extensions",
RFC 7823, May 2016.
[RFC7876] Bryant, S., Sivabalan, S., and 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., and
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).
[DRAFT-PCE-PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J.
Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress).
[DRAFT-IETF-PCE-AUTOBW] Dhody, D., Palle, U., Singh, R., Gandhi, R.,
and L. Fang, "PCEP Extensions for MPLS-TE LSP Automatic
Bandwidth Adjustment with Stateful PCE", draft-ietf-pce-
Stateful-pce-auto-bandwidth (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 September 1, 2017 [Page 37]
Internet-Draft PCEP for Performance Measurement February 28, 2017
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 September 1, 2017 [Page 38]