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