idnits 2.17.1 draft-li-ippm-ref-delay-measurement-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Li 3 Internet-Draft T. Sun 4 Intended status: Informational H. Yang 5 Expires: August 26, 2021 D. Chen 6 China Mobile 7 February 22, 2021 9 One-way Delay Measurement Based on Reference Delay 10 draft-li-ippm-ref-delay-measurement-00 12 Abstract 14 The end-to-end network one-way delay is an important performance 15 indicator of the arising 5G network. One type of existing methods 16 requires the end-to-end deployment of accurate clock synchronization 17 mechanism, such as PTP or GPS, which results in relatively high 18 deployment cost. Another type of existing methods uses round-trip 19 delay measurements to estimate the one-way delay. However, since the 20 delay of the downlink and uplink of the 5G network may be asymmetric, 21 the accuracy is relatively low. This document introduces a method to 22 accurately measure end-to-end network one-way delay using reference 23 delay without deploying clock synchronization. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 26, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. The method of One-way Delay Measurement Based on Reference 64 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. One-way Delay Measurement Method . . . . . . . . . . . . 5 66 3.2. Packet and Measurement Header Format . . . . . . . . . . 7 67 4. Acquisition of Reference Delay . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 With the gradual promotion of new-generation network technologies 76 (such as 5G networks) and their application in various industries, 77 SLA guarantees for network quality become more and more important. 78 For example, different 5G services have different requirements for 79 network performance indicators such as delay, jitter, packet loss, 80 and bandwidth. Among them, the 5G network delay is defined as end- 81 to-end one-way delay of the network. Real-time and accurate 82 measurement of the end-to-end one-way delay is very important for the 83 SLA guarantee of network services, and has become an urgent and 84 important requirement. 86 A common scenario for end-to-end one-way delay measurement, such as a 87 5G network HD video surveillance service scenario, is shown in figure 88 1. One end of the network is a high-definition surveillance camera, 89 as shown in the wireless access side on the left in figure 1, and the 90 other end of the network is a video server. The end-to-end one-way 91 delay measurement of the above-mentioned network is the one-way delay 92 from the surveillance camera to the video server, including wireless 93 access network, optical transmission network, 5G core network, and IP 94 data network. The delay is the sum of T1, T2, T3 and T4 as shown in 95 figure 1. 97 +--------+ +-------+ +-------+ +-------+ 98 +------+ |Wireless| |Optical| |5G Core| | IP | +------+ 99 |Camera+<->+ Access +<->+ Trans +<->+Network+<->+ Data +<->+Server| 100 +------+ |Network | |Network| | | |Network| +------+ 101 +--------+ +-------+ +-------+ +-------+ 103 |<---- T1 ---->|<--- T2 -->|<--- T3 -->|<--- T4 ---->| 105 Figure 1:A Scenario for End-to-end One-way Delay 107 The existing one-way delay measurement solutions are divided into two 108 categories. The first type is a one-way delay measurement solution 109 based on round-trip communication delay, such as TWAMP[RFC8186]. The 110 second type of one-way delay measurement solution is based on 111 accurate network time synchronization mechanism, such as NTP[RFC5905] 112 or PTP[IEEE.1588.2008]. 114 The one-way delay measurement solution based on the round-trip delay 115 requires the deployment of network measurement probes on the source 116 end, namely the surveillance camera side, and the destination end, 117 namely the server side. The source sends the measurement packet; the 118 destination reflects the received measurement packet; after the 119 source receives the measurement packet reflected by the destination, 120 the round-trip delay can be obtained. By dividing the round-trip 121 delay by two, the end-to-end one-way delay can be approximated. 122 However, because the uplink delay and downlink delay of an end-to-end 123 network (such as a 5G network) are not equal, the accuracy of the 124 end-to-end one-way delay approximated by the round-trip communication 125 delay is low. It cannot meet the requirements for accurate end-to- 126 end one-way delay measurement. 128 The one-way delay measurement solution based on precise network time 129 synchronization requires the deployment of an end-to-end time 130 synchronization mechanism. The current time synchronization accuracy 131 based on the NTP protocol can only reach millisecond level, which 132 cannot fully meet the measurement accuracy requirements, while the 133 time synchronization accuracy based on the GPS module or the PTP 134 protocol can meet the requirements. On the basis of end-to-end time 135 synchronization, the source sends a measurement packet with an 136 accurate egress timestamp; when the destination receives the 137 measurement packet, the accurate ingress timestamp is marked. Since 138 the source and destination have already performed end-to-end time 139 synchronization, the ingress timestamp is subtracted from the egress 140 timestamp to obtain the end-to-end one-way delay. However, for GPS 141 module-based time synchronization solutions, in actual deployment 142 scenarios, many data centers are located underground or in rooms 143 without GPS signals,so GPS clock information cannot be continuously 144 obtained for time synchronization. For time synchronization 145 solutions based on the PTP protocol, end-to-end deployment is 146 required, which is to say, each device in the wireless access 147 network, optical transmission network, 5G core network and IP data 148 network must support the PTP protocol, which is unrealistic at the 149 moment. So the one-way delay measurement solution based on precise 150 end-to-end time synchronization is expensive and difficult to be 151 deployed. 153 This document introduces a one-way delay measurement solution based 154 on reference delay. The end-to-end one-way delay of a reference 155 packet with a stable delay is used as the reference delay, which is 156 known in advance and has extremely low jitter. For example, next 157 generation networks are gradually supporting deterministic 158 network[RFC8655] and end-to-end network slicing technologies, which 159 are characterized by bounded end-to-end delay and extremely low 160 jitter of transmitted packets, which are ideal for reference packets. 161 We can use the reference delay provided by the reference packet to 162 indirectly measure the one-way delay of other packet streams under 163 measurement. 165 2. Conventions Used in This Document 167 2.1. Terminology 169 NTP Network Time Protocol 171 PTP Precision Time Protocol 173 TWAMP Two-Way Active Measurement Protocol 175 SLA Service Level Agreement 177 2.2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14[RFC2119][RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 3. The method of One-way Delay Measurement Based on Reference Delay 187 The end-to-end one-way delay of a reference packet with a stable 188 delay in the network can be used as a reference delay, denoted as 189 Dref, which is known in advance and has extremely low jitter. This 190 section will describe in detail the end-to-end one-way delay 191 measurement method based on reference delay of the reference packet. 192 Assume that the end-to-end one-way delay from the sender to the 193 receiver is measured, as shown in figure 2. The intermediate network 194 devices other than the sender and receiver are hidden in the figure. 196 +------------+ +------------+ 197 | | Clock Offset | | 198 | Sender | +---------------> | Receiver | 199 | | | | 200 +------------+ +------------+ 202 Reference +-----+ Dref +-----+ 203 Packet: | Ts1 | +-------------------> | Tr1 | 204 +-----+ +-----+ 206 Target +-----+ Dtarget +-----+ 207 Packet: | Ts2 | +-------------------> | Tr2 | 208 +-----+ +-----+ 210 Figure 2:Topology of One-way Delay Measurement 212 3.1. One-way Delay Measurement Method 214 The measurement steps are shown in figure 3, which describe the 215 measurement steps at the sender side and receiver side respectively. 216 For the sender side, a reference packet is sent. In the first step, 217 the sender gets ready to send a reference packet; in the second step, 218 the sender marks an egress timestamp Ts1 for the reference packet; in 219 the third step, the sender encapsulates the egress timestamp of the 220 reference packet in the measurement header of the reference packet; 221 in the fourth step, the sender sends the reference packet. For the 222 target packet, the sender side procedures are the same,we omit it for 223 simplicity. The sending time of the target packet is according to 224 the traffic model of real applications. On the other hand, the 225 sender can send the reference packet according to a fixed frequency 226 or adjust the sending frequency according to the link usage rate, so 227 that the target packet can always find a nearby reference packet to 228 make sure that the sending time interval between the reference packet 229 and the target packet is small. 231 For the reference packet, the processing steps at the receiver are 232 shown in figure 3. In the first step, the reference packet arrives 233 at the receiver, and the receiver receives the reference packet; in 234 the second step, the receiver timestamps the reference packet at the 235 entrance, which is denoted as Tr1; in the third step, the receiver 236 decapsulates the measurement header of the reference packet to obtain 237 the sender side timestamp Ts1; in the fourth step, the receiver 238 records the timestamp information of Ts1 and Tr1; in the fifth step, 239 the receiver uses the source/destination pair obtained by 240 decapsulation in the third step as the search key, queries the 241 reference delay table and records the reference delay search result, 242 denoted as Dref. 244 For the target packet, the processing steps at the receiver are also 245 shown in figure 3. In the first step, the target packet arrives at 246 the receiver, and the receiver receives the target packet; in the 247 second step, the receiver timestamps the target packet at the 248 entrance, which is denoted as Tr2; in the third step, the receiver 249 decapsulates the measurement header of the target packet to obtain 250 the sender side timestamp Ts2; in the fourth step, the receiver 251 records the timestamp information of Ts2 and Tr2; in the fifth step, 252 the receiver calculates the target one-way delay, which we want to 253 measure, according to the recorded timestamp information Ts1, Ts2, 254 Tr1, Tr2 and reference delay information Dref. The target one-way 255 delay of the target packet is recorded as Dtarget. 257 Sender Side Procedures for both Reference and Target Packet: 259 +-------+ +------------+ +-------------+ +-------+ 260 |Sender | |Sender Side | |Sender Side | |Sending| 261 |Ready +-->+Timestamping+-->+Encapsulation+-->+ Packet| 262 | | | | | | | | 263 +-------+ +------------+ +-------------+ +-------+ 265 Receiver Side Procedures for Reference Packet: 267 +---------+ +-------------+ +-------------+ +---------+ +---------+ 268 |Reference| |Receiver Side| |Receiver Side| |Timestamp| |Query for| 269 |Packet +->+Timestamping +->+Decapsulation+->+Recorded +->+Reference| 270 |Arrival | | | | | | | | Delay | 271 +---------+ +-------------+ +-------------+ +---------+ +---------+ 273 Receiver Side Procedures for Target Packet: 275 +-------+ +-------------+ +-------------+ +---------+ +-----------+ 276 | Target| |Receiver Side| |Receiver Side| |Timestamp| | One-way | 277 | Packet+->+Timestamping +->+Decapsulation+->+Recorded +->+ Delay | 278 |Arrival| | | | | | | |Calculation| 279 +-------+ +-------------+ +-------------+ +---------+ +-----------+ 281 Figure 3: Measurement steps for Sender and Receiver Respectively 283 Now we describe the fifth step of the receiver procedures for the 284 target packet in figure 3, that is, calculating the one-way delay 285 Dtarget of the target packet based on the recorded timestamp 286 information Ts1, Ts2, Tr1, Tr2 and the reference delay information 287 Dref. The calculation method is the core of this solution. For the 288 reference packet, leveraging the receiver timestamp minus the sender 289 timestamp, we can get Equation 1. 291 Equation 1: Tr1 - Ts1 = Dref + Offset1 293 where Offset1 is the time offset between the sender and the receiver 294 when the reference packet transmission occurs. Similarly, for the 295 target packet, we can get Equation 2 using the same method. 297 Equation 2: Tr2 - Ts2 = Dtarget + Offset2 299 where Offset2 is the time offset between the sender and the receiver 300 when the target packet transmission occurs. Assuming that the 301 sending time interval between the reference packet and the target 302 packet is very small, we can get that Offset1 = Offset2. By 303 (Equation 2 - Equation 1), we can get Equation 3. 305 Equation 3: Dtarget = (Tr2 + Ts1) - (Tr1 + Ts2) + Dref 307 So the one-way delay of the target packet can be calculated by 308 Equation 3. 310 3.2. Packet and Measurement Header Format 312 The sender encapsulates the timestamp information and sender-receiver 313 pair information in the measurement header of the sent packet, as 314 shown in figure 4. The position of measurement header is in the 315 option field of the TCP protocol header. Detailed measurement header 316 format is shown in figure 5. The Kind value can be 253 or 254, and 317 the Length value is 8, which is in accordance with TCP 318 option[RFC4727]. The sender ID is one octet, and the receiver ID is 319 also one octet. The sender side timestamp is 4 octets, which can 320 store accurate timestamp information. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Ethernet header (14 octets) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | IP header (20 octets) | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 | TCP header (20 octets) | 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Measurement Header in TCP option (8 octets) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Data | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 4: Format of Reference or Target Packet 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Kind | Length | Sender ID | Receiver ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Sender Side Timestamp (4 octets) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 5: Detailed Measurement Header Format 354 4. Acquisition of Reference Delay 356 The end-to-end one-way delay includes three parts, namely the 357 transmission delay, the internal processing delay of the network 358 devices, and the internal queueing delay of the network devices. 359 Among them, fixed parts of the delay include transmission delay and 360 internal processing delay. The transmission delay is related to 361 transmission distance and transmission media. For example, in 362 optical fiber, it is about 5ns per meter. With transmission path and 363 media determined, it is basically a fixed value. The internal 364 processing delay of a network device includes processing delay of the 365 device's internal pipeline or processor and serial-to-parallel 366 conversion delay of the interface, which is related to in/out port 367 rate of the device, message length and forwarding behavior. The 368 magnitude of the internal processing delay is at microsecond level, 369 and it is basically a fixed value related to the chip design 370 specifications of a particular network device. Variable part of the 371 delay is the internal queueing delay. The queueing delay of the 372 device internal buffer is related to the queue depth, queue 373 scheduling algorithm, message priority and message length. For each 374 device along the end-to-end path, the queueing delay can reach 375 microsecond or even millisecond level, depending on values of the 376 above parameters and network congestion state. 378 With the continuous development of networking technologies and 379 application requirements, a series of new network technologies have 380 emerged which can guarantee bounded end-to-end delay and ultra small 381 jitter. For example, deterministic network[RFC8655], by leveraging 382 novel scheduling algorithms and packet priority settings, can 383 stabilize queuing delay of network device on the end-to-end path. As 384 a result, the end-to-end one-way delay is extremely low and bounded. 385 So packets transmitted by a deterministic network with delay 386 guarantee can be used as reference packets, and their end-to-end one- 387 way delay can be used as reference delays. The acquisition method of 388 reference delay is not limited to the above method based on 389 deterministic network technology. 391 5. Security Considerations 393 TBD. 395 6. IANA Considerations 397 TBD. 399 7. Normative References 401 [IEEE.1588.2008] 402 IEEE, "IEEE Standard for a Precision Clock Synchronization 403 Protocol for Networked Measurement and Control Systems", 404 July 2008. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 412 ICMPv6, UDP, and TCP Headers", RFC 4727, 413 DOI 10.17487/RFC4727, November 2006, 414 . 416 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 417 "Network Time Protocol Version 4: Protocol and Algorithms 418 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 419 . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 426 Timestamp Format in a Two-Way Active Measurement Protocol 427 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 428 . 430 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 431 "Deterministic Networking Architecture", RFC 8655, 432 DOI 10.17487/RFC8655, October 2019, 433 . 435 Authors' Addresses 437 Yang Li 438 China Mobile 439 Beijing 100053 440 China 442 Email: liyangzn@chinamobile.com 444 Tao Sun 445 China Mobile 446 Beijing 100053 447 China 449 Email: suntao@chinamobile.com 451 Hongwei Yang 452 China Mobile 453 Beijing 100053 454 China 456 Email: yanghongwei@chinamobile.com 457 Danyang Chen 458 China Mobile 459 Beijing 100053 460 China 462 Email: chendanyang@chinamobile.com