idnits 2.17.1 draft-yang-ippm-pnmp-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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As is regularized in IANA, the source port or destination port 319 and 320 in UDP/TCP header are defined to represent PTP event message and PTP general message respectively, the source port and destination port in PNMP header MUST not cover 319 or 320. -- The document date (February 22, 2021) is 1157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5905' is defined on line 374, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yang 3 Internet-Draft K. Yao 4 Intended status: Informational T. Sun 5 Expires: August 26, 2021 C. Zhou 6 China Mobile 7 W. Cheng 8 J. Wang 9 Centec networks 10 February 22, 2021 12 Precise Network Measurement Protocol 13 draft-yang-ippm-pnmp-00 15 Abstract 17 PNMP, precise network measurement protocol, is used for out-of-band 18 network measurement. As 5G is continuously evolving, there become 19 many more time sensitive services which require high precision of 20 measurements. In addition, in order to better simulate the 21 transmission of packets of monitored services, the length and 22 priorities of the measurement packets SHOULD be customized, 23 especially for some network that is inclined to get congested. PNMP 24 can not only support PTP, precise time protocol, but also allow some 25 customization on packet payload. It only introduces a little 26 overhead by adding an extendable header over IP header. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 3. PNMP Operations . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. IP Header Update . . . . . . . . . . . . . . . . . . . . 4 68 3.2. PNMP Header Format . . . . . . . . . . . . . . . . . . . 5 69 3.3. Customization of Length and Priority . . . . . . . . . . 6 70 3.3.1. Length . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3.2. Priority . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Measurement Procedures . . . . . . . . . . . . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The precision of some conventional ways used to measure the one-way 81 or round-trip delay and jitter, including ICMP (ping command) and 82 Iperf, a measurement tool, is highly dependent on 83 NTP[RFC5905]precision which is between millisecond and second. As 5G 84 has arisen and it is still continuously evolving, many industrial 85 scenarios, such as internet of vehicles, and other time sensitive 86 services have new requirements for time precision which is in 87 microsecond and even in nanosecond. With the growing support of 88 Precision Time Protocol (PTP) [IEEE.1588.2008], in many industrial 89 scenarios, such as industrial control network and video transmission 90 network, devices can be synchronized in very high precision that is 91 in sub-microsecond. 93 Although TWAMP has already supported PTP timestamp, as is stated 94 in[RFC8186] , the current protocol doesn't allow customizing the 95 length and priorities of packets. Since packets of actual services 96 have different length and priorities, which MAY lead to different 97 time delay, the measurement packets need to be designed to meet such 98 requirements. Moreover, when there are many different paths between 99 source and destination, ECMP, equal cost multi-path algorithm is used 100 to balance the load in different paths. In order to make measurement 101 packets transmitted in the same path as the packet of monitored 102 services, they MUST contain the same 5-tuple elements when computing 103 the hash algorithm. The document defines PNMP by introducing an 104 extendable header over IP header, which could make ECMP algorithm 105 treats the measurement packets and the monitored packets as the same. 107 2. Conventions Used in This Document 109 2.1. Terminology 111 NTP Network Time Protocol 113 PTP Precision Time Protocol 115 TWAMP Two-Way Active Measurement Protocol 117 DSCP Differentiated Services Code Point 119 ICMP Internet Control Message Protocol 121 ECMP Equal Cost Multi Path 123 PNMP Precise Network Measurement Protocol 125 2.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14[RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. PNMP Operations 135 PNMP needs to modify the IP header and adds an extendable layer 136 between layer 3 and layer 4. The added layer records the information 137 copied from the monitored packet in order to compute the hash 138 algorithm, and additionally, it serves as a sign to tell switches or 139 routers at each hop that the packet is used for network measurement. 140 The major purpose of the definition of PNMP is to ensure that the 141 measurement packet can be treated as much likely the same as the 142 monitored packet. In this way, the out-of-band measurement can 143 approximate the in-band network measurement to a great extent. 145 3.1. IP Header Update 147 Before introducing the extendable PNMP header, some updates in the IP 148 header needs to be declared. Such updates have been shown in the 149 figures below in both IPv4 and IPv6 header format. The protocol 150 fields in both IPv4 and IPv6 headers are updated to represent that 151 the extendable PNMP header is added over layer 3. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |Version| IHL | DS | Total Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Identification |Flags| Fragment Offset | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Time to Live | Protocol=PNMP | Header Checksum | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Source IPv4 Address | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Destination IPv4 Address | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: IPV4 Header Format 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |Version| Traffic Class | Flow Label | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Payload Length |Next Hdr = PNMP| Hop Limit | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 + + 178 | | 179 + Source IPv6 Address + 180 | | 181 + + 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 + + 186 | | 187 + Destination IPv6 Address + 188 | | 189 + + 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2: IPV6 Header Format 195 3.2. PNMP Header Format 197 PNMP header format is shown in figure below. The extendable header 198 is a 64-bit header which contains several fields. 200 *Version. This field represents the version number of the protocol. 201 Since the protocol is first defined in this document, the version 202 number is 0 here. 204 *Next Header. Since PNMP header is inserted between layer 3 and 205 layer 4, the next header field needs to record the followed layer 4 206 header, UDP or TCP. 208 *Source Port. This source port MUST be clarified, because it is not 209 the source port copied from layer 4 of this packet, but from the 210 monitored packet. When using ECMP algorithm to compute the hash 211 value of the chosen 5-tuple elements that contains the source and 212 destination IP address, source and destination port, and the layer 4 213 protocol, UDP or TCP, PNMP MUST ensure that the measurement packet 214 has the same hash value as the monitored packet. According to this 215 principle, the source port field in PNMP header MUST be the same as 216 the source port in layer 4 header of the monitored packet. 218 *Destination Port. Similarly, this field is the same as the 219 destination port of the monitored packet. 221 *Pre-allocated field. This field is used for some specific purposes. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Version | Next Hdr | Source Port | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Destination Port | Pre-allocated | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 3: PNMP Header Format 233 3.3. Customization of Length and Priority 235 Another feature of PNMP is that the length and priorities of packets 236 can be set manually in order to get close to the messages of 237 monitored services, and this is crucial for some time sensitive 238 services. Customization of message length and priority can be done 239 in adjustments below. 241 3.3.1. Length 243 The complete PTP event or general message is composed by three major 244 parts, header, body, and suffix, as described in PTPv2 245 [IEEE.1588.2008] . The specification allows the suffix to be zero 246 length if the message does not carry any information other than its 247 timestamp. To simulate the transmission of messages of monitored 248 services, the suffix can be filled with extra bytes, and in this way, 249 the total length of this PTP messages can be the same as the actual 250 ones. Thereby, in the figure below, the suffix is labeled as 251 'customized'. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ~ ~ 257 | header (34 octets) | 258 ~ ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 | Timestamp (10 octets) | 262 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ ~ 266 | suffix (customized) | 267 ~ ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: PTP Message Format 272 3.3.2. Priority 274 Priorities of packets are set in the DS field of IP header which is 275 defined in [RFC2474] . The format of IP header is shown in the figure 276 below where the DS field occupies the second octet. The first 6 bits 277 of the DS field is named as DSCP, differentiated services code point, 278 which are used to represent maximum 64 priorities. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |Version| IHL | DS | Total Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Identification |Flags| Fragment Offset | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Time to Live | Protocol=PNMP | Header Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Source Address | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Destination Address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 5: IP Header Format 296 The complete encapsulation of PTP messages by the UDP/TCP header, 297 PNMP header, IP header, and Mac header is shown in the figure below, 298 with their length and priorities customized. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ ~ 304 | Ethernet header (14 octets) | 305 ~ ~ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 ~ ~ 308 | IP header (20 octets) | 309 ~ ~ 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | PNMP header | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | UDP/TCP header | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 ~ ~ 318 | PTP Message in Payload (more than 44 octets) | 319 ~ ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | FCS | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 6: Format of PTP Message over UDP/TCP 326 4. Measurement Procedures 328 * First of all, the network to which both source and destination are 329 connected needs to be synchronized globally. 331 * Before measuring the time delay and jitter between source and 332 destination, measurement mode needs to be enabled and every switch or 333 router MUST support the ability to distinguish packets encapsulated 334 by PNMP header. 336 * At each hop, every monitored packet needs to know the next hop it 337 will go to, so as the measurement packet. Apart from updating the 338 source and destination address in IP header, the PNMP header should 339 be updated too. The source and destination port of monitored packets 340 MUST be recorded first and pasted on the source port and destination 341 port of PNMP header respectively. In this way, when there are 342 multiple paths between two consecutive hops, the measurement packets 343 can be transmitted together with the monitored packets. 345 5. Security Considerations 347 TBD. 349 6. IANA Considerations 351 As is regularized in IANA, the source port or destination port 319 352 and 320 in UDP/TCP header are defined to represent PTP event message 353 and PTP general message respectively, the source port and destination 354 port in PNMP header MUST not cover 319 or 320. 356 7. Normative References 358 [IEEE.1588.2008] 359 IEEE, "IEEE Standard for a Precision Clock Synchronization 360 Protocol for Networked Measurement and Control Systems", 361 July 2008. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 369 "Definition of the Differentiated Services Field (DS 370 Field) in the IPv4 and IPv6 Headers", RFC 2474, 371 DOI 10.17487/RFC2474, December 1998, 372 . 374 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 375 "Network Time Protocol Version 4: Protocol and Algorithms 376 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 384 Timestamp Format in a Two-Way Active Measurement Protocol 385 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 386 . 388 Authors' Addresses 389 Hongwei Yang 390 China Mobile 391 Beijing 100053 392 China 394 Email: yanghongwei@chinamobile.com 396 Kehan Yao 397 China Mobile 398 Beijing 100053 399 China 401 Email: yaokehan@chinamobile.com 403 Tao Sun 404 China Mobile 405 Beijing 100053 406 China 408 Email: suntao@chinamobile.com 410 Cheng Zhou 411 China Mobile 412 Beijing 100053 413 China 415 Email: zhouchengyjy@chinamobile.com 417 Wei Cheng 418 Centec networks 419 Suzhou 215000 420 China 422 Email: chengw@centecnetworks.com 424 Junjie Wang 425 Centec networks 426 Suzhou 215000 427 China 429 Email: wangjj@centecnetworks.com