idnits 2.17.1 draft-gandhi-pce-pm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group R. Gandhi 3 Internet-Draft Cisco Systems, Inc. 4 Intended Status: Standards Track B. Wen 5 Expires: September 13, 2017 Comcast 6 C. Barth 7 Juniper Networks 8 D. Dhody 9 Huawei Technologies 10 March 12, 2017 12 PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements 13 with Stateful PCE 14 draft-gandhi-pce-pm-07 16 Abstract 18 The Path Computation Element Communication Protocol (PCEP) provides 19 mechanisms for Path Computation Elements (PCEs) to perform path 20 computations in response to Path Computation Clients (PCCs) requests. 21 The Stateful PCE extensions allow Stateful control of Multi-Protocol 22 Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 23 LSPs) using PCEP. 25 In certain networks, network performance data such as packet loss, 26 delay and delay variation (jitter) as well as bandwidth utilization 27 is a critical measure for Traffic Engineering (TE). This data 28 provides operators the characteristics of their networks for 29 performance evaluation that is required to ensure the Service Level 30 Agreements (SLAs). Performance Measurement (PM) mechanisms can be 31 employed to monitor these metrics end-to-end for TE Label Switched 32 Paths (LSPs). This document describes Path Computation Element 33 Protocol (PCEP) extensions for reporting such performance 34 measurements to an Active Stateful PCE for both PCE-Initiated and 35 PCC-Initiated LSPs. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as 45 Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/1id-abstracts.html 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 Copyright and License Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Dependencies and Considerations . . . . . . . . . . . . . 5 77 1.2. Auto-bandwidth Considerations . . . . . . . . . . . . . . 6 78 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 79 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 80 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.3. Measurement Units . . . . . . . . . . . . . . . . . . . . 7 82 3. Overview of the PCEP Extensions . . . . . . . . . . . . . . . 7 83 3.1. Report Thresholds . . . . . . . . . . . . . . . . . . . . 8 84 4. Sub-TLVs for Measurements Attributes . . . . . . . . . . . . . 9 85 4.1. Measurement-Enable sub-TLV . . . . . . . . . . . . . . . . 9 86 4.2. Measurement-Interval sub-TLV . . . . . . . . . . . . . . . 10 87 4.3. Report-Threshold sub-TLV . . . . . . . . . . . . . . . . . 10 88 4.4. Report-Threshold-Percentage sub-TLV . . . . . . . . . . . 11 89 4.5. Report-Interval sub-TLV . . . . . . . . . . . . . . . . . 11 90 5. PCEP Extensions for Reporting Delay Measurement . . . . . . . 12 91 5.1. Delay Measurement Capability Advertisement . . . . . . . . 12 92 5.1.1. DELAY-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . . 12 93 5.2. DELAY-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . . 13 94 5.2.1. Delay Measurement Enable . . . . . . . . . . . . . . . 14 95 5.2.2. Delay Measurement Interval . . . . . . . . . . . . . . 14 96 5.2.3. Delay Measurement Report Threshold . . . . . . . . . . 14 97 5.2.4. Delay Measurement Report Threshold Percentage . . . . 14 98 5.2.5. Delay Measurement Report Interval . . . . . . . . . . 15 99 5.3. DELAY-MEASUREMENT Object . . . . . . . . . . . . . . . . . 15 100 6. PCEP Extensions for Reporting Loss Measurement . . . . . . . . 17 101 6.1. Loss Measurement Capability Advertisement . . . . . . . . 17 102 6.1.1. LOSS-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . . 18 103 6.2. LOSS-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . . 19 104 6.2.1. Loss Measurement Enable . . . . . . . . . . . . . . . 20 105 6.2.2. Loss Measurement Interval . . . . . . . . . . . . . . 20 106 6.2.3. Loss Measurement Report Threshold . . . . . . . . . . 20 107 6.2.4. Loss Measurement Report Threshold Percentage . . . . . 20 108 6.2.5. Loss Measurement Report Interval . . . . . . . . . . . 20 109 6.3. LOSS-MEASUREMENT Object . . . . . . . . . . . . . . . . . 21 110 7. PCEP Extensions for Reporting Bandwidth Utilization . . . . . 22 111 7.1. Bandwidth Utilization Capability Advertisement . . . . . . 22 112 7.1.1. BANDWIDTH-UTILIZATION-CAPABILITY TLV . . . . . . . . . 22 113 7.2. BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . 23 114 7.2.1. Bandwidth Utilization Measurement Enable . . . . . . . 24 115 7.2.2. Bandwidth Utilization Measurement Interval . . . . . . 24 116 7.2.3. Bandwidth Utilization Report Threshold . . . . . . . . 24 117 7.2.4. Bandwidth Utilization Report Threshold Percentage . . 24 118 7.2.5. Bandwidth Utilization Report Interval . . . . . . . . 24 119 7.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 24 120 8. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 25 121 8.1. Various MEASUREMENT-ATTRIBUTES TLVs . . . . . . . . . . . 25 122 8.2. The MEASUREMENT Objects . . . . . . . . . . . . . . . . . 26 123 9. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 26 124 9.1. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 26 125 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 126 11. Manageability Considerations . . . . . . . . . . . . . . . . 27 127 11.1. Control of Function and Policy . . . . . . . . . . . . . 27 128 11.2. Information and Data Models . . . . . . . . . . . . . . . 27 129 11.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 130 11.4. Verify Correct Operations . . . . . . . . . . . . . . . . 28 131 11.5. Requirements On Other Protocols . . . . . . . . . . . . . 28 132 11.6. Impact On Network Operations . . . . . . . . . . . . . . 28 133 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 134 12.1. Measurement Capability TLV Types . . . . . . . . . . . . 28 135 12.1.1. Flag Fields for MEASUREMENT-CAPABILITY TLVs . . . . . 28 136 12.2. MEASUREMENT-ATTRIBUTES TLVs . . . . . . . . . . . . . . . 29 137 12.2.1. The Sub-TLVs For MEASUREMENT-ATTRIBUTES TLVs . . . . 29 138 12.2.1.1. Flag Fields in Measurement-Enable sub-TLV . . . . 30 139 12.3. Measurement Object-Class . . . . . . . . . . . . . . . . 30 140 12.3.1. DELAY-MEASUREMENT Object-Types . . . . . . . . . . . 31 141 12.3.2. LOSS-MEASUREMENT Object-Types . . . . . . . . . . . . 31 142 12.3.3. BANDWIDTH Object-Type . . . . . . . . . . . . . . . . 31 143 12.4. PCE Error Codes . . . . . . . . . . . . . . . . . . . . . 31 144 12.5. Notification Object-Type . . . . . . . . . . . . . . . . 32 145 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 146 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 147 13.2. Informative References . . . . . . . . . . . . . . . . . 33 148 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 151 1. Introduction 153 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 154 communication mechanism between a Path Computation Client (PCC) and a 155 Path Control Element (PCE), or between PCE and PCE, that enables 156 computation of Multi-Protocol Label Switching (MPLS) Traffic 157 Engineering Label Switched Paths (TE LSPs). 159 [DRAFT-PCE-STATEFUL] specifies extensions to PCEP to enable Stateful 160 control of TE LSPs. It describes two mode of operations - Passive 161 Stateful PCE and Active Stateful PCE. Further [DRAFT-PCE-INITIATED- 162 LSP] describes the setup, maintenance and teardown of PCE-Initiated 163 LSPs for the Stateful PCE model. In this document, the focus is on 164 Active Stateful PCE where the LSPs are controlled by the PCE, for 165 both PCE-Initiated and PCC-Initiated LSPs. 167 In certain networks, such as financial information networks, network 168 performance data (e.g. packet loss, delay and delay variation 169 (jitter), bandwidth utilization) is a critical measure for traffic 170 engineering. The protocol extensions have been defined to advertise 171 link performance metrics, see [RFC7471], [RFC7810], [RFC7823] and 172 [DRAFT-IDR-TE-PM-BGP]. This data provides operators the 173 characteristics of their networks for performance evaluation that is 174 required to ensure the Service Level Agreements (SLAs). 176 [DRAFT-PCE-SERVICE-AWARE] defines the PCEP extensions for TE LSP path 177 computation using packet loss, delay and delay variation as path 178 selection metrics. Such path computations use link metrics for 179 packet loss and delay and do not provide end-to-end metrics of the TE 180 LSPs. The end-to-end metrics of a TE LSP may be very different than 181 the path computation results due to many factors, such as queuing, 182 etc. There is a need to verify and monitor that the traffic sent 183 over the established TE LSPs does not exceed the requested metric 184 bounds (e.g. total end-to-end delay/loss). The Stateful PCE may need 185 to take some action (such as tear-down or re-optimize the LSP) when 186 the performance requirement is not met. [RFC6374], [RFC6375] and 187 [RFC7876] define protocol extensions needed for measuring end-to-end 188 packet loss, delay and delay variation (jitter) for bidirectional and 189 unidirectional TE LSPs. 191 This document provides mechanisms to report the performance 192 measurements (PM) such as packet loss, delay, delay variation 193 (jitter) and bandwidth utilization for a TE LSP to an Active Stateful 194 PCE, for both PCE-Initiated and PCC-Initiated LSPs. 196 1.1. Dependencies and Considerations 198 [RFC6374] describes several reasons why PMs are valuable to 199 operators. Note that the specification of the use of the reported 200 packet loss, delay, delay variation and bandwidth utilization 201 measurements by a Stateful PCE is outside the scope of this document. 203 Furthermore, [RFC6374] describes many types of MPLS channels that may 204 leverage PMs and some may have bidirectional dependencies. Defining 205 a mechanism for the verification and/or provisioning of bidirectional 206 or associated bidirectional LSPs within the Stateful PCE architecture 207 is outside the scope of this document. 209 In all cases, delay and loss PM messages are carried over the MPLS 210 Generic Associated Channel (G-ACh) as described in [RFC5586]. MPLS 211 LSPs that carry the G-ACh can be referred to as MPLS Transport 212 Profile (MPLS-TP) LSPs [RFC5921]. MPLS-TP LSPs require Ultimate Hop 213 Popping (UHP). It is beyond the scope of this document to define the 214 mechanism by which a Stateful PCE verifies and/or provisions an LSP 215 for UHP. Note that for both unidirectional and bidirectional LSPs, 216 packet loss measurement requires UHP. 218 1.2. Auto-bandwidth Considerations 220 Auto-Bandwidth feature allows a head-end LSR (PCC) to automatically 221 adjust the LSP bandwidth reservation based on the traffic demand of a 222 TE LSP. Auto-bandwidth requested bandwidth computation can be 223 implemented on a PCC or a Stateful PCE. 225 [DRAFT-IETF-PCE-AUTOBW] describes the PCEP extensions for auto- 226 bandwidth, where the requested bandwidth for the LSP is computed by 227 the PCC and reported to the Stateful PCE. There is a benefit in 228 pushing the responsibility for deciding when auto-bandwidth 229 adjustments are needed to the PCC as this distributes the load of 230 monitoring the bandwidth utilization of the LSPs down to the PCCs and 231 frees up the PCE for path computations. In addition, it reduces the 232 load on PCEP communications for reporting the bandwidth utilization 233 of the LSP. 235 However, exactly when to adjust an LSP bandwidth could be better left 236 to a Stateful PCE. That is, a PCE could be flexible in its 237 interpretation of thresholds enabling it to trigger auto-bandwidth 238 adjustment early if it believes there is a good reason (for example, 239 doing a set of parallel path re-computations) or late (for example, 240 when it knows that an adjustment would be disruptive to the network). 241 When the auto-bandwidth computation is delegated to the PCC, the PCC 242 cannot see the impact on other LSPs in the network, and the PCE 243 cannot tell whether the request to adjust the LSP bandwidth is 244 critical or not. The bandwidth utilization reporting defined in this 245 document can be used by the PCE to do computations to determine 246 whether auto-bandwidth adjustments are needed and/or desirable before 247 performing the path computations. 249 2. Conventions Used in This Document 251 2.1. Requirements Language 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 255 document are to be interpreted as described in [RFC2119]. 257 2.2. Terminology 259 The reader is assumed to be familiar with the terminology defined in 260 [RFC5440], [RFC6374] and [RFC7471]. 262 2.3. Measurement Units 264 The measurement unit for delay value is defined in [RFC7471], Section 265 4.1.5. 267 The measurement unit for loss value is defined in [RFC7471], Section 268 4.4.5. 270 The utilized bandwidth [RFC7471] is encoded in IEEE floating point 271 format in bytes per second (see [IEEE.754.1985]). 273 All average values are calculated as rolling averages. 275 3. Overview of the PCEP Extensions 277 The high-level overview of the PCEP extensions defined in this 278 document for requesting and reporting end-to-end performance 279 measurements and bandwidth utilization for TE LSPs are shown in 280 Figure 1. 282 --------- 283 | | 284 | PCE | 285 | | 286 --------- 287 | ^ 288 MEASUREMENT CAPABILITY | | MEASUREMENT CAPABILITY 289 | | 290 MEASUREMENT ATTRIBUTES | | MEASUREMENT ATTRIBUTES 291 | | (For delegated LSPs) 292 | | 293 | | MEASUREMENT REPORTS 294 v | 295 --------- 296 | | 297 | PCC | 298 | | 299 --------- 301 Figure 1: Overview of PCEP Extensions 303 The following steps describe the PCEP extensions for reporting 304 performance measurements and bandwidth utilization of TE LSPs: 306 o The Stateful PCE and PCC (head-end of the LSP) advertise the 307 capability of their support for the delay, loss and bandwidth- 308 utilization measurements and reporting in the PCEP Open message 309 (in the OPEN Object). 311 o The Stateful PCE enables the measurement of a feature and sends 312 and updates the configuration parameters of the feature using the 313 LSPA object to PCC in PCInitiate and PCUpd messages respectively. 315 o The PCC reports the measured values of the feature to the Stateful 316 PCE at the end of the specified report-interval or when measured 317 values cross the specified report-threshold. The periodic 318 reporting can be used at the PCE to monitor the TE LSP metrics 319 whereas report-threshold can be used to trigger an immediate 320 action at the PCE on the TE LSP. 322 o The PCE and PCC notify each other of their entering and clearing 323 the overwhelmed state when operating under high LSP scale. 325 3.1. Report Thresholds 327 When explicitly configured, report threshold (absolute or percentage) 328 parameter (along with the configured number of counts) is used to 329 trigger an immediate reporting of the delay and loss measurements and 330 bandwidth utilization, bypassing the report interval. Threshold is 331 used to detect a sudden change in the performance measurement metric 332 of a TE LSP. In order to detect that a measured value has crossed 333 the threshold, the (delay/loss) metric is compared from the last 334 reported interval and the current interval. If the change (increase 335 or decrease) in the value is above the threshold (absolute or 336 percentage) consecutively for the given number of counts, the 337 measurement from the current interval is reported immediately. In 338 case of bandwidth utilization, the MaxSampleBw (see [DRAFT-IETF-PCE- 339 AUTOBW]) from the last reported interval is compared with the 340 MaxSampleBW from the the current interval to detect the threshold 341 crossing. The delay and loss measurements are still reported at the 342 end of the report interval even if they were reported due to the 343 crossing of the threshold. Refer to [RFC7471], Section 5, for 344 additional considerations. 346 4. Sub-TLVs for Measurements Attributes 348 This section specifies the generic sub-TLVs those provide various 349 configurable parameters for reporting measurements to a Stateful PCE. 350 These sub-TLVs are carried in various measurement attributes TLVs 351 defined in this document. 353 Following sub-TLVs are defined: 355 Type Len Name 356 ----------------------------------------------------------------- 357 1 4 Measurement-Enable sub-TLV 358 2 4 Measurement-Interval sub-TLV 359 3 8 Report-Threshold sub-TLV 360 4 4 Report-Threshold-Percentage sub-TLV 361 5 4 Report-Interval sub-TLV 363 The Measurement-Enable sub-TLV MUST be added in the LSPA Object when 364 the measurement feature is enabled for the LSP. All other sub-TLVs 365 are optional and any unrecognized sub-TLV MUST be silently ignored. 366 If a sub-TLV of same type appears more than once, only the first 367 occurrence is processed and all others MUST be ignored. If sub-TLVs 368 are not present, the default values based on the local policy are 369 assumed. 371 4.1. Measurement-Enable sub-TLV 373 The Measurement-Enable sub-TLV specifies that the given measurement 374 feature is enabled. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type=1 | Length=4 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Flags | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Measurement-Enable sub-TLV Format 386 The Type is 1, Length is 4 bytes, and the value comprises of flags 387 (32 bits) for enabling various measurement features. 389 Unassigned flags are considered reserved, they MUST be set to 0 when 390 sent and MUST be ignored when received. 392 4.2. Measurement-Interval sub-TLV 394 The Measurement-Interval sub-TLV specifies a time interval in seconds 395 for the measurement. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type=2 | Length=4 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Measurement-Interval | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Measurement-Interval sub-TLV Format 407 The Type is 2, Length is 4 bytes, and the value comprises of 4-byte 408 time interval, the valid range is from 1 to 604800, in seconds. The 409 default value is 300 seconds. 411 4.3. Report-Threshold sub-TLV 413 The Report-Threshold sub-TLV specifies the threshold value used to 414 trigger an immediate reporting of the measurements bypassing the 415 report-interval. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type=3 | Length=8 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | RESERVED | Count | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Report-Threshold | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Report-Threshold sub-TLV Format 429 The Type is 3, Length is 8 bytes, and the value comprises of - 431 o Report-Threshold: 32-bit absolute threshold value. 433 o Count: 8-bit integer counter. The number of consecutive 434 measurement values MUST be above the threshold before reporting 435 the measurement. The value 0 is considered to be invalid. 437 o RESERVED: It MUST be set to zero when sent and MUST be ignored 438 when received. 440 4.4. Report-Threshold-Percentage sub-TLV 442 The Report-Threshold-Percentage sub-TLV specifies the threshold value 443 used to trigger an immediate reporting of the measurements bypassing 444 the report-interval. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type=4 | Length=4 | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Percentage | RESERVED | Count | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Report-Threshold-Percentage sub-TLV Format 456 The Type is 4, Length is 4 bytes, and the value comprises of - 458 o Percentage: 7-bit threshold value, encoded in percentage (an 459 integer from 0 to 100). 461 o Count: 8-bit integer counter. The number of consecutive 462 measurement values MUST be above threshold before reporting the 463 measurement. The value 0 is considered to be invalid. 465 o RESERVED: It MUST be set to zero when sent and MUST be ignored 466 when received. 468 4.5. Report-Interval sub-TLV 470 The Report-Interval sub-TLV specifies the time interval in seconds 471 when measured values are to be reported. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type=5 | Length=4 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Report-Interval | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Report-Interval sub-TLV Format 483 The Type is 5, Length is 4 bytes, and the value comprises of 4-byte 484 time interval, the valid range is from 1 to 604800, in seconds. The 485 default value is 3600 seconds. 487 5. PCEP Extensions for Reporting Delay Measurement 489 5.1. Delay Measurement Capability Advertisement 491 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 492 advertise their support of DELAY-MEASUREMENT. A PCEP Speaker (PCE or 493 PCC) includes the DELAY-MEASUREMENT-CAPABILITY TLV, in the OPEN 494 Object to advertise its support for PCEP Delay-Measurement 495 extensions. The presence of the DELAY-MEASUREMENT-CAPABILITY TLV in 496 the OPEN Object (in the Open message) indicates that the Delay 497 Measurement capability is supported as described in this document. 498 Additional procedure is defined as following: 500 o The PCEP protocol extensions for Delay Measurement MUST NOT be 501 used if one or both PCEP Speakers have not included the DELAY- 502 MEASUREMENT-CAPABILITY TLV in their respective Open message. 504 o If the PCEP speaker that supports the extensions of this document 505 but did not advertise this capability, then upon receipt of DELAY- 506 MEASUREMENT-ATTRIBUTES TLV in LSPA object, it SHOULD generate a 507 PCErr with error-type 19 (Invalid Operation), error-value TBD7 508 (Delay-Measurement capability was not advertised) and it will 509 terminate the PCEP session. 511 o Similarly, the PCEP speaker SHOULD generate error-value TBD9 512 (Bidirectional Measurement capability was not advertised) and 513 TBD10 (Unidirectional Measurement capability was not advertised) 514 upon receipt of DELAY-MEASUREMENT-ATTRIBUTES TLV in LSPA object 515 with two-way measurement request and one-way measurement request, 516 respectively, when it did not advertise this capability. 518 o If the PCEP speaker that supports the extensions of this document 519 but did not advertise this capability, then upon receipt of DELAY- 520 MEASUREMENT object, it SHOULD generate a PCErr with error-type 19 521 (Invalid Operation), error-value TBD7 (Delay-Measurement 522 capability was not advertised) and it will terminate the PCEP 523 session. 525 5.1.1. DELAY-MEASUREMENT-CAPABILITY TLV 527 The DELAY-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in 528 the OPEN Object for Delay Measurement via PCEP capability 529 advertisement. Its format is shown in the following figure: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type=TBD1 | Length=4 | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Flags |B|U| 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 DELAY-MEASUREMENT-CAPABILITY TLV Format 541 The Type of the TLV is TBD1 and it has a fixed length of 4 bytes. 543 The value comprises a single field - Flags (32 bits): 545 o U (Unidirectional Delay Measurement - 1 bit): if set to 1 by a 546 PCC, the U Flag indicates that the PCC allows reporting of 547 unidirectional delay measurement information; if set to 1 by a 548 PCE, the U Flag indicates that the PCE is capable of receiving 549 unidirectional delay measurement information from the PCC. 551 o B (Bidirectional Delay Measurement - 1 bit): if set to 1 by a PCC, 552 the B Flag indicates that the PCC allows reporting of 553 bidirectional delay measurement information; if set to 1 by a PCE, 554 the B Flag indicates that the PCE is capable of receiving 555 bidirectional delay measurement information from the PCC. 556 Bidirectional measurement is only applicable to the bidirectional 557 LSPs (e.g. MPLS-TP LSPs [RFC5921]). 559 Unassigned bits are considered reserved. They MUST be set to 0 when 560 sent and MUST be ignored when received. 562 Advertisement of the DELAY-MEASUREMENT-CAPABILITY TLV implies support 563 of delay measurement, as well as the objects, TLVs and procedures 564 defined in this document. Either U or B flag MUST be set in the TLV. 566 5.2. DELAY-MEASUREMENT-ATTRIBUTES TLV 568 The DELAY-MEASUREMENT-ATTRIBUTES TLV provides the configurable 569 parameters of the delay measurement feature. 571 The format of the DELAY-MEASUREMENT-ATTRIBUTES TLV is shown in the 572 following figure: 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | PCEP TLV Type TBD4 | Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 // sub-TLVs // 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 DELAY-MEASUREMENT-ATTRIBUTES TLV Format 586 PCEP TLV Type is defined as following: 588 Type Name 589 ---------------------------------------------------------- 590 TBD4 DELAY-MEASUREMENT-ATTRIBUTES 592 Length: The Length field defines the length of the value portion in 593 bytes as per [RFC5440]. 595 Value: Comprises of one or more sub-TLVs as described in Section 4 of 596 this document. 598 The following sub-sections describe the parameters which are 599 currently defined to be carried within this TLV. 601 5.2.1. Delay Measurement Enable 603 The Measurement-Enable sub-TLV specifies the delay measurement mode 604 enabled using following flags: 606 Bit Description 607 ------------------------------------------------------------------ 608 31 One-Way Delay Measurement Enabled 609 30 Two-Way Delay Measurement Enabled 611 5.2.2. Delay Measurement Interval 613 The Measurement-Interval sub-TLV specifies a time interval in seconds 614 for the delay measurement. 616 5.2.3. Delay Measurement Report Threshold 618 The Report-Threshold sub-TLV specifies the threshold value used to 619 trigger an immediate reporting of the delay measurements bypassing 620 the report-interval. 622 o Report-Threshold: Delay in microseconds, encoded as 24-bit 623 integer, as defined in [RFC7471]. 625 Same report-threshold is used for all delay measurement values. 627 5.2.4. Delay Measurement Report Threshold Percentage 628 The Report-Threshold-Percentage sub-TLV specifies the threshold value 629 used to trigger an immediate reporting of the measurements bypassing 630 the report-interval. 632 Same report-threshold-percentage is used for all delay measurement 633 values. 635 5.2.5. Delay Measurement Report Interval 637 The Report-Interval sub-TLV specifies the time interval in seconds 638 when measured delay values are to be reported. 640 5.3. DELAY-MEASUREMENT Object 642 A new object, DELAY-MEASUREMENT with Object-Class (Value TBD5) is 643 defined in this document to report the delay measurement of a TE LSP. 645 When the LSP is enabled with the delay measurement feature, the PCC 646 SHOULD include the DELAY-MEASUREMENT Object to report the measured 647 delay values to the PCE in the PCRpt message. The PCC SHOULD report 648 (either one-way or two-way) average delay, min/max delay and delay 649 variations to the PCE in the PCRpt message. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Class=TBD5 | OT |Res|P|I| Object Length (bytes) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | | 657 // (Object body) // 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 DELAY-MEASUREMENT Object Format 663 Object Length (16 bits): Specifies the total object length including 664 the header, in bytes as per [RFC5440]. 666 Object-Types (OT) are defined as follows: 668 Object-Type Len Name 669 -------------------------------------------------------------- 670 1 8 One-Way Delay Measurement Value 671 2 12 One-Way Delay Measurement Min/Max Values 672 3 8 One-Way Delay Variation Measurement Value 673 4 8 Two-Way Delay Measurement Value 674 5 12 Two-Way Delay Measurement Min/Max Values 675 6 8 Two-Way Delay Variation Measurement Value 677 The object body formats are defined as following: 679 For Object-Type 1 and 4: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | RESERVED | Delay Value Average | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 For Object-Type 2 and 5: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | RESERVED | Delay Value Minimum | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | RESERVED | Delay Value Maximum | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 For Object-Type 3 and 6: 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | RESERVED | Delay Variation Value | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 DELAY-MEASUREMENT Object Body Formats (One-Way and Two-Way) 707 Al delay values are reported in microseconds, encoded as 24-bit 708 integer, as defined in [RFC7471]. When set to the maximum value 709 16,777,215 (16.777215 sec), the delay is at least that value and may 710 be larger. 712 o One-way Delay Measurement Value: Average Delay of the LSP in one 713 (forward) direction. 715 o One-way Delay Measurement Variation Value: Average Delay Variation 716 of the LSP in one (forward) direction. 718 o One-Way Delay Measurement Value Minimum/Maximum: Minimum and 719 Maximum values of the Delay of the LSP in one (forward) direction 720 in the last measurement interval. 722 o Two-way Delay Measurement Value: Average Delay of the 723 bidirectional LSP in both (forward and reverse) directions. 725 o Two-way Delay Measurement Variation Value: Average Delay Variation 726 of the bidirectional LSP in both (forward and reverse) 727 directions. 729 o Two-Way Delay Measurement Value Minimum/Maximum: Minimum and 730 Maximum values of the Delay of the bidirectional LSP in both 731 (forward and reverse) directions in the last measurement interval. 733 o RESERVED: This field is reserved for future use. It MUST be set 734 to 0 when sent and MUST be ignored when received. 736 6. PCEP Extensions for Reporting Loss Measurement 738 6.1. Loss Measurement Capability Advertisement 740 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 741 advertise their support of LOSS-MEASUREMENT. A PCEP Speaker includes 742 the LOSS-MEASUREMENT-CAPABILITY TLV, in the OPEN Object to advertise 743 its support for PCEP Loss-Measurement extensions. The presence of 744 the LOSS-MEASUREMENT-CAPABILITY TLV in the OPEN Object (in the Open 745 message) indicates that the Loss Measurement capability is supported 746 as described in this document. Additional procedure is defined as 747 following: 749 o The PCEP protocol extensions for Loss Measurement MUST NOT be used 750 if one or both PCEP Speakers have not included the LOSS- 751 MEASUREMENT-CAPABILITY TLV in their respective Open message. 753 o If the PCEP speaker that supports the extensions of this document 754 but did not advertise this capability, then upon receipt of LOSS- 755 MEASUREMENT-ATTRIBUTES TLV in LSPA object, it SHOULD generate a 756 PCErr with error-type 19 (Invalid Operation), error-value TBD8 757 (Loss-Measurement capability was not advertised) and it will 758 terminate the PCEP session. 760 o Similarly, the PCEP speaker SHOULD generate error-value TBD9 761 (Bidirectional Measurement capability was not advertised) and 762 TBD10 (Unidirectional Measurement capability was not advertised) 763 upon receipt of LOSS-MEASUREMENT-ATTRIBUTES TLV in LSPA object 764 with two-way measurement request and one-way measurement request, 765 respectively, when it did not advertise this capability. 767 o Further, the PCEP speaker SHOULD generate error-value TBD11 768 (Inferred Mode Loss Measurement capability was not advertised) and 769 TBD12 (Direct Mode Loss Measurement capability was not advertised) 770 upon receipt of LOSS-MEASUREMENT-ATTRIBUTES TLV in LSPA object 771 with Inferred Mode loss measurement request and Direct Mode loss 772 measurement request, respectively, when it did not advertise this 773 capability. 775 o If the PCEP speaker that supports the extensions of this document 776 but did not advertise this capability, then upon receipt of LOSS- 777 MEASUREMENT object, it SHOULD generate a PCErr with error-type 19 778 (Invalid Operation), error-value TBD8 (Loss-Measurement capability 779 was not advertised) and it will terminate the PCEP session. 781 6.1.1. LOSS-MEASUREMENT-CAPABILITY TLV 783 The LOSS-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in the 784 OPEN Object for Loss Measurement via PCEP capability advertisement. 785 Its format is shown in the following figure: 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type=TBD2 | Length=4 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Flags |N|I|B|U| 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 LOSS-MEASUREMENT-CAPABILITY TLV Format 797 The Type of the TLV is TBD2 and it has a fixed length of 4 bytes. 799 The value comprises a single field - Flags (32 bits): 801 o U (Unidirectional Measurement - 1 bit): if set to 1 by a PCC, the 802 U Flag indicates that the PCC allows reporting of unidirectional 803 loss measurement information; if set to 1 by a PCE, the U Flag 804 indicates that the PCE is capable of receiving unidirectional loss 805 measurement information from the PCC. 807 o B (Bidirectional Measurement - 1 bit): if set to 1 by a PCC, the B 808 Flag indicates that the PCC allows reporting of bidirectional loss 809 measurement information; if set to 1 by a PCE, the B Flag 810 indicates that the PCE is capable of receiving bidirectional loss 811 measurement information from the PCC. Bidirectional measurement 812 is only applicable to the bidirectional LSPs (e.g. MPLS-TP LSPs 813 [RFC5921]). 815 o I (Inferred Loss Measurement Mode - 1 bit): if set to 1 by a PCC, 816 the I Flag indicates that the PCC allows reporting of inferred 817 mode loss measurement [RFC6374] information; if set to 1 by a PCE, 818 the I Flag indicates that the PCE is capable of receiving inferred 819 mode loss measurement information from the PCC. 821 o N (Direct Loss Measurement Mode - 1 bit): if set to 1 by a PCC, 822 the N Flag indicates that the PCC allows reporting of direct mode 823 loss measurement [RFC6374] information; if set to 1 by a PCE, the 824 N Flag indicates that the PCE is capable of receiving direct mode 825 loss measurement information from the PCC. 827 Unassigned bits are considered reserved. They MUST be set to 0 when 828 sent and MUST be ignored when received. 830 Advertisement of the LOSS-MEASUREMENT-CAPABILITY TLV implies support 831 of loss measurement, as well as the objects, TLVs and procedures 832 defined in this document. Either U or B flag MUST be set in the TLV. 833 Similarly, either I or N flag MUST be set in the TLV. 835 6.2. LOSS-MEASUREMENT-ATTRIBUTES TLV 837 The LOSS-MEASUREMENT-ATTRIBUTES TLV provides the configurable 838 parameters of the loss measurement feature. 840 The format of the LOSS-MEASUREMENT-ATTRIBUTES TLV is shown in the 841 following figure: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | PCEP TLV Type TBD16 | Length | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | | 849 // sub-TLVs // 850 | | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 LOSS-MEASUREMENT-ATTRIBUTES TLV Format 855 PCEP TLV Type is defined as following: 857 Type Name 858 ---------------------------------------------------------- 859 TBD16 LOSS-MEASUREMENT-ATTRIBUTES 861 Length: The Length field defines the length of the value portion in 862 bytes as per [RFC5440]. 864 Value: Comprises of one or more sub-TLVs as described in Section 4 of 865 this document. 867 The following sub-sections describe the parameters which are 868 currently defined to be carried within this TLV. 870 6.2.1. Loss Measurement Enable 872 The Measurement-Enable sub-TLV specifies the loss measurement mode 873 enabled using following flags: 875 Bit Description 876 ------------------------------------------------------------------ 877 29 Unidirectional Loss Measurement Enabled 878 28 Bidirectional Loss Measurement Enabled 879 27 Inferred Loss Measurement Enabled 881 6.2.2. Loss Measurement Interval 883 The Measurement-Interval sub-TLV specifies a time interval in seconds 884 for the loss measurement. 886 6.2.3. Loss Measurement Report Threshold 888 The Report-Threshold sub-TLV specifies the threshold value used to 889 trigger an immediate reporting of the loss measurements bypassing the 890 report-interval. 892 o Report-Threshold: This 24-bit field identifying the packet loss as 893 a percentage of the total packets sent or received. The encoding 894 is as per [RFC7471]. 896 Same report-threshold is used for all loss measurement values. 898 6.2.4. Loss Measurement Report Threshold Percentage 900 The Report-Threshold-Percentage sub-TLV specifies the threshold value 901 used to trigger an immediate reporting of the loss measurements 902 bypassing the report-interval. 904 Same report-threshold-percentage is used for all loss measurement 905 values. 907 6.2.5. Loss Measurement Report Interval 909 The Report-Interval sub-TLV specifies the time interval in seconds 910 when measured loss values are to be reported. 912 6.3. LOSS-MEASUREMENT Object 914 The LOSS-MEASUREMENT Object with Object-Class (Value TBD6) is defined 915 in this document to report the packet loss measurement of a TE LSP. 917 When the LSP is enabled with the loss measurement feature, the PCC 918 SHOULD include the LOSS-MEASUREMENT Object to report the measured 919 packet loss to the PCE in the PCRpt message. 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Class=TBD6 | OT |Res|P|I| Object Length (bytes) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | | 927 // (Object body) // 928 | | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 LOSS-MEASUREMENT Object Format 933 Object Length (16 bits): Specifies the total object length including 934 the header, in bytes [RFC5440]. 936 Object-Types (OT) are defined as following: 938 Object-Type Len Name 939 -------------------------------------------------------------- 940 1 8 Tx Packets-Lost 941 2 8 Rx Packets-Lost 943 The object body format is defined as following: 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | RESERVED | Packets-Lost | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 LOSS-MEASUREMENT Object Body Formats (Tx and Rx) 953 o Packets-Lost: This 24-bit field identifying the packet loss as a 954 percentage of the total packets sent or received, encoded as per 955 [RFC7471]. 957 o RESERVED: This field is reserved for future use. It MUST be set 958 to 0 when sent and MUST be ignored when received. 960 The Packets-Lost in the Rx direction is reported when bidirectional 961 loss measurement is enabled. 963 7. PCEP Extensions for Reporting Bandwidth Utilization 965 7.1. Bandwidth Utilization Capability Advertisement 967 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 968 advertise their support of bandwidth utilization reporting. A PCEP 969 Speaker includes the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV, in the 970 OPEN Object to advertise its support for PCEP extension. The 971 presence of the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in the OPEN 972 Object (in the Open message) indicates that the bandwidth utilization 973 reporting is supported as described in this document. Additional 974 procedure is defined as following: 976 o The PCEP protocol extensions for bandwidth utilization MUST NOT be 977 used if one or both PCEP Speakers have not included the 978 "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in their respective Open 979 message. 981 o If the PCEP speaker that supports the extensions of this document 982 but did not advertise this capability, then upon receipt of 983 BANDWIDTH-UTILIZATION-ATTRIBUTES TLV in LSPA object, it SHOULD 984 generate a PCErr with error-type 19 (Invalid Operation), error- 985 value TBD13 (Bandwidth utilization capability was not advertised) 986 and it will terminate the PCEP session. 988 o If the PCEP speaker that supports the extensions of this document 989 but did not advertise this capability, then upon receipt of 990 BANDWIDTH object of type TBD14, it SHOULD generate a PCErr with 991 error-type 19 (Invalid Operation), error-value TBD13 (Bandwidth 992 utilization capability was not advertised) and it will terminate 993 the PCEP session. 995 7.1.1. BANDWIDTH-UTILIZATION-CAPABILITY TLV 997 The BANDWIDTH-UTILIZATION-CAPABILITY TLV is an optional TLV for use 998 in the OPEN Object for Bandwidth Utilization reporting via PCEP 999 capability advertisement. Its format is shown in the following 1000 figure: 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Type=TBD3 | Length=4 | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Flags | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 BANDWIDTH-UTILIZATION-CAPABILITY TLV Format 1012 The Type of the TLV is TBD3 and it has a fixed length of 4 bytes. 1014 The value comprises a single field - Flags (32 bits). Currently no 1015 flags are defined for this TLV. 1017 Unassigned bits are considered reserved. They MUST be set to 0 when 1018 sent and MUST be ignored when received. 1020 Advertisement of the BANDWIDTH-UTILIZATION-CAPABILITY TLV implies 1021 support of bandwidth utilization reporting, as well as the objects, 1022 TLVs and procedures defined in this document. 1024 7.2. BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV 1026 The BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV provides the 1027 configurable parameters of bandwidth utilization feature. 1029 The format of the BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV is shown 1030 in the following figure: 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | PCEP TLV Type TBD17 | Length | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | | 1038 // sub-TLVs // 1039 | | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV Format 1044 PCEP TLV Type is defined as following: 1046 Type Name 1047 ---------------------------------------------------------- 1048 TBD17 BW-UTILIZATION-MEASUREMENT-ATTRIBUTES 1050 Length: The Length field defines the length of the value portion in 1051 bytes as per [RFC5440]. 1053 Value: Comprises of one or more sub-TLVs as described in Section 4 of 1054 this document. 1056 The following sub-sections describe the parameters which are 1057 currently defined to be carried within this TLV. 1059 7.2.1. Bandwidth Utilization Measurement Enable 1061 The Measurement-Enable sub-TLV specifies that the bandwidth 1062 utilization reporting is enabled using following flag: 1064 Bit Description 1065 ------------------------------------------------------------------ 1066 26 Bandwidth Utilization Reporting Enabled 1068 7.2.2. Bandwidth Utilization Measurement Interval 1070 The Measurement-Interval sub-TLV specifies a time interval in seconds 1071 for the bandwidth samples collection interval. 1073 7.2.3. Bandwidth Utilization Report Threshold 1075 The Report-Threshold sub-TLV is used to decide if the bandwidth 1076 samples collected so far should be immediately reported bypassing the 1077 report-interval. 1079 o Threshold: The absolute threshold bandwidth value in 32-bits, 1080 encoded in IEEE floating point format (see [IEEE.754.1985]), 1081 expressed in bytes per second. 1083 7.2.4. Bandwidth Utilization Report Threshold Percentage 1085 The Report-Threshold-Percentage sub-TLV is used to decide if the 1086 bandwidth samples collected so far should be immediately reported 1087 bypassing the report-interval. 1089 7.2.5. Bandwidth Utilization Report Interval 1091 The Report-Interval sub-TLV specifies a time interval in seconds when 1092 the collected bandwidth samples are to be reported to PCE. 1094 7.3. BANDWIDTH Object 1096 A new object-type for BANDWIDTH object (Object-Class 5) is defined to 1097 report the bandwidth utilization of a TE LSP. 1099 When the TE LSP is enabled with the bandwidth utilization reporting, 1100 the PCC SHOULD include the BANDWIDTH-UTILIZATION Object to report the 1101 bandwidth utilization of the TE LSP to the PCE in the PCRpt message. 1103 The object-type is TBD14, the object length is variable with 1104 multiples of 4 bytes. 1106 The object body format is defined as following: 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | BwSample1 | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | ... | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | BwSampleN | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 BANDWIDTH-UTILIZATION Object Body Format 1120 o BwSample: The utilized bandwidth, (the BwSample collected at the 1121 end of each measurement-interval) encoded in IEEE floating point 1122 format (see [IEEE.754.1985]), expressed in bytes per second. 1124 8. PCEP Procedure 1126 Following procedure is defined for the extensions to different PCEP 1127 messages for reporting performance measurements. 1129 8.1. Various MEASUREMENT-ATTRIBUTES TLVs 1131 o For a PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with reporting 1132 features enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV for 1133 each measurement MUST be included in the LSPA Object with the 1134 PCInitiate message. 1136 o For a PCE-Initiated LSP [DRAFT-PCE-INITIATED-LSP] with reporting 1137 features enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV for 1138 each measurement is carried in the PCUpd message in the LSPA 1139 Object in order to make updates to the attributes such as 1140 Report-Interval. 1142 o For a PCC-Initiated LSP with reporting features enabled, when the 1143 LSP is delegated to the PCE, the corresponding MEASUREMENT- 1144 ATTRIBUTES TLV for each measurement MUST be included in the LSPA 1145 Object of the PCRpt message. 1147 o The various MEASUREMENT-ATTRIBUTES TLVs are encoded in all PCEP 1148 messages for the LSP with reporting features enabled, the absence 1149 of the corresponding MEASUREMENT-ATTRIBUTES TLV indicates that the 1150 PCEP speaker wishes to disable the feature. 1152 8.2. The MEASUREMENT Objects 1154 When a TE LSP is enabled with a measurement reporting feature, the 1155 PCC SHOULD include the corresponding MEASUREMENT Object to report the 1156 measured values to the PCE in the PCRpt message [DRAFT-PCE- 1157 STATEFUL]. 1159 The format of the "actual_attribute-list" in the PCRpt message is 1160 modified as following: 1162 ::=[] 1163 [] 1164 [] 1165 [] 1167 9. Scaling Considerations 1169 It should be noted that when measurement reporting is deployed under 1170 LSP scale, it can lead to frequent reporting updates to the PCE. 1171 Operators are advised to set the values of various measurement 1172 reporting parameters appropriate for the deployed LSP scale. 1174 If a PCE gets overwhelmed, it can notify the PCC to temporarily 1175 suspend the reporting of the measurements as described below. 1177 9.1. The PCNtf Message 1179 As per [RFC5440], the PCEP Notification message (PCNtf) can be sent 1180 by a PCEP speaker to notify its peer of a specific event. A PCEP 1181 speaker SHOULD notify its PCEP peer that it is overwhelmed, and on 1182 receipt of such notification the peer SHOULD NOT send any PCEP 1183 messages related to measurement reporting. If a PCEP message related 1184 to measurement reporting is received, it MUST be silently ignored. 1186 o When a PCEP speaker is overwhelmed, it SHOULD notify its peer by 1187 sending a PCNtf message with Notification Type = TBD15 (PM 1188 Overwhelm State) and Notification Value = 1 (Entering PM overwhelm 1189 state). 1191 o Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY be included that 1192 specifies the time period during which no further PCEP messages 1193 related to PM should be sent. 1195 o When the PCEP speaker is no longer in the overwhelm state and is 1196 available to process the PM reporting, it SHOULD notify its peer 1197 by sending a PCNtf message with Notification Type = TBD15 (PM 1198 Overwhelm State) and Notification Value = 2 (Clearing PM overwhelm 1199 state). 1201 10. Security Considerations 1203 This document defines new MEASUREMENT-ATTRIBUTES TLVs, CAPABILITY 1204 TLVs and MEASUREMENT Objects for reporting loss, delay measurements 1205 and bandwidth utilization which do not add additional security 1206 concerns beyond those discussed in [RFC5440] and 1207 [DRAFT-PCE-STATEFUL]. 1209 Some deployments may find the reporting of the performance 1210 measurement and bandwidth utilization information as extra sensitive 1211 as it could be used to influence LSP path computation and LSP setup 1212 with adverse effect. Additionally, snooping of PCEP messages with 1213 such data or using PCEP messages for network reconnaissance, may give 1214 an attacker sensitive information about the operations of the 1215 network. Thus, such deployment should employ suitable PCEP security 1216 mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or 1217 [DRAFT-PCE-PCEPS]. 1219 11. Manageability Considerations 1221 11.1. Control of Function and Policy 1223 The performance measurement reporting SHOULD be controlled per TE 1224 tunnel (at PCC or PCE) and the values for feature attributes e.g. 1225 measurement-interval, report-interval, report-threshold SHOULD be 1226 configurable by an operator. 1228 11.2. Information and Data Models 1230 A Management Information Base (MIB) module for modeling PCEP is 1231 described in [RFC7420]. However, one may prefer the mechanism for 1232 configuration using YANG data model [DRAFT-PCE-PCEP-YANG]. These 1233 SHOULD be enhanced to provide controls and indicators for support of 1234 performance measurement reporting feature. Support for various 1235 configuration knobs as well as counters of messages sent/received 1236 containing the TLVs (defined in this document) SHOULD be added. 1238 11.3. Liveness Detection and Monitoring 1240 Mechanisms defined in this document do not imply any new liveness 1241 detection and monitoring requirements in addition to those already 1242 listed in [RFC5440]. 1244 11.4. Verify Correct Operations 1246 Mechanisms defined in this document do not imply any new operation 1247 verification requirements in addition to those already listed in 1248 [RFC5440]. 1250 11.5. Requirements On Other Protocols 1252 Mechanisms defined in this document do not add any new requirements 1253 on other protocols. 1255 11.6. Impact On Network Operations 1257 In order to avoid any unacceptable impact on network operations, an 1258 implementation SHOULD allow a limit to be placed on the number of 1259 LSPs that can be enabled with performance measurement reporting 1260 feature. An implementation MAY allow a limit to be placed on the 1261 rate of measurement reporting messages sent by a PCEP speaker and 1262 received by a peer. An implementation MAY also allow sending a 1263 notification when a PCEP speaker is overwhelmed or the rate of 1264 messages reach a threshold. 1266 12. IANA Considerations 1268 12.1. Measurement Capability TLV Types 1270 This document defines the following new PCEP TLVs; IANA is requested 1271 to make the following allocations from the "PCEP TLV Type Indicators" 1272 registry. 1275 Type Name Reference 1276 ---------------------------------------------------------- 1277 TBD1 DELAY-MEASUREMENT-CAPABILITY [This I.D.] 1278 TBD2 LOSS-MEASUREMENT-CAPABILITY [This I.D.] 1279 TBD3 BANDWIDTH-UTILIZATION-CAPABILITY [This I.D.] 1281 12.1.1. Flag Fields for MEASUREMENT-CAPABILITY TLVs 1283 IANA is requested to create a registry to manage the Flag field of 1284 the DELAY-MEASUREMENT-CAPABILITY TLV, LOSS-MEASUREMENT-CAPABILITY TLV 1285 and BANDWIDTH-UTILIZATION-CAPABILITY TLV. 1287 New bit numbers are allocated only by an IETF Review action 1288 [RFC5226]. Each bit should be tracked with the following qualities: 1290 o Bit number (counting from bit 0 as the most significant bit) 1291 o Capability description 1293 o Defining RFC 1295 The following value are defined in this document for the Flag field 1296 for - 1298 DELAY-MEASUREMENT-CAPABILITY TLV: 1300 Bit Description Reference 1301 ------------------------------------------------------------ 1302 31 Unidirectional Delay Measurement [This I.D.] 1303 30 Bidirectional Delay Measurement [This I.D.] 1305 LOSS-MEASUREMENT-CAPABILITY TLV: 1307 Bit Description Reference 1308 ------------------------------------------------------------ 1309 31 Unidirectional Loss Measurement [This I.D.] 1310 30 Bidirectional Loss Measurement [This I.D.] 1311 29 Inferred Loss Measurement Mode [This I.D.] 1312 28 Direct Loss Measurement Mode [This I.D.] 1314 12.2. MEASUREMENT-ATTRIBUTES TLVs 1316 This document defines the following new PCEP TLV Types; IANA is 1317 requested to make the following TLV type allocations from the "PCEP 1318 TLV Type Indicators" registry. 1319 1322 Type Name Reference 1323 ------------------------------------------------------------- 1324 TBD4 DELAY-MEASUREMENT-ATTRIBUTES [This I.D.] 1325 TBD16 LOSS-MEASUREMENT-ATTRIBUTES [This I.D.] 1326 TBD17 BW-UTILIZATION-MEASUREMENT-ATTRIBUTES [This I.D.] 1328 12.2.1. The Sub-TLVs For MEASUREMENT-ATTRIBUTES TLVs 1330 IANA is requested to create an "MEASUREMENT-ATTRIBUTES Sub-TLV Types" 1331 sub-registry in the "PCEP TLV Type Indicators" registry. New sub-TLV 1332 are allocated only by an IETF Review action [RFC5226]. 1334 This document defines the following sub-TLV types: 1336 Type Name Reference 1337 ---------------------------------------------------------- 1338 0 Reserved [This I.D.] 1339 1 Measurement-Enable sub-TLV [This I.D.] 1340 2 Measurement-Interval sub-TLV [This I.D.] 1341 3 Report-Threshold sub-TLV [This I.D.] 1342 4 Report-Threshold-Percentage sub-TLV [This I.D.] 1343 5 Report-Interval sub-TLV [This I.D.] 1344 6- Unassigned [This I.D.] 1345 65535 1347 12.2.1.1. Flag Fields in Measurement-Enable sub-TLV 1349 IANA is requested to create a registry to manage the Flag field of 1350 the Measurement-Enable sub-TLV. 1352 New bit numbers are allocated only by an IETF Review action 1353 [RFC5226]. Each bit should be tracked with the following qualities: 1355 o Bit number (counting from bit 0 as the most significant bit) 1357 o Capability description 1359 o Defining RFC 1361 The following value are defined in this document for the Flag field. 1363 Bit Description Reference 1364 ------------------------------------------------------------ 1365 31 One-Way Delay Measurement Enabled [This I.D.] 1366 30 Two-Way Delay Measurement Enabled [This I.D.] 1367 29 Unidirectional Loss Measurement Enabled [This I.D.] 1368 28 Bidirectional Loss Measurement Enabled [This I.D.] 1369 27 Inferred Loss Measurement Enabled [This I.D.] 1370 26 Bandwidth Utilization Reporting Enabled [This I.D.] 1372 12.3. Measurement Object-Class 1374 This document defines Object-Class for the following Objects; IANA is 1375 requested to make the following allocations from the "PCEP Objects" 1376 registry. 1379 Object-Class Name Reference 1380 ---------------------------------------------------------- 1381 TBD5 DELAY-MEASUREMENT Object [This I.D.] 1382 TBD6 LOSS-MEASUREMENT Object [This I.D.] 1384 12.3.1. DELAY-MEASUREMENT Object-Types 1386 IANA is requested to create an "DELAY-MEASUREMENT Object-Types" 1387 sub-registry for DELAY-MEASUREMENT Object (Object-class TBD5). 1389 This document defines the following object-types: 1391 Object-Type Name Reference 1392 ------------------------------------------------------------------ 1393 0 Reserved [This I.D.] 1394 1 One-Way Delay Measurement Value [This I.D.] 1395 2 One-Way Delay Measurement Min/Max Values [This I.D.] 1396 3 One-Way Delay Variation Measurement Value [This I.D.] 1397 4 Two-Way Delay Measurement Value [This I.D.] 1398 5 Two-Way Delay Measurement Min/Max Values [This I.D.] 1399 6 Two-Way Delay Variation Measurement Value [This I.D.] 1401 12.3.2. LOSS-MEASUREMENT Object-Types 1403 IANA is requested to create an "LOSS-MEASUREMENT Object-Types" 1404 sub-registry for LOSS-MEASUREMENT Object (Object-class TBD6). 1406 This document defines the following object-types: 1408 Object-Type Name Reference 1409 ---------------------------------------------------------- 1410 0 Reserved [This I.D.] 1411 1 Tx Packets-Lost [This I.D.] 1412 2 Rx Packets-Lost [This I.D.] 1414 12.3.3. BANDWIDTH Object-Type 1416 This document defines new Object-Type for the BANDWIDTH object 1417 (Object-Class 5, [RFC5440]); IANA is requested to make the following 1418 allocation from the "PCEP Objects" registry. 1419 1421 Object-Type Name Reference 1422 ---------------------------------------------------------- 1423 TBD14 BANDWIDTH-UTILIZATION Object [This I.D.] 1425 12.4. PCE Error Codes 1427 This document defines two new error-values for PCErr with error-code 1428 19 (Invalid Operation). IANA is requested to make the following 1429 allocations. 1431 Error-Value Name Reference 1432 ------------------------------------------------------------------- 1433 TBD7 Delay-Measurement capability 1434 was not advertised [This I.D.] 1435 TBD8 Loss-Measurement capability 1436 was not advertised [This I.D.] 1437 TBD9 Bidirectional Measurement capability 1438 was not advertised [This I.D.] 1439 TBD10 Unidirectional Measurement capability 1440 was not advertised [This I.D.] 1441 TBD11 Inferred Mode Loss Measurement capability 1442 was not advertised [This I.D.] 1443 TBD12 Direct Mode Loss Measurement capability 1444 was not advertised [This I.D.] 1445 TBD13 Bandwidth Utilization capability 1446 was not advertised [This I.D.] 1448 12.5. Notification Object-Type 1450 IANA is requested to allocate new Notification Types and Notification 1451 Values within the "Notification Object" sub-registry of the PCEP 1452 Numbers registry, as follows: 1454 Type Meaning Reference 1455 -------------------------------------------------------------- 1456 TBD15 PM Overwhelm State [This I.D.] 1458 Notification-value=1: Entering PM overwhelm state 1459 Notification-value=2: Clearing PM overwhelm state 1461 13. References 1463 13.1. Normative References 1465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1466 Requirement Levels", BCP 14, RFC 2119, March 1997. 1468 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1469 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1470 May 2008. 1472 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1473 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1474 2009. 1476 [DRAFT-PCE-STATEFUL] Crabbe, E., Minei, I., Medved, J., and R. 1477 Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- 1478 stateful-pce, (work in progress). 1480 [DRAFT-PCE-INITIATED-LSP] Crabbe, E., Minei, I., Sivabalan, S., and 1481 R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in 1482 a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp, 1483 (work in progress). 1485 13.2. Informative References 1487 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1488 "MPLS Generic Associated Channel", RFC 5586, June 2009. 1490 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 1491 L., and L. Berger, "A Framework for MPLS in Transport 1492 Networks", RFC 5921, July 2010. 1494 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1495 Authentication Option", RFC 5925, June 2010. 1497 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1498 Measurement for MPLS Networks", DOI 10.17487/RFC6374, RFC 1499 6374, September 2011. 1501 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 1502 Measurement Profile for MPLS-Based Transport Networks", 1503 RFC 6375, September 2011. 1505 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1506 Hardwick, "Path Computation Element Communication Protocol 1507 (PCEP) Management Information Base (MIB) Module", RFC 1508 7420, December 2014. 1510 [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, and S. Previdi, 1511 "OSPF Traffic Engineering (TE) Metric Extensions", RFC 1512 7471, March 2015. 1514 [RFC7810] S. Previdi, S. Giacalone, D. Ward, J. Drake, and Q. Wu, 1515 "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 1516 7810, May 2016. 1518 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1519 "Performance-Based Path Selection for Explicitly Routed 1520 Label Switched Paths (LSPs) Using TE Metric Extensions", 1521 RFC 7823, May 2016. 1523 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path 1524 for Packet Loss and Delay Measurement for MPLS Networks", 1525 RFC 7876, July 2016. 1527 [DRAFT-PCE-PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1528 Transport for PCEP", draft-ietf-pce-pceps, (work in 1529 progress). 1531 [DRAFT-PCE-SERVICE-AWARE] Dhody, D., V. Manral, V., Ali, Z., and 1532 Kumaki, K., "Extensions to the Path Computation Element 1533 Communication Protocol (PCEP) to compute service aware 1534 Label Switched Path (LSP)", draft-ietf-pce-pcep-service- 1535 aware, (work in progress). 1537 [DRAFT-IDR-TE-PM-BGP] Wu, Q., Danhua, W., Previdi, S., Gredler, H., 1538 and S. Ray, "BGP attribute for North-Bound Distribution of 1539 Traffic Engineering (TE) performance Metrics", draft-ietf- 1540 idr-te-pm-bgp (work in progress). 1542 [DRAFT-PCE-PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. 1543 Tantsura, "A YANG Data Model for Path Computation Element 1544 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1545 (work in progress). 1547 [DRAFT-IETF-PCE-AUTOBW] Dhody, D., Palle, U., Singh, R., Gandhi, R., 1548 and L. Fang, "PCEP Extensions for MPLS-TE LSP Automatic 1549 Bandwidth Adjustment with Stateful PCE", draft-ietf-pce- 1550 stateful-pce-auto-bandwidth (work in progress). 1552 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 1553 "Standard for Binary Floating-Point Arithmetic", IEEE 1554 Standard 754, August 1985. 1556 Acknowledgments 1558 TBA. 1560 Authors' Addresses 1562 Rakesh Gandhi 1563 Cisco Systems, Inc. 1565 EMail: rgandhi@cisco.com 1567 Bin Wen 1568 Comcast 1570 EMail: Bin_Wen@cable.comcast.com 1572 Colby Barth 1573 Juniper Networks 1575 EMail: cbarth@juniper.net 1577 Dhruv Dhody 1578 Huawei Technologies 1579 India 1581 EMail: dhruv.ietf@gmail.com