idnits 2.17.1 draft-ietf-ippm-stamp-option-tlv-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 date (October 31, 2019) is 1636 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) == Outdated reference: A later version (-10) exists of draft-ietf-ippm-stamp-09 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 G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: May 3, 2020 H. Nydell 6 Accedian Networks 7 R. Foote 8 Nokia 9 A. Masputra 10 Apple Inc. 11 E. Ruffini 12 OutSys 13 October 31, 2019 15 Simple Two-way Active Measurement Protocol Optional Extensions 16 draft-ietf-ippm-stamp-option-tlv-02 18 Abstract 20 This document describes optional extensions to Simple Two-way Active 21 Measurement Protocol (STAMP) which enable measurement performance 22 metrics in addition to ones supported by the STAMP base 23 specification. 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 May 3, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 64 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 4 65 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 8 68 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 9 69 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 10 70 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 11 71 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 13 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 14 74 5.2. Synchronization Source Sub-registry . . . . . . . . . . . 15 75 5.3. Timestamping Method Sub-registry . . . . . . . . . . . . 16 76 5.4. Access ID Sub-registry . . . . . . . . . . . . . . . . . 17 77 5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 17 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 Simple Two-way Active Measurement Protocol (STAMP) 89 [I-D.ietf-ippm-stamp] supports the use of optional extensions that 90 use Type-Length-Value (TLV) encoding. Such extensions are to enhance 91 the STAMP base functions, such as measurement of one-way and round- 92 trip delay, latency, packet loss, as well as ability to detect packet 93 duplication and out-of-order delivery of the test packets. This 94 specification provides definitions of optional STAMP extensions, 95 their formats, and theory of operation. 97 2. Conventions used in this document 99 2.1. Terminology 101 STAMP - Simple Two-way Active Measurement Protocol 103 DSCP - Differentiated Services Code Point 105 ECN - Explicit Congestion Notification 107 NTP - Network Time Protocol 109 PTP - Precision Time Protocol 111 HMAC Hashed Message Authentication Code 113 TLV Type-Length-Value 115 BITS Building Integrated Timing Supply 117 SSU Synchronization Supply Unit 119 GPS Global Positioning System 121 GLONASS Global Orbiting Navigation Satellite System 123 LORAN-C Long Range Navigation System Version C 125 MBZ Must Be Zeroed 127 CoS Class of Service 129 PMF Performance Measurement Function 131 2.2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. Theory of Operation 141 STAMP Session-Sender transmits test packets to STAMP Session- 142 Reflector. STAMP Session-Reflector receives Session-Sender's packet 143 and acts according to the configuration and optional control 144 information communicated in the Session-Sender's test packet. STAMP 145 defines two different test packet formats, one for packets 146 transmitted by the STAMP-Session-Sender and one for packets 147 transmitted by the STAMP-Session-Reflector. STAMP supports two 148 modes: unauthenticated and authenticated. Unauthenticated STAMP test 149 packets are compatible on the wire with unauthenticated TWAMP-Test 150 [RFC5357] packet formats. 152 By default, STAMP uses symmetrical packets, i.e., the size of the 153 packet transmitted by Session-Reflector equals the size of the packet 154 received by the Session-Reflector. 156 4. TLV Extensions to STAMP 158 Figure 1 displays the format of STAMP Session-Sender test packet in 159 unauthenticated mode that includes a TLV. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Sequence Number | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Timestamp | 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Error Estimate | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 171 | | 172 | | 173 | MBZ (30 octets) | 174 | | 175 | | 176 | | 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 ~ Value ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: STAMP Session-Sender test packet format with TLV in 185 unauthenticated mode 187 The MBZ (Must Be Zeroed) field of a test packet transmitted by a 188 STAMP Session-Sender MUST be 30 octets long. A STAMP Session-Sender 189 test packet MUST NOT use the Reflect Octets capability defined in 190 [RFC6038]. 192 TLVs (Type-Length-Value tuples) have the two octets long Type field, 193 two octets long Length field that is the length of the Value field in 194 octets. Type values, see Section 5.1, less than 32768 identify 195 mandatory TLVs that MUST be supported by an implementation. Type 196 values greater than or equal to 32768 identify optional TLVs that 197 SHOULD be ignored if the implementation does not understand or 198 support them. If a Type value for TLV or sub-TLV is in the range for 199 Vendor Private Use, the Length MUST be at least 4, and the first four 200 octets MUST be that vendor's the Structure of Management Information 201 (SMI) Private Enterprise Number, in network octet order. The rest of 202 the Value field is private to the vendor. Following sections 203 describe the use of TLVs for STAMP that extend STAMP capability 204 beyond its base specification. 206 Figure 2 displays the format of STAMP Session-Reflector test packet 207 in unauthenticated mode that includes a TLV. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Sequence Number | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Timestamp | 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Error Estimate | MBZ | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Receive Timestamp | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Session-Sender Sequence Number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Session-Sender Timestamp | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Session-Sender Error Estimate | MBZ | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |Ses-Sender TTL | MBZ2 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Value ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 2: STAMP Session-Reflector test packet format with TLV in 237 unauthenticated mode 239 The MBZ2 field of a test packet transmitted by a STAMP Session- 240 Reflector MUST be 3 octets long. 242 A STAMP node, whether Session-Sender or Session-Reflector, receiving 243 a test packet MUST determine whether the packet is a base STAMP 244 packet or includes one or more TLVs. The node MUST compare the value 245 in the Length field of the UDP header and the length of the base 246 STAMP test packet in the mode, unauthenticated or authenticated based 247 on the configuration of the particular STAMP test session. If the 248 difference between the two values is larger than the length of UDP 249 header, then the test packet includes one or more STAMP TLVs that 250 immediately follow the base STAMP test packet. 252 4.1. Extra Padding TLV 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Extra Padding Type | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Extra Padding ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 3: Extra Padding TLV 266 where fields are defined as the following: 268 o Extra Padding Type - TBA1 allocated by IANA Section 5.1 270 o Length - two octets long field equals length on the Extra Padding 271 field in octets. 273 o Extra Padding - a pseudo-random sequence of numbers. The field 274 MAY be filled with all zeroes. 276 The Extra Padding TLV is similar to the Packet Padding field in 277 TWAMP-Test packet [RFC5357]. The in STAMP the Packet Padding field 278 is used to ensure symmetrical size between Session-Sender and 279 Session-Reflector test packets. Extra Padding TLV MUST be used to 280 create STAMP test packets of larger size. 282 4.2. Location TLV 284 STAMP session-sender MAY include the Location TLV to request 285 information from the session-reflector. The session-sender SHOULD 286 NOT fill any information fields except for Type and Length. The 287 session-reflector MUST validate the Length value against the address 288 family of the transport encapsulating the STAMP test packet. If the 289 value of the Length field is invalid, the session-reflector MUST zero 290 all fields and MUST NOT return any information to the session-sender. 291 The session-reflector MUST ignore all other fields of the received 292 Location TLV. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Location Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Source MAC | 300 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | Reserved A | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 ~ Destination IP Address ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 ~ Source IP Address ~ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Dest.port | Src.Port | Reserved B | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 4: Session-Reflector Location TLV 312 where fields are defined as the following: 314 o Location Type - TBA2 allocated by IANA Section 5.1 316 o Length - two octets long field equals length on the Value field in 317 octets. Length field value MUST be 20 octets for the IPv4 address 318 family. For the IPv6 address family value of the Length field 319 MUST be 44 octets. All other values are invalid. 321 o Source MAC - 6 octets 48 bits long field. The session-reflector 322 MUST copy Source MAC of received STAMP packet into this field. 324 o Reserved A - two octets long field. MUST be zeroed on 325 transmission and ignored on reception. 327 o Destination IP Address - IPv4 or IPv6 destination address of the 328 received by the session-reflector STAMP packet. 330 o Source IP Address - IPv4 or IPv6 source address of the received by 331 the session-reflector STAMP packet. 333 o Dest.port - one octet long UDP destination port number of the 334 received STAMP packet. 336 o Src.port - one octet long UDP source port number of the received 337 STAMP packet. 339 o Reserved B - two octets long field. MUST be zeroed on 340 transmission and ignored on reception. 342 The Location TLV MAY be used to determine the last-hop addressing for 343 STAMP packets including source and destination IP addresses as well 344 as the MAC address of the last-hop router. Last-hop MAC address MAY 345 be monitored by the Session-Sender whether there has been a path 346 switch on the last hop, closest to the Session-Reflector. The IP 347 addresses and UDP port will indicate if there is a NAT router on the 348 path, and allows the Session-Sender to identify the IP address of the 349 Session-Reflector behind the NAT, detect changes in the NAT mapping 350 that could cause sending the STAMP packets to the wrong Session- 351 Reflector. 353 4.3. Timestamp Information TLV 355 STAMP session-sender MAY include the Timestamp Information TLV to 356 request information from the session-reflector. The session-sender 357 SHOULD NOT fill any information fields except for Type and Length. 358 The session-reflector MUST validate the Length value of the STAMP 359 test packet. If the value of the Length field is invalid, the 360 session-reflector MUST zero all fields and MUST NOT return any 361 information to the session-sender. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Timestamp Information Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 5: Timestamp Information TLV 373 where fields are defined as the following: 375 o Timestamp Information Type - TBA3 allocated by IANA Section 5.1 377 o Length - two octets long field, equals four octets. 379 o Sync Src In - one octet long field that characterizes the source 380 of clock synchronization at the ingress of Session-Reflector. 381 There are several of methods to synchronize the clock, e.g., 382 Network Time Protocol (NTP) [RFC5905], Precision Time Protocol 383 (PTP) [IEEE.1588.2008], Synchronization Supply Unit (SSU) or 384 Building Integrated Timing Supply (BITS), or Global Positioning 385 System (GPS), Global Orbiting Navigation Satellite System 386 (GLONASS) and Long Range Navigation System Version C (LORAN-C). 387 The value is one of the listed in Table 4. 389 o Timestamp In - one octet long field that characterizes the method 390 by which the ingress of Session-Reflector obtained the timestamp 391 T2. A timestamp may be obtained with hardware assist, via 392 software API from a local wall clock, or from a remote clock (the 393 latter referred to as "control plane"). The value is one of the 394 listed in Table 6. 396 o Sync Src Out - one octet long field that characterizes the source 397 of clock synchronization at the egress of Session-Reflector. The 398 value is one of the listed in Table 4. 400 o Timestamp Out - one octet long field that characterizes the method 401 by which the egress of Session-Reflector obtained the timestamp 402 T3. The value is one of the listed in Table 6. 404 4.4. Class of Service TLV 406 The STAMP session-sender MAY include Class of Service (CoS) TLV in 407 the STAMP test packet. If the CoS TLV is present in the STAMP test 408 packet and the value of the DSCP1 field is zero, then the STAMP 409 session-reflector MUST copy the values of Differentiated Services 410 Code Point (DSCP) ECN fields from the received STAMP test packet into 411 DSCP2 and ECN fields respectively of the CoS TLV of the reflected 412 STAMP test packet. If the value of the DSCP1 field is non-zero, then 413 the STAMP session-reflector MUST use DSCP1 value from the CoS TLV in 414 the received STAMP test packet as DSCP value of STAMP reflected test 415 packet and MUST copy DSCP and ECN values of the received STAMP test 416 packet into DSCP2 and ECN fields of Class of Service TLV in the STAMP 417 reflected a packet. The Session-Sender, upon receiving the reflected 418 packet, will save the DSCP and ECN values for analysis of the CoS in 419 the reverse direction. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Class of Service Type | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | DSCP1 | DSCP2 |ECN| Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 6: Class of Service TLV 431 where fields are defined as the following: 433 o Class of Service Type - TBA4 allocated by IANA Section 5.1 435 o Length - two octets long field, equals four octets. 437 o DSCP1 - The Differentiated Services Code Point (DSCP) intended by 438 the Session-Sender. To be used as the return DSCP from the 439 Session-Reflector. 441 o DSCP2 - The received value in the DSCP field at the Session- 442 Reflector in the forward direction. 444 o ECN - The received value in the ECN field at the Session-Reflector 445 in the forward direction. 447 o Reserved - 18 bits long field, must be zeroed in transmission and 448 ignored on receipt. 450 A STAMP Session-Sender that includes the CoS TLV sets the value of 451 the DSCP1 field and zeroes the value of the DSCP2 field. A STAMP 452 Session-Reflector that received the test packet with the CoS TLV MUST 453 include the CoS TLV in the reflected test packet. Also, the Session- 454 Reflector MUST copy the value of the DSCP field of the IP header of 455 the received STAMP test packet into the DSCP2 field in the reflected 456 test packet. And, at last, the Session-Reflector MUST set the value 457 of the DSCP field in the IP header of the reflected test packet equal 458 to the value of the DSCP1 field of the test packet it has received. 460 Re-mapping of CoS in some use cases, for example, in mobile backhaul 461 networks is used to provide multiple services, i.e., 2G, 3G, LTE, 462 over the same network. But if it is misconfigured, then it is often 463 difficult to diagnose the root cause of the problem that is viewed as 464 an excessive packet drop of higher level service while packet drop 465 for lower service packets is at a normal level. Using CoS TLV in 466 STAMP test helps to troubleshoot the existing problem and also verify 467 whether DiffServ policies are processing CoS as required by the 468 configuration. 470 4.5. Direct Measurement TLV 472 The Direct Measurement TLV enables collection of "in profile" IP 473 packets that had been transmitted and received by the Session-Sender 474 and Session-Reflector respectfully. The definition of "in-profile 475 packet" is outside the scope of this document. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Direct Measurement Type | Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Session-Sender Tx counter (S_TxC) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Session-Reflector Rx counter (R_RxC) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Session-Reflector Tx counter (R_TxC) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 7: Direct Measurement TLV 491 where fields are defined as the following: 493 o Direct Measurement Type - TBA5 allocated by IANA Section 5.1 495 o Length - two octets long field equals length on the Value field in 496 octets. Length field value MUST be 12 octets. 498 o Session-Sender Tx counter (S_TxC) is four octets long field. 500 o Session-Reflector Rx counter (R_RxC) is four octets long field. 501 MUST be zeroed by the Session-Sender and filled by the Session- 502 Reflector. 504 o Session-Reflector Tx counter (R_TxC) is four octets long field. 505 MUST be zeroed by the Session-Sender and filled by the Session- 506 Reflector. 508 4.6. Access Report TLV 510 A STAMP Session-Sender MAY include Access Report TLV (Figure 8) to 511 indicate changes to the access network status to the Session- 512 Reflector. The definition of an access network is outside the scope 513 of this document. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Access Report Type | Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Access ID | Return Code | Reserved | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 8: Access Report TLV 525 where fields are defined as follows: 527 o Access Report Type - TBA6 allocated by IANA Section 5.1. 529 o Length - two octets long field, equals four octets. 531 o Access ID - one octet long field that identifies the access 532 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 533 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 534 The value is one of Section 5.4. 536 o Return Code - one octet long field that identifies the report 537 signal, e.g., available, unavailable. The value is one of 538 Section 5.5. 540 o Reserved - two octets long field, must be zeroed on transmission 541 and ignored on receipt. 543 The STAMP Session-Sender that includes the Access Report TLV sets the 544 value of the Access ID field according to the type of access network 545 it reports on. Also, the Session-Sender sets the value of the Return 546 Code field to reflect the operational state of the access network. 547 The mechanism to determine the state of the access network is outside 548 the scope of this specification. A STAMP Session-Reflector that 549 received the test packet with the Access Report TLV MUST include the 550 Access Report TLV in the reflected test packet. The Session- 551 Reflector MUST set the value of the Access ID and Return Code fields 552 equal to the values of the corresponding fields from the test packet 553 it has received. 555 The Session-Sender MUST also arm a retransmission timer after sending 556 a test packet that includes the Access Report TLV. This timer MUST 557 be disarmed upon the reception of the reflected STAMP test packet 558 that includes Access Report TLV. In the event the timer expires 559 before such a packet is received, the Session-Sender MUST retransmit 560 the STAMP test packet that contains the Access Report TLV. This 561 retransmission SHOULD be repeated up to four times before the 562 procedure is aborted. Setting the value for the retransmission timer 563 is based on local policies, network environment. The default value 564 of the retransmission timer for Access Report TLV SHOULD be three 565 seconds. An implementation MUST provide control of the 566 retransmission timer value and the number of retransmissions. 568 The Access Report TLV is used by the Performance Measurement Function 569 (PMF) components of the Access Steering, Switching and Splitting 570 feature for 5G networks [TS23501]. The PMF component in the User 571 Equipment acts as the STAMP Session-Sender, and the PMF component in 572 the User Plane Function acts as the STAMP Session-Reflector. 574 4.7. Follow-up Telemetry TLV 576 A Session-Reflector might be able to put in the Timestamp field only 577 a "SW Local" (see Table 6) timestamp. But the hosting system might 578 provide the timestamp closer to the start of actual packet 579 transmission even though when it is not possible to deliver the 580 information to the Session-Sender in the packet itself. This 581 timestamp might nevertheless be important for the Session-Sender, as 582 it helps in to improve the accuracy of measuring network delay by 583 minimizing the impact of egress queuing delays on the measurement. 585 A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to 586 request information from the Session-Reflector. The Session-Sender 587 MUST set the Follow-up Telemetry Type and Length fields to their 588 appropriate values. Sequence Number and Timestamp fields MUST be 589 zeroed on transmission by the Session-Sender and ignored by the 590 Session-Reflector upon receipt of the STAMP test packet that includes 591 the Follow-up Telemetry TLV. The Session-Reflector MUST validate the 592 Length value of the STAMP test packet. If the value of the Length 593 field is invalid, the Session-Reflector MUST zero Sequence Number and 594 Timestamp fields. If the Session-Reflector is in stateless mode 595 (defined in Section 4.2 [I-D.ietf-ippm-stamp]), it MUST zero Sequence 596 Number and Timestamp fields. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Follow-up Telemetry Type | Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Sequence Number | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Timestamp | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Timestamp M | Reserved | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 9: Follow-up Telemetry TLV 613 where fields are defined as follows: 615 o Follow-up Telemetry Type - TBA7 allocated by IANA Section 5.1. 617 o Length - two octets long field, equals 12 octets. 619 o Sequence Number - four octets long field indicating the sequence 620 number of the last packet reflected in the same STAMP-test 621 session. Since the Session-Reflector runs in the stateful mode 622 (defined in Section 4.2 [I-D.ietf-ippm-stamp]), it is the Session- 623 Reflector's Sequence Number of the previous reflected packet. 625 o Timestamp - eight octets long field, with the format indicated by 626 the Z flag of the Error Estimate field as described in Section 4.1 627 [I-D.ietf-ippm-stamp]. It carries the timestamp when the 628 reflected packet with the specified sequence number was sent.. 630 o Timestamp M(ode) - one octet long field that characterizes the 631 method by which the entity that transmits a reflected STAMP packet 632 obtained the timestamp. The value is one of the listed in 633 Table 6. 635 o Reserved - the field MUST be zeroed on transmission and ignored on 636 receipt. 638 5. IANA Considerations 640 5.1. STAMP TLV Registry 642 IANA is requested to create the STAMP TLV Type registry. All code 643 points in the range 1 through 32759 in this registry shall be 644 allocated according to the "IETF Review" procedure as specified in 645 [RFC8126]. Code points in the range 32760 through 65279 in this 646 registry shall be allocated according to the "First Come First 647 Served" procedure as specified in [RFC8126]. Remaining code points 648 are allocated according to Table 1: 650 +---------------+-------------------------+-------------------------+ 651 | Value | Description | Reference | 652 +---------------+-------------------------+-------------------------+ 653 | 0 | Reserved | This document | 654 | 1- 32767 | Mandatory TLV, | IETF Review | 655 | | unassigned | | 656 | 32768 - 65279 | Optional TLV, | First Come First Served | 657 | | unassigned | | 658 | 65280 - 65519 | Experimental | This document | 659 | 65520 - 65534 | Private Use | This document | 660 | 65535 | Reserved | This document | 661 +---------------+-------------------------+-------------------------+ 663 Table 1: STAMP TLV Type Registry 665 This document defines the following new values in the STAMP TLV Type 666 registry: 668 +-------+-----------------------+---------------+ 669 | Value | Description | Reference | 670 +-------+-----------------------+---------------+ 671 | TBA1 | Extra Padding | This document | 672 | TBA2 | Location | This document | 673 | TBA3 | Timestamp Information | This document | 674 | TBA4 | Class of Service | This document | 675 | TBA6 | Access Report | This document | 676 | TBA7 | Follow-up Telemetry | This document | 677 +-------+-----------------------+---------------+ 679 Table 2: STAMP Types 681 5.2. Synchronization Source Sub-registry 683 IANA is requested to create Synchronization Source sub-registry as 684 part of STAMP TLV Type registry. All code points in the range 1 685 through 127 in this registry shall be allocated according to the 686 "IETF Review" procedure as specified in [RFC8126]. Code points in 687 the range 128 through 239 in this registry shall be allocated 688 according to the "First Come First Served" procedure as specified in 689 [RFC8126]. Remaining code points are allocated according to Table 1: 691 +-----------+--------------+-------------------------+ 692 | Value | Description | Reference | 693 +-----------+--------------+-------------------------+ 694 | 0 | Reserved | This document | 695 | 1- 127 | Unassigned | IETF Review | 696 | 128 - 239 | Unassigned | First Come First Served | 697 | 240 - 249 | Experimental | This document | 698 | 250 - 254 | Private Use | This document | 699 | 255 | Reserved | This document | 700 +-----------+--------------+-------------------------+ 702 Table 3: Synchronization Source Sub-registry 704 This document defines the following new values in the Synchronization 705 Source sub-registry: 707 +-------+---------------------+---------------+ 708 | Value | Description | Reference | 709 +-------+---------------------+---------------+ 710 | 1 | NTP | This document | 711 | 2 | PTP | This document | 712 | 3 | SSU/BITS | This document | 713 | 4 | GPS/GLONASS/LORAN-C | This document | 714 | 5 | Local free-running | This document | 715 +-------+---------------------+---------------+ 717 Table 4: Synchronization Sources 719 5.3. Timestamping Method Sub-registry 721 IANA is requested to create Timestamping Method sub-registry as part 722 of STAMP TLV Type registry. All code points in the range 1 through 723 127 in this registry shall be allocated according to the "IETF 724 Review" procedure as specified in [RFC8126]. Code points in the 725 range 128 through 239 in this registry shall be allocated according 726 to the "First Come First Served" procedure as specified in [RFC8126]. 727 Remaining code points are allocated according to Table 1: 729 +-----------+--------------+-------------------------+ 730 | Value | Description | Reference | 731 +-----------+--------------+-------------------------+ 732 | 0 | Reserved | This document | 733 | 1- 127 | Unassigned | IETF Review | 734 | 128 - 239 | Unassigned | First Come First Served | 735 | 240 - 249 | Experimental | This document | 736 | 250 - 254 | Private Use | This document | 737 | 255 | Reserved | This document | 738 +-----------+--------------+-------------------------+ 740 Table 5: Timestamping Method Sub-registry 742 This document defines the following new values in the Timestamping 743 Methods sub-registry: 745 +-------+---------------+---------------+ 746 | Value | Description | Reference | 747 +-------+---------------+---------------+ 748 | 1 | HW Assist | This document | 749 | 2 | SW local | This document | 750 | 3 | Control plane | This document | 751 +-------+---------------+---------------+ 753 Table 6: Timestamping Methods 755 5.4. Access ID Sub-registry 757 IANA is requested to create Access ID sub-registry as part of STAMP 758 TLV Type registry. All code points in the range 1 through 127 in 759 this registry shall be allocated according to the "IETF Review" 760 procedure as specified in [RFC8126]. Code points in the range 128 761 through 239 in this registry shall be allocated according to the 762 "First Come First Served" procedure as specified in [RFC8126]. 763 Remaining code points are allocated according to Table 7: 765 +-----------+--------------+-------------------------+ 766 | Value | Description | Reference | 767 +-----------+--------------+-------------------------+ 768 | 0 | Reserved | This document | 769 | 1- 127 | Unassigned | IETF Review | 770 | 128 - 239 | Unassigned | First Come First Served | 771 | 240 - 249 | Experimental | This document | 772 | 250 - 254 | Private Use | This document | 773 | 255 | Reserved | This document | 774 +-----------+--------------+-------------------------+ 776 Table 7: Access ID Sub-registry 778 This document defines the following new values in the Access ID sub- 779 registry: 781 +-------+-------------+---------------+ 782 | Value | Description | Reference | 783 +-------+-------------+---------------+ 784 | 1 | 3GPP | This document | 785 | 2 | Non-3GPP | This document | 786 +-------+-------------+---------------+ 788 Table 8: Access IDs 790 5.5. Return Code Sub-registry 792 IANA is requested to create Return Code sub-registry as part of STAMP 793 TLV Type registry. All code points in the range 1 through 127 in 794 this registry shall be allocated according to the "IETF Review" 795 procedure as specified in [RFC8126]. Code points in the range 128 796 through 239 in this registry shall be allocated according to the 797 "First Come First Served" procedure as specified in [RFC8126]. 798 Remaining code points are allocated according to Table 7: 800 +-----------+--------------+-------------------------+ 801 | Value | Description | Reference | 802 +-----------+--------------+-------------------------+ 803 | 0 | Reserved | This document | 804 | 1- 127 | Unassigned | IETF Review | 805 | 128 - 239 | Unassigned | First Come First Served | 806 | 240 - 249 | Experimental | This document | 807 | 250 - 254 | Private Use | This document | 808 | 255 | Reserved | This document | 809 +-----------+--------------+-------------------------+ 811 Table 9: Return Code Sub-registry 813 This document defines the following new values in the Return Code 814 sub-registry: 816 +-------+---------------------+---------------+ 817 | Value | Description | Reference | 818 +-------+---------------------+---------------+ 819 | 1 | Network available | This document | 820 | 2 | Network unavailable | This document | 821 +-------+---------------------+---------------+ 823 Table 10: Return Codes 825 6. Security Considerations 827 Use of HMAC in authenticated mode may be used to simultaneously 828 verify both the data integrity and the authentication of the STAMP 829 test packets. 831 7. Acknowledgments 833 Authors much appreciate the thorough review and thoughful comments 834 received from Tianran Zhou. 836 8. Contributors 838 The following people contributed text to this document: 840 Guo Jun 841 ZTE Corporation 842 68# Zijinghua Road 843 Nanjing, Jiangsu 210012 844 P.R.China 846 Phone: +86 18105183663 847 Email: guo.jun2@zte.com.cn 849 9. References 851 9.1. Normative References 853 [I-D.ietf-ippm-stamp] 854 Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 855 Two-way Active Measurement Protocol", draft-ietf-ippm- 856 stamp-09 (work in progress), October 2019. 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 864 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 865 RFC 5357, DOI 10.17487/RFC5357, October 2008, 866 . 868 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 869 Protocol (TWAMP) Reflect Octets and Symmetrical Size 870 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 871 . 873 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 874 Writing an IANA Considerations Section in RFCs", BCP 26, 875 RFC 8126, DOI 10.17487/RFC8126, June 2017, 876 . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 9.2. Informative References 884 [IEEE.1588.2008] 885 "Standard for a Precision Clock Synchronization Protocol 886 for Networked Measurement and Control Systems", 887 IEEE Standard 1588, March 2008. 889 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 890 "Network Time Protocol Version 4: Protocol and Algorithms 891 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 892 . 894 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 895 Specification Group Services and System Aspects; System 896 Architecture for the 5G System; Stage 2 (Release 16)", 897 3GPP TS23501, 2019. 899 Authors' Addresses 901 Greg Mirsky 902 ZTE Corp. 904 Email: gregimirsky@gmail.com 906 Xiao Min 907 ZTE Corp. 909 Email: xiao.min2@zte.com.cn 911 Henrik Nydell 912 Accedian Networks 914 Email: hnydell@accedian.com 916 Richard Foote 917 Nokia 919 Email: footer.foote@nokia.com 921 Adi Masputra 922 Apple Inc. 923 One Apple Park Way 924 Cupertino, CA 95014 925 USA 927 Email: adi@apple.com 929 Ernesto Ruffini 930 OutSys 931 via Caracciolo, 65 932 Milano 20155 933 Italy 935 Email: eruffini@outsys.org