idnits 2.17.1 draft-yang-ippm-ptp-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 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 (July 12, 2020) is 1385 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5905' is defined on line 336, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Measurement H. Yang 3 Internet-Draft T. Sun 4 Intended status: Informational K. Yao 5 Expires: January 13, 2021 China Mobile 6 July 12, 2020 8 Application Oriented High Precision Delay and Jitter Measurement 9 draft-yang-ippm-ptp-measurement-00 11 Abstract 13 As 5G has arisen and it is still evolving, there become many more 14 time sensitive services which require high precision of measurements. 15 In addition, in order to better simulate the transmission of packets 16 of actual services, the length and priorities of the measurement 17 packets SHOULD be customized, especially for some network that is 18 inclined to get congested. This document introduces a new way to 19 measure the time delay and jitter between two devices by making 20 adjustments based on PTP Sync message and Delay_Req message, which 21 could, to a great extent, get close to the messages of actual 22 services as well as achieve high precison of measured metrics, so as 23 to meet all requirements mentioned above. 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 January 13, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . . . . . . . . 3 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 3. Adjustments on PTP Sync Message and Delay_Req Message . . . . 3 64 3.1. Adjustments on PTP Header . . . . . . . . . . . . . . . . 3 65 3.2. Customization of Length and Priority . . . . . . . . . . 4 66 3.2.1. Length . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2.2. Priority . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Measurement Procedures . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The precision of some conventional ways used to measure the one-way 77 or round-trip delay and jitter, including ICMP (ping command) and 78 Iperf, a measurement tool, is highly dependent on 79 NTP[RFC5905]precision which is between millisecond and second. As 5G 80 has arisen and it is still continuously evolving, many industrial 81 scenarios, such as internet of vehicles, and other time sensitive 82 sevices have new requirements for time precision which is in 83 microsecond and even in nanosecond. With the growing support of 84 Precision Time Protocol (PTP) [IEEE.1588.2008], in many industrial 85 scenarios, such as industrial control network and video transmission 86 network, devices can be synchronized in very high precision that is 87 in sub-microsecond. 89 Although TWAMP has already supported PTP timestamp, as is stated 90 in[RFC8186] , the current protocol doesn't allow customizing the 91 length and priorities of packets. Since packets of actual services 92 have different length and priorities, which MAY lead to different 93 time delay, the measurement packets need to be designed to meet such 94 requirements. This document introduces a new way to measure the time 95 delay and jitter between two devices by making adjustments based on 96 PTP Sync message and Delay_Req message, which could, to a great 97 extent, get close to the messages of actual services as well as 98 achieve high precison of measured metrics, so as to meet all 99 requirements mentioned above. 101 2. Conventions Used in This Document 103 2.1. Terminology 105 NTP Network Time Protocol 107 PTP Precision Time Protocol 109 TWAMP Two-Way Active Measurement Protocol 111 DSCP Differentiated Services Code Point 113 ICMP Internet Control Message Protocol 115 2.2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14[RFC2119][RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Adjustments on PTP Sync Message and Delay_Req Message 125 Since PTP Sync message and Delay_Req message are used to synchronize 126 two devices, namely Source and Destination. In order to use these 127 messages to measure time delay and jitter, this document introduces a 128 new way by making some adjustments on original messages. Utilizing 129 the modified PTP Sync message and Delay_Req message, people can 130 measure the forward and backward time delay and jitter between two 131 nodes respectively within the same synchonized network. 133 3.1. Adjustments on PTP Header 135 The adjustments can be done through setting the field, FlagField, in 136 the PTP header. The format of the PTP header is shown in figure 1. 137 There are two consecutive flag bits in the field, PTP profile 138 Specific 1 and PTP profile Specific 2, whose default values are 139 false. PTP profile Specific 1 takes up the sixth bit while PTP 140 profile Specific 2 takes up the seventh bit. Both of values inside 141 FlagField are changed to be true, as is shown in figure 2, indicating 142 the message is not used for synchronization, but for measurement. 144 * PTP profile Specific 1: False -> True 145 * PTP profile Specific 2: False -> True 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |MsgType|TranSpc|VerPTP | Resvd | MsgLength | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | DomainNumber | Reserved | FlagField | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | CorrectionField | 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Reserved | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | 160 | SourcePortIdentity (10 octets) | 161 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | SequenceID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ControlField |LogMsgInterval | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: PTP Header Format 169 0 1 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 172 | |T |T | | 173 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 175 Figure 2: Modified FlagField 177 3.2. Customization of Length and Priority 179 Another feature of the modified PTP Sync message or Delay_Req message 180 is that their length and priorities can be set manually in order to 181 get close to the messages of actual services, and this is crucial for 182 some time sensitive services. Customization of message length and 183 priority can be done in adjustments below. 185 3.2.1. Length 187 The complete PTP Sync message or Delay_Req message is composed by 188 three major parts, header, body, and suffix, as described in PTPv2 189 [IEEE.1588.2008] . The specification allows the suffix to be zero 190 length if the message does not carry any information other than its 191 timestamp. To simulate the transmission of messages of actual 192 services, the suffix can be filled with extra bytes, and in this way, 193 the total length of this PTP Sync message or Delay_Req message can be 194 the same as the actual one. Thereby, in the figure below, the suffix 195 is labeled as 'customized'. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 ~ ~ 201 | header (34 octets) | 202 ~ ~ 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 | TimeStamp (10 octets) | 206 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ~ ~ 210 | suffix (customized) | 211 ~ ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 3: PTP Sync or Delay_Req Message Format 216 3.2.2. Priority 218 Priorities of packets are set in the DS field of IP header which is 219 defined in [RFC2474] . The format of IP header is shown in the figure 220 below where the DS field occupies the second octet. The first 6 bits 221 of the DS field is named as DSCP, differentiated services codepoint, 222 which are used to represent maximum 64 priorities. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |Version| IHL | DS | Total Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Identification |Flags| Fragment Offset | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Time to Live | Protocol | Header Checksum | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Source Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Destination Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 4: IP Header Format 240 The complete encapsulation of modified PTP Sync message or Delay_Req 241 message by the UDP header, IP header, and Mac header is shown in the 242 figure below, with their length and prioritities customized. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 ~ ~ 248 | Ethernet header (14 octets) | 249 ~ ~ 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 ~ ~ 252 | IP header (20 octets) | 253 ~ ~ 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | UDP header | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ ~ 259 | PTP Message in Payload (more than 44 octets) | 260 ~ ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | FCS | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 5: Format of PTP Message over UDP 267 4. Measurement Procedures 269 * First of all, the network to which both source and destination are 270 connected needs to be synchronized globally. 272 * Before measuring the time delay and jitter between source and 273 destination, the measurement mode of devices needs to be enabled and 274 adjustments need to be done by following section 3. For the source 275 device, the destination address needs to be configured and the PTP 276 Sync message carrying the source timestamp MUST be converted into 277 measurement mode by modifying the FlagField inside the message 278 header. For the destination device, the address of receiver is 279 configured as the source address and the PTP Delay_Req message 280 carrying the destination timestamp MUST be turned into measurement 281 mode too by following the same way. 283 * To measure the time delay and jitter of the forward path, the 284 source device sends the modified PTP Sync message to the destination 285 device. When packets are transmitted inside the middle network from 286 source to destination, the nodes between them will check the IP 287 address of destination. If it's not the same as the local address, 288 then pass it to the next node.When packets are receieved by 289 destination device, the measurement mode of the PTP Sync message can 290 be decided by recognizing the FlagField inside its message header . 291 Then the source timestamp and the arrival timestamp generated by 292 destination device will be uploaded to CPUs in upper layers to count 293 the difference of these two timestamps, which is just the time delay 294 of the forward path. To measusre the forward jitter, the source 295 needs to send the modified PTP Sync message to the destination for 296 one more time, and the jitter is the difference of two consecutive 297 time delays. 299 * To measure the time delay and jitter of the backward path, the 300 destination device sends the modified PTP Delay_Req message to the 301 source device. The message carries the local timestamp of the 302 destination and it can be recognized by the source device with its 303 adjusted message header. Upon receipt of the modified PTP Delay_Req 304 message, the source device will generate a local timestamp and upload 305 it together with the timestamp inside the message to CPUs in upper 306 layers. Then the time delay will be achieved by calculating the 307 difference of two timestamps and the backward jitter is the 308 difference of two consecutive backward time delays. 310 5. Security Considerations 312 TBD. 314 6. IANA Considerations 316 TBD. 318 7. Normative References 320 [IEEE.1588.2008] 321 IEEE, "IEEE Standard for a Precision Clock Synchronization 322 Protocol for Networked Measurement and Control Systems", 323 July 2008. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 331 "Definition of the Differentiated Services Field (DS 332 Field) in the IPv4 and IPv6 Headers", RFC 2474, 333 DOI 10.17487/RFC2474, December 1998, 334 . 336 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 337 "Network Time Protocol Version 4: Protocol and Algorithms 338 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 346 Timestamp Format in a Two-Way Active Measurement Protocol 347 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 348 . 350 Authors' Addresses 352 Hongwei Yang 353 China Mobile 354 Beijing 100053 355 China 357 Email: yanghongwei@chinamobile.com 359 Tao Sun 360 China Mobile 361 Beijing 100053 362 China 364 Email: suntao@chinamobile.com 366 Kehan Yao 367 China Mobile 368 Beijing 100053 369 China 371 Email: yaokehan@chinamobile.com