idnits 2.17.1 draft-li-ippm-pm-on-lag-03.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 (November 02, 2020) is 1268 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-09 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 3 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: May 6, 2021 Huawei 6 G. Mirsky 7 ZTE Corp. 8 November 02, 2020 10 Performance Measurement on LAG 11 draft-li-ippm-pm-on-lag-03 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 May 6, 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 . . . . . . . . . . . . . . . . . . . . 5 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. Mirco STAMP Session . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Micro STAMP-Test . . . . . . . . . . . . . . . . . . . . 12 77 5.1.1. Session-Sender Packet Format . . . . . . . . . . . . 12 78 5.1.2. Session-Reflector Packet Format . . . . . . . . . . . 13 79 5.1.3. Micro STAMP-Test Procedures . . . . . . . . . . . . . 16 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 6.1. Mico OWAMP-Control Command . . . . . . . . . . . . . . . 17 82 6.2. Mico TWAMP-Control Command . . . . . . . . . . . . . . . 17 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 9.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 In addition, for LAG, using passive or hybrid methods (like 116 alternative marking[RFC8321] or iOAM [I-D.ietf-ippm-ioam-data]) can 117 only monitor the link crossed by traffic. Means the measured metrics 118 only reflect the performance of some member links or an average of 119 some/all member links of the LAG as well. Therefore, in order to 120 measure every link of a LAG, using active methods would be more 121 appropriate. 123 This document defines extensions to OWAMP [RFC4656], TWAMP [RFC5357] 124 or STAMP [RFC8762] to implement performance measurement on every 125 member link of a LAG. 127 2. Micro Session on LAG 129 This document intends to address the scenario (e.g., Figure 1) where 130 two hosts (A and B) are directly connected by a LAG (e.g., the LAG is 131 consisted by three links). The purpose is to measure the performance 132 of each link of the LAG. 134 +---+ +---+ 135 | |-----------------------| | 136 | A |-----------------------| B | 137 | |-----------------------| | 138 +---+ +---+ 140 Figure 1: PM for LAG 142 To measure performance metrics of every member link of a LAG, 143 multiple sessions (one session for each member link) need to be 144 established between the two hosts that are connected by the LAG. 145 These sessions are called micro sessions in the remainder of this 146 document. 148 All micro sessions of a LAG share the same Sender Address, Receiver 149 Address. As for the Sender Port and Receiver Port, the micro 150 sessions may share the same Sender Port and Receiver Port pair, or 151 each micro session is configured with different Sender Port and 152 Receiver Port pair. But from simplifying operation point of view, 153 the former is recommended. 155 In addition, with micro sessions, there needs a way to correlate a 156 session with a member link. For example, when receives a Control or 157 Test packet, the Server/Reflector/Receiver needs to know from which 158 member link the packet is received, and then correlate the packet 159 with a micro session. This is different from the existing OWAMP 160 [RFC4656], TWAMP [RFC5357], or STAMP [RFC8762]. 162 This document defines new command types to indicate that a session is 163 a micro session, the details are described in Section 3 and 4 of this 164 document. For a micro session, on receiving of a Control/Test 165 packet, the receiver uses the receiving link to correlate the packet 166 with a particular session. In addition, Test packets may need to 167 carry the member link information for validation checking. For 168 example, when a Session-Sender receives a Test packet, it may need to 169 check whether the Test packet is from the expected member link. 171 3. Mirco OWAMP Session 173 This document assumes that the OWAMP Server and the OWAMP Receiver of 174 an OWAMP micro session are at the same host. 176 3.1. Micro OWAMP-Control 178 To support micro OWAMP session, a new command, which is referred to 179 as Request-OW-Micro-Session (TBD1), is defined in this document. The 180 Request-OW-Micro-Session command is based on the OWAMP Request- 181 Session command, and uses the message format as described in 182 Section 3.5 of OWAMP [RFC4656]. Test session creation of micro OWAMP 183 session follows the same procedure as defined in Section 3.5 of OWAMP 184 [RFC4656] with the following additions: 186 When a OWAMP Server receives a Request-OW-Micro-Session command, if 187 the Session is accepted, the OWAMP Server MUST build an association 188 between the session and the member link from which the Request- 189 Session message is received. 191 3.2. Micro OWAMP-Test 193 Micro OWAMP-Test reuses the OWAMP-Test packet format and procedures 194 as defined in Section 4 of OWAMP [RFC4656] with the following 195 additions: 197 The micro OWAMP Sender MUST send the micro OWAMP-Test packets over 198 the member link with which the session is associated. When receives 199 a Test packet, the micro OWAMP receiver MUST use the member link from 200 which the Test packet is received to correlate the micro OWAMP 201 session. If there is no such a session, the Test packet MUST be 202 discarded. 204 4. Mirco TWAMP Session 206 As above, this document assumes that the TWAMP Server and the TWAMP 207 Session-Reflector of a micro OWAMP session are at the same host. 209 4.1. Micro TWAMP-Control 211 To support micro TWAMP session, a new command, which is referred to 212 as Request-TW-Micro-Session (TBD2), is defined in this document. The 213 Request-TW-Micro-Session command is based on the TWAMP Request- 214 Session command, and uses the message format as described in 215 Section 3.5 of TWAMP [RFC5357]. Test session creation of micro TWAMP 216 session follows the same procedure as defined in Section 3.5 of TWAMP 217 [RFC5357] with the following additions: 219 When a micro TWAMP Server receives a Request-TW-Micro-Session 220 command, if the micro TWAMP Session is accepted, the micro TWAMP 221 Server MUST build an association between the session and the member 222 link from which the Request-Session message is received. 224 4.2. Micro TWAMP-Test 226 The micro TWAMP-Test protocol is based on the TWAMP-Test protocol 227 [RFC5357] with the following extensions. 229 4.2.1. Sender Behavior 231 In addition to inheriting the TWAMP sender behavior as defined 232 Section 4.1 of [RFC5357], the micro TWAMP Session-Sender MUST send 233 the micro TWAMP-Test packets over the member link with which the 234 session is associated. 236 When sending Test packet, the micro TWAMP Session-Sender MUST put the 237 Sender member link identifier that is associated with the micro TWAMP 238 session in the Sender Member Link ID. If the Session-Sender knows 239 the Reflector member link identifier, it MUST put it in the Reflector 240 Member Link ID fields (see Figure 2 and Figure 3). Otherwise, the 241 Reflector Member Link ID field MUST be set to zero. 243 The Sender member link identifier is used by the Session-Sender to 244 check whether a reflected Test packet is received from the member 245 link that associates to the correct micro TWAMP session. Therefore, 246 it is carried in the Sender Member Link ID field of a Test packet and 247 sent to the Session-Reflector. Then it will be sent back by the 248 Session-Reflector with the reflected Test packet. 250 The Reflector member link identifier carried in the Reflector Member 251 Link ID field is used by the Session-Receiver to check whether a Test 252 packet is received from the member link that associates to the 253 correct micro TWAMP session. Means that the Session-Sender has to 254 learns the Reflector member link identifier. Once the Session-Sender 255 learns the Reflector member link identifier, it MUST put the 256 identifier in the Reflector Member Link ID field (see Figure 2 or 257 Figure 3) of the Test packets that will be sent to the Session- 258 Reflector. The Reflector member link identifier can be obtained from 259 pre-configuration or learned through control plane or data plane 260 (e.g., learned from a reflected Test packet). How to abtain/learn 261 the Reflector member link identifier is out of the scope of this 262 document. 264 When receives a reflected Test packet, the micro TWAMP Session-Sender 265 MUST use the receiving member link to correlate the reflected Test 266 packet to a micro TWAMP session. If there is no such a session, the 267 reflected Test packet MUST be discarded. If a matched session 268 exists, the Session-Sender MUST use the identifier carried in the 269 Sender Member Link ID field to validate whether the reflected Test 270 packet is correctly transmitted over the expected member link. If 271 the validation is failed, the Test packet MUST be discarded. 273 4.2.1.1. Packet Format and Content 275 The micro TWAMP Session-Sender packet format is based on the TWAMP 276 Session-Sender packet format as defined in Section 4.1.2 of 277 [RFC5357]. In addition, in order to carry the LAG member link 278 identifier, two new fields (Sender and Reflector Member Link ID) are 279 added. The formats are as below: 281 For unauthenticated mode: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Sequence Number | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Timestamp | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Error Estimate | MBZ | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Sender Member Link ID | Reflector Member Link ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 . Packet Padding . 297 . . 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: Session-Sender Packet format in Unauthenticated Mode 303 For authenticated mode: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Sequence Number | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 | MBZ (12 octets) | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Timestamp | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Error Estimate | MBZ | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Sender Member Link ID | Reflector Member Link ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | HMAC (16 octets) | 323 | | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 . Packet Padding . 328 . . 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: Session-Sender Packet Format in Authenticated Mode 334 Except for the Sender/Reflector Member Link ID field, all the other 335 fields are the same as defined in Section 4.1.2 of TWAMP [RFC5357], 336 which is originally defined in Section 4.1.2 of OWAMP [RFC4656]. 337 Therefore, it follows the same procedure and guidelines as defined in 338 Section 4.1.2 of TWAMP [RFC5357]. 340 Sender Member Link ID (2-octets in length): it is defined to carry 341 the LAG member link identifier of the Sender side. The value of the 342 Sender Member Link ID MUST be unique at the Session-Sender. 344 Reflector Member Link ID (2-octets in length): it is defined to carry 345 the LAG member link identifier of the Reflector side. The value of 346 the Reflector Member ID MUST be unique at the Session-Reflector. 348 4.2.2. Reflector Behavior 350 The micro TWAMP Session-Reflector inherits the behaviors of a TWAMP 351 Session-Reflector as defined in Section 4.2 of [RFC5357]. 353 In addition, when receives a Test packet, the micro TWAMP Session- 354 Reflector MUST use the receiving member link to correlate the Test 355 packet to a micro TWAMP session. If there is no such a session, the 356 Test packet MUST be discarded. If Reflector Member Link ID is not 357 zero, the Reflector MUST use the Reflector member link identifier to 358 check whether it associates with the receiving member link. If it 359 does not, the Test packet MUST be discarded. 361 When sends a response to the received Test packet, the micro TWAMP 362 Session-Sender MUST copy the Sender member link identifier from the 363 received Test packet and put it in the Sender Member Link ID field of 364 the reflected Test packet (see Figure 4 and Figure 5). In addition, 365 the micro TWAMP Session-Reflector MUST fill the Reflector Member Link 366 ID field (see Figure 2 or Figure 3) of the reflected Test packet with 367 the member link identifier that are associated with the micro TWAMP 368 session. 370 4.2.2.1. Packet Format and Content 372 The micro TWAMP Session-Reflector packet format is based on the TWAMP 373 Session-Reflector packet format as defined in Section 4.2.1 of 374 [RFC5357]. In addition, in order to carry the LAG member link 375 identifier, two new fields (Sender and Reflector Member Link ID) are 376 added. The formats are as below: 378 For unauthenticated mode: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Sequence Number | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Timestamp | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Error Estimate | MBZ | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Receive Timestamp | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Sender Sequence Number | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Sender Timestamp | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Sender Error Estimate | Sender Member Link ID | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Sender TTL | MBZ | Reflector Member Link ID | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 . . 404 . Packet Padding . 405 . . 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 4: Session-Reflector Packet Format in Unauthenticated Mode 411 For authenticated and encrypted modes: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Sequence Number | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | MBZ (12 octets) | 419 | | 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Timestamp | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Error Estimate | MBZ | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Sender Member Link ID | Reflector Member Link ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Receive Timestamp | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | MBZ (8 octets) | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Sender Sequence Number | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | MBZ (12 octets) | 438 | | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Sender Timestamp | 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Sender Error Estimate | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 446 | MBZ (6 octets) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Sender TTL | | 449 +-+-+-+-+-+-+-+-+ + 450 | | 451 | | 452 | MBZ (15 octets) | 453 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 454 | HMAC (16 octets) | 455 | | 456 | | 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 . Packet Padding . 461 . . 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 5: Session-Reflector Packet Format in Authenticated Mode 467 Except for the Sender/Reflector Member Link ID field, all the other 468 fields are the same as defined in Section 4.2.1 of TWAMP [RFC5357]. 469 Therefore, it follows the same procedure and guidelines as defined in 470 Section 4.2.1 of TWAMP [RFC5357]. 472 Sender Member Link ID (2-octets in length): it is defined to carry 473 the LAG member link identifier of the Sender side. The value of the 474 Sender Member Link ID MUST be unique at the Session-Sender. 476 Reflector Member Link ID (2-octets in length): it is defined to carry 477 the LAG member link identifier of the Reflector side. The value of 478 the Reflector Member ID MUST be unique at the Session-Reflector. 480 5. Mirco STAMP Session 482 5.1. Micro STAMP-Test 484 The micro STAMP-Test protocol is based on the STAMP-Test protocol 485 [RFC8762] and [I-D.ietf-ippm-stamp-option-tlv] with the following 486 extensions. 488 5.1.1. Session-Sender Packet Format 490 The micro STAMP Session-Sender Test packet formats are based on the 491 STAMP Session-Sender Test packet formats and with some extensions, 492 two new fields (Sender and Reflector Member Link ID) are added. The 493 formats are as follows: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Sequence Number | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Timestamp | 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Error Estimate | SSID | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Sender Member Link ID | Reflector Member Link ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 | MBZ (24 octets) | 509 | | 510 | | 511 | | 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 6: Session-Sender Test Packet in Unauthenticated Mode 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Sequence Number | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 | MBZ (12 octets) | 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Timestamp | 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Error Estimate | SSID | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Sender Member Link ID | Reflector Member Link ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | MBZ (64 octets) | 533 ~ ~ 534 | | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | | 537 | HMAC (16 octets) | 538 | | 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 7: Session-Sender Test Packet in Authenticated Mode 544 Except for the Sender/Reflector Member Link ID fields, all the other 545 fields are as defined in STAMP [RFC8762] and 546 [I-D.ietf-ippm-stamp-option-tlv]. 548 Sender Member Link ID (2-octets in length): it is defined to carry 549 the LAG member link identifier of the Sender side. The value of the 550 Sender Member Link ID MUST be unique at the Session-Sender. 552 Reflector Member Link ID (2-octets in length): it is defined to carry 553 the LAG member link identifier of the Reflector side. The value of 554 the Reflector Member ID MUST be unique at the Session-Reflector. 556 5.1.2. Session-Reflector Packet Format 558 The micro STAMP Session-Reflector Test packet formats are based on 559 the STAMP Session-Reflector Test packet formats with some minor 560 extensions, two new fields (Sender and Reflector Member Link ID) are 561 added. The formats are as follows: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Sequence Number | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Timestamp | 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Error Estimate | SSID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Receive Timestamp | 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Session-Sender Sequence Number | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Session-Sender Timestamp | 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Session-Sender Error Estimate | Sender Member Link ID | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |Ses-Sender TTL | MBZ | Reflector Member Link ID | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 8: Session-Reflector Test Packet in Unauthenticated Mode 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Sequence Number | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | MBZ (12 octets) | 593 | | 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Timestamp | 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Error Estimate | SSID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Sender Member Link ID | Reflector Member Link ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Receive Timestamp | 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | MBZ (8 octets) | 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Session-Sender Sequence Number | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | MBZ (12 octets) | 612 | | 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Session-Sender Timestamp | 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Session-Sender Error Estimate | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 620 | MBZ (6 octets) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |Ses-Sender TTL | | 623 +-+-+-+-+-+-+-+-+ + 624 | | 625 | MBZ (15 octets) | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | HMAC (16 octets) | 629 | | 630 | | 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 9: Session-Reflector Test Packet in Authenticated Mode 636 Except for the Sender/Reflector Member Link ID fields, all the other 637 fields are as defined in STAMP [RFC8762] and 638 [I-D.ietf-ippm-stamp-option-tlv]. 640 Sender Member Link ID (2-octets in length): it is defined to carry 641 the LAG member link identifier of the Sender side. The value of the 642 Sender Member Link ID MUST be unique at the Session-Sender. 644 Reflector Member Link ID (2-octets in length): it is defined to carry 645 the LAG member link identifier of the Reflector side. The value of 646 the Reflector Member ID MUST be unique at the Session-Reflector. 648 5.1.3. Micro STAMP-Test Procedures 650 The micro STAMP-Test reuses the procedures as defined in Section 4 of 651 STAMP [RFC8762] with the following additions: 653 The micro STAMP Session-Sender MUST send the micro STAMP-Test packets 654 over the member link with which the session is associated. 656 The configuration and management of the mapping between a micro STAMP 657 session and the Sender/Reflector member link identifiers are outside 658 the scope of this document. 660 When sending a Test packet, the micro STAMP Session-Sender MUST set 661 the Sender Member Link ID field with the member link identifier that 662 is associated with the micro STAMP session. If the Session-Sender 663 knows the Reflector member link identifier, it MUST put it in the 664 Reflector Member Link ID field (see Figure 6 or Figure 7). 665 Otherwise, the Reflector Member Link ID field MUST be set to zero. 667 The Sender member link identifier is used by the Session-Sender to 668 check whether a reflected Test packet is received from the member 669 link that associates with the correct micro STAMP session. The 670 Reflector member link identifier is used by the Session-Receiver to 671 check whether a Test packet is received from the member link that 672 associates with the correct micro STAMP session. 674 The Reflector member link identifier can be obtained from pre- 675 configuration or learned through data plane (e.g., learned from a 676 reflected Test packet). How to abtain/learn the Reflector member 677 link identifier is out of the scope of this document. 679 When receives a Test packet, the micro STAMP Session-Reflector MUST 680 use the receiving member link to correlate the Test packet to a micro 681 STAMP session. If there is no such a micro STAMP session, the Test 682 packet MUST be discarded. If the Reflector Member Link ID is not 683 zero, the micro STAMP Session-Reflector MUST use the Reflector member 684 link identifier to check whether it associates with the micro STAMP 685 session. If it does not, the Test packet MUST be discarded and no 686 reflected Test packet will be sent back the Session-Sender. If all 687 validation passed, the Session-Reflector sends a reflected Test 688 packet to the Session-Sender. The micro STAMP Session-Reflector MUST 689 put the Sender and Reflector member link identifiers that are 690 associated with the micro STAMP session in the Sender Member Link ID 691 and Reflector Member Link ID fields (see Figure 8 and Figure 9) 692 respectively. The Sender member link identifier is copied from the 693 received Test packet. 695 When receives a reflected Test packet, the micro STAMP Session-Sender 696 MUST use the receiving member link to correlate the reflected Test 697 Packet to a micro STAMP session. If there is no such a session, the 698 reflected Test packet MUST be discarded. If a matched micro STAMP 699 session exists, the Session-Sender MUST use the identifier carried in 700 the Sender Member Link ID field to check whether it associates with 701 the session. If the checking failed, the Test packet MUST be 702 discarded. 704 6. IANA Considerations 706 6.1. Mico OWAMP-Control Command 708 This document requires the IANA to allocate the following command 709 type from OWAMP-Control Command Number Registry. 711 Value Description Semantics Definition 712 TBD1 Request-OW-Micro-Session This document, Section 3.1 714 6.2. Mico TWAMP-Control Command 716 This document requires the IANA to allocate the following command 717 type from TWAMP-Control Command Number Registry. 719 Value Description Semantics Definition 720 TBD1 Request-TW-Micro-Session This document, Section 4.1 722 7. Security Considerations 724 The security considerations in [RFC4656], [RFC5357], [RFC8762] apply 725 to this document. 727 8. Acknowledgements 729 The authors would like to thank Min Xiao, Fang Xin for the valuable 730 comments to this work. 732 9. References 734 9.1. Normative References 736 [I-D.ietf-ippm-stamp-option-tlv] 737 Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 738 and E. Ruffini, "Simple Two-way Active Measurement 739 Protocol Optional Extensions", draft-ietf-ippm-stamp- 740 option-tlv-09 (work in progress), August 2020. 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 748 Zekauskas, "A One-way Active Measurement Protocol 749 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 750 . 752 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 753 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 754 RFC 5357, DOI 10.17487/RFC5357, October 2008, 755 . 757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 758 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 759 May 2017, . 761 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 762 Two-Way Active Measurement Protocol", RFC 8762, 763 DOI 10.17487/RFC8762, March 2020, 764 . 766 9.2. Informative References 768 [I-D.ietf-ippm-ioam-data] 769 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 770 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 771 progress), July 2020. 773 [IEEE802.1AX] 774 IEEE Std. 802.1AX, "IEEE Standard for Local and 775 metropolitan area networks - Link Aggregation", November 776 2008. 778 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 779 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 780 "Alternate-Marking Method for Passive and Hybrid 781 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 782 January 2018, . 784 Authors' Addresses 786 Zhenqiang Li 787 China Mobile 789 Email: li_zhenqiang@hotmail.com 791 Mach(Guoyi) Chen 792 Huawei 794 Email: mach.chen@huawei.com 796 Greg Mirsky 797 ZTE Corp. 799 Email: gregimirsky@gmail.com