idnits 2.17.1 draft-li-ippm-pm-on-lag-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-ippm-stamp-option-tlv-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft China Mobile 4 Intended status: Standards Track M. Chen 5 Expires: January 14, 2021 Huawei 6 G. Mirsky 7 ZTE Corp. 8 July 13, 2020 10 Performance Measurement on LAG 11 draft-li-ippm-pm-on-lag-01 13 Abstract 15 This document defines extensions to One-way Active Measurement 16 Protocol (OWAMP), Two-way Active Measurement Protocol (TWAMP), and 17 Simple Two-Way Active Measurement Protocol (STAMP) to implement 18 performance measurement on every member link of a Link Aggregation 19 Group (LAG). With the measured metrics of each member links of a 20 LAG, it enables operators to enforce performance metric based traffic 21 steering policy among the member links. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in 28 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 29 as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 14, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Micro Session on LAG . . . . . . . . . . . . . . . . . . . . 3 67 3. Mirco OWAMP Session . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Micro OWAMP-Control . . . . . . . . . . . . . . . . . . . 4 69 3.2. Micro OWAMP-Test . . . . . . . . . . . . . . . . . . . . 4 70 4. Mirco TWAMP Session . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Micro TWAMP-Control . . . . . . . . . . . . . . . . . . . 5 72 4.2. Micro TWAMP-Test . . . . . . . . . . . . . . . . . . . . 5 73 4.2.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 5 74 4.2.2. Reflector Behavior . . . . . . . . . . . . . . . . . 7 75 5. Mirco STAMP Session . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Micro STAMP-Test . . . . . . . . . . . . . . . . . . . . 11 77 5.1.1. Session-Sender Packet Format . . . . . . . . . . . . 11 78 5.1.2. Session-Reflector Packet Format . . . . . . . . . . . 12 79 5.1.3. Micro STAMP-Test Procedures . . . . . . . . . . . . . 15 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 6.1. Mico OWAMP-Control Command . . . . . . . . . . . . . . . 16 82 6.2. Mico TWAMP-Control Command . . . . . . . . . . . . . . . 16 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 9.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Problem Statement 92 Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides 93 mechanisms to combine multiple physical links into a single logical 94 link. This logical link provides higher bandwidth and better 95 resiliency, because if one of the physical member links fails, the 96 aggregate logical link can continue to forward traffic over the 97 remaining operational physical member links. 99 Normally, when forwarding traffic over a LAG, a hash based or the 100 like mechanism is used to load balance the traffic among member links 101 of the LAG. In some cases, the link delays of the member links are 102 different because the member links are over different transport 103 paths. To provide low delay service to time sensitive traffic, we 104 have to know the link delay of each member link of a LAG and then 105 steer traffic accordingly. This requires a solution that could 106 measure the performance metrics of each member link of a LAG. 108 However, when using One-way Active Measurement Protocol (OWAMP) 109 [RFC4656], Two-way Active Measurement Protocol (TWAMP) [RFC5357], or 110 Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] to 111 measure the performance of a LAG, the LAG is treated as a single 112 logical link/path. The measured metrics reflect the performance of 113 one member link or an average of some/all member links of the LAG. 115 This document defines extensions to OWAMP [RFC4656], TWAMP [RFC5357] 116 or STAMP [RFC8762] to implement performance measurement on every 117 member link of a LAG. 119 2. Micro Session on LAG 121 To measure performance metrics of every member link of a LAG, 122 multiple sessions (one session for each member link) need to be 123 established between the two hosts that are connected by the LAG. 124 These sessions are called micro sessions in the remainder of this 125 document. 127 From the OWAMP/TWAMP-Control point of view, micro sessions of a LAG 128 share the same Sender Address, Receiver Address, have different 129 Session Identifiers (SID). As for the Sender Port and Receiver Port, 130 micro sessions may share the same Sender Port and Receiver Port pair, 131 or each micro session is configured with different Sender Port and 132 Receiver Port pair. But from simplifying operation point of view, 133 the former is recommended. 135 In addition, with micro sessions, there needs a way to correlate a 136 session with a member link. For example, when receives a Control or 137 Test packet, the Server/Reflector/Receiver needs to know from which 138 member link the packet is received, and then correlate the packet 139 with a micro session. This is different from the existing OWAMP 140 [RFC4656], TWAMP [RFC5357], or STAMP [RFC8762]. 142 This document defines new command types to indicate that a session is 143 a micro session, the details are described in Section 3 and 4 of this 144 document. For a micro session, on receiving of a Control/Test 145 packet, the receiver uses the receiving link to correlate the packet 146 with a particular session. In the case of two-way measurement, Test 147 packets may need to carry the member link related information for 148 valid checking. For example, when a Sender receives a reflected Test 149 packet, it may needs to check whether the Test packet is from the 150 expected member link. 152 3. Mirco OWAMP Session 154 This document assumes that the OWAMP Server and the OWAMP Receiver of 155 an OWAMP micro session are at the same host. 157 3.1. Micro OWAMP-Control 159 To support micro OWAMP session, a new command, which is referred to 160 as Request-OW-Micro-Session (TBD1), is defined in this document. The 161 Request-OW-Micro-Session command is based on the OWAMP Request- 162 Session command, and uses the message format as described in 163 Section 3.5 of OWAMP [RFC4656]. Test session creation of micro OWAMP 164 session follows the same procedure as defined in Section 3.5 of OWAMP 165 [RFC4656] with the following additions: 167 When a OWAMP Server receives a Request-OW-Micro-Session command, if 168 the Session is accepted, the OWAMP Server MUST build an association 169 between the session and the member link from which the Request- 170 Session message is received. 172 3.2. Micro OWAMP-Test 174 Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures 175 as defined in Section 4 of OWAMP [RFC4656] with the following 176 additions: 178 The micro OWAMP Sender MUST send the micro OWAMP-Test packets over 179 the member link with which the session is associated. When receives 180 a Test packet, the micro OWAMP receiver MUST use the member link from 181 which the Test packet is received to correlate the micro OWAMP 182 session. 184 4. Mirco TWAMP Session 186 As above, this document assumes that the TWAMP Server and the TWAMP 187 Session-Reflector of a micro OWAMP session are at the same host. 189 4.1. Micro TWAMP-Control 191 To support micro TWAMP session, a new command, which is referred to 192 as Request-TW-Micro-Session (TBD2), is defined in this document. The 193 Request-TW-Micro-Session command is based on the TWAMP Request- 194 Session command, and uses the message format as described in 195 Section 3.5 of TWAMP [RFC5357]. Test session creation of micro TWAMP 196 session follows the same procedure as defined in Section 3.5 of TWAMP 197 [RFC5357] with the following additions: 199 When a micro TWAMP Server receives a Request-TW-Micro-Session 200 command, if the micro TWAMP Session is accepted, the micro TWAMP 201 Server MUST build an association between the session and the member 202 link from which the Request-Session message is received. 204 4.2. Micro TWAMP-Test 206 The micro TWAMP-Test protocol is based on the TWAMP-Test protocol 207 [RFC5357] with the following extensions. 209 4.2.1. Sender Behavior 211 In addition to inheriting the TWAMP sender behavior as defined 212 Section 4.1 of [RFC5357], the micro TWAMP Session-Sender MUST send 213 the micro TWAMP-Test packets over the member link with which the 214 session is associated. 216 When sending Test packet, the micro TWAMP Session-Sender MUST put the 217 Sender and Reflector member link identifier that is associated with 218 the micro TWAMP session in the Sender Member Link ID and Reflector 219 Member Link ID fields (see Figure 1 and Figure 2) respectively. The 220 Sender and Reflector member link identifiers are used for validating 221 whether a Test packet is correctly transmitted over the expected 222 member link. 224 The Reflector member link identifier can be obtained from 225 configuration or learned through control plane or data plane (e.g., 226 learned from a reflected Test packet). How to abtain/learn the 227 Reflector member link identifier is out of the scope of this 228 document. If the micro TWAMP Session-Sender does not know the 229 Reflector member link identifier, the Reflector Member Link ID field 230 MUST be set to zero. 232 When receives a reflected Test packet, the micro TWAMP Session-Sender 233 MUST use the member link from which the Test packet is received to 234 correlate to a micro TWAMP session and use the Sender/Reflector 235 member link identifiers to validate whether the Test packet is 236 correctly transmitted over the expected member link. 238 4.2.1.1. Packet Format and Content 240 The micro TWAMP Session-Sender packet format is based on the TWAMP 241 Session-Sender packet format as defined in Section 4.1.2 of 242 [RFC5357]. In addition, in order to carry the LAG member link 243 identifier, two new fields (Sender and Reflector Member Link ID) are 244 added. The formats are as below: 246 For unauthenticated mode: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Sequence Number | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Timestamp | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Error Estimate | MBZ | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Sender Member Link ID | Reflector Member Link ID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 . Packet Padding . 262 . . 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1: Session-Sender Packet format in Unauthenticated Mode 268 For authenticated mode: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Sequence Number | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 | MBZ (12 octets) | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Timestamp | 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Error Estimate | MBZ | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Sender Member Link ID | Reflector Member Link ID | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 | HMAC (16 octets) | 288 | | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 . Packet Padding . 293 . . 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 2: Session-Sender Packet Format in Authenticated Mode 299 Except for the Sender/Reflector Member Link ID field, all the other 300 fields are the same as defined in Section 4.1.2 of TWAMP [RFC5357], 301 which is originally defined in Section 4.1.2 of OWAMP [RFC4656]. 302 Therefore, it follows the same procedure and guidelines as defined in 303 Section 4.1.2 of TWAMP [RFC5357]. 305 Sender Member Link ID (2-octets in length): it is defined to carry 306 the LAG member link identifier of the Sender side. The value of the 307 Sender Member Link ID MUST be unique at the Session-Sender. 309 Reflector Member Link ID (2-octets in length): it is defined to carry 310 the LAG member link identifier of the Reflector side. The value of 311 the Reflector Member ID MUST be unique at the Session-Reflector. 313 4.2.2. Reflector Behavior 315 The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP 316 Session-Reflector as defined in Section 4.2 of [RFC5357]. 318 In addition, when receives a Test packet, the micro TWAMP Session- 319 Reflector MUST use the member link from which the Test packet is 320 received to correlate to a micro TWAMP session and use the Sender and 321 Reflector member link identifiers to validate whether the Test packet 322 is from the expected member link. 324 When sends a response to the received Test packet, the micro TWAMP 325 Session-Sender MUST put the Sender and Reflector member link 326 identifiers that are associated with the micro TWAMP session in the 327 Sender Member Link ID and Reflector Member Link ID fields (see 328 Figure 3 and Figure 4) respectively. The Sender member link 329 identifier is copied from the received Test packet. 331 4.2.2.1. Packet Format and Content 333 The micro TWAMP Session-Reflector packet format is based on the TWAMP 334 Session-Reflector packet format as defined in Section 4.2.1 of 335 [RFC5357]. In addition, in order to carry the LAG member link 336 identifier, two new fields (Sender and Reflector Member Link ID) are 337 added. The formats are as below: 339 For unauthenticated mode: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Sequence Number | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Timestamp | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Error Estimate | MBZ | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Receive Timestamp | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Sender Sequence Number | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sender Timestamp | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Sender Error Estimate | Sender Member Link ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Sender TTL | MBZ | Reflector Member Link ID | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . . 365 . Packet Padding . 366 . . 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 3: Session-Reflector Packet Format in Unauthenticated Mode 372 For authenticated and encrypted modes: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Sequence Number | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | MBZ (12 octets) | 380 | | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Timestamp | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Error Estimate | MBZ | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Sender Member Link ID | Reflector Member Link ID | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Receive Timestamp | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | MBZ (8 octets) | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Sender Sequence Number | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | MBZ (12 octets) | 399 | | 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Sender Timestamp | 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Sender Error Estimate | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 407 | MBZ (6 octets) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sender TTL | | 410 +-+-+-+-+-+-+-+-+ + 411 | | 412 | | 413 | MBZ (15 octets) | 414 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 415 | HMAC (16 octets) | 416 | | 417 | | 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 . Packet Padding . 422 . . 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 4: Session-Reflector Packet Format in Authenticated Mode 428 Except for the Sender/Reflector Member Link ID field, all the other 429 fields are the same as defined in Section 4.2.1 of TWAMP [RFC5357]. 430 Therefore, it follows the same procedure and guidelines as defined in 431 Section 4.2.1 of TWAMP [RFC5357]. 433 Sender Member Link ID (2-octets in length): it is defined to carry 434 the LAG member link identifier of the Sender side. The value of the 435 Sender Member Link ID MUST be unique at the Session-Sender. 437 Reflector Member Link ID (2-octets in length): it is defined to carry 438 the LAG member link identifier of the Reflector side. The value of 439 the Reflector Member ID MUST be unique at the Session-Reflector. 441 5. Mirco STAMP Session 443 5.1. Micro STAMP-Test 445 The micro STAMP-Test protocol is based on the STAMP-Test protocol 446 [RFC8762] with the following extensions. 448 5.1.1. Session-Sender Packet Format 450 The micro STAMP Session-Sender Test packet formats are based on the 451 STAMP Session-Sender Test packet formats and with some extensions, 452 two new fields (Sender and Reflector Member Link ID) are added. The 453 formats are as follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Sequence Number | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Timestamp | 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Error Estimate | SSID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Sender Member Link ID | Reflector Member Link ID | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 | MBZ (24 octets) | 469 | | 470 | | 471 | | 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 5: Session-Sender Test Packet in Unauthenticated Mode 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Sequence Number | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 | MBZ (12 octets) | 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Timestamp | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Error Estimate | SSID | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Sender Member Link ID | Reflector Member Link ID | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | MBZ (64 octets) | 494 ~ ~ 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 | HMAC (16 octets) | 499 | | 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 6: Session-Sender Test Packet in Authenticated Mode 504 Except for the Sender/Reflector Member Link ID field, all the other 505 fields are the same as those defined in STAMP [RFC8762] and 506 [I-D.ietf-ippm-stamp-option-tlv]. 508 Sender Member Link ID (2-octets in length): it is defined to carry 509 the LAG member link identifier of the Sender side, which i. The 510 value of the Sender Member Link ID MUST be unique at the Session- 511 Sender. 513 Reflector Member Link ID (2-octets in length): it is defined to carry 514 the LAG member link identifier of the Reflector side. The value of 515 the Reflector Member ID MUST be unique at the Session-Reflector. 517 5.1.2. Session-Reflector Packet Format 519 The micro STAMP Session-Reflector Test packet formats are based on 520 the STAMP Session-Reflector Test packet formats with some minor 521 extensions, two new fields (Sender and Reflector Member Link ID) are 522 added. The formats are as follows: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Sequence Number | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Timestamp | 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Error Estimate | SSID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Receive Timestamp | 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Session-Sender Sequence Number | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Session-Sender Timestamp | 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Session-Sender Error Estimate | Sender Member Link ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |Ses-Sender TTL | MBZ | Reflector Member Link ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 7: Session-Reflector Test Packet in Unauthenticated Mode 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sequence Number | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | MBZ (12 octets) | 554 | | 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Timestamp | 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Error Estimate | SSID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Sender Member Link ID | Reflector Member Link ID | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Receive Timestamp | 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | MBZ (8 octets) | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Session-Sender Sequence Number | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | MBZ (12 octets) | 573 | | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Session-Sender Timestamp | 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Session-Sender Error Estimate | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 581 | MBZ (6 octets) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |Ses-Sender TTL | | 584 +-+-+-+-+-+-+-+-+ + 585 | | 586 | MBZ (15 octets) | 587 | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | HMAC (16 octets) | 590 | | 591 | | 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 8: Session-Reflector Test Packet in Authenticated Mode 597 Except for the Sender/Reflector Member Link ID fields, all the other 598 fields are the same those as defined in STAMP [RFC8762] and 599 [I-D.ietf-ippm-stamp-option-tlv]. 601 Sender Member Link ID (2-octets in length): it is defined to carry 602 the LAG member link identifier of the Sender side. The value of the 603 Sender Member Link ID MUST be unique at the Session-Sender. 605 Reflector Member Link ID (2-octets in length): it is defined to carry 606 the LAG member link identifier of the Reflector side. The value of 607 the Reflector Member ID MUST be unique at the Session-Reflector. 609 5.1.3. Micro STAMP-Test Procedures 611 The micro STAMP-Test reuses the procedures as defined in Section 4 of 612 STAMP [RFC8762] with the following additions: 614 The micro STAMP Session-Sender MUST send the micro STAMP-Test packets 615 over the member link with which the session is associated. 617 The configuration and management of the mapping between a micro STAMP 618 session and the Sender/Reflector member link identifiers are outside 619 the scope of this document. 621 When sending Test packet, the micro STAMP Session-Sender MUST put the 622 Sender and Reflector member link identifiers that are associated with 623 the micro STAMP session in the Sender Member Link ID and Reflector 624 Member Link ID fields (see Figure 5 and Figure 6) respectively. The 625 Sender and Reflector member link identifiers are used for validating 626 whether a Test packet is correctly transmitted over the expected 627 member link. 629 When receives a Test packet, the micro STAMP Session-Reflector MUST 630 use the member link from which the Test packet is received to 631 correlate to a micro STAMP session and use the Sender/Reflector 632 member link identifiers to validate whether the Test packet is is 633 correctly transmitted over the expected member link. If the 634 validation passed, the Session-Reflector sends the reflected Test 635 packet to the Session-Sender. The micro STAMP Session-Reflector MUST 636 put the Sender and Reflector member link identifiers that are 637 associated with the micro STAMP session in the Sender Member Link ID 638 and Reflector Member Link ID fields (see Figure 7 and Figure 8) 639 respectively. The Sender member link identifier is copied from the 640 received Test packet. 642 When receives a reflected Test packet, the micro STAMP Session-Send 643 MUST use the member link from which the Test packet is received to 644 correlate to a micro STAMP session and use the Sender/Reflector 645 member link identifiers to validate whether the Test packet is 646 correctly transmitted over the expected member link. 648 6. IANA Considerations 650 6.1. Mico OWAMP-Control Command 652 This document requires the IANA to allocate the following command 653 type from OWAMP-Control Command Number Registry. 655 Value Description Semantics Definition 656 TBD1 Request-OW-Micro-Session This document, Section 3.1 658 6.2. Mico TWAMP-Control Command 660 This document requires the IANA to allocate the following command 661 type from TWAMP-Control Command Number Registry. 663 Value Description Semantics Definition 664 TBD1 Request-TW-Micro-Session This document, Section 4.1 666 7. Security Considerations 668 The security considerations in [RFC4656], [RFC5357], [RFC8762] apply 669 to this document. 671 8. Acknowledgements 673 The authors would like to thank Min Xiao for the valuable comments to 674 this work. 676 9. References 678 9.1. Normative References 680 [I-D.ietf-ippm-stamp-option-tlv] 681 Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 682 and E. Ruffini, "Simple Two-way Active Measurement 683 Protocol Optional Extensions", draft-ietf-ippm-stamp- 684 option-tlv-07 (work in progress), July 2020. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, 688 DOI 10.17487/RFC2119, March 1997, 689 . 691 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 692 Zekauskas, "A One-way Active Measurement Protocol 693 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 694 . 696 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 697 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 698 RFC 5357, DOI 10.17487/RFC5357, October 2008, 699 . 701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 702 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 703 May 2017, . 705 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 706 Two-Way Active Measurement Protocol", RFC 8762, 707 DOI 10.17487/RFC8762, March 2020, 708 . 710 9.2. Informative References 712 [IEEE802.1AX] 713 IEEE Std. 802.1AX, "IEEE Standard for Local and 714 metropolitan area networks - Link Aggregation", November 715 2008. 717 Authors' Addresses 719 Zhenqiang Li 720 China Mobile 722 Email: li_zhenqiang@hotmail.com 724 Mach(Guoyi) Chen 725 Huawei 727 Email: mach.chen@huawei.com 729 Greg Mirsky 730 ZTE Corp. 732 Email: gregimirsky@gmail.com