idnits 2.17.00 (12 Aug 2021) /tmp/idnits57814/draft-chen-detnet-loss-delay-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 23, 2018) is 1299 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) == Unused Reference: 'I-D.ietf-detnet-use-cases' is defined on line 446, but no explicit reference was found in the text == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-ip-01 == Outdated reference: A later version (-02) exists of draft-ietf-detnet-dp-sol-mpls-01 == Outdated reference: draft-ietf-detnet-use-cases has been published as RFC 8578 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft A. Malis 4 Intended status: Standards Track Huawei 5 Expires: April 26, 2019 October 23, 2018 7 DetNet Packet Loss and Delay Performance Measurement 8 draft-chen-detnet-loss-delay-01 10 Abstract 12 Deterministic Networking (DetNet) is defined to provide end-to-end 13 bounded latency and extremely low packet loss rates for critical 14 flows. It's important to measure and monitor the packet loss rates 15 and end-to-end delay and delay variation of a DetNet flow path, which 16 allows evaluation of whether the Service Level Agreements (SLA) of 17 the provided DetNet services are satisfied. These metrics are also 18 useful in network/traffic planning, trouble shooting, and network 19 performance evaluation. 21 This document defines protocol mechanisms to support passive 22 Performance Measurement (PM) for DetNet service. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in 29 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 26, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. DetNet Control Word based PM . . . . . . . . . . . . . . . . 3 68 2.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 4 69 2.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 5 70 2.3. Alternative Solutions to the "D/L" Bits . . . . . . . . . 6 71 3. PM for IP-based Encapsulation . . . . . . . . . . . . . . . . 6 72 4. Extensions to RFC6374 . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Measurement Interval TLV . . . . . . . . . . . . . . . . 7 74 4.2. DetNet Control Word TLV . . . . . . . . . . . . . . . . . 7 75 4.3. Service Label TLV . . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 8.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] can 87 provide end-to-end bounded latency and extremely low packet loss 88 rates for critical flows. This achieved by dedicating network 89 resources (e.g., link bandwidth and queue buffering) to DetNet flows, 90 and by replicating packets along multiple paths. 92 It's important to measure and monitor the packet loss rate and one- 93 way delay and delay variation of a DetNet flow path in order to 94 evaluate whether the Service Level Agreements (SLA) of the provided 95 DetNet services are satisfied. These metrics are also useful in 96 network/traffic planning, troubleshooting, and network performance 97 evaluation. 99 As defined in [RFC7799], performance measurement can be classified 100 into Active, Passive and Hybrid measurement. Active measurement is 101 performed by injecting Operations, Administration, and Maintenance 102 (OAM) packets to the network to estimate the performance of the 103 network by measuring the performance of the OAM packets. However, 104 adding extra traffic can affect the quantities to be measured to some 105 degree. On the other hand, passive measurement monitors the actual 106 service traffic, rather than injecting OAM packets to estimate the 107 traffic performance. Therefore, Passive performance measurement will 108 not affect the behavior of the real DetNet service, and also provide 109 more accurate measurement results. Accordingly, this document 110 defines protocol mechanisms to support Passive PM for DetNet 111 services. 113 DetNet defines two encapsulations, an MPLS-based encapsulation 114 [I-D.ietf-detnet-dp-sol-mpls], and an IP-based encapsulation 115 [I-D.ietf-detnet-dp-sol-ip]. For the MPLS based encapsulation, a 116 service layer is introduced, which is supported by a DetNet Service 117 Label (S-Label) and a DetNet Control Word (d-CW). The S-Label is 118 used to identify a DetNet flow. The d-CW contains a sequence number 119 that is designed for supporting the Packet Replication, Elimination, 120 and Ordering Functions (PREOF). When perform packet loss and delay 121 measurements, the sequence number can be used for packet accounting 122 and packet count/timestamp correlation as well. 124 [RFC6374] defines Loss Measurement (LM) and Delay Measurement (DM) 125 messages to communicate packet counts, timestamps, and other relevant 126 information between Measurement Points (MPs). This document defines 127 three new TLVs to the [RFC6374] LM message and DM messages. Which 128 are used for communicating the correlation information (e.g., 129 sequence number, measurement interval, and service label) that 130 enables the packet loss and packet delay calculation. The detailed 131 definitions of these new TLVs are described in Section 3. 133 2. DetNet Control Word based PM 135 As discussed above, MPLS-based DetNet encapsulation introduces an 136 S-Label and a d-CW. This document defines two new flags in the d-CW 137 (as shown in Figure 1). The L bit is defined to indicate whether the 138 loss measurement is enabled, and the D bit is defined to indicate 139 whether the delay measurement is enabled. 141 +-----------------+ 142 ~ IP/MPLS Tunnel ~ 143 +-----------------+ <--\ 144 | Service Label | | 145 +-----------------+ +-- Service Layer Header 146 +----| Control Word | | 147 | +-----------------+ <--/ 148 | | Payload | 149 | +-----------------+ 150 | 151 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 +--->|0 0 0 0|L|D| Sequence Number | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: DetNet Control Word 157 Where: 159 o L bit: Loss measurement indicator; 1 means the loss measurement is 160 enabled, otherwise the loss measurement is not enabled. 162 o D bit: Delay measurement indicator;1 means the delay measurement 163 is enabled, otherwise the delay measurement is not enabled. When 164 a node receive a packet with D bit set, it will timestamp the 165 packet and copy it for further PM processing. 167 2.1. Packet Loss Measurement 169 Assume a DetNet service path between node A and node B, where node A 170 is the ingress node, and node B is the egress node. To measure the 171 number of packets transmitted at node A but not received at node B 172 within a measurement interval, there needs a way to determine which 173 packets belong to which measurement interval. [RFC6374] uses OAM 174 packets to demarcate different measurement intervals. However, an 175 OAM packet-based solution cannot work when there is packet mis- 176 ordering. This document uses the sequence number to determine to 177 which measurement interval a packet belongs. Specifically, the 178 measurement interval number is calculated as the modulo of the 179 sequence number and a pre-configured constant. 181 o Measurement Interval = "Sequence Number" mod "Pre-configured 182 constant". 184 With this, the ingress and egress nodes can use the sequence number 185 of a packet to calculate the measurement interval number. The 186 packets with same interval number belong to the same measurement 187 interval. Then the packet loss can be calculated as below: 189 Loss[n] = A_TxP[n] - B_RxP[n], where: 191 o A_TxP[n] is the number of packets transmitted at node A within the 192 No. "n" measurement interval; 194 o B_RxP[n] is the number of packets received at node B within the 195 No. "n" measurement interval; 197 If the calculation is performed at one side of the path, the A_TxP[n] 198 or B_RxP[n] needs to be sent to the other side. The Loss Measurement 199 (LM) message defined in [RFC6374] is used to communicate the counts, 200 in order to correlate the counts from the ingress node with the 201 counts from the egress node. The extensions to [RFC6374] to 202 communicate the measurement interval are defined in Section 3. 204 If the calculation is performed at a centralized controller, then the 205 A_TxP[n] and B_RxP[n] need to be sent to the controller. The 206 mechanism for sending counts to a centralized controller is out side 207 the scope of this document. 209 2.2. Packet Delay Measurement 211 To measure the delay of a packet, the D bit of the d-CW MUST be set. 212 At the ingress node, record the time when sending the packet, with 213 the timestamp indexed by the sequence number. At the egress node, 214 when receiving a packet with D bit set, record the time when the 215 packet was received, with the timestamp indexed by the sequence 216 number. Then, with the timestamps from the ingress and egress nodes, 217 and the sequence number, the packet delay can be calculated as below: 219 Delay[n] = B_RxT[n] - A_TxT[n], where: 221 o B_RxT[n] identifies the timestamp at node B when receiving the No. 222 "n" packet; 224 o A_TxT[n] identifies the timestamp at node A when sending the No. 225 "n" packet; 227 Similar to loss measurement, the Delay Measurement (DM) message 228 defined in [RFC6374] is used to communicate the timestamps when 229 calculation is performed at either side of a DetNet service path. In 230 order to correlate the timestamps from the ingress node with the 231 timestamps from the egress node, extensions to [RFC6374] to 232 communicate the sequence number and other relevant information are 233 needed. The detailed definitions of these extensions are described 234 in Section 3. 236 The mechanism for sending timestamps to a centralized controller is 237 out side the scope of this document. 239 2.3. Alternative Solutions to the "D/L" Bits 241 Configuration can be used to indicate whether the delay and/or loss 242 measurements are enabled on a specific DetNet service flow. This can 243 be done by through the DetNet configuration model 244 [I-D.geng-detnet-conf-yang], a PCEP extension, a Command Line 245 Interface (CLI), or other means. 247 Another way is to use the signalling protocol as the enabler of 248 performance measurement. More detail will be added in the future. 250 [Editor notes: 252 This document introduces three ways (as summarized below) to enable 253 PM on a DetNet flow. We'd like to solicit more inputs and comments 254 from the WG: 256 1. Indicated by the "D/L" bits: A straightforward way to indicate 257 when to measure, which packets to measured. The cost is to take 258 two bits (or at least one bit) away from the sequence number. 260 2. Configured by CLI or YANG: Normally, it's easy to enable/disable 261 PM on a DetNet flow. The receiving node may take more time 262 (e.g., by matching a local configuration item to determine) to 263 determine whether a packet should be counted, whether a packet 264 should be timestamped. And it is difficult to support if only 265 partial packets of a flow need to be measured. This is a common 266 case for packet delay measurement, where sample measurement is 267 acceptable and reasonable. 269 3. Signalled by control protocol: The pros and cons similar to 270 option 2. 272 ] 274 3. PM for IP-based Encapsulation 276 For IP-based encapsulation, since there is no service layer, the d- 277 CW-based solution as defined in Section 2 can not be applied. The 278 marking-based solution defined in [RFC8321] can be used. More detail 279 will be added in future versions. 281 4. Extensions to RFC6374 283 [RFC6374] defines how to communicate the packet counts and timestamps 284 between measurement points. In order to support passive PM, this 285 document defines several new TLVs to carry the correlation 286 information. The correlation information can be used to determine 287 with which DetNet service path a packet count/timestamp correlates, 288 and with which measurement interval a packet count correlates, and 289 with which packet a timestamp correlates. 291 Three new TLVs to LM and DM messages [RFC6374] are defined in the 292 following sub-sections. 294 4.1. Measurement Interval TLV 296 This document defines a new TLV which is referred to as Measurement 297 Interval TLV to Loss Measurement message [RFC6374]. The Measurement 298 Interval TLV carries the measurement interval that is used to 299 correlate the packet counts from the ingress node with the packet 300 counts from the egress nodes. Then the packet loss can be calculated 301 as described in Section 2. 303 The format of the Measurement Interval TLV is as below: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type (TBD1) | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Measurement Interval | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 2: Measurement Interval TLV 314 Where: 316 o The Type field is two octets in length, and the value is TBD1. 318 o The Length field is two octets in length, with a value is 4, 319 indicating the length of the Measurement Interval field. 321 o The Measurement Interval field is 4 octets in length, and carries 322 the measurement interval. 324 4.2. DetNet Control Word TLV 326 This document defines a new TLV which is referred to as DetNet 327 Control Word TLV to Delay Measurement message [RFC6374]. The 328 sequence number of the d-CW is used to correlate the timestamps from 329 the ingress node with the timestamp from the egress node. Then the 330 packet delay can be calculated as described in Section 2. 332 The format of the DetNet Control Word TLV is as below: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type (TBD2) | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | DetNet Control Word | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3: DetNet Control Word TLV 343 Where: 345 o The Type field is two octets in length, and the value is TBD2. 347 o The Length field is two octets in length, with a value is 4, 348 indicating the length of the DetNet Control Word field. 350 o The DetNet Control Word is 4 octets in length. 352 4.3. Service Label TLV 354 This document defines a new TLV which is referred to as Service Label 355 TLV to Loss Measurement message and Delay Measurement message 356 [RFC6374]. The Service Label TLV carries the DetNet S-Label that is 357 allocated by the receiving node to the DetNet service path that is 358 being measured. Here, the receiving node can be the egress node, or 359 an relay node. The S-Label is used to determine to which DetNet 360 service path the packet counts/timestamps belong. 362 The format of the Service Label TLV is as below: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type (TBD3) | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Reserved | Service Label | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 4: Service Label TLV 373 Where: 375 o The Type field is two octets in length, and the value is TBD3. 377 o The Length field is two octets in length, with a value is 4, 378 indicating the length of the Reserved and the Service Label 379 fields. 381 o The Service Label field is 20-bit in length. 383 5. IANA Considerations 385 IANA is requested to allocate the following TLV types from the "MPLS 386 Loss/Delay Measurement TLV Object" sub-registry of the "Generic 387 Associated Channel (G-ACh) Parameters" registry: 389 Type Description Reference 390 ---- --------------------------------- --------- 391 TBD1 Measurement Interval This document 392 TBD2 DetNet Control Word This document 393 TBD3 DetNet Service Label This document 395 6. Security Considerations 397 This document enables the use of Passive monitoring to determine the 398 SLA conformance of DetNet service flows, and does not introduce any 399 additional Active monitoring packets to the network. As a result, 400 this document introduces no new security considerations beyond those 401 already described in Section 8 of [RFC6374] and Section 5 of 402 [RFC7799]. 404 7. Acknowledgements 406 8. References 408 8.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 416 Measurement for MPLS Networks", RFC 6374, 417 DOI 10.17487/RFC6374, September 2011, 418 . 420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 421 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 422 May 2017, . 424 8.2. Informative References 426 [I-D.geng-detnet-conf-yang] 427 Geng, X., Chen, M., Li, Z., and R. Rahman, "DetNet 428 Configuration YANG Model", draft-geng-detnet-conf-yang-06 429 (work in progress), October 2018. 431 [I-D.ietf-detnet-architecture] 432 Finn, N., Thubert, P., Varga, B., and J. Farkas, 433 "Deterministic Networking Architecture", draft-ietf- 434 detnet-architecture-09 (work in progress), October 2018. 436 [I-D.ietf-detnet-dp-sol-ip] 437 Korhonen, J. and B. Varga, "DetNet IP Data Plane 438 Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in 439 progress), October 2018. 441 [I-D.ietf-detnet-dp-sol-mpls] 442 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 443 Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in 444 progress), October 2018. 446 [I-D.ietf-detnet-use-cases] 447 Grossman, E., "Deterministic Networking Use Cases", draft- 448 ietf-detnet-use-cases-19 (work in progress), October 2018. 450 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 451 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 452 May 2016, . 454 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 455 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 456 "Alternate-Marking Method for Passive and Hybrid 457 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 458 January 2018, . 460 Authors' Addresses 462 Mach(Guoyi) Chen 463 Huawei 465 Email: mach.chen@huawei.com 467 Andrew G. Malis 468 Huawei 470 Email: agmalis@gmail.com