idnits 2.17.1 draft-ietf-ippm-stamp-00.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 (January 4, 2018) is 2294 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. 'IEEE.1588.2008' 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 ZTE Corp. 4 Intended status: Standards Track G. Jun 5 Expires: July 8, 2018 ZTE Corporation 6 H. Nydell 7 Accedian Networks 8 January 4, 2018 10 Simple Two-way Active Measurement Protocol 11 draft-ietf-ippm-stamp-00 13 Abstract 15 This document describes a Two-way Active Measurement Protocol which 16 enables measurement of both one-way and round-trip performance 17 metrics like delay, delay variation and packet loss. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 8, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 2 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Softwarization of Performance Measurement . . . . . . . . . . 3 58 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Sender Behavior and Packet Format . . . . . . . . . . . . 4 60 4.1.1. Sender Packet Format in Unauthenticated Mode . . . . 4 61 4.1.2. Sender Packet Format in Authenticated and Encrypted 62 Modes . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Reflector Behavior and Packet Format . . . . . . . . . . 7 64 4.2.1. Reflector Packet Format in Unauthenticated Mode . . . 7 65 4.2.2. Reflector Packet Format in Authenticated and 66 Encrypted Modes . . . . . . . . . . . . . . . . . . . 8 67 5. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 9 68 5.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 10 69 5.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 12 71 5.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 13 74 6.2. Synchronization Source Sub-registry . . . . . . . . . . . 14 75 6.3. Timestamp Method Sub-registry . . . . . . . . . . . . . . 14 76 6.4. CoS Operation Sub-registry . . . . . . . . . . . . . . . 14 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 2. Conventions used in this document 86 2.1. Terminology 88 STAMP - Simple Two-way Active Measurement Protocol 90 NTP - Network Time Protocol 92 PTP - Precision Time Protocol 94 2.2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Softwarization of Performance Measurement 104 Instance of a Simple Two-way Active Measurement Protocol (STAMP) 105 session between a Sender and a Reflector controlled by communication 106 between a Configuration Client as a manager and Configuration Servers 107 as agents of the configuration session that configures STAMP 108 measurement between Sender and Reflector. The Configuration Client 109 also issues queries to obtain operational state information and/or 110 measurement results. 112 o----------------------------------------------------------o 113 | Config client | 114 o----------------------------------------------------------o 115 || || 116 || NETCONF/RESTCONF || 117 || || 118 o-------------------o o-------------------o 119 | Config server | | Config server | 120 | | | | 121 +-------------------+ +-------------------+ 122 | STAMP Sender | <--- STAMP---> | STAMP Reflector | 123 +-------------------+ +-------------------+ 125 Figure 1: STAMP Reference Model 127 4. Theory of Operation 129 STAMP Sender transmits test packets toward STAMP Reflector. STAMP 130 Reflector receives Sender's packet and acts according to the 131 configuration and optional control information communicated in the 132 Sender's test packet. STAMP defines two different test packet 133 formats, one for packets transmitted by the STAMP-Sender and one for 134 packets transmitted by the STAMP-Reflector. STAMP supports three 135 modes: unauthenticated, authenticated, and encrypted. 136 Unauthenticated STAMP test packets are compatible on the wire with 137 unauthenticated TWAMP-Test [RFC5357] packet formats. 139 By default STAMP uses symmetrical packets, i.e. size of the packet 140 transmitted by Reflector equals to the size of the packet received by 141 the Reflector. 143 4.1. Sender Behavior and Packet Format 145 4.1.1. Sender Packet Format in Unauthenticated Mode 147 Because STAMP supports symmetrical test packets, STAMP Sender packet 148 has minimum size of 44 octets in unauthenticated mode, see Figure 2, 149 and 48 octets in authenticated or encrypted modes , see Figure 4. 151 For unauthenticated mode: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Sequence Number | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Timestamp | 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Error Estimate | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 163 | | 164 | | 165 | MBZ (27 octets) | 166 | | 167 | | 168 | | 169 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | Server Octets | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 172 | Remaining Packet Padding (to be reflected) | 173 ~ (length in octets specified in command) ~ 174 + +-+-+-+-+-+-+-+-+ 175 | | Comp.MBZ | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type | Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 ~ Value ~ 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: STAMP Sender test packet format in unauthenticated mode 184 where fields are defined as the following: 186 o Sequence Number is four octets long field. For each new session 187 its value starts at zero and is incremented with each transmitted 188 packet. 190 o Timestamp is eight octets long field. STAMP node MUST support 191 Network Time Protocol (NTP) version 4 64-bit timestamp format 192 [RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time 193 Protocol truncated 64-bit timestamp format [IEEE.1588.2008]. 195 o Error Estimate is two octets long field with format displayed in 196 Figure 3 198 0 1 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |S|Z| Scale | Multiplier | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 3: Error Estimate Format 206 where S, Scale and Multiplier fields are interpreted as they have 207 been defined in section 4.1.2 [RFC4656]; and Z field - as has been 208 defined in section 2.3 [RFC8186]: 210 * 0 - NTP 64 bit format of a timestamp; 212 * 1 - PTPv2 truncated format of a timestamp. 214 o Must-be-Zero (MBZ) field in the sender unauthenticated packet is 215 27 octets long. It MUST be all zeroed on transmission and ignored 216 on receipt. 218 o Server Octets field is two octets long field. It MUST follow the 219 27 octets long MBZ field. The Reflect Octets capability defined 220 in [RFC6038]. The value in the Server Octets field equals to the 221 number of octets the Reflector is expected to copy back to the 222 Sender starting with the Server Octets field. Thus the minimal 223 non-zero value for the Server Octets field is two and value of one 224 is invalid. If none of Payload to be copied the value of the 225 Server Octets field MUST be set to zero on transmit. 227 o Remaining Packet Padding is optional field of variable length. 228 The number of octets in the Remaining Packet Padding field is the 229 value of the Server Octets field less the length of the Server 230 Octets field. 232 o Comp.MBZ is variable length field used to achieve alignment on 233 word boundary. Thus the length of Comp.MBZ field may be only 0, 234 1, 2 or 3 octets. The value of the field MUST be zeroed on 235 transmission and ignored on receipt. 237 The unauthenticated STAMP Sender packet MAY include Type-Length-Value 238 encodings that immediately follow the Comp. MBZ field. 240 o Type field is two octets long. The value of the Type field is the 241 codepoint allocated by IANA Section 6 that identifies data in the 242 Value field. 244 o Length is two octets long field and its value is the length of the 245 Value field in octets. 247 4.1.2. Sender Packet Format in Authenticated and Encrypted Modes 249 For authenticated and encrypted modes: 251 0 1 2 3 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Sequence Number | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 | MBZ (12 octets) | 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Timestamp | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Error Estimate | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 265 | MBZ (6 octets) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | HMAC (16 octets) | 269 | | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ~ Value ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 4: STAMP Sender test packet format in authenticated or 278 encrypted modes 280 4.2. Reflector Behavior and Packet Format 282 The Reflector receives the STAMP test packet, verifies it, prepares 283 and transmits the reflected test packet. [Editor note: Verification 284 may include presence and content of TLVs in the STAMP test packet.] 286 4.2.1. Reflector Packet Format in Unauthenticated Mode 288 For unauthenticated mode: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Sequence Number | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Timestamp | 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Error Estimate | MBZ | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Receive Timestamp | 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Sender Sequence Number | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Sender Timestamp | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Sender Error Estimate | MBZ | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Sender TTL | | 311 +-+-+-+-+-+-+-+-+ + 312 | | 313 ~ Packet Padding (reflected) ~ 314 + +-+-+-+-+-+-+-+-+ 315 | | Comp.MBZ | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 ~ Value ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 5: STAMP Reflector test packet format in unauthenticated mode 324 where fields are defined as the following: 326 o Sequence Number is four octets long field. The value of the 327 Sequence Number field is set according to the mode of the STAMP 328 Reflector: 330 * in the stateless mode the Reflector copies the value from the 331 received STAMP test packet's Sequence Number field; 333 * in the stateful mode the Reflector counts the received STAMP 334 test packets in each test session and uses that counter to set 335 value of the Sequence Number field. 337 o Timestamp and Receiver Timestamp fields are each 8 octets long. 338 The format of these fields, NTP or PTPv2, indicated by the Z flag 339 of the Error Estimate field as described in Section 4.1. 341 o Error Estimate has the same size and interpretation as described 342 in Section 4.1. 344 o Sender Sequence Number, Sender Timestamp, and Sender Error 345 Estimate are copies of the corresponding fields in the STAMP test 346 packet send by the Sender. 348 o Sender TTL is one octet long field and its value is the copy of 349 the TTL field from the received STAMP test packet. 351 o Packet Padding (reflected) is optional variable length field. The 352 length of the Packet Padding (reflected) field MUST be equal to 353 the value of the Server Octets field (Figure 2). If the value is 354 non-zero, the Reflector copies octets starting with the Server 355 Octets field. 357 o Comp.MBZ is variable length field used to achieve alignment on 358 word boundary. Thus the length of Comp.MBZ field may be only 0, 359 1, 2 or 3 octets. The value of the field MUST be zeroed on 360 transmission and ignored on receipt. 362 4.2.2. Reflector Packet Format in Authenticated and Encrypted Modes 364 For authenticated and encrypted modes: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Sequence Number | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | MBZ (12 octets) | 372 | | 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Timestamp | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Error Estimate | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 380 | MBZ (6 octets) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Receive Timestamp | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | MBZ (8 octets) | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Sender Sequence Number | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | MBZ (12 octets) | 391 | | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Sender Timestamp | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Sender Error Estimate | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 399 | MBZ (6 octets) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Sender TTL | | 402 +-+-+-+-+-+-+-+-+ + 403 | | 404 | | 405 | MBZ (15 octets) | 406 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 407 | HMAC (16 octets) | 408 | | 409 | | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 413 Figure 6: STAMP Reflector test packet format in authenticated or 414 encrypted modes 416 5. TLV Extensions to STAMP 418 TBA 420 5.1. Extra Padding TLV 422 TBA 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Extra Padding Type | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 ~ Extra Padding ~ 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 7: Extra Padding TLV 436 where fields are defined as the following: 438 o Extra Padding Type - TBA1 allocated by IANA Section 6.1 440 o Length - 2 octets long field equals length on the Extra Padding 441 field in octets. 443 o Extra Padding - pseudo-random sequence of numbers. The field MAY 444 be filled with all zeroes. 446 5.2. Location TLV 448 STAMP sender MAY include the Location TLV to request information from 449 the reflector. The sender SHOULD NOT fill any information fields 450 except for Type and Length. The reflector MUST validate the Length 451 value against address family of the transport encapsulating the STAMP 452 test packet. If the value of the Length field is invalid, the 453 reflector MUST zero all fields and MUST NOT return any information to 454 the sender. The reflector MUST ignore all other fields of the 455 received Location TLV. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Location Type | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Source MAC | 463 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | MBZ | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 ~ Destination IP Address ~ 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 ~ Source IP Address ~ 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Dest.port | Src.Port | MBZ | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 8: Reflector Location TLV 475 where fields are defined as the following: 477 o Location Type - TBA1 allocated by IANA Section 6.1 479 o Length - 2 octets long field equals length on the Value field in 480 octets. Length field value MUST be 20 octets for IPv4 address 481 family. For IPv6 address family value of the Length field MUST be 482 44 octets. All other values are invalid 484 o Source MAC - 6 octets 48 bits long field. The reflector MUST copy 485 Source MAC of received STAMP packet into this field. 487 o MBZ - two octets long field. MUST be zeroed on transmission and 488 ignored on reception. 490 o Destination IP Address - IPv4 or IPv6 destination address of the 491 received by the reflector STAMP packet. 493 o Source IP Address - IPv4 or IPv6 source address of the received by 494 the reflector STAMP packet. 496 o Dest.port - one octet long UDP destination port number of the 497 received STAMP packet. 499 o Src.port - one octet long UDP source port number of the received 500 STAMP packet. 502 5.3. Timestamp Information TLV 504 STAMP sender MAY include the Timestamp Information TLV to request 505 information from the reflector. The sender SHOULD NOT fill any 506 information fields except for Type and Length. The reflector MUST 507 validate the Length value of the STAMP test packet. If the value of 508 the Length field is invalid, the reflector MUST zero all fields and 509 MUST NOT return any information to the sender. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Timestamp Information Type | Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Synchronization Source | Timestamp Method | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 9: Timestamp Information TLV 521 where fields are defined as the following: 523 o Timestamp Information Type - TBA1 allocated by IANA Section 6.1 525 o Length - 2 octets long field, equals 4 octets. 527 o Synchronization Source - two octets long field that characterizes 528 the source of clock synchronization at the reflector. The value 529 is one of Section 6.2. 531 o Timestamp Method - two octets long field that characterizes 532 timestamping method at the reflector. The value is one of 533 Section 6.3. [Ed.note: Should it be split for ingress and 534 egress?] 536 5.4. Class of Service TLV 538 The STAMP sender MAY include Class of Service TLV in the STAMP test 539 packet. If the Class of Service TLV is present in the STAMP test 540 packet and the value of the Op field equals Report (TBA5) value 541 Section 6.4, then the STAMP reflector MUST copy DSCP and ECN values 542 from the received STAMP test packet into DSCP and ECN fields of the 543 Class of Service TLV of the reflected STAMP test packet. If the 544 value of the Op field equals Set and Report (TBA6) Section 6.4, then 545 the STAMP reflector MUST use DSCP value from the Class of Service TLV 546 in the received STAMP test packet as DSCP value of STAMP reflected 547 test packet and MUST copy DSCP and ECN values of the received STAMP 548 test packet into DSCP and ECN fields of Class of Service TLV in the 549 STAMP reflected packet. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Class of Service Type | Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | DSCP |ECN|Op | MBZ | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 10: Class of Service TLV 561 where fields are defined as the following: 563 o 565 6. IANA Considerations 567 6.1. STAMP TLV Registry 569 IANA is requested to create STAMP TLV Type registry. All code points 570 in the range 1 through 32759 in this registry shall be allocated 571 according to the "IETF Review" procedure as specified in [RFC8126]. 572 Code points in the range 32760 through 65279 in this registry shall 573 be allocated according to the "First Come First Served" procedure as 574 specified in [RFC8126]. Remaining code points are allocated 575 according to the Table 1: 577 +---------------+--------------+-------------------------+ 578 | Value | Description | Reference | 579 +---------------+--------------+-------------------------+ 580 | 0 | Reserved | This document | 581 | 1- 32759 | Unassigned | IETF Review | 582 | 32760 - 65279 | Unassigned | First Come First Served | 583 | 65280 - 65519 | Experimental | This document | 584 | 65520 - 65534 | Private Use | This document | 585 | 65535 | Reserved | This document | 586 +---------------+--------------+-------------------------+ 588 Table 1: STAMP TLV Type Registry 590 This document defines the following new values in STAMP TLV Type 591 registry: 593 +-------+-----------------------+---------------+ 594 | Value | Description | Reference | 595 +-------+-----------------------+---------------+ 596 | TBA1 | Extra Padding | This document | 597 | TBA2 | Location | This document | 598 | TBA3 | Timestamp Information | This document | 599 | TBA4 | Class of Service | This document | 600 +-------+-----------------------+---------------+ 602 Table 2: STAMP Types 604 6.2. Synchronization Source Sub-registry 606 TBD 608 6.3. Timestamp Method Sub-registry 610 TBD 612 6.4. CoS Operation Sub-registry 614 TBD 616 7. Security Considerations 618 TBD 620 8. Acknowledgments 622 TBD 624 9. Normative References 626 [IEEE.1588.2008] 627 "Standard for a Precision Clock Synchronization Protocol 628 for Networked Measurement and Control Systems", 629 IEEE Standard 1588, March 2008. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, 634 . 636 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 637 Zekauskas, "A One-way Active Measurement Protocol 638 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 639 . 641 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 642 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 643 RFC 5357, DOI 10.17487/RFC5357, October 2008, 644 . 646 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 647 "Network Time Protocol Version 4: Protocol and Algorithms 648 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 649 . 651 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 652 Protocol (TWAMP) Reflect Octets and Symmetrical Size 653 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 654 . 656 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 657 Writing an IANA Considerations Section in RFCs", BCP 26, 658 RFC 8126, DOI 10.17487/RFC8126, June 2017, 659 . 661 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 662 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 663 May 2017, . 665 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 666 Timestamp Format in a Two-Way Active Measurement Protocol 667 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 668 . 670 Authors' Addresses 672 Greg Mirsky 673 ZTE Corp. 675 Email: gregimirsky@gmail.com 677 Guo Jun 678 ZTE Corporation 679 68# Zijinghua Road 680 Nanjing, Jiangsu 210012 681 P.R.China 683 Phone: +86 18105183663 684 Email: guo.jun2@zte.com.cn 685 Henrik Nydell 686 Accedian Networks 688 Email: hnydell@accedian.com