idnits 2.17.1 draft-li-ippm-otwamp-on-lag-02.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 (24 January 2022) is 823 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) == Unused Reference: 'RFC7130' is defined on line 518, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7799 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 1 error (**), 0 flaws (~~), 3 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 T. Zhou 5 Expires: 28 July 2022 Huawei 6 J. Guo 7 ZTE Corp. 8 G. Mirsky 9 Ericsson 10 R. Gandhi 11 Cisco 12 24 January 2022 14 One-way/Two-way Active Measurement Protocol Extensions for Performance 15 Measurement on LAG 16 draft-li-ippm-otwamp-on-lag-02 18 Abstract 20 This document defines extensions to One-way Active Measurement 21 Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to 22 implement performance measurement on every member link of a Link 23 Aggregation Group (LAG). Knowing the measured metrics of each member 24 link of a LAG enables operators to enforce the performance based 25 traffic steering policy across the member links. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in 32 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 33 as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 28 July 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Micro Session on LAG . . . . . . . . . . . . . . . . . . . . 3 69 3. Mirco OWAMP Session . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Micro OWAMP-Control . . . . . . . . . . . . . . . . . . . 4 71 3.2. Micro OWAMP-Test . . . . . . . . . . . . . . . . . . . . 4 72 4. Mirco TWAMP Session . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Micro TWAMP-Control . . . . . . . . . . . . . . . . . . . 5 74 4.2. Micro TWAMP-Test . . . . . . . . . . . . . . . . . . . . 5 75 4.2.1. Sender Packet Format and Content . . . . . . . . . . 5 76 4.2.2. Sender Behavior . . . . . . . . . . . . . . . . . . . 7 77 4.2.3. Reflector Packet Format and Content . . . . . . . . . 8 78 4.2.4. Reflector Behavior . . . . . . . . . . . . . . . . . 11 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Mico OWAMP-Control Command . . . . . . . . . . . . . . . 11 81 5.2. Mico TWAMP-Control Command . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 8.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides 92 mechanisms to combine multiple physical links into a single logical 93 link. This logical link offers higher bandwidth and better 94 resiliency, because if one of the physical member links fails, the 95 aggregate logical link can continue to forward traffic over the 96 remaining operational physical member links. 98 Usually, when forwarding traffic over LAG, the hash-based mechanism 99 is used to load balance the traffic across the LAG member links. 100 Link delay of each member link varies because of different transport 101 paths. To provide low latency service for time sensitive traffic, we 102 need to explicitly steer the traffic across the LAG member links 103 based on the link delay, loss and so on. That requires a solution to 104 measure the performance metrics of every member link of a LAG. 106 OWAMP [RFC4656] and TWAMP [RFC5357] are two active measurement 107 methods according to the classification given in RFC7799 [RFC7799]. 108 With both methods, running a single test session over the aggregation 109 without the knowledge of each member link would make it impossible to 110 measure the performance of a given physical member link. The 111 measured metrics can only reflect the performance of one member link 112 or an average of some/all member links of the LAG. 114 This document extends OWAMP and TWAMP to implement performance 115 measurement on every member link of a LAG. The proposed method could 116 also potentially apply to layer 3 ECMP (Equal Cost Multi-Path), e.g., 117 with SR-Policy [I-D.ietf-spring-segment-routing-policy]. 119 2. Micro Session on LAG 121 This document intends to address the scenario (e.g., Figure 1) where 122 a LAG (e.g., the LAG includes three member links) directly connects 123 two nodes (A and B) . The goal is to measure the performance of each 124 link of the LAG. 126 +---+ +---+ 127 | |-----------------------| | 128 | A |-----------------------| B | 129 | |-----------------------| | 130 +---+ +---+ 132 Figure 1: PM for LAG 134 To measure the performance metrics of every member link of a LAG, 135 multiple sessions (one session for each member link) need to be 136 established between the two end points that are connected by the LAG. 137 These sessions are called micro sessions in the remainder of this 138 document. 140 The micro sessions need to correlate with the corresponding member 141 links. For example, when the Server/Reflector/Receiver receives a 142 Control or Test packet, it needs to know from which member link the 143 packet is received, and correlate it with a micro session. 145 All micro sessions of a LAG share the same Sender IP Address and 146 Receiver IP Address. As for the UDP Port, the micro sessions may 147 share the same Sender Port and Receiver Port pair, or each micro 148 session is configured with a different Sender Port and Receiver Port 149 pair. But from the operational point of view, the former is simpler 150 and is recommended. 152 This document defines new command types to indicate that a session is 153 a micro session. The details are described in Sections 3 and 4 of 154 this document. Upon receiving a Control/Test packet, the receiver 155 uses the receiving link's identifier to correlate the packet to a 156 particular micro session. In addition, Test packets may need to 157 carry the member link information for validation checking. For 158 example, when a Session-Sender receives a Test packet, it may need to 159 check whether the Test packet is from the expected member link. 161 3. Mirco OWAMP Session 163 This document assumes that the OWAMP Server and the OWAMP Receiver of 164 an OWAMP micro session are at the same end point. 166 3.1. Micro OWAMP-Control 168 To support the micro OWAMP session, a new command, Request-OW-Micro- 169 Session (TBD1), is defined in this document. The Request-OW-Micro- 170 Session command is based on the OWAMP Request-Session command, and 171 uses the message format as described in Section 3.5 of OWAMP 172 [RFC4656]. Test session creation of micro OWAMP session follows the 173 same procedure as defined in Section 3.5 of OWAMP [RFC4656] with the 174 following additions: 176 When a OWAMP Server receives a Request-OW-Micro-Session command, if 177 the Session is accepted, the OWAMP Server MUST build an association 178 between the session and the member link from which the Request- 179 Session message is received. 181 3.2. Micro OWAMP-Test 183 Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures 184 as defined in Section 4 of OWAMP [RFC4656] with the following 185 additions: 187 The micro OWAMP Sender MUST send the micro OWAMP-Test packets over 188 the member link with which the session is associated. When receives 189 a Test packet, the micro OWAMP receiver MUST use the member link from 190 which the Test packet is received to correlate the micro OWAMP 191 session. If there is no such a session, the Test packet MUST be 192 discarded. 194 4. Mirco TWAMP Session 196 As above, this document assumes that the TWAMP Server and the TWAMP 197 Session-Reflector of a micro OWAMP session are at the same end point. 199 4.1. Micro TWAMP-Control 201 To support the micro TWAMP session, a new command, Request-TW-Micro- 202 Session (TBD2), is defined in this document. The Request-TW-Micro- 203 Session command is based on the TWAMP Request-Session command, and 204 uses the message format as described in Section 3.5 of TWAMP 205 [RFC5357]. Test session creation of micro TWAMP session follows the 206 same procedure as defined in Section 3.5 of TWAMP [RFC5357] with the 207 following additions: 209 When a micro TWAMP Server receives a Request-TW-Micro-Session 210 command, if the micro TWAMP Session is accepted, the micro TWAMP 211 Server MUST build an association between the session and the member 212 link from which the Request-Session message is received. 214 4.2. Micro TWAMP-Test 216 The micro TWAMP-Test protocol is based on the TWAMP-Test protocol 217 [RFC5357] with the following extensions. 219 4.2.1. Sender Packet Format and Content 221 The micro TWAMP Session-Sender packet format is based on the TWAMP 222 Session-Sender packet format as defined in Section 4.1.2 of 223 [RFC5357]. Two new fields (Sender Member Link ID and Reflector 224 Member Link ID) are added to carry the LAG member link identifiers. 226 For unauthenticated mode, the format is as below: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Sequence Number | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Timestamp | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Error Estimate | MBZ | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Sender Member Link ID | Reflector Member Link ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 . Packet Padding . 242 . . 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2: Session-Sender Packet format in Unauthenticated Mode 248 For authenticated mode, the format is as below: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Sequence Number | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 | MBZ (12 octets) | 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Timestamp | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Error Estimate | MBZ | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Sender Member Link ID | Reflector Member Link ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 | HMAC (16 octets) | 268 | | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 . Packet Padding . 273 . . 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 3: Session-Sender Packet Format in Authenticated Mode 278 Except for the Sender/Reflector Member Link ID field, all the other 279 fields are the same as defined in Section 4.1.2 of TWAMP [RFC5357], 280 which is defined in Section 4.1.2 of OWAMP [RFC4656]. Therefore, it 281 follows the same procedure and guidelines as defined in Section 4.1.2 282 of TWAMP [RFC5357]. 284 * Sender Member Link ID (2-octets in length): it is defined to carry 285 the LAG member link identifier of the Sender side. The value of 286 the Sender Member Link ID MUST be unique at the Session-Sender. 288 * Reflector Member Link ID (2-octets in length): it is defined to 289 carry the LAG member link identifier of the Reflector side. The 290 value of the Reflector Member ID MUST be unique at the Session- 291 Reflector. 293 4.2.2. Sender Behavior 295 The micro TWAMP Session-Sender inherits the behaviors of the TWAMP 296 Session-Reflector as defined in Section 4.1 of [RFC5357]. In 297 addition, the micro TWAMP Session-Sender MUST send the micro TWAMP- 298 Test packets over the member link with which the session is 299 associated. 301 When sending the Test packet, the micro TWAMP Session-Sender MUST put 302 the Sender member link identifier that is associated with the micro 303 TWAMP session in the Sender Member Link ID. If the Session-Sender 304 knows the Reflector member link identifier, it MUST put it in the 305 Reflector Member Link ID fields (see Figure 2 and Figure 3). 306 Otherwise, the Reflector Member Link ID field MUST be set to zero. 308 A Test packet with Sender member link identifier is sent to the 309 Session-Reflector, and then is reflected with the same Sender member 310 link identifier. So the Session-Sender can use the Sender member 311 link identifier to check whether a reflected Test packet is received 312 from the member link associated with the correct micro TWAMP session. 314 The Reflector member link identifier carried in the Reflector Member 315 Link ID field is used by the Session-Receiver to check whether a Test 316 packet is received from the member link associated with the correct 317 micro TWAMP session. It means that the Session-Sender has to learn 318 the Reflector member link identifier. Once the Session-Sender knows 319 the Reflector member link identifier, it MUST put the identifier in 320 the Reflector Member Link ID field (see Figure 2 or Figure 3) of the 321 Test packets that will be sent to the Session-Reflector. The 322 Reflector member link identifier can be obtained from pre- 323 configuration or learned through the control plane or data plane 324 (e.g., learned from a reflected Test packet). How to obtain/learn 325 the Reflector member link identifier is out of the scope of this 326 document. 328 When receives a reflected Test packet, the micro TWAMP Session-Sender 329 MUST use the receiving member link to correlate the reflected Test 330 packet to a micro TWAMP session. If there is no such a session, the 331 reflected Test packet MUST be discarded. If a matched session 332 exists, the Session-Sender MUST use the Sender Member Link ID to 333 validate whether the reflected Test packet is correctly transmitted 334 over the expected member link. If the validation fails, the Test 335 packet MUST be discarded. The Session-Sender MUST use the Reflector 336 Member Link ID to validate the Reflector's behavior.If the validation 337 fails, the Test packet MUST be discarded. 339 4.2.3. Reflector Packet Format and Content 341 The micro TWAMP Session-Reflector packet format is based on the TWAMP 342 Session-Reflector packet format as defined in Section 4.2.1 of 343 [RFC5357]. Two new fields (Sender and Reflector Member Link ID) are 344 added to carry the LAG member link identifiers. 346 For unauthenticated mode, the format is as below: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Sequence Number | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Timestamp | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Error Estimate | MBZ | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Receive Timestamp | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Sender Sequence Number | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Sender Timestamp | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Sender Error Estimate | Sender Member Link ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sender TTL | MBZ | Reflector Member Link ID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 . . 372 . Packet Padding . 373 . . 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 4: Session-Reflector Packet Format in Unauthenticated Mode 379 For authenticated mode, the format is as below: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sequence Number | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | MBZ (12 octets) | 387 | | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Timestamp | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Error Estimate | MBZ | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Sender Member Link ID | Reflector Member Link ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Receive Timestamp | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | MBZ (8 octets) | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Sender Sequence Number | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | MBZ (12 octets) | 406 | | 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sender Timestamp | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Sender Error Estimate | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 414 | MBZ (6 octets) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Sender TTL | | 417 +-+-+-+-+-+-+-+-+ + 418 | | 419 | | 420 | MBZ (15 octets) | 421 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 422 | HMAC (16 octets) | 423 | | 424 | | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 . Packet Padding . 429 . . 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 5: Session-Reflector Packet Format in Authenticated Mode 435 Except for the Sender/Reflector Member Link ID field, all the other 436 fields are the same as defined in Section 4.2.1 of TWAMP [RFC5357]. 437 Therefore, it follows the same procedure and guidelines as defined in 438 Section 4.2.1 of TWAMP [RFC5357]. 440 * Sender Member Link ID (2-octets in length): it is defined to carry 441 the LAG member link identifier of the Sender side. The value of 442 the Sender Member Link ID MUST be unique at the Session-Sender. 444 * Reflector Member Link ID (2-octets in length): it is defined to 445 carry the LAG member link identifier of the Reflector side. The 446 value of the Reflector Member ID MUST be unique at the Session- 447 Reflector. 449 4.2.4. Reflector Behavior 451 The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP 452 Session-Reflector as defined in Section 4.2 of [RFC5357]. 454 In addition, when receiving a Test packet, the micro TWAMP Session- 455 Reflector MUST use the receiving member link to correlate the Test 456 packet to a micro TWAMP session. If there is no such a session, the 457 Test packet MUST be discarded. If the Reflector Member Link ID is 458 not zero, the Reflector MUST use the Reflector Member Link ID to 459 validate whether it associates with the receiving member link. If 460 the validation fails, the Test packet MUST be discarded. 462 When sending a response to the received Test packet, the micro TWAMP 463 Session-Sender MUST copy the Sender member link identifier from the 464 received Test packet and put it in the Sender Member Link ID field of 465 the reflected Test packet (see Figure 4 and Figure 5). In addition, 466 the micro TWAMP Session-Reflector MUST fill the Reflector Member Link 467 ID field (see Figure 2 and Figure 3) of the reflected Test packet 468 with the member link identifier that is associated with the micro 469 TWAMP session. 471 5. IANA Considerations 473 5.1. Mico OWAMP-Control Command 475 This document requires the IANA to allocate the following command 476 type from OWAMP-Control Command Number Registry. 478 Value Description Semantics Definition 479 TBD1 Request-OW-Micro-Session This document, Section 3.1 481 5.2. Mico TWAMP-Control Command 483 This document requires the IANA to allocate the following command 484 type from TWAMP-Control Command Number Registry. 486 Value Description Semantics Definition 487 TBD1 Request-TW-Micro-Session This document, Section 4.1 489 6. Security Considerations 491 This document does not introduce additional security requirements and 492 mechanisms other than those described in [RFC4656], and [RFC5357]. 494 7. Acknowledgements 496 The authors would like to thank Min Xiao, Fang Xin for the valuable 497 comments to this work. 499 8. References 501 8.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 509 Zekauskas, "A One-way Active Measurement Protocol 510 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 511 . 513 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 514 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 515 RFC 5357, DOI 10.17487/RFC5357, October 2008, 516 . 518 [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., 519 Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional 520 Forwarding Detection (BFD) on Link Aggregation Group (LAG) 521 Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 522 2014, . 524 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 525 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 526 May 2016, . 528 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 529 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 530 May 2017, . 532 8.2. Informative References 534 [I-D.ietf-spring-segment-routing-policy] 535 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 536 P. Mattes, "Segment Routing Policy Architecture", Work in 537 Progress, Internet-Draft, draft-ietf-spring-segment- 538 routing-policy-14, 25 October 2021, 539 . 542 [IEEE802.1AX] 543 IEEE Std. 802.1AX, "IEEE Standard for Local and 544 metropolitan area networks - Link Aggregation", November 545 2008. 547 Authors' Addresses 549 Zhenqiang Li 550 China Mobile 551 China 553 Email: li_zhenqiang@hotmail.com 555 Tianran Zhou 556 Huawei 557 China 559 Email: zhoutianran@huawei.com 561 Jun Guo 562 ZTE Corp. 563 China 565 Email: guo.jun2@zte.com.cn 567 Greg Mirsky 568 Ericsson 569 United States of America 571 Email: gregimirsky@gmail.com 573 Rakesh Gandhi 574 Cisco 575 Canada 577 Email: rgandhi@cisco.com