idnits 2.17.1 draft-ietf-ippm-stamp-option-tlv-10.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 (November 15, 2020) is 1258 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: May 19, 2021 Accedian Networks 7 R. Foote 8 Nokia 9 A. Masputra 10 Apple Inc. 11 E. Ruffini 12 OutSys 13 November 15, 2020 15 Simple Two-way Active Measurement Protocol Optional Extensions 16 draft-ietf-ippm-stamp-option-tlv-10 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 May 19, 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 . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . . 30 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 TLVs defined in this specification 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 Session-Sender that has received a reflected STAMP test 434 packet with extension TLVs MUST validate each TLV: 436 If the U flag is set, the STAMP system MUST skip the processing of 437 the TLV. 439 If the M flag is set, the STAMP system MUST stop processing the 440 remainder of the extended STAMP packet. 442 If the I flag is set, the STAMP system MUST discard all TLVs and 443 MUST stop processing the remainder of the extended STAMP packet. 445 If an implementation of a Session-Reflector does not recognize the 446 Type field value, it MUST include a copy of the TLV into the 447 reflected STAMP packet. The Session-Reflector MUST set the U flag 448 to 1. The Session-Reflector MUST skip the processing of the 449 unrecognized TLV. 451 If a TLV is malformed, the processing of extension TLVs MUST be 452 stopped. The Session-Reflector MUST copy the remainder of the 453 received extended STAMP packet into the reflected STAMP packet. 454 The Session-Reflector MUST set the M flag to 1. 456 4.1. Extra Padding TLV 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |STAMP TLV Flags|Extra Pad Type | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 ~ Extra Padding ~ 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 7: Extra Padding TLV 470 where fields are defined as the following: 472 o STAMP TLV Flags - is an eight-bit-long field. Its format is 473 presented in Figure 6. 475 o Extra Padding Type - is a one-octet-long field, value TBA1 476 allocated by IANA Section 5.1. 478 o Length - two-octet-long field equal to the length of the Extra 479 Padding field in octets. 481 o Extra Padding - SHOULD be filled by a sequence of a pseudo-random 482 numbers. The field MAY be filled with all zeros. An 483 implementation MUST control the type of filling of the Extra 484 Padding field. 486 The Extra Padding TLV is similar to the Packet Padding field in a 487 TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is 488 RECOMMENDED to perform a STAMP test using test packets of larger size 489 than the base STAMP packet [RFC8762]. The length of the base STAMP 490 packet is 44 octets in the unauthenticated mode or 112 octets in the 491 authenticated mode. The Extra Padding TLV MAY be present more than 492 one time in an extended STAMP test packet. 494 4.2. Location TLV 496 STAMP Session-Senders MAY include the variable-size Location TLV to 497 query location information from the Session-Reflector. The Session- 498 Sender MUST NOT fill any information fields except for STAMP TLV 499 Flags, Type, and Length. The Session-Reflector MUST verify that the 500 TLV is well-formed. If it is not, the Session-Reflector follows the 501 procedure defined in Section 4 for a malformed TLV. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |STAMP TLV Flags| Location Type | Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Destination Port | Source Port | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 ~ Sub-TLVs ~ 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 8: Location TLV 515 where fields are defined as the following: 517 o STAMP TLV Flags - is an eight-bit-long field. Its format is 518 presented in Figure 6. 520 o Location Type - is a one-octet-long field, value TBA2 allocated by 521 IANA Section 5.1. 523 o Length - two-octet-long field equal to the length of the Value 524 field in octets. 526 o Destination Port - two-octet-long UDP destination port number of 527 the received STAMP packet. 529 o Source Port - two-octet-long UDP source port number of the 530 received STAMP packet. 532 o Sub-TLVs - a sequence of sub-TLVs, as defined further in this 533 section. The sub-TLVs are used by the Session-Sender to request 534 location information with generic sub-TLV types, and the Session- 535 Reflector responds with the corresponding more-specific sub-TLVs 536 for the type of address (e.g., IPv4 or IPv6) used at the Session- 537 Reflector. 539 Note that all fields not filled by either a Session-Sender or 540 Session-Reflector are transmitted with all bits set to zero. 542 4.2.1. Location Sub-TLVs 544 A sub-TLV in the Location TLV uses the format displayed in Figure 5. 545 Handling of the U and M flags in the sub-TLV is as defined in 546 Section 4. The I flag MUST be set by a Session-Sender and Session- 547 Reflector to 0 before transmission and its value ignored on receipt. 548 The following types of sub-TLV for the Location TLV are defined in 549 this specification (type values are assigned according to Table 5): 551 o Source MAC Address sub-TLV - is a 12-octet-long sub-TLV. The Type 552 value is TBA9. The value of the Length field MUST equal to 8. 553 The Value field is an 8-octet-long MBZ field that MUST be zeroed 554 on transmission and ignored on receipt. 556 o Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that 557 includes the EUI-48 source MAC address. The Type value is TBA10. 558 The value of the Length field MUST equal to 8. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | EUI-48 Address | 564 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | MBZ | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 9: The Value Field of the Source EUI-48 Address sub-TLV 570 The Value field consists of the following fields (Figure 9): 572 * The EUI-48 is a six-octet-long field. 574 * Two-octet-ling MBZ field MUST be zeroed on transmission and 575 ignored on receipt. 577 o Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV that 578 includes the EUI-64 source MAC address. The Type value is TBA11. 579 The value of the Length field MUST equal to 8. The Value field 580 consists of an eight-octet-long EUI-64 field. 582 o Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. The 583 Type value is TBA12. The value of the Length field MUST equal to 584 16. The Value field consists of a 16-octet-long MBZ field that 585 MUST be zeroed on transmit and ignored on receipt 587 o Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that 588 includes IPv4 destination address. The Type value is TBA13. The 589 value of the Length field MUST equal to 16. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | IPv4 Address | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 ~ MBZ (12 octets) ~ 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 10: IPv4 Address in a Sub-TLV's Value Field 602 The Value field consists of the following fields (Figure 10): 604 * The IPv4 Address is a four-octet-long field. 606 * 12-octet-long MBZ field MUST be zeroed on transmit and ignored 607 on receipt. 609 o Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that 610 includes IPv6 destination address. The Type value is TBA14. The 611 value of the Length field MUST equal to 16. The Value field is a 612 16-octet-long IP v6 Address field. 614 o Source IP Address sub-TLV - is a 20-octet-long sub-TLV. The Type 615 value is TBA15. The value of the Length field MUST equal to 16. 616 The Value field is a 16-octet-long MBZ field that MUST be zeroed 617 on transmit and ignored on receipt 619 o Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that 620 includes IPv4 source address. The Type value is TBA16. The value 621 of the Length field MUST equal to 16. The Value field consists of 622 the following fields (Figure 10): 624 * The IPv4 Address is a four-octet-long field. 626 * 12-octet-long MBZ field that MUST be zeroed on transmit and 627 ignored on receipt. 629 o Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that 630 includes IPv6 source address. The Type value is TBA17. The value 631 of the Length field MUST equal to 16. The Value field is a 16- 632 octet-long IPv6 Address field. 634 4.2.2. Theory of Operation of Location TLV 636 The Session-Reflector that received an extended STAMP packet with the 637 Location TLV MUST include the Location TLV of the size equal to the 638 size of Location TLV in the received packet in the reflected packet. 640 Based on the local policy, the Session-Reflector MAY leave some 641 fields unreported by filling them with zeroes. An implementation of 642 the stateful Session-Reflector MUST provide control for managing such 643 policies. 645 A Session-Sender MAY include the Source MAC Address sub-TLV in the 646 Location TLV. If the Session-Reflector receives the Location TLV 647 that includes the Source MAC Address sub-TLV, it MUST include the 648 Source EUI-48 Address sub-TLV if the source MAC address of the 649 received extended test packet is in EUI-48 format. And the Session- 650 Reflector MUST copy the value of the source MAC address in the EUI-48 651 field. Otherwise, the Session-Reflector MUST use the Source EUI-64 652 Address sub-TLV and MUST copy the value of the Source MAC address 653 from the received packet into the EUI-64 field. If the received 654 extended STAMP test packet does not have the Source MAC address, the 655 Session-Reflector MUST zero the EUI-64 field before transmitting the 656 reflected packet. 658 A Session-Sender MAY include the Destination IP Address sub-TLV in 659 the Location TLV. If the Session-Reflector receives the Location TLV 660 that includes the Destination IP Address sub-TLV, it MUST include the 661 Destination IPv4 Address sub-TLV if the source IP address of the 662 received extended test packet is of IPv4 address family. And the 663 Session-Reflector MUST copy the value of the destination IP address 664 in the IPv4 Address field. Otherwise, the Session-Reflector MUST use 665 the Destination IPv6 Address sub-TLV and MUST copy the value of the 666 destination IP address from the received packet into the IPv6 Address 667 field. 669 A Session-Sender MAY include the Source IP Address sub-TLV in the 670 Location TLV. If the Session-Reflector receives the Location TLV 671 that includes the Source IP Address sub-TLV, it MUST include the 672 Source IPv4 Address sub-TLV if the source IP address of the received 673 extended test packet is of IPv4 address family. And the Session- 674 Reflector MUST copy the value of the source IP address in the IPv4 675 Address field. Otherwise, the Session-Reflector MUST use the Source 676 IPv6 Address sub-TLV and MUST copy the value of the source IP address 677 from the received packet into the IPv6 Address field. 679 The Location TLV MAY be used to determine the last-hop IP addresses, 680 ports, and last-hop MAC address for STAMP packets. The MAC address 681 can indicate a path switch on the last hop. The IP addresses and UDP 682 ports will indicate if there is a NAT router on the path. It allows 683 the Session-Sender to identify the IP address of the Session- 684 Reflector behind the NAT, and detect changes in the NAT mapping that 685 could cause sending the STAMP packets to the wrong Session-Reflector. 687 4.3. Timestamp Information TLV 689 The STAMP Session-Sender MAY include the Timestamp Information TLV to 690 request information from the Session-Reflector. The Session-Sender 691 MUST NOT fill any information fields except for STAMP TLV Flags, 692 Type, and Length. All other fields MUST be filled with zeroes. The 693 Session-Reflector MUST validate the Length value of the TLV. If the 694 value of the Length field is invalid, the Session-Reflector follows 695 the procedure defined in Section 4 for a malformed TLV. 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 |STAMP TLV Flags|Times Info Type| Length | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 ~ Optional sub-TLVs ~ 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 11: Timestamp Information TLV 709 where fields are defined as the following: 711 o STAMP TLV Flags - is an eight-bit-long field. Its format is 712 presented in Figure 6. 714 o Timestamp Information Type - is a one-octet-long field, value TBA3 715 allocated by IANA Section 5.1. 717 o Length - two-octet-long field, set equal to the length of the 718 Value field in octets (Figure 5). 720 o Sync Src In - one-octet-long field that characterizes the source 721 of clock synchronization at the ingress of a Session-Reflector. 722 There are several methods to synchronize the clock, e.g., Network 723 Time Protocol (NTP) [RFC5905]. The value is one of those listed 724 in Table 7. 726 o Timestamp In - one-octet-long field that characterizes the method 727 by which the ingress of the Session-Reflector obtained the 728 timestamp T2. A timestamp may be obtained with hardware 729 assistance, via software API from a local wall clock, or from a 730 remote clock (the latter is referred to as "control plane"). The 731 value is one of those listed in Table 9. 733 o Sync Src Out - one-octet-long field that characterizes the source 734 of clock synchronization at the egress of the Session-Reflector. 735 The value is one of those listed in Table 7. 737 o Timestamp Out - one-octet-long field that characterizes the method 738 by which the egress of the Session-Reflector obtained the 739 timestamp T3. The value is one of those listed in Table 9. 741 o Optional sub-TLVs - optional variable-length field. 743 4.4. Class of Service TLV 745 The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in 746 the STAMP test packet. The format of the CoS TLV is presented in 747 Figure 12. 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |STAMP TLV Flags| CoS Type | Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | DSCP1 | DSCP2 |ECN| RP| Reserved | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 Figure 12: Class of Service TLV 759 where fields are defined as the following: 761 o STAMP TLV Flags - is an eight-bit-long field. Its format is 762 presented in Figure 6. 764 o CoS (Class of Service) Type - is a one-octet-long field, value 765 TBA4 allocated by IANA Section 5.1. 767 o Length - two-octet-long field, set equal to the value 4. 769 o DSCP1 - The Differentiated Services Code Point (DSCP) intended by 770 the Session-Sender to be used as the DSCP value of the reflected 771 test packet. 773 o DSCP2 - The received value in the DSCP field at the ingress of the 774 Session-Reflector. 776 o ECN - The received value in the ECN field at the ingress of the 777 Session-Reflector. 779 o RP (Reverse Path) - is a two-bit-long field. A Session-Sender 780 MUST set the value of the RP field to 0 on transmission. 782 o Reserved - 16-bit-long field, MUST be zeroed on transmission and 783 ignored on receipt. 785 A STAMP Session-Reflector that receives a test packet with the CoS 786 TLV MUST include the CoS TLV in the reflected test packet. Also, the 787 Session-Reflector MUST copy the value of the DSCP and ECN fields of 788 the IP header of the received STAMP test packet into the DSCP2 field 789 in the reflected test packet. Finally, the Session-Reflector MUST 790 use the local policy to verify whether the CoS corresponding to the 791 value of the DSCP1 field is permitted in the domain. If it is, the 792 Session-Reflectorset MUST set the DSCP field's value in the IP header 793 of the reflected test packet equal to the value of the DSCP1 field of 794 the received test packet. Otherwise, the Session-Reflector MUST use 795 the DSCP value of the received STAMP packet and set the value of the 796 RP field to 1. Upon receiving the reflected packet, if the value of 797 the RP field is 0, the Session-Sender will save the DSCP and ECN 798 values for analysis of the CoS in the reverse direction. If the 799 value of the RP field in the received reflected packet is 1, only CoS 800 in the forward direction can be analyzed. 802 Re-mapping of CoS can be used to provide multiple services (e,g., 2G, 803 3G, LTE in mobile backhaul networks) over the same network. But if 804 it is misconfigured, then it is often difficult to diagnose the root 805 cause of excessive packet drops of higher-level service while packet 806 drops for lower service packets are at a normal level. Using a CoS 807 TLV in STAMP testing helps to troubleshoot the existing problem and 808 also verify whether DiffServ policies are processing CoS as required 809 by the configuration. 811 4.5. Direct Measurement TLV 813 The Direct Measurement TLV enables collection of the number of in- 814 profile packets, i.e., packets that form a specific data flow, that 815 had been transmitted and received by the Session-Sender and Session- 816 Reflector, respectively. The definition of "in-profile packet" is 817 outside the scope of this document and is left to the test operators 818 to determine. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 |STAMP TLV Flags| Direct Type | Length | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Session-Sender Tx counter (S_TxC) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Session-Reflector Rx counter (R_RxC) | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Session-Reflector Tx counter (R_TxC) | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Figure 13: Direct Measurement TLV 834 where fields are defined as the following: 836 o STAMP TLV Flags - is an eight-bit-long field. Its format is 837 presented in Figure 6. 839 o Direct (Measurement) Type - is a one-octet-long field, value TBA5 840 allocated by IANA Section 5.1. 842 o Length - two-octet-long field equals the length of the Value field 843 in octets. The Length field value MUST equal 12 octets. 845 o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The 846 Session-Sender MUST set its value equal to the number of the 847 transmitted in-profile packets. 849 o Session-Reflector Rx counter (R_RxC) is a four-octet-long field. 850 MUST be zeroed by the Session-Sender on transmit and ignored by 851 the Session-Reflector on receipt. The Session-Reflector MUST fill 852 it with the value of in-profile packets received. 854 o Session-Reflector Tx counter (R_TxC) is a four-octet-long field. 855 MUST be zeroed by the Session-Sender and ignored by the Session- 856 Reflector on receipt. The Session-Reflector MUST fill it with the 857 value of the transmitted in-profile packets. 859 A Session-Sender MAY include the Direct Measurement TLV in a STAMP 860 test packet. If the received STAMP test packet includes the Direct 861 Measurement TLV, the Session-Reflector MUST include it in the 862 reflected test packet. The Session-Reflector MUST copy the value 863 from the S_TxC field of the received test packet into the same field 864 of the reflected packet before its transmission. 866 4.6. Access Report TLV 868 A STAMP Session-Sender MAY include an Access Report TLV (Figure 14) 869 to indicate changes to the access network status to the Session- 870 Reflector. The definition of an access network is outside the scope 871 of this document. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 |STAMP TLV Flags|Acc Report Type| Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | ID | Resv | Return Code | Reserved | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 14: Access Report TLV 883 where fields are defined as follows: 885 o STAMP TLV Flags - is an eight-bit-long field. Its format 886 presented in Figure 6. 888 o Access Report Type - is a one-octet-long field, value TBA6 889 allocated by IANA Section 5.1. 891 o Length - two-octet-long field, set equal to the value 4. 893 o ID (Access ID) - four-bit-long field that identifies the access 894 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 895 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 896 The value is one of those listed below: 898 * 1 - 3GPP Network 900 * 2 - Non-3GPP Network 902 All other values are invalid and the TLV that contains it MUST be 903 discarded. 905 o Resv - four-bit-long field, MUST be zeroed on transmission and 906 ignored on receipt. 908 o Return Code - one-octet-long field that identifies the report 909 signal, e.g., available or unavailable. The value is supplied to 910 the STAMP end-point through some mechanism that is outside the 911 scope of this document. The value is one of those listed in 912 Section 5.6. 914 o Reserved - two-octet-long field, MUST be zeroed on transmission 915 and ignored on receipt. 917 The STAMP Session-Sender that includes the Access Report TLV sets the 918 value of the Access ID field according to the type of access network 919 it reports on. Also, the Session-Sender sets the value of the Return 920 Code field to reflect the operational state of the access network. 921 The mechanism to determine the state of the access network is outside 922 the scope of this specification. A STAMP Session-Reflector that 923 received the test packet with the Access Report TLV MUST include the 924 Access Report TLV in the reflected test packet. The Session- 925 Reflector MUST set the value of the Access ID and Return Code fields 926 equal to the values of the corresponding fields from the test packet 927 it has received. 929 The Session-Sender MUST also arm a retransmission timer after sending 930 a test packet that includes the Access Report TLV. This timer MUST 931 be disarmed upon reception of the reflected STAMP test packet that 932 includes the Access Report TLV. In the event the timer expires 933 before such a packet is received, the Session-Sender MUST retransmit 934 the STAMP test packet that contains the Access Report TLV. This 935 retransmission SHOULD be repeated up to four times before the 936 procedure is aborted. Setting the value for the retransmission timer 937 is based on local policies and network environment. The default 938 value of the retransmission timer for the Access Report TLV SHOULD be 939 three seconds. An implementation MUST provide control of the 940 retransmission timer value and the number of retransmissions. 942 The Access Report TLV is used by the Performance Measurement Function 943 (PMF) components of the Access Steering, Switching and Splitting 944 feature for 5G networks [TS23501]. The PMF component in the User 945 Equipment acts as the STAMP Session-Sender, and the PMF component in 946 the User Plane Function acts as the STAMP Session-Reflector. 948 4.7. Follow-up Telemetry TLV 950 A Session-Reflector might be able to put in the Timestamp field only 951 an "SW Local" (see Table 9) timestamp. But the hosting system might 952 provide a timestamp closer to the start of the actual packet 953 transmission even though it is not possible to deliver the 954 information to the Session-Sender in time for the packet itself. 955 This timestamp might nevertheless be important for the Session- 956 Sender, as it improves the accuracy of measuring network delay by 957 minimizing the impact of egress queuing delays on the measurement. 959 A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to 960 request information from the Session-Reflector. The Session-Sender 961 MUST set the Follow-up Telemetry Type and Length fields to their 962 appropriate values. The Sequence Number and Timestamp fields MUST be 963 zeroed on transmission by the Session-Sender and ignored by the 964 Session-Reflector upon receipt of the STAMP test packet that includes 965 the Follow-up Telemetry TLV. The Session-Reflector MUST validate the 966 Length value of the STAMP test packet. If the value of the Length 967 field is invalid, the Session-Reflector MUST zero the Sequence Number 968 and Timestamp fields and set the M flag in the STAMP TLV Flags field 969 in the reflected packet. If the Session-Reflector is in stateless 970 mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence 971 Number and Timestamp fields. 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 |STAMP TLV Flags| Follow-up Type| Length | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Sequence Number | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Follow-up Timestamp | 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Timestamp M | Reserved | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 15: Follow-up Telemetry TLV 988 where fields are defined as follows: 990 o STAMP TLV Flags - is an eight-bit-long field. Its format 991 presented in Figure 6. 993 o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 994 allocated by IANA Section 5.1. 996 o Length - two-octet-long field, set equal to the value 16 octets. 998 o Sequence Number - four-octet-long field indicating the sequence 999 number of the last packet reflected in the same STAMP-test 1000 session. Since the Session-Reflector runs in the stateful mode 1001 (defined in Section 4.2 [RFC8762]), it is the Session-Reflector's 1002 Sequence Number of the previous reflected packet. 1004 o Follow-up Timestamp - eight-octet-long field, with the format 1005 indicated by the Z flag of the Error Estimate field of the STAMP 1006 base packet, which is contained in this reflected test packet 1007 transmitted by a Session-Reflector, as described in Section 4.2.1 1008 [RFC8762]. It carries the timestamp when the reflected packet 1009 with the specified sequence number was sent. 1011 o Timestamp M(ode) - one-octet-long field that characterizes the 1012 method by which the entity that transmits a reflected STAMP packet 1013 obtained the Follow-up Timestamp. The value is one of those 1014 listed in Table 9. 1016 o Reserved - three-octet-long field. Its value MUST be zeroed on 1017 transmission and ignored on receipt. 1019 4.8. HMAC TLV 1021 The STAMP authenticated mode protects the integrity of data collected 1022 in the STAMP base packet. STAMP extensions are designed to provide 1023 valuable information about the condition of a network, and protecting 1024 the integrity of that data is also essential. All authenticated 1025 STAMP base packets (per Section 4.2.2 and Section 4.3.2 [RFC8762]) 1026 compatible with this specification MUST additionally authenticate the 1027 option TLVs by including the keyed Hashed Message Authentication Code 1028 (HMAC) TLV, with the sole exception of when there is only one TLV 1029 present, and it is the Extended Padding TLV. The HMAC TLV MUST 1030 follow all TLVs included in a STAMP test packet, except for the Extra 1031 Padding TLV. If the HMAC TLV appears in any other position in a 1032 STAMP extended test packet, then the situation MUST be processed as 1033 HMAC verification failure, as defined in this section, further below. 1034 The HMAC TLV MAY be used to protect the integrity of STAMP extensions 1035 in STAMP unauthenticated mode. An implementation of STAMP extensions 1036 MUST provide controls to enable the integrity protection of STAMP 1037 extensions in STAMP unauthenticated mode. 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |STAMP TLV Flags| HMAC Type | Length | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | | 1045 | HMAC | 1046 | | 1047 | | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Figure 16: HMAC TLV 1052 where fields are defined as follows: 1054 o STAMP TLV Flags - is an eight-bit-long field. Its format is 1055 presented in Figure 6. 1057 o HMAC Type - is a one-octet-long field, value TBA8 allocated by 1058 IANA Section 5.1. 1060 o Length - two-octet-long field, set equal to 16 octets. 1062 o HMAC - is a 16-octet-long field that carries HMAC digest of the 1063 text of all preceding TLVs. 1065 As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 1066 bits ([RFC4868]). All considerations regarding using the key listed 1067 in Section 4.4 of [RFC8762] are fully applicable to the use of the 1068 HMAC TLV. Key management and the mechanisms to distribute the HMAC 1069 key are outside the scope of this specification. HMAC TLV is 1070 anticipated to track updates in the base STAMP protocol [RFC8762], 1071 including the use of more advanced cryptographic algorithms. HMAC is 1072 calculated as defined in [RFC2104] over text as the concatenation of 1073 the Sequence Number field of the base STAMP packet and all preceding 1074 TLVs. The digest then MUST be truncated to 128 bits and written into 1075 the HMAC field. If the HMAC TLV is present in the extended STAMP 1076 test packet, e.g., in the authenticated mode, HMAC MUST be verified 1077 before using any data in the included STAMP TLVs. If HMAC 1078 verification by the Session-Reflector fails, then the Session- 1079 Reflector MUST stop processing the received extended STAMP test 1080 packet. The Session-Reflector MUST copy the TLVs from the received 1081 STAMP test packet into the reflected packet. The Session-Reflector 1082 MUST set the I flag in each TLV copied over into the reflected packet 1083 to 1 before transmitting the reflected test packet. If the Session- 1084 Sender receives the extended STAMP test packet with I flag set to 1, 1085 then the Session-Sender MUST stop processing TLVs in the reflected 1086 test packet. If HMAC verification by the Session-Sender fails, then 1087 the Session-Sender MUST stop processing TLVs in the reflected 1088 extended STAMP packet. 1090 5. IANA Considerations 1092 5.1. STAMP TLV Registry 1094 IANA is requested to create the STAMP TLV Type registry. All code 1095 points in the range 1 through 175 in this registry shall be allocated 1096 according to the "IETF Review" procedure as specified in [RFC8126]. 1097 Code points in the range 176 through 239 in this registry shall be 1098 allocated according to the "First Come First Served" procedure as 1099 specified in [RFC8126]. The remaining code points are allocated 1100 according to Table 1: 1102 +-----------+--------------+---------------+ 1103 | Value | Description | Reference | 1104 +-----------+--------------+---------------+ 1105 | 0 | Reserved | This document | 1106 | 1- 175 | Unassigned | This document | 1107 | 176 - 239 | Unassigned | This document | 1108 | 240 - 251 | Experimental | This document | 1109 | 252 - 254 | Private Use | This document | 1110 | 255 | Reserved | This document | 1111 +-----------+--------------+---------------+ 1113 Table 1: STAMP TLV Type Registry 1115 This document defines the following new values in the IETF Review 1116 range of the STAMP TLV Type registry: 1118 +-------+-----------------------+---------------+ 1119 | Value | Description | Reference | 1120 +-------+-----------------------+---------------+ 1121 | TBA1 | Extra Padding | This document | 1122 | TBA2 | Location | This document | 1123 | TBA3 | Timestamp Information | This document | 1124 | TBA4 | Class of Service | This document | 1125 | TBA5 | Direct Measurement | This document | 1126 | TBA6 | Access Report | This document | 1127 | TBA7 | Follow-up Telemetry | This document | 1128 | TBA8 | HMAC | This document | 1129 +-------+-----------------------+---------------+ 1131 Table 2: STAMP TLV Types 1133 5.2. STAMP TLV Flags Sub-registry 1135 IANA is requested to create the STAMP TLV Flags sub-registry as part 1136 of the STAMP TLV Type registry. The registration procedure is "IETF 1137 Review" [RFC8126]. Flags are 8 bits. This document defines the 1138 following bit positions in the STAMP TLV Flags sub-registry: 1140 +--------------+--------+------------------------+---------------+ 1141 | Bit position | Symbol | Description | Reference | 1142 +--------------+--------+------------------------+---------------+ 1143 | 0 | U | Unrecognized TLV | This document | 1144 | 1 | M | Malformed TLV | This document | 1145 | 2 | I | Integrity check failed | This document | 1146 +--------------+--------+------------------------+---------------+ 1148 Table 3: STAMP TLV Flags 1150 5.3. Sub-TLV Type Sub-registry 1152 IANA is requested to create the sub-TLV Type sub-registry as part of 1153 the STAMP TLV Type registry. All code points in the range 1 through 1154 175 in this registry shall be allocated according to the "IETF 1155 Review" procedure as specified in [RFC8126]. Code points in the 1156 range 176 through 239 in this registry shall be allocated according 1157 to the "First Come First Served" procedure as specified in [RFC8126]. 1158 The remaining code points are allocated according to Table 4: 1160 +-----------+--------------+---------------+ 1161 | Value | Description | Reference | 1162 +-----------+--------------+---------------+ 1163 | 0 | Reserved | This document | 1164 | 1- 175 | Unassigned | This document | 1165 | 176 - 239 | Unassigned | This document | 1166 | 240 - 251 | Experimental | This document | 1167 | 252 - 254 | Private Use | This document | 1168 | 255 | Reserved | This document | 1169 +-----------+--------------+---------------+ 1171 Table 4: Location Sub-TLV Type Sub-registry 1173 This document defines the following new values in the IETF Review 1174 range of the Location sub-TLV Type sub-registry: 1176 +-------+--------------------------+----------+---------------+ 1177 | Value | Description | TLV Used | Reference | 1178 +-------+--------------------------+----------+---------------+ 1179 | TBA9 | Source MAC Address | Location | This document | 1180 | TBA10 | Source EUI-48 Address | Location | This document | 1181 | TBA11 | Source EUI-64 Address | Location | This document | 1182 | TBA12 | Destination IP Address | Location | This document | 1183 | TBA13 | Destination IPv4 Address | Location | This document | 1184 | TBA14 | Destination IPv6 Address | Location | This document | 1185 | TBA15 | Source IP Address | Location | This document | 1186 | TBA16 | Source IPv4 Address | Location | This document | 1187 | TBA17 | Source IPv6 Address | Location | This document | 1188 +-------+--------------------------+----------+---------------+ 1190 Table 5: STAMP sub-TLV Types 1192 5.4. Synchronization Source Sub-registry 1194 IANA is requested to create the Synchronization Source sub-registry 1195 as part of the STAMP TLV Type registry. All code points in the range 1196 1 through 127 in this registry shall be allocated according to the 1197 "IETF Review" procedure as specified in [RFC8126]. Code points in 1198 the range 128 through 239 in this registry shall be allocated 1199 according to the "First Come First Served" procedure as specified in 1200 [RFC8126]. Remaining code points are allocated according to Table 6: 1202 +-----------+--------------+---------------+ 1203 | Value | Description | Reference | 1204 +-----------+--------------+---------------+ 1205 | 0 | Reserved | This document | 1206 | 1- 127 | Unassigned | This document | 1207 | 128 - 239 | Unassigned | This document | 1208 | 240 - 249 | Experimental | This document | 1209 | 250 - 254 | Private Use | This document | 1210 | 255 | Reserved | This document | 1211 +-----------+--------------+---------------+ 1213 Table 6: Synchronization Source Sub-registry 1215 This document defines the following new values in the Synchronization 1216 Source sub-registry: 1218 +-------+---------------------------------+---------------+ 1219 | Value | Description | Reference | 1220 +-------+---------------------------------+---------------+ 1221 | 1 | NTP | This document | 1222 | 2 | PTP | This document | 1223 | 3 | SSU/BITS | This document | 1224 | 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | This document | 1225 | 5 | Local free-running | This document | 1226 +-------+---------------------------------+---------------+ 1228 Table 7: Synchronization Sources 1230 5.5. Timestamping Method Sub-registry 1232 IANA is requested to create the Timestamping Method sub-registry as 1233 part of the STAMP TLV Type registry. All code points in the range 1 1234 through 127 in this registry shall be allocated according to the 1235 "IETF Review" procedure as specified in [RFC8126]. Code points in 1236 the range 128 through 239 in this registry shall be allocated 1237 according to the "First Come First Served" procedure as specified in 1238 [RFC8126]. Remaining code points are allocated according to Table 8: 1240 +-----------+--------------+---------------+ 1241 | Value | Description | Reference | 1242 +-----------+--------------+---------------+ 1243 | 0 | Reserved | This document | 1244 | 1- 127 | Unassigned | This document | 1245 | 128 - 239 | Unassigned | This document | 1246 | 240 - 249 | Experimental | This document | 1247 | 250 - 254 | Private Use | This document | 1248 | 255 | Reserved | This document | 1249 +-----------+--------------+---------------+ 1251 Table 8: Timestamping Method Sub-registry 1253 This document defines the following new values in the Timestamping 1254 Methods sub-registry: 1256 +-------+---------------+---------------+ 1257 | Value | Description | Reference | 1258 +-------+---------------+---------------+ 1259 | 1 | HW Assist | This document | 1260 | 2 | SW local | This document | 1261 | 3 | Control plane | This document | 1262 +-------+---------------+---------------+ 1264 Table 9: Timestamping Methods 1266 5.6. Return Code Sub-registry 1268 IANA is requested to create the Return Code sub-registry as part of 1269 the STAMP TLV Type registry. All code points in the range 1 through 1270 127 in this registry shall be allocated according to the "IETF 1271 Review" procedure as specified in [RFC8126]. Code points in the 1272 range 128 through 239 in this registry shall be allocated according 1273 to the "First Come First Served" procedure as specified in [RFC8126]. 1274 Remaining code points are allocated according to Table 10: 1276 +-----------+--------------+---------------+ 1277 | Value | Description | Reference | 1278 +-----------+--------------+---------------+ 1279 | 0 | Reserved | This document | 1280 | 1- 127 | Unassigned | This document | 1281 | 128 - 239 | Unassigned | This document | 1282 | 240 - 249 | Experimental | This document | 1283 | 250 - 254 | Private Use | This document | 1284 | 255 | Reserved | This document | 1285 +-----------+--------------+---------------+ 1287 Table 10: Return Code Sub-registry 1289 This document defines the following new values in the Return Code 1290 sub-registry: 1292 +-------+---------------------+---------------+ 1293 | Value | Description | Reference | 1294 +-------+---------------------+---------------+ 1295 | 1 | Network available | This document | 1296 | 2 | Network unavailable | This document | 1297 +-------+---------------------+---------------+ 1299 Table 11: Return Codes 1301 6. Security Considerations 1303 This document defines extensions to STAMP [RFC8762] and inherits all 1304 the security considerations applicable to the base protocol. 1305 Additionally, the HMAC TLV is defined in this document. Though the 1306 HMAC TLV protects the integrity of STAMP extensions; it does not 1307 protect against a replay attack. The use of HMAC TLV is discussed in 1308 detail in Section 4.8. 1310 To protect against a malformed TLV an implementation of a Session- 1311 Sender and Session-Reflector MUST: 1313 o check the setting of the M flag; 1315 o validate the Length field value. 1317 As this specification defined the mechanism to test DSCP mapping, 1318 this document inherits all the security considerations discussed in 1319 [RFC2474]. Monitoring and optional control of DSCP using the CoS TLV 1320 may be used across the Internet so that the Session-Sender and the 1321 Session-Reflector are located in domains that use different CoS 1322 profiles. Thus, it is essential that an operator verifies the set of 1323 CoS values that are used in the Session-Reflector's domain. Also, an 1324 implementation of a Session-Reflector SHOULD support a local policy 1325 to confirm whether the value sent by the Session-Sender can be used 1326 as the value of the DSCP field. Section 4.4 defines the use of that 1327 local policy. 1329 7. Acknowledgments 1331 Authors much appreciate the thorough review and thoughtful comments 1332 received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali 1333 Wang. The authors express their gratitude to Al Morton for his 1334 comments and the most valuable suggestions. The authors greatly 1335 appreciate comments and thoughtful suggestions received from Martin 1336 Duke. 1338 8. Contributors 1340 The following people contributed text to this document: 1342 Guo Jun 1343 ZTE Corporation 1344 68# Zijinghua Road 1345 Nanjing, Jiangsu 210012 1346 P.R.China 1348 Phone: +86 18105183663 1349 Email: guo.jun2@zte.com.cn 1351 9. References 1353 9.1. Normative References 1355 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1356 Hashing for Message Authentication", RFC 2104, 1357 DOI 10.17487/RFC2104, February 1997, 1358 . 1360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1361 Requirement Levels", BCP 14, RFC 2119, 1362 DOI 10.17487/RFC2119, March 1997, 1363 . 1365 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1366 Writing an IANA Considerations Section in RFCs", BCP 26, 1367 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1368 . 1370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1372 May 2017, . 1374 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1375 Two-Way Active Measurement Protocol", RFC 8762, 1376 DOI 10.17487/RFC8762, March 2020, 1377 . 1379 9.2. Informative References 1381 [GPS] "Global Positioning System (GPS) Standard Positioning 1382 Service (SPS) Performance Standard", GPS SPS 5th Edition, 1383 April 2020. 1385 [I-D.gont-numeric-ids-generation] 1386 Gont, F. and I. Arce, "On the Generation of Transient 1387 Numeric Identifiers", draft-gont-numeric-ids-generation-04 1388 (work in progress), July 2019. 1390 [IEEE.1588.2008] 1391 "Standard for a Precision Clock Synchronization Protocol 1392 for Networked Measurement and Control Systems", 1393 IEEE Standard 1588, March 2008. 1395 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1396 "Definition of the Differentiated Services Field (DS 1397 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1398 DOI 10.17487/RFC2474, December 1998, 1399 . 1401 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1402 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1403 DOI 10.17487/RFC4868, May 2007, 1404 . 1406 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1407 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1408 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1409 . 1411 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1412 "Network Time Protocol Version 4: Protocol and Algorithms 1413 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1414 . 1416 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 1417 Specification Group Services and System Aspects; System 1418 Architecture for the 5G System; Stage 2 (Release 16)", 1419 3GPP TS23501, 2019. 1421 Authors' Addresses 1423 Greg Mirsky 1424 ZTE Corp. 1426 Email: gregimirsky@gmail.com 1428 Xiao Min 1429 ZTE Corp. 1431 Email: xiao.min2@zte.com.cn 1432 Henrik Nydell 1433 Accedian Networks 1435 Email: hnydell@accedian.com 1437 Richard Foote 1438 Nokia 1440 Email: footer.foote@nokia.com 1442 Adi Masputra 1443 Apple Inc. 1444 One Apple Park Way 1445 Cupertino, CA 95014 1446 USA 1448 Email: adi@apple.com 1450 Ernesto Ruffini 1451 OutSys 1452 via Caracciolo, 65 1453 Milano 20155 1454 Italy 1456 Email: eruffini@outsys.org