idnits 2.17.1 draft-dang-ippm-multiple-path-measurement-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 13, 2020) is 1345 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 502, but no explicit reference was found in the text 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 D. Dang, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational W. Wang 5 Expires: February 14, 2021 China Telecom 6 L. LEE 7 LG U+ 8 C. Cheng 9 Huawei 10 August 13, 2020 12 Multi-Path Concurrent Measurement for IPPM 13 draft-dang-ippm-multiple-path-measurement-05 15 Abstract 17 This test method can test multi-paths concurrently from one edge node 18 to another edge node. This document details Multi-Path Concurrent 19 Measurement (MPCM). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 14, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 58 2. Overview of MPCM . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Principle . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.1. Single Path Measurement . . . . . . . . . . . . . . . 4 61 2.1.2. Multiple Path Measurement . . . . . . . . . . . . . . 6 62 3. MPCM-Test Packet Format and Content . . . . . . . . . . . . . 7 63 4. Expansion based on various measurement methods . . . . . . . 10 64 4.1. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 As we know, the current network has been already being in load 75 balancing mode, however it is partially congested. In other words, 76 from the same source node to the same destination node, some paths 77 have been congested to cause a decline in service quality, but some 78 paths carry less traffic and are lightly loaded. To solve the 79 problem of unbalanced network load[draft-liu-ican], the first is to 80 have the ability to detect the quality of the load sharing paths. 81 And then the traffic from the Scr node to the Dst node is required to 82 be steered from the congested paths into the lightly loaded path/ 83 paths basing on the SLA's requirement. So it's necessary to measure 84 the multi-paths in load-balancing mode. 86 In the traditional method, the paths are measured separately because 87 they aren't maintained by the path group. If the multiple load 88 sharing paths are required to be selected based on the SLA 89 information, the measured SLA information needs to be comparable. If 90 you want to ensure that the data obtained by the test is available 91 and accurate, the multi-paths are required to maintain by the path 92 group in order that the test start and end points must be same. 94 For example, the low latency services require millisecond delays. If 95 the start time and the end time aren't same, the measured data may 96 not be in one test cycle, and the accuracy of this data is relatively 97 low and the data cannot be comparedFigure 1. 99 Path1 100 +-+-+-+-+-+-+-+-+ 101 | | 102 +-+-+-+-+-+-+-+-+ 104 Path2 105 +-+-+-+-+-+-+-+-+ 106 | | 107 +-+-+-+-+-+-+-+-+ 109 Path3 110 +-+-+-+-+-+-+-+-+ 111 | | 112 +-+-+-+-+-+-+-+-+ 114 ----------------------------------------------------------------------- 115 0 t 117 Figure 1: Measured Data in the Different Cycles 119 The Multi-Path Concurrent Measurement (MPCM) is required, which can 120 be used bi-directionally to concurrently measure multi-paths metrics 121 between two network elements. At the same time, this method also 122 consider saving the number of test messages to reduces the load on 123 the network. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119. 131 1.2. Terminology & Abbreviations 133 o Muti-paths 135 * There are multiple paths between two nodes in the network. 136 These paths may be equal-cost multi-path (ECMP) mode or 137 unequal-cost multiple (UCMP) mode. In a real network, they 138 might be one [draft-ietf-spring-segment-routing-policy] or 139 [RFC7348] tunnel group. 141 o Concurrent 142 * In order to ensure comparability between multiple paths, the 143 test start point and the test end point are required to be 144 same. 146 2. Overview of MPCM 148 The Multi-Path Concurrent Measurement (MPCM) is the way of 149 measurement of multi-paths metrics. 151 MPCM can be embedded into a variety of transports such as NSH, 152 Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4. 154 2.1. Principle 156 To complete the target scenario, we need to optimize the single-path 157 measurement mechanism, and then further diffuse the single-path 158 measurement mechanism to multiple-path. 160 1. For a single tunnel, the Dst needs to know when to start timing 161 in order to delimit. The Dst needs to solve various problems such as 162 congestion and discarding of measurement packets. Therefore, the Dst 163 needs to initiate a periodic response. 165 2. For multiple paths, the Dst needs to respond one measurement 166 message with multiple path information in its specific time, solving 167 the problems such as inconsistent initiation of any path, 168 inconsistent measurement periods, clock drift, and different delays. 170 2.1.1. Single Path Measurement 172 |-----ti-----|-----ti-----|-----ti-----| 173 t0 t1 t2 174 Src ----------------------------------------- 175 | \ \ 176 | \ \ 177 | \ \ 178 | \ \ 179 Dst ----------------------------------------- 180 t0' t1' t2' 182 Figure 2: Single path measurement 184 A path between Scr node and Dst node in the network to obtain 185 measurement results at equal intervals is as follows: 187 1) Set the measurement interval ti. 189 a) Before the test starts, the Scr sends a protocol packet to the Dst 190 and sets the test interval ti. 192 b) After receiving the protocol message, the Dst sets the test 193 interval ti for the Scr and Dst, and replies to the Scr to confirm 194 that the setting is successful. The congestion at the Dst will be 195 counted at intervals ti. 197 c) After receiving the interval setting successfully, the Scr starts 198 to start measurement. 200 2) The Scr sends the first delimited message, which includes the 201 sending timestamp t0, and starts to count the data packets sent. 203 3) After receiving the first delimited message, the Dst end stamps 204 the time stamp t0 'and starts to count the received data messages. 206 4) The Scr sends the second delimited message at time t1, where t1 = 207 t0 + ti, the message includes the sending timestamp t1, and counts 208 the number of data packets sent. The first delimited message uses 209 high priority, and the second delimited message uses normal priority. 210 Because the second delimitation message has a low priority and a 211 large queuing delay, the interval between the first delimitation 212 message and the second delimitation message shall become larger at 213 the Dest. 215 5) At the time t0 '+ ti, the Dst counts the number of packets 216 received between t0' and t0 '+ ti, and sends the message back to the 217 Src with the number of packets, the sending time t0 and the receiving 218 time t0'. If the delimitation message has not been received at t0' + 219 2 * ti time, the Dst repeats the previous actions, and so on. 221 6) When the second delimited message arrives at the Dst, the Dst 222 counts the number of packets received between t0 'and t1' at t1 223 'time, and sends the message back to the Src with the number of 224 packets, the packet sending time t0 and the packet receiving time t0 225 '. 227 7) After t1 ', the sending time in the message from the Dst is 228 updated to t1, and the receiving time in the message from the Dst is 229 updated to t1'. The number of packets is still the number of packets 230 received within ti time. 232 8) Assuming that t1' is between t0' + (x-1) * ti and t0' + x * ti, 233 then the congestion in the interval ti is calculated in two parts. 234 The first part is from t0 '+ (x-1) * ti to t1', The statistics 235 packets sent at t1' must include the packet statistics and time t0'; 236 the second part is from t1 'to t0' + x * ti, t0 '+ x * ti need to 237 include the packet statistics and t1'. 239 9) Repeat the above steps. 241 2.1.2. Multiple Path Measurement 243 | <-----------> | <------------>| <------------> | 244 | Ti | Ti | Ti | 245 Path1 | m1 m2 | m3 | m4 m5 | m6 246 --------------------------------------------------------------- 247 | | | | 248 Path2 | m1 | m2 m3 m4 | m5 249 --------------------------------------+------------------------ 250 | | | | 251 Path3 | m1 m2 m3 m4 | m5 | m6 252 --------+---------------+----------------+----------------+---- 254 Figure 3: Multiple path measurement 256 There are multiple paths in the tunnel between Src node and Dst nodes 257 in the network. This method is mainly implemented at the Dst. 259 1) Set the measurement interval ti. 261 a) Before the test starts, the Src sends a protocol packet to the 262 Dst, setting the number of paths and the measurement interval ti. 263 The measurement result of each path is a message with measurement 264 data. 266 b) After receiving the protocol message, the Dst sets the number of 267 paths and measurement interval ti, and replies to the source to 268 confirm the successful setting. 270 c) After receiving the message with the number of paths and 271 measurement interval, the Src starts to start measurement. 273 2) On each path, the Src continuously sends measurement packets, and 274 the Dst continuously calculates the measurement results at intervals 275 ti. 277 3) The Dst collects the measurement results of each path at intervals 278 ti after the earliest measurement result of multiple paths is came 279 out. 281 4) The results of multiple paths in the same interval time ti are 282 counted as a group. If there is no measured results on the specific 283 path in the interval ti, the relevant information is set 0 in the 284 group results. A set of measurement results packaged of multiple 285 paths are taken back to the Src. 287 5) The measurement results of multiple paths on the Dst are 288 continuously packaged at intervals ti and sent back to the Src. The 289 packaged message carries the sequence number within the message to 290 prevent out of order. 292 3. MPCM-Test Packet Format and Content 294 This section defines path header and associated data types required 295 for MPCM. 297 Firstly one path packet formatFigure 4 of multi-path can be defined. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Session ID | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Path ID | Path-E2E-Type | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Flags | Transaction ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 4: MPCM Path header 311 o Session ID: A set of load sharing paths 313 o Path ID: One path of the session. 315 o Path-E2E-Type: A 16-bit identifier which Indicates whether the 316 packet type is a send message or a request message. 318 o Flags: 8-bit field. Identify the query or response type. 319 Following flags are defined: 321 * Bit 0 Identify the query type 323 * Bit 1 Identify the response type 325 * Reserved 327 o Transaction ID: 16-bit identifier of one measurement transaction. 328 The sender and receiver to identify measurement transactions based 329 on Transaction ID. 331 When a measurement is for a set of paths, each query message is made 332 for each path, but only one unified response message repliesFigure 5. 334 Sender Receiver 335 | | 336 | Query message of Path1 | 337 | -------------------------------------->| 338 | Query message of Path2 | 339 |--------------------------------------->| 340 | ... | 341 | ... | 342 | Query message of PathN | 343 |--------------------------------------->| 344 | | 345 | | 346 | | 347 | | 348 | | 349 | Response message of All multi-paths | 350 |<---------------------------------------| 351 | | 352 | | 354 Figure 5: Query and Response message 356 The measurement response packet format of a path is as 357 followsFigure 6. 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 | E2E PathN Option Header | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 | PathN Edge-to-Edge Option Data | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 6: Query message 371 The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge 372 Option Data of [draft-ietf-ippm-ioam-data-04]. 374 It suppose there are N paths between two points.The measurement 375 response packet format of multi-paths is as followsFigure 6. 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 | E2E Path1 Option Header | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Path1 Edge-to-Edge Option Data | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 386 ~ ... ~ 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 388 | | 389 | E2E PathN-1 Option Header | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | PathN-1 Edge-to-Edge Option Data | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 | E2E PathN Option Header | 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 | PathN Edge-to-Edge Option Data | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 7: Response message 407 o Long-term measurement 409 * The receiver can wait until it receives all measurement 410 requests of a set of path and then responds. 412 o Short-term measurement 414 * The Sender can query once t. 416 * The receiver can reply once t. 418 The overall solution needs to consider two methods of long-period 419 measurement and short-period measurement. 421 4. Expansion based on various measurement methods 423 The measurement message format defined by this document can be 424 extended based on various measurement methods. 426 4.1. IOAM 428 A new type may be added in IOAM-E2E-Type of IOAM Edge-to-Edge Option 429 header[draft-ietf-ippm-ioam-data-04-section4.4] as follow. 431 o Bit 4: Multiple paths measurement. 433 This bit is set by the headend node if Multi-Path Concurrent 434 Measurement is activated. 436 A common registry is maintained for IOAM-Types, see Section 6. 438 For path-based quality measurements, there is no need to measure each 439 message because the large-scale deployment consumes too much network 440 resources. Here, the way of periodic measurement is recommended.In a 441 period, if there is a packet, the appropriate packet is selected to 442 be inserted into the iOAM packet; if there is no packet, a 443 measurement packet is directly generated[draft-dang-ippm-congestion]. 445 5. Data Export 447 MPCM nodes collect information for packets traversing a domain that 448 supports MPCM. MPCM process the information further and export the 449 information using e.g., IPFIX. Raw data export of IOAM data using 450 IPFIX is discussed in [draft-spiegel-ippm-ioam-rawexport-00]. 452 6. IANA Considerations 454 This document requests the following IANA Actions. 456 IOAM E2E Type Registry: 458 Bit 4 Multiple ways measurement 460 7. Security Considerations 462 The Proof of Transit option (Section Section 4.3 In-situ OAM 463 [draft-ietf-ippm-ioam-data-04-section4.4]) is used for verifying the 464 path of data packets. 466 8. Acknowledgements 468 TBD 470 9. Normative References 472 [draft-dang-ippm-congestion] 473 "A One-Path Congestion Metric for IPPM", 474 . 477 [draft-ietf-ippm-ioam-data-04] 478 "A Variety of Transports", 479 . 482 [draft-ietf-ippm-ioam-data-04-section4.4] 483 "IOAM Edge-to-Edge Option", 484 . 487 [draft-ietf-spring-segment-routing-policy] 488 "Segment Routing Policy Architecture", 489 . 492 [draft-liu-ican] 493 "Instant Congestion Assessment Network (iCAN) for Traffic 494 Engineering", . 497 [draft-spiegel-ippm-ioam-rawexport-00] 498 "In-situ OAM raw data export with IPFIX", 499 . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)", 508 . 510 Authors' Addresses 512 Joanna Dang (editor) 513 Huawei 514 Beijing 515 China 517 Email: dangjuanna@huawei.com 519 Jianglong 520 China Telecom 521 Beijing 522 China 524 Email: wangjl50@chinatelecom.cn 526 Shinyoung 527 LG U+ 528 Seoul 529 Korea 531 Email: leesy@lguplus.co.kr 533 Liang 534 Huawei 535 Beijing 536 China 538 Email: liang.cheng@huawei.com