idnits 2.17.1 draft-dang-ippm-multiple-path-measurement-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 360, but no explicit reference was found in the text Summary: 0 errors (**), 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: May 7, 2020 China Telecom 6 W. LEE 7 LG U+ 8 November 4, 2019 10 Multi-Path Concurrent Measurement for IPPM 11 draft-dang-ippm-multiple-path-measurement-02 13 Abstract 15 This test method can test multi-paths concurrently from one edge node 16 to another edge node. This document details Multi-Path Concurrent 17 Measurement (MPCM). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 7, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 56 2. Overview of MPCM . . . . . . . . . . . . . . . . . . . . . . 4 57 3. MPCM-Test Packet Format and Content . . . . . . . . . . . . . 4 58 4. Expansion based on various measurement methods . . . . . . . 7 59 4.1. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 As we know, the current network has been already being in load 70 balancing mode, however it is partially congested. In other words, 71 from the same source node to the same destination node, some paths 72 have been congested to cause a decline in service quality, but some 73 paths carry less traffic and are lightly loaded. To solve the 74 problem of unbalanced network load[draft-liu-ican], the first is to 75 have the ability to detect the quality of the load sharing paths. 76 And then the traffic from the Scr node to the Dst node is required to 77 be steered from the congested paths into the lightly loaded path/ 78 paths basing on the SLA's requirement. So it's necessary to measure 79 the multi-paths in load-balancing mode. 81 In the traditional method, the paths are measured separately because 82 they aren't maintained by the path group. If the multiple load 83 sharing paths are required to be selected based on the SLA 84 information, the measured SLA information needs to be comparable. If 85 you want to ensure that the data obtained by the test is available 86 and accurate, the multi-paths are required to maintain by the path 87 group in order that the test start and end points must be same. 89 For example, the low latency services require millisecond delays. If 90 the start time and the end time aren't same, the measured data may 91 not be in one test cycle, and the accuracy of this data is relatively 92 low and the data cannot be comparedFigure 1. 94 Path1 95 +-+-+-+-+-+-+-+-+ 96 | | 97 +-+-+-+-+-+-+-+-+ 99 Path2 100 +-+-+-+-+-+-+-+-+ 101 | | 102 +-+-+-+-+-+-+-+-+ 104 Path3 105 +-+-+-+-+-+-+-+-+ 106 | | 107 +-+-+-+-+-+-+-+-+ 109 ----------------------------------------------------------------------- 110 0 t 112 Figure 1: Measured Data in the Different Cycles 114 The Multi-Path Concurrent Measurement (MPCM) is required, which can 115 be used bi-directionally to concurrently measure multi-paths metrics 116 between two network elements. At the same time, this method also 117 consider saving the number of test messages to reduces the load on 118 the network. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119. 126 1.2. Terminology & Abbreviations 128 o Muti-paths 130 * There are multiple paths between two nodes in the network. 131 These paths may be equal-cost multi-path (ECMP) mode or 132 unequal-cost multiple (UCMP) mode. In a real network, they 133 might be one [draft-ietf-spring-segment-routing-policy] or 134 [RFC7348] tunnel group. 136 o Concurrent 138 * In order to ensure comparability between multiple paths, the 139 test start point and the test end point are required to be 140 same. 142 2. Overview of MPCM 144 The Multi-Path Concurrent Measurement (MPCM) is the way of 145 measurement of multi-paths metrics. 147 MPCM can be embedded into a variety of transports such as NSH, 148 Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4. 150 3. MPCM-Test Packet Format and Content 152 This section defines path header and associated data types required 153 for MPCM. 155 Firstly one path packet formatFigure 2 of multi-path can be defined. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Session ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Path ID | Path-E2E-Type | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Flags | Transaction ID | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 2: MPCM Path header 169 o Session ID: A set of load sharing paths 171 o Path ID: One path of the session. 173 o Path-E2E-Type: A 16-bit identifier which Indicates whether the 174 packet type is a send message or a request message. 176 o Flags: 8-bit field. Identify the query or response type. 177 Following flags are defined: 179 * Bit 0 Identify the query type 181 * Bit 1 Identify the response type 183 * Reserved 185 o Transaction ID: 16-bit identifier of one measurement transaction. 186 The sender and receiver to identify measurement transactions based 187 on Transaction ID. 189 When a measurement is for a set of paths, each query message is made 190 for each path, but only one unified response message repliesFigure 3. 192 Sender Receiver 193 | | 194 | Query message of Path1 | 195 | -------------------------------------->| 196 | Query message of Path2 | 197 |--------------------------------------->| 198 | ... | 199 | ... | 200 | Query message of PathN | 201 |--------------------------------------->| 202 | | 203 | | 204 | | 205 | | 206 | | 207 | Response message of All multi-paths | 208 |<---------------------------------------| 209 | | 210 | | 212 Figure 3: Query and Response message 214 The measurement response packet format of a path is as 215 followsFigure 4. 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 | E2E PathN Option Header | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 | PathN Edge-to-Edge Option Data | 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 4: Query message 229 The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge 230 Option Data of [draft-ietf-ippm-ioam-data-04]. 232 It suppose there are N paths between two points.The measurement 233 response packet format of multi-paths is as followsFigure 4. 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | E2E Path1 Option Header | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 | Path1 Edge-to-Edge Option Data | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 244 ~ ... ~ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 246 | | 247 | E2E PathN-1 Option Header | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 | PathN-1 Edge-to-Edge Option Data | 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 | E2E PathN Option Header | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 | PathN Edge-to-Edge Option Data | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 5: Response message 265 o Long-term measurement 267 * The receiver can wait until it receives all measurement 268 requests of a set of path and then responds. 270 o Short-term measurement 272 * The Sender can query once t. 274 * The receiver can reply once t. 276 The overall solution needs to consider two methods of long-period 277 measurement and short-period measurement. 279 4. Expansion based on various measurement methods 281 The measurement message format defined by this document can be 282 extended based on various measurement methods. 284 4.1. IOAM 286 A new type may be added in IOAM-E2E-Type of IOAM Edge-to-Edge Option 287 header[draft-ietf-ippm-ioam-data-04-section4.4] as follow. 289 o Bit 4: Multiple paths measurement. 291 This bit is set by the headend node if Multi-Path Concurrent 292 Measurement is activated. 294 A common registry is maintained for IOAM-Types, see Section 6. 296 For path-based quality measurements, there is no need to measure each 297 message because the large-scale deployment consumes too much network 298 resources. Here, the way of periodic measurement is recommended.In a 299 period, if there is a packet, the appropriate packet is selected to 300 be inserted into the iOAM packet; if there is no packet, a 301 measurement packet is directly generated[draft-dang-ippm-congestion]. 303 5. Data Export 305 MPCM nodes collect information for packets traversing a domain that 306 supports MPCM. MPCM process the information further and export the 307 information using e.g., IPFIX. Raw data export of IOAM data using 308 IPFIX is discussed in [draft-spiegel-ippm-ioam-rawexport-00]. 310 6. IANA Considerations 312 This document requests the following IANA Actions. 314 IOAM E2E Type Registry: 316 Bit 4 Multiple ways measurement 318 7. Security Considerations 320 The Proof of Transit option (Section Section 4.3 In-situ OAM 321 [draft-ietf-ippm-ioam-data-04-section4.4]) is used for verifying the 322 path of data packets. 324 8. Acknowledgements 326 TBD 328 9. Normative References 330 [draft-dang-ippm-congestion] 331 "A One-Path Congestion Metric for IPPM", 332 . 335 [draft-ietf-ippm-ioam-data-04] 336 "A Variety of Transports", 337 . 340 [draft-ietf-ippm-ioam-data-04-section4.4] 341 "IOAM Edge-to-Edge Option", 342 . 345 [draft-ietf-spring-segment-routing-policy] 346 "Segment Routing Policy Architecture", 347 . 350 [draft-liu-ican] 351 "Instant Congestion Assessment Network (iCAN) for Traffic 352 Engineering", . 355 [draft-spiegel-ippm-ioam-rawexport-00] 356 "In-situ OAM raw data export with IPFIX", 357 . 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)", 366 . 368 Authors' Addresses 370 Joanna Dang (editor) 371 Huawei 372 Beijing 373 China 375 Email: dangjuanna@huawei.com 377 Jianglong 378 China Telecom 379 Beijing 380 China 382 Email: wangjl50@chinatelecom.cn 384 Shinyoung 385 LG U+ 386 Seoul 387 Korea 389 Email: leesy@lguplus.co.kr