idnits 2.17.1 draft-li-ippm-otwamp-on-lag-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 : ---------------------------------------------------------------------------- ** 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 (February 8, 2021) is 1170 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 (-17) exists of draft-ietf-ippm-ioam-data-11 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: August 12, 2021 Huawei 6 G. Mirsky 7 ZTE Corp. 8 February 8, 2021 10 One-way/Two-way Active Measurement Protocol Extensions for Performance 11 Measurement on LAG 12 draft-li-ippm-otwamp-on-lag-00 14 Abstract 16 This document defines extensions to One-way Active Measurement 17 Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to 18 implement performance measurement on every member link of a Link 19 Aggregation Group (LAG). Knowing the measured metrics of each member 20 link of a LAG enables operators to enforce a performance metric-based 21 traffic steering policy across 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 August 12, 2021. 48 Copyright Notice 50 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 8 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Mico OWAMP-Control Command . . . . . . . . . . . . . . . 12 77 5.2. Mico TWAMP-Control Command . . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Problem Statement 87 Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides 88 mechanisms to combine multiple physical links into a single logical 89 link. This logical link offers higher bandwidth and better 90 resiliency, because if one of the physical member links fails, the 91 aggregate logical link can continue to forward traffic over the 92 remaining operational physical member links. 94 Usually, when forwarding traffic over a LAG, a hash-based or similar 95 mechanism is used to load balance the traffic across the LAG member 96 links. In some cases, the link delays of the member links are 97 different because they are over different transport paths. To 98 provide low delay service to time sensitive traffic, we have to know 99 the link delay of each member link of a LAG and then steer traffic 100 accordingly. That requires a solution that could measure the 101 performance metrics of each member link of a LAG. 103 However, when using One-way Active Measurement Protocol (OWAMP) 104 [RFC4656], or Two-way Active Measurement Protocol (TWAMP) [RFC5357] 105 to measure the performance of a LAG, the LAG is treated as a single 106 logical link/path. The measured metrics reflect the performance of 107 one member link or an average of some/all member links of the LAG. 109 In addition, for LAG, using passive or hybrid methods (like 110 alternative marking[RFC8321] or iOAM [I-D.ietf-ippm-ioam-data]) can 111 only monitor the link crossed by traffic. It means that the measured 112 metrics reflect the performance of some member links or an average of 113 some/all member links of the LAG. Therefore, in order to measure 114 every link of a LAG, using active methods would be more appropriate. 116 This document defines extensions to OWAMP [RFC4656], and TWAMP 117 [RFC5357] to implement performance measurement on every member link 118 of a LAG. 120 2. Micro Session on LAG 122 This document intends to address the scenario (e.g., Figure 1) where 123 a LAG (e.g., the LAG includes three member links) directly connects 124 two nodes (A and B) . The goal is to measure the performance of each 125 link of the LAG. 127 +---+ +---+ 128 | |-----------------------| | 129 | A |-----------------------| B | 130 | |-----------------------| | 131 +---+ +---+ 133 Figure 1: PM for LAG 135 To measure performance metrics of every member link of a LAG, 136 multiple sessions (one session for each member link) need to be 137 established between the two hosts that are connected by the LAG. 138 These sessions are called micro sessions for the remainder of this 139 document. 141 All micro sessions of a LAG share the same Sender Address, Receiver 142 Address. As for the Sender Port and Receiver Port, the micro 143 sessions may share the same Sender Port and Receiver Port pair, or 144 each micro session is configured with a different Sender Port and 145 Receiver Port pair. But from simplifying operation point of view, 146 the former is recommended. 148 In addition, with micro sessions, there needs a way to correlate a 149 session with a member link. For example, when the Server/Reflector/ 150 Receiver receives a Control or Test packet, it needs to know from 151 which member link the packet is received, and correlate it with a 152 micro session. This is different from the existing OWAMP [RFC4656], 153 or TWAMP [RFC5357] 155 This document defines new command types to indicate that a session is 156 a micro session. The details are described in Sections 3 and 4 of 157 this document. Upon receiving a Control/Test packet, the receiver 158 uses the receiving link's identifier to correlate the packet to a 159 particular micro session. In addition, Test packets may need to 160 carry the member link information for validation checking. For 161 example, when a Session-Sender receives a Test packet, it may need to 162 check whether the Test packet is from the expected member link. 164 3. Mirco OWAMP Session 166 This document assumes that the OWAMP Server and the OWAMP Receiver of 167 an OWAMP micro session are at the same host. 169 3.1. Micro OWAMP-Control 171 To support the micro OWAMP session, a new command, referred to as 172 Request-OW-Micro-Session (TBD1), is defined in this document. The 173 Request-OW-Micro-Session command is based on the OWAMP Request- 174 Session command, and uses the message format as described in 175 Section 3.5 of OWAMP [RFC4656]. Test session creation of micro OWAMP 176 session follows the same procedure as defined in Section 3.5 of OWAMP 177 [RFC4656] with the following additions: 179 When a OWAMP Server receives a Request-OW-Micro-Session command, if 180 the Session is accepted, the OWAMP Server MUST build an association 181 between the session and the member link from which the Request- 182 Session message is received. 184 3.2. Micro OWAMP-Test 186 Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures 187 as defined in Section 4 of OWAMP [RFC4656] with the following 188 additions: 190 The micro OWAMP Sender MUST send the micro OWAMP-Test packets over 191 the member link with which the session is associated. When receives 192 a Test packet, the micro OWAMP receiver MUST use the member link from 193 which the Test packet is received to correlate the micro OWAMP 194 session. If there is no such a session, the Test packet MUST be 195 discarded. 197 4. Mirco TWAMP Session 199 As above, this document assumes that the TWAMP Server and the TWAMP 200 Session-Reflector of a micro OWAMP session are at the same host. 202 4.1. Micro TWAMP-Control 204 To support the micro TWAMP session, a new command, referred to as 205 Request-TW-Micro-Session (TBD2), is defined in this document. The 206 Request-TW-Micro-Session command is based on the TWAMP Request- 207 Session command, and uses the message format as described in 208 Section 3.5 of TWAMP [RFC5357]. Test session creation of micro TWAMP 209 session follows the same procedure as defined in Section 3.5 of TWAMP 210 [RFC5357] with the following additions: 212 When a micro TWAMP Server receives a Request-TW-Micro-Session 213 command, if the micro TWAMP Session is accepted, the micro TWAMP 214 Server MUST build an association between the session and the member 215 link from which the Request-Session message is received. 217 4.2. Micro TWAMP-Test 219 The micro TWAMP-Test protocol is based on the TWAMP-Test protocol 220 [RFC5357] with the following extensions. 222 4.2.1. Sender Behavior 224 In addition to inheriting the TWAMP sender behavior as defined 225 Section 4.1 of [RFC5357], the micro TWAMP Session-Sender MUST send 226 the micro TWAMP-Test packets over the member link with which the 227 session is associated. 229 When sending the Test packet, the micro TWAMP Session-Sender MUST put 230 the Sender member link identifier that is associated with the micro 231 TWAMP session in the Sender Member Link ID. If the Session-Sender 232 knows the Reflector member link identifier, it MUST put it in the 233 Reflector Member Link ID fields (see Figure 2 and Figure 3). 234 Otherwise, the Reflector Member Link ID field MUST be set to zero. 236 The Session-Sender uses the Sender member link identifier to check 237 whether a reflected Test packet is received from the member link 238 associated with the correct micro TWAMP session. Therefore, it is 239 carried in the Sender Member Link ID field of a Test packet and sent 240 to the Session-Reflector. Then it will be sent back by the Session- 241 Reflector with the reflected Test packet. 243 The Reflector member link identifier carried in the Reflector Member 244 Link ID field is used by the Session-Receiver to check whether a Test 245 packet is received from the member link associated with the correct 246 micro TWAMP session. It means that the Session-Sender has to learn 247 the Reflector member link identifier. Once the Session-Sender knows 248 the Reflector member link identifier, it MUST put the identifier in 249 the Reflector Member Link ID field (see Figure 2 or Figure 3) of the 250 Test packets that will be sent to the Session-Reflector. The 251 Reflector member link identifier can be obtained from pre- 252 configuration or learned through the control plane or data plane 253 (e.g., learned from a reflected Test packet). How to obtain/learn 254 the Reflector member link identifier is out of the scope of this 255 document. 257 When receives a reflected Test packet, the micro TWAMP Session-Sender 258 MUST use the receiving member link to correlate the reflected Test 259 packet to a micro TWAMP session. If there is no such a session, the 260 reflected Test packet MUST be discarded. If a matched session 261 exists, the Session-Sender MUST use the identifier carried in the 262 Sender Member Link ID field to validate whether the reflected Test 263 packet is correctly transmitted over the expected member link. If 264 the validation failed, the Test packet MUST be discarded. 266 4.2.1.1. Packet Format and Content 268 The micro TWAMP Session-Sender packet format is based on the TWAMP 269 Session-Sender packet format as defined in Section 4.1.2 of 270 [RFC5357]. Two new fields (Sender Member Link ID and Reflector 271 Member Link ID) are added to carry the LAG member link identifiers. 272 The formats are as below: 274 For unauthenticated mode: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Sequence Number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Timestamp | 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Error Estimate | MBZ | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Sender Member Link ID | Reflector Member Link ID | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 . Packet Padding . 290 . . 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 2: Session-Sender Packet format in Unauthenticated Mode 296 For authenticated mode: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Sequence Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 | MBZ (12 octets) | 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Timestamp | 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Error Estimate | MBZ | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Sender Member Link ID | Reflector Member Link ID | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 | HMAC (16 octets) | 316 | | 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 . Packet Padding . 321 . . 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 3: Session-Sender Packet Format in Authenticated Mode 327 Except for the Sender/Reflector Member Link ID field, all the other 328 fields are the same as defined in Section 4.1.2 of TWAMP [RFC5357], 329 which is defined in Section 4.1.2 of OWAMP [RFC4656]. Therefore, it 330 follows the same procedure and guidelines as defined in Section 4.1.2 331 of TWAMP [RFC5357]. 333 Sender Member Link ID (2-octets in length): it is defined to carry 334 the LAG member link identifier of the Sender side. The value of the 335 Sender Member Link ID MUST be unique at the Session-Sender. 337 Reflector Member Link ID (2-octets in length): it is defined to carry 338 the LAG member link identifier of the Reflector side. The value of 339 the Reflector Member ID MUST be unique at the Session-Reflector. 341 4.2.2. Reflector Behavior 343 The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP 344 Session-Reflector as defined in Section 4.2 of [RFC5357]. 346 In addition, when receives a Test packet, the micro TWAMP Session- 347 Reflector MUST use the receiving member link to correlate the Test 348 packet to a micro TWAMP session. If there is no such a session, the 349 Test packet MUST be discarded. If Reflector Member Link ID is not 350 zero, the Reflector MUST use the Reflector member link identifier to 351 check whether it associates with the receiving member link. If it 352 does not, the Test packet MUST be discarded. 354 When sends a response to the received Test packet, the micro TWAMP 355 Session-Sender MUST copy the Sender member link identifier from the 356 received Test packet and put it in the Sender Member Link ID field of 357 the reflected Test packet (see Figure 4 and Figure 5). In addition, 358 the micro TWAMP Session-Reflector MUST fill the Reflector Member Link 359 ID field (see Figure 2 or Figure 3) of the reflected Test packet with 360 the member link identifier that is associated with the micro TWAMP 361 session. 363 4.2.2.1. Packet Format and Content 365 The micro TWAMP Session-Reflector packet format is based on the TWAMP 366 Session-Reflector packet format as defined in Section 4.2.1 of 367 [RFC5357]. Two new fields (Sender and Reflector Member Link ID) are 368 added to carry the LAG member link identifiers. The formats are as 369 below: 371 For unauthenticated mode: 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Sequence Number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Timestamp | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Error Estimate | MBZ | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Receive Timestamp | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sender Sequence Number | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Sender Timestamp | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Sender Error Estimate | Sender Member Link ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Sender TTL | MBZ | Reflector Member Link ID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 . . 397 . Packet Padding . 398 . . 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 4: Session-Reflector Packet Format in Unauthenticated Mode 404 For authenticated and encrypted modes: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sequence Number | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | MBZ (12 octets) | 412 | | 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Timestamp | 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Error Estimate | MBZ | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Sender Member Link ID | Reflector Member Link ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Receive Timestamp | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | MBZ (8 octets) | 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sender Sequence Number | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | MBZ (12 octets) | 431 | | 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Sender Timestamp | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Sender Error Estimate | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 439 | MBZ (6 octets) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Sender TTL | | 442 +-+-+-+-+-+-+-+-+ + 443 | | 444 | | 445 | MBZ (15 octets) | 446 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 447 | HMAC (16 octets) | 448 | | 449 | | 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 . Packet Padding . 454 . . 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 5: Session-Reflector Packet Format in Authenticated Mode 460 Except for the Sender/Reflector Member Link ID field, all the other 461 fields are the same as defined in Section 4.2.1 of TWAMP [RFC5357]. 462 Therefore, it follows the same procedure and guidelines as defined in 463 Section 4.2.1 of TWAMP [RFC5357]. 465 Sender Member Link ID (2-octets in length): it is defined to carry 466 the LAG member link identifier of the Sender side. The value of the 467 Sender Member Link ID MUST be unique at the Session-Sender. 469 Reflector Member Link ID (2-octets in length): it is defined to carry 470 the LAG member link identifier of the Reflector side. The value of 471 the Reflector Member ID MUST be unique at the Session-Reflector. 473 5. IANA Considerations 475 5.1. Mico OWAMP-Control Command 477 This document requires the IANA to allocate the following command 478 type from OWAMP-Control Command Number Registry. 480 Value Description Semantics Definition 481 TBD1 Request-OW-Micro-Session This document, Section 3.1 483 5.2. Mico TWAMP-Control Command 485 This document requires the IANA to allocate the following command 486 type from TWAMP-Control Command Number Registry. 488 Value Description Semantics Definition 489 TBD1 Request-TW-Micro-Session This document, Section 4.1 491 6. Security Considerations 493 This document does not introduce additional security requirements and 494 mechanisms other than those described in [RFC4656], and [RFC5357]. 496 7. Acknowledgements 498 The authors would like to thank Min Xiao, Fang Xin for the valuable 499 comments to this work. 501 8. References 503 8.1. Normative References 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, 507 DOI 10.17487/RFC2119, March 1997, 508 . 510 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 511 Zekauskas, "A One-way Active Measurement Protocol 512 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 513 . 515 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 516 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 517 RFC 5357, DOI 10.17487/RFC5357, October 2008, 518 . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 8.2. Informative References 526 [I-D.ietf-ippm-ioam-data] 527 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 528 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 529 progress), November 2020. 531 [IEEE802.1AX] 532 IEEE Std. 802.1AX, "IEEE Standard for Local and 533 metropolitan area networks - Link Aggregation", November 534 2008. 536 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 537 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 538 "Alternate-Marking Method for Passive and Hybrid 539 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 540 January 2018, . 542 Authors' Addresses 544 Zhenqiang Li 545 China Mobile 547 Email: li_zhenqiang@hotmail.com 549 Mach(Guoyi) Chen 550 Huawei 552 Email: mach.chen@huawei.com 554 Greg Mirsky 555 ZTE Corp. 557 Email: gregimirsky@gmail.com