idnits 2.17.1 draft-ietf-ippm-stamp-option-tlv-07.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 (July 8, 2020) is 1388 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23501' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: January 9, 2021 Accedian Networks 7 R. Foote 8 Nokia 9 A. Masputra 10 Apple Inc. 11 E. Ruffini 12 OutSys 13 July 8, 2020 15 Simple Two-way Active Measurement Protocol Optional Extensions 16 draft-ietf-ippm-stamp-option-tlv-07 18 Abstract 20 This document describes optional extensions to Simple Two-way Active 21 Measurement Protocol (STAMP) that enable measurement of performance 22 metrics, in addition to ones supported by the STAMP base 23 specification. The document also defines a STAMP Test Session 24 Identifier and thus updates RFC 8762. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4 65 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8 66 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11 67 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 11 68 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 13 69 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 14 70 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 15 71 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 17 72 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 18 73 4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 20 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 75 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 21 76 5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 22 77 5.3. Synchronization Source Sub-registry . . . . . . . . . . . 22 78 5.4. Timestamping Method Sub-registry . . . . . . . . . . . . 23 79 5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 24 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 85 9.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] supports 91 the use of optional extensions that use Type-Length-Value (TLV) 92 encoding. Such extensions enhance the STAMP base functions, such as 93 measurement of one-way and round-trip delay, latency, packet loss, 94 packet duplication, and out-of-order delivery of test packets. This 95 specification defines optional STAMP extensions, their formats, and 96 the theory of operation. Also, a STAMP Test Session Identifier is 97 defined as an update of the base STAMP specification [RFC8762]. 99 2. Conventions Used in This Document 101 2.1. Acronyms 103 BDS BeiDou Navigation Satellite System 105 BITS Building Integrated Timing Supply 107 CoS Class of Service 109 DSCP Differentiated Services Code Point 111 ECN Explicit Congestion Notification 113 GLONASS Global Orbiting Navigation Satellite System 115 GPS Global Positioning System [GPS] 117 HMAC Hashed Message Authentication Code 119 LORAN-C Long Range Navigation System Version C 121 MBZ Must Be Zero 123 NTP Network Time Protocol [RFC5905] 125 PMF Performance Measurement Function 127 PTP Precision Time Protocol [IEEE.1588.2008] 129 TLV Type-Length-Value 131 SSID STAMP Session Identifier 133 SSU Synchronization Supply Unit 135 STAMP Simple Two-way Active Measurement Protocol 137 2.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. STAMP Test Session Identifier 147 The STAMP Session-Sender transmits test packets to the STAMP Session- 148 Reflector. The STAMP Session-Reflector receives the Session-Sender's 149 packet and acts according to the configuration and optional control 150 information communicated in the Session-Sender's test packet. STAMP 151 defines two different test packet formats, one for packets 152 transmitted by the STAMP Session-Sender and one for packets 153 transmitted by the STAMP Session-Reflector. STAMP supports two 154 modes: unauthenticated and authenticated. Unauthenticated STAMP test 155 packets are compatible on the wire with unauthenticated TWAMP-Test 156 [RFC5357] packets. 158 By default, STAMP uses symmetrical packets, i.e., the size of the 159 packet transmitted by the Session-Reflector equals the size of the 160 packet received by the Session-Reflector. 162 A STAMP Session is identified by the 4-tuple (source and destination 163 IP addresses, source and destination UDP port numbers). A STAMP 164 Session-Sender MAY generate a locally unique STAMP Session Identifier 165 (SSID). SSID is a two-octet-long non-zero unsigned integer. A 166 Session-Sender MAY use SSID to identify a STAMP test session. If 167 SSID is used, it MUST be present in each test packet of the given 168 test session. In the unauthenticated mode, SSID is located as 169 displayed in Figure 1. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Sequence Number | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Timestamp | 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Error Estimate | SSID | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 | | 183 | MBZ (28 octets) | 184 | | 185 | | 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 ~ TLVs ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: An example of an extended STAMP Session-Sender test packet 193 format in unauthenticated mode 195 An implementation of the STAMP Session-Reflector that supports this 196 specification SHOULD identify a STAMP Session using the SSID in 197 combination with elements of the usual 4-tuple for the session. 198 Before a test session commences, a Session-Reflector MUST be 199 provisioned with all the elements that identify the STAMP Session. A 200 STAMP Session-Reflector MUST discard non-matching STAMP test 201 packet(s). The means of provisioning the STAMP Session 202 identification is outside the scope of this specification. A 203 conforming implementation of STAMP Session-Reflector MUST copy the 204 SSID value from the received test packet and put it into the 205 reflected packet, as displayed in Figure 2. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Sequence Number | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Timestamp | 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Error Estimate | SSID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Receive Timestamp | 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Session-Sender Sequence Number | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Session-Sender Timestamp | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Session-Sender Error Estimate | MBZ | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |Ses-Sender TTL | MBZ | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ TLVs ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: An example of an extended STAMP Session-Reflector test 233 packet format in unauthenticated mode 235 A STAMP Session-Reflector that does not support this specification 236 will return the zeroed SSID field in the reflected STAMP test packet. 237 The Session-Sender MAY stop the session if it receives a zeroed SSID 238 field. An implementation of a Session-Sender MUST support control of 239 its behavior in such a scenario. If the test session is not stopped, 240 the Session-Sender, can, for example, send a base STAMP packet 241 [RFC8762]. 243 Location of the SSID field in the authenticated mode is shown in 244 Figure 3 and Figure 4. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Sequence Number | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 | MBZ (12 octets) | 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Timestamp | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Error Estimate | SSID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ ~ 261 | MBZ (68 octets) | 262 ~ ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 | HMAC (16 octets) | 266 | | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Base STAMP Session-Sender test packet format in 271 authenticated mode 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Sequence Number | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | MBZ (12 octets) | 279 | | 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Timestamp | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Error Estimate | SSID | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | MBZ (4 octets) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Receive Timestamp | 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | MBZ (8 octets) | 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Session-Sender Sequence Number | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | MBZ (12 octets) | 298 | | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Session-Sender Timestamp | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Session-Sender Error Estimate | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 306 | MBZ (6 octets) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |Ses-Sender TTL | | 309 +-+-+-+-+-+-+-+-+ + 310 | | 311 | MBZ (15 octets) | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | HMAC (16 octets) | 315 | | 316 | | 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 4: Base STAMP Session-Reflector test packet format in 321 authenticated mode 323 4. TLV Extensions to STAMP 325 The Type-Length-Value (TLV) encoding scheme provides a flexible 326 extension mechanism for optional informational elements. TLV is an 327 optional field in the STAMP test packet. Multiple TLVs MAY be placed 328 in a STAMP test packet. A TLV MAY be enclosed in a TLV. TLVs have a 329 one-octet-long STAMP TLV Flags field, one-octet-long Type field, and 330 two-octet-long Length field that is equal to the length of the Value 331 field in octets. If a Type value for TLV or sub-TLV is in the range 332 for Vendor Private Use, the Length MUST be at least 4, and the first 333 four octets MUST be that vendor's the Structure of Management 334 Information (SMI) Private Enterprise Code, as recorded in IANA's SMI 335 Private Enterprise Codes sub-registry, in network octet order. The 336 rest of the Value field is private to the vendor. The following 337 sections describe the use of TLVs for STAMP that extend STAMP 338 capability beyond its base specification. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |STAMP TLV Flags| Type | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ~ Value ~ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 5: TLV Format in a STAMP Extended Packet 350 where fields are defined as the following: 352 o STAMP TLV Flags - eight-bit-long field. Detailed format and 353 interpretation of flags defined in this specification is below. 355 o Type - one-octet-long field that characterizes the interpretation 356 of the Value field. It is allocated by IANA, as specified in 357 Section 5.1. 359 o Length - two-octet-long field equal to the length of the Value 360 field in octets. 362 o Value - a variable-length field. Its interpretation and encoding 363 is determined by the value of the Type field. 365 The format of the STAMP TLV Flags displayed in Figure 6 and the 366 location of flags is according to Section 5.2. 368 0 1 2 3 4 5 6 7 369 +-+-+-+-+-+-+-+-+ 370 |U|L|A|R|R|R|R|R| 371 +-+-+-+-+-+-+-+-+ 373 Figure 6: STAMP TLV Flags Format 375 where fields are defined as the following: 377 o U - a one-bit flag. A Session-Sender MUST set the U flag to 0 378 before transmitting an extended STAMP test packet. A Session- 379 Reflector MUST set the U flag to 1 if the Session-Reflector has 380 not understood the TLV. 382 o L - a one-bit flag. A Session-Sender MUST set the L flag to 0 383 before transmitting an extended STAMP test packet. A Session- 384 Reflector MUST set the L flag to 1 if the Session-Reflector 385 determined the TLV is malformed, i.e., the Length field value of 386 the fixed-size TLV is not equal to the value defined for the 387 particular type, or the remaining length of the extended STAMP 388 packet is less than the size of the TLV. 390 o A - a one-bit flag. A Session-Sender MUST set the A flag to 0 391 before transmitting an extended STAMP test packet. A Session- 392 Reflector MUST set the A flag to 1 if the STAMP extensions have 393 failed HMAC verification (Section 4.8). 395 o R - reserved flags for future use. These flags MUST be zeroed on 396 transmit and ignored on receipt. 398 A STAMP node, whether Session-Sender or Session-Reflector, receiving 399 a test packet MUST determine whether the packet is a base STAMP 400 packet or includes one or more TLVs. The node MUST compare the value 401 in the Length field of the UDP header and the length of the base 402 STAMP test packet in the mode, unauthenticated or authenticated based 403 on the configuration of the particular STAMP test session. If the 404 difference between the two values is larger than the length of the 405 UDP header, then the test packet includes one or more STAMP TLVs that 406 immediately follow the base STAMP test packet. A Session-Reflector 407 that does not support STAMP extensions is not expected to compare the 408 value in the Length field of the UDP header and the length of the 409 STAMP base packet. Hence the Session-Reflector will transmit the 410 base STAMP packet. It is the local policy on the Session-Sender 411 (similar to the handling of SSID == 0 scenario described in 412 Section 3) that will control the sender's behavior. 414 A system that has received a STAMP test packet with extension TLVs 415 MUST validate each TLV: 417 If the U flag is set, the STAMP system MUST skip the processing of 418 the TLV. The implementation MUST try to process the next TLV if 419 present in the extended STAMP packet. 421 If the L flag is set, the STAMP system MUST stop processing the 422 remainder of the extended STAMP packet. 424 If the A flag is set, the STAMP system MUST discard all TLVs and 425 MUST stop processing the remainder of the extended STAMP packet. 427 If an implementation of a Session-Reflector does not recognize the 428 Type field value, it MUST include a copy of the TLV into the 429 reflected STAMP packet. The Session-Reflector MUST set the U flag 430 to 1. The Session-Reflector MUST try to process the next TLV in 431 the extended STAMP packet. 433 If a TLV is malformed, the processing of extension TLVs MUST be 434 stopped. The Session-Reflector MUST copy the remainder of the 435 received extended STAMP packet into the reflected STAMP packet. 436 The Session-Reflector MUST set the L flag to 1. 438 Detected error events MUST be logged. Note that rate of logging MUST 439 be controlled. 441 4.1. Extra Padding TLV 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |STAMP TLV Flags|Extra Pad Type | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 ~ Extra Padding ~ 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 7: Extra Padding TLV 455 where fields are defined as the following: 457 o STAMP TLV Flags - is an eight-bit-long field. Its format is 458 presented in Figure 6. 460 o Extra Padding Type - is a one-octet-long field, value TBA1 461 allocated by IANA Section 5.1. 463 o Length - two-octet-long field equal to the length of the Extra 464 Padding field in octets. 466 o Extra Padding - a pseudo-random sequence of bits. The field MAY 467 be filled with all zeros. 469 The Extra Padding TLV is similar to the Packet Padding field in a 470 TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is 471 RECOMMENDED to perform a STAMP test using test packets of larger size 472 than the base STAMP packet [RFC8762]. The length of the base STAMP 473 packet is 44 octets in the unauthenticated mode or 112 octets in the 474 authenticated mode. The Extra Padding TLV MAY be present more than 475 one time in an extended STAMP test packet. 477 4.2. Location TLV 479 STAMP Session-Senders MAY include the Location TLV to request 480 information from the Session-Reflector. The Session-Sender SHOULD 481 NOT fill any information fields except for STAMP TLV Flags, Type, and 482 Length. The Session-Reflector MUST validate the Length value against 483 the address family of the transport encapsulating the STAMP test 484 packet. If the Length field's value is invalid, the Session- 485 Reflector MUST zero all fields and MUST NOT return any information to 486 the Session-Sender. The Session-Reflector MUST ignore all other 487 fields of the received Location TLV. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |STAMP TLV Flags| Location Type | Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Source MAC | 495 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ Destination IP Address ~ 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 ~ Source IP Address ~ 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Destination Port | Source Port | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 8: Session-Reflector Location TLV 507 where fields are defined as the following: 509 o STAMP TLV Flags - is an eight-bit-long field. Its format is 510 presented in Figure 6. 512 o Location Type - is a one-octet-long field, value TBA2 allocated by 513 IANA Section 5.1. 515 o Length - two-octet-long field equal to the length of the Value 516 field in octets. The Length field value MUST equal 20 octets for 517 the IPv4 address family. For the IPv6 address family, the value 518 of the Length field MUST equal 44 octets. All other values are 519 invalid. 521 o Source MAC - 6-octet-long field. The Session-Reflector MUST copy 522 the Source MAC of the received STAMP packet into this field. 524 o Reserved - two-octet-long field. MUST be zeroed on transmission 525 and ignored on reception. 527 o Destination IP Address - IPv4 or IPv6 destination address of the 528 packet received by the STAMP Session-Reflector. 530 o Source IP Address - IPv4 or IPv6 source address of the packet 531 received by the STAMP Session-Reflector. 533 o Destination Port - two-octet-long UDP destination port number of 534 the received STAMP packet. 536 o Source Port - two-octet-long UDP source port number of the 537 received STAMP packet. 539 The Location TLV MAY be used to determine the last-hop IP addresses, 540 ports, and last-hop MAC address for STAMP packets. The MAC address 541 can indicate a path switch on the last hop. The IP addresses and UDP 542 ports will indicate if there is a NAT router on the path. It allows 543 the Session-Sender to identify the IP address of the Session- 544 Reflector behind the NAT, and detect changes in the NAT mapping that 545 could cause sending the STAMP packets to the wrong Session-Reflector. 547 4.3. Timestamp Information TLV 549 The STAMP Session-Sender MAY include the Timestamp Information TLV to 550 request information from the Session-Reflector. The Session-Sender 551 SHOULD NOT fill any information fields except for STAMP TLV Flags, 552 Type, and Length. The Session-Reflector MUST validate the Length 553 value of the TLV. If the value of the Length field is invalid, the 554 Session-Reflector MUST zero all fields and MUST NOT return any 555 information to the Session-Sender. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |STAMP TLV Flags|Times Info Type| Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 9: Timestamp Information TLV 567 where fields are defined as the following: 569 o STAMP TLV Flags - is an eight-bit-long field. Its format is 570 presented in Figure 6. 572 o Timestamp Information Type - is a one-octet-long field, value TBA3 573 allocated by IANA Section 5.1. 575 o Length - two-octet-long field, set equal to the value 4. 577 o Sync Src In - one-octet-long field that characterizes the source 578 of clock synchronization at the ingress of a Session-Reflector. 579 There are several methods to synchronize the clock, e.g., Network 580 Time Protocol (NTP) [RFC5905]. The value is one of those listed 581 in Table 5. 583 o Timestamp In - one-octet-long field that characterizes the method 584 by which the ingress of the Session-Reflector obtained the 585 timestamp T2. A timestamp may be obtained with hardware 586 assistance, via software API from a local wall clock, or from a 587 remote clock (the latter is referred to as "control plane"). The 588 value is one of those listed in Table 7. 590 o Sync Src Out - one-octet-long field that characterizes the source 591 of clock synchronization at the egress of the Session-Reflector. 592 The value is one of those listed in Table 5. 594 o Timestamp Out - one-octet-long field that characterizes the method 595 by which the egress of the Session-Reflector obtained the 596 timestamp T3. The value is one of those listed in Table 7. 598 4.4. Class of Service TLV 600 The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in 601 the STAMP test packet. The format of the CoS TLV is presented in 602 Figure 10. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |STAMP TLV Flags| CoS Type | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | DSCP1 | DSCP2 |ECN| Reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure 10: Class of Service TLV 614 where fields are defined as the following: 616 o STAMP TLV Flags - is an eight-bit-long field. Its format is 617 presented in Figure 6. 619 o CoS (Class of Service) Type - is a one-octet-long field, value 620 TBA4 allocated by IANA Section 5.1. 622 o Length - two-octet-long field, set equal to the value 4. 624 o DSCP1 - The Differentiated Services Code Point (DSCP) intended by 625 the Session-Sender to be used as the DSCP value of the reflected 626 test packet. 628 o DSCP2 - The received value in the DSCP field at the Session- 629 Reflector in the forward direction. 631 o ECN - The received value in the ECN field at the Session-Reflector 632 in the forward direction. 634 o Reserved - 18-bit-long field, MUST be zeroed on transmission and 635 ignored on receipt. 637 A STAMP Session-Reflector that receives a test packet with the CoS 638 TLV MUST include the CoS TLV in the reflected test packet. Also, the 639 Session-Reflector MUST copy the value of the DSCP and ECN fields of 640 the IP header of the received STAMP test packet into the DSCP2 field 641 in the reflected test packet. Finally, the Session-Reflector MUST 642 set the DSCP field's value in the IP header of the reflected test 643 packet equal to the value of the DSCP1 field of the received test 644 packet. Upon receiving the reflected packet, the Session-Sender will 645 save the DSCP and ECN values for analysis of the CoS in the reverse 646 direction. 648 Re-mapping of CoS can be used to provide multiple services (e,g., 2G, 649 3G, LTE in mobile backhaul networks) over the same network. But if 650 it is misconfigured, then it is often difficult to diagnose the root 651 cause of excessive packet drops of higher-level service while packet 652 drops for lower service packets are at a normal level. Using a CoS 653 TLV in STAMP testing helps to troubleshoot the existing problem and 654 also verify whether DiffServ policies are processing CoS as required 655 by the configuration. 657 4.5. Direct Measurement TLV 659 The Direct Measurement TLV enables collection of the number of in- 660 profile packets that had been transmitted and received by the 661 Session-Sender and Session-Reflector, respectively. The definition 662 of "in-profile packet" is outside the scope of this document and is 663 left to the test operators to determine. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |STAMP TLV Flags| Direct Type | Length | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Session-Sender Tx counter (S_TxC) | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Session-Reflector Rx counter (R_RxC) | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Session-Reflector Tx counter (R_TxC) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 11: Direct Measurement TLV 679 where fields are defined as the following: 681 o STAMP TLV Flags - is an eight-bit-long field. Its format is 682 presented in Figure 6. 684 o Direct (Measurement) Type - is a one-octet-long field, value TBA5 685 allocated by IANA Section 5.1. 687 o Length - two-octet-long field equals length of the Value field in 688 octets. The Length field value MUST equal 12 octets. 690 o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The 691 Session-Sender MUST set its value equal to the number of the 692 transmitted in-profile packets. 694 o Session-Reflector Rx counter (R_RxC) is a four-octet-long field. 695 MUST be zeroed by the Session-Sender on transmit and ignored by 696 the Session-Reflector on receipt. The Session-Reflector MUST fill 697 it with the value of in-profile packets received. 699 o Session-Reflector Tx counter (R_TxC) is a four-octet-long field. 700 MUST be zeroed by the Session-Sender and ignored by the Session- 701 Reflector on receipt. The Session-Reflector MUST fill it with the 702 value of the transmitted in-profile packets. 704 A Session-Sender MAY include the Direct Measurement TLV in a STAMP 705 test packet. The Session-Sender MUST zero the R_RxC and R_TxC fields 706 before the transmission of the STAMP test packet. If the received 707 STAMP test packet includes the Direct Measurement TLV, the Session- 708 Reflector MUST include it in the reflected test packet. The Session- 709 Reflector MUST copy the value from the S_TxC field of the received 710 test packet into the same field of the reflected packet before its 711 transmission. 713 4.6. Access Report TLV 715 A STAMP Session-Sender MAY include an Access Report TLV (Figure 12) 716 to indicate changes to the access network status to the Session- 717 Reflector. The definition of an access network is outside the scope 718 of this document. 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 |STAMP TLV Flags|Acc Report Type| Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | ID | Resv | Return Code | Reserved | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Figure 12: Access Report TLV 730 where fields are defined as follows: 732 o STAMP TLV Flags - is an eight-bit-long field. Its format 733 presented in Figure 6. 735 o Access Report Type - is a one-octet-long field, value TBA6 736 allocated by IANA Section 5.1. 738 o Length - two-octet-long field, set equal to the value 4. 740 o ID (Access ID) - four-bit-long field that identifies the access 741 network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) 742 or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. 743 The value is one of those listed below: 745 * 1 - 3GPP Network 747 * 2 - Non-3GPP Network 749 All other values are invalid and the TLV that contains it MUST be 750 discarded. 752 o Resv - four-bit-long field, MUST be zeroed on transmission and 753 ignored on receipt. 755 o Return Code - one-octet-long field that identifies the report 756 signal, e.g., available or unavailable. The value is supplied to 757 the STAMP end-point through some mechanism that is outside the 758 scope of this document. The value is one of those listed in 759 Section 5.5. 761 o Reserved - two-octet-long field, MUST be zeroed on transmission 762 and ignored on receipt. 764 The STAMP Session-Sender that includes the Access Report TLV sets the 765 value of the Access ID field according to the type of access network 766 it reports on. Also, the Session-Sender sets the value of the Return 767 Code field to reflect the operational state of the access network. 768 The mechanism to determine the state of the access network is outside 769 the scope of this specification. A STAMP Session-Reflector that 770 received the test packet with the Access Report TLV MUST include the 771 Access Report TLV in the reflected test packet. The Session- 772 Reflector MUST set the value of the Access ID and Return Code fields 773 equal to the values of the corresponding fields from the test packet 774 it has received. 776 The Session-Sender MUST also arm a retransmission timer after sending 777 a test packet that includes the Access Report TLV. This timer MUST 778 be disarmed upon reception of the reflected STAMP test packet that 779 includes the Access Report TLV. In the event the timer expires 780 before such a packet is received, the Session-Sender MUST retransmit 781 the STAMP test packet that contains the Access Report TLV. This 782 retransmission SHOULD be repeated up to four times before the 783 procedure is aborted. Setting the value for the retransmission timer 784 is based on local policies and network environment. The default 785 value of the retransmission timer for the Access Report TLV SHOULD be 786 three seconds. An implementation MUST provide control of the 787 retransmission timer value and the number of retransmissions. 789 The Access Report TLV is used by the Performance Measurement Function 790 (PMF) components of the Access Steering, Switching and Splitting 791 feature for 5G networks [TS23501]. The PMF component in the User 792 Equipment acts as the STAMP Session-Sender, and the PMF component in 793 the User Plane Function acts as the STAMP Session-Reflector. 795 4.7. Follow-up Telemetry TLV 797 A Session-Reflector might be able to put in the Timestamp field only 798 an "SW Local" (see Table 7) timestamp. But the hosting system might 799 provide a timestamp closer to the start of the actual packet 800 transmission even though it is not possible to deliver the 801 information to the Session-Sender in time for the packet itself. 802 This timestamp might nevertheless be important for the Session- 803 Sender, as it improves the accuracy of measuring network delay by 804 minimizing the impact of egress queuing delays on the measurement. 806 A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to 807 request information from the Session-Reflector. The Session-Sender 808 MUST set the Follow-up Telemetry Type and Length fields to their 809 appropriate values. The Sequence Number and Timestamp fields MUST be 810 zeroed on transmission by the Session-Sender and ignored by the 811 Session-Reflector upon receipt of the STAMP test packet that includes 812 the Follow-up Telemetry TLV. The Session-Reflector MUST validate the 813 Length value of the STAMP test packet. If the value of the Length 814 field is invalid, the Session-Reflector MUST zero the Sequence Number 815 and Timestamp fields and set the L flag in the STAMP TLV Flags field 816 in the reflected packet. If the Session-Reflector is in stateless 817 mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence 818 Number and Timestamp fields. 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| Follow-up Type| Length | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Sequence Number | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Follow-up Timestamp | 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Timestamp M | Reserved | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 13: Follow-up Telemetry TLV 835 where fields are defined as follows: 837 o STAMP TLV Flags - is an eight-bit-long field. Its format 838 presented in Figure 6. 840 o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 841 allocated by IANA Section 5.1. 843 o Length - two-octet-long field, set equal to the value 16 octets. 845 o Sequence Number - four-octet-long field indicating the sequence 846 number of the last packet reflected in the same STAMP-test 847 session. Since the Session-Reflector runs in the stateful mode 848 (defined in Section 4.2 [RFC8762]), it is the Session-Reflector's 849 Sequence Number of the previous reflected packet. 851 o Follow-up Timestamp - eight-octet-long field, with the format 852 indicated by the Z flag of the Error Estimate field of the packet 853 transmitted by a Session-Reflector, as described in Section 4.1 854 [RFC8762]. It carries the timestamp when the reflected packet 855 with the specified sequence number was sent. 857 o Timestamp M(ode) - one-octet-long field that characterizes the 858 method by which the entity that transmits a reflected STAMP packet 859 obtained the Follow-up Timestamp. The value is one of those 860 listed in Table 7. 862 o Reserved - three-octet-long field. Its value MUST be zeroed on 863 transmission and ignored on receipt. 865 4.8. HMAC TLV 867 The STAMP authenticated mode protects the integrity of data collected 868 in the STAMP base packet. STAMP extensions are designed to provide 869 valuable information about the condition of a network, and protecting 870 the integrity of that data is also essential. The keyed Hashed 871 Message Authentication Code (HMAC) TLV MUST be included in a STAMP 872 test packet in the authenticated mode, excluding when the only TLV 873 present is Extra Padding TLV. The HMAC TLV MUST follow all TLVs 874 included in a STAMP test packet, except for the Extra Padding TLV. 875 The HMAC TLV MAY be used to protect the integrity of STAMP extensions 876 in STAMP unauthenticated mode. 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 |STAMP TLV Flags| HMAC Type | Length | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | | 884 | HMAC | 885 | | 886 | | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Figure 14: HMAC TLV 891 where fields are defined as follows: 893 o STAMP TLV Flags - is an eight-bit-long field. Its format is 894 presented in Figure 6. 896 o HMAC Type - is a one-octet-long field, value TBA8 allocated by 897 IANA Section 5.1. 899 o Length - two-octet-long field, set equal to 16 octets. 901 o HMAC - is a 16-octet-long field that carries HMAC digest of the 902 text of all preceding TLVs. 904 As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 905 bits ([RFC4868]). All considerations regarding using the key and key 906 distribution and management listed in Section 4.4 of [RFC8762] are 907 fully applicable to the use of the HMAC TLV. HMAC is calculated as 908 defined in [RFC2104] over text as the concatenation of all preceding 909 TLVs. The digest then MUST be truncated to 128 bits and written into 910 the HMAC field. In the authenticated mode, HMAC MUST be verified 911 before using any data in the included STAMP TLVs. If HMAC 912 verification by the Session-Reflector fails, then the Session- 913 Reflector MUST stop processing the received extended STAMP test 914 packet. The Session-Reflector MUST copy the remainder of the 915 extended STAMP test packet into the reflected packet. The Session- 916 Reflector MUST set the A flag in the copy of the HMAC TLV in the 917 reflected packet to 1 before transmitting the reflected test packet. 918 Also, both the Session-Sender and Session-Reflector SHOULD log the 919 notification that HMAC verification of STAMP TLVs failed. 921 5. IANA Considerations 923 5.1. STAMP TLV Registry 925 IANA is requested to create the STAMP TLV Type registry. All code 926 points in the range 1 through 175 in this registry shall be allocated 927 according to the "IETF Review" procedure as specified in [RFC8126]. 928 Code points in the range 176 through 239 in this registry shall be 929 allocated according to the "First Come First Served" procedure as 930 specified in [RFC8126]. The remaining code points are allocated 931 according to Table 1: 933 +-----------+--------------+-------------------------+ 934 | Value | Description | Reference | 935 +-----------+--------------+-------------------------+ 936 | 0 | Reserved | This document | 937 | 1- 175 | Unassigned | IETF Review | 938 | 176 - 239 | Unassigned | First Come First Served | 939 | 240 - 251 | Experimental | This document | 940 | 252 - 254 | Private Use | This document | 941 | 255 | Reserved | This document | 942 +-----------+--------------+-------------------------+ 944 Table 1: STAMP TLV Type Registry 946 This document defines the following new values in the STAMP Extension 947 TLV range of the STAMP TLV Type registry: 949 +-------+-----------------------+---------------+ 950 | Value | Description | Reference | 951 +-------+-----------------------+---------------+ 952 | TBA1 | Extra Padding | This document | 953 | TBA2 | Location | This document | 954 | TBA3 | Timestamp Information | This document | 955 | TBA4 | Class of Service | This document | 956 | TBA5 | Direct Measurement | This document | 957 | TBA6 | Access Report | This document | 958 | TBA7 | Follow-up Telemetry | This document | 959 | TBA8 | HMAC | This document | 960 +-------+-----------------------+---------------+ 962 Table 2: STAMP Types 964 5.2. STAMP TLV Flags Sub-registry 966 IANA is requested to create the STAMP TLV Flags sub-registry as part 967 of the STAMP TLV Type registry. The registration procedure is "IETF 968 Review" [RFC8126]. Flags are 8 bits. This document defines the 969 following bit positions in the STAMP TLV Flags sub-registry: 971 +--------------+--------+-----------------------+---------------+ 972 | Bit position | Symbol | Description | Reference | 973 +--------------+--------+-----------------------+---------------+ 974 | 0 | U | Unrecognized TLV | This document | 975 | 1 | L | Malformed TLV | This document | 976 | 2 | A | Authentication failed | This document | 977 +--------------+--------+-----------------------+---------------+ 979 Table 3: STAMP TLV Flags 981 5.3. Synchronization Source Sub-registry 983 IANA is requested to create the Synchronization Source sub-registry 984 as part of the STAMP TLV Type registry. All code points in the range 985 1 through 127 in this registry shall be allocated according to the 986 "IETF Review" procedure as specified in [RFC8126]. Code points in 987 the range 128 through 239 in this registry shall be allocated 988 according to the "First Come First Served" procedure as specified in 989 [RFC8126]. Remaining code points are allocated according to Table 4: 991 +-----------+--------------+-------------------------+ 992 | Value | Description | Reference | 993 +-----------+--------------+-------------------------+ 994 | 0 | Reserved | This document | 995 | 1- 127 | Unassigned | IETF Review | 996 | 128 - 239 | Unassigned | First Come First Served | 997 | 240 - 249 | Experimental | This document | 998 | 250 - 254 | Private Use | This document | 999 | 255 | Reserved | This document | 1000 +-----------+--------------+-------------------------+ 1002 Table 4: Synchronization Source Sub-registry 1004 This document defines the following new values in the Synchronization 1005 Source sub-registry: 1007 +-------+-------------------------+---------------+ 1008 | Value | Description | Reference | 1009 +-------+-------------------------+---------------+ 1010 | 1 | NTP | This document | 1011 | 2 | PTP | This document | 1012 | 3 | SSU/BITS | This document | 1013 | 4 | GPS/GLONASS/LORAN-C/BDS | This document | 1014 | 5 | Local free-running | This document | 1015 +-------+-------------------------+---------------+ 1017 Table 5: Synchronization Sources 1019 5.4. Timestamping Method Sub-registry 1021 IANA is requested to create the Timestamping Method sub-registry as 1022 part of the STAMP TLV Type registry. All code points in the range 1 1023 through 127 in this registry shall be allocated according to the 1024 "IETF Review" procedure as specified in [RFC8126]. Code points in 1025 the range 128 through 239 in this registry shall be allocated 1026 according to the "First Come First Served" procedure as specified in 1027 [RFC8126]. Remaining code points are allocated according to Table 6: 1029 +-----------+--------------+-------------------------+ 1030 | Value | Description | Reference | 1031 +-----------+--------------+-------------------------+ 1032 | 0 | Reserved | This document | 1033 | 1- 127 | Unassigned | IETF Review | 1034 | 128 - 239 | Unassigned | First Come First Served | 1035 | 240 - 249 | Experimental | This document | 1036 | 250 - 254 | Private Use | This document | 1037 | 255 | Reserved | This document | 1038 +-----------+--------------+-------------------------+ 1040 Table 6: Timestamping Method Sub-registry 1042 This document defines the following new values in the Timestamping 1043 Methods sub-registry: 1045 +-------+---------------+---------------+ 1046 | Value | Description | Reference | 1047 +-------+---------------+---------------+ 1048 | 1 | HW Assist | This document | 1049 | 2 | SW local | This document | 1050 | 3 | Control plane | This document | 1051 +-------+---------------+---------------+ 1053 Table 7: Timestamping Methods 1055 5.5. Return Code Sub-registry 1057 IANA is requested to create the Return Code sub-registry as part of 1058 the STAMP TLV Type registry. All code points in the range 1 through 1059 127 in this registry shall be allocated according to the "IETF 1060 Review" procedure as specified in [RFC8126]. Code points in the 1061 range 128 through 239 in this registry shall be allocated according 1062 to the "First Come First Served" procedure as specified in [RFC8126]. 1063 Remaining code points are allocated according to Table 8: 1065 +-----------+--------------+-------------------------+ 1066 | Value | Description | Reference | 1067 +-----------+--------------+-------------------------+ 1068 | 0 | Reserved | This document | 1069 | 1- 127 | Unassigned | IETF Review | 1070 | 128 - 239 | Unassigned | First Come First Served | 1071 | 240 - 249 | Experimental | This document | 1072 | 250 - 254 | Private Use | This document | 1073 | 255 | Reserved | This document | 1074 +-----------+--------------+-------------------------+ 1076 Table 8: Return Code Sub-registry 1078 This document defines the following new values in the Return Code 1079 sub-registry: 1081 +-------+---------------------+---------------+ 1082 | Value | Description | Reference | 1083 +-------+---------------------+---------------+ 1084 | 1 | Network available | This document | 1085 | 2 | Network unavailable | This document | 1086 +-------+---------------------+---------------+ 1088 Table 9: Return Codes 1090 6. Security Considerations 1092 This document defines extensions to STAMP [RFC8762] and inherits all 1093 the security considerations applicable to the base protocol. 1094 Additionally, the HMAC TLV is defined in this document to protect the 1095 integrity of optional STAMP extensions. The use of HMAC TLV is 1096 discussed in detail in Section 4.8. 1098 7. Acknowledgments 1100 Authors much appreciate the thorough review and thoughtful comments 1101 received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali 1102 Wang. The authors express their gratitude to Al Morton for his 1103 comments and the most valuable suggestions. The authors greatly 1104 appreciate comments and thoughtful suggestions received from Martin 1105 Duke. 1107 8. Contributors 1109 The following people contributed text to this document: 1111 Guo Jun 1112 ZTE Corporation 1113 68# Zijinghua Road 1114 Nanjing, Jiangsu 210012 1115 P.R.China 1117 Phone: +86 18105183663 1118 Email: guo.jun2@zte.com.cn 1120 9. References 1121 9.1. Normative References 1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1124 Requirement Levels", BCP 14, RFC 2119, 1125 DOI 10.17487/RFC2119, March 1997, 1126 . 1128 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1129 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1130 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1131 . 1133 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1134 Writing an IANA Considerations Section in RFCs", BCP 26, 1135 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1136 . 1138 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1139 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1140 May 2017, . 1142 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 1143 Two-Way Active Measurement Protocol", RFC 8762, 1144 DOI 10.17487/RFC8762, March 2020, 1145 . 1147 [TS23501] 3GPP (3rd Generation Partnership Project), "Technical 1148 Specification Group Services and System Aspects; System 1149 Architecture for the 5G System; Stage 2 (Release 16)", 1150 3GPP TS23501, 2019. 1152 9.2. Informative References 1154 [GPS] "Global Positioning System (GPS) Standard Positioning 1155 Service (SPS) Performance Standard", GPS SPS 5th Edition, 1156 April 2020. 1158 [IEEE.1588.2008] 1159 "Standard for a Precision Clock Synchronization Protocol 1160 for Networked Measurement and Control Systems", 1161 IEEE Standard 1588, March 2008. 1163 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1164 Hashing for Message Authentication", RFC 2104, 1165 DOI 10.17487/RFC2104, February 1997, 1166 . 1168 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1169 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1170 DOI 10.17487/RFC4868, May 2007, 1171 . 1173 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1174 "Network Time Protocol Version 4: Protocol and Algorithms 1175 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1176 . 1178 Authors' Addresses 1180 Greg Mirsky 1181 ZTE Corp. 1183 Email: gregimirsky@gmail.com 1185 Xiao Min 1186 ZTE Corp. 1188 Email: xiao.min2@zte.com.cn 1190 Henrik Nydell 1191 Accedian Networks 1193 Email: hnydell@accedian.com 1195 Richard Foote 1196 Nokia 1198 Email: footer.foote@nokia.com 1200 Adi Masputra 1201 Apple Inc. 1202 One Apple Park Way 1203 Cupertino, CA 95014 1204 USA 1206 Email: adi@apple.com 1207 Ernesto Ruffini 1208 OutSys 1209 via Caracciolo, 65 1210 Milano 20155 1211 Italy 1213 Email: eruffini@outsys.org