idnits 2.17.1 draft-ietf-ippm-stamp-option-tlv-08.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 (August 4, 2020) is 1361 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Updates: 8762 (if approved) ZTE Corp. 5 Intended status: Standards Track H. Nydell 6 Expires: February 5, 2021 Accedian Networks 7 R. Foote 8 Nokia 9 A. Masputra 10 Apple Inc. 11 E. Ruffini 12 OutSys 13 August 4, 2020 15 Simple Two-way Active Measurement Protocol Optional Extensions 16 draft-ietf-ippm-stamp-option-tlv-08 18 Abstract 20 This document describes optional extensions to Simple Two-way Active 21 Measurement Protocol (STAMP) that enable measurement of performance 22 metrics. The document also defines a STAMP Test Session Identifier 23 and thus updates RFC 8762. 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 February 5, 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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4 64 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8 65 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11 66 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.1. Location Sub-TLVs . . . . . . . . . . . . . . . . . . 13 68 4.2.2. Theory of Operation of Location TLV . . . . . . . . . 14 69 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 16 70 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 17 71 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 18 72 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 19 73 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 21 74 4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 23 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 76 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 24 77 5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 25 78 5.3. Sub-TLV Type Sub-registry . . . . . . . . . . . . . . . . 25 79 5.4. Synchronization Source Sub-registry . . . . . . . . . . . 26 80 5.5. Timestamping Method Sub-registry . . . . . . . . . . . . 27 81 5.6. Return Code Sub-registry . . . . . . . . . . . . . . . . 28 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 87 9.2. Informative References . . . . . . . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 90 1. Introduction 92 Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined 93 the STAMP base functionalities. This document specifies the use of 94 optional extensions that use Type-Length-Value (TLV) encoding. Such 95 extensions enhance the STAMP base functions, such as measurement of 96 one-way and round-trip delay, latency, packet loss, packet 97 duplication, and out-of-order delivery of test packets. This 98 specification defines optional STAMP extensions, their formats, and 99 the theory of operation. Also, a STAMP Test Session Identifier is 100 defined as an update of the base STAMP specification [RFC8762]. 102 2. Conventions Used in This Document 104 2.1. Acronyms 106 BDS BeiDou Navigation Satellite System 108 BITS Building Integrated Timing Supply 110 CoS Class of Service 112 DSCP Differentiated Services Code Point 114 ECN Explicit Congestion Notification 116 GLONASS Global Orbiting Navigation Satellite System 118 GPS Global Positioning System [GPS] 120 HMAC Hashed Message Authentication Code 122 LORAN-C Long Range Navigation System Version C 124 MBZ Must Be Zero 126 NTP Network Time Protocol [RFC5905] 128 PMF Performance Measurement Function 130 PTP Precision Time Protocol [IEEE.1588.2008] 132 TLV Type-Length-Value 134 SSID STAMP Session Identifier 136 SSU Synchronization Supply Unit 138 STAMP Simple Two-way Active Measurement Protocol 140 2.2. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. STAMP Test Session Identifier 150 The STAMP Session-Sender transmits test packets to the STAMP Session- 151 Reflector. The STAMP Session-Reflector receives the Session-Sender's 152 packet and acts according to the configuration and optional control 153 information communicated in the Session-Sender's test packet. STAMP 154 defines two different test packet formats, one for packets 155 transmitted by the STAMP Session-Sender and one for packets 156 transmitted by the STAMP Session-Reflector. STAMP supports two 157 modes: unauthenticated and authenticated. Unauthenticated STAMP test 158 packets are compatible on the wire with unauthenticated TWAMP-Test 159 [RFC5357] packets. 161 By default, STAMP uses symmetrical packets, i.e., the size of the 162 packet transmitted by the Session-Reflector equals the size of the 163 packet received by the Session-Reflector. 165 A STAMP Session is identified by the 4-tuple (source and destination 166 IP addresses, source and destination UDP port numbers). A STAMP 167 Session-Sender MAY generate a locally unique STAMP Session Identifier 168 (SSID). The SSID is a two-octet-long non-zero unsigned integer. 169 SSID generation policy is implementation-specific. 170 [I-D.gont-numeric-ids-generation] thoroughly analyzes common 171 algorithms for identifier generation and their vulnerabilities. For 172 example, an implementation can use algorithms described in 173 Section 7.1 of [I-D.gont-numeric-ids-generation]. An implementation 174 MUST NOT assign the same identifier to different STAMP test sessions. 175 A Session-Sender MAY use the SSID to identify a STAMP test session. 176 If the SSID is used, it MUST be present in each test packet of the 177 given test session. In the unauthenticated mode, the SSID is located 178 as displayed in Figure 1. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Timestamp | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Error Estimate | SSID | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 | | 192 | MBZ (28 octets) | 193 | | 194 | | 195 | | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ~ TLVs ~ 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: The format of an extended STAMP Session-Sender test packet 202 in unauthenticated mode 204 An implementation of the STAMP Session-Reflector that supports this 205 specification MUST identify a STAMP Session using the SSID in 206 combination with elements of the usual 4-tuple for the session. 207 Before a test session commences, a Session-Reflector MUST be 208 provisioned with all the elements that identify the STAMP Session. A 209 STAMP Session-Reflector MUST discard non-matching STAMP test 210 packet(s). The means of provisioning the STAMP Session 211 identification is outside the scope of this specification. A 212 conforming implementation of STAMP Session-Reflector MUST copy the 213 SSID value from the received test packet and put it into the 214 reflected packet, as displayed in Figure 2. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Sequence Number | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Timestamp | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Error Estimate | SSID | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Receive Timestamp | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Session-Sender Sequence Number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Session-Sender Timestamp | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Session-Sender Error Estimate | MBZ | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |Ses-Sender TTL | MBZ | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ~ TLVs ~ 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: The format of an extended STAMP Session-Reflector test 242 packet in unauthenticated mode 244 A STAMP Session-Reflector that does not support this specification 245 will return the zeroed SSID field in the reflected STAMP test packet. 246 The Session-Sender MAY stop the session if it receives a zeroed SSID 247 field. An implementation of a Session-Sender MUST support control of 248 its behavior in such a scenario. If the test session is not stopped, 249 the Session-Sender, can, for example, send a base STAMP packet 250 [RFC8762] or continue transmitting STAMP test packets with the SSID. 252 Location of the SSID field in the authenticated mode is shown in 253 Figure 3 and Figure 4. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Sequence Number | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 | MBZ (12 octets) | 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Timestamp | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Error Estimate | SSID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 ~ ~ 270 | MBZ (68 octets) | 271 ~ ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | HMAC (16 octets) | 275 | | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 ~ TLVs ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3: Base STAMP Session-Sender test packet format in 282 authenticated mode 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Sequence Number | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | MBZ (12 octets) | 290 | | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Timestamp | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Error Estimate | SSID | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | MBZ (4 octets) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Receive Timestamp | 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MBZ (8 octets) | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Session-Sender Sequence Number | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | MBZ (12 octets) | 309 | | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Session-Sender Timestamp | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Session-Sender Error Estimate | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 317 | MBZ (6 octets) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |Ses-Sender TTL | | 320 +-+-+-+-+-+-+-+-+ + 321 | | 322 | MBZ (15 octets) | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | HMAC (16 octets) | 326 | | 327 | | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 ~ TLVs ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 4: Base STAMP Session-Reflector test packet format in 334 authenticated mode 336 4. TLV Extensions to STAMP 338 The Type-Length-Value (TLV) encoding scheme provides a flexible 339 extension mechanism for optional informational elements. TLV is an 340 optional field in the STAMP test packet. Multiple TLVs MAY be placed 341 in a STAMP test packet. Additional TLVs may be enclosed within a 342 given TLV, subject to the semantics of the (outer) TLV in question. 343 TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long 344 Type field, and a two-octet-long Length field that is equal to the 345 length of the Value field in octets. If a Type value for TLV or sub- 346 TLV is in the range for Vendor Private Use, the Length MUST be at 347 least 4, and the first four octets MUST be that vendor's Structure of 348 Management Information (SMI) Private Enterprise Code, as recorded in 349 IANA's SMI Private Enterprise Codes sub-registry, in network octet 350 order. The rest of the Value field is private to the vendor. The 351 following sections describe the use of TLVs for STAMP that extend the 352 STAMP capability beyond its base specification. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |STAMP TLV Flags| Type | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 ~ Value ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 5: TLV Format in a STAMP Extended Packet 364 where fields are defined as the following: 366 o STAMP TLV Flags - eight-bit-long field. Detailed format and 367 interpretation of flags defined in this specification is below. 369 o Type - one-octet-long field that characterizes the interpretation 370 of the Value field. It is allocated by IANA, as specified in 371 Section 5.1. 373 o Length - two-octet-long field equal to the length of the Value 374 field in octets. 376 o Value - a variable-length field. Its interpretation and encoding 377 is determined by the value of the Type field. 379 All multibyte fields in the defined in this specification TLVs are in 380 network byte order. 382 The format of the STAMP TLV Flags displayed in Figure 6 and the 383 location of flags is according to Section 5.2. 385 0 1 2 3 4 5 6 7 386 +-+-+-+-+-+-+-+-+ 387 |U|M|I|R|R|R|R|R| 388 +-+-+-+-+-+-+-+-+ 390 Figure 6: STAMP TLV Flags Format 392 where fields are defined as the following: 394 o U (Unrecognized) is a one-bit flag. A Session-Sender MUST set the 395 U flag to 1 before transmitting an extended STAMP test packet. A 396 Session-Reflector MUST set the U flag to 1 if the Session- 397 Reflector has not understood the TLV. Otherwise, the Session- 398 Reflector MUST set the U flag in the reflected packet to 0. 400 o M (Malformed) is a one-bit flag. A Session-Sender MUST set the M 401 flag to 0 before transmitting an extended STAMP test packet. A 402 Session-Reflector MUST set the M flag to 1 if the Session- 403 Reflector determined the TLV is malformed, i.e., the Length field 404 value is not valid for the particular type, or the remaining 405 length of the extended STAMP packet is less than the size of the 406 TLV. Otherwise, the Session-Reflector MUST set the M flag in the 407 reflected packet to 0. 409 o I (Integrity) is a one-bit flag. A Session-Sender MUST set the I 410 flag to 0 before transmitting an extended STAMP test packet. A 411 Session-Reflector MUST set the I flag to 1 if the STAMP extensions 412 have failed HMAC verification (Section 4.8). Otherwise, the 413 Session-Reflector MUST set the I flag in the reflected packet to 414 0. 416 o R - reserved flags for future use. These flags MUST be zeroed on 417 transmit and ignored on receipt. 419 A STAMP node, whether Session-Sender or Session-Reflector, receiving 420 a test packet MUST determine whether the packet is a base STAMP 421 packet or includes one or more TLVs. The node MUST compare the value 422 in the Length field of the UDP header and the length of the base 423 STAMP test packet in the mode, unauthenticated or authenticated based 424 on the configuration of the particular STAMP test session. If the 425 difference between the two values is larger than the length of the 426 UDP header, then the test packet includes one or more STAMP TLVs that 427 immediately follow the base STAMP test packet. A Session-Reflector 428 that does not support STAMP extensions will not process but copy them 429 into the reflected packet, as defined in Section 4.3 [RFC8762]. A 430 Session-Reflector that supports TLVs will indicate specific TLVs that 431 it did not process by setting the U flag to 1 in those TLVs. 433 A STAMP system, i.e., either a Session-Sender or a Session-Reflector, 434 that has received a STAMP test packet with extension TLVs MUST 435 validate each TLV: 437 If the U flag is set, the STAMP system MUST skip the processing of 438 the TLV. 440 If the M flag is set, the STAMP system MUST stop processing the 441 remainder of the extended STAMP packet. 443 If the I flag is set, the STAMP system MUST discard all TLVs and 444 MUST stop processing the remainder of the extended STAMP packet. 446 If an implementation of a Session-Reflector does not recognize the 447 Type field value, it MUST include a copy of the TLV into the 448 reflected STAMP packet. The Session-Reflector MUST set the U flag 449 to 1. The Session-Reflector MUST skip the processing of the 450 unrecognized TLV. 452 If a TLV is malformed, the processing of extension TLVs MUST be 453 stopped. The Session-Reflector MUST copy the remainder of the 454 received extended STAMP packet into the reflected STAMP packet. 455 The Session-Reflector MUST set the M flag to 1. 457 4.1. Extra Padding TLV 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |STAMP TLV Flags|Extra Pad Type | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 ~ Extra Padding ~ 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 7: Extra Padding TLV 471 where fields are defined as the following: 473 o STAMP TLV Flags - is an eight-bit-long field. Its format is 474 presented in Figure 6. 476 o Extra Padding Type - is a one-octet-long field, value TBA1 477 allocated by IANA Section 5.1. 479 o Length - two-octet-long field equal to the length of the Extra 480 Padding field in octets. 482 o Extra Padding - SHOULD be filled by a sequence of a pseudo-random 483 numbers. The field MAY be filled with all zeros. An 484 implementation MUST control the type of filling of the Extra 485 Padding field. 487 The Extra Padding TLV is similar to the Packet Padding field in a 488 TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is 489 RECOMMENDED to perform a STAMP test using test packets of larger size 490 than the base STAMP packet [RFC8762]. The length of the base STAMP 491 packet is 44 octets in the unauthenticated mode or 112 octets in the 492 authenticated mode. The Extra Padding TLV MAY be present more than 493 one time in an extended STAMP test packet. 495 4.2. Location TLV 497 STAMP Session-Senders MAY include the variable-size Location TLV to 498 query location information from the Session-Reflector. The Session- 499 Sender MUST NOT fill any information fields except for STAMP TLV 500 Flags, Type, and Length. The Session-Reflector MUST verify that the 501 TLV is well-formed. If it is not, the Session-Reflector follows the 502 procedure defined in Section 4 for a malformed TLV. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |STAMP TLV Flags| Location Type | Length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Destination Port | Source Port | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 ~ Sub-TLVs ~ 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 8: Location TLV 516 where fields are defined as the following: 518 o STAMP TLV Flags - is an eight-bit-long field. Its format is 519 presented in Figure 6. 521 o Location Type - is a one-octet-long field, value TBA2 allocated by 522 IANA Section 5.1. 524 o Length - two-octet-long field equal to the length of the Value 525 field in octets. 527 o Destination Port - two-octet-long UDP destination port number of 528 the received STAMP packet. 530 o Source Port - two-octet-long UDP source port number of the 531 received STAMP packet. 533 o Sub-TLVs - a sequence of sub-TLVs, as defined further in this 534 section. The sub-TLVs are used by the Session-Sender to request 535 location information with generic sub-TLV types, and the Session- 536 Reflector responds with the corresponding more-specific sub-TLVs 537 for the type of address (e.g., IPv4 or IPv6) used at the Session- 538 Reflector. 540 4.2.1. Location Sub-TLVs 542 A sub-TLV in the Location TLV uses the format displayed in Figure 5. 543 Handling of the U and M flags in the sub-TLV is as defined in 544 Section 4. The I flag MUST be set by a Session-Sender and Session- 545 Reflector to 0 before transmission and its value ignored on receipt. 546 The following types of sub-TLV for the Location TLV are defined in 547 this specification (type values are assigned according to Table 5): 549 o Source MAC Address sub-TLV - is a 12-octet-long sub-TLV. The Type 550 value is TBA9. The value of the Length field MUST equal to 8. 551 The Value field is a 12-octet-long MBZ field that MUST be zeroed 552 on transmission and ignored on receipt. 554 o Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that 555 includes the EUI-48 source MAC address. The Type value is TBA10. 556 The value of the Length field MUST equal to 8. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | EUI-48 Address | 562 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | MBZ | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 9: The Value Field of the Source EUI-48 Address sub-TLV 568 The Value field consists of the following fields (Figure 9): 570 * The EUI-48 is a six-octet-long field. 572 * Two-octet-ling MBZ field MUST be zeroed on transmission and 573 ignored on receipt. 575 o Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV that 576 includes the EUI-64 source MAC address. The Type value is TBA11. 577 The value of the Length field MUST equal to 12. The Value field 578 consists of an eight-octet-long EUI-64 field. 580 o Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. The 581 Type value is TBA12. The value of the Length field MUST equal to 582 16. The Value field consists of a 16-octet-long MBZ field that 583 MUST be zeroed on transmit and ignored on receipt 585 o Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that 586 includes IPv4 destination address. The Type value is TBA13. The 587 value of the Length field MUST equal to 16. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | IPv4 Address | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 ~ MBZ (12 octets) ~ 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Figure 10: IPv4 Address in a Sub-TLV's Value Field 600 The Value field consists of the following fields (Figure 10): 602 * The IPv4 Address is a four-octet-long field. 604 * 12-octet-long MBZ field MUST be zeroed on transmit and ignored 605 on receipt. 607 o Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that 608 includes IPv6 destination address. The Type value is TBA14. The 609 value of the Length field MUST equal to 16. The Value field is a 610 16-octet-long IP v6 Address field. 612 o Source IP Address sub-TLV - is a 20-octet-long sub-TLV. The Type 613 value is TBA15. The value of the Length field MUST equal to 16. 614 The Value field is a 16-octet-long MBZ field that MUST be zeroed 615 on transmit and ignored on receipt 617 o Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that 618 includes IPv4 source address. The Type value is TBA16. The value 619 of the Length field MUST equal to 16. The Value field consists of 620 the following fields (Figure 10): 622 * The IPv4 Address is a four-octet-long field. 624 * 12-octet-long MBZ field that MUST be zeroed on transmit and 625 ignored on receipt. 627 o Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that 628 includes IPv6 source address. The Type value is TBA17. The value 629 of the Length field MUST equal to 16. The Value field is a 16- 630 octet-long IPv6 Address field. 632 4.2.2. Theory of Operation of Location TLV 634 The Session-Reflector that received an extended STAMP packet with the 635 Location TLV MUST include the Location TLV of the size equal to the 636 size of Location TLV in the received packet in the reflected packet. 638 Based on the local policy, the Session-Reflector MAY leave some 639 fields unreported by filling them with zeroes. An implementation of 640 the stateful Session-Reflector MUST provide control for managing such 641 policies. 643 A Session-Sender MAY include the Source MAC Address sub-TLV is the 644 Location TLV. If the Session-Reflector receives the Location TLV 645 that includes the Source MAC Address sub-TLV, it MUST include the 646 Source EUI-48 Address sub-TLV if the source MAC address of the 647 received extended test packet is in EUI-48 format. And the Session- 648 Reflector MUST copy the value of the source MAC address in the EUI-48 649 field. Otherwise, the Session-Reflector MUST use the Source EUI-64 650 Address sub-TLV and MUST copy the value of the Source MAC address 651 from the received packet into the EUI-64 field. If the received 652 extended STAMP test packet does not have the Source MAC address, the 653 Session-Reflector MUST zero the EUI-64 field before transmitting the 654 reflected packet. 656 A Session-Sender MAY include the Destination IP Address sub-TLV is 657 the Location TLV. If the Session-Reflector receives the Location TLV 658 that includes the Destination IP Address sub-TLV, it MUST include the 659 Destination IPv4 Address sub-TLV if the source IP address of the 660 received extended test packet is of IPv4 address family. And the 661 Session-Reflector MUST copy the value of the destination IP address 662 in the IPv4 Address field. Otherwise, the Session-Reflector MUST use 663 the Destination IPv6 Address sub-TLV and MUST copy the value of the 664 destination IP address from the received packet into the IPv6 Address 665 field. 667 A Session-Sender MAY include the Source IP Address sub-TLV is the 668 Location TLV. If the Session-Reflector receives the Location TLV 669 that includes the Source IP Address sub-TLV, it MUST include the 670 Source IPv4 Address sub-TLV if the source IP address of the received 671 extended test packet is of IPv4 address family. And the Session- 672 Reflector MUST copy the value of the source IP address in the IPv4 673 Address field. Otherwise, the Session-Reflector MUST use the Source 674 IPv6 Address sub-TLV and MUST copy the value of the source IP address 675 from the received packet into the IPv6 Address field. 677 The Location TLV MAY be used to determine the last-hop IP addresses, 678 ports, and last-hop MAC address for STAMP packets. The MAC address 679 can indicate a path switch on the last hop. The IP addresses and UDP 680 ports will indicate if there is a NAT router on the path. It allows 681 the Session-Sender to identify the IP address of the Session- 682 Reflector behind the NAT, and detect changes in the NAT mapping that 683 could cause sending the STAMP packets to the wrong Session-Reflector. 685 4.3. Timestamp Information TLV 687 The STAMP Session-Sender MAY include the Timestamp Information TLV to 688 request information from the Session-Reflector. The Session-Sender 689 MUST NOT fill any information fields except for STAMP TLV Flags, 690 Type, and Length. All other fields MUST be filled with zeroes The 691 Session-Reflector MUST validate the Length value of the TLV. If the 692 value of the Length field is invalid, the Session-Reflector follows 693 the procedure defined in Section 4 for a malformed TLV. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |STAMP TLV Flags|Times Info Type| Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 ~ Optional sub-TLVs ~ 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 11: Timestamp Information TLV 707 where fields are defined as the following: 709 o STAMP TLV Flags - is an eight-bit-long field. Its format is 710 presented in Figure 6. 712 o Timestamp Information Type - is a one-octet-long field, value TBA3 713 allocated by IANA Section 5.1. 715 o Length - two-octet-long field, set equal to the length of the 716 Value field in octets (Figure 5). 718 o Sync Src In - one-octet-long field that characterizes the source 719 of clock synchronization at the ingress of a Session-Reflector. 720 There are several methods to synchronize the clock, e.g., Network 721 Time Protocol (NTP) [RFC5905]. The value is one of those listed 722 in Table 7. 724 o Timestamp In - one-octet-long field that characterizes the method 725 by which the ingress of the Session-Reflector obtained the 726 timestamp T2. A timestamp may be obtained with hardware 727 assistance, via software API from a local wall clock, or from a 728 remote clock (the latter is referred to as "control plane"). The 729 value is one of those listed in Table 9. 731 o Sync Src Out - one-octet-long field that characterizes the source 732 of clock synchronization at the egress of the Session-Reflector. 733 The value is one of those listed in Table 7. 735 o Timestamp Out - one-octet-long field that characterizes the method 736 by which the egress of the Session-Reflector obtained the 737 timestamp T3. The value is one of those listed in Table 9. 739 o Optional sub-TLVs - optional variable-length field. 741 4.4. Class of Service TLV 743 The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in 744 the STAMP test packet. The format of the CoS TLV is presented in 745 Figure 12. 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 |STAMP TLV Flags| CoS Type | Length | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | DSCP1 | DSCP2 |ECN| Reserved | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 12: Class of Service TLV 757 where fields are defined as the following: 759 o STAMP TLV Flags - is an eight-bit-long field. Its format is 760 presented in Figure 6. 762 o CoS (Class of Service) Type - is a one-octet-long field, value 763 TBA4 allocated by IANA Section 5.1. 765 o Length - two-octet-long field, set equal to the value 4. 767 o DSCP1 - The Differentiated Services Code Point (DSCP) intended by 768 the Session-Sender to be used as the DSCP value of the reflected 769 test packet. 771 o DSCP2 - The received value in the DSCP field at the ingress of the 772 Session-Reflector. 774 o ECN - The received value in the ECN field at the ingress of the 775 Session-Reflector. 777 o Reserved - 18-bit-long field, MUST be zeroed on transmission and 778 ignored on receipt. 780 A STAMP Session-Reflector that receives a test packet with the CoS 781 TLV MUST include the CoS TLV in the reflected test packet. Also, the 782 Session-Reflector MUST copy the value of the DSCP and ECN fields of 783 the IP header of the received STAMP test packet into the DSCP2 field 784 in the reflected test packet. Finally, the Session-Reflector MUST 785 set the DSCP field's value in the IP header of the reflected test 786 packet equal to the value of the DSCP1 field of the received test 787 packet. Upon receiving the reflected packet, the Session-Sender will 788 save the DSCP and ECN values for analysis of the CoS in the reverse 789 direction. 791 Re-mapping of CoS can be used to provide multiple services (e,g., 2G, 792 3G, LTE in mobile backhaul networks) over the same network. But if 793 it is misconfigured, then it is often difficult to diagnose the root 794 cause of excessive packet drops of higher-level service while packet 795 drops for lower service packets are at a normal level. Using a CoS 796 TLV in STAMP testing helps to troubleshoot the existing problem and 797 also verify whether DiffServ policies are processing CoS as required 798 by the configuration. 800 4.5. Direct Measurement TLV 802 The Direct Measurement TLV enables collection of the number of in- 803 profile packets, i.e., packets that form a specific data flow, that 804 had been transmitted and received by the Session-Sender and Session- 805 Reflector, respectively. The definition of "in-profile packet" is 806 outside the scope of this document and is left to the test operators 807 to determine. 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 |STAMP TLV Flags| Direct Type | Length | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Session-Sender Tx counter (S_TxC) | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Session-Reflector Rx counter (R_RxC) | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Session-Reflector Tx counter (R_TxC) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Figure 13: Direct Measurement TLV 823 where fields are defined as the following: 825 o STAMP TLV Flags - is an eight-bit-long field. Its format is 826 presented in Figure 6. 828 o Direct (Measurement) Type - is a one-octet-long field, value TBA5 829 allocated by IANA Section 5.1. 831 o Length - two-octet-long field equals the length of the Value field 832 in octets. The Length field value MUST equal 12 octets. 834 o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The 835 Session-Sender MUST set its value equal to the number of the 836 transmitted in-profile packets. 838 o Session-Reflector Rx counter (R_RxC) is a four-octet-long field. 839 MUST be zeroed by the Session-Sender on transmit and ignored by 840 the Session-Reflector on receipt. The Session-Reflector MUST fill 841 it with the value of in-profile packets received. 843 o Session-Reflector Tx counter (R_TxC) is a four-octet-long field. 844 MUST be zeroed by the Session-Sender and ignored by the Session- 845 Reflector on receipt. The Session-Reflector MUST fill it with the 846 value of the transmitted in-profile packets. 848 A Session-Sender MAY include the Direct Measurement TLV in a STAMP 849 test packet. If the received STAMP test packet includes the Direct 850 Measurement TLV, the Session-Reflector MUST include it in the 851 reflected test packet. The Session-Reflector MUST copy the value 852 from the S_TxC field of the received test packet into the same field 853 of the reflected packet before its transmission. 855 4.6. Access Report TLV 857 A STAMP Session-Sender MAY include an Access Report TLV (Figure 14) 858 to indicate changes to the access network status to the Session- 859 Reflector. The definition of an access network is outside the scope 860 of this document. 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 |STAMP TLV Flags|Acc Report Type| Length | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | ID | Resv | Return Code | Reserved | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 Figure 14: Access Report TLV 872 where fields are defined as follows: 874 o STAMP TLV Flags - is an eight-bit-long field. Its format 875 presented in Figure 6. 877 o Access Report Type - is a one-octet-long field, value TBA6 878 allocated by IANA Section 5.1. 880 o Length - two-octet-long field, set equal to the value 4. 882 o ID (Access ID) - four-bit-long field that identifies the access 883 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 884 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 885 The value is one of those listed below: 887 * 1 - 3GPP Network 889 * 2 - Non-3GPP Network 891 All other values are invalid and the TLV that contains it MUST be 892 discarded. 894 o Resv - four-bit-long field, MUST be zeroed on transmission and 895 ignored on receipt. 897 o Return Code - one-octet-long field that identifies the report 898 signal, e.g., available or unavailable. The value is supplied to 899 the STAMP end-point through some mechanism that is outside the 900 scope of this document. The value is one of those listed in 901 Section 5.6. 903 o Reserved - two-octet-long field, MUST be zeroed on transmission 904 and ignored on receipt. 906 The STAMP Session-Sender that includes the Access Report TLV sets the 907 value of the Access ID field according to the type of access network 908 it reports on. Also, the Session-Sender sets the value of the Return 909 Code field to reflect the operational state of the access network. 910 The mechanism to determine the state of the access network is outside 911 the scope of this specification. A STAMP Session-Reflector that 912 received the test packet with the Access Report TLV MUST include the 913 Access Report TLV in the reflected test packet. The Session- 914 Reflector MUST set the value of the Access ID and Return Code fields 915 equal to the values of the corresponding fields from the test packet 916 it has received. 918 The Session-Sender MUST also arm a retransmission timer after sending 919 a test packet that includes the Access Report TLV. This timer MUST 920 be disarmed upon reception of the reflected STAMP test packet that 921 includes the Access Report TLV. In the event the timer expires 922 before such a packet is received, the Session-Sender MUST retransmit 923 the STAMP test packet that contains the Access Report TLV. This 924 retransmission SHOULD be repeated up to four times before the 925 procedure is aborted. Setting the value for the retransmission timer 926 is based on local policies and network environment. The default 927 value of the retransmission timer for the Access Report TLV SHOULD be 928 three seconds. An implementation MUST provide control of the 929 retransmission timer value and the number of retransmissions. 931 The Access Report TLV is used by the Performance Measurement Function 932 (PMF) components of the Access Steering, Switching and Splitting 933 feature for 5G networks [TS23501]. The PMF component in the User 934 Equipment acts as the STAMP Session-Sender, and the PMF component in 935 the User Plane Function acts as the STAMP Session-Reflector. 937 4.7. Follow-up Telemetry TLV 939 A Session-Reflector might be able to put in the Timestamp field only 940 an "SW Local" (see Table 9) timestamp. But the hosting system might 941 provide a timestamp closer to the start of the actual packet 942 transmission even though it is not possible to deliver the 943 information to the Session-Sender in time for the packet itself. 944 This timestamp might nevertheless be important for the Session- 945 Sender, as it improves the accuracy of measuring network delay by 946 minimizing the impact of egress queuing delays on the measurement. 948 A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to 949 request information from the Session-Reflector. The Session-Sender 950 MUST set the Follow-up Telemetry Type and Length fields to their 951 appropriate values. The Sequence Number and Timestamp fields MUST be 952 zeroed on transmission by the Session-Sender and ignored by the 953 Session-Reflector upon receipt of the STAMP test packet that includes 954 the Follow-up Telemetry TLV. The Session-Reflector MUST validate the 955 Length value of the STAMP test packet. If the value of the Length 956 field is invalid, the Session-Reflector MUST zero the Sequence Number 957 and Timestamp fields and set the M flag in the STAMP TLV Flags field 958 in the reflected packet. If the Session-Reflector is in stateless 959 mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence 960 Number and Timestamp fields. 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 |STAMP TLV Flags| Follow-up Type| Length | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Sequence Number | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Follow-up Timestamp | 970 | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Timestamp M | Reserved | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Figure 15: Follow-up Telemetry TLV 977 where fields are defined as follows: 979 o STAMP TLV Flags - is an eight-bit-long field. Its format 980 presented in Figure 6. 982 o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 983 allocated by IANA Section 5.1. 985 o Length - two-octet-long field, set equal to the value 16 octets. 987 o Sequence Number - four-octet-long field indicating the sequence 988 number of the last packet reflected in the same STAMP-test 989 session. Since the Session-Reflector runs in the stateful mode 990 (defined in Section 4.2 [RFC8762]), it is the Session-Reflector's 991 Sequence Number of the previous reflected packet. 993 o Follow-up Timestamp - eight-octet-long field, with the format 994 indicated by the Z flag of the Error Estimate field of the STAMP 995 base packet, which is contained in this reflected test packet 996 transmitted by a Session-Reflector, as described in Section 4.2.1 997 [RFC8762]. It carries the timestamp when the reflected packet 998 with the specified sequence number was sent. 1000 o Timestamp M(ode) - one-octet-long field that characterizes the 1001 method by which the entity that transmits a reflected STAMP packet 1002 obtained the Follow-up Timestamp. The value is one of those 1003 listed in Table 9. 1005 o Reserved - three-octet-long field. Its value MUST be zeroed on 1006 transmission and ignored on receipt. 1008 4.8. HMAC TLV 1010 The STAMP authenticated mode protects the integrity of data collected 1011 in the STAMP base packet. STAMP extensions are designed to provide 1012 valuable information about the condition of a network, and protecting 1013 the integrity of that data is also essential. All authenticated 1014 STAMP base packets (per Section 4.2.2 and Section 4.3.2 [RFC8762]) 1015 compatible with this specification MUST additionally authenticate the 1016 option TLVs by including the keyed Hashed Message Authentication Code 1017 (HMAC) TLV, with the sole exception of when there is only one TLV 1018 present, and it is the Extended Padding TLV. The HMAC TLV MUST 1019 follow all TLVs included in a STAMP test packet, except for the Extra 1020 Padding TLV. If the HMAC TLV appears in any other position in a 1021 STAMP extended test packet, then the situation MUST be processed as 1022 HMAC verification failure, as defined in this section, further below. 1023 The HMAC TLV MAY be used to protect the integrity of STAMP extensions 1024 in STAMP unauthenticated mode. An implementation of STAMP extensions 1025 MUST provide controls to enable the integrity protection of STAMP 1026 extensions in STAMP unauthenticated mode. 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 |STAMP TLV Flags| HMAC Type | Length | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | | 1034 | HMAC | 1035 | | 1036 | | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Figure 16: HMAC TLV 1041 where fields are defined as follows: 1043 o STAMP TLV Flags - is an eight-bit-long field. Its format is 1044 presented in Figure 6. 1046 o HMAC Type - is a one-octet-long field, value TBA8 allocated by 1047 IANA Section 5.1. 1049 o Length - two-octet-long field, set equal to 16 octets. 1051 o HMAC - is a 16-octet-long field that carries HMAC digest of the 1052 text of all preceding TLVs. 1054 As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 1055 bits ([RFC4868]). All considerations regarding using the key and key 1056 distribution and management listed in Section 4.4 of [RFC8762] are 1057 fully applicable to the use of the HMAC TLV. HMAC TLV is anticipated 1058 to track updates in the base STAMP protocol [RFC8762], including the 1059 use of more advanced cryptographic algorithms. HMAC is calculated as 1060 defined in [RFC2104] over text as the concatenation of the Sequence 1061 Number field of the base STAMP packet and all preceding TLVs. The 1062 digest then MUST be truncated to 128 bits and written into the HMAC 1063 field. If the HMAC TLV is present in the extended STAMP test packet, 1064 e.g., in the authenticated mode, HMAC MUST be verified before using 1065 any data in the included STAMP TLVs. If HMAC verification by the 1066 Session-Reflector fails, then the Session-Reflector MUST stop 1067 processing the received extended STAMP test packet. The Session- 1068 Reflector MUST copy the TLVs from the received STAMP test packet into 1069 the reflected packet. The Session-Reflector MUST set the I flag in 1070 each TLV copied over into the reflected packet to 1 before 1071 transmitting the reflected test packet. If the Session-Sender 1072 receives the extended STAMP test packet with I flag set to 1, then 1073 the Session-Sender MUST stop processing TLVs in the reflected test 1074 packet. If HMAC verification by the Session-Sender fails, then the 1075 Session-Sender MUST stop processing TLVs in the reflected extended 1076 STAMP packet. 1078 5. IANA Considerations 1080 5.1. STAMP TLV Registry 1082 IANA is requested to create the STAMP TLV Type registry. All code 1083 points in the range 1 through 175 in this registry shall be allocated 1084 according to the "IETF Review" procedure as specified in [RFC8126]. 1085 Code points in the range 176 through 239 in this registry shall be 1086 allocated according to the "First Come First Served" procedure as 1087 specified in [RFC8126]. The remaining code points are allocated 1088 according to Table 1: 1090 +-----------+--------------+---------------+ 1091 | Value | Description | Reference | 1092 +-----------+--------------+---------------+ 1093 | 0 | Reserved | This document | 1094 | 1- 175 | Unassigned | This document | 1095 | 176 - 239 | Unassigned | This document | 1096 | 240 - 251 | Experimental | This document | 1097 | 252 - 254 | Private Use | This document | 1098 | 255 | Reserved | This document | 1099 +-----------+--------------+---------------+ 1101 Table 1: STAMP TLV Type Registry 1103 This document defines the following new values in the IETF Review 1104 range of the STAMP TLV Type registry: 1106 +-------+-----------------------+---------------+ 1107 | Value | Description | Reference | 1108 +-------+-----------------------+---------------+ 1109 | TBA1 | Extra Padding | This document | 1110 | TBA2 | Location | This document | 1111 | TBA3 | Timestamp Information | This document | 1112 | TBA4 | Class of Service | This document | 1113 | TBA5 | Direct Measurement | This document | 1114 | TBA6 | Access Report | This document | 1115 | TBA7 | Follow-up Telemetry | This document | 1116 | TBA8 | HMAC | This document | 1117 +-------+-----------------------+---------------+ 1119 Table 2: STAMP TLV Types 1121 5.2. STAMP TLV Flags Sub-registry 1123 IANA is requested to create the STAMP TLV Flags sub-registry as part 1124 of the STAMP TLV Type registry. The registration procedure is "IETF 1125 Review" [RFC8126]. Flags are 8 bits. This document defines the 1126 following bit positions in the STAMP TLV Flags sub-registry: 1128 +--------------+--------+------------------------+---------------+ 1129 | Bit position | Symbol | Description | Reference | 1130 +--------------+--------+------------------------+---------------+ 1131 | 0 | U | Unrecognized TLV | This document | 1132 | 1 | M | Malformed TLV | This document | 1133 | 2 | I | Integrity check failed | This document | 1134 +--------------+--------+------------------------+---------------+ 1136 Table 3: STAMP TLV Flags 1138 5.3. Sub-TLV Type Sub-registry 1140 IANA is requested to create the sub-TLV Type sub-registry as part of 1141 the STAMP TLV Type registry. All code points in the range 1 through 1142 175 in this registry shall be allocated according to the "IETF 1143 Review" procedure as specified in [RFC8126]. Code points in the 1144 range 176 through 239 in this registry shall be allocated according 1145 to the "First Come First Served" procedure as specified in [RFC8126]. 1146 The remaining code points are allocated according to Table 4: 1148 +-----------+--------------+---------------+ 1149 | Value | Description | Reference | 1150 +-----------+--------------+---------------+ 1151 | 0 | Reserved | This document | 1152 | 1- 175 | Unassigned | This document | 1153 | 176 - 239 | Unassigned | This document | 1154 | 240 - 251 | Experimental | This document | 1155 | 252 - 254 | Private Use | This document | 1156 | 255 | Reserved | This document | 1157 +-----------+--------------+---------------+ 1159 Table 4: Location Sub-TLV Type Sub-registry 1161 This document defines the following new values in the IETF Review 1162 range of the Location sub-TLV Type sub-registry: 1164 +-------+--------------------------+----------+---------------+ 1165 | Value | Description | TLV Used | Reference | 1166 +-------+--------------------------+----------+---------------+ 1167 | TBA9 | Source MAC Address | Location | This document | 1168 | TBA10 | Source EUI-48 Address | Location | This document | 1169 | TBA11 | Source EUI-64 Address | Location | This document | 1170 | TBA12 | Destination IP Address | Location | This document | 1171 | TBA13 | Destination IPv4 Address | Location | This document | 1172 | TBA14 | Destination IPv6 Address | Location | This document | 1173 | TBA15 | Source IP Address | Location | This document | 1174 | TBA16 | Source IPv4 Address | Location | This document | 1175 | TBA17 | Source IPv6 Address | Location | This document | 1176 +-------+--------------------------+----------+---------------+ 1178 Table 5: STAMP sub-TLV Types 1180 5.4. Synchronization Source Sub-registry 1182 IANA is requested to create the Synchronization Source sub-registry 1183 as part of the STAMP TLV Type registry. All code points in the range 1184 1 through 127 in this registry shall be allocated according to the 1185 "IETF Review" procedure as specified in [RFC8126]. Code points in 1186 the range 128 through 239 in this registry shall be allocated 1187 according to the "First Come First Served" procedure as specified in 1188 [RFC8126]. Remaining code points are allocated according to Table 6: 1190 +-----------+--------------+---------------+ 1191 | Value | Description | Reference | 1192 +-----------+--------------+---------------+ 1193 | 0 | Reserved | This document | 1194 | 1- 127 | Unassigned | This document | 1195 | 128 - 239 | Unassigned | This document | 1196 | 240 - 249 | Experimental | This document | 1197 | 250 - 254 | Private Use | This document | 1198 | 255 | Reserved | This document | 1199 +-----------+--------------+---------------+ 1201 Table 6: Synchronization Source Sub-registry 1203 This document defines the following new values in the Synchronization 1204 Source sub-registry: 1206 +-------+---------------------------------+---------------+ 1207 | Value | Description | Reference | 1208 +-------+---------------------------------+---------------+ 1209 | 1 | NTP | This document | 1210 | 2 | PTP | This document | 1211 | 3 | SSU/BITS | This document | 1212 | 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | This document | 1213 | 5 | Local free-running | This document | 1214 +-------+---------------------------------+---------------+ 1216 Table 7: Synchronization Sources 1218 5.5. Timestamping Method Sub-registry 1220 IANA is requested to create the Timestamping Method sub-registry as 1221 part of the STAMP TLV Type registry. All code points in the range 1 1222 through 127 in this registry shall be allocated according to the 1223 "IETF Review" procedure as specified in [RFC8126]. Code points in 1224 the range 128 through 239 in this registry shall be allocated 1225 according to the "First Come First Served" procedure as specified in 1226 [RFC8126]. Remaining code points are allocated according to Table 8: 1228 +-----------+--------------+---------------+ 1229 | Value | Description | Reference | 1230 +-----------+--------------+---------------+ 1231 | 0 | Reserved | This document | 1232 | 1- 127 | Unassigned | This document | 1233 | 128 - 239 | Unassigned | This document | 1234 | 240 - 249 | Experimental | This document | 1235 | 250 - 254 | Private Use | This document | 1236 | 255 | Reserved | This document | 1237 +-----------+--------------+---------------+ 1239 Table 8: Timestamping Method Sub-registry 1241 This document defines the following new values in the Timestamping 1242 Methods sub-registry: 1244 +-------+---------------+---------------+ 1245 | Value | Description | Reference | 1246 +-------+---------------+---------------+ 1247 | 1 | HW Assist | This document | 1248 | 2 | SW local | This document | 1249 | 3 | Control plane | This document | 1250 +-------+---------------+---------------+ 1252 Table 9: Timestamping Methods 1254 5.6. Return Code Sub-registry 1256 IANA is requested to create the Return Code sub-registry as part of 1257 the STAMP TLV Type registry. All code points in the range 1 through 1258 127 in this registry shall be allocated according to the "IETF 1259 Review" procedure as specified in [RFC8126]. Code points in the 1260 range 128 through 239 in this registry shall be allocated according 1261 to the "First Come First Served" procedure as specified in [RFC8126]. 1262 Remaining code points are allocated according to Table 10: 1264 +-----------+--------------+---------------+ 1265 | Value | Description | Reference | 1266 +-----------+--------------+---------------+ 1267 | 0 | Reserved | This document | 1268 | 1- 127 | Unassigned | This document | 1269 | 128 - 239 | Unassigned | This document | 1270 | 240 - 249 | Experimental | This document | 1271 | 250 - 254 | Private Use | This document | 1272 | 255 | Reserved | This document | 1273 +-----------+--------------+---------------+ 1275 Table 10: Return Code Sub-registry 1277 This document defines the following new values in the Return Code 1278 sub-registry: 1280 +-------+---------------------+---------------+ 1281 | Value | Description | Reference | 1282 +-------+---------------------+---------------+ 1283 | 1 | Network available | This document | 1284 | 2 | Network unavailable | This document | 1285 +-------+---------------------+---------------+ 1287 Table 11: Return Codes 1289 6. Security Considerations 1291 This document defines extensions to STAMP [RFC8762] and inherits all 1292 the security considerations applicable to the base protocol. 1293 Additionally, the HMAC TLV is defined in this document to protect the 1294 integrity of optional STAMP extensions. The use of HMAC TLV is 1295 discussed in detail in Section 4.8. 1297 To protect against a malformed TLV an implementation of a Session- 1298 Sender and Session-Reflector MUST: 1300 o check the setting of the M flag; 1302 o validate the Length field value. 1304 Monitoring and optional control of DSCP do not appear to introduce 1305 any additional security threat to hosts that communicate with STAMP 1306 as defined in [RFC8762]. As this specification defined the mechanism 1307 to test DSCP mapping, this document inherits all the security 1308 considerations discussed in [RFC2474]. 1310 7. Acknowledgments 1312 Authors much appreciate the thorough review and thoughtful comments 1313 received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali 1314 Wang. The authors express their gratitude to Al Morton for his 1315 comments and the most valuable suggestions. The authors greatly 1316 appreciate comments and thoughtful suggestions received from Martin 1317 Duke. 1319 8. Contributors 1321 The following people contributed text to this document: 1323 Guo Jun 1324 ZTE Corporation 1325 68# Zijinghua Road 1326 Nanjing, Jiangsu 210012 1327 P.R.China 1329 Phone: +86 18105183663 1330 Email: guo.jun2@zte.com.cn 1332 9. References 1334 9.1. Normative References 1336 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1337 Hashing for Message Authentication", RFC 2104, 1338 DOI 10.17487/RFC2104, February 1997, 1339 . 1341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1342 Requirement Levels", BCP 14, RFC 2119, 1343 DOI 10.17487/RFC2119, March 1997, 1344 . 1346 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1347 Writing an IANA Considerations Section in RFCs", BCP 26, 1348 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1349 . 1351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1353 May 2017, . 1355 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1356 Two-Way Active Measurement Protocol", RFC 8762, 1357 DOI 10.17487/RFC8762, March 2020, 1358 . 1360 9.2. Informative References 1362 [GPS] "Global Positioning System (GPS) Standard Positioning 1363 Service (SPS) Performance Standard", GPS SPS 5th Edition, 1364 April 2020. 1366 [I-D.gont-numeric-ids-generation] 1367 Gont, F. and I. Arce, "On the Generation of Transient 1368 Numeric Identifiers", draft-gont-numeric-ids-generation-04 1369 (work in progress), July 2019. 1371 [IEEE.1588.2008] 1372 "Standard for a Precision Clock Synchronization Protocol 1373 for Networked Measurement and Control Systems", 1374 IEEE Standard 1588, March 2008. 1376 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1377 "Definition of the Differentiated Services Field (DS 1378 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1379 DOI 10.17487/RFC2474, December 1998, 1380 . 1382 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1383 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1384 DOI 10.17487/RFC4868, May 2007, 1385 . 1387 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1388 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1389 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1390 . 1392 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1393 "Network Time Protocol Version 4: Protocol and Algorithms 1394 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1395 . 1397 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 1398 Specification Group Services and System Aspects; System 1399 Architecture for the 5G System; Stage 2 (Release 16)", 1400 3GPP TS23501, 2019. 1402 Authors' Addresses 1404 Greg Mirsky 1405 ZTE Corp. 1407 Email: gregimirsky@gmail.com 1409 Xiao Min 1410 ZTE Corp. 1412 Email: xiao.min2@zte.com.cn 1413 Henrik Nydell 1414 Accedian Networks 1416 Email: hnydell@accedian.com 1418 Richard Foote 1419 Nokia 1421 Email: footer.foote@nokia.com 1423 Adi Masputra 1424 Apple Inc. 1425 One Apple Park Way 1426 Cupertino, CA 95014 1427 USA 1429 Email: adi@apple.com 1431 Ernesto Ruffini 1432 OutSys 1433 via Caracciolo, 65 1434 Milano 20155 1435 Italy 1437 Email: eruffini@outsys.org