idnits 2.17.1 draft-fioccola-v6ops-ipv6-alt-mark-01.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 abstract seems to contain references ([RFC7837], [RFC8321]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2018) is 2124 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 (-02) exists of draft-fear-ippm-mpdm-00 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS Working Group G. Fioccola 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track G. Van de Velde 5 Expires: December 7, 2018 Nokia 6 M. Cociglio 7 Telecom Italia 8 P. Muley 9 Nokia 10 June 5, 2018 12 IPv6 Performance Measurement with Alternate Marking Method 13 draft-fioccola-v6ops-ipv6-alt-mark-01 15 Abstract 17 This document describes how the alternate marking method in [RFC8321] 18 can be used as the passive performance measurement method in an IPv6 19 domain, and will discuss the strengths and the weaknesses of the 20 implementation options available to network operations. It proposes 21 how to extend [RFC7837] to apply alternate marking technique. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 7, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. IPv6 application of Alternate Marking . . . . . . . . . . . . 3 65 2.1. IPv6 Extension Headers as Marking Field . . . . . . . . . 3 66 2.2. Other Possibilities . . . . . . . . . . . . . . . . . . . 5 67 2.2.1. IPv6 Addresses as Marking Field . . . . . . . . . . . 5 68 2.2.2. IPv6 Flow Label as Marking Field . . . . . . . . . . 5 69 3. Alternate Marking Method Operation . . . . . . . . . . . . . 6 70 3.1. Single Mark Measurement . . . . . . . . . . . . . . . . . 6 71 3.2. Double Mark Measurement . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 This document reports a summary on the possible implementation 83 options for the application of the alternate marking method in an 84 IPv6 domain. 86 [RFC8321] describes passive performance measurement method, which can 87 be used to measure packet loss, latency and jitter on live traffic. 88 Because this method is based on marking consecutive batches of 89 packets the method often referred as Alternate Marking Method. 91 This document defines how the alternate marking method can be used to 92 measure packet loss and delay metrics of IPv6 tunneled packets or 93 SRv6 policies. 95 The IPv6 Header Format defined in [RFC8200] introduces the format of 96 IPv6 addresses, the Extension Headers in the base IPv6 Header and the 97 availability of a 20-bit flow label, that can be considered for the 98 application of the Alternate Marking methodology. 100 2. IPv6 application of Alternate Marking 102 The application of the alternate marking requires a marking field. 103 The alternatives that can be taken into consideration for the choice 104 of the marking field are the following: 106 o Extension Header 108 o IPv6 Address 110 o Flow Label 112 2.1. IPv6 Extension Headers as Marking Field 114 A new type of EH may be a solution space proposal (e.g. [RFC8250] 115 and [RFC7837] give a chance). 117 A possibility can be to use a Hop-By-Hop(HBH) Extension Header(EH). 118 The assumption is that a HBH EH with an alternate marking measurement 119 option can be defined. The router processing can be optimized to 120 handle this use case. 122 Using a new EH assumes that ALL routers in the domain support this 123 type of headers, which complicates backward compatibility of the 124 technology. The extension of an existing EH (e.g. [RFC7837]) can 125 overcome this issue. 127 0 1 2 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Option Type | Option Length |X|L|E|C| MF|res| 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Mark Field (MF) is: 135 0 136 0 1 137 +-+-+-+-+ 138 | S | D | 139 +-+-+-+-+ 141 Figure 1: ConEx HBH Option Layout with Mark Field 143 where: 145 o S - Single mark method; 147 o D - Double mark method. 149 The Figure 1 defines a new ConEx HBH (Hop-By-Hop) Option Layout. 151 This proposal starts from ConEx Destination Option Layout defined in 152 [RFC7837], where the Reserved (res) field is made by four bits that 153 are not used in that specification, in fact they are set to zero by 154 the sender and are ignored by the receiver. 156 This document aims to introduce the Mark Field (2 bits from 4 bits 157 res field). So the Mark Field (MF) reduces the number of Reserved 158 bits and the Reserved (res) field is now made by 2 bits. 160 It is important to highlight that the Destination Option Layout is 161 used as Hop-By-Hop Option Layout, since the alternate marking 162 methodology in [RFC8321] allows, by definition, Hop-By-Hop 163 performance measurements. 165 [I-D.krishnan-conex-ipv6] also tried to introduce a ConEx HBH Options 166 and inspired this proposal. 168 [I-D.fear-ippm-mpdm] introduces Marking Performance and Diagnostic 169 Metrics (M-PDM) and aims to combine [RFC8250] with [RFC8321], while 170 the extension of [RFC7837], proposed in this document, is optimized 171 to include only marking method without any considerations on how to 172 report and manage, this can be done in-band or out-of-band depending 173 on the case. 175 2.2. Other Possibilities 177 This section reports the other possibilities that have been 178 discussed. 180 2.2.1. IPv6 Addresses as Marking Field 182 There is an advantage of using destination addresses (DA) to encode 183 the alternate marking method. In addition to identifying a host, a 184 destination address is also and more fundamentally identifying an 185 exit point from the forwarding domain. It indicates where processing 186 for forwarding to the DA stops, and where other processing of the 187 packet is to occur. Using the DA to encode this alternate marking 188 processing means that it is easy to retrofit into existing devices 189 and models. There is no need to replace existing IPv6 forwarding 190 devices, because they already support DA based forwarding. 192 However using DA for marking seems a lot expensive. 194 2.2.2. IPv6 Flow Label as Marking Field 196 Considering the Flow Label, [RFC6294] makes a survey of Proposed Use 197 Cases for the IPv6 Flow Label. The flow label is an immutable field 198 recommended to contain a pseudo-random value, however, often it has 199 the default value of zero. [RFC6436] and [RFC6437] open the door for 200 IPv6 Flow Label to be used in a controlled environment and [RFC6438] 201 describes the use of the IPv6 Flow Label field for load distribution 202 purpose, especially across Equal Cost Multi-Path (ECMP) and/or Link 203 Aggregation Group (LAG) paths. In addition it is possible to mention 204 [I-D.krishnan-6man-header-reserved-bits] that tried to set aside 4 205 bits from the flow label field for future expansion. 207 There are few drawbacks to use Flow Label instead of an EH solution 208 or IPv6 Addresses for IPv6 alternate marking, in particular an easier 209 backward compatibility and less bits on the wire. In this way 210 nothing breaks if a transit router does not have the capability of 211 understanding the Flow Label context. 213 Since the flow-label based load balancing has been defined, the 214 application of the Alternate Marking method to the flow label could 215 be realised with two fundamental assumptions: 217 o The original flow-label reconstructed when leaving the controlled 218 domain. 220 o The usage of IPv6 tunnels (IPv6inIPv6, IPSec, IPv6 UDP, etc..) or 221 SRv6 policies. 223 In this case, the controlled domain reflects to the fact that it is a 224 network operator choice that grabs control of packet handling within 225 its own network. In fact, regarding the flow label, four options can 226 be supposed: 228 1) Just do not do anything with Flow Label (leave it default). 230 2) Entropy only and NO alternate marking for performance 231 measurements. 233 3) Alternate marking only and NO usage of entropy. 235 4) Alternate marking and entropy (in this case the entropy SHOULD 236 be based upon a subset of bits because otherwise paths may be 237 changed when the marking changes). 239 3. Alternate Marking Method Operation 241 [RFC8321] describes in detail the methodology, that we briefly 242 illustrate also here. 244 3.1. Single Mark Measurement 246 As explained in the [RFC8321], marking can be applied to delineate 247 blocks of packets based either on equal number of packets in a block 248 or based on equal time interval. The latter method offers better 249 control as it allows better account for capabilities of downstream 250 nodes to report statistics related to batches of packets and, at the 251 same time, time resolution that affects defect detection interval. 253 If the Single Mark measurement used, then the D flag MUST be set to 254 zero on transmit and ignored by monitoring point. 256 The S flag is used to create alternate flows to measure the packet 257 loss by switching value of the S flag. Delay metrics MAY be 258 calculated with the alternate flow using any of the following 259 methods: 261 o First/Last Batch Packet Delay calculation: timestamps are 262 collected based on order of arrival so this method is sensitive to 263 packet loss and re-ordering. 265 o Average Packet Delay calculation: an average delay is calculated 266 by considering the average arrival time of the packets within a 267 single block. This method only provides single metric for the 268 duration of the block and it doesn't give information about the 269 delay distribution. 271 3.2. Double Mark Measurement 273 Double Mark method allows more detailed measurement of delays for the 274 monitored flow but it requires more nodal and network resources. If 275 the Double Mark method used, then the S flag MUST be used to create 276 the alternate flow. The D flag MUST be used to mark single packets 277 to measure delay jitter. 279 The first marking (S flag alternation) is needed for packet loss and 280 also for average delay measurement. The second marking (D flag is 281 put to one) creates a new set of marked packets that are fully 282 identified and dedicated for delay. This method is useful to have 283 not only the average delay but also to know more about the statistic 284 distribution of delay values. 286 4. Security Considerations 288 tbc 290 5. IANA Considerations 292 tbc 294 6. Acknowledgements 296 The authors would like to thank Fred Baker, Ole Troan, Robert Hinden, 297 Suresh Krishnan, Brian Carpenter, Roberta Maglione, Tom Herbert, Mark 298 Smith, Joel Halpern, Fernando Gont, Xiaohu Xu and Joel Jaeggli for 299 their comments and feedbacks. 301 7. References 303 7.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 7.2. Informative References 312 [I-D.fear-ippm-mpdm] 313 Elkins, N., Fioccola, G., and m. mackermann@bcbsm.com, 314 "IPv6 Marking and Performance and Diagnostic Metrics 315 (MPDM)", draft-fear-ippm-mpdm-00 (work in progress), June 316 2018. 318 [I-D.krishnan-6man-header-reserved-bits] 319 Krishnan, S. and J. Halpern, "Reserving bits in the IPv6 320 header for future use", draft-krishnan-6man-header- 321 reserved-bits-00 (work in progress), October 2010. 323 [I-D.krishnan-conex-ipv6] 324 Krishnan, S., Kuehlewind, M., and C. Ucendo, "Options for 325 Conex marking in IPv6 packets", draft-krishnan-conex- 326 ipv6-02 (work in progress), March 2011. 328 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 329 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 330 2011, . 332 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 333 Update to the IPv6 Flow Label Specification", RFC 6436, 334 DOI 10.17487/RFC6436, November 2011, 335 . 337 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 338 "IPv6 Flow Label Specification", RFC 6437, 339 DOI 10.17487/RFC6437, November 2011, 340 . 342 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 343 for Equal Cost Multipath Routing and Link Aggregation in 344 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 345 . 347 [RFC7837] Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli, 348 "IPv6 Destination Option for Congestion Exposure (ConEx)", 349 RFC 7837, DOI 10.17487/RFC7837, May 2016, 350 . 352 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 353 (IPv6) Specification", STD 86, RFC 8200, 354 DOI 10.17487/RFC8200, July 2017, 355 . 357 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 358 Performance and Diagnostic Metrics (PDM) Destination 359 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 360 . 362 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 363 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 364 "Alternate-Marking Method for Passive and Hybrid 365 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 366 January 2018, . 368 Authors' Addresses 370 Giuseppe Fioccola 371 Telecom Italia 372 Torino 373 Italy 375 Email: giuseppe.fioccola@telecomitalia.it 377 Gunter Van de Velde 378 Nokia 379 Antwerp 380 BE 382 Email: gunter.van_de_velde@nokia.com 384 Mauro Cociglio 385 Telecom Italia 386 Torino 387 Italy 389 Email: mauro.cociglio@telecomitalia.it 391 Praveen Muley 392 Nokia 393 Mountain View 394 USA 396 Email: praveen.muley@nokia.com