idnits 2.17.1 draft-dang-ippm-multiple-path-measurement-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 : ---------------------------------------------------------------------------- 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 (March 4, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 279, 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 March 4, 2019 5 Expires: September 5, 2019 7 A Multi-Path Concurrent Measurement Protocol for IPPM 8 draft-dang-ippm-multiple-path-measurement-00 10 Abstract 12 This test method can test multi-paths concurrently between two edge 13 nodes. This document details Multi-Path Concurrent Measurement 14 Protocol (MPCMP). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 5, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 2 53 2. Overview of Multi-Path Concurrent Measurement Protocol . . . 3 54 3. MPCMP-Test Packet Format and Content . . . . . . . . . . . . 3 55 4. Expansion based on various measurement methods . . . . . . . 6 56 4.1. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 In load-balancing scenario, there are multiple paths adopted between 67 two edge nodes. The traffic from the Scr node to the Dst node is 68 required to be steered into to the specific path/paths basing on the 69 SLA information of each path. In the traditional method, the paths 70 are measured separately. If you want to ensure that the data 71 obtained by the test is available and accurate, then the test start 72 and end points of this set of Paths must be consistent. 74 The Multi-Path Concurrent Measurement Protocol (MPCMP) is required, 75 which can be used bi-directionally to concurrently measure multi- 76 paths metrics between two network elements. At the same time, this 77 method also saves the number of test messages and reduces the load on 78 the network. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119. 86 1.2. Terminology & Abbreviations 88 o Mutiple Paths 90 * There are multiple paths between two nodes in the network. 91 These paths may be equal-cost multi-path (ECMP) mode or 92 unequal-cost multiple (UCMP) mode. In a real network, they 93 might be one [draft-ietf-spring-segment-routing-policy] or 94 [RFC7348] tunnel. 96 o Concurrent 98 * In order to ensure comparability between multiple paths, the 99 test start point and the test end point are required to be 100 synchronized. 102 2. Overview of Multi-Path Concurrent Measurement Protocol 104 The Multi-Path Concurrent Measurement Protocol (MPCMP) is an open 105 protocol for measurement of multi-paths metrics. 107 MPCMP can be embedded into a variety of transports such as NSH, 108 Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4. 110 3. MPCMP-Test Packet Format and Content 112 This section defines path header and associated data types required 113 for MPCMP. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Session ID | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Path ID | Path-E2E-Type | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Flags | Transaction ID | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1: MPCMP Path header 127 o Session ID: A set of load sharing paths 129 o Path ID: One path of the session. 131 o Path-E2E-Type: A 16-bit identifier which Indicates whether the 132 packet type is a send message or a request message. 134 o Flags: 8-bit field. Identify the query or response type. 135 Following flags are defined: 137 * Bit 0 Identify the query type 139 * Bit 1 Identify the response type 141 * Reserved 143 o Transaction ID: 16-bit identifier of one measurement transaction. 144 The sender and receiver to identify measurement transactions based 145 on Transaction ID. 147 When a measurement is for a set of paths, each query message is made 148 for each path, but only one unified response message replies. 149 Therefore, the message format is defined as follows. 151 The measurement packet format of a path is as follows. 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 | E2E PathN Option Header | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 | PathN Edge-to-Edge Option Data | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 2: Query message 165 The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge 166 Option Data of [draft-ietf-ippm-ioam-data-04]. 168 The response type message format is as follows. It suppose there are 169 N paths between two points. 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 | E2E Path1 Option Header | 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 | Path1 Edge-to-Edge Option Data | 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 180 ~ ... ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 182 | | 183 | E2E PathN-1 Option Header | 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 | PathN-1 Edge-to-Edge Option Data | 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 | E2E PathN Option Header | 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 | PathN Edge-to-Edge Option Data | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 3: Response message 201 o Long-term measurement 203 * The receiver can wait until it receives all measurement 204 requests of a set of path and then responds. 206 o Short-term measurement 208 * The Sender can query once t. 210 * The receiver can reply once t. 212 The overall solution needs to consider two methods of long-period 213 measurement and short-period measurement. 215 4. Expansion based on various measurement methods 217 The measurement message format defined by this document can be 218 extended based on various measurement methods. 220 4.1. IOAM 222 A new type is added in IOAM-E2E-Type of IOAM Edge-to-Edge Option 223 header[draft-ietf-ippm-ioam-data-04-section4.4] as follow. 225 o Bit 4: Multiple paths measurement. 227 This bit is set by the headend node if Multi-Path Concurrent 228 Measurement is activated. 230 A common registry is maintained for IOAM-Types, see Section 6. 232 5. Data Export 234 MPCMP nodes collect information for packets traversing a domain that 235 supports MPCMP. MPCMP process the information further and export the 236 information using e.g., IPFIX. Raw data export of IOAM data using 237 IPFIX is discussed in [draft-spiegel-ippm-ioam-rawexport-00]. 239 6. IANA Considerations 241 This document requests the following IANA Actions. 243 IOAM E2E Type Registry: 245 Bit 4 Multiple ways measurement 247 7. Security Considerations 249 The Proof of Transit option (Section Section 4.3 In-situ OAM 250 [draft-ietf-ippm-ioam-data-04-section4.4]) is used for verifying the 251 path of data packets. 253 8. Acknowledgements 255 TBD 257 9. Normative References 259 [draft-ietf-ippm-ioam-data-04] 260 "A Variety of Transports", 261 . 264 [draft-ietf-ippm-ioam-data-04-section4.4] 265 "IOAM Edge-to-Edge Option", 266 . 269 [draft-ietf-spring-segment-routing-policy] 270 "Segment Routing Policy Architecture", 271 . 274 [draft-spiegel-ippm-ioam-rawexport-00] 275 "In-situ OAM raw data export with IPFIX", 276 . 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)", 285 . 287 Author's Address 289 Joanna Dang (editor) 290 Huawei 291 Beijing 292 China 294 Email: dangjuanna@huawei.com