idnits 2.17.1 draft-chen-detnet-loss-delay-00.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 22, 2018) is 2014 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 445, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-08 == 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: A later version (-20) exists of draft-ietf-detnet-use-cases-19 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 25, 2019 October 22, 2018 7 DetNet Packet Loss and Delay Performance Measurement 8 draft-chen-detnet-loss-delay-00 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 25, 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 Command Line Interface (CLI) or through the DetNet 244 configuration model [I-D.geng-detnet-conf-yang]. 246 Another way is to use the signalling protocol as the enabler of 247 performance measurement. More detail will be aded in the future. 249 [Editor notes: 251 This document introduces three ways (as summarized below) to enable 252 PM on a DetNet flow. We'd like to solicit more inputs and comments 253 from the WG: 255 1. Indicated by the "D/L" bits: A straightforward way to indicate 256 when to measure, which packets to measured. The cost is to take 257 two bits (or at least one bit) away from the sequence number. 259 2. Configured by CLI or YANG: Normally, it's easy to enable/disable 260 PM on a DetNet flow. The receiving node may take more time 261 (e.g., by matching a local configuration item to determine) to 262 determine whether a packet should be counted, whether a packet 263 should be timestamped. And it is difficult to support if only 264 partial packets of flow need to be measured. This is a common 265 case for packet delay measurement, where sample measurement is 266 acceptable and reasonable. 268 3. Signalled by control protocol: The pros and cons similar to 269 option 2. 271 ] 273 3. PM for IP-based Encapsulation 275 For IP-based encapsulation, since there is no service layer, the d- 276 CW-based solution as defined in Section 2 can not be applied. The 277 marking-based solution defined in [RFC8321] can be used. More detail 278 will be added in future versions. 280 4. Extensions to RFC6374 282 [RFC6374] defines how to communicate the packet counts and timestamps 283 between measurement points. In order to support passive PM, this 284 document defines several new TLVs to carry the correlation 285 information. The correlation information can be used to determine 286 with which DetNet service path a packet count/timestamp correlates, 287 and with which measurement interval a packet count correlates, and 288 with which packet a timestamp correlates. 290 Three new TLVs to LM and DM messages [RFC6374] are defined in the 291 following sub-sections. 293 4.1. Measurement Interval TLV 295 This document defines a new TLV which is referred to as Measurement 296 Interval TLV to Loss Measurement message [RFC6374]. The Measurement 297 Interval TLV carries the measurement interval that is used to 298 correlate the packet counts from the ingress node with the packet 299 counts from the egress nodes. Then the packet loss can be calculated 300 as described in Section 2. 302 The format of the Measurement Interval TLV is as below: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type (TBD1) | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Measurement Interval | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: Measurement Interval TLV 313 Where: 315 o The Type field is two octets in length, and the value is TBD1. 317 o The Length field is two octets in length, with a value is 4, 318 indicating the length of the Measurement Interval field. 320 o The Measurement Interval field is 4 octets in length, and carries 321 the measurement interval. 323 4.2. DetNet Control Word TLV 325 This document defines a new TLV which is referred to as DetNet 326 Control Word TLV to Delay Measurement message [RFC6374]. The 327 sequence number of the d-CW is used to correlate the timestamps from 328 the ingress node with the timestamp from the egress node. Then the 329 packet delay can be calculated as described in Section 2. 331 The format of the DetNet Control Word TLV is as below: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type (TBD2) | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | DetNet Control Word | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 3: DetNet Control Word TLV 342 Where: 344 o The Type field is two octets in length, and the value is TBD2. 346 o The Length field is two octets in length, with a value is 4, 347 indicating the length of the DetNet Control Word field. 349 o The DetNet Control Word is 4 octets in length. 351 4.3. Service Label TLV 353 This document defines a new TLV which is referred to as Service Label 354 TLV to Loss Measurement message and Delay Measurement message 355 [RFC6374]. The Service Label TLV carries the DetNet S-Label that is 356 allocated by the receiving node to the DetNet service path that is 357 being measured. Here, the receiving node can be the egress node, or 358 an relay node. The S-Label is used to determine to which DetNet 359 service path the packet counts/timestamps belong. 361 The format of the Service Label TLV is as below: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type (TBD3) | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Reserved | Service Label | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 4: Service Label TLV 372 Where: 374 o The Type field is two octets in length, and the value is TBD3. 376 o The Length field is two octets in length, with a value is 4, 377 indicating the length of the Reserved and the Service Label 378 fields. 380 o The Service Label field is 20-bit in length. 382 5. IANA Considerations 384 IANA is requested to allocate the following TLV types from the "MPLS 385 Loss/Delay Measurement TLV Object" sub-registry of the "Generic 386 Associated Channel (G-ACh) Parameters" registry: 388 Type Description Reference 389 ---- --------------------------------- --------- 390 TBD1 Measurement Interval This document 391 TBD2 DetNet Control Word This document 392 TBD3 DetNet Service Label This document 394 6. Security Considerations 396 This document enables the use of Passive monitoring to determine the 397 SLA conformance of DetNet service flows, and does not introduce any 398 additional Active monitoring packets to the network. As a result, 399 this document introduces no new security considerations beyond those 400 already described in Section 8 of [RFC6374] and Section 5 of 401 [RFC7799]. 403 7. Acknowledgements 405 8. References 407 8.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 415 Measurement for MPLS Networks", RFC 6374, 416 DOI 10.17487/RFC6374, September 2011, 417 . 419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 421 May 2017, . 423 8.2. Informative References 425 [I-D.geng-detnet-conf-yang] 426 Geng, X., Chen, M., Li, Z., and R. Rahman, "DetNet 427 Configuration YANG Model", draft-geng-detnet-conf-yang-06 428 (work in progress), October 2018. 430 [I-D.ietf-detnet-architecture] 431 Finn, N., Thubert, P., Varga, B., and J. Farkas, 432 "Deterministic Networking Architecture", draft-ietf- 433 detnet-architecture-08 (work in progress), September 2018. 435 [I-D.ietf-detnet-dp-sol-ip] 436 Korhonen, J. and B. Varga, "DetNet IP Data Plane 437 Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in 438 progress), October 2018. 440 [I-D.ietf-detnet-dp-sol-mpls] 441 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 442 Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in 443 progress), October 2018. 445 [I-D.ietf-detnet-use-cases] 446 Grossman, E., "Deterministic Networking Use Cases", draft- 447 ietf-detnet-use-cases-19 (work in progress), October 2018. 449 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 450 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 451 May 2016, . 453 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 454 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 455 "Alternate-Marking Method for Passive and Hybrid 456 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 457 January 2018, . 459 Authors' Addresses 461 Mach(Guoyi) Chen 462 Huawei 464 Email: mach.chen@huawei.com 466 Andrew G. Malis 467 Huawei 469 Email: agmalis@gmail.com