idnits 2.17.1 draft-li-ippm-ref-delay-measurement-02.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 (10 February 2022) is 805 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: Standards Track H. Yang 5 Expires: 14 August 2022 D. Chen 6 China Mobile 7 Y. Wang 8 Huawei 9 10 February 2022 11 One-way Delay Measurement Based on Reference Delay 12 draft-li-ippm-ref-delay-measurement-02 14 Abstract 16 The end-to-end network one-way delay is an important performance 17 metric in the 5G network. For realizing the accurate one-way delay 18 measurement, existing methods requires the end-to-end deployment of 19 accurate clock synchronization mechanism, such as PTP or GPS, which 20 results in relatively high deployment cost. Another method can 21 derive the one-way delay from the round-trip delay. In this case, 22 since the delay of the downlink and uplink may be asymmetric, the 23 measurement accuracy is relatively low. Hence, this document 24 introduces a method to measure the end-to-end network one-way delay 25 based on a reference delay guaranteed by deterministic networking 26 without clock synchronization.The advantage of this solution is that 27 it has high measurement accuracy and can test any flow type. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 14 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 3. The method of One-way Delay Measurement Based on Reference 67 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. One-way Delay Measurement Method . . . . . . . . . . . . 5 69 3.2. Packet and Measurement Header Format . . . . . . . . . . 7 70 4. Acquisition of Reference Delay . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 With the gradual promotion of new-generation network technologies 79 (such as 5G networks) and their application in various industries, 80 SLA guarantees for network quality become more and more important. 81 For example, different 5G services have different requirements for 82 network performance indicators such as delay, jitter, packet loss, 83 and bandwidth. Among them, the 5G network delay is defined as end- 84 to-end one-way delay of the network. Real-time and accurate 85 measurement of the end-to-end one-way delay is very important for the 86 SLA guarantee of network services, and has become an urgent and 87 important requirement. 89 As shown in figure 1, 5G network HD video surveillance service is a 90 common scenario having requirement of end-to-end one-way delay 91 measurement. In this case, one end of the network is a high- 92 definition surveillance camera in the wireless access side, and the 93 other end of the network is a video server. The end-to-end one-way 94 delay from the surveillance camera to the video server is the sum of 95 T1, T2, T3 and T4, which is composed of delay in wireless access 96 network, optical transmission network, 5G core network, and IP data 97 network. 99 +--------+ +-------+ +-------+ +-------+ 100 +------+ |Wireless| |Optical| |5G Core| | IP | +------+ 101 |Camera+<->+ Access +<->+ Trans +<->+Network+<->+ Data +<->+Server| 102 +------+ |Network | |Network| | | |Network| +------+ 103 +--------+ +-------+ +-------+ +-------+ 105 |<---- T1 ---->|<--- T2 -->|<--- T3 -->|<--- T4 ---->| 107 Figure 1: Figure 1:A Scenario for End-to-end One-way Delay 109 The existing one-way delay measurement solutions are divided into two 110 types. One type of mechanism to calculate one-way delay is based on 111 the measurement of round-trip delay. However, for example, because 112 upstream traffic and downstream traffic do not share the same path in 113 5G network, the accuracy of the end-to-end one-way delay calculated 114 from the round-trip delay is low. Another type of mechanism is in- 115 band OAM with accurate network time synchronization mechanism , such 116 as NTP[RFC5905] or PTP[IEEE.1588.2008]. 118 The one-way delay measurement solution based on precise network time 119 synchronization requires the deployment of an end-to-end time 120 synchronization mechanism. The current time synchronization accuracy 121 based on the NTP protocol can only reach millisecond level, which 122 cannot fully meet the measurement accuracy requirements. The time 123 synchronization accuracy based on the GPS module or the PTP protocol 124 can meet the requirements. However, because many data centers are 125 actually located underground or in rooms without GPS signals, so GPS 126 clock information cannot be continuously obtained for time 127 synchronization. For time synchronization solutions based on the PTP 128 protocol, each device in the wireless access network, 5G transport 129 network, and 5G core network must support the PTP protocol, which is 130 unrealistic at the moment. So the one-way delay measurement solution 131 based on precise end-to-end time synchronization is expensive and 132 difficult to be deployed. 134 This document introduces a one-way delay measurement mechanism for 135 Deterministic Networking (DetNet) [RFC8655]. The one-way delay 136 measurement is based on a stable one-way delay of a reference DetNet 137 packet, named as reference delay, which is known in advance and has 138 extremely low jitter. We can use the reference delay provided by the 139 reference DetNet packet to derive the one-way delay of other common 140 service packets. 142 2. Conventions Used in This Document 144 2.1. Terminology 146 NTP Network Time Protocol 148 PTP Precision Time Protocol 150 SLA Service Level Agreement 152 2.2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14[RFC2119][RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. The method of One-way Delay Measurement Based on Reference Delay 162 The end-to-end one-way delay of a reference packet with a stable 163 delay in the network can be used as a reference delay, denoted as 164 Dref, which is known in advance and has extremely low jitter. This 165 section will describe in detail the end-to-end one-way delay 166 measurement method based on reference delay of the reference packet. 167 Assume that the end-to-end one-way delay from the sender to the 168 receiver is measured, as shown in figure 2. The intermediate network 169 devices other than the sender and receiver are hidden in the figure. 171 +------------+ +------------+ 172 | | Clock Offset | | 173 | Sender | +---------------> | Receiver | 174 | | | | 175 +------------+ +------------+ 177 Reference +-----+ Dref +-----+ 178 Packet: | Ts1 | +-------------------> | Tr1 | 179 +-----+ +-----+ 181 Target +-----+ Dtarget +-----+ 182 Packet: | Ts2 | +-------------------> | Tr2 | 183 +-----+ +-----+ 185 Figure 2: Figure 2:Topology of One-way Delay Measurement 187 3.1. One-way Delay Measurement Method 189 The measurement steps are shown in figure 3, which describe the 190 measurement steps at the sender side and receiver side respectively. 191 For the sender side, a reference packet is sent. In the first step, 192 the sender gets ready to send a reference packet; in the second step, 193 the sender marks an egress timestamp Ts1 for the reference packet; in 194 the third step, the sender encapsulates the egress timestamp of the 195 reference packet in the measurement header of the reference packet; 196 in the fourth step, the sender sends the reference packet. For the 197 target packet, the sender side procedures are the same,we omit it for 198 simplicity. The sending time of the target packet is according to 199 the traffic model of real applications. On the other hand, the 200 sender can send the reference packet according to a fixed frequency 201 or adjust the sending frequency according to the link usage rate, so 202 that the target packet can always find a nearby reference packet to 203 make sure that the sending time interval between the reference packet 204 and the target packet is small. 206 For the reference packet, the processing steps at the receiver are 207 shown in figure 3. In the first step, the reference packet arrives 208 at the receiver, and the receiver receives the reference packet; in 209 the second step, the receiver timestamps the reference packet at the 210 entrance, which is denoted as Tr1; in the third step, the receiver 211 decapsulates the measurement header of the reference packet to obtain 212 the sender side timestamp Ts1; in the fourth step, the receiver 213 records the timestamp information of Ts1 and Tr1; in the fifth step, 214 the receiver uses the source/destination pair obtained by 215 decapsulation in the third step as the search key, queries the 216 reference delay table and records the reference delay search result, 217 denoted as Dref. 219 For the target packet, the processing steps at the receiver are also 220 shown in figure 3. In the first step, the target packet arrives at 221 the receiver, and the receiver receives the target packet; in the 222 second step, the receiver timestamps the target packet at the 223 entrance, which is denoted as Tr2; in the third step, the receiver 224 decapsulates the measurement header of the target packet to obtain 225 the sender side timestamp Ts2; in the fourth step, the receiver 226 records the timestamp information of Ts2 and Tr2; in the fifth step, 227 the receiver calculates the target one-way delay, which we want to 228 measure, according to the recorded timestamp information Ts1, Ts2, 229 Tr1, Tr2 and reference delay information Dref. The target one-way 230 delay of the target packet is recorded as Dtarget. 232 Sender Side Procedures for both Reference and Target Packet: 234 +-------+ +------------+ +-------------+ +-------+ 235 |Sender | |Sender Side | |Sender Side | |Sending| 236 |Ready +-->+Timestamping+-->+Encapsulation+-->+ Packet| 237 | | | | | | | | 238 +-------+ +------------+ +-------------+ +-------+ 240 Receiver Side Procedures for Reference Packet: 242 +---------+ +-------------+ +-------------+ +---------+ +---------+ 243 |Reference| |Receiver Side| |Receiver Side| |Timestamp| |Query for| 244 |Packet +->+Timestamping +->+Decapsulation+->+Recorded +->+Reference| 245 |Arrival | | | | | | | | Delay | 246 +---------+ +-------------+ +-------------+ +---------+ +---------+ 248 Receiver Side Procedures for Target Packet: 250 +-------+ +-------------+ +-------------+ +---------+ +-----------+ 251 | Target| |Receiver Side| |Receiver Side| |Timestamp| | One-way | 252 | Packet+->+Timestamping +->+Decapsulation+->+Recorded +->+ Delay | 253 |Arrival| | | | | | | |Calculation| 254 +-------+ +-------------+ +-------------+ +---------+ +-----------+ 256 Figure 3: Figure 3: Measurement steps for Sender and Receiver 257 Respectively 259 Now we describe the fifth step of the receiver procedures for the 260 target packet in figure 3, that is, calculating the one-way delay 261 Dtarget of the target packet based on the recorded timestamp 262 information Ts1, Ts2, Tr1, Tr2 and the reference delay information 263 Dref. The calculation method is the core of this solution. For the 264 reference packet, leveraging the receiver timestamp minus the sender 265 timestamp, we can get Equation 1. 267 Equation 1: Tr1 - Ts1 = Dref + Offset1 269 where Offset1 is the time offset between the sender and the receiver 270 when the reference packet transmission occurs. Similarly, for the 271 target packet, we can get Equation 2 using the same method. 273 Equation 2: Tr2 - Ts2 = Dtarget + Offset2 275 where Offset2 is the time offset between the sender and the receiver 276 when the target packet transmission occurs. Assuming that the 277 sending time interval between the reference packet and the target 278 packet is very small, we can get that Offset1 = Offset2. By 279 (Equation 2 - Equation 1), we can get Equation 3. 281 Equation 3: Dtarget = (Tr2 + Ts1) - (Tr1 + Ts2) + Dref 283 So the one-way delay of the target packet can be calculated by 284 Equation 3. 286 3.2. Packet and Measurement Header Format 288 The sender encapsulates the timestamp information and sender-receiver 289 pair information in the measurement header of the sent packet, as 290 shown in figure 4. The position of measurement header is in the 291 option field of the TCP protocol header. The delay measurement 292 option format is defined in figure 5. The Length value is 8 octets, 293 which is in accordance with TCP option. The sender ID is one octet, 294 and the receiver ID is also one octet. The sender side timestamp is 295 4 octets, which can store accurate timestamp information. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 | Ethernet header (14 octets) | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 | IP header (20 octets) | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | TCP header (20 octets) | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | TCP Delay Measurement Option (8 octets) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Data | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 4: Figure 4: Format of Reference or Target Packet 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Kind=TBA | Length | Sender ID | Receiver ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Sender Side Timestamp (4 octets) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 5: Figure 5: TCP Delay Measurement Option Format 329 4. Acquisition of Reference Delay 331 The end-to-end one-way delay includes three parts, namely the 332 transmission delay, the internal processing delay of the network 333 devices, and the internal queueing delay of the network devices. 334 Among them, fixed parts of the delay include transmission delay and 335 internal processing delay. The transmission delay is related to 336 transmission distance and transmission media. For example, in 337 optical fiber, it is about 5ns per meter. With transmission path and 338 media determined, it is basically a fixed value. The internal 339 processing delay of a network device includes processing delay of the 340 device's internal pipeline or processor and serial-to-parallel 341 conversion delay of the interface, which is related to in/out port 342 rate of the device, message length and forwarding behavior. The 343 magnitude of the internal processing delay is at microsecond level, 344 and it is basically a fixed value related to the chip design 345 specifications of a particular network device. Variable part of the 346 delay is the internal queueing delay. The queueing delay of the 347 device internal buffer is related to the queue depth, queue 348 scheduling algorithm, message priority and message length. For each 349 device along the end-to-end path, the queueing delay can reach 350 microsecond or even millisecond level, depending on values of the 351 above parameters and network congestion state. 353 With the continuous development of networking technologies and 354 application requirements, a series of new network technologies have 355 emerged which can guarantee bounded end-to-end delay and ultra small 356 jitter. For example, deterministic network[RFC8655], by leveraging 357 novel scheduling algorithms and packet priority settings, can 358 stabilize queuing delay of network device on the end-to-end path. As 359 a result, the end-to-end one-way delay is extremely low and bounded. 360 So packets transmitted by a deterministic network with delay 361 guarantee can be used as reference packets, and their end-to-end one- 362 way delay can be used as reference delays. The acquisition method of 363 reference delay is not limited to the above method based on 364 deterministic network technology. 366 5. Security Considerations 368 TBD. 370 6. IANA Considerations 372 This document requests IANA to assign a Kind Number in TCP Option to 373 indicate TCP Delay Measurement option. 375 7. Normative References 377 [IEEE.1588.2008] 378 IEEE, "IEEE Standard for a Precision Clock Synchronization 379 Protocol for Networked Measurement and Control Systems", 380 July 2008. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 388 "Network Time Protocol Version 4: Protocol and Algorithms 389 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 390 . 392 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 393 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 394 May 2017, . 396 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 397 "Deterministic Networking Architecture", RFC 8655, 398 DOI 10.17487/RFC8655, October 2019, 399 . 401 Authors' Addresses 403 Yang Li 404 China Mobile 405 Beijing 406 100053 407 China 409 Email: liyangzn@chinamobile.com 411 Tao Sun 412 China Mobile 413 Beijing 414 100053 415 China 417 Email: suntao@chinamobile.com 418 Hongwei Yang 419 China Mobile 420 Beijing 421 100053 422 China 424 Email: yanghongwei@chinamobile.com 426 Danyang Chen 427 China Mobile 428 Beijing 429 100053 430 China 432 Email: chendanyang@chinamobile.com 434 Yali Wang 435 Huawei 436 156 Beiqing Rd., Haidian District 437 Beijing 438 China 440 Email: wangyali11@huawei.com