idnits 2.17.00 (12 Aug 2021) /tmp/idnits31718/draft-zhou-ippm-enhanced-alternate-marking-09.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 document date (February 28, 2022) is 75 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 (-14) exists of draft-ietf-6man-ipv6-alt-mark-12 ** Downref: Normative reference to an Informational RFC: RFC 7799 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM T. Zhou, Ed. 3 Internet-Draft G. Fioccola 4 Intended status: Standards Track Huawei 5 Expires: September 1, 2022 Y. Liu 6 China Mobile 7 M. Cociglio 8 Telecom Italia 9 S. Lee 10 LG U+ 11 W. Li 12 Huawei 13 February 28, 2022 15 Enhanced Alternate Marking Method 16 draft-zhou-ippm-enhanced-alternate-marking-09 18 Abstract 20 This document extends the IPv6 Alternate Marking Option to provide 21 enhanced capabilities and allow advanced functionalities. With this 22 extension, it can be possible to perform thicker packet loss 23 measurements and more dense delay measurements with no limitation for 24 the number of concurrent flows under monitoring. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 1, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 5.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The Alternate Marking [RFC8321] and Multipoint Alternate Marking 73 [RFC8889] define the Alternate Marking technique that is a hybrid 74 performance measurement method, per [RFC7799] classification of 75 measurement methods. This method is based on marking consecutive 76 batches of packets and it can be used to measure packet loss, 77 latency, and jitter on live traffic. 79 The IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] applies the 80 Alternate Marking Method to IPv6, and defines an Extension Header 81 Option to encode the Alternate Marking Method for both the Hop-by-Hop 82 Options Header and the Destination Options Header. Similarly, SRv6 83 AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking 84 data is carried as a TLV in the Segment Routing Header. 86 While the IPv6 AltMark Option implements the basic alternate marking 87 methodology, this document defines extended data fields for the 88 AltMark Option and provides enhanced capabilities to overcome some 89 challenges and enable future proof applications. 91 It is worth mentioning that the enhanced capabilities are intended 92 for further use and are optional. 94 Some possible enhanced applications MAY be: 96 1. thicker packet loss measurements: the single marking method of 97 the base AltMark Option can be extended with additional marking 98 bits in order to get shortest marking periods under the same 99 timing conditions. 101 2. more dense delay measurements: than double marking method of the 102 base AltMark Option can be extended with additional marking bits 103 in order to identify down to each packet as delay sample. 105 3. increase the number of concurrent flows under monitoring: if the 106 20-bit FlowMonID is set independently and pseudo randomly, there 107 is a 50% chance of collision for 1206 flows. The size of 108 FlowMonIDcan can be extended to raise the entropy and therefore 109 to increase the number of concurrent flows that can be monitored. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 2. Data Fields Format 121 The Data Fields format is represented in Figure 1. A 4-bit 122 NH(NextHeader) field is allocated from the Reserved field of IPv6 123 AltMark Option [I-D.ietf-6man-ipv6-alt-mark]. It is worth 124 highlighting that remaining bits of the former Reserved field 125 continue to be reserved. 127 0 1 2 3 128 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 129 +---------------------------------------+-+-+-----------+-------+ 130 | FlowMonID |L|D| Reserved | NH | 131 +---------------------------------------+-+-+-----------+-------+ 133 Figure 1: Data fields indicator for enhanced capabilities 135 The NH (NextHeader) field is used to indicate the extended data 136 fields which are used for enhanced capabilities: 138 NextHeader value of 0x00 is reserved for backward compatibility. 139 It means that there is no extended data field attached. 141 NextHeader values of 0x01-0x08 are reserved for private use or for 142 experimentation. 144 NextHeader value of 0x09 indicates the extended data fields. The 145 format is showed in Figure 2. 147 0 1 2 3 148 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 149 +---------------------------------------+-------+-------+-------+ 150 | FlowMonID Ext | Flag | Len | R | 151 +-------------------------------+-------+-------+-------+-------+ 152 | MetaInfo | Padding (variable) | 153 +-------------------------------+-------------------------------+ 154 // Padding (variable) // 155 +-------------------------------+-------------------------------+ 157 Figure 2: Data fields extension for enhanced alternate marking 159 where: 161 o FlowMonID Ext - 20 bits unsigned integer. This is used to extend 162 the FlowMonID in order to reduce the conflict when random 163 allocation is applied. The disambiguation of the FlowMonID field 164 is discussed in IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark]. 166 o Flag - A 4-bit flag to indicate the special purpose usage (see 167 below). 169 o Len - Length. It indicates the length of the enhanced alternate 170 marking extension in bytes. 172 o R - Reserved for further use. These bits MUST be set to zero on 173 transmission and ignored on receipt. 175 o MetaInfo - A 16-bit Bitmap to indicate more meta data attached for 176 the enhanced function (see below). 178 o Padding - These bits MUST be set to zero when not being used. 180 The Flag is defined in Figure 3 as: 182 o bit 0 - Measurement mode, M bit. If M=0, it indicates that it is 183 for hop-by-hop monitoring. If M=1, it indicates that it is for 184 end-to-end monitoring. 186 o bit 2 - Flow direction identification, F bit. This flag is used 187 in the case backward direction flow monitoring is requested to be 188 set up automatically. If F=1, it indicates that the flow 189 direction is forward. If F=0, it indicates that the flow 190 direction is backward. 192 o others (shown as R) - Reserved. These bits MUST be set to zero 193 and ignored on receipt. 195 0 1 2 3 196 +-------+ 197 |M|R|F|R| 198 +-------+ 200 Figure 3: Flag data field 202 The MetaInfo is defined in the following Figure 4 as a bit map: 204 0 1 2 3 4 5 6 7 205 +---------------+ 206 | MetaInfo | 207 +---------------+ 209 Figure 4: MetaInfo data field 211 o bit 0: it indicates a 6 bytes Timestamp that is attached as 212 Padding after the MetaInfo. Timestamp(s) stands for the number of 213 seconds in the timestamp. It will overwrite the Padding after 214 MetaInfo. Timestamp(ns) stands for the number of sub-seconds in 215 the timestamp with the unit of nano second. This Timestamp is 216 filled by the encapsulation node, and is taken all the way to the 217 decapsulation node. So that all the intermediate nodes could 218 compare it with its local time, and measure the one way delay. 220 0 1 2 3 221 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 222 +-------------------------------+ 223 | Timestamp(s) | 224 +-------------------------------+-------------------------------+ 225 | Timestamp(ns) | 226 +---------------------------------------------------------------+ 228 Figure 5: Timestamp data field 230 o bit 1: it indicates the control information with the following 231 data format that is attached as Padding after the MetaInfo: 233 0 1 2 3 234 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 235 +---------------+---------------+-----------+-------------------+ 236 | DIP Mask | SIP Mask | Control | Period | 237 +---------------+---------------+-----------+-------------------+ 239 Figure 6: Control words for backward direction flow monitoring 240 This is used to set up the backward direction flow monitoring. 241 Where: 243 * DIP Mask: it is the length of the destination IP prefix. 245 * SIP Mask: it is the length of the source IP prefix. 247 * Control: it indicates more match fields to set up the backward 248 direction flow monitoring. 250 * Period: it indicates the alternate marking period with the unit 251 of second. 253 o bit 2: it indicates a 4 bytes Sequence number with the following 254 data format that is attached as Padding after the MetaInfo. The 255 unique Sequence could be used to detect the out-of-order packets, 256 in addition to the normal loss measurement. More over, the 257 Sequence can be used together with the latency measurement, so as 258 to get the per packet timestamp. 260 0 1 2 3 261 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 262 +---------------------------------------------------------------+ 263 | Sequence | 264 +---------------------------------------------------------------+ 266 Figure 7: Sequence number data field 268 It is worth noting that the meta data information forming the Padding 269 and specified above in Figure 5, Figure 6 and Figure 7 must be 270 ordered according to the order of the MetaInfo bits. 272 3. Security Considerations 274 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] analyzes different 275 security concerns and related solutions. These aspects are valid and 276 applicable also to this document. In particular the fundamental 277 security requirement is that Alternate Marking MUST only be applied 278 in a specific limited domain, as also mentioned in [RFC8799]. 280 4. IANA Considerations 282 This document has no request to IANA. 284 5. References 286 5.1. Normative References 288 [I-D.fz-spring-srv6-alt-mark] 289 Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing 290 Header encapsulation for Alternate Marking Method", draft- 291 fz-spring-srv6-alt-mark-02 (work in progress), February 292 2022. 294 [I-D.ietf-6man-ipv6-alt-mark] 295 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 296 Pang, "IPv6 Application of the Alternate Marking Method", 297 draft-ietf-6man-ipv6-alt-mark-12 (work in progress), 298 October 2021. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 306 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 307 May 2016, . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 5.2. Informative References 315 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 316 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 317 "Alternate-Marking Method for Passive and Hybrid 318 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 319 January 2018, . 321 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 322 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 323 . 325 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 326 "Multipoint Alternate-Marking Method for Passive and 327 Hybrid Performance Monitoring", RFC 8889, 328 DOI 10.17487/RFC8889, August 2020, 329 . 331 Authors' Addresses 333 Tianran Zhou 334 Huawei 335 156 Beiqing Rd. 336 Beijing 100095 337 China 339 Email: zhoutianran@huawei.com 341 Giuseppe Fioccola 342 Huawei 343 Riesstrasse, 25 344 Munich 80992 345 Germany 347 Email: giuseppe.fioccola@huawei.com 349 Yisong Liu 350 China Mobile 351 Beijing 352 China 354 Email: liuyisong@chinamobile.com 356 Mauro Cociglio 357 Telecom Italia 358 Via Reiss Romoli, 274 359 Torino 10148 360 Italy 362 Email: mauro.cociglio@telecomitalia.it 364 Shinyoung Lee 365 LG U+ 366 71, Magokjungang 8-ro, Gangseo-gu 367 Seoul 368 Republic of Korea 370 Email: leesy@lguplus.co.kr 371 Weidong Li 372 Huawei 373 156 Beiqing Rd. 374 Beijing 100095 375 China 377 Email: poly.li@huawei.com